From serguei.spitsyn at oracle.com Tue Sep 1 08:09:27 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 1 Sep 2020 01:09:27 -0700 Subject: RFR(S) : 8252477 : nsk/share/ArgumentParser should expect that jtreg "splits" an argument In-Reply-To: References: <26E3A312-A45E-489F-A5B1-F1E67CBE807A@oracle.com> <848EB368-B244-4376-91D0-770FF0141477@oracle.com> Message-ID: Hi Igor, LGTM++ It is a nice clean. Surprisingly, this code had a lot of typos! Thanks, Serguei On 8/30/20 21:18, David Holmes wrote: > Hi Igor, > > Update looks good. > > Thanks, > David > > On 29/08/2020 4:18 am, Igor Ignatyev wrote: >> Hi David, >> >> good point, parseArguments (or rather checkOption) does indeed >> validate that passed option is valid and has a valid value, yet for >> many options all values are treated as valid, so ill-formed command >> lines like? `-debugee.vmkeys="${test.vm.opts} ${test.java.opts} >> -transport.address=dynamic` won't be spotted by ArgumentParser and >> its sub-classes, and I'm afraid in some cases might change tests' >> behavior unnoticeably. thus I've decided to add the check that we >> always have even number of double quotes: >> >>> diff -r 83f273f313aa >>> test/hotspot/jtreg/vmTestbase/nsk/share/ArgumentParser.java >>> --- a/test/hotspot/jtreg/vmTestbase/nsk/share/ArgumentParser.java >>> Thu Aug 27 19:37:51 2020 -0700 >>> +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/ArgumentParser.java >>> Fri Aug 28 11:16:24 2020 -0700 >>> @@ -156,6 +156,10 @@ >>> ????????????????? arg.append(" ").append(args[++i]); >>> ????????????????? doubleQuotes += numberOfDoubleQuotes(args[i]); >>> ????????????? } >>> +??????????? if (doubleQuotes % 2 != 0) { >>> +??????????????? throw new TestBug("command-line has odd number of >>> double quotes:" + String.join(" ", args)); >>> +??????????? } >>> + >>> ????????????? list.add(arg.toString()); >>> ????????? } >>> ????????? setRawArguments(list.toArray(String[]::new)); >> >> >> Thanks, >> -- Igor >> >> >>> On Aug 27, 2020, at 9:09 PM, David Holmes >>> wrote: >>> >>> Hi Igor, >>> >>> In case there may be a parsing error and the command-line is >>> ill-formed, should you abort if you reach the end of the arg list >>> without finding an even number of double-quotes? Or will >>> parseArguments already handle that? >>> >>> Otherwise the changes seem good. >>> >>> Thanks, >>> David >>> ----- >>> >>> On 28/08/2020 12:39 pm, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8252477/webrev.00/ >>>>> 99 lines changed: 19 ins; 20 del; 60 mod; >>>> Hi all, >>>> could you please review the patch which unblocks the rest of >>>> 8219140's (get rid of vmTestbase/PropertyResolvingWrapper) sub-tasks? >>>> background from JBS: >>>>> jtreg splits command line by space to get the list of arguments >>>>> and there is no way to prevent that (nor thru escaping, nor by >>>>> adding quotes). currently, PropertyResolvingWrapper handles that >>>>> and joins multiple arguments within double quotes into one >>>>> argument before passing it to the actual test class. the only >>>>> place where it's needed is in the tests which use >>>>> nsk/share/ArgumentParser (or more precisely >>>>> nsk.share.jpda.DebugeeArgumentHandler and >>>>> nsk/share/jdb/JdbArgumentHandler). >>>>> >>>>> in preparation for PropertyResolvingWrapper removal, >>>>> ArgumentParser should be updated to handle the "split" argument on >>>>> its own. >>>> I've also taken the liberty to slightly clean up ArgumentParser. >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8252477 >>>> webrev: http://cr.openjdk.java.net/~iignatyev//8252477/webrev.00/ >>>> testing: all the tests which use ArgumentParser >>>> (:vmTestbase_nsk_aod :vmTestbase_nsk_jdb :vmTestbase_nsk_jdi >>>> :vmTestbase_nsk_jdw ,:vmTestbase_nsk_jvmti :vmTestbase_vm_compiler >>>> :vmTestbase_vm_mlvm) on {windows,linux,macos}-x64 >>>> Thanks, >>>> -- Igor >> From eric.c.liu at arm.com Tue Sep 1 08:15:26 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Tue, 1 Sep 2020 08:15:26 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: Message-ID: Hi all, Please review this simple change to fix some compile warnings. The newer gcc (gcc-8 or higher) would warn for calls to bounded string manipulation functions such as 'strncpy' that may either truncate the copied string or leave the destination unchanged. This patch fixed stringop-truncation warnings reported by gcc, some of them only appear when compiled with "--enable-asan". [TESTS] Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. No new failure found. http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8252407 Thanks, Eric From serguei.spitsyn at oracle.com Tue Sep 1 08:39:44 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 1 Sep 2020 01:39:44 -0700 Subject: RFR(T) : 8252532 : use Utils.TEST_NATIVE_PATH instead of System.getProperty("test.nativepath") In-Reply-To: <93076ed6-f112-dd27-15d3-13f67cdf5de0@oracle.com> References: <93076ed6-f112-dd27-15d3-13f67cdf5de0@oracle.com> Message-ID: <226c299e-4661-1388-5382-daeca3780475@oracle.com> Hi Igor, This looks fine to me too. I also agree with David's suggestions. Thanks, Serguei On 8/30/20 21:53, David Holmes wrote: > Hi Igor, > > On 29/08/2020 1:52 pm, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8252532/webrev.00 >>> 145 lines changed: 28 ins; 22 del; 95 mod; >> >> >> Hi all, >> >> could you please review this trivial clean up which replaces >> System.getProperty("test.nativepath") w/ Utils.TEST_NATIVE_PATH where >> appropriate? >> >> while updating these files, I've also cleaned them up a bit, removed >> unneeded imports, added/removed spaces, etc >> >> testing: runtime, serviceability and vmTestbase/nsk/jvmti/ tests on >> {linux,windows,macos}-x64 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8252532 >> webrev: http://cr.openjdk.java.net/~iignatyev//8252532/webrev.00 > > Generally seems fine (though the fact the patch file contained a > series of changesets threw me initially!) > > test/hotspot/jtreg/runtime/signal/SigTestDriver.java > > ???????? // add test specific arguments w/o signame > ???????? cmd.addAll(Arrays.asList(args) > -???????????????????????? .subList(1, args.length)); > +??????????????? .subList(1, args.length)); > > Your changed line doesn't have the right indent. Can this just be put > on one line anyway: > > ???????? // add test specific arguments w/o signame > ???????? cmd.addAll(Arrays.asList(args).subList(1, args.length)); > > that seems better to me as the fact there is only one argument seems > clearer. Though for greater clarity perhaps: > > ???????? // add test specific arguments w/o signame > ???????? var argList = Arrays.asList(args).subList(1, args.length); > ???????? cmd.addAll(argList); > > -- > > +??????????????? Arrays.stream(Utils.JAVA_OPTIONS.split(" "))) > +??????????????? .filter(s -> !s.isEmpty()) > +??????????????? .filter(s -> s.startsWith("-X")) > +??????????????? .flatMap(arg -> Stream.of("-vmopt", arg)) > +??????????????? .collect(Collectors.toList()); > > The preferred/common style for chained stream operations is to align > the dots: > > ????????? Arrays.stream(Utils.JAVA_OPTIONS.split(" "))) > ??????????????? .filter(s -> !s.isEmpty()) > ??????????????? .filter(s -> s.startsWith("-X")) > ??????????????? .flatMap(arg -> Stream.of("-vmopt", arg)) > ??????????????? .collect(Collectors.toList()); > > --- > > test/lib/jdk/test/lib/process/ProcessTools.java > > -??????? System.out.println("\t" +? t + > -?????????????????????????? " stack: (length = " + stack.length + ")"); > +??????? System.out.println("\t" + t + > +??????????????? " stack: (length = " + stack.length + ")"); > > The original code is more stylistically correct - when breaking > arguments across lines the indent should align with the start of the > arguments. > > Similarly here: > > +??????? return String.format("--- ProcessLog ---%n" + > +??????????????????????? "cmd: %s%n" + > +??????????????????????? "exitvalue: %s%n" + > +??????????????????????? "stderr: %s%n" + > +??????????????????????? "stdout: %s%n", > +??????????????? getCommandLine(pb), exitValue, stderr, stdout); > > should be: > > +??????? return String.format("--- ProcessLog ---%n" + > +???????????????????????????? "cmd: %s%n" + > +???????????????????????????? "exitvalue: %s%n" + > +???????????????????????????? "stderr: %s%n" + > +???????????????????????????? "stdout: %s%n", > +???????????????????????????? getCommandLine(pb), exitValue, stderr, > stdout); > > and here: > > +??????? String executable = Paths.get(Utils.TEST_NATIVE_PATH, > executableName) > +??????????????? .toAbsolutePath() > +??????????????? .toString(); > > indentation again. > > Thanks, > David > ----- > >> Thanks, >> -- Igor >> From serguei.spitsyn at oracle.com Tue Sep 1 08:48:22 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 1 Sep 2020 01:48:22 -0700 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: Message-ID: Hi Eric, It looks good to me. Thank you for taking care about it. Thanks, Serguei On 9/1/20 01:15, Eric Liu wrote: > Hi all, > > Please review this simple change to fix some compile warnings. > > The newer gcc (gcc-8 or higher) would warn for calls to bounded string > manipulation functions such as 'strncpy' that may either truncate the > copied string or leave the destination unchanged. > > This patch fixed stringop-truncation warnings reported by gcc, some of > them only appear when compiled with "--enable-asan". > > [TESTS] > Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. > No new failure found. > > http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8252407 > > Thanks, > Eric From kim.barrett at oracle.com Tue Sep 1 08:55:31 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 Sep 2020 04:55:31 -0400 Subject: RFR: 8251274: Provide utility types for function SFINAE using extra template parameters In-Reply-To: References: <9230593a-1974-9d01-7768-71215ae61c34@oracle.com> <288D2756-60CC-4B14-8464-71FCAA2463A0@oracle.com> <44CD3A2D-F61F-4863-84B9-643F0C51483B@oracle.com> <3C3225BF-3D6C-447A-86A4-EE35315862F0@oracle.com> <295ec966-34d4-879c-55e9-eb9cd3b4ba15@oracle.com> <1D99E9B0-CAA8-4DB2-9862-78F51C705BC8@oracle.com> <9967005c-efef-b4bc-1b3c-64ae5cb6746e@oracle.com> Message-ID: > On Aug 31, 2020, at 9:43 AM, Kim Barrett wrote: > >> On Aug 31, 2020, at 5:38 AM, Erik ?sterlund wrote: >> >> Hi Kim, >> >> Looks good. > > Thanks > >> >> Thanks, >> /Erik >> >> On 2020-08-31 11:18, Kim Barrett wrote: >>> [?] OK. Then here?s a new webrev. (The gtest file has no changes now, but still shows up in the >>> webrev because of the change then revert in the patch series.) Just a full, since there seems >>> little point in an incremental. >>> >>> https://cr.openjdk.java.net/~kbarrett/8251274/open.01/ Given the changes we?ve discussed, the summary for the bug should probably be changed from ?utility types? to ?utility macro?. From david.holmes at oracle.com Tue Sep 1 08:57:01 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Sep 2020 18:57:01 +1000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: Message-ID: Hi Eric, On 1/09/2020 6:15 pm, Eric Liu wrote: > Hi all, > > Please review this simple change to fix some compile warnings. > > The newer gcc (gcc-8 or higher) would warn for calls to bounded string > manipulation functions such as 'strncpy' that may either truncate the > copied string or leave the destination unchanged. > > This patch fixed stringop-truncation warnings reported by gcc, some of > them only appear when compiled with "--enable-asan". We already build with gcc 9.2 and don't see any issues with shared code compiling for hotspot - which of these require --enable-asan? It certainly looks like an unnecessary warning - the whole point of strncpy is to truncate at a safe length. :( Have you tested this by building on other platforms? I'm not sure if all compilers will ignore these gcc specific pragmas. Thanks, David > [TESTS] > Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. > No new failure found. > > http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8252407 > > Thanks, > Eric From thomas.schatzl at oracle.com Tue Sep 1 08:57:38 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 1 Sep 2020 10:57:38 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: Message-ID: Hi, On 01.09.20 10:48, serguei.spitsyn at oracle.com wrote: > Hi Eric, > > It looks good to me. > Thank you for taking care about it. > > Thanks, > Serguei > > > On 9/1/20 01:15, Eric Liu wrote: >> Hi all, >> >> Please review this simple change to fix some compile warnings. >> >> The newer gcc (gcc-8 or higher) would warn for calls to bounded string >> manipulation functions such as 'strncpy' that may either truncate the >> copied string or leave the destination unchanged. >> >> This patch fixed stringop-truncation warnings reported by gcc, some of >> them only appear when compiled with "--enable-asan". >> >> [TESTS] >> Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. >> No new failure found. >> >> http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8252407 >> Looks good. Maybe the comment in compileBroker.hpp could be improved by specifying a gcc version and/or gcc bug number (not sure if done elsewhere too) - so that it can be verified/removed at some point. 66 // This code can incorrectly cause a "stringop-truncation" warning with gcc Or, alternatively by specifying a type in the enum (we are on c++14 now...), the cast to size_t and could go away and with it the error? (If it is the cause of the gcc error). Thanks, Thomas From daniel.fuchs at oracle.com Tue Sep 1 09:18:26 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 1 Sep 2020 10:18:26 +0100 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: Message-ID: <3cab30a7-0b1e-15ef-9237-4083fe271a4c@oracle.com> Hi Eric, The changes to NetworkInterface.c look good to me. best regards, -- daniel On 01/09/2020 09:01, Eric Liu wrote: > Hi all, > > Please review this simple change to fix some compile warnings. > > The newer gcc (gcc-8 or higher) would warn for calls to bounded string > manipulation functions such as 'strncpy' that may either truncate the > copied string or leave the destination unchanged. > > This patch fixed stringop-truncation warnings reported by gcc, some of > them only appear when compiled with "--enable-asan". > > [TESTS] > Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. > No new failure found. > > http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8252407 > > Thanks, > Eric > From kim.barrett at oracle.com Tue Sep 1 09:19:55 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 Sep 2020 05:19:55 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: Message-ID: <0AAF2B52-CC30-4F9A-955C-69C6F1204ABC@oracle.com> > On Sep 1, 2020, at 4:57 AM, David Holmes wrote: > > Hi Eric, > > On 1/09/2020 6:15 pm, Eric Liu wrote: >> Hi all, >> Please review this simple change to fix some compile warnings. >> The newer gcc (gcc-8 or higher) would warn for calls to bounded string >> manipulation functions such as 'strncpy' that may either truncate the >> copied string or leave the destination unchanged. >> This patch fixed stringop-truncation warnings reported by gcc, some of >> them only appear when compiled with "--enable-asan?. Not a review, just responding to David?s comments. > We already build with gcc 9.2 and don't see any issues with shared code compiling for hotspot - which of these require --enable-asan? It certainly looks like an unnecessary warning - the whole point of strncpy is to truncate at a safe length. :( -Wstringop-truncation seems to be somewhat buggy, esp. older versions of it, generating many false positives (as well as false negatives). But we?ve been reluctant to just turn it off, because it has actually found real bugs in our code. > Have you tested this by building on other platforms? I'm not sure if all compilers will ignore these gcc specific pragmas. The pragma macros are defined appropriately for use in shared code. From kim.barrett at oracle.com Tue Sep 1 09:27:20 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 Sep 2020 05:27:20 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: Message-ID: <94A9F918-D982-4D31-BD4E-9DEE3BD0E08A@oracle.com> > On Sep 1, 2020, at 4:57 AM, Thomas Schatzl wrote: > > Hi, > > On 01.09.20 10:48, serguei.spitsyn at oracle.com wrote: >> Hi Eric, >> It looks good to me. >> Thank you for taking care about it. >> Thanks, >> Serguei >> On 9/1/20 01:15, Eric Liu wrote: >>> Hi all, >>> >>> Please review this simple change to fix some compile warnings. >>> >>> The newer gcc (gcc-8 or higher) would warn for calls to bounded string >>> manipulation functions such as 'strncpy' that may either truncate the >>> copied string or leave the destination unchanged. >>> >>> This patch fixed stringop-truncation warnings reported by gcc, some of >>> them only appear when compiled with "--enable-asan". >>> >>> [TESTS] >>> Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. >>> No new failure found. >>> >>> http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8252407 >>> > > Looks good. > > Maybe the comment in compileBroker.hpp could be improved by specifying a gcc version and/or gcc bug number (not sure if done elsewhere too) - so that it can be verified/removed at some point. > > 66 // This code can incorrectly cause a "stringop-truncation" warning with gcc We don?t really know what gcc versions are relevant, and there?s a whole pile of gcc bugs for -Wstringop-truncation (currently 22 open bugs). Figuring out which one or ones it is doesn?t seem like a good use of time. > > Or, alternatively by specifying a type in the enum (we are on c++14 now...), the cast to size_t and could go away and with it the error? (If it is the cause of the gcc error). Or don?t use an enum, but change it to an appropriately typed static constant. I don?t know if the cast has anything to do with -Wstringop-truncation being confused, but as I had the same thought, that seems worth a try. From thomas.schatzl at oracle.com Tue Sep 1 09:33:28 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 1 Sep 2020 11:33:28 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <94A9F918-D982-4D31-BD4E-9DEE3BD0E08A@oracle.com> References: <94A9F918-D982-4D31-BD4E-9DEE3BD0E08A@oracle.com> Message-ID: Hi, On 01.09.20 11:27, Kim Barrett wrote: >> On Sep 1, 2020, at 4:57 AM, Thomas Schatzl wrote: >> >> Hi, >> >> On 01.09.20 10:48, serguei.spitsyn at oracle.com wrote: >>> Hi Eric, >>> It looks good to me. >>> Thank you for taking care about it. >>> Thanks, >>> Serguei >>> On 9/1/20 01:15, Eric Liu wrote: >>>> Hi all, >>>> >>>> Please review this simple change to fix some compile warnings. >>>> >>>> The newer gcc (gcc-8 or higher) would warn for calls to bounded string >>>> manipulation functions such as 'strncpy' that may either truncate the >>>> copied string or leave the destination unchanged. >>>> >>>> This patch fixed stringop-truncation warnings reported by gcc, some of >>>> them only appear when compiled with "--enable-asan". >>>> >>>> [TESTS] >>>> Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. >>>> No new failure found. >>>> >>>> http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8252407 >>>> >> >> Looks good. >> >> Maybe the comment in compileBroker.hpp could be improved by specifying a gcc version and/or gcc bug number (not sure if done elsewhere too) - so that it can be verified/removed at some point. >> >> 66 // This code can incorrectly cause a "stringop-truncation" warning with gcc > > We don?t really know what gcc versions are relevant, and there?s a whole pile of > gcc bugs for -Wstringop-truncation (currently 22 open bugs). Figuring out which > one or ones it is doesn?t seem like a good use of time. Okay, fine. > >> >> Or, alternatively by specifying a type in the enum (we are on c++14 now...), the cast to size_t and could go away and with it the error? (If it is the cause of the gcc error). > > Or don?t use an enum, but change it to an appropriately typed static constant. > I don?t know if the cast has anything to do with -Wstringop-truncation being confused, but > as I had the same thought, that seems worth a try. > +1. In any case using a typed static constant is better than the single enum value, even if it does not fix the problem. Thanks, Thomas From kim.barrett at oracle.com Tue Sep 1 09:46:26 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 Sep 2020 05:46:26 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: Message-ID: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> > On Sep 1, 2020, at 4:01 AM, Eric Liu wrote: > > Hi all, > > Please review this simple change to fix some compile warnings. > > The newer gcc (gcc-8 or higher) would warn for calls to bounded string > manipulation functions such as 'strncpy' that may either truncate the > copied string or leave the destination unchanged. > > This patch fixed stringop-truncation warnings reported by gcc, some of > them only appear when compiled with "--enable-asan". > > [TESTS] > Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. > No new failure found. > > http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8252407 > > Thanks, > Eric I really hate -Wstringop-truncation. It's been a constant source of churn for us ever since it appeared. The changes being made to getIndex and getFlags (NetworkInterface.c) are modifying lines that were changed very recently to deal with such warnings from gcc10. I'm worried that these new changes will re-trigger warnings from gcc10 (though this change isn't a revert; the gcc10 warning was justifiable). I think it should be okay, but there?s some risk here. Changes look good, subject to that caveat. I think these changes conform better to the documented description of the warning than did the recent NetworkInterface.c change mentioned above, so I?m hopeful that we?re not in a warning cycle here. But it would be good to have someone test these changes against gcc10.x. From kim.barrett at oracle.com Tue Sep 1 09:53:28 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 Sep 2020 05:53:28 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: <444A171B-076F-402C-A601-2C66203A1DE0@oracle.com> > On Sep 1, 2020, at 5:46 AM, Kim Barrett wrote: > >> On Sep 1, 2020, at 4:01 AM, Eric Liu wrote: >> >> Hi all, >> >> Please review this simple change to fix some compile warnings. >> >> The newer gcc (gcc-8 or higher) would warn for calls to bounded string >> manipulation functions such as 'strncpy' that may either truncate the >> copied string or leave the destination unchanged. >> >> This patch fixed stringop-truncation warnings reported by gcc, some of >> them only appear when compiled with "--enable-asan". >> >> [TESTS] >> Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. >> No new failure found. >> >> http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8252407 >> >> Thanks, >> Eric > > I really hate -Wstringop-truncation. It's been a constant source of churn > for us ever since it appeared. The changes being made to getIndex and > getFlags (NetworkInterface.c) are modifying lines that were changed very > recently to deal with such warnings from gcc10. I'm worried that these new > changes will re-trigger warnings from gcc10 (though this change isn't a > revert; the gcc10 warning was justifiable). I think it should be okay, but > there?s some risk here. > > Changes look good, subject to that caveat. Apparently I forgot about the discussion of the casted enum, so belay that. > I think these changes conform > better to the documented description of the warning than did the recent > NetworkInterface.c change mentioned above, so I?m hopeful that we?re not > in a warning cycle here. But it would be good to have someone test these > changes against gcc10.x. From erik.osterlund at oracle.com Tue Sep 1 10:55:07 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 1 Sep 2020 12:55:07 +0200 Subject: RFR: 8252627: Make it safe for JFR thread to read threadObj Message-ID: <1cf3a3ba-2417-261c-a085-dd2c7dd3e6a1@oracle.com> Hi, Since the thread oop moved to OopStorage, a bug was introduced. The oop is now read with load barriers. If the JFR thread shoots a signal at a thread that holds a load barrier lock, the target thread is stuck holding that lock. Then the JFR thread tries to read the threadObj(), which might grab the same lock. This causes a deadlock. There are also some ZGC asserts that fire, not expecting relocation to happen from an unknown non-Java thread. I had fixes for said problems in my own concurrent stack scanning branch, but forgot to point it out in the review thread for JDK-8244997. My solution is to read the threadObj before the target thread is shot down, and simply pass in the already sampled thread oop to the context where the events are created. All of this is done with the Threads_lock taken (today) to lock out safepoints from destroying the oop. Webrev: http://cr.openjdk.java.net/~eosterlund/8252627/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8252627 Thanks, /Erik From aleksei.voitylov at bell-sw.com Tue Sep 1 11:41:52 2020 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Tue, 1 Sep 2020 14:41:52 +0300 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port Message-ID: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> Hi, JEP 386 is now Candidate [1] and as we resolved all outstanding issues within the Portola project I'd like to ask for comments from HotSpot, Core Libs (changes in libjli/java_md.c), and Build groups before moving the JEP to Proposed to Target: http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ Testing: JTReg, VM TestBase on all platforms (Linux x86_64, Linux x86, Linux Arm, Linux AArch64, Linux PPC, Windows x86_64, Windows x86, Mac) with no regressions. A downport of these changes to 14 passes JCK 14 on these platforms. The port was tested on Alpine Linux 3.8 and 3.11 with JTReg, VM TestBase. There are no differences with Linux x86_64? with the exception of SA which is not supported as per the JEP. A downport of these changes to 14 passes JCK 14 on Alpine Linux. Thanks, -Aleksei [1] https://bugs.openjdk.java.net/browse/JDK-8229469 From daniel.fuchs at oracle.com Tue Sep 1 11:59:17 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 1 Sep 2020 12:59:17 +0100 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: Hi Eric, Kim, On 01/09/2020 10:46, Kim Barrett wrote: > he changes being made to getIndex and > getFlags (NetworkInterface.c) are modifying lines that were changed very > recently to deal with such warnings from gcc10. I'm worried that these new > changes will re-trigger warnings from gcc10 (though this change isn't a > revert; the gcc10 warning was justifiable). I think it should be okay, but > there?s some risk here. Thanks for reminding me of these changes. Indeed, the changes proposed to NetworkInteface.c - though not incorrect - may well re-trigger this gcc10 warning [1]. So now I don't think this should go through unless it's verified that it doesn't cause further issues down the road. [1] https://bugs.openjdk.java.net/browse/JDK-8250863 best regards, -- daniel From sgehwolf at redhat.com Tue Sep 1 12:23:32 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Sep 2020 14:23:32 +0200 Subject: [8u] RFR: 8244225: stringop-overflow warning on strncpy call from compile_the_world_in Message-ID: Hi, Could I please get a review of this 8u backport? The JDK 11u patch doesn't apply cleanly since string_ends_with() function isn't in 8u. Therefore, the context is different enough for the patch to not apply cleanly. This is in a NOT_PRODUCT() path of the VM and should be low risk. I'm proposing this for review for JDK 8u parity. Bug: https://bugs.openjdk.java.net/browse/JDK-8244225 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244225/01/webrev/ Testing: Manual on a fastdebug build of the JVM. Compiling classLoader.o with -Wstringop-overflow. Warning present before the fix and it's gone after. Thoughts? I'm not sure if this is worth the churn of doing the backport, though. Thanks, Severin From shade at redhat.com Tue Sep 1 12:28:28 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 1 Sep 2020 14:28:28 +0200 Subject: [8u] RFR: 8244225: stringop-overflow warning on strncpy call from compile_the_world_in In-Reply-To: References: Message-ID: <6c991ccd-fbcb-b84d-ff58-92eaa9023756@redhat.com> On 9/1/20 2:23 PM, Severin Gehwolf wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8244225 > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244225/01/webrev/ 8u backport looks fine. > Thoughts? I'm not sure if this is worth the churn of doing the > backport, though. I'd prefer to fix warnings in non-risky places, because they obscure the warnings in other critical places. -- Thanks, -Aleksey From erik.joelsson at oracle.com Tue Sep 1 12:47:42 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 1 Sep 2020 05:47:42 -0700 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> Message-ID: Build changes look ok. /Erik On 2020-09-01 04:41, Aleksei Voitylov wrote: > Hi, > > JEP 386 is now Candidate [1] and as we resolved all outstanding issues > within the Portola project I'd like to ask for comments from HotSpot, > Core Libs (changes in libjli/java_md.c), and Build groups before moving > the JEP to Proposed to Target: > > http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ > > Testing: > > JTReg, VM TestBase on all platforms (Linux x86_64, Linux x86, Linux Arm, > Linux AArch64, Linux PPC, Windows x86_64, Windows x86, Mac) with no > regressions. A downport of these changes to 14 passes JCK 14 on these > platforms. > > The port was tested on Alpine Linux 3.8 and 3.11 with JTReg, VM > TestBase. There are no differences with Linux x86_64? with the exception > of SA which is not supported as per the JEP. A downport of these changes > to 14 passes JCK 14 on Alpine Linux. > > Thanks, > > -Aleksei > > [1] https://bugs.openjdk.java.net/browse/JDK-8229469 > > From stefan.karlsson at oracle.com Tue Sep 1 13:13:08 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 1 Sep 2020 15:13:08 +0200 Subject: RFR: 8252656: Replace RegisterArrayForGC mechanism with plain Handles Message-ID: <2630e73c-878d-fd0f-1eb4-c5fb2f341b43@oracle.com> Hi all, Please review this patch to replace the RegisterArrayForGC mechanism with the usage of plain Handles. https://cr.openjdk.java.net/~stefank/8252656/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8252656 JVM_GetStackAccessControlContext collects a bunch of oops in array and then calls into allocating code that might safepoint. To deal with this, the local array is registered and explicitly visited by the GCs. This patch gets rid of this and use an array of Handles instead. I've tested this locally with test TEST="test/jdk/java/security". Any other suggestions on what to test this with? I've also run this through tier1, as a sanity check. Thanks, StefanK From magnus.ihse.bursie at oracle.com Tue Sep 1 13:21:30 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 1 Sep 2020 15:21:30 +0200 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> Message-ID: On 2020-09-01 13:41, Aleksei Voitylov wrote: > Hi, > > JEP 386 is now Candidate [1] and as we resolved all outstanding issues > within the Portola project I'd like to ask for comments from HotSpot, > Core Libs (changes in libjli/java_md.c), and Build groups before moving > the JEP to Proposed to Target: > > http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ Looks good to me. /Magnus > > Testing: > > JTReg, VM TestBase on all platforms (Linux x86_64, Linux x86, Linux Arm, > Linux AArch64, Linux PPC, Windows x86_64, Windows x86, Mac) with no > regressions. A downport of these changes to 14 passes JCK 14 on these > platforms. > > The port was tested on Alpine Linux 3.8 and 3.11 with JTReg, VM > TestBase. There are no differences with Linux x86_64? with the exception > of SA which is not supported as per the JEP. A downport of these changes > to 14 passes JCK 14 on Alpine Linux. > > Thanks, > > -Aleksei > > [1] https://bugs.openjdk.java.net/browse/JDK-8229469 > > From sgehwolf at redhat.com Tue Sep 1 13:39:10 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Sep 2020 15:39:10 +0200 Subject: [8u] RFR: 8244225: stringop-overflow warning on strncpy call from compile_the_world_in In-Reply-To: <6c991ccd-fbcb-b84d-ff58-92eaa9023756@redhat.com> References: <6c991ccd-fbcb-b84d-ff58-92eaa9023756@redhat.com> Message-ID: <21ec77909064538f5393b65de1ec049fa10c4ba4.camel@redhat.com> On Tue, 2020-09-01 at 14:28 +0200, Aleksey Shipilev wrote: > On 9/1/20 2:23 PM, Severin Gehwolf wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244225 > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244225/01/webrev/ > > 8u backport looks fine. Thanks for the review! Cheers, Severin From coleen.phillimore at oracle.com Tue Sep 1 13:41:45 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 1 Sep 2020 09:41:45 -0400 Subject: RFR: 8252656: Replace RegisterArrayForGC mechanism with plain Handles In-Reply-To: <2630e73c-878d-fd0f-1eb4-c5fb2f341b43@oracle.com> References: <2630e73c-878d-fd0f-1eb4-c5fb2f341b43@oracle.com> Message-ID: <65fd8496-f9db-f348-efa7-b91e1665846a@oracle.com> Looks good to me!? I don't see further need for testing as this as this code path is executed for almost everything. Coleen On 9/1/20 9:13 AM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to replace the RegisterArrayForGC mechanism > with the usage of plain Handles. > > https://cr.openjdk.java.net/~stefank/8252656/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8252656 > > JVM_GetStackAccessControlContext collects a bunch of oops in array and > then calls into allocating code that might safepoint. To deal with > this, the local array is registered and explicitly visited by the GCs. > This patch gets rid of this and use an array of Handles instead. > > I've tested this locally with test TEST="test/jdk/java/security". Any > other suggestions on what to test this with? I've also run this > through tier1, as a sanity check. > > Thanks, > StefanK From stefan.karlsson at oracle.com Tue Sep 1 13:45:32 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 1 Sep 2020 15:45:32 +0200 Subject: RFR: 8252656: Replace RegisterArrayForGC mechanism with plain Handles In-Reply-To: <65fd8496-f9db-f348-efa7-b91e1665846a@oracle.com> References: <2630e73c-878d-fd0f-1eb4-c5fb2f341b43@oracle.com> <65fd8496-f9db-f348-efa7-b91e1665846a@oracle.com> Message-ID: <6fd80239-7a76-ecf1-281f-c5410214e786@oracle.com> Thanks, Coleen. StefanK On 2020-09-01 15:41, Coleen Phillimore wrote: > Looks good to me!? I don't see further need for testing as this as this > code path is executed for almost everything. > Coleen > > On 9/1/20 9:13 AM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to replace the RegisterArrayForGC mechanism >> with the usage of plain Handles. >> >> https://cr.openjdk.java.net/~stefank/8252656/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8252656 >> >> JVM_GetStackAccessControlContext collects a bunch of oops in array and >> then calls into allocating code that might safepoint. To deal with >> this, the local array is registered and explicitly visited by the GCs. >> This patch gets rid of this and use an array of Handles instead. >> >> I've tested this locally with test TEST="test/jdk/java/security". Any >> other suggestions on what to test this with? I've also run this >> through tier1, as a sanity check. >> >> Thanks, >> StefanK > From eric.c.liu at arm.com Tue Sep 1 13:59:32 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Tue, 1 Sep 2020 13:59:32 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com>, Message-ID: Hi Daniel, Kim, Thanks for your review. > Kim Barrett on Tue Sep 1 09:46:26 UTC 2020 > > Changes look good, subject to that caveat. I think these changes conform > better to the documented description of the warning than did the recent > NetworkInterface.c change mentioned above, so I?m hopeful that we?re not > in a warning cycle here. But it would be good to have someone test these > changes against gcc10.x. I just tested this patch by GCC (10.1.0) and it would really re-trigger those warnings :( I have not noticed the history before, but it's really hard to imagine that GCC would have different behaviors. >Daniel Fuchs on Tue Sep 1 11:59:17 UTC 2020 > > Thanks for reminding me of these changes. > Indeed, the changes proposed to NetworkInteface.c - though > not incorrect - may well re-trigger this gcc10 warning [1]. > So now I don't think this should go through unless it's verified > that it doesn't cause further issues down the road. Do you think it's a good idea to suppress those warnings by pragma? As we already know the code are actually correct, and that would make GCC happy both for 9 and 10. Thanks, Eric From thomas.schatzl at oracle.com Tue Sep 1 15:01:35 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 1 Sep 2020 17:01:35 +0200 Subject: RFR: 8252656: Replace RegisterArrayForGC mechanism with plain Handles In-Reply-To: <2630e73c-878d-fd0f-1eb4-c5fb2f341b43@oracle.com> References: <2630e73c-878d-fd0f-1eb4-c5fb2f341b43@oracle.com> Message-ID: <5eeea8f5-62cc-316d-075d-1a2c4277eeab@oracle.com> Hi, On 01.09.20 15:13, Stefan Karlsson wrote: > Hi all, > > Please review this patch to replace the RegisterArrayForGC mechanism > with the usage of plain Handles. > > https://cr.openjdk.java.net/~stefank/8252656/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8252656 > > JVM_GetStackAccessControlContext collects a bunch of oops in array and > then calls into allocating code that might safepoint. To deal with this, > the local array is registered and explicitly visited by the GCs. This > patch gets rid of this and use an array of Handles instead. > > I've tested this locally with test TEST="test/jdk/java/security". Any > other suggestions on what to test this with? I've also run this through > tier1, as a sanity check. > > Thanks, > StefanK lgtm. Thomas From lois.foltan at oracle.com Tue Sep 1 17:26:22 2020 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 1 Sep 2020 13:26:22 -0400 Subject: RFR: 8251274: Provide utility types for function SFINAE using extra template parameters In-Reply-To: References: <9230593a-1974-9d01-7768-71215ae61c34@oracle.com> <288D2756-60CC-4B14-8464-71FCAA2463A0@oracle.com> <44CD3A2D-F61F-4863-84B9-643F0C51483B@oracle.com> <3C3225BF-3D6C-447A-86A4-EE35315862F0@oracle.com> <295ec966-34d4-879c-55e9-eb9cd3b4ba15@oracle.com> <1D99E9B0-CAA8-4DB2-9862-78F51C705BC8@oracle.com> <9967005c-efef-b4bc-1b3c-64ae5cb6746e@oracle.com> Message-ID: <394e5299-5fcc-a53b-a06e-082c13808e8a@oracle.com> On 9/1/2020 4:55 AM, Kim Barrett wrote: >> On Aug 31, 2020, at 9:43 AM, Kim Barrett wrote: >> >>> On Aug 31, 2020, at 5:38 AM, Erik ?sterlund wrote: >>> >>> Hi Kim, >>> >>> Looks good. >> Thanks >> >>> Thanks, >>> /Erik >>> >>> On 2020-08-31 11:18, Kim Barrett wrote: >>>> [?] OK. Then here?s a new webrev. (The gtest file has no changes now, but still shows up in the >>>> webrev because of the change then revert in the patch series.) Just a full, since there seems >>>> little point in an incremental. >>>> >>>> https://cr.openjdk.java.net/~kbarrett/8251274/open.01/ > Given the changes we?ve discussed, the summary for the bug should probably be changed from > ?utility types? to ?utility macro?. > Hi Kim, This looks good.? After reading through the discussion with Erik, I am glad about the resulting ENABLE_IF macro.? I do have one question/comment which might just be for my clarification.? I am assuming I can also still use this new C++11? extra anonymous non-type template parameter with a default value as the return type?? In addition, if I am allowed to use this as the return type, I further assume that it is also allowed to use a single template parameter that is a conjunction of expressions for the return type too? Thanks, Lois From igor.ignatyev at oracle.com Tue Sep 1 19:29:25 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 1 Sep 2020 12:29:25 -0700 Subject: RFR(S) : 8252477 : nsk/share/ArgumentParser should expect that jtreg "splits" an argument In-Reply-To: References: <26E3A312-A45E-489F-A5B1-F1E67CBE807A@oracle.com> <848EB368-B244-4376-91D0-770FF0141477@oracle.com> Message-ID: Serguei, David, thanks for your reviews, pushed. -- Igor > On Sep 1, 2020, at 1:09 AM, serguei.spitsyn at oracle.com wrote: > > Hi Igor, > > LGTM++ > It is a nice clean. Surprisingly, this code had a lot of typos! > > Thanks, > Serguei > > > On 8/30/20 21:18, David Holmes wrote: >> Hi Igor, >> >> Update looks good. >> >> Thanks, >> David >> >> On 29/08/2020 4:18 am, Igor Ignatyev wrote: >>> Hi David, >>> >>> good point, parseArguments (or rather checkOption) does indeed validate that passed option is valid and has a valid value, yet for many options all values are treated as valid, so ill-formed command lines like `-debugee.vmkeys="${test.vm.opts} ${test.java.opts} -transport.address=dynamic` won't be spotted by ArgumentParser and its sub-classes, and I'm afraid in some cases might change tests' behavior unnoticeably. thus I've decided to add the check that we always have even number of double quotes: >>> >>>> diff -r 83f273f313aa test/hotspot/jtreg/vmTestbase/nsk/share/ArgumentParser.java >>>> --- a/test/hotspot/jtreg/vmTestbase/nsk/share/ArgumentParser.java Thu Aug 27 19:37:51 2020 -0700 >>>> +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/ArgumentParser.java Fri Aug 28 11:16:24 2020 -0700 >>>> @@ -156,6 +156,10 @@ >>>> arg.append(" ").append(args[++i]); >>>> doubleQuotes += numberOfDoubleQuotes(args[i]); >>>> } >>>> + if (doubleQuotes % 2 != 0) { >>>> + throw new TestBug("command-line has odd number of double quotes:" + String.join(" ", args)); >>>> + } >>>> + >>>> list.add(arg.toString()); >>>> } >>>> setRawArguments(list.toArray(String[]::new)); >>> >>> >>> Thanks, >>> -- Igor >>> >>> >>>> On Aug 27, 2020, at 9:09 PM, David Holmes wrote: >>>> >>>> Hi Igor, >>>> >>>> In case there may be a parsing error and the command-line is ill-formed, should you abort if you reach the end of the arg list without finding an even number of double-quotes? Or will parseArguments already handle that? >>>> >>>> Otherwise the changes seem good. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> On 28/08/2020 12:39 pm, Igor Ignatyev wrote: >>>>> http://cr.openjdk.java.net/~iignatyev//8252477/webrev.00/ >>>>>> 99 lines changed: 19 ins; 20 del; 60 mod; >>>>> Hi all, >>>>> could you please review the patch which unblocks the rest of 8219140's (get rid of vmTestbase/PropertyResolvingWrapper) sub-tasks? >>>>> background from JBS: >>>>>> jtreg splits command line by space to get the list of arguments and there is no way to prevent that (nor thru escaping, nor by adding quotes). currently, PropertyResolvingWrapper handles that and joins multiple arguments within double quotes into one argument before passing it to the actual test class. the only place where it's needed is in the tests which use nsk/share/ArgumentParser (or more precisely nsk.share.jpda.DebugeeArgumentHandler and nsk/share/jdb/JdbArgumentHandler). >>>>>> >>>>>> in preparation for PropertyResolvingWrapper removal, ArgumentParser should be updated to handle the "split" argument on its own. >>>>> I've also taken the liberty to slightly clean up ArgumentParser. >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8252477 >>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8252477/webrev.00/ >>>>> testing: all the tests which use ArgumentParser (:vmTestbase_nsk_aod :vmTestbase_nsk_jdb :vmTestbase_nsk_jdi :vmTestbase_nsk_jdw ,:vmTestbase_nsk_jvmti :vmTestbase_vm_compiler :vmTestbase_vm_mlvm) on {windows,linux,macos}-x64 >>>>> Thanks, >>>>> -- Igor >>> > From igor.ignatyev at oracle.com Tue Sep 1 20:21:56 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 1 Sep 2020 13:21:56 -0700 Subject: RFR(T) : 8252532 : use Utils.TEST_NATIVE_PATH instead of System.getProperty("test.nativepath") In-Reply-To: <226c299e-4661-1388-5382-daeca3780475@oracle.com> References: <93076ed6-f112-dd27-15d3-13f67cdf5de0@oracle.com> <226c299e-4661-1388-5382-daeca3780475@oracle.com> Message-ID: <964517DC-D9E0-41AC-A838-0B1F89FC4191@oracle.com> Hi Serguei, David, thanks for your reviews, I've updated the patch to address David's comments: http://cr.openjdk.java.net/~iignatyev//8252532/webrev.01/ (whole) http://cr.openjdk.java.net/~iignatyev//8252532/webrev.0-1/ (incremental) Thanks, -- Igor > On Sep 1, 2020, at 1:39 AM, serguei.spitsyn at oracle.com wrote: > > Hi Igor, > > This looks fine to me too. > I also agree with David's suggestions. > > Thanks, > Serguei > > > On 8/30/20 21:53, David Holmes wrote: >> Hi Igor, >> >> On 29/08/2020 1:52 pm, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8252532/webrev.00 >>>> 145 lines changed: 28 ins; 22 del; 95 mod; >>> >>> >>> Hi all, >>> >>> could you please review this trivial clean up which replaces System.getProperty("test.nativepath") w/ Utils.TEST_NATIVE_PATH where appropriate? >>> >>> while updating these files, I've also cleaned them up a bit, removed unneeded imports, added/removed spaces, etc >>> >>> testing: runtime, serviceability and vmTestbase/nsk/jvmti/ tests on {linux,windows,macos}-x64 >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8252532 >>> webrev: http://cr.openjdk.java.net/~iignatyev//8252532/webrev.00 >> >> Generally seems fine (though the fact the patch file contained a series of changesets threw me initially!) >> >> test/hotspot/jtreg/runtime/signal/SigTestDriver.java >> >> // add test specific arguments w/o signame >> cmd.addAll(Arrays.asList(args) >> - .subList(1, args.length)); >> + .subList(1, args.length)); >> >> Your changed line doesn't have the right indent. Can this just be put on one line anyway: >> >> // add test specific arguments w/o signame >> cmd.addAll(Arrays.asList(args).subList(1, args.length)); >> >> that seems better to me as the fact there is only one argument seems clearer. Though for greater clarity perhaps: >> >> // add test specific arguments w/o signame >> var argList = Arrays.asList(args).subList(1, args.length); >> cmd.addAll(argList); >> agree >> -- >> >> + Arrays.stream(Utils.JAVA_OPTIONS.split(" "))) >> + .filter(s -> !s.isEmpty()) >> + .filter(s -> s.startsWith("-X")) >> + .flatMap(arg -> Stream.of("-vmopt", arg)) >> + .collect(Collectors.toList()); >> >> The preferred/common style for chained stream operations is to align the dots: >> >> Arrays.stream(Utils.JAVA_OPTIONS.split(" "))) >> .filter(s -> !s.isEmpty()) >> .filter(s -> s.startsWith("-X")) >> .flatMap(arg -> Stream.of("-vmopt", arg)) >> .collect(Collectors.toList()); >> `collect` is actually called on the result of `Stream.concat`, anyhow I've aligned the chained calls by dots. >> --- >> >> test/lib/jdk/test/lib/process/ProcessTools.java >> >> - System.out.println("\t" + t + >> - " stack: (length = " + stack.length + ")"); >> + System.out.println("\t" + t + >> + " stack: (length = " + stack.length + ")"); I've decided to put this on one line. >> >> The original code is more stylistically correct - when breaking arguments across lines the indent should align with the start of the arguments. >> >> Similarly here: >> >> + return String.format("--- ProcessLog ---%n" + >> + "cmd: %s%n" + >> + "exitvalue: %s%n" + >> + "stderr: %s%n" + >> + "stdout: %s%n", >> + getCommandLine(pb), exitValue, stderr, stdout); >> >> should be: >> >> + return String.format("--- ProcessLog ---%n" + >> + "cmd: %s%n" + >> + "exitvalue: %s%n" + >> + "stderr: %s%n" + >> + "stdout: %s%n", >> + getCommandLine(pb), exitValue, stderr, stdout); fixed >> >> and here: >> >> + String executable = Paths.get(Utils.TEST_NATIVE_PATH, executableName) >> + .toAbsolutePath() >> + .toString(); fixed >> >> indentation again. >> >> Thanks, >> David >> ----- >> >>> Thanks, >>> -- Igor >>> > From markus.gronlund at oracle.com Tue Sep 1 21:00:48 2020 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 1 Sep 2020 14:00:48 -0700 (PDT) Subject: RFR: 8252627: Make it safe for JFR thread to read threadObj In-Reply-To: <1cf3a3ba-2417-261c-a085-dd2c7dd3e6a1@oracle.com> References: <1cf3a3ba-2417-261c-a085-dd2c7dd3e6a1@oracle.com> Message-ID: Hi Erik, Looks good. Thanks Markus -----Original Message----- From: Erik ?sterlund Sent: den 1 september 2020 12:55 To: hotspot-dev Cc: Markus Gronlund ; Erik Gahlin Subject: RFR: 8252627: Make it safe for JFR thread to read threadObj Hi, Since the thread oop moved to OopStorage, a bug was introduced. The oop is now read with load barriers. If the JFR thread shoots a signal at a thread that holds a load barrier lock, the target thread is stuck holding that lock. Then the JFR thread tries to read the threadObj(), which might grab the same lock. This causes a deadlock. There are also some ZGC asserts that fire, not expecting relocation to happen from an unknown non-Java thread. I had fixes for said problems in my own concurrent stack scanning branch, but forgot to point it out in the review thread for JDK-8244997. My solution is to read the threadObj before the target thread is shot down, and simply pass in the already sampled thread oop to the context where the events are created. All of this is done with the Threads_lock taken (today) to lock out safepoints from destroying the oop. Webrev: http://cr.openjdk.java.net/~eosterlund/8252627/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8252627 Thanks, /Erik From erik.osterlund at oracle.com Tue Sep 1 21:06:46 2020 From: erik.osterlund at oracle.com (=?utf-8?Q?Erik_=C3=96sterlund?=) Date: Tue, 1 Sep 2020 23:06:46 +0200 Subject: RFR: 8252627: Make it safe for JFR thread to read threadObj In-Reply-To: References: Message-ID: <85F09ED9-0F45-42C5-B212-CF3A082C69E5@oracle.com> Hi Markus, Thanks for the review. /Erik > On 1 Sep 2020, at 23:00, Markus Gronlund wrote: > > ?Hi Erik, > > Looks good. > > Thanks > Markus > > -----Original Message----- > From: Erik ?sterlund > Sent: den 1 september 2020 12:55 > To: hotspot-dev > Cc: Markus Gronlund ; Erik Gahlin > Subject: RFR: 8252627: Make it safe for JFR thread to read threadObj > > Hi, > > Since the thread oop moved to OopStorage, a bug was introduced. The oop is now read with load barriers. > If the JFR thread shoots a signal at a thread that holds a load barrier lock, the target thread is stuck holding that lock. Then the JFR thread tries to read the threadObj(), which might grab the same lock. > This causes a deadlock. There are also some ZGC asserts that fire, not expecting relocation to happen from an unknown non-Java thread. I had fixes for said problems in my own concurrent stack scanning branch, but forgot to point it out in the review thread for JDK-8244997. > > My solution is to read the threadObj before the target thread is shot down, and simply pass in the already sampled thread oop to the context where the events are created. All of this is done with the Threads_lock taken (today) to lock out safepoints from destroying the oop. > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8252627/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8252627 > > Thanks, > /Erik From mikael.vidstedt at oracle.com Tue Sep 1 21:29:55 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 1 Sep 2020 14:29:55 -0700 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> Message-ID: Great to see this - thank you for all the great work you?re putting into it! The changes are in line with what I?m expecting given that I?ve looked at them before, so looks good to me! That said, I?ve looked at this so many times now - and after all even authored some of the original changes - so I would very much appreciate some other hotspot and core libs eyes on it. :) One very minor thing I realized: WB_GetLibcName now returns ?glibc? by default (unless MUSL_LIBC is defined) which means it may return ?glibc? on platforms where the default library really isn?t GNU libc. I will work just fine for what it?s currently being used for (isMusl), but is potentially a bit misleading. Cheers, Mikael > On Sep 1, 2020, at 4:41 AM, Aleksei Voitylov wrote: > > Hi, > > JEP 386 is now Candidate [1] and as we resolved all outstanding issues > within the Portola project I'd like to ask for comments from HotSpot, > Core Libs (changes in libjli/java_md.c), and Build groups before moving > the JEP to Proposed to Target: > > http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ > > Testing: > > JTReg, VM TestBase on all platforms (Linux x86_64, Linux x86, Linux Arm, > Linux AArch64, Linux PPC, Windows x86_64, Windows x86, Mac) with no > regressions. A downport of these changes to 14 passes JCK 14 on these > platforms. > > The port was tested on Alpine Linux 3.8 and 3.11 with JTReg, VM > TestBase. There are no differences with Linux x86_64 with the exception > of SA which is not supported as per the JEP. A downport of these changes > to 14 passes JCK 14 on Alpine Linux. > > Thanks, > > -Aleksei > > [1] https://bugs.openjdk.java.net/browse/JDK-8229469 > > From david.holmes at oracle.com Tue Sep 1 23:58:46 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Sep 2020 09:58:46 +1000 Subject: RFR(T) : 8252532 : use Utils.TEST_NATIVE_PATH instead of System.getProperty("test.nativepath") In-Reply-To: <93076ed6-f112-dd27-15d3-13f67cdf5de0@oracle.com> References: <93076ed6-f112-dd27-15d3-13f67cdf5de0@oracle.com> Message-ID: <9e962e6c-79c7-35c2-621d-e55a9173ece9@oracle.com> Hi Igor, Changes seem fine (incremental webrev didn't show them all though). There are other pre-existing indentation issues in those files but this is fine. Thanks, David On 31/08/2020 2:53 pm, David Holmes wrote: > Hi Igor, > > On 29/08/2020 1:52 pm, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8252532/webrev.00 >>> 145 lines changed: 28 ins; 22 del; 95 mod; >> >> >> Hi all, >> >> could you please review this trivial clean up which replaces >> System.getProperty("test.nativepath") w/ Utils.TEST_NATIVE_PATH where >> appropriate? >> >> while updating these files, I've also cleaned them up a bit, removed >> unneeded imports, added/removed spaces, etc >> >> testing: runtime, serviceability and vmTestbase/nsk/jvmti/ tests on >> {linux,windows,macos}-x64 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8252532 >> webrev: http://cr.openjdk.java.net/~iignatyev//8252532/webrev.00 > > Generally seems fine (though the fact the patch file contained a series > of changesets threw me initially!) > > test/hotspot/jtreg/runtime/signal/SigTestDriver.java > > ???????? // add test specific arguments w/o signame > ???????? cmd.addAll(Arrays.asList(args) > -???????????????????????? .subList(1, args.length)); > +??????????????? .subList(1, args.length)); > > Your changed line doesn't have the right indent. Can this just be put on > one line anyway: > > ???????? // add test specific arguments w/o signame > ???????? cmd.addAll(Arrays.asList(args).subList(1, args.length)); > > that seems better to me as the fact there is only one argument seems > clearer. Though for greater clarity perhaps: > > ???????? // add test specific arguments w/o signame > ???????? var argList = Arrays.asList(args).subList(1, args.length); > ???????? cmd.addAll(argList); > > -- > > +??????????????? Arrays.stream(Utils.JAVA_OPTIONS.split(" "))) > +??????????????? .filter(s -> !s.isEmpty()) > +??????????????? .filter(s -> s.startsWith("-X")) > +??????????????? .flatMap(arg -> Stream.of("-vmopt", arg)) > +??????????????? .collect(Collectors.toList()); > > The preferred/common style for chained stream operations is to align the > dots: > > ????????? Arrays.stream(Utils.JAVA_OPTIONS.split(" "))) > ??????????????? .filter(s -> !s.isEmpty()) > ??????????????? .filter(s -> s.startsWith("-X")) > ??????????????? .flatMap(arg -> Stream.of("-vmopt", arg)) > ??????????????? .collect(Collectors.toList()); > > --- > > test/lib/jdk/test/lib/process/ProcessTools.java > > -??????? System.out.println("\t" +? t + > -?????????????????????????? " stack: (length = " + stack.length + ")"); > +??????? System.out.println("\t" + t + > +??????????????? " stack: (length = " + stack.length + ")"); > > The original code is more stylistically correct - when breaking > arguments across lines the indent should align with the start of the > arguments. > > Similarly here: > > +??????? return String.format("--- ProcessLog ---%n" + > +??????????????????????? "cmd: %s%n" + > +??????????????????????? "exitvalue: %s%n" + > +??????????????????????? "stderr: %s%n" + > +??????????????????????? "stdout: %s%n", > +??????????????? getCommandLine(pb), exitValue, stderr, stdout); > > should be: > > +??????? return String.format("--- ProcessLog ---%n" + > +???????????????????????????? "cmd: %s%n" + > +???????????????????????????? "exitvalue: %s%n" + > +???????????????????????????? "stderr: %s%n" + > +???????????????????????????? "stdout: %s%n", > +???????????????????????????? getCommandLine(pb), exitValue, stderr, > stdout); > > and here: > > +??????? String executable = Paths.get(Utils.TEST_NATIVE_PATH, > executableName) > +??????????????? .toAbsolutePath() > +??????????????? .toString(); > > indentation again. > > Thanks, > David > ----- > >> Thanks, >> -- Igor >> From igor.ignatyev at oracle.com Wed Sep 2 00:34:53 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 1 Sep 2020 17:34:53 -0700 Subject: RFR(T) : 8252532 : use Utils.TEST_NATIVE_PATH instead of System.getProperty("test.nativepath") In-Reply-To: <9e962e6c-79c7-35c2-621d-e55a9173ece9@oracle.com> References: <93076ed6-f112-dd27-15d3-13f67cdf5de0@oracle.com> <9e962e6c-79c7-35c2-621d-e55a9173ece9@oracle.com> Message-ID: <6305BACE-B690-46D8-B932-4AB420CEDCCA@oracle.com> thanks Serguei, David, pushed. -- Igor > Hi Igor, > > The update looks good. > > Thanks, > Serguei > On Sep 1, 2020, at 4:58 PM, David Holmes wrote: > > Hi Igor, > > Changes seem fine (incremental webrev didn't show them all though). > > There are other pre-existing indentation issues in those files but this is fine. > > Thanks, > David > > On 31/08/2020 2:53 pm, David Holmes wrote: >> Hi Igor, >> On 29/08/2020 1:52 pm, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8252532/webrev.00 >>>> 145 lines changed: 28 ins; 22 del; 95 mod; >>> >>> >>> Hi all, >>> >>> could you please review this trivial clean up which replaces System.getProperty("test.nativepath") w/ Utils.TEST_NATIVE_PATH where appropriate? >>> >>> while updating these files, I've also cleaned them up a bit, removed unneeded imports, added/removed spaces, etc >>> >>> testing: runtime, serviceability and vmTestbase/nsk/jvmti/ tests on {linux,windows,macos}-x64 >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8252532 >>> webrev: http://cr.openjdk.java.net/~iignatyev//8252532/webrev.00 >> Generally seems fine (though the fact the patch file contained a series of changesets threw me initially!) >> test/hotspot/jtreg/runtime/signal/SigTestDriver.java >> // add test specific arguments w/o signame >> cmd.addAll(Arrays.asList(args) >> - .subList(1, args.length)); >> + .subList(1, args.length)); >> Your changed line doesn't have the right indent. Can this just be put on one line anyway: >> // add test specific arguments w/o signame >> cmd.addAll(Arrays.asList(args).subList(1, args.length)); >> that seems better to me as the fact there is only one argument seems clearer. Though for greater clarity perhaps: >> // add test specific arguments w/o signame >> var argList = Arrays.asList(args).subList(1, args.length); >> cmd.addAll(argList); >> -- >> + Arrays.stream(Utils.JAVA_OPTIONS.split(" "))) >> + .filter(s -> !s.isEmpty()) >> + .filter(s -> s.startsWith("-X")) >> + .flatMap(arg -> Stream.of("-vmopt", arg)) >> + .collect(Collectors.toList()); >> The preferred/common style for chained stream operations is to align the dots: >> Arrays.stream(Utils.JAVA_OPTIONS.split(" "))) >> .filter(s -> !s.isEmpty()) >> .filter(s -> s.startsWith("-X")) >> .flatMap(arg -> Stream.of("-vmopt", arg)) >> .collect(Collectors.toList()); >> --- >> test/lib/jdk/test/lib/process/ProcessTools.java >> - System.out.println("\t" + t + >> - " stack: (length = " + stack.length + ")"); >> + System.out.println("\t" + t + >> + " stack: (length = " + stack.length + ")"); >> The original code is more stylistically correct - when breaking arguments across lines the indent should align with the start of the arguments. >> Similarly here: >> + return String.format("--- ProcessLog ---%n" + >> + "cmd: %s%n" + >> + "exitvalue: %s%n" + >> + "stderr: %s%n" + >> + "stdout: %s%n", >> + getCommandLine(pb), exitValue, stderr, stdout); >> should be: >> + return String.format("--- ProcessLog ---%n" + >> + "cmd: %s%n" + >> + "exitvalue: %s%n" + >> + "stderr: %s%n" + >> + "stdout: %s%n", >> + getCommandLine(pb), exitValue, stderr, stdout); >> and here: >> + String executable = Paths.get(Utils.TEST_NATIVE_PATH, executableName) >> + .toAbsolutePath() >> + .toString(); >> indentation again. >> Thanks, >> David >> ----- >>> Thanks, >>> -- Igor >>> From igor.ignatyev at oracle.com Wed Sep 2 00:36:43 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 1 Sep 2020 17:36:43 -0700 Subject: RFR(S) : 8252402 : rewrite vmTestbase/nsk/jvmti/Allocate/alloc001 shell test to Java In-Reply-To: <87aa2d79-d411-4787-45b8-9c1824834a10@oracle.com> References: <1B17F111-EA9D-4BB6-93DB-663A5328A40F@oracle.com> <9E518796-8336-449C-AB5A-5B2BF387AA9B@oracle.com> <146ac950-2b0b-b4ac-d957-9b6a9f01afcd@oracle.com> <9B0DB297-83B5-4098-BBD7-42370C8D3396@oracle.com> <87aa2d79-d411-4787-45b8-9c1824834a10@oracle.com> Message-ID: <5017C152-6BA3-40E2-932D-4F6E3B409700@oracle.com> thanks Alex, pushed. -- Igor > On Aug 31, 2020, at 3:37 PM, Alex Menkov wrote: > > I suppose with WSL cygwin is not required. > But it should be OK as well. > LGTM. > > --alex > > On 08/31/2020 15:03, Igor Ignatyev wrote: >> Hi Alex, >> AFAIK, cygwin always was and still is a requirement for both building and testing on windows, so it should not be a problem for anyone who is developing/testing OpenJDK on windows. >> Cheers, >> -- Igor >>> On Aug 31, 2020, at 2:54 PM, Alex Menkov wrote: >>> >>> Hi Igor, >>> >>> Looks good in general. >>> One question. >>> As far as I see old test didn't run "sh ulimit" on Windows. >>> So now the test requires cygwin to run? >>> >>> --alex >>> >>> On 08/31/2020 12:03, Igor Ignatyev wrote: >>>> ping? >>>>> On Aug 26, 2020, at 4:59 PM, Igor Ignatyev wrote: >>>>> >>>>> http://cr.openjdk.java.net/~iignatyev//8252402/webrev.00 >>>>>> 287 lines changed: 60 ins; 200 del; 27 mod; >>>>> >>>>> Hi all, >>>>> >>>>> could you please review the patch which removes shell script from alloc001 test? >>>>> there are two small difference comparing to the original test: >>>>> - if we don't get OutOfMemory on mac or windows, the test will be reported as skipped (as opposed to passed-passed before) >>>>> - as changing DYLD_LIBRARY_PATH on mac is a bit cumbersome due to SIP, I decided to use '-agentpath:' instead of '-agentlib:' >>>>> >>>>> the patch also moves alloc001.java to closer to the other files (vmTestbase/nsk/jvmti/Allocate/alloc001), removes TestDescription.java file, moves jtreg test description to the test source code and removes printdump agent option making trace messages in alloc001.cpp unconditional. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8252402/webrev.00 (depends on 8252401[1,2]) >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8252402 >>>>> testing: vmTestbase/nsk/jvmti/Allocate/alloc001 on {linux,windows,macos}-x64 >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8252401 >>>>> [2] http://cr.openjdk.java.net/~iignatyev//8252401/webrev.00 >>>>> >>>>> Thanks, >>>>> -- Igor >>>>> From ioi.lam at oracle.com Wed Sep 2 01:29:27 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 1 Sep 2020 18:29:27 -0700 Subject: RFR(L) 8243208 Clean up JVMFlag implementation Message-ID: https://bugs.openjdk.java.net/browse/JDK-8243208 http://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v01/ https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags+Clean+Up+-+Design+Proposal+for+JDK-8243208 Please review this major clean up of HotSpot command-line flags. The goals are: ??? + Reduce the complexity of the implementation ??? + Improvement footprint/performance (with C++ constexpr) ??? + Allow more flexibility in flag declaration (see also JDK-7123237) **** Notable interface changes: ??? I tried to make the changes non-intrusive. Most HotSpot developers ? ? should not be affected at all, unless you touch the following areas: [1] The declaration of diagnostic/experimental/manageable flags is changed. ? ? See globals.hpp for examples: ??? OLD: experimental(intx, hashCode, 5, "..docs...") ??? NEW: product(intx, hashCode, 5, EXPERIMENTAL, "..docs...") ??? The reason is to support more flexible combinations. Before, ? ? all experimental flags must be "product". Now they can be "develop" ? ? as well. [2] Declaration of constraint functions is changed to use a macro. ??? See jvmFlagConstraintsRuntime.hpp [3] The confusing type JVMFlag::Flags is renamed to JVMFlag::Attrs to be ? ? clear it's about "attributes of the flags" and not "the flags ? ? themselves". [4] The min/max of all ranges must be compile-time constants. We had ? ? two cases where the min/max was specified via os::xxx function ? ? calls. These are converted to constraint functions: ??? OLD: ??? product_pd(uintx, InitialCodeCacheSize, "...") \ ??????????? range(os::vm_page_size(), max_uintx) ??? product(size_t, NUMAInterleaveGranularity, 2*M, "...")? \ ??????????? range(os::vm_allocation_granularity(), \ ????????????????? NOT_LP64(2*G) LP64_ONLY(8192*G)) \ ??? NEW: ??? product_pd(uintx, InitialCodeCacheSize, "...") \ ??????????? constraint(VMPageSizeConstraintFunc, AtParse) ??? product(size_t, NUMAInterleaveGranularity, 2*M, "...")? \ ???????????? constraint(NUMAInterleaveGranularityConstraintFunc, \ ??????????????????????? AtParse) **** Notable implementation changes: [1] C++ constexpr is used extensively for build-time initialization of ? ? various tables. [2] All XXX_FLAGS() macros now consistent take 7 arguments. Application ??? of these macros in jvmFlag.cpp have been greatly simplified. ??? This also makes it possible for further modularization in the future ? ? (see JDK-8243205). ??? example: ??? #define RUNTIME_FLAGS(develop, \ ??? ? ?? ???????????????? develop_pd, \ ??????? ? ?? ???????????? product, \ ??????????? ? ?? ???????? product_pd, \ ??????????????? ? ?? ???? notproduct, \ ??????????????????? ? ? ? range, \ ????????????????????????? constraint) \ [3] When processing the command-line arguments, the JVM flags are now ??? searched using a build-time generated hashtable. See jvmFlagLookup.cpp [4] Tables for range/constraint check used to be dynamically constructed ??? and linearly searched. Now they are build-time generated, with O(1) ? ? access time (a simple array index). For detailed discussion on the new design, please see https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags+Clean+Up+-+Design+Proposal+for+JDK-8243208 **** Next steps ??? I tried to keep this changeset small. So some changes are deferred: [1] In an separate RFE (JDK-8081833) I will use C++ templates ??? to consolidate the large amount of duplicated code in jvmFlag.cpp, ? ? jvmFlagRangeList.cpp and jvmFlagConstraintList.cpp. [2] There are archaic test cases that assume that experimental flags ? ? must be product flags. See JVMFlag::JVMFlag() constructor in jvmFlag.cpp. ? ? I'll relax this in JDK-7123237 and update the test cases. Thanks - Ioi From kim.barrett at oracle.com Wed Sep 2 01:43:50 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 Sep 2020 21:43:50 -0400 Subject: RFR: 8251274: Provide utility types for function SFINAE using extra template parameters In-Reply-To: <394e5299-5fcc-a53b-a06e-082c13808e8a@oracle.com> References: <9230593a-1974-9d01-7768-71215ae61c34@oracle.com> <288D2756-60CC-4B14-8464-71FCAA2463A0@oracle.com> <44CD3A2D-F61F-4863-84B9-643F0C51483B@oracle.com> <3C3225BF-3D6C-447A-86A4-EE35315862F0@oracle.com> <295ec966-34d4-879c-55e9-eb9cd3b4ba15@oracle.com> <1D99E9B0-CAA8-4DB2-9862-78F51C705BC8@oracle.com> <9967005c-efef-b4bc-1b3c-64ae5cb6746e@oracle.com> <394e5299-5fcc-a53b-a06e-082c13808e8a@oracle.com> Message-ID: <48B61015-7B65-4E22-91D9-516E8ACE9712@oracle.com> > On Sep 1, 2020, at 1:26 PM, Lois Foltan wrote: > > On 9/1/2020 4:55 AM, Kim Barrett wrote: >>> On Aug 31, 2020, at 9:43 AM, Kim Barrett wrote: >>> >>>> On Aug 31, 2020, at 5:38 AM, Erik ?sterlund wrote: >>>> >>>> Hi Kim, >>>> >>>> Looks good. >>> Thanks >>> >>>> Thanks, >>>> /Erik >>>> >>>> On 2020-08-31 11:18, Kim Barrett wrote: >>>>> [?] OK. Then here?s a new webrev. (The gtest file has no changes now, but still shows up in the >>>>> webrev because of the change then revert in the patch series.) Just a full, since there seems >>>>> little point in an incremental. >>>>> >>>>> https://cr.openjdk.java.net/~kbarrett/8251274/open.01/ >> Given the changes we?ve discussed, the summary for the bug should probably be changed from >> ?utility types? to ?utility macro?. >> > > Hi Kim, > > This looks good. Thanks. > After reading through the discussion with Erik, I am glad about the resulting ENABLE_IF macro. I do have one question/comment which might just be for my clarification. I am assuming I can also still use this new C++11 extra anonymous non-type template parameter with a default value as the return type? I'm not sure I understand your question, so apologies if I've misinterpreted and answered something else. The new macro, and the new in C++11 mechanism it uses, is only in template parameter lists. You can still use the old technique of a SFINAE expression for a function's result type. That is, this still works: template typename EnableIf::value, bool>::type foo(T x) { ... } is a function returning bool that is only applicable if the argument is an int. Though with C++11 one could instead write that as template std::enable_if_t::value, bool> foo(T x) { ... } But why would you, when you can separate the SFINAE part from the signature, improving readability: template::value)> bool foo(T x) { ? } > In addition, if I am allowed to use this as the return type, I further assume that it is also allowed to use a single template parameter that is a conjunction of expressions for the return type too? In each of the above examples, `std::is_integral::value` is in a syntactic position that must be an expression. Any boolean expression will do, including a conjunction of subexpressions. From david.holmes at oracle.com Wed Sep 2 05:03:51 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Sep 2020 15:03:51 +1000 Subject: RFR: 8252656: Replace RegisterArrayForGC mechanism with plain Handles In-Reply-To: <2630e73c-878d-fd0f-1eb4-c5fb2f341b43@oracle.com> References: <2630e73c-878d-fd0f-1eb4-c5fb2f341b43@oracle.com> Message-ID: <62dd4d4b-1720-4635-32c1-cfe980162c30@oracle.com> Nice cleanup/simplification! LGTM. Thanks, David On 1/09/2020 11:13 pm, Stefan Karlsson wrote: > Hi all, > > Please review this patch to replace the RegisterArrayForGC mechanism > with the usage of plain Handles. > > https://cr.openjdk.java.net/~stefank/8252656/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8252656 > > JVM_GetStackAccessControlContext collects a bunch of oops in array and > then calls into allocating code that might safepoint. To deal with this, > the local array is registered and explicitly visited by the GCs. This > patch gets rid of this and use an array of Handles instead. > > I've tested this locally with test TEST="test/jdk/java/security". Any > other suggestions on what to test this with? I've also run this through > tier1, as a sanity check. > > Thanks, > StefanK From david.holmes at oracle.com Wed Sep 2 05:14:58 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Sep 2020 15:14:58 +1000 Subject: RFR: 8252627: Make it safe for JFR thread to read threadObj In-Reply-To: <1cf3a3ba-2417-261c-a085-dd2c7dd3e6a1@oracle.com> References: <1cf3a3ba-2417-261c-a085-dd2c7dd3e6a1@oracle.com> Message-ID: <808f945d-7d4a-4f86-d796-c4f82054343f@oracle.com> Hi Erik, On 1/09/2020 8:55 pm, Erik ?sterlund wrote: > Hi, > > Since the thread oop moved to OopStorage, a bug was introduced. The oop > is now read with load barriers. > If the JFR thread shoots a signal at a thread that holds a load barrier > lock, the target thread is stuck > holding that lock. Then the JFR thread tries to read the threadObj(), > which might grab the same lock. > This causes a deadlock. There are also some ZGC asserts that fire, not > expecting relocation to happen > from an unknown non-Java thread. I had fixes for said problems in my own > concurrent stack scanning branch, > but forgot to point it out in the review thread for JDK-8244997. > > My solution is to read the threadObj before the target thread is shot > down, and simply pass in the already > sampled thread oop to the context where the events are created. That makes sense given the target thread's threadObj() can't change. > All of this is done with the Threads_lock > taken (today) to lock out safepoints from destroying the oop. Not clear to me (being unfamiliar with the general structure of the JFR code) where this taking of the Threads_lock is occurring relative to these raw oop uses? Also what kind of thread is executing this code? Thanks, David ----- > Webrev: > http://cr.openjdk.java.net/~eosterlund/8252627/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8252627 > > Thanks, > /Erik From magnus.ihse.bursie at oracle.com Wed Sep 2 06:39:47 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 2 Sep 2020 08:39:47 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> On 2020-09-01 11:46, Kim Barrett wrote: >> On Sep 1, 2020, at 4:01 AM, Eric Liu wrote: >> >> Hi all, >> >> Please review this simple change to fix some compile warnings. >> >> The newer gcc (gcc-8 or higher) would warn for calls to bounded string >> manipulation functions such as 'strncpy' that may either truncate the >> copied string or leave the destination unchanged. >> >> This patch fixed stringop-truncation warnings reported by gcc, some of >> them only appear when compiled with "--enable-asan". >> >> [TESTS] >> Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. >> No new failure found. >> >> http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8252407 >> >> Thanks, >> Eric > I really hate -Wstringop-truncation. It's been a constant source of churn > for us ever since it appeared. The changes being made to getIndex and > getFlags (NetworkInterface.c) are modifying lines that were changed very > recently to deal with such warnings from gcc10. I'm worried that these new > changes will re-trigger warnings from gcc10 (though this change isn't a > revert; the gcc10 warning was justifiable). I think it should be okay, but > there?s some risk here. Maybe we should have a common library for all native code where we supply our own string operation functions? It will then be much easier to make sure the implementation passes different compiler versions, and that we provide sane semantics (which isn't really the? case with the original C library functions; hence all this warning churning). There have been other problem areas before, where a common library (static or dynamic) would have helped. Perhaps it's time to go ahead and create one... /Magnus > > Changes look good, subject to that caveat. I think these changes conform > better to the documented description of the warning than did the recent > NetworkInterface.c change mentioned above, so I?m hopeful that we?re not > in a warning cycle here. But it would be good to have someone test these > changes against gcc10.x. > > From stefan.karlsson at oracle.com Wed Sep 2 06:50:34 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 2 Sep 2020 08:50:34 +0200 Subject: RFR: 8252656: Replace RegisterArrayForGC mechanism with plain Handles In-Reply-To: <5eeea8f5-62cc-316d-075d-1a2c4277eeab@oracle.com> References: <2630e73c-878d-fd0f-1eb4-c5fb2f341b43@oracle.com> <5eeea8f5-62cc-316d-075d-1a2c4277eeab@oracle.com> Message-ID: Thanks, Thomas. StefanK On 2020-09-01 17:01, Thomas Schatzl wrote: > Hi, > > On 01.09.20 15:13, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to replace the RegisterArrayForGC mechanism >> with the usage of plain Handles. >> >> https://cr.openjdk.java.net/~stefank/8252656/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8252656 >> >> JVM_GetStackAccessControlContext collects a bunch of oops in array and >> then calls into allocating code that might safepoint. To deal with >> this, the local array is registered and explicitly visited by the GCs. >> This patch gets rid of this and use an array of Handles instead. >> >> I've tested this locally with test TEST="test/jdk/java/security". Any >> other suggestions on what to test this with? I've also run this >> through tier1, as a sanity check. >> >> Thanks, >> StefanK > > ? lgtm. > > Thomas From stefan.karlsson at oracle.com Wed Sep 2 06:50:44 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 2 Sep 2020 08:50:44 +0200 Subject: RFR: 8252656: Replace RegisterArrayForGC mechanism with plain Handles In-Reply-To: <62dd4d4b-1720-4635-32c1-cfe980162c30@oracle.com> References: <2630e73c-878d-fd0f-1eb4-c5fb2f341b43@oracle.com> <62dd4d4b-1720-4635-32c1-cfe980162c30@oracle.com> Message-ID: Thanks, David. StefanK On 2020-09-02 07:03, David Holmes wrote: > Nice cleanup/simplification! > > LGTM. > > Thanks, > David > > On 1/09/2020 11:13 pm, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to replace the RegisterArrayForGC mechanism >> with the usage of plain Handles. >> >> https://cr.openjdk.java.net/~stefank/8252656/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8252656 >> >> JVM_GetStackAccessControlContext collects a bunch of oops in array and >> then calls into allocating code that might safepoint. To deal with >> this, the local array is registered and explicitly visited by the GCs. >> This patch gets rid of this and use an array of Handles instead. >> >> I've tested this locally with test TEST="test/jdk/java/security". Any >> other suggestions on what to test this with? I've also run this >> through tier1, as a sanity check. >> >> Thanks, >> StefanK From fweimer at redhat.com Wed Sep 2 07:19:52 2020 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 02 Sep 2020 09:19:52 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> (Magnus Ihse Bursie's message of "Wed, 2 Sep 2020 08:39:47 +0200") References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> Message-ID: <87tuwgodbb.fsf@oldenburg2.str.redhat.com> * Magnus Ihse Bursie: > Maybe we should have a common library for all native code where we > supply our own string operation functions? It will then be much easier > to make sure the implementation passes different compiler versions, > and that we provide sane semantics (which isn't really the? case with > the original C library functions; hence all this warning churning). When I looked at this (sorry that I never sent a patch), pretty much all uses of strncpy were actually bugs: The code should check the actual string length using strlen, report an error if it would be truncated, and then use memcpy with the length already computed, plus one. In other words, the strncpy warnings are correct, and there is only churn in the sense that GCC gets smarter at discovering bugs. At least one of the bugs was in theory user-visible: the network interface code would return data for an interface that does not actually exist on the system. Thanks, Florian From kim.barrett at oracle.com Wed Sep 2 07:50:38 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 2 Sep 2020 03:50:38 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> Message-ID: > On Sep 2, 2020, at 2:39 AM, Magnus Ihse Bursie wrote: > > On 2020-09-01 11:46, Kim Barrett wrote: >> I really hate -Wstringop-truncation. It's been a constant source of churn >> for us ever since it appeared. The changes being made to getIndex and >> getFlags (NetworkInterface.c) are modifying lines that were changed very >> recently to deal with such warnings from gcc10. I'm worried that these new >> changes will re-trigger warnings from gcc10 (though this change isn't a >> revert; the gcc10 warning was justifiable). I think it should be okay, but >> there?s some risk here. > Maybe we should have a common library for all native code where we supply our own string operation functions? It will then be much easier to make sure the implementation passes different compiler versions, and that we provide sane semantics (which isn't really the case with the original C library functions; hence all this warning churning). For the recurring problems with strncpy, there?s already this: https://bugs.openjdk.java.net/browse/JDK-8232187 Nobody?s picked it up yet. From kim.barrett at oracle.com Wed Sep 2 07:56:06 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 2 Sep 2020 03:56:06 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <87tuwgodbb.fsf@oldenburg2.str.redhat.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> Message-ID: <89A572A7-E2EE-4A26-A907-C5D59FDBDFCA@oracle.com> > On Sep 2, 2020, at 3:19 AM, Florian Weimer wrote: > > * Magnus Ihse Bursie: > >> Maybe we should have a common library for all native code where we >> supply our own string operation functions? It will then be much easier >> to make sure the implementation passes different compiler versions, >> and that we provide sane semantics (which isn't really the case with >> the original C library functions; hence all this warning churning). > > When I looked at this (sorry that I never sent a patch), pretty much all > uses of strncpy were actually bugs: The code should check the actual > string length using strlen, report an error if it would be truncated, > and then use memcpy with the length already computed, plus one. > > In other words, the strncpy warnings are correct, and there is only > churn in the sense that GCC gets smarter at discovering bugs. Having been involved in reviews of a lot of these warnings, I think that?s seriously overstating the cases where there have been actual bugs. There have been some actual bugs found, but there have been a lot of definite false positives. Particularly from -Wstringop-truncation. From erik.osterlund at oracle.com Wed Sep 2 08:43:39 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 2 Sep 2020 10:43:39 +0200 Subject: RFR: 8252627: Make it safe for JFR thread to read threadObj In-Reply-To: <808f945d-7d4a-4f86-d796-c4f82054343f@oracle.com> References: <1cf3a3ba-2417-261c-a085-dd2c7dd3e6a1@oracle.com> <808f945d-7d4a-4f86-d796-c4f82054343f@oracle.com> Message-ID: Hi David, Thanks for reviewing this. On 2020-09-02 07:14, David Holmes wrote: > Hi Erik, > > On 1/09/2020 8:55 pm, Erik ?sterlund wrote: >> Hi, >> >> Since the thread oop moved to OopStorage, a bug was introduced. The >> oop is now read with load barriers. >> If the JFR thread shoots a signal at a thread that holds a load >> barrier lock, the target thread is stuck >> holding that lock. Then the JFR thread tries to read the threadObj(), >> which might grab the same lock. >> This causes a deadlock. There are also some ZGC asserts that fire, >> not expecting relocation to happen >> from an unknown non-Java thread. I had fixes for said problems in my >> own concurrent stack scanning branch, >> but forgot to point it out in the review thread for JDK-8244997. >> >> My solution is to read the threadObj before the target thread is shot >> down, and simply pass in the already >> sampled thread oop to the context where the events are created. > > That makes sense given the target thread's threadObj() can't change. Exactly. >> All of this is done with the Threads_lock >> taken (today) to lock out safepoints from destroying the oop. > > Not clear to me (being unfamiliar with the general structure of the > JFR code) where this taking of the Threads_lock is occurring relative > to these raw oop uses? The JfrThreadSampler::task_stacktrace function grabs the Threads_lock, and selects target threads to sample. Said sampling is done with a call to JfrThreadSampleClosure::do_sample_thread (which starts by asserting the lock is owned). In there, it has two modes of sampling: one for in_native and one for in_java threads. The native case constructs a JfrNativeSamplerCallback, which caches the oop in the constructor, and the java case constructs a OSThreadSampler, which caches the oop in the constructor. Both of them act as corresponding context for the native and java sampling correspondingly, and the cached oop is used in the subsequent callbacks, when the threads have been stopped, instead of reading the oop fresh from the target threads. > Also what kind of thread is executing this code? The JFR sampling thread is a non-Java thread. And that is indeed why it is taking the Threads_lock in the first place. It is currently the only way for a non-Java and non-GC thread to block out safepoints. Thanks, /Erik > Thanks, > David > ----- > >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8252627/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8252627 >> >> Thanks, >> /Erik From stefan.karlsson at oracle.com Wed Sep 2 09:09:27 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 2 Sep 2020 11:09:27 +0200 Subject: RFR(L) 8243208 Clean up JVMFlag implementation In-Reply-To: References: Message-ID: Hi Ioi, I did an initial scan over the change, to see what it looked like from the GC perspective, but didn't actually look at the code in detail. Would you mind making these whitespace changes to make the code a bit more clear and consistent: https://cr.openjdk.java.net/~stefank/8243208/review/webrev.01/ Regarding the rename Flags to Attrs. I think this is one of those things that would be nice to get separated out into a preparation patch. Also, I'm not sure about the name Attrs. It's obscure, and even our guidelines discourage introducing abbreviated names. Could we rename this to Attributes? I think this shouldn't be pushed. It's fine during the review, but I don't think we should leave these breadcrumbs in the code. It should be enough that it has been logged as an RFE. // TODO: // JVMFlagConstraintChecker is just temporary code to bridge JVMFlagLimit with the existing // JVMFlagConstraint_XXX classes. All of these will be gone when we templatize the // range/constraint checks (JDK-8081833). Thanks, StefanK On 2020-09-02 03:29, Ioi Lam wrote: > https://bugs.openjdk.java.net/browse/JDK-8243208 > http://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v01/ > https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags+Clean+Up+-+Design+Proposal+for+JDK-8243208 > > > > > Please review this major clean up of HotSpot command-line flags. The > goals are: > > ??? + Reduce the complexity of the implementation > ??? + Improvement footprint/performance (with C++ constexpr) > ??? + Allow more flexibility in flag declaration (see also JDK-7123237) > > > > **** Notable interface changes: > > ??? I tried to make the changes non-intrusive. Most HotSpot developers > ? ? should not be affected at all, unless you touch the following areas: > > [1] The declaration of diagnostic/experimental/manageable flags is changed. > ? ? See globals.hpp for examples: > > ??? OLD: experimental(intx, hashCode, 5, "..docs...") > ??? NEW: product(intx, hashCode, 5, EXPERIMENTAL, "..docs...") > > ??? The reason is to support more flexible combinations. Before, > ? ? all experimental flags must be "product". Now they can be "develop" > ? ? as well. > > [2] Declaration of constraint functions is changed to use a macro. > ??? See jvmFlagConstraintsRuntime.hpp > > [3] The confusing type JVMFlag::Flags is renamed to JVMFlag::Attrs to be > ? ? clear it's about "attributes of the flags" and not "the flags > ? ? themselves". > > [4] The min/max of all ranges must be compile-time constants. We had > ? ? two cases where the min/max was specified via os::xxx function > ? ? calls. These are converted to constraint functions: > > ??? OLD: > ??? product_pd(uintx, InitialCodeCacheSize, "...") \ > ??????????? range(os::vm_page_size(), max_uintx) > > ??? product(size_t, NUMAInterleaveGranularity, 2*M, "...")? \ > ??????????? range(os::vm_allocation_granularity(), \ > ????????????????? NOT_LP64(2*G) LP64_ONLY(8192*G)) \ > > ??? NEW: > ??? product_pd(uintx, InitialCodeCacheSize, "...") \ > ??????????? constraint(VMPageSizeConstraintFunc, AtParse) > > ??? product(size_t, NUMAInterleaveGranularity, 2*M, "...")? \ > ???????????? constraint(NUMAInterleaveGranularityConstraintFunc, \ > ??????????????????????? AtParse) > > > > **** Notable implementation changes: > > [1] C++ constexpr is used extensively for build-time initialization of > ? ? various tables. > > [2] All XXX_FLAGS() macros now consistent take 7 arguments. Application > ??? of these macros in jvmFlag.cpp have been greatly simplified. > > ??? This also makes it possible for further modularization in the future > ? ? (see JDK-8243205). > > ??? example: > > ??? #define RUNTIME_FLAGS(develop, \ > ??? ? ?? ???????????????? develop_pd, \ > ??????? ? ?? ???????????? product, \ > ??????????? ? ?? ???????? product_pd, \ > ??????????????? ? ?? ???? notproduct, \ > ??????????????????? ? ? ? range, \ > ????????????????????????? constraint) \ > > [3] When processing the command-line arguments, the JVM flags are now > ??? searched using a build-time generated hashtable. See jvmFlagLookup.cpp > > [4] Tables for range/constraint check used to be dynamically constructed > ??? and linearly searched. Now they are build-time generated, with O(1) > ? ? access time (a simple array index). > > For detailed discussion on the new design, please see > https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags+Clean+Up+-+Design+Proposal+for+JDK-8243208 > > > > > **** Next steps > > ??? I tried to keep this changeset small. So some changes are deferred: > > [1] In an separate RFE (JDK-8081833) I will use C++ templates > ??? to consolidate the large amount of duplicated code in jvmFlag.cpp, > ? ? jvmFlagRangeList.cpp and jvmFlagConstraintList.cpp. > > [2] There are archaic test cases that assume that experimental flags > ? ? must be product flags. See JVMFlag::JVMFlag() constructor in > jvmFlag.cpp. > ? ? I'll relax this in JDK-7123237 and update the test cases. > > > Thanks > - Ioi From daniel.fuchs at oracle.com Wed Sep 2 09:26:29 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 Sep 2020 10:26:29 +0100 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <87tuwgodbb.fsf@oldenburg2.str.redhat.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> Message-ID: Hi, On 02/09/2020 08:19, Florian Weimer wrote: > At least one of the bugs was in theory user-visible: the network > interface code would return data for an interface that does not actually > exist on the system. WRT NetworkInterface.c, I might support using `strnlen` to check the length before hand, if that solves both cases (gcc8 and gcc10). I'm always a bit nervous of changing the behavior in this library as it's hard to verify that no regression is introduced. best regards, -- daniel From aph at redhat.com Wed Sep 2 09:32:11 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 2 Sep 2020 10:32:11 +0100 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: Message-ID: On 01/09/2020 09:57, David Holmes wrote: > We already build with gcc 9.2 and don't see any issues with shared code > compiling for hotspot - which of these require --enable-asan? It > certainly looks like an unnecessary warning - the whole point of strncpy > is to truncate at a safe length. :( Yes, exactly. As long as the destination buffer isn't overrun, the code is working as it should. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nick.gasson at arm.com Wed Sep 2 09:42:44 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Wed, 02 Sep 2020 17:42:44 +0800 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> Message-ID: <85tuwgy0ob.fsf@nicgas01-pc.shanghai.arm.com> Hi Aleksei, On 09/01/20 19:41 pm, Aleksei Voitylov wrote: > > JEP 386 is now Candidate [1] and as we resolved all outstanding issues > within the Portola project I'd like to ask for comments from HotSpot, > Core Libs (changes in libjli/java_md.c), and Build groups before moving > the JEP to Proposed to Target: > > http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ > I see the JEP only mentions support for x86_64, so maybe this is out of scope, but with this trivial change to os_linux_aarch64.cpp your patch works on Alpine/AArch64 too: --- a/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp +++ b/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp @@ -74,7 +74,6 @@ # include # include # include -# include #define REG_FP 29 #define REG_LR 30 -- Thanks, Nick From magnus.ihse.bursie at oracle.com Wed Sep 2 10:31:53 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 2 Sep 2020 12:31:53 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> Message-ID: On 2020-09-02 09:50, Kim Barrett wrote: >> On Sep 2, 2020, at 2:39 AM, Magnus Ihse Bursie wrote: >> >> On 2020-09-01 11:46, Kim Barrett wrote: >>> I really hate -Wstringop-truncation. It's been a constant source of churn >>> for us ever since it appeared. The changes being made to getIndex and >>> getFlags (NetworkInterface.c) are modifying lines that were changed very >>> recently to deal with such warnings from gcc10. I'm worried that these new >>> changes will re-trigger warnings from gcc10 (though this change isn't a >>> revert; the gcc10 warning was justifiable). I think it should be okay, but >>> there?s some risk here. >> Maybe we should have a common library for all native code where we supply our own string operation functions? It will then be much easier to make sure the implementation passes different compiler versions, and that we provide sane semantics (which isn't really the case with the original C library functions; hence all this warning churning). > For the recurring problems with strncpy, there?s already this: > https://bugs.openjdk.java.net/browse/JDK-8232187 > Nobody?s picked it up yet. Yes, but that's hotspot only. The other JDK libraries would not be able to use it. (And as I said, there are other, already existing functions, that ideally should be shared between hotspot and the rest of the libraries). /Magnus > From eric.c.liu at arm.com Wed Sep 2 13:40:17 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Wed, 2 Sep 2020 13:40:17 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: , Message-ID: Hi David, Thanks for your review and sorry for the delay. David Holmes on Tue Sep 1 08:57:01 UTC 2020 > We already build with gcc 9.2 and don't see any issues with shared code > compiling for hotspot - which of these require --enable-asan? It > certainly looks like an unnecessary warning - the whole point of strncpy > is to truncate at a safe length. :( I suppose all of those warnings require "--enable-asan", but two of them (test related) also require "--with-gtest". > Have you tested this by building on other platforms? I'm not sure if all > compilers will ignore these gcc specific pragmas. Yes. Besides aarch64, I also tested this by building on x86. But a harder question now is the different behaviors between gcc-9 and gcc-10. As Kim Barrett said it would result to a warning cycle here. Thanks, Eric From lois.foltan at oracle.com Wed Sep 2 15:40:45 2020 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 2 Sep 2020 11:40:45 -0400 Subject: RFR: 8251274: Provide utility types for function SFINAE using extra template parameters In-Reply-To: <48B61015-7B65-4E22-91D9-516E8ACE9712@oracle.com> References: <9230593a-1974-9d01-7768-71215ae61c34@oracle.com> <288D2756-60CC-4B14-8464-71FCAA2463A0@oracle.com> <44CD3A2D-F61F-4863-84B9-643F0C51483B@oracle.com> <3C3225BF-3D6C-447A-86A4-EE35315862F0@oracle.com> <295ec966-34d4-879c-55e9-eb9cd3b4ba15@oracle.com> <1D99E9B0-CAA8-4DB2-9862-78F51C705BC8@oracle.com> <9967005c-efef-b4bc-1b3c-64ae5cb6746e@oracle.com> <394e5299-5fcc-a53b-a06e-082c13808e8a@oracle.com> <48B61015-7B65-4E22-91D9-516E8ACE9712@oracle.com> Message-ID: On 9/1/2020 9:43 PM, Kim Barrett wrote: >> On Sep 1, 2020, at 1:26 PM, Lois Foltan wrote: >> >> On 9/1/2020 4:55 AM, Kim Barrett wrote: >>>> On Aug 31, 2020, at 9:43 AM, Kim Barrett wrote: >>>> >>>>> On Aug 31, 2020, at 5:38 AM, Erik ?sterlund wrote: >>>>> >>>>> Hi Kim, >>>>> >>>>> Looks good. >>>> Thanks >>>> >>>>> Thanks, >>>>> /Erik >>>>> >>>>> On 2020-08-31 11:18, Kim Barrett wrote: >>>>>> [?] OK. Then here?s a new webrev. (The gtest file has no changes now, but still shows up in the >>>>>> webrev because of the change then revert in the patch series.) Just a full, since there seems >>>>>> little point in an incremental. >>>>>> >>>>>> https://cr.openjdk.java.net/~kbarrett/8251274/open.01/ >>> Given the changes we?ve discussed, the summary for the bug should probably be changed from >>> ?utility types? to ?utility macro?. >>> >> Hi Kim, >> >> This looks good. > Thanks. > >> After reading through the discussion with Erik, I am glad about the resulting ENABLE_IF macro. I do have one question/comment which might just be for my clarification. I am assuming I can also still use this new C++11 extra anonymous non-type template parameter with a default value as the return type? > I'm not sure I understand your question, so apologies if I've misinterpreted > and answered something else. > > The new macro, and the new in C++11 mechanism it uses, is only in template > parameter lists. > > You can still use the old technique of a SFINAE expression for a function's > result type. That is, this still works: > > template > typename EnableIf::value, bool>::type > foo(T x) { ... } > > is a function returning bool that is only applicable if the argument is an > int. Though with C++11 one could instead write that as > > template > std::enable_if_t::value, bool> > foo(T x) { ... } > > But why would you, when you can separate the SFINAE part from the signature, > improving readability: > > template::value)> > bool foo(T x) { ? } Hi Kim, Yes, I wanted to understand how would the new ENABLE_IF macro be used for the return type.? Thank you for detailing the different coding examples and I like your suggestion of the last example of separating the SFINAE part from the signature. Thanks, Lois >> In addition, if I am allowed to use this as the return type, I further assume that it is also allowed to use a single template parameter that is a conjunction of expressions for the return type too? > In each of the above examples, `std::is_integral::value` is in a > syntactic position that must be an expression. Any boolean expression will > do, including a conjunction of subexpressions. > From ioi.lam at oracle.com Wed Sep 2 18:32:00 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 2 Sep 2020 11:32:00 -0700 Subject: RFR(L) 8243208 Clean up JVMFlag implementation In-Reply-To: References: Message-ID: <1f6cef00-1fcf-5359-5266-ca102a756047@oracle.com> Hi Stefan, Thanks for your comments & patch! On 9/2/20 2:09 AM, Stefan Karlsson wrote: > Hi Ioi, > > I did an initial scan over the change, to see what it looked like from > the GC perspective, but didn't actually look at the code in detail. > > Would you mind making these whitespace changes to make the code a bit > more clear and consistent: > https://cr.openjdk.java.net/~stefank/8243208/review/webrev.01/ > Fixed. > Regarding the rename Flags to Attrs. I think this is one of those > things that would be nice to get separated out into a preparation > patch. Also, I'm not sure about the name Attrs. It's obscure, and even > our guidelines discourage introducing abbreviated names. Could we > rename this to Attributes? > I reverted Attrs/attrs back to Flags/flags. This eliminated a lot of deltas in the code so hopefully will make it a little easier to review :-) I think I'll can do the renaming of Flags -> Attributes after the initial push, as it's not really needed in the main clean up. > I think this shouldn't be pushed. It's fine during the review, but I > don't think we should leave these breadcrumbs in the code. It should > be enough that it has been logged as an RFE. > > // TODO: > // JVMFlagConstraintChecker is just temporary code to bridge > JVMFlagLimit with the existing > // JVMFlagConstraint_XXX classes. All of these will be gone when we > templatize the > // range/constraint checks (JDK-8081833). > Removed. http://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/ Thanks - Ioi > Thanks, > StefanK > > On 2020-09-02 03:29, Ioi Lam wrote: >> https://bugs.openjdk.java.net/browse/JDK-8243208 >> http://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v01/ >> >> https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags+Clean+Up+-+Design+Proposal+for+JDK-8243208 >> >> >> >> >> Please review this major clean up of HotSpot command-line flags. The >> goals are: >> >> ???? + Reduce the complexity of the implementation >> ???? + Improvement footprint/performance (with C++ constexpr) >> ???? + Allow more flexibility in flag declaration (see also JDK-7123237) >> >> >> >> **** Notable interface changes: >> >> ???? I tried to make the changes non-intrusive. Most HotSpot developers >> ?? ? should not be affected at all, unless you touch the following >> areas: >> >> [1] The declaration of diagnostic/experimental/manageable flags is >> changed. >> ?? ? See globals.hpp for examples: >> >> ???? OLD: experimental(intx, hashCode, 5, "..docs...") >> ???? NEW: product(intx, hashCode, 5, EXPERIMENTAL, "..docs...") >> >> ???? The reason is to support more flexible combinations. Before, >> ?? ? all experimental flags must be "product". Now they can be "develop" >> ?? ? as well. >> >> [2] Declaration of constraint functions is changed to use a macro. >> ???? See jvmFlagConstraintsRuntime.hpp >> >> [3] The confusing type JVMFlag::Flags is renamed to JVMFlag::Attrs to be >> ?? ? clear it's about "attributes of the flags" and not "the flags >> ?? ? themselves". >> >> [4] The min/max of all ranges must be compile-time constants. We had >> ?? ? two cases where the min/max was specified via os::xxx function >> ?? ? calls. These are converted to constraint functions: >> >> ???? OLD: >> ???? product_pd(uintx, InitialCodeCacheSize, "...") \ >> ???????????? range(os::vm_page_size(), max_uintx) >> >> ???? product(size_t, NUMAInterleaveGranularity, 2*M, "...")? \ >> ???????????? range(os::vm_allocation_granularity(), \ >> ?????????????????? NOT_LP64(2*G) LP64_ONLY(8192*G)) \ >> >> ???? NEW: >> ???? product_pd(uintx, InitialCodeCacheSize, "...") \ >> ???????????? constraint(VMPageSizeConstraintFunc, AtParse) >> >> ???? product(size_t, NUMAInterleaveGranularity, 2*M, "...")? \ >> constraint(NUMAInterleaveGranularityConstraintFunc, \ >> ???????????????????????? AtParse) >> >> >> >> **** Notable implementation changes: >> >> [1] C++ constexpr is used extensively for build-time initialization of >> ?? ? various tables. >> >> [2] All XXX_FLAGS() macros now consistent take 7 arguments. Application >> ???? of these macros in jvmFlag.cpp have been greatly simplified. >> >> ???? This also makes it possible for further modularization in the >> future >> ?? ? (see JDK-8243205). >> >> ???? example: >> >> ???? #define RUNTIME_FLAGS(develop, \ >> ???? ? ?? ???????????????? develop_pd, \ >> ???????? ? ?? ???????????? product, \ >> ???????????? ? ?? ???????? product_pd, \ >> ???????????????? ? ?? ???? notproduct, \ >> ???????????????????? ? ? ? range, \ >> ?????????????????????????? constraint) \ >> >> [3] When processing the command-line arguments, the JVM flags are now >> ???? searched using a build-time generated hashtable. See >> jvmFlagLookup.cpp >> >> [4] Tables for range/constraint check used to be dynamically constructed >> ???? and linearly searched. Now they are build-time generated, with O(1) >> ?? ? access time (a simple array index). >> >> For detailed discussion on the new design, please see >> https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags+Clean+Up+-+Design+Proposal+for+JDK-8243208 >> >> >> >> >> **** Next steps >> >> ???? I tried to keep this changeset small. So some changes are deferred: >> >> [1] In an separate RFE (JDK-8081833) I will use C++ templates >> ???? to consolidate the large amount of duplicated code in jvmFlag.cpp, >> ?? ? jvmFlagRangeList.cpp and jvmFlagConstraintList.cpp. >> >> [2] There are archaic test cases that assume that experimental flags >> ?? ? must be product flags. See JVMFlag::JVMFlag() constructor in >> jvmFlag.cpp. >> ?? ? I'll relax this in JDK-7123237 and update the test cases. >> >> >> Thanks >> - Ioi From ioi.lam at oracle.com Wed Sep 2 18:37:36 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 2 Sep 2020 11:37:36 -0700 Subject: RFR(L) 8243208 Clean up JVMFlag implementation In-Reply-To: References: Message-ID: <0a5448c3-0ec1-d4cf-00ad-f98e314f1c51@oracle.com> I have an updated version (with fewer changes!) as suggested to me Stefan Karlsson offline: http://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/ [1] More consistent white spaces in the macro definitions [2] Reverted the renaming of JVMFlag::Flags. This renaming is not really needed by ??? the cleanup. Doing it later will avoid unnecessary clutter in the changeset. ??? Also Stefan suggested renaming to JVMFlag::Attributes (instead of ::Attrs). [3] Removed some TODO comments as they are already captured in JBS issues. Thanks - Ioi On 9/1/20 6:29 PM, Ioi Lam wrote: > https://bugs.openjdk.java.net/browse/JDK-8243208 > http://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v01/ > https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags+Clean+Up+-+Design+Proposal+for+JDK-8243208 > > > > > Please review this major clean up of HotSpot command-line flags. The > goals are: > > ??? + Reduce the complexity of the implementation > ??? + Improvement footprint/performance (with C++ constexpr) > ??? + Allow more flexibility in flag declaration (see also JDK-7123237) > > > > **** Notable interface changes: > > ??? I tried to make the changes non-intrusive. Most HotSpot developers > ? ? should not be affected at all, unless you touch the following areas: > > [1] The declaration of diagnostic/experimental/manageable flags is > changed. > ? ? See globals.hpp for examples: > > ??? OLD: experimental(intx, hashCode, 5, "..docs...") > ??? NEW: product(intx, hashCode, 5, EXPERIMENTAL, "..docs...") > > ??? The reason is to support more flexible combinations. Before, > ? ? all experimental flags must be "product". Now they can be "develop" > ? ? as well. > > [2] Declaration of constraint functions is changed to use a macro. > ??? See jvmFlagConstraintsRuntime.hpp > > [3] The confusing type JVMFlag::Flags is renamed to JVMFlag::Attrs to be > ? ? clear it's about "attributes of the flags" and not "the flags > ? ? themselves". > > [4] The min/max of all ranges must be compile-time constants. We had > ? ? two cases where the min/max was specified via os::xxx function > ? ? calls. These are converted to constraint functions: > > ??? OLD: > ??? product_pd(uintx, InitialCodeCacheSize, "...") \ > ??????????? range(os::vm_page_size(), max_uintx) > > ??? product(size_t, NUMAInterleaveGranularity, 2*M, "...")? \ > ??????????? range(os::vm_allocation_granularity(), \ > ????????????????? NOT_LP64(2*G) LP64_ONLY(8192*G)) \ > > ??? NEW: > ??? product_pd(uintx, InitialCodeCacheSize, "...") \ > ??????????? constraint(VMPageSizeConstraintFunc, AtParse) > > ??? product(size_t, NUMAInterleaveGranularity, 2*M, "...")? \ > ???????????? constraint(NUMAInterleaveGranularityConstraintFunc, \ > ??????????????????????? AtParse) > > > > **** Notable implementation changes: > > [1] C++ constexpr is used extensively for build-time initialization of > ? ? various tables. > > [2] All XXX_FLAGS() macros now consistent take 7 arguments. Application > ??? of these macros in jvmFlag.cpp have been greatly simplified. > > ??? This also makes it possible for further modularization in the future > ? ? (see JDK-8243205). > > ??? example: > > ??? #define RUNTIME_FLAGS(develop, \ > ??? ? ?? ???????????????? develop_pd, \ > ??????? ? ?? ???????????? product, \ > ??????????? ? ?? ???????? product_pd, \ > ??????????????? ? ?? ???? notproduct, \ > ??????????????????? ? ? ? range, \ > ????????????????????????? constraint) \ > > [3] When processing the command-line arguments, the JVM flags are now > ??? searched using a build-time generated hashtable. See > jvmFlagLookup.cpp > > [4] Tables for range/constraint check used to be dynamically constructed > ??? and linearly searched. Now they are build-time generated, with O(1) > ? ? access time (a simple array index). > > For detailed discussion on the new design, please see > https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags+Clean+Up+-+Design+Proposal+for+JDK-8243208 > > > > > **** Next steps > > ??? I tried to keep this changeset small. So some changes are deferred: > > [1] In an separate RFE (JDK-8081833) I will use C++ templates > ??? to consolidate the large amount of duplicated code in jvmFlag.cpp, > ? ? jvmFlagRangeList.cpp and jvmFlagConstraintList.cpp. > > [2] There are archaic test cases that assume that experimental flags > ? ? must be product flags. See JVMFlag::JVMFlag() constructor in > jvmFlag.cpp. > ? ? I'll relax this in JDK-7123237 and update the test cases. > > > Thanks > - Ioi From david.holmes at oracle.com Wed Sep 2 22:05:50 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Sep 2020 08:05:50 +1000 Subject: RFR: 8252627: Make it safe for JFR thread to read threadObj In-Reply-To: References: <1cf3a3ba-2417-261c-a085-dd2c7dd3e6a1@oracle.com> <808f945d-7d4a-4f86-d796-c4f82054343f@oracle.com> Message-ID: <0135e13f-2c1e-7aa2-cd47-d6a041a90cda@oracle.com> Hi Erik, Thanks for clarifying the details around the Threads_lock. David On 2/09/2020 6:43 pm, Erik ?sterlund wrote: > Hi David, > > Thanks for reviewing this. > > On 2020-09-02 07:14, David Holmes wrote: >> Hi Erik, >> >> On 1/09/2020 8:55 pm, Erik ?sterlund wrote: >>> Hi, >>> >>> Since the thread oop moved to OopStorage, a bug was introduced. The >>> oop is now read with load barriers. >>> If the JFR thread shoots a signal at a thread that holds a load >>> barrier lock, the target thread is stuck >>> holding that lock. Then the JFR thread tries to read the threadObj(), >>> which might grab the same lock. >>> This causes a deadlock. There are also some ZGC asserts that fire, >>> not expecting relocation to happen >>> from an unknown non-Java thread. I had fixes for said problems in my >>> own concurrent stack scanning branch, >>> but forgot to point it out in the review thread for JDK-8244997. >>> >>> My solution is to read the threadObj before the target thread is shot >>> down, and simply pass in the already >>> sampled thread oop to the context where the events are created. >> >> That makes sense given the target thread's threadObj() can't change. > > Exactly. > >>> All of this is done with the Threads_lock >>> taken (today) to lock out safepoints from destroying the oop. >> >> Not clear to me (being unfamiliar with the general structure of the >> JFR code) where this taking of the Threads_lock is occurring relative >> to these raw oop uses? > > The JfrThreadSampler::task_stacktrace function grabs the Threads_lock, > and selects target threads to sample. Said sampling is done with a call > to JfrThreadSampleClosure::do_sample_thread (which starts by asserting > the lock is owned). In there, it has two modes of sampling: one for > in_native and one for in_java threads. The native case constructs a > JfrNativeSamplerCallback, which caches the oop in the constructor, and > the java case constructs a OSThreadSampler, which caches the oop in the > constructor. Both of them act as corresponding context for the native > and java sampling correspondingly, and the cached oop is used in the > subsequent callbacks, when the threads have been stopped, instead of > reading the oop fresh from the target threads. > >> Also what kind of thread is executing this code? > > The JFR sampling thread is a non-Java thread. And that is indeed why it > is taking the Threads_lock in the first place. It is currently the only > way for a non-Java and non-GC thread to block out safepoints. > > Thanks, > /Erik > >> Thanks, >> David >> ----- >> >>> Webrev: >>> http://cr.openjdk.java.net/~eosterlund/8252627/webrev.00/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8252627 >>> >>> Thanks, >>> /Erik > From david.holmes at oracle.com Thu Sep 3 05:00:28 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Sep 2020 15:00:28 +1000 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> Message-ID: <5e0cc7c5-224f-97fc-7ceb-992a19630f4c@oracle.com> Hi Aleksei, Overall this all seems okay. A few minor comments below. On 1/09/2020 9:41 pm, Aleksei Voitylov wrote: > Hi, > > JEP 386 is now Candidate [1] and as we resolved all outstanding issues > within the Portola project I'd like to ask for comments from HotSpot, > Core Libs (changes in libjli/java_md.c), and Build groups before moving > the JEP to Proposed to Target: > > http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ src/hotspot/os/linux/os_linux.cpp 624 os::Linux::set_libc_version("unknown"); 625 os::Linux::set_libpthread_version("unknown"); Surely we can do better than "unknown"? Surely different releases of Alpine linux must identify different version of the libraries? -- The PaX related error message belongs in release notes not the source code - the error message should be much more succint: "Failed to mark memory page as executable - check if grsecurity/PaX is enabled" -- src/hotspot/os/linux/os_linux.hpp numa_node_to_cpus is too big to be in the header file now. --- src/hotspot/share/prims/whitebox.cpp I would expect this to use the version string set in os_linux.cpp. --- src/hotspot/share/runtime/abstract_vm_version.cpp Ideally LIBC_STR would come from the build system - as we do for FLOAT_ARCH. See flags.m4. --- src/java.base/unix/native/libjli/java_md.c The comment is way too long - see the AIX case below it. :) --- src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c 282 // To improve portability across platforms and avoid conflicts 283 // between GNU and XSI versions of strerror_r, plain strerror is used. 284 // It's safe because this code is not used in any multithreaded environment. It is not at all clear to me that this code is not used in a multi-threaded environment. The VM is always multi-threaded. This usage was added here: http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-December/018419.html But this code also uses strerror in another place (as does other code) so ... --- test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c Why is this change needed? --- In general the busybox changes are bit unpleasant in the tests. Pity Alpine didn't try to present a familiar binary environment. :( --- test/jdk/java/lang/ProcessBuilder/RedirectWithLongFilename.java @comment is not needed That said I don't think that test should be using the Basic class. --- Thanks, David > Testing: > > JTReg, VM TestBase on all platforms (Linux x86_64, Linux x86, Linux Arm, > Linux AArch64, Linux PPC, Windows x86_64, Windows x86, Mac) with no > regressions. A downport of these changes to 14 passes JCK 14 on these > platforms. > > The port was tested on Alpine Linux 3.8 and 3.11 with JTReg, VM > TestBase. There are no differences with Linux x86_64? with the exception > of SA which is not supported as per the JEP. A downport of these changes > to 14 passes JCK 14 on Alpine Linux. > > Thanks, > > -Aleksei > > [1] https://bugs.openjdk.java.net/browse/JDK-8229469 > > From david.holmes at oracle.com Thu Sep 3 05:38:39 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Sep 2020 15:38:39 +1000 Subject: RFR(L) 8243208 Clean up JVMFlag implementation In-Reply-To: <0a5448c3-0ec1-d4cf-00ad-f98e314f1c51@oracle.com> References: <0a5448c3-0ec1-d4cf-00ad-f98e314f1c51@oracle.com> Message-ID: Hi Ioi, This looks really good - I like the end result in regard to the global definitions. I can't comment on the detailed macros or constexpr use. Small style nit - the are few places where spaces are missing around operators e.g. + for (int i=0; i I have an updated version (with fewer changes!) as suggested to me > Stefan Karlsson offline: > > http://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/ > > [1] More consistent white spaces in the macro definitions > > [2] Reverted the renaming of JVMFlag::Flags. This renaming is not really > needed by > ??? the cleanup. Doing it later will avoid unnecessary clutter in the > changeset. > > ??? Also Stefan suggested renaming to JVMFlag::Attributes (instead of > ::Attrs). > > [3] Removed some TODO comments as they are already captured in JBS issues. > > Thanks > - Ioi > > > > On 9/1/20 6:29 PM, Ioi Lam wrote: >> https://bugs.openjdk.java.net/browse/JDK-8243208 >> http://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v01/ >> https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags+Clean+Up+-+Design+Proposal+for+JDK-8243208 >> >> >> >> >> Please review this major clean up of HotSpot command-line flags. The >> goals are: >> >> ??? + Reduce the complexity of the implementation >> ??? + Improvement footprint/performance (with C++ constexpr) >> ??? + Allow more flexibility in flag declaration (see also JDK-7123237) >> >> >> >> **** Notable interface changes: >> >> ??? I tried to make the changes non-intrusive. Most HotSpot developers >> ? ? should not be affected at all, unless you touch the following areas: >> >> [1] The declaration of diagnostic/experimental/manageable flags is >> changed. >> ? ? See globals.hpp for examples: >> >> ??? OLD: experimental(intx, hashCode, 5, "..docs...") >> ??? NEW: product(intx, hashCode, 5, EXPERIMENTAL, "..docs...") >> >> ??? The reason is to support more flexible combinations. Before, >> ? ? all experimental flags must be "product". Now they can be "develop" >> ? ? as well. >> >> [2] Declaration of constraint functions is changed to use a macro. >> ??? See jvmFlagConstraintsRuntime.hpp >> >> [3] The confusing type JVMFlag::Flags is renamed to JVMFlag::Attrs to be >> ? ? clear it's about "attributes of the flags" and not "the flags >> ? ? themselves". >> >> [4] The min/max of all ranges must be compile-time constants. We had >> ? ? two cases where the min/max was specified via os::xxx function >> ? ? calls. These are converted to constraint functions: >> >> ??? OLD: >> ??? product_pd(uintx, InitialCodeCacheSize, "...") \ >> ??????????? range(os::vm_page_size(), max_uintx) >> >> ??? product(size_t, NUMAInterleaveGranularity, 2*M, "...")? \ >> ??????????? range(os::vm_allocation_granularity(), \ >> ????????????????? NOT_LP64(2*G) LP64_ONLY(8192*G)) \ >> >> ??? NEW: >> ??? product_pd(uintx, InitialCodeCacheSize, "...") \ >> ??????????? constraint(VMPageSizeConstraintFunc, AtParse) >> >> ??? product(size_t, NUMAInterleaveGranularity, 2*M, "...")? \ >> ???????????? constraint(NUMAInterleaveGranularityConstraintFunc, \ >> ??????????????????????? AtParse) >> >> >> >> **** Notable implementation changes: >> >> [1] C++ constexpr is used extensively for build-time initialization of >> ? ? various tables. >> >> [2] All XXX_FLAGS() macros now consistent take 7 arguments. Application >> ??? of these macros in jvmFlag.cpp have been greatly simplified. >> >> ??? This also makes it possible for further modularization in the future >> ? ? (see JDK-8243205). >> >> ??? example: >> >> ??? #define RUNTIME_FLAGS(develop, \ >> ??? ? ?? ???????????????? develop_pd, \ >> ??????? ? ?? ???????????? product, \ >> ??????????? ? ?? ???????? product_pd, \ >> ??????????????? ? ?? ???? notproduct, \ >> ??????????????????? ? ? ? range, \ >> ????????????????????????? constraint) \ >> >> [3] When processing the command-line arguments, the JVM flags are now >> ??? searched using a build-time generated hashtable. See >> jvmFlagLookup.cpp >> >> [4] Tables for range/constraint check used to be dynamically constructed >> ??? and linearly searched. Now they are build-time generated, with O(1) >> ? ? access time (a simple array index). >> >> For detailed discussion on the new design, please see >> https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags+Clean+Up+-+Design+Proposal+for+JDK-8243208 >> >> >> >> >> **** Next steps >> >> ??? I tried to keep this changeset small. So some changes are deferred: >> >> [1] In an separate RFE (JDK-8081833) I will use C++ templates >> ??? to consolidate the large amount of duplicated code in jvmFlag.cpp, >> ? ? jvmFlagRangeList.cpp and jvmFlagConstraintList.cpp. >> >> [2] There are archaic test cases that assume that experimental flags >> ? ? must be product flags. See JVMFlag::JVMFlag() constructor in >> jvmFlag.cpp. >> ? ? I'll relax this in JDK-7123237 and update the test cases. >> >> >> Thanks >> - Ioi > From Alan.Bateman at oracle.com Thu Sep 3 13:37:34 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 3 Sep 2020 14:37:34 +0100 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> Message-ID: On 01/09/2020 12:41, Aleksei Voitylov wrote: > Hi, > > JEP 386 is now Candidate [1] and as we resolved all outstanding issues > within the Portola project I'd like to ask for comments from HotSpot, > Core Libs (changes in libjli/java_md.c), and Build groups before moving > the JEP to Proposed to Target: > > http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ > .02, .03, .04 seem to be older and seem to include the changes to JDK-8252248 that Alexander Scherbatiy had out for review separately so I'll ignore those and just look at .01, I hope that is right. I agree with David that the comment in java_md.c is excessive and unnecessary. The WB API is mostly for the hotspot tests and looks a bit strange to be using it in the launcher tests to check for musl. Have you look at alternatives? The changes to the Process test to check for busybox is okay. -Alan From gerard.ziemski at oracle.com Thu Sep 3 16:58:29 2020 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Thu, 3 Sep 2020 11:58:29 -0500 Subject: RFR(L) 8243208 Clean up JVMFlag implementation In-Reply-To: <0a5448c3-0ec1-d4cf-00ad-f98e314f1c51@oracle.com> References: <0a5448c3-0ec1-d4cf-00ad-f98e314f1c51@oracle.com> Message-ID: <871070c2-0175-7833-0280-cb2e86302e5c@oracle.com> hi Ioi, Very nice work! I reviewed most of the files already (they look good), but the core implementation is taking me more time, so for now I?m going to share what I have so far on file src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp: #1 The API JVMFlagLimit::get_constraint(flag) says ?constraint?, but it returns JVMFlagLimit* using different names for the same thing - one calls it ?limit", the other uses ?constraint?. Maybe instead of 282 JVMFlagRangeChecker range = JVMFlagRangeList::find(flag); 283 if (range.exists()) { 284 range.print(st); 285 } else { 286 const JVMFlagLimit* limit = JVMFlagLimit::get_constraint(flag); 287 if (limit != NULL) { we could have this: 282 JVMFlagRangeChecker range = JVMFlagRangeList::find(flag); 283 if (range.exists()) { 284 range.print(st); 285 } else { 286 const JVMFlagLimit* limit = JVMFlagLimit::find(flag); 287 if (limit != NULL) { or alternatively rename ?JVMFlagLimit? to ?JVMFlagConstraint? ? #2 Comment: 290?????? // Two special cases who's range lower limit is an os:: function call and cannot should be: 290?????? // Two special cases whose range lower limit is an os:: function call and cannot #3 Isn?t there a better way to treat the special cases in "JVMFlagRangeList::print?, without explicitly checking for hardcoded function pointers? Or is it just not worth the effort, with only 2 such cases for now? #4 Inconsistent white space usage in: 245 #define DEFINE_RANGE_CHECK(T) \ 246 JVMFlag::Error JVMFlagRangeChecker::check_ ## T(T value, bool verbose) const {????????? \ 247?? assert(exists(), "must be");????????????????????????????????????????????????????????? \ 248?? JVMFlagRange_ ## T range(_flag, _limit->as_##T()->min(), _limit->as_ ## T()->max()); \ 249?? return range.check_ ## T(value, verbose);???????????????????????????????????????????? \ For example, at line 248 we have "_limit->as_##T()->min()? (no spaces around ##) then "_limit->as_ ## T()->max()" #5 I'm not sure how others feel about it, but I think I personally would find it helpful for macros like ?DEFINE_RANGE_CHECK? to see a comment with a concrete example of macro expansion for some flag, just to see what it works out to be. I?ll have more feedback soon? cheers On 9/2/20 1:37 PM, Ioi Lam wrote: > I have an updated version (with fewer changes!) as suggested to me > Stefan Karlsson offline: > > http://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/ > > [1] More consistent white spaces in the macro definitions > > [2] Reverted the renaming of JVMFlag::Flags. This renaming is not > really needed by > ??? the cleanup. Doing it later will avoid unnecessary clutter in the > changeset. > > ??? Also Stefan suggested renaming to JVMFlag::Attributes (instead of > ::Attrs). > > [3] Removed some TODO comments as they are already captured in JBS > issues. > > Thanks > - Ioi > > > > On 9/1/20 6:29 PM, Ioi Lam wrote: >> https://bugs.openjdk.java.net/browse/JDK-8243208 >> http://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v01/ >> >> https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags+Clean+Up+-+Design+Proposal+for+JDK-8243208 >> >> >> >> >> Please review this major clean up of HotSpot command-line flags. The >> goals are: >> >> ??? + Reduce the complexity of the implementation >> ??? + Improvement footprint/performance (with C++ constexpr) >> ??? + Allow more flexibility in flag declaration (see also JDK-7123237) >> >> >> >> **** Notable interface changes: >> >> ??? I tried to make the changes non-intrusive. Most HotSpot developers >> ? ? should not be affected at all, unless you touch the following areas: >> >> [1] The declaration of diagnostic/experimental/manageable flags is >> changed. >> ? ? See globals.hpp for examples: >> >> ??? OLD: experimental(intx, hashCode, 5, "..docs...") >> ??? NEW: product(intx, hashCode, 5, EXPERIMENTAL, "..docs...") >> >> ??? The reason is to support more flexible combinations. Before, >> ? ? all experimental flags must be "product". Now they can be "develop" >> ? ? as well. >> >> [2] Declaration of constraint functions is changed to use a macro. >> ??? See jvmFlagConstraintsRuntime.hpp >> >> [3] The confusing type JVMFlag::Flags is renamed to JVMFlag::Attrs to be >> ? ? clear it's about "attributes of the flags" and not "the flags >> ? ? themselves". >> >> [4] The min/max of all ranges must be compile-time constants. We had >> ? ? two cases where the min/max was specified via os::xxx function >> ? ? calls. These are converted to constraint functions: >> >> ??? OLD: >> ??? product_pd(uintx, InitialCodeCacheSize, "...") \ >> ??????????? range(os::vm_page_size(), max_uintx) >> >> ??? product(size_t, NUMAInterleaveGranularity, 2*M, "...")? \ >> ??????????? range(os::vm_allocation_granularity(), \ >> ????????????????? NOT_LP64(2*G) LP64_ONLY(8192*G)) \ >> >> ??? NEW: >> ??? product_pd(uintx, InitialCodeCacheSize, "...") \ >> ??????????? constraint(VMPageSizeConstraintFunc, AtParse) >> >> ??? product(size_t, NUMAInterleaveGranularity, 2*M, "...")? \ >> ???????????? constraint(NUMAInterleaveGranularityConstraintFunc, \ >> ??????????????????????? AtParse) >> >> >> >> **** Notable implementation changes: >> >> [1] C++ constexpr is used extensively for build-time initialization of >> ? ? various tables. >> >> [2] All XXX_FLAGS() macros now consistent take 7 arguments. Application >> ??? of these macros in jvmFlag.cpp have been greatly simplified. >> >> ??? This also makes it possible for further modularization in the future >> ? ? (see JDK-8243205). >> >> ??? example: >> >> ??? #define RUNTIME_FLAGS(develop, \ >> ??? ? ?? ???????????????? develop_pd, \ >> ??????? ? ?? ???????????? product, \ >> ??????????? ? ?? ???????? product_pd, \ >> ??????????????? ? ?? ???? notproduct, \ >> ??????????????????? ? ? ? range, \ >> ????????????????????????? constraint) \ >> >> [3] When processing the command-line arguments, the JVM flags are now >> ??? searched using a build-time generated hashtable. See >> jvmFlagLookup.cpp >> >> [4] Tables for range/constraint check used to be dynamically constructed >> ??? and linearly searched. Now they are build-time generated, with O(1) >> ? ? access time (a simple array index). >> >> For detailed discussion on the new design, please see >> https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags+Clean+Up+-+Design+Proposal+for+JDK-8243208 >> >> >> >> >> **** Next steps >> >> ??? I tried to keep this changeset small. So some changes are deferred: >> >> [1] In an separate RFE (JDK-8081833) I will use C++ templates >> ??? to consolidate the large amount of duplicated code in jvmFlag.cpp, >> ? ? jvmFlagRangeList.cpp and jvmFlagConstraintList.cpp. >> >> [2] There are archaic test cases that assume that experimental flags >> ? ? must be product flags. See JVMFlag::JVMFlag() constructor in >> jvmFlag.cpp. >> ? ? I'll relax this in JDK-7123237 and update the test cases. >> >> >> Thanks >> - Ioi > From vladimir.kozlov at oracle.com Thu Sep 3 19:50:07 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 3 Sep 2020 12:50:07 -0700 Subject: [16] RFR(T) 8252779: compiler/graalunit/HotspotTest.java failed after 8251525 Message-ID: <116ae32d-7dfd-9374-f037-a9be6e7fe162@oracle.com> http://cr.openjdk.java.net/~kvn/8252779/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8252779 8251525 [1] added new intrinsics but it did not update Graal's test which checks intrinsics. Updated CheckGraalIntrinsics.java to fix it. Ran tier1 for testing. Thanks, Vladimir [1] https://bugs.openjdk.java.net/browse/JDK-8251525 From daniel.daugherty at oracle.com Thu Sep 3 19:56:56 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 3 Sep 2020 15:56:56 -0400 Subject: [16] RFR(T) 8252779: compiler/graalunit/HotspotTest.java failed after 8251525 In-Reply-To: <116ae32d-7dfd-9374-f037-a9be6e7fe162@oracle.com> References: <116ae32d-7dfd-9374-f037-a9be6e7fe162@oracle.com> Message-ID: <2d8ba242-924d-0d10-f099-8e6ccc5dd650@oracle.com> On 9/3/20 3:50 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8252779/webrev.00/ src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java ??? No comments. Thumbs up. I agree that this is a trivial change. Dan > https://bugs.openjdk.java.net/browse/JDK-8252779 > > 8251525 [1] added new intrinsics but it did not update Graal's test > which checks intrinsics. > > Updated CheckGraalIntrinsics.java to fix it. > > Ran tier1 for testing. > > Thanks, > Vladimir > > [1] https://bugs.openjdk.java.net/browse/JDK-8251525 From vladimir.kozlov at oracle.com Thu Sep 3 19:58:15 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 3 Sep 2020 12:58:15 -0700 Subject: [16] RFR(T) 8252779: compiler/graalunit/HotspotTest.java failed after 8251525 In-Reply-To: <2d8ba242-924d-0d10-f099-8e6ccc5dd650@oracle.com> References: <116ae32d-7dfd-9374-f037-a9be6e7fe162@oracle.com> <2d8ba242-924d-0d10-f099-8e6ccc5dd650@oracle.com> Message-ID: Thank you, Dean Vladimir K On 9/3/20 12:56 PM, Daniel D. Daugherty wrote: > On 9/3/20 3:50 PM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8252779/webrev.00/ > > src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java > > ??? No comments. > > Thumbs up. I agree that this is a trivial change. > > Dan > > >> https://bugs.openjdk.java.net/browse/JDK-8252779 >> >> 8251525 [1] added new intrinsics but it did not update Graal's test which checks intrinsics. >> >> Updated CheckGraalIntrinsics.java to fix it. >> >> Ran tier1 for testing. >> >> Thanks, >> Vladimir >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8251525 > From aleksei.voitylov at bell-sw.com Fri Sep 4 07:55:07 2020 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Fri, 4 Sep 2020 10:55:07 +0300 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: <5e0cc7c5-224f-97fc-7ceb-992a19630f4c@oracle.com> References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> <5e0cc7c5-224f-97fc-7ceb-992a19630f4c@oracle.com> Message-ID: <99c52389-4df8-17ae-e29c-bcb16ce1dc23@bell-sw.com> Hi Erik, Magnus, Mikael, Nick, David, and Alan, thank you for looking into it. I grouped together all the comments in one response to avoid polluting the mailing lists. Here is an updated version of the patch which addresses the comments: http://cr.openjdk.java.net/~avoitylov/webrev.8247589.06/ Please also find inline answers to the comments by Mikael, Nick, Alan and David, in order. Testing is in progress. [Mikael] > WB_GetLibcName now returns ?glibc? by default (unless MUSL_LIBC is > defined) which means it may return ?glibc? on platforms where the > default library really isn?t GNU libc. I will work just fine for what > it?s currently being used for (isMusl), but is potentially a bit > misleading. I agree. In the updated version WB_GetLibcName returns the LIBC the JDK is build for. [Nick] > I see the JEP only mentions support for x86_64, so maybe this is out of > scope, but with this trivial change to os_linux_aarch64.cpp your patch > works on Alpine/AArch64 too: I planned to add additional platforms it a follow-up enhancement but updated the webrev to include AArch64 now. Testing is in progress, and, if the same level of quality is reached as on x64, I will slightly update the JEP to make it clear AArch64 is also known to work. I hope this will be fine. [Alan] > .02, .03, .04 seem to be older and seem to include the changes to > JDK-8252248 that Alexander Scherbatiy had out for review separately so > I'll ignore those and just look at .01, I hope that is right. This is correct. > I agree with David that the comment in java_md.c is excessive and > unnecessary. Fixed in the updated version. > > The WB API is mostly for the hotspot tests and looks a bit strange to > be using it in the launcher tests to check for musl. Have you look at > alternatives? The changes to the Process test to check for busybox is > okay. The WhiteBox API is used in JDK tests for JFR [1], CollectionUsageThreshold.java [2], TimSortStackSize2.java [3], so we are not adding an extra dependency. Tests tools/launcher/Test7029048.java and tools/launcher/ExecutionEnvironment.java need to change behavior on systems that alter LD_LIBRARY_PATH (AIX and musl). The alternative we first considered was to detect the libc of the OS with ldd in the test and avoid WhiteBox dependency. This approach has a significant drawback: some distributions bundle glibc and OpenJDK and launch it on a musl-based Linux OS, so we really need to detect the libc the JDK was compiled for, not the default libc present in the OS. To avoid such problems all together it was decided to detect the libc flavor the JDK was compiled for through WhiteBox. [David] > src/hotspot/os/linux/os_linux.cpp > > ?624?? os::Linux::set_libc_version("unknown"); > ?625?? os::Linux::set_libpthread_version("unknown"); > > Surely we can do better than "unknown"? Surely different releases of > Alpine linux must identify different version of the libraries? The author of musl indicated it currently does not provide a way to obtain the library version programmatically [4]. > The PaX related error message belongs in release notes not the source > code - the error message should be much more succint: > > "Failed to mark memory page as executable - check if grsecurity/PaX is > enabled" Fixed. > src/hotspot/os/linux/os_linux.hpp > > numa_node_to_cpus is too big to be in the header file now. Fixed. > src/hotspot/share/prims/whitebox.cpp > > I would expect this to use the version string set in os_linux.cpp. In the updated version of the patch the libc variant now comes from the build system. The libc version would probably be unused at this point in WhiteBox, also see answer to your first comment. > src/hotspot/share/runtime/abstract_vm_version.cpp > > Ideally LIBC_STR would come from the build system - as we do for > FLOAT_ARCH. See flags.m4. Yes, thank you for the suggestion. It now comes from the build system, as above. > src/java.base/unix/native/libjli/java_md.c > > The comment is way too long - see the AIX case below it. :) OK, trimmed it down :) > src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c > > ?282???? // To improve portability across platforms and avoid conflicts > ?283???? // between GNU and XSI versions of strerror_r, plain strerror > is used. > ?284???? // It's safe because this code is not used in any > multithreaded environment. > > It is not at all clear to me that this code is not used in a > multi-threaded environment. The VM is always multi-threaded.? This > usage was added here: > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2015-December/018419.html > > > But this code also uses strerror in another place (as does other code) > so ... I checked LinuxDebuggerLocal.java and all attach0 calls using this functionality are guarded by corresponding syncronized constructs. That's because nobody claims that ptrace_attach is thread-safe or re-enterant. It depends to kernel implementation and attempt to use it from multiple threads could lead to unpredictable results. If ptrace_attach is run from different threads but with the same PID, it could crash the target process or fail. And it doesn't have any sense from serviceability agent point of view. Running ptrace_attach from multiple threads with different PIDs should be more or less OK - I trust modern kernel, but I don't see any usecase or command line support for using hotspot agent with multiple PIDs. So it was concluded that using strerror instead of strerror_r to mitigate compatibility issues should not be a problem. > > test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c > > Why is this change needed? Both? tests fail without it because res = (*_jvm)->AttachCurrentThread(_jvm, (void **)&env, NULL); returned with an error (res != JNI_OK). AttachCurrentThread uses the current thread as JavaThread and allocates a java level Thread object and needs to run initializing java code (JavaThread::allocate_threadObj). In order to run java code, the remaining stack space is checked. There must be sufficient? space for an interpreter frame, the java frame and shadow pages ( JavaCalls::call_helper() ). The default for the number of shadow pages is 10 for a release build. If this check fails a StackOverflowException is thrown. As we return with a pending exception the attach fails and we return JNI_ERR. This is only a problem as we call AttachCurrentThread from a thread that we created with the default stacksize. Threads created by the JVM are created with a much higher stacksize. > In general the busybox changes are bit unpleasant in the tests. Pity > Alpine didn't try to present a familiar binary environment. :( By doing so, it managed to significantly trim down the image size. > test/jdk/java/lang/ProcessBuilder/RedirectWithLongFilename.java > > @comment is not needed > > That said I don't think that test should be using the Basic class. Fixed by removing the dependency on Basic class and adding windows to @requires. Thanks, -Aleksei [1] https://hg.openjdk.java.net/jdk/jdk/file/8f642d0b0f63/test/jdk/jdk/jfr/event/compiler/TestCodeCacheConfig.java [2] https://hg.openjdk.java.net/jdk/jdk/file/8f642d0b0f63/test/jdk/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java [3] https://hg.openjdk.java.net/jdk/jdk/file/8f642d0b0f63/test/jdk/java/util/Arrays/TimSortStackSize2.java [4] https://www.openwall.com/lists/musl/2020/05/27/2 From Alan.Bateman at oracle.com Fri Sep 4 09:00:24 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Sep 2020 10:00:24 +0100 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: <99c52389-4df8-17ae-e29c-bcb16ce1dc23@bell-sw.com> References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> <5e0cc7c5-224f-97fc-7ceb-992a19630f4c@oracle.com> <99c52389-4df8-17ae-e29c-bcb16ce1dc23@bell-sw.com> Message-ID: <0ae99863-f6b1-6b14-b896-b8ed4fb7b1a5@oracle.com> On 04/09/2020 08:55, Aleksei Voitylov wrote: > : > Tests tools/launcher/Test7029048.java and > tools/launcher/ExecutionEnvironment.java need to change behavior on > systems that alter LD_LIBRARY_PATH (AIX and musl). The alternative we > first considered was to detect the libc of the OS with ldd in the test > and avoid WhiteBox dependency. This approach has a significant drawback: > some distributions bundle glibc and OpenJDK and launch it on a > musl-based Linux OS, so we really need to detect the libc the JDK was > compiled for, not the default libc present in the OS. To avoid such > problems all together it was decided to detect the libc flavor the JDK > was compiled for through WhiteBox. > I really dislike the changes to the launcher tests and I don't think the WB API is the right place for this. I think we need to find something cleaner and maybe expose it as a method on jdk.test.lib.Platform. -Alan From Alan.Bateman at oracle.com Fri Sep 4 09:08:39 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Sep 2020 10:08:39 +0100 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: <0ae99863-f6b1-6b14-b896-b8ed4fb7b1a5@oracle.com> References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> <5e0cc7c5-224f-97fc-7ceb-992a19630f4c@oracle.com> <99c52389-4df8-17ae-e29c-bcb16ce1dc23@bell-sw.com> <0ae99863-f6b1-6b14-b896-b8ed4fb7b1a5@oracle.com> Message-ID: On 04/09/2020 10:00, Alan Bateman wrote: > On 04/09/2020 08:55, Aleksei Voitylov wrote: >> : >> Tests tools/launcher/Test7029048.java and >> tools/launcher/ExecutionEnvironment.java need to change behavior on >> systems that alter LD_LIBRARY_PATH (AIX and musl). The alternative we >> first considered was to detect the libc of the OS with ldd in the test >> and avoid WhiteBox dependency. This approach has a significant drawback: >> some distributions bundle glibc and OpenJDK and launch it on a >> musl-based Linux OS, so we really need to detect the libc the JDK was >> compiled for, not the default libc present in the OS. To avoid such >> problems all together it was decided to detect the libc flavor the JDK >> was compiled for through WhiteBox. >> > I really dislike the changes to the launcher tests and I don't think > the WB API is the right place for this. I think we need to find > something cleaner and maybe expose it as a method on > jdk.test.lib.Platform. > or alternatively, a new class in jdk.test.lib that gives provide methods to introspect the runtime, whatever is simplest and doesn't depend on the WB API as it's independent of HotSpot. -Alan From fweimer at redhat.com Fri Sep 4 11:50:55 2020 From: fweimer at redhat.com (Florian Weimer) Date: Fri, 04 Sep 2020 13:50:55 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: (Daniel Fuchs's message of "Wed, 2 Sep 2020 10:26:29 +0100") References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> Message-ID: <87sgbxhiao.fsf@oldenburg2.str.redhat.com> * Daniel Fuchs: > Hi, > > On 02/09/2020 08:19, Florian Weimer wrote: >> At least one of the bugs was in theory user-visible: the network >> interface code would return data for an interface that does not actually >> exist on the system. > > WRT NetworkInterface.c, I might support using `strnlen` to check > the length before hand, if that solves both cases (gcc8 and gcc10). > I'm always a bit nervous of changing the behavior in this library > as it's hard to verify that no regression is introduced. I think you should use strlen. If the string is longer than the buffer sent to the kernel, it cannot match an existing interface because all the names are shorter. So some sort of ?not found? error needs to reported. (I assume that it's actually a bug that you can look up a network interface by a name that merely shares the same prefix with an actual interface on the system.) Thanks, Florian From aleksei.voitylov at bell-sw.com Fri Sep 4 12:51:34 2020 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Fri, 4 Sep 2020 15:51:34 +0300 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> <5e0cc7c5-224f-97fc-7ceb-992a19630f4c@oracle.com> <99c52389-4df8-17ae-e29c-bcb16ce1dc23@bell-sw.com> <0ae99863-f6b1-6b14-b896-b8ed4fb7b1a5@oracle.com> Message-ID: <5f68767a-67cd-e788-7765-45f6ec78462e@bell-sw.com> Alan, in this case I'm leaning towards a new class jdk.test.lib.LibcHelper with a native implementation which calls (*env)->NewStringUTF(env, libc), which will be used by the tests which require it. Otherwise we'd have to specify nativepath for all tests which use jdk.test.lib.Platform. What do you think? -Aleksei On 04/09/2020 12:08, Alan Bateman wrote: > On 04/09/2020 10:00, Alan Bateman wrote: >> On 04/09/2020 08:55, Aleksei Voitylov wrote: >>> : >>> Tests tools/launcher/Test7029048.java and >>> tools/launcher/ExecutionEnvironment.java need to change behavior on >>> systems that alter LD_LIBRARY_PATH (AIX and musl). The alternative we >>> first considered was to detect the libc of the OS with ldd in the test >>> and avoid WhiteBox dependency. This approach has a significant >>> drawback: >>> some distributions bundle glibc and OpenJDK and launch it on a >>> musl-based Linux OS, so we really need to detect the libc the JDK was >>> compiled for, not the default libc present in the OS. To avoid such >>> problems all together it was decided to detect the libc flavor the JDK >>> was compiled for through WhiteBox. >>> >> I really dislike the changes to the launcher tests and I don't think >> the WB API is the right place for this. I think we need to find >> something cleaner and maybe expose it as a method on >> jdk.test.lib.Platform. >> > or alternatively, a new class in jdk.test.lib that gives provide > methods to introspect the runtime, whatever is simplest and doesn't > depend on the WB API as it's independent of HotSpot. > > -Alan From igor.ignatyev at oracle.com Fri Sep 4 20:22:13 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 4 Sep 2020 13:22:13 -0700 Subject: RFR(S) : 8252522 : nsk/share/test/StressOptions should multiple stressTime by jtreg's timeout-factor In-Reply-To: <01cb34eb-e5f0-8b1d-9ac1-fd5cbdcf9aff@oracle.com> References: <1DC46B2B-E923-4847-8005-76091A1775CD@oracle.com> <01cb34eb-e5f0-8b1d-9ac1-fd5cbdcf9aff@oracle.com> Message-ID: <2DC60034-9345-4C46-818B-CCAE93BF6BFB@oracle.com> Hi David, > On Aug 30, 2020, at 9:24 PM, David Holmes wrote: > > Hi Igor, > > On 29/08/2020 5:32 am, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8252522/webrev.01/ >>> 118 lines changed: 32 ins; 36 del; 50 mod; >> Hi all, >> could you please review this small patch which updates StressOptions to adjust allocated time according to TIMEOUT_FACTOR? >> from JBS: >>> nsk/share/test/StressOptions and Stresser aren't aware of jtreg's timeout-factor and hence don't provide enough stress time for testing in slow/stress configurations, e.g. Xcomp. >> the patch also includes small clean up and refactoring, such as removal of unused c-tor and using switch instead if-elif. webrev w/o these changes -- http://cr.openjdk.java.net/~iignatyev/8252522/webrev.00/ > > Both webrevs seem to be the same. > not sure how that happened. > But the changes seem fine. thanks for your review, the testing showed that tests which use vmTestbase/nsk/share/jvmti/Injector started to fail w/ this patch b/c of the switch statement being introduced in StressOptions. so I've decided to revert that part of refactoring: - http://cr.openjdk.java.net/~iignatyev/8252522/webrev.1-2 (diff) - http://cr.openjdk.java.net/~iignatyev/8252522/webrev.02 (full) just to be on the safe side, I'm rerunning the testing. -- Igor > > Thanks, > David > >> webrev: http://cr.openjdk.java.net/~iignatyev/8252522/webrev.01/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8252522 >> testing: vmTestbase tests (in progress) >> Thanks, >> -- Igor From aleksei.voitylov at bell-sw.com Fri Sep 4 20:55:41 2020 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Fri, 4 Sep 2020 23:55:41 +0300 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: <5f68767a-67cd-e788-7765-45f6ec78462e@bell-sw.com> References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> <5e0cc7c5-224f-97fc-7ceb-992a19630f4c@oracle.com> <99c52389-4df8-17ae-e29c-bcb16ce1dc23@bell-sw.com> <0ae99863-f6b1-6b14-b896-b8ed4fb7b1a5@oracle.com> <5f68767a-67cd-e788-7765-45f6ec78462e@bell-sw.com> Message-ID: Alan, here is a simpler version which, for the two tests in question, refers to a local helper class with a native method: http://cr.openjdk.java.net/~avoitylov/webrev.8247589.07/ If there is a preference to avoid JNI, there is yet another alternative: split the two launcher tests in question into tests? with @requires vm.musl | os.family = "aix" and with @requires !vm.musl & os.family != "aix". -Aleksei On 04/09/2020 15:51, Aleksei Voitylov wrote: > Alan, > > in this case I'm leaning towards a new class jdk.test.lib.LibcHelper > with a native implementation which calls (*env)->NewStringUTF(env, > libc), which will be used by the tests which require it. Otherwise we'd > have to specify nativepath for all tests which use > jdk.test.lib.Platform. What do you think? > > -Aleksei > > On 04/09/2020 12:08, Alan Bateman wrote: >> On 04/09/2020 10:00, Alan Bateman wrote: >>> On 04/09/2020 08:55, Aleksei Voitylov wrote: >>>> : >>>> Tests tools/launcher/Test7029048.java and >>>> tools/launcher/ExecutionEnvironment.java need to change behavior on >>>> systems that alter LD_LIBRARY_PATH (AIX and musl). The alternative we >>>> first considered was to detect the libc of the OS with ldd in the test >>>> and avoid WhiteBox dependency. This approach has a significant >>>> drawback: >>>> some distributions bundle glibc and OpenJDK and launch it on a >>>> musl-based Linux OS, so we really need to detect the libc the JDK was >>>> compiled for, not the default libc present in the OS. To avoid such >>>> problems all together it was decided to detect the libc flavor the JDK >>>> was compiled for through WhiteBox. >>>> >>> I really dislike the changes to the launcher tests and I don't think >>> the WB API is the right place for this. I think we need to find >>> something cleaner and maybe expose it as a method on >>> jdk.test.lib.Platform. >>> >> or alternatively, a new class in jdk.test.lib that gives provide >> methods to introspect the runtime, whatever is simplest and doesn't >> depend on the WB API as it's independent of HotSpot. >> >> -Alan From Alan.Bateman at oracle.com Sun Sep 6 08:13:24 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 6 Sep 2020 09:13:24 +0100 Subject: RFC: 8229469 JEP 386: Alpine Linux/x64 Port In-Reply-To: References: <40cb3355-a80d-afec-c458-d6b306d09a05@bell-sw.com> <5e0cc7c5-224f-97fc-7ceb-992a19630f4c@oracle.com> <99c52389-4df8-17ae-e29c-bcb16ce1dc23@bell-sw.com> <0ae99863-f6b1-6b14-b896-b8ed4fb7b1a5@oracle.com> <5f68767a-67cd-e788-7765-45f6ec78462e@bell-sw.com> Message-ID: <3bb90ff9-61b5-0bb2-0476-4d52d4c8766d@oracle.com> On 04/09/2020 21:55, Aleksei Voitylov wrote: > Alan, > > here is a simpler version which, for the two tests in question, refers > to a local helper class with a native method: > > http://cr.openjdk.java.net/~avoitylov/webrev.8247589.07/ > > If there is a preference to avoid JNI, there is yet another alternative: > split the two launcher tests in question into tests? with @requires > vm.musl | os.family = "aix" and with @requires !vm.musl & os.family != > "aix". > The download side of using JNI in these tests is that it complicates the setup a bit for those that run jtreg directly and/or just build the JDK and not the test libraries. You could reduce this burden a bit by limiting the load library/isMusl check to Linux only, meaning isMusl would not be called on other platforms. The alternative you suggest above might indeed be better. I assume you don't mean splitting the tests but rather just adding a second @test description so that the vm.musl case runs the test with a system property that allows the test know the expected load library path behavior. The updated comment in java_md.c in this looks good. A minor comment on Platform.isBusybox is Files.isSymbolicLink returning true implies that the link exists so no need to check for exists too. Also the if-then-else style for the new class in ProcessBuilder/Basic.java is inconsistent with the rest of the test so it stands out. Given the repo transition this weekend then I assume you'll create a PR for the final review at least. Also I see JEP 386 hasn't been targeted yet but I assume Boris, as owner, will propose-to-target and wait for it to be targeted before it is integrated. -Alan From kim.barrett at oracle.com Sun Sep 6 11:30:09 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 6 Sep 2020 07:30:09 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <87sgbxhiao.fsf@oldenburg2.str.redhat.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> <87sgbxhiao.fsf@oldenburg2.str.redhat.com> Message-ID: <387538C2-0BE8-43BB-9EF6-DE94786E5CD6@oracle.com> > On Sep 4, 2020, at 7:50 AM, Florian Weimer wrote: > > * Daniel Fuchs: > >> Hi, >> >> On 02/09/2020 08:19, Florian Weimer wrote: >>> At least one of the bugs was in theory user-visible: the network >>> interface code would return data for an interface that does not actually >>> exist on the system. >> >> WRT NetworkInterface.c, I might support using `strnlen` to check >> the length before hand, if that solves both cases (gcc8 and gcc10). >> I'm always a bit nervous of changing the behavior in this library >> as it's hard to verify that no regression is introduced. > > I think you should use strlen. If the string is longer than the buffer > sent to the kernel, it cannot match an existing interface because all > the names are shorter. So some sort of ?not found? error needs to > reported. That may be, but I think doing so probably won't do anything to address the -Wstringop-truncation warnings. > (I assume that it's actually a bug that you can look up a network > interface by a name that merely shares the same prefix with an actual > interface on the system.) > > Thanks, > Florian From kim.barrett at oracle.com Sun Sep 6 11:35:40 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 6 Sep 2020 07:35:40 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: > On Sep 1, 2020, at 9:59 AM, Eric Liu wrote: > I just tested this patch by GCC (10.1.0) and it would really re-trigger those warnings :( > I have not noticed the history before, but it's really hard to imagine that GCC would > have different behaviors. Can you be (very) specific about this. Do all of these changes cause gcc10 to warn? Or do only some of them. If only some, specifically which ones? I have a conjecture about some of them (see below). (I should probably try this myself; I know we have done some testing with gcc10, but I don?t remember where to find that devkit.) ------------------------------------------------------------------------------ src/java.base/unix/native/libnet/NetworkInterface.c 232 strncpy(searchName, name_utf, IFNAMESIZE - 1); A better solution here would be to eliminate the strncpy entirely. The strncpy is used to make a copy of a string so the copy can be searched for a colon, and if one is found, terminate the string there. But there's no need to make such a copy. The string being copied is the local temporary string name_utf. We could instead use name_utf everywhere searchName is currently used, including clobbering the first colon to NUL. We'd have to undo that before the later loop at line 249, but we have the information needed to do so. ------------------------------------------------------------------------------ src/java.base/unix/native/libnet/NetworkInterface.c 1298 memset((char *)&if2, 0, sizeof(if2)); 1299 strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1); 1300 if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; (in getIndex) So gcc8 does not warn about this, but gcc10 does? That would be a regression in gcc10 (and should be reported as such), because the documentation for -Wstringop-truncate is clear that the above is the proper idiom for avoiding the warning. Regardless, the memset on 1298 is useless. The code from before JDK-8250863 was the memset then the strncpy with sizeof(if2.ifr_name)-1 as the bound, which worked because the memset would have zeroed the last element. The change for JDK-8250863 did not follow the documented idiom though. It would be interesting to find out if removal of the memset changes anything. It's barely conceivable that it's confusing the heuristics used to decide whether -Wstringop-truncation should trigger. For example, the compiler might decide that the subsequent assignment of the last element is unnecessary because of the memset and optimize the assignment away, removing the idiomatic warning suppression. If gcc10 still warns about the above after removing the memset then I see little recourse but to use PRAGMA_STRINGOP_TRUNCATION_IGNORED here. Similarly for the strncpy in getFlags: 1362 memset((char *)&if2, 0, sizeof(if2)); 1363 strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1); 1364 if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; ------------------------------------------------------------------------------ src/java.base/unix/native/libnet/NetworkInterface.c 937 strncpy(name, if_name, IFNAMESIZE - 1); 938 name[IFNAMESIZE - 1] = '\0'; gcc10 presumably did not complain about the old version here, and this was not touched as part of JDK-8250863. Does gcc10 complain about this new version? If so, then I see little recoarse but to use PRAGMA_STRINGOP_TRUNCATION_IGNORED here, because a gcc10 warning here is contrary to the documentation. ------------------------------------------------------------------------------ src/hotspot/share/compiler/compileBroker.hpp 64 PRAGMA_DIAG_PUSH 65 PRAGMA_STRINGOP_TRUNCATION_IGNORED 66 // This code can incorrectly cause a "stringop-truncation" warning with gcc 67 strncpy(_current_method, method, (size_t)cmname_buffer_length-1); 68 PRAGMA_DIAG_POP 69 _current_method[cmname_buffer_length-1] = '\0'; I think I'd prefer the PRAGMA_DIAG_POP moved one line further down, so that the push/pop surrounds the entire idiomactic usage that is supposed to prevent the warning. This seems to be a gcc8 bug. gcc10 doesn't warn about this (and shouldn't). It would be interesting to know if it too warns with --enable-asan. ------------------------------------------------------------------------------ src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c est/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp These changes look good, as they follow the documented idiom for suppressing -Wstringop-truncation. Does gcc10 warn after these changes? ------------------------------------------------------------------------------ test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/libInheritedChannel.c (In Java_UnixDomainSocket_bind0) 234 memset(&addr, 0, sizeof(addr)); 235 addr.sun_family = AF_UNIX; 236 strncpy(addr.sun_path, nameUtf, length - 1); 237 addr.sun_path[length - 1] = '\0'; (In Java_UnixDomainSocket_connect0) 267 memset(&addr, 0, sizeof(addr)); 268 addr.sun_family = AF_UNIX; 269 strncpy(addr.sun_path, nameUtf, length - 1); 270 addr.sun_path[length - 1] = '\0'; These changes look good, as they follow the documented idiom for suppressing -Wstringop-truncation. Does gcc10 warn after these changes? Per the discussion above about getIndex in NetworkInterface.c, does removing the memsets change that? The memsets seem entirely unnecessary, since we're filling in all (both) members. ------------------------------------------------------------------------------ From david.holmes at oracle.com Sun Sep 6 13:32:49 2020 From: david.holmes at oracle.com (David Holmes) Date: Sun, 6 Sep 2020 23:32:49 +1000 Subject: RFR(S) : 8252522 : nsk/share/test/StressOptions should multiple stressTime by jtreg's timeout-factor In-Reply-To: <2DC60034-9345-4C46-818B-CCAE93BF6BFB@oracle.com> References: <1DC46B2B-E923-4847-8005-76091A1775CD@oracle.com> <01cb34eb-e5f0-8b1d-9ac1-fd5cbdcf9aff@oracle.com> <2DC60034-9345-4C46-818B-CCAE93BF6BFB@oracle.com> Message-ID: <7abd185b-96f8-4d60-b359-45b061a361dd@oracle.com> Hi Igor, On 5/09/2020 6:22 am, Igor Ignatyev wrote: > Hi David, > > >> On Aug 30, 2020, at 9:24 PM, David Holmes > > wrote: >> >> Hi Igor, >> >> On 29/08/2020 5:32 am, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev/8252522/webrev.01/ >>>> 118 lines changed: 32 ins; 36 del; 50 mod; >>> Hi all, >>> could you please review this small patch which updates StressOptions >>> to adjust allocated time according to TIMEOUT_FACTOR? >>> from JBS: >>>> nsk/share/test/StressOptions and Stresser aren't aware of jtreg's >>>> timeout-factor and hence don't provide enough stress time for >>>> testing in slow/stress configurations, e.g. Xcomp. >>> the patch also includes small clean up and refactoring, such as >>> removal of unused c-tor and using switch instead if-elif. webrev w/o >>> these changes -- http://cr.openjdk.java.net/~iignatyev/8252522/webrev.00/ >> >> Both webrevs seem to be the same. >> > not sure how that happened. >> But the changes seem fine. > > thanks for your review, the testing showed that tests which use > vmTestbase/nsk/share/jvmti/Injector started to fail w/ this patch b/c of > the switch statement being introduced in StressOptions. so I've decided > to revert that part of refactoring: > ?- http://cr.openjdk.java.net/~iignatyev/8252522/webrev.1-2?(diff) > ?- http://cr.openjdk.java.net/~iignatyev/8252522/webrev.02?(full) Reversion seems fine, but I don't understand why the change would have caused failures? I cause this will need a PR now. Cheers, David > just to be on the safe side, I'm rerunning the testing. > > -- Igor > >> >> Thanks, >> David >> >>> webrev: http://cr.openjdk.java.net/~iignatyev/8252522/webrev.01/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8252522 >>> testing: vmTestbase tests (in progress) >>> Thanks, >>> -- Igor > From igor.ignatyev at oracle.com Sun Sep 6 16:20:11 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sun, 6 Sep 2020 09:20:11 -0700 Subject: RFR(S) : 8252522 : nsk/share/test/StressOptions should multiple stressTime by jtreg's timeout-factor In-Reply-To: <7abd185b-96f8-4d60-b359-45b061a361dd@oracle.com> References: <1DC46B2B-E923-4847-8005-76091A1775CD@oracle.com> <01cb34eb-e5f0-8b1d-9ac1-fd5cbdcf9aff@oracle.com> <2DC60034-9345-4C46-818B-CCAE93BF6BFB@oracle.com> <7abd185b-96f8-4d60-b359-45b061a361dd@oracle.com> Message-ID: <75480DA4-C8D1-432B-99ED-A09802471C5A@oracle.com> > On Sep 6, 2020, at 6:32 AM, David Holmes wrote: > > Hi Igor, > > On 5/09/2020 6:22 am, Igor Ignatyev wrote: >> Hi David, >>> On Aug 30, 2020, at 9:24 PM, David Holmes >> wrote: >>> >>> Hi Igor, >>> >>> On 29/08/2020 5:32 am, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev/8252522/webrev.01/ >>>>> 118 lines changed: 32 ins; 36 del; 50 mod; >>>> Hi all, >>>> could you please review this small patch which updates StressOptions to adjust allocated time according to TIMEOUT_FACTOR? >>>> from JBS: >>>>> nsk/share/test/StressOptions and Stresser aren't aware of jtreg's timeout-factor and hence don't provide enough stress time for testing in slow/stress configurations, e.g. Xcomp. >>>> the patch also includes small clean up and refactoring, such as removal of unused c-tor and using switch instead if-elif. webrev w/o these changes -- http://cr.openjdk.java.net/~iignatyev/8252522/webrev.00/ >>> >>> Both webrevs seem to be the same. >>> >> not sure how that happened. >>> But the changes seem fine. >> thanks for your review, the testing showed that tests which use vmTestbase/nsk/share/jvmti/Injector started to fail w/ this patch b/c of the switch statement being introduced in StressOptions. so I've decided to revert that part of refactoring: >> - http://cr.openjdk.java.net/~iignatyev/8252522/webrev.1-2 (diff) >> - http://cr.openjdk.java.net/~iignatyev/8252522/webrev.02 (full) > > Reversion seems fine, but I don't understand why the change would have caused failures? frankly speaking, neither do I. I'll file an issue and look into it later. > > I cause this will need a PR now. yup, I've already created and integrated the PR. > > Cheers, > David > >> just to be on the safe side, I'm rerunning the testing. >> -- Igor >>> >>> Thanks, >>> David >>> >>>> webrev: http://cr.openjdk.java.net/~iignatyev/8252522/webrev.01/ >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8252522 >>>> testing: vmTestbase tests (in progress) >>>> Thanks, >>>> -- Igor From iignatyev at openjdk.java.net Sun Sep 6 16:21:03 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sun, 6 Sep 2020 16:21:03 GMT Subject: Integrated: 8252522: nsk/share/test/StressOptions should multiple stressTime by jtreg's timeout-factor Message-ID: pre-skara ear RFR threads: [Aug](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-August/042790.html), [Sep](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042877.html) > Hi all, > > could you please review this small patch which updates StressOptions to adjust allocated time according to > TIMEOUT_FACTOR? > from [JBS](https://bugs.openjdk.java.net/browse/JDK-8252522): > > nsk/share/test/StressOptions and Stresser aren't aware of jtreg's timeout-factor and hence don't provide enough stress > > time for testing in slow/stress configurations, e.g. Xcomp. ------------- Commit messages: - 8252522: nsk/share/test/StressOptions should multiple stressTime by jtreg's timeout-factor Changes: https://git.openjdk.java.net/jdk/pull/32/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=32&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252522 Stats: 31 lines in 1 file changed: 2 ins; 12 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/32.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/32/head:pull/32 PR: https://git.openjdk.java.net/jdk/pull/32 From iignatyev at openjdk.java.net Sun Sep 6 16:21:03 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sun, 6 Sep 2020 16:21:03 GMT Subject: Integrated: 8252522: nsk/share/test/StressOptions should multiple stressTime by jtreg's timeout-factor In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 16:09:04 GMT, Igor Ignatyev wrote: > pre-skara ear RFR threads: [Aug](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-August/042790.html), > [Sep](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042877.html) >> Hi all, >> >> could you please review this small patch which updates StressOptions to adjust allocated time according to >> TIMEOUT_FACTOR? >> from [JBS](https://bugs.openjdk.java.net/browse/JDK-8252522): >> > nsk/share/test/StressOptions and Stresser aren't aware of jtreg's timeout-factor and hence don't provide enough stress >> > time for testing in slow/stress configurations, e.g. Xcomp. This pull request has now been integrated. Changeset: 5f76deb2 Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk/commit/5f76deb2 Stats: 32 lines in 1 file changed: 13 ins; 3 del; 16 mod 8252522: nsk/share/test/StressOptions should multiple stressTime by jtreg's timeout-factor Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/32 From fweimer at redhat.com Sun Sep 6 17:03:55 2020 From: fweimer at redhat.com (Florian Weimer) Date: Sun, 06 Sep 2020 19:03:55 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <387538C2-0BE8-43BB-9EF6-DE94786E5CD6@oracle.com> (Kim Barrett's message of "Sun, 6 Sep 2020 07:30:09 -0400") References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> <87sgbxhiao.fsf@oldenburg2.str.redhat.com> <387538C2-0BE8-43BB-9EF6-DE94786E5CD6@oracle.com> Message-ID: <87sgbuet1g.fsf@oldenburg2.str.redhat.com> * Kim Barrett: >> On Sep 4, 2020, at 7:50 AM, Florian Weimer wrote: >> >> * Daniel Fuchs: >> >>> Hi, >>> >>> On 02/09/2020 08:19, Florian Weimer wrote: >>>> At least one of the bugs was in theory user-visible: the network >>>> interface code would return data for an interface that does not actually >>>> exist on the system. >>> >>> WRT NetworkInterface.c, I might support using `strnlen` to check >>> the length before hand, if that solves both cases (gcc8 and gcc10). >>> I'm always a bit nervous of changing the behavior in this library >>> as it's hard to verify that no regression is introduced. >> >> I think you should use strlen. If the string is longer than the buffer >> sent to the kernel, it cannot match an existing interface because all >> the names are shorter. So some sort of ?not found? error needs to >> reported. > > That may be, but I think doing so probably won't do anything to > address the -Wstringop-truncation warnings. There is no reason to use strncpy. At least on Linux, the struct field needs to be null-terminated, and you need to compute the length for the length check. So you might as well use memcpy with the length plus one (to copy the null terminator). You can keep using strncpy, and the warning should be gone (because GCC will recognize a dominating strlen check), but it's not necessary. On current GNU/Linux, the most common structs now have the appropriate annotations, so you get the strncpy warnings only in cases where there is an actual truncation bug. Thanks, Florian From david.holmes at oracle.com Sun Sep 6 23:08:00 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Sep 2020 09:08:00 +1000 Subject: RFR(S) : 8252522 : nsk/share/test/StressOptions should multiple stressTime by jtreg's timeout-factor In-Reply-To: <75480DA4-C8D1-432B-99ED-A09802471C5A@oracle.com> References: <1DC46B2B-E923-4847-8005-76091A1775CD@oracle.com> <01cb34eb-e5f0-8b1d-9ac1-fd5cbdcf9aff@oracle.com> <2DC60034-9345-4C46-818B-CCAE93BF6BFB@oracle.com> <7abd185b-96f8-4d60-b359-45b061a361dd@oracle.com> <75480DA4-C8D1-432B-99ED-A09802471C5A@oracle.com> Message-ID: Hi Igor, On 7/09/2020 2:20 am, Igor Ignatyev wrote: > > >> On Sep 6, 2020, at 6:32 AM, David Holmes > > wrote: >> >> Hi Igor, >> >> On 5/09/2020 6:22 am, Igor Ignatyev wrote: >>> Hi David, >>>> On Aug 30, 2020, at 9:24 PM, David Holmes >>> > wrote: >>>> >>>> Hi Igor, >>>> >>>> On 29/08/2020 5:32 am, Igor Ignatyev wrote: >>>>> http://cr.openjdk.java.net/~iignatyev/8252522/webrev.01/ >>>>>> 118 lines changed: 32 ins; 36 del; 50 mod; >>>>> Hi all, >>>>> could you please review this small patch which updates >>>>> StressOptions to adjust allocated time according to TIMEOUT_FACTOR? >>>>> from JBS: >>>>>> nsk/share/test/StressOptions and Stresser aren't aware of jtreg's >>>>>> timeout-factor and hence don't provide enough stress time for >>>>>> testing in slow/stress configurations, e.g. Xcomp. >>>>> the patch also includes small clean up and refactoring, such as >>>>> removal of unused c-tor and using switch instead if-elif. webrev >>>>> w/o these changes -- >>>>> http://cr.openjdk.java.net/~iignatyev/8252522/webrev.00/ >>>> >>>> Both webrevs seem to be the same. >>>> >>> not sure how that happened. >>>> But the changes seem fine. >>> thanks for your review, the testing showed that tests which use >>> vmTestbase/nsk/share/jvmti/Injector started to fail w/ this patch b/c >>> of the switch statement being introduced in StressOptions. so I've >>> decided to revert that part of refactoring: >>> ?- http://cr.openjdk.java.net/~iignatyev/8252522/webrev.1-2?(diff) >>> ?- http://cr.openjdk.java.net/~iignatyev/8252522/webrev.02?(full) >> >> Reversion seems fine, but I don't understand why the change would have >> caused failures? > frankly speaking, neither do I. I'll file an issue and look into it later. >> >> I cause this will need a PR now. > yup, I've already created and integrated the PR. Not quite the way I expected it to happen. I had assumed the PR would start things from scratch and I would indicate my review as part of the PR. :) I see you found a way to short-circuit the cutover process. Cheers, David ----- >> >> Cheers, >> David >> >>> just to be on the safe side, I'm rerunning the testing. >>> -- Igor >>>> >>>> Thanks, >>>> David >>>> >>>>> webrev:http://cr.openjdk.java.net/~iignatyev/8252522/webrev.01/ >>>>> JBS:https://bugs.openjdk.java.net/browse/JDK-8252522 >>>>> testing: vmTestbase tests (in progress) >>>>> Thanks, >>>>> -- Igor > From kim.barrett at oracle.com Mon Sep 7 01:49:48 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 6 Sep 2020 21:49:48 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: <63FFE48F-03C1-4F2E-9ECE-8C3303C6AF8F@oracle.com> > On Sep 6, 2020, at 7:35 AM, Kim Barrett wrote: > src/hotspot/share/compiler/compileBroker.hpp > 64 PRAGMA_DIAG_PUSH > 65 PRAGMA_STRINGOP_TRUNCATION_IGNORED > 66 // This code can incorrectly cause a "stringop-truncation" warning with gcc > 67 strncpy(_current_method, method, (size_t)cmname_buffer_length-1); > 68 PRAGMA_DIAG_POP > 69 _current_method[cmname_buffer_length-1] = '\0'; > > I think I'd prefer the PRAGMA_DIAG_POP moved one line further down, so > that the push/pop surrounds the entire idiomactic usage that is > supposed to prevent the warning. This seems to be a gcc8 bug. > > gcc10 doesn't warn about this (and shouldn't). It would be > interesting to know if it too warns with --enable-asan. I keep forgetting. This is the one where we think the cast on line 67 might be confusing gcc8, and if it were eliminated we might not need the PRAGMA dance here after all. From kim.barrett at oracle.com Mon Sep 7 01:51:06 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 6 Sep 2020 21:51:06 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: <47D04DC0-DF34-49D4-B901-5544BEFB09BB@oracle.com> > On Sep 6, 2020, at 7:35 AM, Kim Barrett wrote: > src/java.base/unix/native/libnet/NetworkInterface.c > 1298 memset((char *)&if2, 0, sizeof(if2)); > 1299 strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1); > 1300 if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; > > (in getIndex) > > So gcc8 does not warn about this, but gcc10 does? That would be a > regression in gcc10 (and should be reported as such), because the > documentation for -Wstringop-truncate is clear that the above is the > proper idiom for avoiding the warning. > > Regardless, the memset on 1298 is useless. The code from before > JDK-8250863 was the memset then the strncpy with > sizeof(if2.ifr_name)-1 as the bound, which worked because the memset > would have zeroed the last element. > > The change for JDK-8250863 did not follow the documented idiom though. > > It would be interesting to find out if removal of the memset changes > anything. It's barely conceivable that it's confusing the heuristics > used to decide whether -Wstringop-truncation should trigger. For > example, the compiler might decide that the subsequent assignment of > the last element is unnecessary because of the memset and optimize the > assignment away, removing the idiomatic warning suppression. > > If gcc10 still warns about the above after removing the memset then I > see little recourse but to use PRAGMA_STRINGOP_TRUNCATION_IGNORED here. I found a gcc10.2 devkit that I could take for a spin with Eric's patches. I got -Wstringop-truncation warnings in NetworkInterface.c, in getIndex and getFlags. Removing the immediately preceeding memset removed those warnings. (Note that in these two cases the memset is otherwise completely superfluous, both before and after Eric's changes.) Strangely, there are other places in this file where a strncpy is preceeded by a memcpy and there is no assignment of the last element to NUL, but which no version of gcc seems to complain about. Examples include getMacAddress, getMTU, enumIPv6Interfaces. Oh, good grief! This file contains 3 identical copies of getMTU and getFlags, one each for linux, AIX, and BSD. And getIndex is kind of a mess. If changing any of these for linux, probably similar changes ought to be applied to the other copies to keep things in sync. After removing the superfluous memsets from getIndex and getFlags, my test build with gcc10.2 completed successfully with Eric's patches. From kim.barrett at oracle.com Mon Sep 7 02:19:05 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 6 Sep 2020 22:19:05 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <87sgbuet1g.fsf@oldenburg2.str.redhat.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> <87sgbxhiao.fsf@oldenburg2.str.redhat.com> <387538C2-0BE8-43BB-9EF6-DE94786E5CD6@oracle.com> <87sgbuet1g.fsf@oldenburg2.str.redhat.com> Message-ID: <211FC028-8CE8-4296-BEC5-BE927558BDA0@oracle.com> > On Sep 6, 2020, at 1:03 PM, Florian Weimer wrote: > There is no reason to use strncpy. At least on Linux, the struct field > needs to be null-terminated, and you need to compute the length for the > length check. So you might as well use memcpy with the length plus one > (to copy the null terminator). You can keep using strncpy, and the > warning should be gone (because GCC will recognize a dominating strlen > check), but it's not necessary. > > On current GNU/Linux, the most common structs now have the appropriate > annotations, so you get the strncpy warnings only in cases where there > is an actual truncation bug. [Keep in mind that gcc on recent GNU/Linux is not the only platform this code base needs to worry about. Though it is the one that is driving us a bit batty with its varying warnings here.] I'm not sure whether you are suggesting one should never use strncpy anywhere, or whether there is some specific place(s) from this webrev you are suggesting it should be avoided? I agree there are some uses of strncpy that look at least somewhat suspect. Without further analysis it's hard to know whether there is really a problem with truncation (can it occur at all, and is it a problem if it does). Figuring that out seems somewhat beyond the scope of what this change is trying to do. Please file bugs about problematic uses. (A bug of the form "don't use strncpy" might not get quick action.) And strlen is not even necessarily the best solution, as it likely introduces an additional otherwise unnecessary string traversal. For example, getFlags could be changed to reject an overly long ifname, without using strlen, thusly: strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name)); if (if2.ifr_name[sizeof(if2.ifr_name) - 1] != '\0') { return -1; } Unfortunately, gcc10 -Wstringop-truncation whines about this entirely reasonable code. From kim.barrett at oracle.com Mon Sep 7 02:36:33 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 6 Sep 2020 22:36:33 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <47D04DC0-DF34-49D4-B901-5544BEFB09BB@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <47D04DC0-DF34-49D4-B901-5544BEFB09BB@oracle.com> Message-ID: > On Sep 6, 2020, at 9:51 PM, Kim Barrett wrote: > Oh, good grief! This file contains 3 identical copies of getMTU and > getFlags, one each for linux, AIX, and BSD. And getIndex is kind of a > mess. If changing any of these for linux, probably similar changes > ought to be applied to the other copies to keep things in sync. Is there any reason the linux version of getIndex couldn?t be changed to use if_nametoindex (like the AIX version)? That would eliminate one of the cases that is causing problems. From clanger at openjdk.java.net Mon Sep 7 04:22:04 2020 From: clanger at openjdk.java.net (Christoph Langer) Date: Mon, 7 Sep 2020 04:22:04 GMT Subject: RFR: 8252837: Cleanup SAP Copyright file headers Message-ID: The format for SAP copyrights in OpenJDK headers should be like: Copyright (c) SAP SE. All rights reserved. or Copyright (c) , SAP SE. All rights reserved. There should not be a comma character (",") before "SAP SE". This is inconsistent in some files which calls for some cleanup. Please review :) ------------- Commit messages: - 8252837: Cleanup SAP Copyright file headers Changes: https://git.openjdk.java.net/jdk/pull/36/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=36&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252837 Stats: 55 lines in 55 files changed: 0 ins; 0 del; 55 mod Patch: https://git.openjdk.java.net/jdk/pull/36.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/36/head:pull/36 PR: https://git.openjdk.java.net/jdk/pull/36 From goetz.lindenmaier at sap.com Mon Sep 7 06:19:56 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 7 Sep 2020 06:19:56 +0000 Subject: RFR: 8252837: Cleanup SAP Copyright file headers In-Reply-To: References: Message-ID: Hi Christoph, Looks good to me ?? Best regards, Goetz. -----Original Message----- From: nio-dev On Behalf Of Christoph Langer Sent: Montag, 7. September 2020 06:22 To: hotspot-dev at openjdk.java.net; net-dev at openjdk.java.net; nio-dev at openjdk.java.net; serviceability-dev at openjdk.java.net Subject: RFR: 8252837: Cleanup SAP Copyright file headers The format for SAP copyrights in OpenJDK headers should be like: Copyright (c) SAP SE. All rights reserved. or Copyright (c) , SAP SE. All rights reserved. There should not be a comma character (",") before "SAP SE". This is inconsistent in some files which calls for some cleanup. Please review :) ------------- Commit messages: - 8252837: Cleanup SAP Copyright file headers Changes: https://git.openjdk.java.net/jdk/pull/36/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=36&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252837 Stats: 55 lines in 55 files changed: 0 ins; 0 del; 55 mod Patch: https://git.openjdk.java.net/jdk/pull/36.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/36/head:pull/36 PR: https://git.openjdk.java.net/jdk/pull/36 From david.holmes at oracle.com Mon Sep 7 07:17:13 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Sep 2020 17:17:13 +1000 Subject: RFR: 8252837: Cleanup SAP Copyright file headers In-Reply-To: References: Message-ID: Looks good to me - and trivial. Thanks, David On 7/09/2020 2:22 pm, Christoph Langer wrote: > The format for SAP copyrights in OpenJDK headers should be like: > Copyright (c) SAP SE. All rights reserved. > or > Copyright (c) , SAP SE. All rights reserved. > > There should not be a comma character (",") before "SAP SE". > > This is inconsistent in some files which calls for some cleanup. > > Please review :) > > ------------- > > Commit messages: > - 8252837: Cleanup SAP Copyright file headers > > Changes: https://git.openjdk.java.net/jdk/pull/36/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=36&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8252837 > Stats: 55 lines in 55 files changed: 0 ins; 0 del; 55 mod > Patch: https://git.openjdk.java.net/jdk/pull/36.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/36/head:pull/36 > > PR: https://git.openjdk.java.net/jdk/pull/36 > From cgo at openjdk.java.net Mon Sep 7 07:33:37 2020 From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=) Date: Mon, 7 Sep 2020 07:33:37 GMT Subject: RFR: 8252500: ZGC on aarch64: Unable to allocate heap for certain Linux kernel configurations Message-ID: The patch introduces a new function to probe for the highest valid bit in the virtual address space for userspace programs on Linux. I guarded the whole implementation to only probe on Linux, other platforms will remain unaffected. Possibly, it would be nicer to move the probing code into an OS+ARCH specific source file. But since this is only a single function, I thought it would be better to put it right next to the caller and guard it with an #ifdef LINUX. The probing mechanism uses a combination of msync + mmap, to first check if the address is valid using msync (if msync succeeds, the address was valid). If msync fails, mmap is used to check if msync failed because the memory wasn't mapped, or if it failed because the address is invalid. Due to some undefined behavior (documented in the msync man page), I also use a single mmap at the end, if the msync approach failed before. I tested msync with different combinations of mappings, and also with sbrk, and it always succeeded, or failed with ENOMEM. I never got back any other error code. The specified minimum value has been chosen "randomly". The JVM terminates (unable to allocate heap), if this minimum value is smaller than the requested Java Heap size, so it might be better to make the minimum dependent on the MaxHeapSize and not a compile time constant? I didn't want to make the minimum too big, since for aarch64 on Linux, the documented minimum would be 38 (see [1]). I avoided MAP_FIXED_NOREPLACE, because according to the man page, it has been added in Linux 4.17. There are still plenty of stable kernel versions around which will not have that feature, which means we need to implement a workaround for it. Some of my test devices also have a kernel version lower than that. I executed the HotSpot tier1 JTreg tests on two different aarch64 devices. One with 4KB pages and 3 page levels and the other with 4KB pages and 4 page levels. Tests passed on both devices. [1] https://www.kernel.org/doc/Documentation/arm64/memory.txt ------------- Commit messages: - 8252500: ZGC on aarch64: Unable to allocate heap for certain Linux kernel configurations Changes: https://git.openjdk.java.net/jdk/pull/40/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=40&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252500 Stats: 62 lines in 1 file changed: 60 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/40.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/40/head:pull/40 PR: https://git.openjdk.java.net/jdk/pull/40 From clanger at openjdk.java.net Mon Sep 7 07:34:23 2020 From: clanger at openjdk.java.net (Christoph Langer) Date: Mon, 7 Sep 2020 07:34:23 GMT Subject: RFR: 8252837: Cleanup SAP Copyright file headers In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 07:25:41 GMT, David Holmes wrote: >> The format for SAP copyrights in OpenJDK headers should be like: >> Copyright (c) SAP SE. All rights reserved. >> or >> Copyright (c) , SAP SE. All rights reserved. >> >> There should not be a comma character (",") before "SAP SE". >> >> This is inconsistent in some files which calls for some cleanup. >> >> Please review :) > > Marked as reviewed by dholmes (Reviewer). > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on > [nio-dev](mailto:nio-dev at openjdk.java.net):_ > Looks good to me - and trivial. > > Thanks, > David > > On 7/09/2020 2:22 pm, Christoph Langer wrote: Thanks, David! ------------- PR: https://git.openjdk.java.net/jdk/pull/36 From dholmes at openjdk.java.net Mon Sep 7 07:34:23 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 7 Sep 2020 07:34:23 GMT Subject: RFR: 8252837: Cleanup SAP Copyright file headers In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 04:14:06 GMT, Christoph Langer wrote: > The format for SAP copyrights in OpenJDK headers should be like: > Copyright (c) SAP SE. All rights reserved. > or > Copyright (c) , SAP SE. All rights reserved. > > There should not be a comma character (",") before "SAP SE". > > This is inconsistent in some files which calls for some cleanup. > > Please review :) Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/36 From dholmes at openjdk.java.net Mon Sep 7 07:34:24 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 7 Sep 2020 07:34:24 GMT Subject: RFR: 8252837: Cleanup SAP Copyright file headers In-Reply-To: <92QNtmcIFJs6sayq_eDy440L-mer93dWgHUu2OiBvu0=.b627cf37-40bf-4b5f-bb6d-6c1e9ad8a011@github.com> References: <92QNtmcIFJs6sayq_eDy440L-mer93dWgHUu2OiBvu0=.b627cf37-40bf-4b5f-bb6d-6c1e9ad8a011@github.com> Message-ID: On Mon, 7 Sep 2020 07:28:36 GMT, Christoph Langer wrote: >>> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on >>> [nio-dev](mailto:nio-dev at openjdk.java.net):_ >>> Looks good to me - and trivial. >>> >>> Thanks, >>> David >>> >>> On 7/09/2020 2:22 pm, Christoph Langer wrote: >> >> Thanks, David! > >> _Mailing list message from [Lindenmaier, Goetz](mailto:goetz.lindenmaier at sap.com) on >> [nio-dev](mailto:nio-dev at openjdk.java.net):_ >> Hi Christoph, >> >> Looks good to me ?? >> >> Best regards, >> Goetz. >> > Thanks, Goetz :) Note that Goetz was not officially added as a reviewer. The email was included in this PR as a comment, but he either has to add himself as a reviewer, or the PR author has to based on the email. ------------- PR: https://git.openjdk.java.net/jdk/pull/36 From clanger at openjdk.java.net Mon Sep 7 07:34:23 2020 From: clanger at openjdk.java.net (Christoph Langer) Date: Mon, 7 Sep 2020 07:34:23 GMT Subject: RFR: 8252837: Cleanup SAP Copyright file headers In-Reply-To: References: Message-ID: <92QNtmcIFJs6sayq_eDy440L-mer93dWgHUu2OiBvu0=.b627cf37-40bf-4b5f-bb6d-6c1e9ad8a011@github.com> On Mon, 7 Sep 2020 07:27:39 GMT, Christoph Langer wrote: >> Marked as reviewed by dholmes (Reviewer). > >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on >> [nio-dev](mailto:nio-dev at openjdk.java.net):_ >> Looks good to me - and trivial. >> >> Thanks, >> David >> >> On 7/09/2020 2:22 pm, Christoph Langer wrote: > > Thanks, David! > _Mailing list message from [Lindenmaier, Goetz](mailto:goetz.lindenmaier at sap.com) on > [nio-dev](mailto:nio-dev at openjdk.java.net):_ > Hi Christoph, > > Looks good to me ?? > > Best regards, > Goetz. > Thanks, Goetz :) ------------- PR: https://git.openjdk.java.net/jdk/pull/36 From clanger at openjdk.java.net Mon Sep 7 07:34:24 2020 From: clanger at openjdk.java.net (Christoph Langer) Date: Mon, 7 Sep 2020 07:34:24 GMT Subject: Integrated: 8252837: Cleanup SAP Copyright file headers In-Reply-To: References: Message-ID: <4dxuz2CMLex13-rJlTK-83x3U4y00GceUN0ZxDchdDg=.20ca2330-97da-48df-8e8e-939c777ca686@github.com> On Mon, 7 Sep 2020 04:14:06 GMT, Christoph Langer wrote: > The format for SAP copyrights in OpenJDK headers should be like: > Copyright (c) SAP SE. All rights reserved. > or > Copyright (c) , SAP SE. All rights reserved. > > There should not be a comma character (",") before "SAP SE". > > This is inconsistent in some files which calls for some cleanup. > > Please review :) This pull request has now been integrated. Changeset: cc5039e1 Author: Christoph Langer URL: https://git.openjdk.java.net/jdk/commit/cc5039e1 Stats: 55 lines in 55 files changed: 0 ins; 0 del; 55 mod 8252837: Cleanup SAP Copyright file headers Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/36 From fweimer at redhat.com Mon Sep 7 09:55:28 2020 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 07 Sep 2020 11:55:28 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <211FC028-8CE8-4296-BEC5-BE927558BDA0@oracle.com> (Kim Barrett's message of "Sun, 6 Sep 2020 22:19:05 -0400") References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> <87sgbxhiao.fsf@oldenburg2.str.redhat.com> <387538C2-0BE8-43BB-9EF6-DE94786E5CD6@oracle.com> <87sgbuet1g.fsf@oldenburg2.str.redhat.com> <211FC028-8CE8-4296-BEC5-BE927558BDA0@oracle.com> Message-ID: <87o8mh7vxr.fsf@oldenburg2.str.redhat.com> * Kim Barrett: > And strlen is not even necessarily the best solution, as it likely > introduces an additional otherwise unnecessary string traversal. For > example, getFlags could be changed to reject an overly long ifname, > without using strlen, thusly: > > strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name)); > if (if2.ifr_name[sizeof(if2.ifr_name) - 1] != '\0') { > return -1; > } > > Unfortunately, gcc10 -Wstringop-truncation whines about this entirely > reasonable code. Thanks, I filed this as: Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill From ayang at openjdk.java.net Mon Sep 7 10:59:34 2020 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 7 Sep 2020 10:59:34 GMT Subject: RFR: 8252859: Inconsistent use of alpha in class AbsSeq Message-ID: 8252859: Inconsistent use of alpha in class AbsSeq ------------- Commit messages: - alpha Changes: https://git.openjdk.java.net/jdk/pull/47/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=47&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252859 Stats: 5 lines in 3 files changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/47.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/47/head:pull/47 PR: https://git.openjdk.java.net/jdk/pull/47 From thomas.schatzl at oracle.com Mon Sep 7 11:20:39 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 7 Sep 2020 13:20:39 +0200 Subject: RFR: 8252859: Inconsistent use of alpha in class AbsSeq In-Reply-To: References: Message-ID: Hi, On 07.09.20 12:59, Albert Mingkun Yang wrote: > 8252859: Inconsistent use of alpha in class AbsSeq could you please give *some* explanation in the PR description as before? Thanks. > > ------------- > > Commit messages: > - alpha > > Changes: https://git.openjdk.java.net/jdk/pull/47/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=47&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8252859 > Stats: 5 lines in 3 files changed: 0 ins; 1 del; 4 mod > Patch: https://git.openjdk.java.net/jdk/pull/47.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/47/head:pull/47 > > PR: https://git.openjdk.java.net/jdk/pull/47 > - G1AdaptiveIHOPControl::_marking_times_s and _allocation_rate_s were not updated. - Testing? Looks good otherwise. Thanks, Thomas From ayang at openjdk.java.net Mon Sep 7 11:59:25 2020 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 7 Sep 2020 11:59:25 GMT Subject: RFR: 8252859: Inconsistent use of alpha in class AbsSeq [v2] In-Reply-To: References: Message-ID: > 8252859: Inconsistent use of alpha in class AbsSeq Albert Mingkun Yang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: alpha ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/47/files - new: https://git.openjdk.java.net/jdk/pull/47/files/347ff19b..89df9a5f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=47&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=47&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/47.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/47/head:pull/47 PR: https://git.openjdk.java.net/jdk/pull/47 From ayang at openjdk.java.net Mon Sep 7 12:06:41 2020 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 7 Sep 2020 12:06:41 GMT Subject: RFR: 8252859: Inconsistent use of alpha in class AbsSeq In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 10:53:36 GMT, Albert Mingkun Yang wrote: > Invert the meaning of `_alpha`, from `alpha` to `1-alpha`. > > Test: I instrumented the constructor of `AbsSeq` with `printf("%f\n", _alpha)` onto master and `printf("%f\n", 1.0 - > _alpha)` after the patch, and checked the output of `java --version` (G1, Parallel, Shenandoah, and Z) are the > same before and after. Thomas, thank you for the review. Updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/47 From rehn at openjdk.java.net Mon Sep 7 12:21:58 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 7 Sep 2020 12:21:58 GMT Subject: RFR: 8252794: Creation of JNIMethodBlock should be done with a leaf lock Message-ID: <4v19DvtX5ykcCzTGeQ2tJ-mrRsfwsruMMS-XE9rLPMw=.6f419fd6-2bec-4c9e-a432-16497d589264@github.com> JVM TI uses handshakes and sometimes need jmethod ids. The CLD have an area where these ids are saved, which is created on first request for an id. The creation of this area should be done with a leaf lock. In W.I.P. asynchronous handshake change-set we use a mutex instead of a semaphore for serializing the handshakes, we thus get into lock ranks asserts. The CLD metaspace lock cannot be pushed down but we can use the same lock as for creating jmethod ids: JmethodIdCreation_lock. And push that down. (special-2 is picked to be compatible with W.I.P. asynchronous handshake change-set) The reason for CLD metaspace lock being used now is that we have one per CLD instead of one global one. Testing passes: t1-3 ------------- Commit messages: - Changed and pushed down Changes: https://git.openjdk.java.net/jdk/pull/53/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=53&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252794 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/53.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/53/head:pull/53 PR: https://git.openjdk.java.net/jdk/pull/53 From eosterlund at openjdk.java.net Mon Sep 7 12:40:13 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 7 Sep 2020 12:40:13 GMT Subject: RFR: 8252661: Change SafepointMechanism terminology to talk less about "blocking" Message-ID: Migrating this review from the mailing list into a pull request. So far, the favourite terminology is to talk about "process", but without "operation". ------------- Commit messages: - 8252661: Change SafepointMechanism terminology to talk less about "blocking" Changes: https://git.openjdk.java.net/jdk/pull/54/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=54&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252661 Stats: 33 lines in 12 files changed: 0 ins; 0 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/54.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/54/head:pull/54 PR: https://git.openjdk.java.net/jdk/pull/54 From rehn at openjdk.java.net Mon Sep 7 12:48:56 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 7 Sep 2020 12:48:56 GMT Subject: RFR: 8252661: Change SafepointMechanism terminology to talk less about "blocking" In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 12:33:37 GMT, Erik ?sterlund wrote: > Migrating this review from the mailing list into a pull request. So far, the favourite terminology is to talk about > "process", but without "operation". I think we can do better than "process". I can't think anything now, so ship it. Thanks ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/54 From shade at openjdk.java.net Mon Sep 7 12:48:57 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 7 Sep 2020 12:48:57 GMT Subject: RFR: 8252661: Change SafepointMechanism terminology to talk less about "blocking" In-Reply-To: References: Message-ID: <7OdJuem20drI8cd4XWtXmjIhpk6RLb5UQuv3ZkbWLe4=.41b1ac71-3401-4cc6-96cb-359f585454bc@github.com> On Mon, 7 Sep 2020 12:33:37 GMT, Erik ?sterlund wrote: > Migrating this review from the mailing list into a pull request. So far, the favourite terminology is to talk about > "process", but without "operation". Okay, I am somewhat confused how Skara is supposed to register my review here. Reviewed! ------------- PR: https://git.openjdk.java.net/jdk/pull/54 From shade at openjdk.java.net Mon Sep 7 12:52:07 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 7 Sep 2020 12:52:07 GMT Subject: RFR: 8252661: Change SafepointMechanism terminology to talk less about "blocking" In-Reply-To: References: Message-ID: <6ZFOovgs_X7wlVoZcYRYlrTPLJo6Ns7w4VNvoQT-MZs=.d825a4e4-05e8-404b-926d-8ed6300d4e66@github.com> On Mon, 7 Sep 2020 12:33:37 GMT, Erik ?sterlund wrote: > Migrating this review from the mailing list into a pull request. So far, the favourite terminology is to talk about > "process", but without "operation". Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/54 From eosterlund at openjdk.java.net Mon Sep 7 13:06:22 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 7 Sep 2020 13:06:22 GMT Subject: RFR: 8252661: Change SafepointMechanism terminology to talk less about "blocking" In-Reply-To: <6ZFOovgs_X7wlVoZcYRYlrTPLJo6Ns7w4VNvoQT-MZs=.d825a4e4-05e8-404b-926d-8ed6300d4e66@github.com> References: <6ZFOovgs_X7wlVoZcYRYlrTPLJo6Ns7w4VNvoQT-MZs=.d825a4e4-05e8-404b-926d-8ed6300d4e66@github.com> Message-ID: On Mon, 7 Sep 2020 12:49:49 GMT, Aleksey Shipilev wrote: >> Migrating this review from the mailing list into a pull request. So far, the favourite terminology is to talk about >> "process", but without "operation". > > Marked as reviewed by shade (Reviewer). Thanks for the reviews, @shipilev and @robehn. I'll add David Holmes as reviewer too, as the final name suggestion was his. ------------- PR: https://git.openjdk.java.net/jdk/pull/54 From thomas.schatzl at oracle.com Mon Sep 7 13:15:22 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 7 Sep 2020 15:15:22 +0200 Subject: RFR: 8252859: Inconsistent use of alpha in class AbsSeq [v2] In-Reply-To: References: Message-ID: Hi, On 07.09.20 13:59, Albert Mingkun Yang wrote: >> 8252859: Inconsistent use of alpha in class AbsSeq > > Albert Mingkun Yang has refreshed the contents of this pull request, and previous commits have been removed. The > incremental views will show differences compared to the previous content of the PR. The pull request contains one new > commit since the last revision: > > alpha > > ------------- > > Changes: > - all: https://git.openjdk.java.net/jdk/pull/47/files > - new: https://git.openjdk.java.net/jdk/pull/47/files/347ff19b..89df9a5f > > Webrevs: > - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=47&range=01 > - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=47&range=00-01 > > Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod > Patch: https://git.openjdk.java.net/jdk/pull/47.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/47/head:pull/47 > > PR: https://git.openjdk.java.net/jdk/pull/47 > lgtm. Thomas From tschatzl at openjdk.java.net Mon Sep 7 13:17:20 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 7 Sep 2020 13:17:20 GMT Subject: RFR: 8252859: Inconsistent use of alpha in class AbsSeq [v2] In-Reply-To: References: Message-ID: <4lzr7snsWQA77z3AK8b17LI6RkjguZUFOAB6y52kjZ0=.d8c38c13-842d-441d-9d7c-cfa1c901d203@github.com> On Mon, 7 Sep 2020 11:59:25 GMT, Albert Mingkun Yang wrote: >> Invert the meaning of `_alpha`, from `alpha` to `1-alpha`. >> >> Test: I instrumented the constructor of `AbsSeq` with `printf("%f\n", _alpha)` onto master and `printf("%f\n", 1.0 - >> _alpha)` after the patch, and checked the output of `java --version` (G1, Parallel, Shenandoah, and Z) are the >> same before and after. > > Albert Mingkun Yang has refreshed the contents of this pull request, and previous commits have been removed. The > incremental views will show differences compared to the previous content of the PR. Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/47 From eosterlund at openjdk.java.net Mon Sep 7 14:02:24 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 7 Sep 2020 14:02:24 GMT Subject: Integrated: 8252661: Change SafepointMechanism terminology to talk less about "blocking" In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 12:33:37 GMT, Erik ?sterlund wrote: > Migrating this review from the mailing list into a pull request. So far, the favourite terminology is to talk about > "process", but without "operation". This pull request has now been integrated. Changeset: e29c3f61 Author: Erik ?sterlund URL: https://git.openjdk.java.net/jdk/commit/e29c3f61 Stats: 33 lines in 12 files changed: 0 ins; 0 del; 33 mod 8252661: Change SafepointMechanism terminology to talk less about "blocking" Reviewed-by: rehn, shade, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/54 From eosterlund at openjdk.java.net Mon Sep 7 14:20:05 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 7 Sep 2020 14:20:05 GMT Subject: RFR: 8252627: Make it safe for JFR thread to read threadObj Message-ID: Migrating this review from the mailing list to a PR so I can integrate it. Already reviewed really. ------------- Commit messages: - 8252627_jfr_thread_oop Changes: https://git.openjdk.java.net/jdk/pull/59/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=59&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252627 Stats: 13 lines in 2 files changed: 3 ins; 4 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/59.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/59/head:pull/59 PR: https://git.openjdk.java.net/jdk/pull/59 From jbhateja at openjdk.java.net Mon Sep 7 14:34:14 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 7 Sep 2020 14:34:14 GMT Subject: RFR: 8252847: New AVX512 optimized stubs for both conjoint and disjoint arraycopy Message-ID: Summary: 1) New AVX3 optimized stubs for both conjoint and disjoint arraycopy. 2) Special instruction sequence blocks for copy sizes b/w 32-192 bytes. 3) Block copy operation above 192 bytes is performed using destination address aligned PRE-MAIN-POST loop. Main loop copies 192 byte in one iteration and tail part fall over special instruction sequence blocks. 4) Both small copy block and aligned loop use 32 byte vector register to prevent and frequency penalty for copy sizes less than AVX3Threshold. 5) For block size above AVX3Theshold both special blocks and loop operate using 64 byte register. 6) In case user sets the maximum vector size to 32 bytes, forward copy (disjoint) operations are done using efficient REP MOVS for copy sizes above 4096 bytes. JMH Results: System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java Baseline : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_Baseline.txt]() WithOpt : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_WithOpts.txt]() ------------- Commit messages: - 8252847: New AVX512 optimized stubs for both conjoint and disjoint arraycopy. Changes: https://git.openjdk.java.net/jdk/pull/61/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=61&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252847 Stats: 1315 lines in 12 files changed: 1213 ins; 69 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/61.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/61/head:pull/61 PR: https://git.openjdk.java.net/jdk/pull/61 From eosterlund at openjdk.java.net Mon Sep 7 14:35:41 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 7 Sep 2020 14:35:41 GMT Subject: Integrated: 8252627: Make it safe for JFR thread to read threadObj In-Reply-To: References: Message-ID: <7j7MeTb4Z2__oDGHKguL9SYIv6DTl79xIyhU-hBI-r8=.c322465e-f363-4002-9fc4-1598965fd5f4@github.com> On Mon, 7 Sep 2020 14:12:18 GMT, Erik ?sterlund wrote: > Migrating this review from the mailing list to a PR so I can integrate it. Already reviewed really. This pull request has now been integrated. Changeset: e0d5b5f7 Author: Erik ?sterlund URL: https://git.openjdk.java.net/jdk/commit/e0d5b5f7 Stats: 13 lines in 2 files changed: 4 ins; 3 del; 6 mod 8252627: Make it safe for JFR thread to read threadObj Reviewed-by: dholmes, mgronlun ------------- PR: https://git.openjdk.java.net/jdk/pull/59 From eric.c.liu at arm.com Mon Sep 7 14:56:53 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Mon, 7 Sep 2020 14:56:53 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> , Message-ID: Hi Kim: Thanks for the discussion, this makes more sense to me now. > Kim Barrett on 06 September 2020 19:35 wrote: > > Can you be (very) specific about this.? Do all of these changes cause gcc10 to warn?? Or > do only some of them.? If only some, specifically which ones??I have a conjecture about > some of them (see below).? (I should probably try this myself; I know we have done some > testing with gcc10, but I don?t remember where to find that devkit.) I have tested 4 cases for those warnings: a) Without my patch, without asan, gcc-8 and gcc-10 are OK. b) Without my patch, with asan, gcc-8 has warned, gcc-10 is OK. c) With my patch, without asan, gcc-8 and gcc-10 are OK. d) With my patch, with asan, gcc-8 is OK, gcc-10 has warned. Those warnings can be reported by both gcc-8 and gcc-10 only when asan enabled. Without asan, no warning would be found even through some of them doesn't align with the documentation. > ------------------------------------------------------------------------------ > src/java.base/unix/native/libnet/NetworkInterface.c >?232???? strncpy(searchName, name_utf, IFNAMESIZE - 1); > > A better solution here would be to eliminate the strncpy entirely. > > The strncpy is used to make a copy of a string so the copy can be > searched for a colon, and if one is found, terminate the string there. > > But there's no need to make such a copy.? The string being copied is > the local temporary string name_utf.? We could instead use name_utf > everywhere searchName is currently used, including clobbering the > first colon to NUL.? We'd have to undo that before the later loop at > line 249, but we have the information needed to do so. Yes, this copy seems unnecessary. I was thinking whether it's a good way to find parent by using strstr, so that we can not have to recover the zero. Will that be much slower? > ------------------------------------------------------------------------------ > src/java.base/unix/native/libnet/NetworkInterface.c > 1298???? memset((char *)&if2, 0, sizeof(if2)); > 1299???? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1); > 1300???? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; > > (in getIndex) > > So gcc8 does not warn about this, but gcc10 does? That would be a > regression in gcc10 (and should be reported as such), because the > documentation for -Wstringop-truncate is clear that the above is the > proper idiom for avoiding the warning. Yse, I followed the documentation and gcc-8 does not warn about this, but gcc-10 does (both with asan enabled). > Regardless, the memset on 1298 is useless.? The code from before > JDK-8250863 was the memset then the strncpy with > sizeof(if2.ifr_name)-1 as the bound, which worked because the memset > would have zeroed the last element. > > The change for JDK-8250863 did not follow the documented idiom though. > > It would be interesting to find out if removal of the memset changes > anything.? It's barely conceivable that it's confusing the heuristics > used to decide whether -Wstringop-truncation should trigger.? For > example, the compiler might decide that the subsequent assignment of > the last element is unnecessary because of the memset and optimize the > assignment away, removing the idiomatic warning suppression. > > If gcc10 still warns about the above after removing the memset then I > see little recourse but to use PRAGMA_STRINGOP_TRUNCATION_IGNORED here. > > Similarly for the strncpy in getFlags: > 1362???? memset((char *)&if2, 0, sizeof(if2)); > 1363???? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1); > 1364???? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; After removing the memset, gcc-10(10.1.0) still warns about it, gcc-8 and gcc-9 also. > ------------------------------------------------------------------------------ > src/java.base/unix/native/libnet/NetworkInterface.c > ?937???? strncpy(name, if_name, IFNAMESIZE - 1); > ?938???? name[IFNAMESIZE - 1] = '\0'; > > gcc10 presumably did not complain about the old version here, and this > was not touched as part of JDK-8250863.? Does gcc10 complain about > this new version?? If so, then I see little recoarse but to use > PRAGMA_STRINGOP_TRUNCATION_IGNORED here, because a gcc10 warning here > is contrary to the documentation. Yes, gcc-10 would warn about this both before and after my patch if asan enabled. > ------------------------------------------------------------------------------ > src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c > est/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp > > These changes look good, as they follow the documented idiom for > suppressing -Wstringop-truncation. Does gcc10 warn after these changes? Gcc-10 does'n warn about this changes. > ------------------------------------------------------------------------------ > test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/libInheritedChannel.c > (In Java_UnixDomainSocket_bind0)? > 234???? memset(&addr, 0, sizeof(addr)); > 235???? addr.sun_family = AF_UNIX; > 236???? strncpy(addr.sun_path, nameUtf, length - 1); > 237???? addr.sun_path[length - 1] = '\0'; > > (In Java_UnixDomainSocket_connect0) > 267???? memset(&addr, 0, sizeof(addr)); > 268???? addr.sun_family = AF_UNIX; > 269???? strncpy(addr.sun_path, nameUtf, length - 1); > 270???? addr.sun_path[length - 1] = '\0'; > > These changes look good, as they follow the documented idiom for > suppressing -Wstringop-truncation. > > Does gcc10 warn after these changes? Gcc-10 doesn't warn about these changes. I'm working on a new patch that to make both gcc-8 and gcc-10 happy. Thanks, Eric From sjohanss at openjdk.java.net Mon Sep 7 15:33:21 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 7 Sep 2020 15:33:21 GMT Subject: RFR: 8252859: Inconsistent use of alpha in class AbsSeq [v2] In-Reply-To: References: Message-ID: <-Tezhiqv5tTqvKOnKNRdUaB_uDJWZGbdqwB1hZIUs5Q=.4904934e-4d19-4c7e-8052-0e4f510898ae@github.com> On Mon, 7 Sep 2020 11:59:25 GMT, Albert Mingkun Yang wrote: >> Invert the meaning of `_alpha`, from `alpha` to `1-alpha`. >> >> Test: I instrumented the constructor of `AbsSeq` with `printf("%f\n", _alpha)` onto master and `printf("%f\n", 1.0 - >> _alpha)` after the patch, and checked the output of `java --version` (G1, Parallel, Shenandoah, and Z) are the >> same before and after. > > Albert Mingkun Yang has refreshed the contents of this pull request, and previous commits have been removed. The > incremental views will show differences compared to the previous content of the PR. Looks good, thanks for cleaning this up. ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/47 From ayang at openjdk.java.net Mon Sep 7 15:36:30 2020 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 7 Sep 2020 15:36:30 GMT Subject: RFR: 8252859: Inconsistent use of alpha in class AbsSeq [v2] In-Reply-To: <-Tezhiqv5tTqvKOnKNRdUaB_uDJWZGbdqwB1hZIUs5Q=.4904934e-4d19-4c7e-8052-0e4f510898ae@github.com> References: <-Tezhiqv5tTqvKOnKNRdUaB_uDJWZGbdqwB1hZIUs5Q=.4904934e-4d19-4c7e-8052-0e4f510898ae@github.com> Message-ID: <0q0ktWV931QhiBgbSYInPo4jq7e01YCUfMkiDqgIAvg=.64e3a17c-7707-4695-a4b3-49db69037b15@github.com> On Mon, 7 Sep 2020 15:30:44 GMT, Stefan Johansson wrote: >> Albert Mingkun Yang has refreshed the contents of this pull request, and previous commits have been removed. The >> incremental views will show differences compared to the previous content of the PR. > > Looks good, thanks for cleaning this up. Stefan, thank you for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/47 From github.com+471021+marschall at openjdk.java.net Mon Sep 7 17:08:40 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Mon, 7 Sep 2020 17:08:40 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package Message-ID: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Hello, newbie here I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. - I tried to update the copyright year to 2020 in every file. - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. - All tier1 tests pass. - One jpackage/jlink tier2 test fails but I don't believe it is related. - Some tier3 Swing tests fail but I don't think they are related. ------------- Commit messages: - 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate Changes: https://git.openjdk.java.net/jdk/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8138732 Stats: 747 lines in 63 files changed: 149 ins; 148 del; 450 mod Patch: https://git.openjdk.java.net/jdk/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk/pull/45 From alanb at openjdk.java.net Mon Sep 7 17:53:50 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 7 Sep 2020 17:53:50 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Mon, 7 Sep 2020 09:44:09 GMT, Philippe Marschall wrote: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. This one probably needs discussion on hotspot-dev to get agreement on the rename/move. It might need coordination with Graal. If the change does go ahead then please check if java.base's module-info.java still needs to export jdk.internal to jdk.jfr, I suspect that qualified export can be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From rehn at openjdk.java.net Mon Sep 7 18:56:33 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 7 Sep 2020 18:56:33 GMT Subject: RFR: 8252871: fatal error: must own lock JvmtiThreadState_lock Message-ID: <89Sl3sTUIGnLL04rLqKd2nw0q_W7jSnLHaT2urJu2xE=.0ffbc7a7-92ad-4514-926e-7ee0d1416fea@github.com> When these two methods (set_frame_pop/clear_frame_pop) are called in a handshake the requesting thread will have lock the JvmtiThreadState_lock. But the thread executing one of these in the handshake may not be the owner. So we only check that JvmtiThreadState_lock is locked. When verifying the callers to these methods I notice "clear_to_frame_pop" was unused, so instead of fixing it I remove it. Passes testing locally, still running T3 and T7. Now passed! ------------- Commit messages: - Fix assert and removed unsed methods Changes: https://git.openjdk.java.net/jdk/pull/60/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=60&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252871 Stats: 26 lines in 4 files changed: 0 ins; 24 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/60.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/60/head:pull/60 PR: https://git.openjdk.java.net/jdk/pull/60 From dholmes at openjdk.java.net Mon Sep 7 21:47:48 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 7 Sep 2020 21:47:48 GMT Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function Message-ID: This is a rather large but generally simple cleanup. We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(), which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was also added to allow use in cases where we start with "const Thread *". Summary of changes: - changed raw casts to use as_Java_thread() - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread() - Removed checks that are checking the type system e.g. void foo(JavaThread* t) { assert(t->is_Java_thread(), "must be") the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry about that then we would need asserts like this on every method that expects a JavaThread! The right place for the assertion is at the head of any such call chain. - Removed asserts that are already guaranteed in the caller. - Use JavaThread::current() where appropriate. - Use pre-existing "thread" variable where available rather than casting THREAD Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have been missed. Testing: tiers 1-3 Thanks, David ------------- Commit messages: - Initial changes for 8252406 Changes: https://git.openjdk.java.net/jdk/pull/37/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252406 Stats: 463 lines in 112 files changed: 15 ins; 124 del; 324 mod Patch: https://git.openjdk.java.net/jdk/pull/37.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37 PR: https://git.openjdk.java.net/jdk/pull/37 From shade at openjdk.java.net Mon Sep 7 21:47:48 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 7 Sep 2020 21:47:48 GMT Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 05:56:14 GMT, David Holmes wrote: > This is a rather large but generally simple cleanup. > > We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify > this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(), > which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was > also added to allow use in cases where we start with "const Thread *". Summary of changes: > - changed raw casts to use as_Java_thread() > - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread() > - Removed checks that are checking the type system e.g. > void foo(JavaThread* t) { > assert(t->is_Java_thread(), "must be") > the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry > about that then we would need asserts like this on every method that expects a JavaThread! The right place for the > assertion is at the head of any such call chain. > - Removed asserts that are already guaranteed in the caller. > - Use JavaThread::current() where appropriate. > - Use pre-existing "thread" variable where available rather than casting THREAD > > Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have > been missed. > Testing: tiers 1-3 > > Thanks, > David Drive-by comment: Shenandoah changes look good. ------------- PR: https://git.openjdk.java.net/jdk/pull/37 From dholmes at openjdk.java.net Mon Sep 7 21:47:48 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 7 Sep 2020 21:47:48 GMT Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 13:37:10 GMT, Aleksey Shipilev wrote: >> This is a rather large but generally simple cleanup. >> >> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify >> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(), >> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was >> also added to allow use in cases where we start with "const Thread *". Summary of changes: >> - changed raw casts to use as_Java_thread() >> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread() >> - Removed checks that are checking the type system e.g. >> void foo(JavaThread* t) { >> assert(t->is_Java_thread(), "must be") >> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry >> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the >> assertion is at the head of any such call chain. >> - Removed asserts that are already guaranteed in the caller. >> - Use JavaThread::current() where appropriate. >> - Use pre-existing "thread" variable where available rather than casting THREAD >> >> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have >> been missed. >> Testing: tiers 1-3 >> >> Thanks, >> David > > Drive-by comment: Shenandoah changes look good. Thanks @shipilev ! Sending this out for RFR now. ------------- PR: https://git.openjdk.java.net/jdk/pull/37 From ysuenaga at openjdk.java.net Mon Sep 7 23:09:41 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 7 Sep 2020 23:09:41 GMT Subject: RFR: 8252871: fatal error: must own lock JvmtiThreadState_lock In-Reply-To: <89Sl3sTUIGnLL04rLqKd2nw0q_W7jSnLHaT2urJu2xE=.0ffbc7a7-92ad-4514-926e-7ee0d1416fea@github.com> References: <89Sl3sTUIGnLL04rLqKd2nw0q_W7jSnLHaT2urJu2xE=.0ffbc7a7-92ad-4514-926e-7ee0d1416fea@github.com> Message-ID: On Mon, 7 Sep 2020 14:14:28 GMT, Robbin Ehn wrote: > When these two methods (set_frame_pop/clear_frame_pop) are called in a handshake the requesting thread will have lock > the JvmtiThreadState_lock. But the thread executing one of these in the handshake may not be the owner. > So we only check that JvmtiThreadState_lock is locked. > > When verifying the callers to these methods I notice "clear_to_frame_pop" was unused, so instead of fixing it I remove > it. > Passes testing locally, still running T3 and T7. > > Now passed! Thanks for catching up this. Looks good. ------------- Marked as reviewed by ysuenaga (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/60 From kim.barrett at oracle.com Mon Sep 7 23:23:51 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 7 Sep 2020 19:23:51 -0400 Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function In-Reply-To: References: Message-ID: <7A59E0A1-6D4B-4593-8E86-919B27EEBCAA@oracle.com> > On Sep 7, 2020, at 5:47 PM, David Holmes wrote: > > [?] > Commit messages: > - Initial changes for 8252406 > > Changes: https://git.openjdk.java.net/jdk/pull/37/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8252406 > Stats: 463 lines in 112 files changed: 15 ins; 124 del; 324 mod > Patch: https://git.openjdk.java.net/jdk/pull/37.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37 > > PR: https://git.openjdk.java.net/jdk/pull/37 ------------------------------------------------------------------------------ src/hotspot/share/runtime/thread.hpp 506 JavaThread* as_Java_thread() { 507 assert(is_Java_thread(), "incorrect cast to JavaThread"); 508 return (JavaThread*)this; 509 } This should be using a static_cast. However, making that change will uncover a problem. This definition cannot correctly be located here. It must follow the definition of the JavaThread class. At this point (in the body of the Thread class definition), JavaThread is incomplete, so the C-style cast is a reinterpret_cast. It's only by implementation accident (and that we're not using multiple or virtual inheritance anywhere in the vicinity), that a reinterpret_cast happens to work. (The definition can remain in this file if that's more convenient #include-wise than putting it in thread.inline.hpp, though the latter would be the more usual placement.) (One of the very real dangers with C-style casts is that you might not be doing the cast you think you are doing.) ------------------------------------------------------------------------------ src/hotspot/share/runtime/thread.hpp 510 JavaThread * as_const_Java_thread() const { 511 assert(is_Java_thread(), "incorrect cast to JavaThread"); 512 return (JavaThread*)this; 513 } This should be const JavaThread* as_Java_Thread() const { assert(is_Java_thread(), "incorrect cast to JavaThread"); return static_cast(this); } And of course, moved after the definition of JavaThread, per the above discussion of the non-const function. ------------------------------------------------------------------------------ I reviewed all the (non-Shenandoah) gc changes, and they look good. From david.holmes at oracle.com Tue Sep 8 00:11:30 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Sep 2020 10:11:30 +1000 Subject: RFR: 8252871: fatal error: must own lock JvmtiThreadState_lock In-Reply-To: <89Sl3sTUIGnLL04rLqKd2nw0q_W7jSnLHaT2urJu2xE=.0ffbc7a7-92ad-4514-926e-7ee0d1416fea@github.com> References: <89Sl3sTUIGnLL04rLqKd2nw0q_W7jSnLHaT2urJu2xE=.0ffbc7a7-92ad-4514-926e-7ee0d1416fea@github.com> Message-ID: Hi Robbin, On 8/09/2020 4:56 am, Robbin Ehn wrote: > When these two methods (set_frame_pop/clear_frame_pop) are called in a handshake the requesting thread will have lock > the JvmtiThreadState_lock. But the thread executing one of these in the handshake may not be the owner. Ouch! We continue to get bitten by the fact the executor of a handshake operation is not known a-priori. :( > So we only check that JvmtiThreadState_lock is locked. That avoids the problem but it is not really a sufficient check - we need to know that it is the handshaker thread that owns the lock and that it acquired it purely for the purpose of this handshake operation! More importantly this issue shows that the locking code is in fact incorrect. We are on very dangerous ground if we are going to allow locks to be "proxied" in this fashion! This is akin to reintroducing "sneaky locks"! If a handshake operation can be executed by either the target thread or the handshaker thread, and locks are required, then they will have to be acquired in the context of the handshake operation. If we can't do that because of potential deadlocks in the handshake mechanism then I feel that handshakes have a serious flaw that needs to be rectified. Perhaps we need a way to force the operation to be executed by the handshaker so that they can setup the right execution environment prior to the handshake? > When verifying the callers to these methods I notice "clear_to_frame_pop" was unused, so instead of fixing it I remove > it. There is already a bug for that: https://bugs.openjdk.java.net/browse/JDK-8252816 so if this proceeds you should add that issue to the PR. Thanks, David ----- > Passes testing locally, still running T3 and T7. > > Now passed! > > ------------- > > Commit messages: > - Fix assert and removed unsed methods > > Changes: https://git.openjdk.java.net/jdk/pull/60/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=60&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8252871 > Stats: 26 lines in 4 files changed: 0 ins; 24 del; 2 mod > Patch: https://git.openjdk.java.net/jdk/pull/60.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/60/head:pull/60 > > PR: https://git.openjdk.java.net/jdk/pull/60 > From david.holmes at oracle.com Tue Sep 8 01:11:09 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Sep 2020 11:11:09 +1000 Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: <369201b2-087d-44c5-d020-26c239d172aa@oracle.com> Hi Philippe, On 8/09/2020 3:08 am, Philippe Marschall wrote: > Hello, newbie here Welcome aboard! > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. That's somewhat debatable, but I don't think @since really serves any useful purpose on non-public APIs, so I'm fine either way. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. The changes all look good to me. Thanks, David ----- > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. > > ------------- > > Commit messages: > - 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate > > Changes: https://git.openjdk.java.net/jdk/pull/45/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8138732 > Stats: 747 lines in 63 files changed: 149 ins; 148 del; 450 mod > Patch: https://git.openjdk.java.net/jdk/pull/45.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 > > PR: https://git.openjdk.java.net/jdk/pull/45 > From dholmes at openjdk.java.net Tue Sep 8 01:13:41 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 8 Sep 2020 01:13:41 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: <7422UelQpc0A_Q-YQ_TIQ-ihtR0d-7lTmQVaG2o0owg=.fea1ee30-463d-44e2-b63a-26b6baa2559b@github.com> On Mon, 7 Sep 2020 09:44:09 GMT, Philippe Marschall wrote: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. The changes all look good to me. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/45 From david.holmes at oracle.com Tue Sep 8 01:31:59 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Sep 2020 11:31:59 +1000 Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function In-Reply-To: <7A59E0A1-6D4B-4593-8E86-919B27EEBCAA@oracle.com> References: <7A59E0A1-6D4B-4593-8E86-919B27EEBCAA@oracle.com> Message-ID: <73622215-c297-f47e-069b-1746fae3121f@oracle.com> Hi Kim, Thanks for taking a look. On 8/09/2020 9:23 am, Kim Barrett wrote: >> On Sep 7, 2020, at 5:47 PM, David Holmes wrote: >> >> [?] >> Commit messages: >> - Initial changes for 8252406 >> >> Changes: https://git.openjdk.java.net/jdk/pull/37/files >> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8252406 >> Stats: 463 lines in 112 files changed: 15 ins; 124 del; 324 mod >> Patch: https://git.openjdk.java.net/jdk/pull/37.diff >> Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37 >> >> PR: https://git.openjdk.java.net/jdk/pull/37 > > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/thread.hpp > 506 JavaThread* as_Java_thread() { > 507 assert(is_Java_thread(), "incorrect cast to JavaThread"); > 508 return (JavaThread*)this; > 509 } > > This should be using a static_cast. However, making that change will > uncover a problem. > > This definition cannot correctly be located here. It must follow the > definition of the JavaThread class. I did try to do the right thing with static_cast and of course discovered that I couldn't use it at that location. As I was replacing C-style casts, and as other C-style casts continue to be used in similar methods, I just kept with the C-styler cast. > At this point (in the body of the > Thread class definition), JavaThread is incomplete, so the C-style > cast is a reinterpret_cast. It's only by implementation accident (and > that we're not using multiple or virtual inheritance anywhere in the > vicinity), that a reinterpret_cast happens to work. > > (The definition can remain in this file if that's more > convenient #include-wise than putting it in thread.inline.hpp, though > the latter would be the more usual placement.) Okay I will look at what is involved in putting it in the .inline.hpp file; if that causes too many problems then I'll just shift it to an inline definition later in the hpp file. > (One of the very real dangers with C-style casts is that you might not > be doing the cast you think you are doing.) > > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/thread.hpp > 510 JavaThread * as_const_Java_thread() const { > 511 assert(is_Java_thread(), "incorrect cast to JavaThread"); > 512 return (JavaThread*)this; > 513 } > > This should be > > const JavaThread* as_Java_Thread() const { > assert(is_Java_thread(), "incorrect cast to JavaThread"); > return static_cast(this); > } > > And of course, moved after the definition of JavaThread, per the above > discussion of the non-const function. Will fix. > ------------------------------------------------------------------------------ > > I reviewed all the (non-Shenandoah) gc changes, and they look good. Thanks for the review and coding tips! Cheers, David From dholmes at openjdk.java.net Tue Sep 8 04:09:14 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 8 Sep 2020 04:09:14 GMT Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v2] In-Reply-To: References: Message-ID: > This is a rather large but generally simple cleanup. > > We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify > this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(), > which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was > also added to allow use in cases where we start with "const Thread *". Summary of changes: > - changed raw casts to use as_Java_thread() > - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread() > - Removed checks that are checking the type system e.g. > void foo(JavaThread* t) { > assert(t->is_Java_thread(), "must be") > the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry > about that then we would need asserts like this on every method that expects a JavaThread! The right place for the > assertion is at the head of any such call chain. > - Removed asserts that are already guaranteed in the caller. > - Use JavaThread::current() where appropriate. > - Use pre-existing "thread" variable where available rather than casting THREAD > > Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have > been missed. > Testing: tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Used static_cast instead of raw C-style cast Moved inline functions to thread.inline.hpp Updated #includes to deal with the move to thread.inline.hpp Updated copyright year where needed. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/37/files - new: https://git.openjdk.java.net/jdk/pull/37/files/b18faad5..da70f804 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=00-01 Stats: 102 lines in 33 files changed: 39 ins; 28 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/37.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37 PR: https://git.openjdk.java.net/jdk/pull/37 From dholmes at openjdk.java.net Tue Sep 8 04:38:43 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 8 Sep 2020 04:38:43 GMT Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v3] In-Reply-To: References: Message-ID: > This is a rather large but generally simple cleanup. > > We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify > this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(), > which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was > also added to allow use in cases where we start with "const Thread *". Summary of changes: > - changed raw casts to use as_Java_thread() > - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread() > - Removed checks that are checking the type system e.g. > void foo(JavaThread* t) { > assert(t->is_Java_thread(), "must be") > the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry > about that then we would need asserts like this on every method that expects a JavaThread! The right place for the > assertion is at the head of any such call chain. > - Removed asserts that are already guaranteed in the caller. > - Use JavaThread::current() where appropriate. > - Use pre-existing "thread" variable where available rather than casting THREAD > > Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have > been missed. > Testing: tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: More missing includes of thread.inline.hpp The fanout for this change is now quite large. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/37/files - new: https://git.openjdk.java.net/jdk/pull/37/files/da70f804..68995170 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=01-02 Stats: 8 lines in 7 files changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/37.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37 PR: https://git.openjdk.java.net/jdk/pull/37 From kim.barrett at oracle.com Tue Sep 8 06:34:17 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 8 Sep 2020 02:34:17 -0400 Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v2] In-Reply-To: References: Message-ID: <5CFDA329-BF65-4D6F-84AD-8863B06BBA33@oracle.com> > On Sep 8, 2020, at 12:09 AM, David Holmes wrote: > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Used static_cast instead of raw C-style cast > Moved inline functions to thread.inline.hpp > Updated #includes to deal with the move to thread.inline.hpp > Updated copyright year where needed. > > ------------- > > Changes: > - all: https://git.openjdk.java.net/jdk/pull/37/files > - new: https://git.openjdk.java.net/jdk/pull/37/files/b18faad5..da70f804 > > Webrevs: > - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=01 > - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=00-01 > > Stats: 102 lines in 33 files changed: 39 ins; 28 del; 35 mod > Patch: https://git.openjdk.java.net/jdk/pull/37.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37 > > PR: https://git.openjdk.java.net/jdk/pull/37 ------------------------------------------------------------------------------ src/hotspot/share/runtime/thread.hpp 507 const JavaThread* as_const_Java_thread() const; This missed part of what I'd suggested. I don't think the "const" part of the name is needed or helpful. Just overload as_Java_thread on the const-ness of the thread it's being applied to. There are some situations where there is such an overload pair and it is useful to additionally have an explicit const function, but I don't think this is one of those. ------------------------------------------------------------------------------ The fannout from putting the conversion functions in thread.inline.hpp seems pretty high in the number of files that get touched. Especially since it leads to JavaThread::current() and JavaThread::as_CompilerThread() being moved. I would have been at least fine with, and probably would prefer, having the definitions of as_JavaThread near the old definitions of those functions in thread.hpp. ------------------------------------------------------------------------------ From shade at openjdk.java.net Tue Sep 8 06:56:30 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 8 Sep 2020 06:56:30 GMT Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v3] In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 04:38:43 GMT, David Holmes wrote: >> This is a rather large but generally simple cleanup. >> >> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify >> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(), >> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was >> also added to allow use in cases where we start with "const Thread *". Summary of changes: >> - changed raw casts to use as_Java_thread() >> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread() >> - Removed checks that are checking the type system e.g. >> void foo(JavaThread* t) { >> assert(t->is_Java_thread(), "must be") >> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry >> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the >> assertion is at the head of any such call chain. >> - Removed asserts that are already guaranteed in the caller. >> - Use JavaThread::current() where appropriate. >> - Use pre-existing "thread" variable where available rather than casting THREAD >> >> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have >> been missed. >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > More missing includes of thread.inline.hpp > > The fanout for this change is now quite large. Shenandoah parts still look good. Formally approving. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/37 From david.holmes at oracle.com Tue Sep 8 07:00:27 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Sep 2020 17:00:27 +1000 Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v2] In-Reply-To: <5CFDA329-BF65-4D6F-84AD-8863B06BBA33@oracle.com> References: <5CFDA329-BF65-4D6F-84AD-8863B06BBA33@oracle.com> Message-ID: <5b615b71-9630-ac0a-08be-ce3dd09da7b8@oracle.com> On 8/09/2020 4:34 pm, Kim Barrett wrote: >> On Sep 8, 2020, at 12:09 AM, David Holmes wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Used static_cast instead of raw C-style cast >> Moved inline functions to thread.inline.hpp >> Updated #includes to deal with the move to thread.inline.hpp >> Updated copyright year where needed. >> >> ------------- >> >> Changes: >> - all: https://git.openjdk.java.net/jdk/pull/37/files >> - new: https://git.openjdk.java.net/jdk/pull/37/files/b18faad5..da70f804 >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=01 >> - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=00-01 >> >> Stats: 102 lines in 33 files changed: 39 ins; 28 del; 35 mod >> Patch: https://git.openjdk.java.net/jdk/pull/37.diff >> Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37 >> >> PR: https://git.openjdk.java.net/jdk/pull/37 > > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/thread.hpp > 507 const JavaThread* as_const_Java_thread() const; > > This missed part of what I'd suggested. I don't think the "const" part > of the name is needed or helpful. Just overload as_Java_thread on the > const-ness of the thread it's being applied to. I saw that but thought it was a typo as I don't think about overloads in terms of const or other modifiers. To me overloads are same named methods that differ in arguments (and I'm going to guess that 'this' is considered an argument in this context and hence leads to the overload based on the const?). But in addition I wanted to have this say as_const_JavaThread because I wanted to clearly distringuish it from as_JavaThread because there is only a couple of special cases in the JFR code where this const version is needed. If that code were to change and is_const_JavaThread because unused, it would be easy to see that. > There are some situations where there is such an overload pair and it > is useful to additionally have an explicit const function, but I don't > think this is one of those. > > ------------------------------------------------------------------------------ > > The fannout from putting the conversion functions in thread.inline.hpp seems > pretty high in the number of files that get touched. Especially since it > leads to JavaThread::current() and JavaThread::as_CompilerThread() being > moved. I would have been at least fine with, and probably would prefer, > having the definitions of as_JavaThread near the old definitions of those > functions in thread.hpp. I tried to do the right and obey the "use .inline.hpp for inline definitions" rule. But I must confess I was reaching a point where I thought this was going too far but it's a good exercise with using git and PRs so I don't mind if I back up and take a simpler approach - especially as I just discovered more build failures due to missing includes. :( Thanks, David > ------------------------------------------------------------------------------ > From rehn at openjdk.java.net Tue Sep 8 07:39:15 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 8 Sep 2020 07:39:15 GMT Subject: RFR: 8252871: fatal error: must own lock JvmtiThreadState_lock In-Reply-To: References: <89Sl3sTUIGnLL04rLqKd2nw0q_W7jSnLHaT2urJu2xE=.0ffbc7a7-92ad-4514-926e-7ee0d1416fea@github.com> Message-ID: <_CymPcNGFQfEGh-pUsr2XHpavaR7gCjCGm92XOkQIJQ=.76cb76e8-6422-432b-96f4-00b38dd04412@github.com> On Mon, 7 Sep 2020 23:07:13 GMT, Yasumasa Suenaga wrote: >> When these two methods (set_frame_pop/clear_frame_pop) are called in a handshake the requesting thread will have lock >> the JvmtiThreadState_lock. But the thread executing one of these in the handshake may not be the owner. >> So we only check that JvmtiThreadState_lock is locked. >> >> When verifying the callers to these methods I notice "clear_to_frame_pop" was unused, so instead of fixing it I remove >> it. >> Passes testing locally, still running T3 and T7. >> >> Now passed! > > Thanks for catching up this. Looks good. Hi David, > > When these two methods (set_frame_pop/clear_frame_pop) are called in a handshake the requesting thread will have lock > > the JvmtiThreadState_lock. But the thread executing one of these in the handshake may not be the owner. > > Ouch! We continue to get bitten by the fact the executor of a handshake > operation is not known a-priori. :( > We could add this. But I would prefer not doing it in this bug fix. > > So we only check that JvmtiThreadState_lock is locked. > > That avoids the problem but it is not really a sufficient check - we > need to know that it is the handshaker thread that owns the lock and > that it acquired it purely for the purpose of this handshake operation! > Right now we know that because I traced the code :) As I said I can make the requesting thread known to execution thread, but I would really prefer not doing that in this bug fix. > More importantly this issue shows that the locking code is in fact > incorrect. We are on very dangerous ground if we are going to allow > locks to be "proxied" in this fashion! This is akin to reintroducing > "sneaky locks"! A problem is that we use a safepoiting global lock to protect per thread resource. The way we get around this with safepoints is: "assert_locked_or_safepoint" (assert may be passed by a non-JavaThread or JavaThread in blocked/native without lock during a safepoint (safepoint + VM thread would fix that)) Which have this in it: // see if invoker of VM operation owns it VM_Operation* op = VMThread::vm_operation(); if (op != NULL && op->calling_thread() == lock->owner()) return; So we already have proxied locks and in other cases just avoiding them (by just checking if at safepoint). And as I said a few times now, I said I can make the requesting thread known to execution thread, but I would really prefer not doing that in this bug fix. > > If a handshake operation can be executed by either the target thread or > the handshaker thread, and locks are required, then they will have to be > acquired in the context of the handshake operation. If we can't do that > because of potential deadlocks in the handshake mechanism then I feel > that handshakes have a serious flaw that needs to be rectified. Perhaps > we need a way to force the operation to be executed by the handshaker so > that they can setup the right execution environment prior to the handshake? The problem is that it's a safepointing lock. Only executing the handshake by requester is an interesting idea, I'll investigate that. > > > When verifying the callers to these methods I notice "clear_to_frame_pop" was unused, so instead of fixing it I remove > > it. > > There is already a bug for that: > > https://bugs.openjdk.java.net/browse/JDK-8252816 > > so if this proceeds you should add that issue to the PR. Ok, I'll do that. Thanks for having a look, let me know howto proceed. > > Thanks, > David > ----- ------------- PR: https://git.openjdk.java.net/jdk/pull/60 From robbin.ehn at oracle.com Tue Sep 8 07:58:03 2020 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 8 Sep 2020 09:58:03 +0200 Subject: RFR: 8252871: fatal error: must own lock JvmtiThreadState_lock In-Reply-To: <_CymPcNGFQfEGh-pUsr2XHpavaR7gCjCGm92XOkQIJQ=.76cb76e8-6422-432b-96f4-00b38dd04412@github.com> References: <89Sl3sTUIGnLL04rLqKd2nw0q_W7jSnLHaT2urJu2xE=.0ffbc7a7-92ad-4514-926e-7ee0d1416fea@github.com> <_CymPcNGFQfEGh-pUsr2XHpavaR7gCjCGm92XOkQIJQ=.76cb76e8-6422-432b-96f4-00b38dd04412@github.com> Message-ID: <1248bbaa-3573-f006-8cb5-7249a80c9199@oracle.com> Hi David, our mail service did the wrong thing here. This was a reply to your comment, so you should have been in To-field, this quote above "Hi David" should not have been here, and this was a reply your mail (via github comment). Thanks, Robbin On 2020-09-08 09:39, Robbin Ehn wrote: > On Mon, 7 Sep 2020 23:07:13 GMT, Yasumasa Suenaga wrote: > >>> When these two methods (set_frame_pop/clear_frame_pop) are called in a handshake the requesting thread will have lock >>> the JvmtiThreadState_lock. But the thread executing one of these in the handshake may not be the owner. >>> So we only check that JvmtiThreadState_lock is locked. >>> >>> When verifying the callers to these methods I notice "clear_to_frame_pop" was unused, so instead of fixing it I remove >>> it. >>> Passes testing locally, still running T3 and T7. >>> >>> Now passed! >> >> Thanks for catching up this. Looks good. > > Hi David, > >>> When these two methods (set_frame_pop/clear_frame_pop) are called in a handshake the requesting thread will have lock >>> the JvmtiThreadState_lock. But the thread executing one of these in the handshake may not be the owner. >> >> Ouch! We continue to get bitten by the fact the executor of a handshake >> operation is not known a-priori. :( >> > > We could add this. But I would prefer not doing it in this bug fix. > >>> So we only check that JvmtiThreadState_lock is locked. >> >> That avoids the problem but it is not really a sufficient check - we >> need to know that it is the handshaker thread that owns the lock and >> that it acquired it purely for the purpose of this handshake operation! >> > > Right now we know that because I traced the code :) > > As I said I can make the requesting thread known to execution thread, > but I would really prefer not doing that in this bug fix. > >> More importantly this issue shows that the locking code is in fact >> incorrect. We are on very dangerous ground if we are going to allow >> locks to be "proxied" in this fashion! This is akin to reintroducing >> "sneaky locks"! > > A problem is that we use a safepoiting global lock to protect per thread resource. > The way we get around this with safepoints is: > "assert_locked_or_safepoint" (assert may be passed by a non-JavaThread or JavaThread in blocked/native without lock > during a safepoint (safepoint + VM thread would fix that)) Which have this in it: > // see if invoker of VM operation owns it > VM_Operation* op = VMThread::vm_operation(); > if (op != NULL && op->calling_thread() == lock->owner()) return; > > So we already have proxied locks and in other cases just avoiding them (by just checking if at safepoint). > > And as I said a few times now, I said I can make the requesting thread known to execution thread, > but I would really prefer not doing that in this bug fix. > >> >> If a handshake operation can be executed by either the target thread or >> the handshaker thread, and locks are required, then they will have to be >> acquired in the context of the handshake operation. If we can't do that >> because of potential deadlocks in the handshake mechanism then I feel >> that handshakes have a serious flaw that needs to be rectified. Perhaps >> we need a way to force the operation to be executed by the handshaker so >> that they can setup the right execution environment prior to the handshake? > > The problem is that it's a safepointing lock. > Only executing the handshake by requester is an interesting idea, I'll investigate that. > >> >>> When verifying the callers to these methods I notice "clear_to_frame_pop" was unused, so instead of fixing it I remove >>> it. >> >> There is already a bug for that: >> >> https://bugs.openjdk.java.net/browse/JDK-8252816 >> >> so if this proceeds you should add that issue to the PR. > > Ok, I'll do that. > > Thanks for having a look, let me know howto proceed. > >> >> Thanks, >> David >> ----- > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/60 > From ofirg6 at gmail.com Tue Sep 8 08:29:40 2020 From: ofirg6 at gmail.com (Ofir Gordon) Date: Tue, 8 Sep 2020 11:29:40 +0300 Subject: How to build changes made in "os" directory files? Message-ID: Hello everyone, I'm working on the jdk14 source code, and I'm trying to make some changes in the gc code. Any changes that I make in files under the "shared" code directory appear in the compiled program as expected. The problem is when I'm trying to change the code in a file under the "os" directory (specifically "os_aix"), the changes don't seem to appear in the compiled program. I build the program with the `make images` command and use the output program to run a simple java program. What is the correct way of making changes in this part of the code? To elaborate a little more, my intention is to intervene in the part where a new thread is created for a gc task, in order to bind this thread to a specific core. If there is a simple way to do so or if the "os_aix" file is not the correct place, I would be happy to hear your advice. Thanks a lot, Ofir From shade at redhat.com Tue Sep 8 08:35:19 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 8 Sep 2020 10:35:19 +0200 Subject: How to build changes made in "os" directory files? In-Reply-To: References: Message-ID: <60a374cc-157a-d5d3-ccc6-27447619d96c@redhat.com> On 9/8/20 10:29 AM, Ofir Gordon wrote: > The problem is when I'm trying to change the code in a file under the "os" > directory (specifically "os_aix"), the changes don't seem to appear in the > compiled program. "os_aix" implies that is OS-specific code for AIX. Unless you are building the binary for AIX, that code would not get compiled. > What is the correct way of making changes in this part of the code? The correct way is to either get the AIX machine to test this change, or kindly ask AIX port maintainers to test it for you. But chances are, you don't need that if you are just prototyping the change, which must be fine for a single target platform you have (I assume something like Linux x86_64). -- Thanks, -Aleksey From thomas.schatzl at oracle.com Tue Sep 8 08:39:27 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 8 Sep 2020 10:39:27 +0200 Subject: How to build changes made in "os" directory files? In-Reply-To: References: Message-ID: <4d011490-aab2-1e9e-753b-f93831124cfa@oracle.com> Hi, On 08.09.20 10:29, Ofir Gordon wrote: > Hello everyone, > > I'm working on the jdk14 source code, and I'm trying to make some changes > in the gc code. Any changes that I make in files under the "shared" code > directory appear in the compiled program as expected. > The problem is when I'm trying to change the code in a file under the "os" > directory (specifically "os_aix"), the changes don't seem to appear in the > compiled program. > > I build the program with the `make images` command and use the output > program to run a simple java program. > > What is the correct way of making changes in this part of the code? > > To elaborate a little more, my intention is to intervene in the part where > a new thread is created for a gc task, in order to bind this thread to a > specific core. If there is a simple way to do so or if the "os_aix" file is > not the correct place, I would be happy to hear your advice. The OS files contain OS dependent code, with the suffix indicating the OS it is for. Sources in the os/aix directory like os_aix.* are related to the AIX operating system. So unless you compile for AIX, it is natural that changes there do not show up. Not sure what OS you are targeting, but e.g. Linux code is located either in os/posix or os/linux. Hth, Thomas From goetz.lindenmaier at sap.com Tue Sep 8 08:47:01 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 8 Sep 2020 08:47:01 +0000 Subject: How to build changes made in "os" directory files? In-Reply-To: References: Message-ID: Hi, The os_aix files are the implementation of the aix OS port. AIX is an operating system by IBM These files will be used if you build on AIX. I would guess you build on linux. In this case you need to edit the os_linux files. Best regards, Goetz. > -----Original Message----- > From: hotspot-dev On Behalf Of Ofir > Gordon > Sent: Tuesday, September 8, 2020 10:30 AM > To: hotspot-dev at openjdk.java.net > Subject: How to build changes made in "os" directory files? > > Hello everyone, > > I'm working on the jdk14 source code, and I'm trying to make some changes > in the gc code. Any changes that I make in files under the "shared" code > directory appear in the compiled program as expected. > The problem is when I'm trying to change the code in a file under the "os" > directory (specifically "os_aix"), the changes don't seem to appear in the > compiled program. > > I build the program with the `make images` command and use the output > program to run a simple java program. > > What is the correct way of making changes in this part of the code? > > To elaborate a little more, my intention is to intervene in the part where > a new thread is created for a gc task, in order to bind this thread to a > specific core. If there is a simple way to do so or if the "os_aix" file is > not the correct place, I would be happy to hear your advice. > > Thanks a lot, > Ofir From ofirg6 at gmail.com Tue Sep 8 09:03:39 2020 From: ofirg6 at gmail.com (Ofir Gordon) Date: Tue, 8 Sep 2020 12:03:39 +0300 Subject: How to build changes made in "os" directory files? In-Reply-To: <60a374cc-157a-d5d3-ccc6-27447619d96c@redhat.com> References: <60a374cc-157a-d5d3-ccc6-27447619d96c@redhat.com> Message-ID: Thank you for the quick response! Can you please explain what you meant in the last comment? If I don't need that, how can I implement this change in the code I'm using? Say, if I want to add code that binds a new created thread to a specific core (I'm familiar with the c++ code required to do so, but where should I add it in the hotspot source code?) Regarding the platform, I'm currently just testing it on a linux x86_64 bit system, but the plan is to run it on a simulated arm 64bit architecture (I don't know if it makes any difference for where I do the changes in the source code). ??????? ??? ??, 8 ????? 2020 ?-11:35 ??? ?Aleksey Shipilev?? :? > On 9/8/20 10:29 AM, Ofir Gordon wrote: > > The problem is when I'm trying to change the code in a file under the > "os" > > directory (specifically "os_aix"), the changes don't seem to appear in > the > > compiled program. > > "os_aix" implies that is OS-specific code for AIX. Unless you are building > the binary for AIX, that > code would not get compiled. > > > What is the correct way of making changes in this part of the code? > > The correct way is to either get the AIX machine to test this change, or > kindly ask AIX port > maintainers to test it for you. > > But chances are, you don't need that if you are just prototyping the > change, which must be fine for > a single target platform you have (I assume something like Linux x86_64). > > -- > Thanks, > -Aleksey > > From shade at redhat.com Tue Sep 8 09:09:11 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 8 Sep 2020 11:09:11 +0200 Subject: How to build changes made in "os" directory files? In-Reply-To: References: <60a374cc-157a-d5d3-ccc6-27447619d96c@redhat.com> Message-ID: <3466e679-7bfc-c3cd-93e9-35eb2002caad@redhat.com> On 9/8/20 11:03 AM, Ofir Gordon wrote: > Can you please explain what you meant in the last comment? > If I don't need that, how can I implement this change in the code I'm using? > Say, if I want to add code that binds a new created thread to a specific core (I'm familiar?with the > c++ code required to do so, but where should I add it in the hotspot source code?) Then add it only in the platform-specific code related to the platform where you are building. That would be simpler for prototyping. If/when your prototype graduates to something that might be included into the tree, _then_ figure out what to change in other platform-specific code, and how to test it. > Regarding the platform, I'm currently just testing it on a linux x86_64 bit system, but the plan is > to run it on a simulated arm 64bit architecture So Linux x86_64 means these are built: src/hotspot/share/ src/hotspot/cpu/x86/ src/hotspot/os/linux/ src/hotspot/os/posix/ (maybe?) src/hotspot/os_cpu/linux_x86/ See? It selects x86 from "cpu", linux from "os", and linux_x86 from "os_cpu". -- Thanks, -Aleksey From dholmes at openjdk.java.net Tue Sep 8 09:34:14 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 8 Sep 2020 09:34:14 GMT Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v4] In-Reply-To: References: Message-ID: > This is a rather large but generally simple cleanup. > > We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify > this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(), > which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was > also added to allow use in cases where we start with "const Thread *". Summary of changes: > - changed raw casts to use as_Java_thread() > - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread() > - Removed checks that are checking the type system e.g. > void foo(JavaThread* t) { > assert(t->is_Java_thread(), "must be") > the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry > about that then we would need asserts like this on every method that expects a JavaThread! The right place for the > assertion is at the head of any such call chain. > - Removed asserts that are already guaranteed in the caller. > - Use JavaThread::current() where appropriate. > - Use pre-existing "thread" variable where available rather than casting THREAD > > Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have > been missed. > Testing: tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: This reverts commit 689951708fccd0073873e645bf683bc34b75a772 This reverts commit da70f8047d3f9c8af9d3eee3b14c71122c5220a0. Reverting v3 and v2 so that we can take a simpler approach that touches far fewer files. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/37/files - new: https://git.openjdk.java.net/jdk/pull/37/files/68995170..202af760 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=02-03 Stats: 110 lines in 40 files changed: 28 ins; 45 del; 37 mod Patch: https://git.openjdk.java.net/jdk/pull/37.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37 PR: https://git.openjdk.java.net/jdk/pull/37 From kim.barrett at oracle.com Tue Sep 8 10:01:24 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 8 Sep 2020 06:01:24 -0400 Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v2] In-Reply-To: <5b615b71-9630-ac0a-08be-ce3dd09da7b8@oracle.com> References: <5CFDA329-BF65-4D6F-84AD-8863B06BBA33@oracle.com> <5b615b71-9630-ac0a-08be-ce3dd09da7b8@oracle.com> Message-ID: <28246A71-A3BD-4240-BED1-6D575B23B851@oracle.com> > On Sep 8, 2020, at 3:00 AM, David Holmes wrote: > > On 8/09/2020 4:34 pm, Kim Barrett wrote: >> [?] >> src/hotspot/share/runtime/thread.hpp >> 507 const JavaThread* as_const_Java_thread() const; >> This missed part of what I'd suggested. I don't think the "const" part >> of the name is needed or helpful. Just overload as_Java_thread on the >> const-ness of the thread it's being applied to. > > I saw that but thought it was a typo Intentional, not a typo. > as I don't think about overloads in terms of const or other modifiers. To me overloads are same named methods that differ in arguments (and I'm going to guess that 'this' is considered an argument in this context and hence leads to the overload based on the const?). That's correct, the function's const qualifier or lack thereof provides overloading on the corresponding qualification of the 'this' argument. Such overloading is a "common C++ idiom". > But in addition I wanted to have this say as_const_JavaThread because I wanted to clearly distringuish it from as_JavaThread because there is only a couple of special cases in the JFR code where this const version is needed. If that code were to change and is_const_JavaThread because unused, it would be easy to see that. I think those cases are just jfr being better than typical HotSpot code about const qualifications. I wouldn't be surprised if there were other places that could benefit from having such an overload pair if we tried harder to be const-correct. So I would prefer overloading rather than the odd name. >> The fannout from putting the conversion functions in thread.inline.hpp seems >> pretty high in the number of files that get touched. Especially since it >> leads to JavaThread::current() and JavaThread::as_CompilerThread() being >> moved. I would have been at least fine with, and probably would prefer, >> having the definitions of as_JavaThread near the old definitions of those >> functions in thread.hpp. > > I tried to do the right and obey the "use .inline.hpp for inline definitions" rule. But I must confess I was reaching a point where I thought this was going too far but it's a good exercise with using git and PRs so I don't mind if I back up and take a simpler approach - especially as I just discovered more build failures due to missing includes. :( I don't think there is such a rule, but that's a deep discussion that goes far beyond the scope of this change. I think there are problems with how we are using "inline" files. Stefan Karlsson and I (and others?) had a long discussion about this a while back, which I can't find right now (drat!). From david.holmes at oracle.com Tue Sep 8 10:06:02 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Sep 2020 20:06:02 +1000 Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v4] In-Reply-To: References: Message-ID: <7c0fd793-e3a0-01df-0efe-0d144e6f20ea@oracle.com> Just to be clear please wait for v5 to appear before reviewing. Thanks, David On 8/09/2020 7:34 pm, David Holmes wrote: >> This is a rather large but generally simple cleanup. >> >> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify >> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(), >> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was >> also added to allow use in cases where we start with "const Thread *". Summary of changes: >> - changed raw casts to use as_Java_thread() >> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread() >> - Removed checks that are checking the type system e.g. >> void foo(JavaThread* t) { >> assert(t->is_Java_thread(), "must be") >> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry >> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the >> assertion is at the head of any such call chain. >> - Removed asserts that are already guaranteed in the caller. >> - Use JavaThread::current() where appropriate. >> - Use pre-existing "thread" variable where available rather than casting THREAD >> >> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have >> been missed. >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > This reverts commit 689951708fccd0073873e645bf683bc34b75a772 > This reverts commit da70f8047d3f9c8af9d3eee3b14c71122c5220a0. > > Reverting v3 and v2 so that we can take a simpler approach that touches far fewer files. > > ------------- > > Changes: > - all: https://git.openjdk.java.net/jdk/pull/37/files > - new: https://git.openjdk.java.net/jdk/pull/37/files/68995170..202af760 > > Webrevs: > - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=03 > - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=02-03 > > Stats: 110 lines in 40 files changed: 28 ins; 45 del; 37 mod > Patch: https://git.openjdk.java.net/jdk/pull/37.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37 > > PR: https://git.openjdk.java.net/jdk/pull/37 > From thartmann at openjdk.java.net Tue Sep 8 10:10:40 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 8 Sep 2020 10:10:40 GMT Subject: RFR: 8252889: C2 crashes when disabling InsertMemBarAfterArraycopy Message-ID: The InsertMemBarAfterArraycopy product flag (enabled by default) is broken. I propose to simply remove it. The corresponding CSR (JDK-8252890) is still waiting for approval. Thanks, Tobias ------------- Commit messages: - 8252889: C2 crashes when disabling InsertMemBarAfterArraycopy Changes: https://git.openjdk.java.net/jdk/pull/69/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=69&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252889 Stats: 17 lines in 3 files changed: 1 ins; 15 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/69.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/69/head:pull/69 PR: https://git.openjdk.java.net/jdk/pull/69 From shade at openjdk.java.net Tue Sep 8 10:23:03 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 8 Sep 2020 10:23:03 GMT Subject: RFR: 8252889: C2 crashes when disabling InsertMemBarAfterArraycopy In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 10:04:35 GMT, Tobias Hartmann wrote: > The InsertMemBarAfterArraycopy product flag (enabled by default) is broken. I propose to simply remove it. > The corresponding CSR (JDK-8252890) is still waiting for approval. > > Thanks, > Tobias Synopsis might be changed to "Obsolete -XX:+InsertMemBarAfterArraycopy". src/hotspot/share/runtime/arguments.cpp line 556: > 554: { "UseSemaphoreGCThreadsSynchronization", JDK_Version::undefined(), JDK_Version::jdk(16), JDK_Version::jdk(17) }, > 555: { "ForceNUMA", JDK_Version::jdk(15), JDK_Version::jdk(16), JDK_Version::jdk(17) }, > 556: { "InsertMemBarAfterArraycopy", JDK_Version::undefined(), JDK_Version::jdk(16), JDK_Version::jdk(17) }, This seems like a product flag, so needs to follow `ForceNUMA` example? E.g. 16 -> 17 -> 18? And a provisional CSR? src/hotspot/share/opto/macroArrayCopy.cpp line 1106: > 1104: RegionNode* slow_region = new RegionNode(1); > 1105: transform_later(slow_region); > 1106: This cleanup does not seem related? ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/69 From david.holmes at oracle.com Tue Sep 8 10:42:54 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Sep 2020 20:42:54 +1000 Subject: RFR: 8252871: fatal error: must own lock JvmtiThreadState_lock In-Reply-To: <_CymPcNGFQfEGh-pUsr2XHpavaR7gCjCGm92XOkQIJQ=.76cb76e8-6422-432b-96f4-00b38dd04412@github.com> References: <89Sl3sTUIGnLL04rLqKd2nw0q_W7jSnLHaT2urJu2xE=.0ffbc7a7-92ad-4514-926e-7ee0d1416fea@github.com> <_CymPcNGFQfEGh-pUsr2XHpavaR7gCjCGm92XOkQIJQ=.76cb76e8-6422-432b-96f4-00b38dd04412@github.com> Message-ID: <8073444c-a146-348c-9ba3-707bbff9470b@oracle.com> Hi Robbin, On 8/09/2020 5:39 pm, Robbin Ehn wrote: > Hi David, > >>> When these two methods (set_frame_pop/clear_frame_pop) are called in a handshake the requesting thread will have lock >>> the JvmtiThreadState_lock. But the thread executing one of these in the handshake may not be the owner. >> >> Ouch! We continue to get bitten by the fact the executor of a handshake >> operation is not known a-priori. :( >> > > We could add this. But I would prefer not doing it in this bug fix. Okay we can put in the current proposed fix to get the test working again. Please file a new bug to fix the underlying locking problem. >>> So we only check that JvmtiThreadState_lock is locked. >> >> That avoids the problem but it is not really a sufficient check - we >> need to know that it is the handshaker thread that owns the lock and >> that it acquired it purely for the purpose of this handshake operation! >> > > Right now we know that because I traced the code :) I'm sure you get my point though. :) > As I said I can make the requesting thread known to execution thread, > but I would really prefer not doing that in this bug fix. > >> More importantly this issue shows that the locking code is in fact >> incorrect. We are on very dangerous ground if we are going to allow >> locks to be "proxied" in this fashion! This is akin to reintroducing >> "sneaky locks"! > > A problem is that we use a safepoiting global lock to protect per thread resource. > The way we get around this with safepoints is: > "assert_locked_or_safepoint" (assert may be passed by a non-JavaThread or JavaThread in blocked/native without lock > during a safepoint (safepoint + VM thread would fix that)) Which have this in it: > // see if invoker of VM operation owns it > VM_Operation* op = VMThread::vm_operation(); > if (op != NULL && op->calling_thread() == lock->owner()) return; > > So we already have proxied locks and in other cases just avoiding them (by just checking if at safepoint). Okay ... we know that the VMThread and safepoint VMops are special, and always have been special, and people absolutely loathe the things we did in supporting that special-ness and we (well you, Erik, Patricio, Dan) have been working hard to get rid of a lot of that special code. So I can't accept an argument that it is okay to take VMThread/VMop special behaviour (e.g. lock proxying) and now spread it around to make other special cases. > And as I said a few times now, I said I can make the requesting thread known to execution thread, > but I would really prefer not doing that in this bug fix. Understood. I have a general concern with locking in relation to handshakes, that we cannot actually get rid of all the special handling that pertained to safepoints (safepoint-check-always/never, lock ranking) just because we now use handshakes. We have the same kinds of deadlock concerns if a handshake operation tries to take a lock and might block the thread. So same problem as safepoints and locks but no supporting code to try and help us with that. So if we cannot simply grab the necessary locks as part of the handshake operation, then we need a way to ensure locking correctness prior to the op - and the simplest seems to be that the handshaker does the necessary locking and the handshake mechanism allows us to ensure the handshaker executes the operation not the target. Thanks, David ----- >> >> If a handshake operation can be executed by either the target thread or >> the handshaker thread, and locks are required, then they will have to be >> acquired in the context of the handshake operation. If we can't do that >> because of potential deadlocks in the handshake mechanism then I feel >> that handshakes have a serious flaw that needs to be rectified. Perhaps >> we need a way to force the operation to be executed by the handshaker so >> that they can setup the right execution environment prior to the handshake? > > The problem is that it's a safepointing lock. > Only executing the handshake by requester is an interesting idea, I'll investigate that. > >> >>> When verifying the callers to these methods I notice "clear_to_frame_pop" was unused, so instead of fixing it I remove >>> it. >> >> There is already a bug for that: >> >> https://bugs.openjdk.java.net/browse/JDK-8252816 >> >> so if this proceeds you should add that issue to the PR. > > Ok, I'll do that. > > Thanks for having a look, let me know howto proceed. > >> >> Thanks, >> David >> ----- > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/60 > From dholmes at openjdk.java.net Tue Sep 8 10:46:44 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 8 Sep 2020 10:46:44 GMT Subject: RFR: 8252871: fatal error: must own lock JvmtiThreadState_lock In-Reply-To: <89Sl3sTUIGnLL04rLqKd2nw0q_W7jSnLHaT2urJu2xE=.0ffbc7a7-92ad-4514-926e-7ee0d1416fea@github.com> References: <89Sl3sTUIGnLL04rLqKd2nw0q_W7jSnLHaT2urJu2xE=.0ffbc7a7-92ad-4514-926e-7ee0d1416fea@github.com> Message-ID: On Mon, 7 Sep 2020 14:14:28 GMT, Robbin Ehn wrote: > When these two methods (set_frame_pop/clear_frame_pop) are called in a handshake the requesting thread will have lock > the JvmtiThreadState_lock. But the thread executing one of these in the handshake may not be the owner. > So we only check that JvmtiThreadState_lock is locked. > > When verifying the callers to these methods I notice "clear_to_frame_pop" was unused, so instead of fixing it I remove > it. > Passes testing locally, still running T3 and T7. > > Now passed! Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/60 From rehn at openjdk.java.net Tue Sep 8 11:16:45 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 8 Sep 2020 11:16:45 GMT Subject: RFR: 8252871: fatal error: must own lock JvmtiThreadState_lock In-Reply-To: References: <89Sl3sTUIGnLL04rLqKd2nw0q_W7jSnLHaT2urJu2xE=.0ffbc7a7-92ad-4514-926e-7ee0d1416fea@github.com> Message-ID: On Tue, 8 Sep 2020 10:44:24 GMT, David Holmes wrote: >> When these two methods (set_frame_pop/clear_frame_pop) are called in a handshake the requesting thread will have lock >> the JvmtiThreadState_lock. But the thread executing one of these in the handshake may not be the owner. >> So we only check that JvmtiThreadState_lock is locked. >> >> When verifying the callers to these methods I notice "clear_to_frame_pop" was unused, so instead of fixing it I remove >> it. >> Passes testing locally, still running T3 and T7. >> >> Now passed! > > Marked as reviewed by dholmes (Reviewer). Hi David, > Okay we can put in the current proposed fix to get the test working > again. Please file a new bug to fix the underlying locking problem. I created https://bugs.openjdk.java.net/browse/JDK-8252902 Please feel free to add sub-task, edit or change if I missed anything. Thanks, Robbin > > > > > So we only check that JvmtiThreadState_lock is locked. > > > > > > > > > That avoids the problem but it is not really a sufficient check - we > > > need to know that it is the handshaker thread that owns the lock and > > > that it acquired it purely for the purpose of this handshake operation! > > > > > > Right now we know that because I traced the code :) > > I'm sure you get my point though. :) > > > As I said I can make the requesting thread known to execution thread, > > but I would really prefer not doing that in this bug fix. > > > More importantly this issue shows that the locking code is in fact > > > incorrect. We are on very dangerous ground if we are going to allow > > > locks to be "proxied" in this fashion! This is akin to reintroducing > > > "sneaky locks"! > > > > > > A problem is that we use a safepoiting global lock to protect per thread resource. > > The way we get around this with safepoints is: > > "assert_locked_or_safepoint" (assert may be passed by a non-JavaThread or JavaThread in blocked/native without lock > > during a safepoint (safepoint + VM thread would fix that)) Which have this in it: > > // see if invoker of VM operation owns it > > VM_Operation* op = VMThread::vm_operation(); > > if (op != NULL && op->calling_thread() == lock->owner()) return; > > So we already have proxied locks and in other cases just avoiding them (by just checking if at safepoint). > > Okay ... we know that the VMThread and safepoint VMops are special, and > always have been special, and people absolutely loathe the things we did > in supporting that special-ness and we (well you, Erik, Patricio, Dan) > have been working hard to get rid of a lot of that special code. So I > can't accept an argument that it is okay to take VMThread/VMop special > behaviour (e.g. lock proxying) and now spread it around to make other > special cases. > > > And as I said a few times now, I said I can make the requesting thread known to execution thread, > > but I would really prefer not doing that in this bug fix. > > Understood. > > I have a general concern with locking in relation to handshakes, that we > cannot actually get rid of all the special handling that pertained to > safepoints (safepoint-check-always/never, lock ranking) just because we > now use handshakes. We have the same kinds of deadlock concerns if a > handshake operation tries to take a lock and might block the thread. So > same problem as safepoints and locks but no supporting code to try and > help us with that. > > So if we cannot simply grab the necessary locks as part of the handshake > operation, then we need a way to ensure locking correctness prior to the > op - and the simplest seems to be that the handshaker does the necessary > locking and the handshake mechanism allows us to ensure the handshaker > executes the operation not the target. > > Thanks, > David > ----- ------------- PR: https://git.openjdk.java.net/jdk/pull/60 From ayang at openjdk.java.net Tue Sep 8 11:22:03 2020 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 8 Sep 2020 11:22:03 GMT Subject: Integrated: 8252859: Inconsistent use of alpha in class AbsSeq In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 10:53:36 GMT, Albert Mingkun Yang wrote: > Invert the meaning of `_alpha`, from `alpha` to `1-alpha`. > > Test: I instrumented the constructor of `AbsSeq` with `printf("%f\n", _alpha)` onto master and `printf("%f\n", 1.0 - > _alpha)` after the patch, and checked the output of `java --version` (G1, Parallel, Shenandoah, and Z) are the > same before and after. This pull request has now been integrated. Changeset: 76002747 Author: Albert Mingkun Yang Committer: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/76002747 Stats: 7 lines in 4 files changed: 1 ins; 0 del; 6 mod 8252859: Inconsistent use of alpha in class AbsSeq Reviewed-by: tschatzl, sjohanss ------------- PR: https://git.openjdk.java.net/jdk/pull/47 From thartmann at openjdk.java.net Tue Sep 8 11:28:07 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 8 Sep 2020 11:28:07 GMT Subject: RFR: 8252889: Obsolete -XX:+InsertMemBarAfterArraycopy In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 10:19:17 GMT, Aleksey Shipilev wrote: >> The InsertMemBarAfterArraycopy product flag (enabled by default) is broken. I propose to simply remove it. >> The corresponding CSR (JDK-8252890) is still waiting for approval. >> >> Thanks, >> Tobias > > src/hotspot/share/opto/macroArrayCopy.cpp line 1106: > >> 1104: RegionNode* slow_region = new RegionNode(1); >> 1105: transform_later(slow_region); >> 1106: > > This cleanup does not seem related? Yes but it does not seem justified to create a separate PR for removing dead code in the same file. > src/hotspot/share/runtime/arguments.cpp line 556: > >> 554: { "UseSemaphoreGCThreadsSynchronization", JDK_Version::undefined(), JDK_Version::jdk(16), JDK_Version::jdk(17) }, >> 555: { "ForceNUMA", JDK_Version::jdk(15), JDK_Version::jdk(16), JDK_Version::jdk(17) }, >> 556: { "InsertMemBarAfterArraycopy", JDK_Version::undefined(), JDK_Version::jdk(16), JDK_Version::jdk(17) }, > > This seems like a product flag, so needs to follow `ForceNUMA` example? E.g. 16 -> 17 -> 18? And a provisional CSR? Since the flag is broken, I think immediate obsoletion, rather than deprecation makes more sense. See also discussion in JDK-8252889. A CSR has been created (JDK-8252890). ------------- PR: https://git.openjdk.java.net/jdk/pull/69 From shade at openjdk.java.net Tue Sep 8 11:33:16 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 8 Sep 2020 11:33:16 GMT Subject: RFR: 8252889: Obsolete -XX:+InsertMemBarAfterArraycopy In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 11:25:19 GMT, Tobias Hartmann wrote: >> src/hotspot/share/runtime/arguments.cpp line 556: >> >>> 554: { "UseSemaphoreGCThreadsSynchronization", JDK_Version::undefined(), JDK_Version::jdk(16), JDK_Version::jdk(17) }, >>> 555: { "ForceNUMA", JDK_Version::jdk(15), JDK_Version::jdk(16), JDK_Version::jdk(17) }, >>> 556: { "InsertMemBarAfterArraycopy", JDK_Version::undefined(), JDK_Version::jdk(16), JDK_Version::jdk(17) }, >> >> This seems like a product flag, so needs to follow `ForceNUMA` example? E.g. 16 -> 17 -> 18? And a provisional CSR? > > Since the flag is broken, I think immediate obsoletion, rather than deprecation makes more sense. See also discussion > in JDK-8252889. A CSR has been created (JDK-8252890). Okay then! >> src/hotspot/share/opto/macroArrayCopy.cpp line 1106: >> >>> 1104: RegionNode* slow_region = new RegionNode(1); >>> 1105: transform_later(slow_region); >>> 1106: >> >> This cleanup does not seem related? > > Yes but it does not seem justified to create a separate PR for removing dead code in the same file. Okay then. ------------- PR: https://git.openjdk.java.net/jdk/pull/69 From thartmann at openjdk.java.net Tue Sep 8 11:33:15 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 8 Sep 2020 11:33:15 GMT Subject: RFR: 8252889: Obsolete -XX:+InsertMemBarAfterArraycopy In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 11:29:09 GMT, Aleksey Shipilev wrote: >> The InsertMemBarAfterArraycopy product flag (enabled by default) is broken. I propose to simply remove it. >> The corresponding CSR (JDK-8252890) is still waiting for approval. >> >> Thanks, >> Tobias > > Marked as reviewed by shade (Reviewer). Thanks for the review, Aleksey! ------------- PR: https://git.openjdk.java.net/jdk/pull/69 From shade at openjdk.java.net Tue Sep 8 11:33:15 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 8 Sep 2020 11:33:15 GMT Subject: RFR: 8252889: Obsolete -XX:+InsertMemBarAfterArraycopy In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 10:04:35 GMT, Tobias Hartmann wrote: > The InsertMemBarAfterArraycopy product flag (enabled by default) is broken. I propose to simply remove it. > The corresponding CSR (JDK-8252890) is still waiting for approval. > > Thanks, > Tobias Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/69 From kim.barrett at oracle.com Tue Sep 8 12:28:21 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 8 Sep 2020 08:28:21 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> Message-ID: <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> > On Sep 7, 2020, at 10:56 AM, Eric Liu wrote: > I have tested 4 cases for those warnings: > a) Without my patch, without asan, gcc-8 and gcc-10 are OK. > b) Without my patch, with asan, gcc-8 has warned, gcc-10 is OK. > c) With my patch, without asan, gcc-8 and gcc-10 are OK. That?s *very* strange, since I get warnings in NetworkInterface getIndex and getFlags with gcc10.2 + your patch. > d) With my patch, with asan, gcc-8 is OK, gcc-10 has warned. > > Those warnings can be reported by both gcc-8 and gcc-10 only when asan enabled. Without > asan, no warning would be found even through some of them doesn't align with the documentation. >> src/java.base/unix/native/libnet/NetworkInterface.c >> 1298 memset((char *)&if2, 0, sizeof(if2)); >> 1299 strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1); >> 1300 if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; >> >> (in getIndex) >> >> So gcc8 does not warn about this, but gcc10 does? That would be a >> regression in gcc10 (and should be reported as such), because the >> documentation for -Wstringop-truncate is clear that the above is the >> proper idiom for avoiding the warning. > > Yse, I followed the documentation and gcc-8 does not warn about this, but > gcc-10 does (both with asan enabled). > >> Regardless, the memset on 1298 is useless. The code from before >> JDK-8250863 was the memset then the strncpy with >> sizeof(if2.ifr_name)-1 as the bound, which worked because the memset >> would have zeroed the last element. >> >> The change for JDK-8250863 did not follow the documented idiom though. >> >> It would be interesting to find out if removal of the memset changes >> anything. It's barely conceivable that it's confusing the heuristics >> used to decide whether -Wstringop-truncation should trigger. For >> example, the compiler might decide that the subsequent assignment of >> the last element is unnecessary because of the memset and optimize the >> assignment away, removing the idiomatic warning suppression. >> >> If gcc10 still warns about the above after removing the memset then I >> see little recourse but to use PRAGMA_STRINGOP_TRUNCATION_IGNORED here. >> >> Similarly for the strncpy in getFlags: >> 1362 memset((char *)&if2, 0, sizeof(if2)); >> 1363 strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1); >> 1364 if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; > > After removing the memset, gcc-10(10.1.0) still warns about it, gcc-8 and gcc-9 also. I?m confused. Above you said that with your patch + asan gcc-8 did not warn. Maybe what you are saying is that *just* removing the memset, and not applying your patch, for this case with asan warns with all of gcc-8,9,10? > I'm working on a new patch that to make both gcc-8 and gcc-10 happy. Good luck! I think I?m coming around to Florian?s ?never use strncpy? position, not so much because it?s the wrong function to use (though sometimes it probably is, or is being used wrongly), but because fighting with -Wstringop-truncation is just not worth the aggravation. From kim.barrett at oracle.com Tue Sep 8 12:29:42 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 8 Sep 2020 08:29:42 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <87o8mh7vxr.fsf@oldenburg2.str.redhat.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <8d4f0de2-4076-30d5-217c-458a4f74bebe@oracle.com> <87tuwgodbb.fsf@oldenburg2.str.redhat.com> <87sgbxhiao.fsf@oldenburg2.str.redhat.com> <387538C2-0BE8-43BB-9EF6-DE94786E5CD6@oracle.com> <87sgbuet1g.fsf@oldenburg2.str.redhat.com> <211FC028-8CE8-4296-BEC5-BE927558BDA0@oracle.com> <87o8mh7vxr.fsf@oldenburg2.str.redhat.com> Message-ID: <089F94C7-4126-4D7C-A3E9-33373B960D7F@oracle.com> > On Sep 7, 2020, at 5:55 AM, Florian Weimer wrote: > > * Kim Barrett: > >> And strlen is not even necessarily the best solution, as it likely >> introduces an additional otherwise unnecessary string traversal. For >> example, getFlags could be changed to reject an overly long ifname, >> without using strlen, thusly: >> >> strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name)); >> if (if2.ifr_name[sizeof(if2.ifr_name) - 1] != '\0') { >> return -1; >> } >> >> Unfortunately, gcc10 -Wstringop-truncation whines about this entirely >> reasonable code. > > Thanks, I filed this as: Thanks. Though it looks like the response is just ?don?t use strncpy?. From david.holmes at oracle.com Tue Sep 8 13:01:45 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Sep 2020 23:01:45 +1000 Subject: RFR: 8252889: C2 crashes when disabling InsertMemBarAfterArraycopy In-Reply-To: References: Message-ID: <62101ef9-d59e-9d59-9591-0707a16087e3@oracle.com> Hi Aleksey, On 8/09/2020 8:23 pm, Aleksey Shipilev wrote: > On Tue, 8 Sep 2020 10:04:35 GMT, Tobias Hartmann wrote: > >> The InsertMemBarAfterArraycopy product flag (enabled by default) is broken. I propose to simply remove it. >> The corresponding CSR (JDK-8252890) is still waiting for approval. >> >> Thanks, >> Tobias > > Synopsis might be changed to "Obsolete -XX:+InsertMemBarAfterArraycopy". > > src/hotspot/share/runtime/arguments.cpp line 556: > >> 554: { "UseSemaphoreGCThreadsSynchronization", JDK_Version::undefined(), JDK_Version::jdk(16), JDK_Version::jdk(17) }, >> 555: { "ForceNUMA", JDK_Version::jdk(15), JDK_Version::jdk(16), JDK_Version::jdk(17) }, >> 556: { "InsertMemBarAfterArraycopy", JDK_Version::undefined(), JDK_Version::jdk(16), JDK_Version::jdk(17) }, > > This seems like a product flag, so needs to follow `ForceNUMA` example? E.g. 16 -> 17 -> 18? And a provisional CSR? Product flags can be directly obsoleted without being deprecated first if they are basically non-functional, as this one seems to be. Cheers, David ----- > src/hotspot/share/opto/macroArrayCopy.cpp line 1106: > >> 1104: RegionNode* slow_region = new RegionNode(1); >> 1105: transform_later(slow_region); >> 1106: > > This cleanup does not seem related? > > ------------- > > Changes requested by shade (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/69 > From erikj at openjdk.java.net Tue Sep 8 13:04:24 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 8 Sep 2020 13:04:24 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 11:23:28 GMT, Aleksei Voitylov wrote: > continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html > >> The download side of using JNI in these tests is that it complicates the >> setup a bit for those that run jtreg directly and/or just build the JDK >> and not the test libraries. You could reduce this burden a bit by >> limiting the load library/isMusl check to Linux only, meaning isMusl >> would not be called on other platforms. >> >> The alternative you suggest above might indeed be better. I assume you >> don't mean splitting the tests but rather just adding a second @test >> description so that the vm.musl case runs the test with a system >> property that allows the test know the expected load library path behavior. > > I have updated the PR to split the two tests in multiple @test s. > >> The updated comment in java_md.c in this looks good. A minor comment on >> Platform.isBusybox is Files.isSymbolicLink returning true implies that >> the link exists so no need to check for exists too. Also the >> if-then-else style for the new class in ProcessBuilder/Basic.java is >> inconsistent with the rest of the test so it stands out. > > Thank you, these changes are done in the updated PR. > >> Given the repo transition this weekend then I assume you'll create a PR >> for the final review at least. Also I see JEP 386 hasn't been targeted >> yet but I assume Boris, as owner, will propose-to-target and wait for it >> to be targeted before it is integrated. > > Yes. How can this be best accomplished with the new git workflow? > - we can continue the review process till the end and I will request the integration to happen only after the JEP is > targeted. I guess this step is now done by typing "slash integrate" in a comment. > - we can pause the review process now until the JEP is targeted. > > In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here. Build changes look ok. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/49 From dholmes at openjdk.java.net Tue Sep 8 13:27:17 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 8 Sep 2020 13:27:17 GMT Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v5] In-Reply-To: References: Message-ID: > This is a rather large but generally simple cleanup. > > We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify > this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(), > which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was > also added to allow use in cases where we start with "const Thread *". Summary of changes: > - changed raw casts to use as_Java_thread() > - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread() > - Removed checks that are checking the type system e.g. > void foo(JavaThread* t) { > assert(t->is_Java_thread(), "must be") > the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry > about that then we would need asserts like this on every method that expects a JavaThread! The right place for the > assertion is at the head of any such call chain. > - Removed asserts that are already guaranteed in the caller. > - Use JavaThread::current() where appropriate. > - Use pre-existing "thread" variable where available rather than casting THREAD > > Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have > been missed. > Testing: tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: This is a simpler approach to use the static_cast. Changes: - Change C-style cast to static_cast and move function definitions so this works. - Use overloading for const and non-const versions of as_Java_thread(). - Update copyright years. Re-testing builds in tiers 1-5. Thanks. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/37/files - new: https://git.openjdk.java.net/jdk/pull/37/files/202af760..50dd8b38 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=03-04 Stats: 31 lines in 12 files changed: 10 ins; 6 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/37.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37 PR: https://git.openjdk.java.net/jdk/pull/37 From rehn at openjdk.java.net Tue Sep 8 13:49:41 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 8 Sep 2020 13:49:41 GMT Subject: Integrated: 8252871: fatal error: must own lock JvmtiThreadState_lock In-Reply-To: <89Sl3sTUIGnLL04rLqKd2nw0q_W7jSnLHaT2urJu2xE=.0ffbc7a7-92ad-4514-926e-7ee0d1416fea@github.com> References: <89Sl3sTUIGnLL04rLqKd2nw0q_W7jSnLHaT2urJu2xE=.0ffbc7a7-92ad-4514-926e-7ee0d1416fea@github.com> Message-ID: On Mon, 7 Sep 2020 14:14:28 GMT, Robbin Ehn wrote: > When these two methods (set_frame_pop/clear_frame_pop) are called in a handshake the requesting thread will have lock > the JvmtiThreadState_lock. But the thread executing one of these in the handshake may not be the owner. > So we only check that JvmtiThreadState_lock is locked. > > When verifying the callers to these methods I notice "clear_to_frame_pop" was unused, so instead of fixing it I remove > it. > Passes testing locally, still running T3 and T7. > > Now passed! This pull request has now been integrated. Changeset: 704f784c Author: Robbin Ehn URL: https://git.openjdk.java.net/jdk/commit/704f784c Stats: 26 lines in 4 files changed: 24 ins; 0 del; 2 mod 8252871: fatal error: must own lock JvmtiThreadState_lock 8252816: JvmtiEnvThreadState::clear_to_frame_pop() is not used Reviewed-by: ysuenaga, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/60 From dnsimon at openjdk.java.net Tue Sep 8 15:11:53 2020 From: dnsimon at openjdk.java.net (Doug Simon) Date: Tue, 8 Sep 2020 15:11:53 GMT Subject: RFR: 8252898: remove bulk registration of JFR CompilerPhaseType names Message-ID: The changes made in [JDK-8193210](https://bugs.openjdk.java.net/browse/JDK-8193210) support only [bulk registration](https://github.com/openjdk/jdk/blob/4e6a4af1866d0007d368b78bf78b6a8e1c8be425/src/hotspot/share/compiler/compilerEvent.hpp#L75) of compiler phase names with JFR. However, Graal only registers compiler phase names upon first execution of the phase since the set of phases is not known during VM initialization. This means registration of a Graal phase name needs to do unnecessary work, wrapping a single name into an array to conform to the bulk registration API. This pull request updates the registration API to be in terms of a registering a single phase name. ------------- Commit messages: - 8252898: remove bulk registration of JFR CompilerPhaseType names Changes: https://git.openjdk.java.net/jdk/pull/77/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=77&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252898 Stats: 114 lines in 6 files changed: 31 ins; 41 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/77/head:pull/77 PR: https://git.openjdk.java.net/jdk/pull/77 From coleenp at openjdk.java.net Tue Sep 8 15:41:25 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 8 Sep 2020 15:41:25 GMT Subject: RFR: 8252794: Creation of JNIMethodBlock should be done with a leaf lock In-Reply-To: <4v19DvtX5ykcCzTGeQ2tJ-mrRsfwsruMMS-XE9rLPMw=.6f419fd6-2bec-4c9e-a432-16497d589264@github.com> References: <4v19DvtX5ykcCzTGeQ2tJ-mrRsfwsruMMS-XE9rLPMw=.6f419fd6-2bec-4c9e-a432-16497d589264@github.com> Message-ID: <8OuaVtwxgY7m64oJZ4e8yhY8eeZEHFG-0I4SZnODwnQ=.3af8e436-d74d-455e-8b46-baed0747b9a8@github.com> On Mon, 7 Sep 2020 12:16:17 GMT, Robbin Ehn wrote: > JVM TI uses handshakes and sometimes need jmethod ids. > The CLD have an area where these ids are saved, which is created on first request for an id. > > The creation of this area should be done with a leaf lock. > In W.I.P. asynchronous handshake change-set we use a mutex instead of a semaphore for serializing the handshakes, > we thus get into lock ranks asserts. > > The CLD metaspace lock cannot be pushed down but we can use the same lock as for creating jmethod ids: > JmethodIdCreation_lock. And push that down. (special-2 is picked to be compatible with W.I.P. asynchronous handshake > change-set) > The reason for CLD metaspace lock being used now is that we have one per CLD instead of one global one. > > Testing passes: t1-3 Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/53 From shade at openjdk.java.net Tue Sep 8 16:24:26 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 8 Sep 2020 16:24:26 GMT Subject: RFR: 8252695: Shenandoah: clean up Graal enabled/disabled filter in tests [v2] In-Reply-To: References: Message-ID: > Drop `!vm.graal.enabled` since it is not required after JDK-8249000. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Fix some missing tests too ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/51/files - new: https://git.openjdk.java.net/jdk/pull/51/files/68d210a6..a5a5967c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=51&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=51&range=00-01 Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/51.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/51/head:pull/51 PR: https://git.openjdk.java.net/jdk/pull/51 From iklam at openjdk.java.net Tue Sep 8 16:28:49 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 8 Sep 2020 16:28:49 GMT Subject: RFR: 8244778: Archive full module graph in CDS Message-ID: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> This is the same patch as [8244778-archive-full-module-graph.v03](http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/) published in [hotspot-runtime-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041496.html). The rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. ------------- Commit messages: - fixed trailing spaces - Renamed ModuleEntry::write_growable_array - Update to latest repo (JDK-8251557); added comments - 8244778: Archive full module graph in CDS Changes: https://git.openjdk.java.net/jdk/pull/80/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=80&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244778 Stats: 2039 lines in 59 files changed: 1887 ins; 26 del; 126 mod Patch: https://git.openjdk.java.net/jdk/pull/80.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/80/head:pull/80 PR: https://git.openjdk.java.net/jdk/pull/80 From iklam at openjdk.java.net Tue Sep 8 16:45:41 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 8 Sep 2020 16:45:41 GMT Subject: RFR: 8244778: Archive full module graph in CDS In-Reply-To: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> References: <_zK0u_HNDIcmtKd9K8fTBGf2fuC9rqrWfkCz7IR0G5o=.d71f9618-f177-490f-8983-5191f5d8860b@github.com> Message-ID: On Tue, 8 Sep 2020 15:59:33 GMT, Ioi Lam wrote: > This is the same patch as > [8244778-archive-full-module-graph.v03](http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v03/) > published in > [hotspot-runtime-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041496.html). > The rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. In response to Lois Foltain's comments on [hotspot-runtime-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-September/041616.html): > Minor nit in moduleEntry.cpp & packageEntry.cpp when dealing with the ModuleEntry's reads list and a PackageEntry's > exports list. The names of the methods to write and read those arrays is somewhat confusing. > > ModuleEntry::write_archived_entry_array > ModuleEntry::read_archived_entry_array > > At first I thought you were reading/writing an array of archived entries, not the array within an archived entry > itself. I was trying to think of a better name. Please consider adding a comment at line #400 & line #417 ahead of > those methods in moduleEntry.cpp to indicate that they are used for both reading/writing a ModuleEntry's reads list and > a PackageEntry's exports list. I renamed the functions to `ModuleEntry's::write_growable_array` and `ModuleEntry::restore_growable_array`, and added comments as you suggested. See commit [4f90e77](https://github.com/openjdk/jdk/pull/80/commits/4f90e77207de5fc7cf09a12fb89b75087be57225) // This function is used to archive ModuleEntry::_reads and PackageEntry::_qualified_exports. // GrowableArray cannot be directly archived, as it needs to be expandable at runtime. // Write it out as an Array, and convert it back to GrowableArray at runtime. Array* ModuleEntry::write_growable_array(GrowableArray* array) { > A question about this because a user's program can define modules post module initialization via > ModuleDescriptor.newModule(). See for example, tests within open/test/hotspot/jtreg/runtime/module/AccessCheck. So > all of these tests would trigger check_cds_restrictions() if -Xshare:dump was turned on. Is that a concern? Arbitrary user code cannot be executed during -Xshare:dump. The only way to do it is to use a JVMTI agent, which requires specifying `-XX:+AllowArchivingWithJavaAgent`. You can see an example in the [GCDuringDump.java](https://github.com/openjdk/jdk/blob/704f784c88ee282837c980948167e741e7227f27/test/hotspot/jtreg/runtime/cds/appcds/javaldr/GCDuringDump.java#L65) test. If the agent tries to define an extra module, it will get an `UnsupportedOperationException` thrown by `check_cds_restrictions()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/80 From shade at openjdk.java.net Tue Sep 8 17:47:13 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 8 Sep 2020 17:47:13 GMT Subject: Integrated: 8252695: Shenandoah: clean up Graal enabled/disabled filter in tests In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 11:54:38 GMT, Aleksey Shipilev wrote: > Drop `!vm.graal.enabled` since it is not required after JDK-8249000. This pull request has now been integrated. Changeset: 91a20ca7 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/91a20ca7 Stats: 58 lines in 17 files changed: 0 ins; 0 del; 58 mod 8252695: Shenandoah: clean up Graal enabled/disabled filter in tests Reviewed-by: zgu ------------- PR: https://git.openjdk.java.net/jdk/pull/51 From zgu at openjdk.java.net Tue Sep 8 17:47:12 2020 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 8 Sep 2020 17:47:12 GMT Subject: RFR: 8252695: Shenandoah: clean up Graal enabled/disabled filter in tests [v2] In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 16:24:26 GMT, Aleksey Shipilev wrote: >> Drop `!vm.graal.enabled` since it is not required after JDK-8249000. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Fix some missing tests too Marked as reviewed by zgu (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/51 From akozlov at azul.com Tue Sep 8 18:36:14 2020 From: akozlov at azul.com (Anton Kozlov) Date: Tue, 8 Sep 2020 21:36:14 +0300 Subject: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: <3834f328-d31f-0111-6ed3-afbe3fe3d9f7@redhat.com> Message-ID: <72a22b1b-2670-014d-8964-d08b0158fa46@azul.com> Hello Bernhard, All, On 26.08.2020 14:52, Bernhard Urban-Forster wrote: > On 25/08/2020 11:44, Andrew Haley wrote: >> Looks OK. It would be nice if you could get rid of some of the #ifndef >> _WIN64 stuff in common code by moving queries like icache_line_size() >> into os-specific files, but you may do that later. > > I agree, there are still a few opportunities to make it cleaner. I'll take care of it. How far have you gone with CPU feature and cache size detection? I have some time I can spend some time cleaning vm_version for aarch64, which I think leaks too much Linux details into the common CPU code. 1. The linux part of feature detection should probably go to os_cpu/xxx/vm_version_xxx.cpp. 2. CPU features detection stub [1] for some reason takes 550 bytes (and is allocated permanently in the code cache), constructs a frame, and probably can be replaced with just inline assembly at least for Linux. 3. dcpop feature is taken from /proc/cpuinfo[2], although it is also there in HWCAP[3]. 4. I'm a bit concerned about Feature_Flags[4] implicitly mirrors of Linux HWCAP. I think some code (e.g assert) should provide a hint about mapping. For example, HWCAP_ATOMIC implicitly mapped to CPU_LSE. As a note, Feature_Flags had also leaked into Graal, which should also be considered. ... I'm asking to avoid duplicating efforts. If you have done some significant work for vm_version that you're not ready to share yet, then OK, there is no rush. Otherwise, I can try to do something with these and anything else that may jump out after some work. In that case, the success criteria will be a better separation of common and Linux code, which should also simplify the Windows-aarch64 patch. Thanks, Anton [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp#L110 [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp#L211 [3] https://elixir.bootlin.com/linux/latest/source/arch/arm64/include/uapi/asm/hwcap.h#L39 [4] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/vm_version_aarch64.hpp#L91 From iklam at openjdk.java.net Tue Sep 8 18:40:33 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 8 Sep 2020 18:40:33 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation Message-ID: This is the same patch as [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/) published in [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html). The rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. ------------- Commit messages: - 8243208: Clean up JVMFlag implementation Changes: https://git.openjdk.java.net/jdk/pull/82/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8243208 Stats: 2034 lines in 45 files changed: 695 ins; 516 del; 823 mod Patch: https://git.openjdk.java.net/jdk/pull/82.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/82/head:pull/82 PR: https://git.openjdk.java.net/jdk/pull/82 From luhenry at microsoft.com Tue Sep 8 19:09:18 2020 From: luhenry at microsoft.com (Ludovic Henry) Date: Tue, 8 Sep 2020 19:09:18 +0000 Subject: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: <72a22b1b-2670-014d-8964-d08b0158fa46@azul.com> References: <3834f328-d31f-0111-6ed3-afbe3fe3d9f7@redhat.com> <72a22b1b-2670-014d-8964-d08b0158fa46@azul.com> Message-ID: Hi Anton, You can find the diff at https://gist.github.com/luhenry/d981f5fe7e9f1a1ad8cd3292b5e75cc4 (we are in the process of upstreaming it). > 1. The linux part of feature detection should probably go to os_cpu/xxx/vm_version_xxx.cpp. It probably should indeed. I'd do the work for the macOS-AArch64 port, and I would adapt the windows-AArch64 port whichever lands first. > 2. CPU features detection stub [1] for some reason takes 550 bytes (and is allocated permanently in the code cache), constructs a frame, and probably can be replaced with just inline assembly at least for Linux. I agree, especially since `ctr_el0` is not even accessible on Windows. I'm happy to go for inline assembly or a dedicated assembly file. We need to keep it in `os_cpu` (especially for inline assembly) as it will need to be different for Windows at least (even for macOS, since the compiler is different and some platform specifics quirks). > 3. dcpop feature is taken from /proc/cpuinfo[2], although it is also there in HWCAP[3]. There is no equivalent of /proc/cpuinfo on Windows, and we can only rely on `IsProcessorFeaturePresent`. I would make sure to keep that check in `os_cpu` for the same reason as above. > 4. I'm a bit concerned about Feature_Flags[4] implicitly mirrors of Linux HWCAP. I think some code (e.g assert) should provide a hint about mapping. For example, HWCAP_ATOMIC implicitly mapped to CPU_LSE. As a note, Feature_Flags had also leaked into Graal, which should also be considered. In the case of Feature_Falgs, I would not implicitly define Feature_Flags with HWCAP_*, so I would make sure that `_features` is not simply assigned with the result of `getauxval`. I would also do the mapping HWCAP -> Feature_Flags in the Linux-AArch64 specific code, so that HWCAP doesn't have to leak into the Windows or macOS codebase. > I'm asking to avoid duplicating efforts. If you have done some significant work for vm_version that you're not ready to share yet, then OK, there is no rush. Otherwise, I can try to do something with these and anything else that may jump out after some work. In that case, the success criteria will be a better separation of common and Linux code, which should also simplify the Windows-aarch64 patch. All our Windows-AArch64 changes have been made public (through upstreaming it directly to jdk/jdk or by publishing webrevs), and we have no major work in progress, other than getting the current patches to land. I would be very happy to follow along what you're doing on a public repository, and contribute whatever we can. As we discussed offline last week, we are working on our end to publish what we have so far. Thank you, Ludovic From coleenp at openjdk.java.net Tue Sep 8 19:10:16 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 8 Sep 2020 19:10:16 GMT Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v5] In-Reply-To: References: Message-ID: <4PyDCIaW4eAmRb-XXwMA94s0y-f6ZoIkGPDWY3azkLQ=.a6272f0c-6edc-49f4-a741-6b88bc351b6c@github.com> On Tue, 8 Sep 2020 13:27:17 GMT, David Holmes wrote: >> This is a rather large but generally simple cleanup. >> >> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify >> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(), >> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was >> also added to allow use in cases where we start with "const Thread *". Summary of changes: >> - changed raw casts to use as_Java_thread() >> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread() >> - Removed checks that are checking the type system e.g. >> void foo(JavaThread* t) { >> assert(t->is_Java_thread(), "must be") >> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry >> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the >> assertion is at the head of any such call chain. >> - Removed asserts that are already guaranteed in the caller. >> - Use JavaThread::current() where appropriate. >> - Use pre-existing "thread" variable where available rather than casting THREAD >> >> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have >> been missed. >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > This is a simpler approach to use the static_cast. Changes: > - Change C-style cast to static_cast and move function definitions so this works. > - Use overloading for const and non-const versions of as_Java_thread(). > - Update copyright years. > > Re-testing builds in tiers 1-5. > > Thanks. Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/37 From coleenp at openjdk.java.net Tue Sep 8 19:10:16 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 8 Sep 2020 19:10:16 GMT Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v5] In-Reply-To: <4PyDCIaW4eAmRb-XXwMA94s0y-f6ZoIkGPDWY3azkLQ=.a6272f0c-6edc-49f4-a741-6b88bc351b6c@github.com> References: <4PyDCIaW4eAmRb-XXwMA94s0y-f6ZoIkGPDWY3azkLQ=.a6272f0c-6edc-49f4-a741-6b88bc351b6c@github.com> Message-ID: On Tue, 8 Sep 2020 19:07:01 GMT, Coleen Phillimore wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> This is a simpler approach to use the static_cast. Changes: >> - Change C-style cast to static_cast and move function definitions so this works. >> - Use overloading for const and non-const versions of as_Java_thread(). >> - Update copyright years. >> >> Re-testing builds in tiers 1-5. >> >> Thanks. > > Marked as reviewed by coleenp (Reviewer). I'll look at v5 diffs but if I don't, this is still reviewed. Nice cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/37 From dnsimon at openjdk.java.net Tue Sep 8 21:05:21 2020 From: dnsimon at openjdk.java.net (Doug Simon) Date: Tue, 8 Sep 2020 21:05:21 GMT Subject: RFR: 8252898: remove bulk registration of JFR CompilerPhaseType names [v2] In-Reply-To: References: Message-ID: > The changes made in [JDK-8193210](https://bugs.openjdk.java.net/browse/JDK-8193210) support only [bulk > registration](https://github.com/openjdk/jdk/blob/4e6a4af1866d0007d368b78bf78b6a8e1c8be425/src/hotspot/share/compiler/compilerEvent.hpp#L75) > of compiler phase names with JFR. However, Graal only registers compiler phase names upon first execution of the phase > since the set of phases is not known during VM initialization. This means registration of a Graal phase name needs to > do unnecessary work, wrapping a single name into an array to conform to the bulk registration API. This pull request > updates the registration API to be in terms of a registering a single phase name. Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8252898: remove bulk registration of JFR CompilerPhaseType names ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/77/files - new: https://git.openjdk.java.net/jdk/pull/77/files/662f9854..740c5894 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=77&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=77&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/77.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/77/head:pull/77 PR: https://git.openjdk.java.net/jdk/pull/77 From david.holmes at oracle.com Tue Sep 8 22:05:51 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Sep 2020 08:05:51 +1000 Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v5] In-Reply-To: References: <4PyDCIaW4eAmRb-XXwMA94s0y-f6ZoIkGPDWY3azkLQ=.a6272f0c-6edc-49f4-a741-6b88bc351b6c@github.com> Message-ID: Thanks for the review Coleen! David On 9/09/2020 5:10 am, Coleen Phillimore wrote: > On Tue, 8 Sep 2020 19:07:01 GMT, Coleen Phillimore wrote: > >>> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >>> >>> This is a simpler approach to use the static_cast. Changes: >>> - Change C-style cast to static_cast and move function definitions so this works. >>> - Use overloading for const and non-const versions of as_Java_thread(). >>> - Update copyright years. >>> >>> Re-testing builds in tiers 1-5. >>> >>> Thanks. >> >> Marked as reviewed by coleenp (Reviewer). > > I'll look at v5 diffs but if I don't, this is still reviewed. Nice cleanup. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/37 > From adityam at openjdk.java.net Wed Sep 9 00:02:15 2020 From: adityam at openjdk.java.net (Aditya Mandaleeka) Date: Wed, 9 Sep 2020 00:02:15 GMT Subject: RFR: 8252889: Obsolete -XX:+InsertMemBarAfterArraycopy In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 10:04:35 GMT, Tobias Hartmann wrote: > The InsertMemBarAfterArraycopy product flag (enabled by default) is broken. I propose to simply remove it. > The corresponding CSR (JDK-8252890) is still waiting for approval. > > Thanks, > Tobias Not a reviewer, but this looks good to me. ------------- Marked as reviewed by adityam (Author). PR: https://git.openjdk.java.net/jdk/pull/69 From dholmes at openjdk.java.net Wed Sep 9 00:11:23 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 9 Sep 2020 00:11:23 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 11:23:28 GMT, Aleksei Voitylov wrote: > continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html > >> The download side of using JNI in these tests is that it complicates the >> setup a bit for those that run jtreg directly and/or just build the JDK >> and not the test libraries. You could reduce this burden a bit by >> limiting the load library/isMusl check to Linux only, meaning isMusl >> would not be called on other platforms. >> >> The alternative you suggest above might indeed be better. I assume you >> don't mean splitting the tests but rather just adding a second @test >> description so that the vm.musl case runs the test with a system >> property that allows the test know the expected load library path behavior. > > I have updated the PR to split the two tests in multiple @test s. > >> The updated comment in java_md.c in this looks good. A minor comment on >> Platform.isBusybox is Files.isSymbolicLink returning true implies that >> the link exists so no need to check for exists too. Also the >> if-then-else style for the new class in ProcessBuilder/Basic.java is >> inconsistent with the rest of the test so it stands out. > > Thank you, these changes are done in the updated PR. > >> Given the repo transition this weekend then I assume you'll create a PR >> for the final review at least. Also I see JEP 386 hasn't been targeted >> yet but I assume Boris, as owner, will propose-to-target and wait for it >> to be targeted before it is integrated. > > Yes. How can this be best accomplished with the new git workflow? > - we can continue the review process till the end and I will request the integration to happen only after the JEP is > targeted. I guess this step is now done by typing "slash integrate" in a comment. > - we can pause the review process now until the JEP is targeted. > > In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here. Attempting to use the GitHub UI for further review. If this doesn't work out well I will revert to direct email. make/autoconf/platform.m4 line 536: > 534: AC_SUBST(HOTSPOT_$1_CPU_DEFINE) > 535: > 536: if test "x$OPENJDK_$1_LIBC" = "xmusl"; then I'm not clear why we only check for musl when setting the HOTSPOT_$1_LIBC variable src/hotspot/os/linux/os_linux.cpp line 624: > 622: // confstr() from musl libc returns EINVAL for > 623: // _CS_GNU_LIBC_VERSION and _CS_GNU_LIBPTHREAD_VERSION > 624: os::Linux::set_libc_version("unknown"); This should be "musl - unknown" as we don't know an exact version but we do know that it is musl. src/hotspot/os/linux/os_linux.cpp line 625: > 623: // _CS_GNU_LIBC_VERSION and _CS_GNU_LIBPTHREAD_VERSION > 624: os::Linux::set_libc_version("unknown"); > 625: os::Linux::set_libpthread_version("unknown"); This should be "musl - unknown" as we don't know an exact version but we do know that it is musl. src/hotspot/share/runtime/abstract_vm_version.cpp line 263: > 261: #define LIBC_STR "-" XSTR(LIBC) > 262: #else > 263: #define LIBC_STR "" Again I'm not clear why we do nothing in the non-musl case? Shouldn't we be reporting glibc or musl? src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c line 284: > 282: // To improve portability across platforms and avoid conflicts > 283: // between GNU and XSI versions of strerror_r, plain strerror is used. > 284: // It's safe because this code is not used in any multithreaded environment. I still question this assertion. The issue is not that the current code path that leads to strerror use may be executed concurrently but that any other strerror use could be concurrent with this one. I would consider this a "must fix" if not for the fact we already use strerror in the code and so this doesn't really change the exposure to the problem. test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c line 282: > 280: > 281: pthread_attr_init(&thread_attr); > 282: pthread_attr_setstacksize(&thread_attr, stack_size); Just a comment in response to the explanation as to why this change is needed. If the default thread stacksize under musl is insufficient to successfully attach such a thread to the VM then this will cause problems for applications that embed the VM directly (or which otherwise directly attach existing threads). test/hotspot/jtreg/runtime/TLS/exestack-tls.c line 60: > 58: } > 59: > 60: #if defined(__GLIBC) Why do we use this form here but at line 30 we have: #ifdef __GLIBC__ ? ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/49 From dholmes at openjdk.java.net Wed Sep 9 00:57:31 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 9 Sep 2020 00:57:31 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 18:33:41 GMT, Ioi Lam wrote: > The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the > same patch as > [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/) > published in > [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html). The > rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. One query below and a couple of style nits. Otherwise LGTM! src/hotspot/share/runtime/flags/jvmFlagConstraintList.cpp line 220: > 218: > 219: bool status = true; > 220: for (int i=0; i 55: void* JVMFlagLimit::constraint_func() const { > 56: int i = _constraint_func; > 57: assert(0 <= i && i 96: } > 97: > 98: #define AS_TYPED_LIMIT(type) inline JVMTypedFlagLimit* as_ ## type() const { return > (JVMTypedFlagLimit*)this; } Is it possible to use static_cast here rather than C-style cast? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/82 From dholmes at openjdk.java.net Wed Sep 9 01:32:54 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 9 Sep 2020 01:32:54 GMT Subject: RFR: 8252794: Creation of JNIMethodBlock should be done with a leaf lock In-Reply-To: <4v19DvtX5ykcCzTGeQ2tJ-mrRsfwsruMMS-XE9rLPMw=.6f419fd6-2bec-4c9e-a432-16497d589264@github.com> References: <4v19DvtX5ykcCzTGeQ2tJ-mrRsfwsruMMS-XE9rLPMw=.6f419fd6-2bec-4c9e-a432-16497d589264@github.com> Message-ID: On Mon, 7 Sep 2020 12:16:17 GMT, Robbin Ehn wrote: > JVM TI uses handshakes and sometimes need jmethod ids. > The CLD have an area where these ids are saved, which is created on first request for an id. > > The creation of this area should be done with a leaf lock. > In W.I.P. asynchronous handshake change-set we use a mutex instead of a semaphore for serializing the handshakes, > we thus get into lock ranks asserts. > > The CLD metaspace lock cannot be pushed down but we can use the same lock as for creating jmethod ids: > JmethodIdCreation_lock. And push that down. (special-2 is picked to be compatible with W.I.P. asynchronous handshake > change-set) > The reason for CLD metaspace lock being used now is that we have one per CLD instead of one global one. > > Testing passes: t1-3 The locking strategy in this code is somewhat unclear. src/hotspot/share/oops/method.cpp line 2190: > 2188: // Also have to add the method to the list safely, which the cld lock > 2189: // protects as well. > 2190: MutexLocker ml(JmethodIdCreation_lock, Mutex::_no_safepoint_check_flag); The comment above this states: // Also have to add the method to the list safely, which the cld lock // protects as well. I don't know what list is being referred to here but either the comment is incorrect or else the change of lock is incorrect! src/hotspot/share/oops/method.cpp line 2214: > 2212: // Also have to add the method to the list safely, which the cld lock > 2213: // protects as well. > 2214: MutexLocker ml(JmethodIdCreation_lock, Mutex::_no_safepoint_check_flag); Ditto ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/53 From kim.barrett at oracle.com Wed Sep 9 03:26:56 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 8 Sep 2020 23:26:56 -0400 Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v4] In-Reply-To: <7c0fd793-e3a0-01df-0efe-0d144e6f20ea@oracle.com> References: <7c0fd793-e3a0-01df-0efe-0d144e6f20ea@oracle.com> Message-ID: > On Sep 8, 2020, at 6:06 AM, David Holmes wrote: > > Just to be clear please wait for v5 to appear before reviewing. I think you meant ?v4?, i.e. the 5th zero-based version? From kim.barrett at oracle.com Wed Sep 9 03:30:48 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 8 Sep 2020 23:30:48 -0400 Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v5] In-Reply-To: References: Message-ID: <7247893F-B0B5-468D-A9CD-9B9295750B62@oracle.com> > On Sep 8, 2020, at 9:27 AM, David Holmes wrote: > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > This is a simpler approach to use the static_cast. Changes: > - Change C-style cast to static_cast and move function definitions so this works. > - Use overloading for const and non-const versions of as_Java_thread(). > - Update copyright years. > > Re-testing builds in tiers 1-5. > > Thanks. > > ------------- > > Changes: > - all: https://git.openjdk.java.net/jdk/pull/37/files > - new: https://git.openjdk.java.net/jdk/pull/37/files/202af760..50dd8b38 > > Webrevs: > - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=04 > - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=03-04 > > Stats: 31 lines in 12 files changed: 10 ins; 6 del; 15 mod > Patch: https://git.openjdk.java.net/jdk/pull/37.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37 > > PR: https://git.openjdk.java.net/jdk/pull/37 I reviewed all of v4, not just the gc parts this time. ------------------------------------------------------------------------------ src/hotspot/share/classfile/systemDictionary.cpp The block from line 1646-1655 seems to be misindented. And was before too. ------------------------------------------------------------------------------ src/hotspot/share/gc/shared/barrierSet.cpp [removed] 45 assert(Thread::current()->is_Java_thread(), 46 "Expected main thread to be a JavaThread"); This was an intentional redundancy with the following JavaThread::current(), to provide a more informative error message. [Sorry about missing this on my first pass through.] ------------------------------------------------------------------------------ src/hotspot/share/jvmci/jvmciEnv.cpp 243 void JVMCIEnv::describe_pending_exception(bool clear) { 244 JavaThread* THREAD = JavaThread::current(); This change looks suspicious. The old code used Thread::current() here and later cast to a JavaThread*. But that use and cast is conditional, and might not be executed at all, depending on the result of !is_hotspot(). So previously if !is_hotspot() then the current thread could be a non-JavaThread. (At least locally; there could be things being called in the !is_hotspot() case that also require a current JavaThread.) It also looks like the THREAD variable could be eliminated and it's one use changed to JavaThread::current(). ------------------------------------------------------------------------------ src/hotspot/share/prims/jvm.cpp 992 assert(THREAD->is_Java_thread(), "must be a JavaThread"); It's not obvious why this assert is being removed. ------------------------------------------------------------------------------ src/hotspot/share/gc/shared/concurrentGCBreakpoints.cpp 63 #define assert_Java_thread() \ 64 assert(Thread::current()->is_Java_thread(), "precondition") 65 66 void ConcurrentGCBreakpoints::run_to_idle_impl(bool acquiring_control) { 67 assert_Java_thread(); 68 MonitorLocker ml(monitor()); => 63 void ConcurrentGCBreakpoints::run_to_idle_impl(bool acquiring_control) { 64 MonitorLocker ml(JavaThread::current(), monitor()); and related later changes in this file. I prefer the original code, which intentionally made the precondition check explicit. [Sorry about missing this on my first pass through.] ------------------------------------------------------------------------------ src/hotspot/share/runtime/objectMonitor.cpp 1255 bool ObjectMonitor::reenter(intx recursions, TRAPS) { 1256 Thread * const Self = THREAD; 1257 JavaThread * jt = Self->as_Java_thread(); The only use of Self could just be THREAD, which is also used in this function. And I don't see any references to jt at all here. Maybe that should just be an `assert(THREAD->is_Java_thread(), "precondition");`. Hm, there are other functions in this file that have a peculiar mix of Self/THREAD usage and bound but unused jt. Cleaning that up should probably be a separate task; this changeset is already quite big enough! ------------------------------------------------------------------------------ src/hotspot/share/services/management.cpp 2074 if (thread_id == 0) { // current thread 2075 return thread->cooked_allocated_bytes(); Indentation got messed up. ------------------------------------------------------------------------------ It seems like there are some places where if a function parameter were JavaThread* rather than Thread* then there wouldn't need to be a call to as_Java_thread. That is, use the type system to make sure the types are correct, rather than a debug-only runtime check. But that's something to look at as a followup. ------------------------------------------------------------------------------ From iklam at openjdk.java.net Wed Sep 9 04:56:25 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Sep 2020 04:56:25 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 00:48:08 GMT, David Holmes wrote: >> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the >> same patch as >> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/) >> published in >> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html). The >> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. > > src/hotspot/share/runtime/flags/jvmFlagLimit.cpp line 57: > >> 55: void* JVMFlagLimit::constraint_func() const { >> 56: int i = _constraint_func; >> 57: assert(0 <= i && i > Space after < please Fixed. > src/hotspot/share/runtime/flags/jvmFlagConstraintList.cpp line 220: > >> 218: >> 219: bool status = true; >> 220: for (int i=0; i > Spaces around binary operators please. Fixed. > src/hotspot/share/runtime/flags/jvmFlagLimit.hpp line 98: > >> 96: } >> 97: >> 98: #define AS_TYPED_LIMIT(type) inline JVMTypedFlagLimit* as_ ## type() const { return >> (JVMTypedFlagLimit*)this; } > > Is it possible to use static_cast here rather than C-style cast? I tried but got this error: invalid static_cast from type 'const JVMFlagLimit*' to type 'const JVMTypedFlagLimit*' ------------- PR: https://git.openjdk.java.net/jdk/pull/82 From iklam at openjdk.java.net Wed Sep 9 05:05:39 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Sep 2020 05:05:39 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v2] In-Reply-To: References: Message-ID: > The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the > same patch as > [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/) > published in > [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html). The > rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: (a) coding style nits and comments, (b) updated HOWTO in globals.hpp, (c) added JVMFlag::check_all_flag_declarations(), (d) removed product_rw which is not used by any flags ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/82/files - new: https://git.openjdk.java.net/jdk/pull/82/files/d85cbd63..2e387eb4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=00-01 Stats: 160 lines in 9 files changed: 75 ins; 32 del; 53 mod Patch: https://git.openjdk.java.net/jdk/pull/82.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/82/head:pull/82 PR: https://git.openjdk.java.net/jdk/pull/82 From iklam at openjdk.java.net Wed Sep 9 05:19:06 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Sep 2020 05:19:06 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v2] In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 00:55:07 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> (a) coding style nits and comments, (b) updated HOWTO in globals.hpp, (c) added JVMFlag::check_all_flag_declarations(), >> (d) removed product_rw which is not used by any flags > > One query below and a couple of style nits. Otherwise LGTM! Re: [Gerard Ziemski's comments on hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042868.html): > (1) The API JVMFlagLimit::get_constraint(flag) says ?constraint?, but it returns JVMFlagLimit* using different names > for the same thing - one calls it ?limit", the other uses ?constraint?. JVMFlagLimit is used for both constraints and ranges. I updated the comments: // A JVMFlagLimit is created for each JVMFlag that has a range() and/or constraint() in its declaration in // the globals_xxx.hpp file. // // To query the range information of a JVMFlag: // JVMFlagLimit::get_range(JVMFlag*) // JVMFlagLimit::get_range_at(int flag_enum) // If the given flag doesn't have a range, NULL is returned. // // To query the constraint information of a JVMFlag: // JVMFlagLimit::get_constraint(JVMFlag*) // JVMFlagLimit::get_constraint_at(int flag_enum) // If the given flag doesn't have a constraint, NULL is returned. > (3) Isn?t there a better way to treat the special cases in "JVMFlagRangeList::print?, without explicitly checking for > hardcoded function pointers? Or is it just not worth the effort, with only 2 such cases for now? So far there are only 2 cases so I think the explicit checking may be enough. If we have more cases in the future we can have a more general solution. > (5) I'm not sure how others feel about it, but I think I personally would find it helpful for macros like > ?DEFINE_RANGE_CHECK? to see a comment with a concrete example of macro expansion for some flag, just to see what it > works out to be. I think this macro is fairly easy to read, so adding an expanded example may not have much benefit: #define DEFINE_RANGE_CHECK(T) \ JVMFlag::Error JVMFlagRangeChecker::check_ ## T(T value, bool verbose) const { \ assert(exists(), "must be"); \ JVMFlagRange_ ## T range(_flag, _limit->as_ ## T()->min(), _limit->as_ ## T()->max()); \ return range.check_ ## T(value, verbose); \ } In [JDK-8081833](https://bugs.openjdk.java.net/browse/JDK-8081833), I plan to use templates to replaces the nearly identical code in jvmFlagRangeList.cpp/jvmFlagConstraintList.cpp, and these macros should go away. (I fixed other minor nits found by Gerard.) ------------- PR: https://git.openjdk.java.net/jdk/pull/82 From kim.barrett at oracle.com Wed Sep 9 05:27:14 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 9 Sep 2020 01:27:14 -0400 Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v5] In-Reply-To: <7247893F-B0B5-468D-A9CD-9B9295750B62@oracle.com> References: <7247893F-B0B5-468D-A9CD-9B9295750B62@oracle.com> Message-ID: > On Sep 8, 2020, at 11:30 PM, Kim Barrett wrote: > > I reviewed all of v4, not just the gc parts this time. I guess it was v5 I was reviewing. There seems to be an inconsistency in numbering. From thartmann at openjdk.java.net Wed Sep 9 06:05:01 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 9 Sep 2020 06:05:01 GMT Subject: RFR: 8252889: Obsolete -XX:+InsertMemBarAfterArraycopy In-Reply-To: References: Message-ID: <8wmJgGvGH1XKrlrj1r3xs5vG810IM7Xi4d4JU0ikKAo=.a3cb9787-9c78-4f4c-92f9-0d374ce490c0@github.com> On Tue, 8 Sep 2020 23:59:43 GMT, Aditya Mandaleeka wrote: >> The InsertMemBarAfterArraycopy product flag (enabled by default) is broken. I propose to simply remove it. >> The corresponding CSR (JDK-8252890) is still waiting for approval. >> >> Thanks, >> Tobias > > Not a reviewer, but this looks good to me. Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/69 From eric.c.liu at arm.com Wed Sep 9 06:06:51 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Wed, 9 Sep 2020 06:06:51 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> , <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> Message-ID: Hi Kim, > Kim Barrett on Sent: 08 September 2020 20:28 ? >> On Sep 7, 2020, at 10:56 AM, Eric Liu wrote: >> I have tested 4 cases for those warnings: >> a) Without my patch, without asan, gcc-8 and gcc-10 are OK. >> b) Without my patch, with asan, gcc-8 has warned, gcc-10 is OK. >> c) With my patch, without asan, gcc-8 and gcc-10 are OK. > That?s *very* strange, since I get warnings in NetworkInterface getIndex and getFlags > with gcc10.2 + your patch. Sorry for the mistake, gcc-10 exactly warn?about my patch. >> d) With my patch, with asan, gcc-8 is OK, gcc-10 has warned. >> >> Those warnings can be reported by both gcc-8 and gcc-10 only when asan enabled. Without >> asan, no warning would be found even through some of them doesn't align with the documentation. >>> src/java.base/unix/native/libnet/NetworkInterface.c >>> 1298???? memset((char *)&if2, 0, sizeof(if2)); >>> 1299???? strncpy(if2.ifr_name, name, sizeof(if2.ifr_name) - 1); >>> 1300???? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; >>> >>> (in getIndex) >>> >>> So gcc8 does not warn about this, but gcc10 does? That would be a >>> regression in gcc10 (and should be reported as such), because the >>> documentation for -Wstringop-truncate is clear that the above is the >>> proper idiom for avoiding the warning. >> >> Yse, I followed the documentation and gcc-8 does not warn about this, but >> gcc-10 does (both with asan enabled). >> >>> Regardless, the memset on 1298 is useless.? The code from before >>> JDK-8250863 was the memset then the strncpy with >>> sizeof(if2.ifr_name)-1 as the bound, which worked because the memset >>> would have zeroed the last element. >>> >>> The change for JDK-8250863 did not follow the documented idiom though. >>> >>> It would be interesting to find out if removal of the memset changes >>> anything.? It's barely conceivable that it's confusing the heuristics >>> used to decide whether -Wstringop-truncation should trigger.? For >>> example, the compiler might decide that the subsequent assignment of >>> the last element is unnecessary because of the memset and optimize the >>> assignment away, removing the idiomatic warning suppression. >>> >>> If gcc10 still warns about the above after removing the memset then I >>> see little recourse but to use PRAGMA_STRINGOP_TRUNCATION_IGNORED here. >>> >>> Similarly for the strncpy in getFlags: >>> 1362???? memset((char *)&if2, 0, sizeof(if2)); >>> 1363???? strncpy(if2.ifr_name, ifname, sizeof(if2.ifr_name) - 1); >>> 1364???? if2.ifr_name[sizeof(if2.ifr_name) - 1] = 0; >> >> After removing the memset, gcc-10(10.1.0) still warns about it, gcc-8 and gcc-9 also. > I?m confused.? Above you said that with your patch + asan gcc-8 did not warn. > Maybe what you are saying is that *just* removing the memset, and not applying > your patch, for this case with asan warns with all of gcc-8,9,10? Sorry for my bad expression. Actually removing memset could not make things better. My patch + asan would annoy gcc-10, removing memset changed nothing. For gcc-8 and gcc-9 part, without my patch they would warn about with asan, and removing memset can not fix them as well. Thanks, Eric From iklam at openjdk.java.net Wed Sep 9 06:28:59 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Sep 2020 06:28:59 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v3] In-Reply-To: References: Message-ID: > The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the > same patch as > [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/) > published in > [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html). The > rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed JVMFlag::is_writeable() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/82/files - new: https://git.openjdk.java.net/jdk/pull/82/files/2e387eb4..10246284 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/82.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/82/head:pull/82 PR: https://git.openjdk.java.net/jdk/pull/82 From david.holmes at oracle.com Wed Sep 9 07:08:00 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Sep 2020 17:08:00 +1000 Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v5] In-Reply-To: <7247893F-B0B5-468D-A9CD-9B9295750B62@oracle.com> References: <7247893F-B0B5-468D-A9CD-9B9295750B62@oracle.com> Message-ID: Hi Kim, On 9/09/2020 1:30 pm, Kim Barrett wrote: >> On Sep 8, 2020, at 9:27 AM, David Holmes wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> This is a simpler approach to use the static_cast. Changes: >> - Change C-style cast to static_cast and move function definitions so this works. >> - Use overloading for const and non-const versions of as_Java_thread(). >> - Update copyright years. >> >> Re-testing builds in tiers 1-5. >> >> Thanks. >> >> ------------- >> >> Changes: >> - all: https://git.openjdk.java.net/jdk/pull/37/files >> - new: https://git.openjdk.java.net/jdk/pull/37/files/202af760..50dd8b38 >> >> Webrevs: >> - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=04 >> - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=03-04 >> >> Stats: 31 lines in 12 files changed: 10 ins; 6 del; 15 mod >> Patch: https://git.openjdk.java.net/jdk/pull/37.diff >> Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37 >> >> PR: https://git.openjdk.java.net/jdk/pull/37 > > I reviewed all of v4, not just the gc parts this time. Thank you. Note that I've been using the version as given in the email subject (i.e. v5 here) not the "range" value (04 here) listed in the webrev links. Sorry for any confusion. > ------------------------------------------------------------------------------ > src/hotspot/share/classfile/systemDictionary.cpp > > The block from line 1646-1655 seems to be misindented. And was before too. Fixed. > ------------------------------------------------------------------------------ > src/hotspot/share/gc/shared/barrierSet.cpp > [removed] > 45 assert(Thread::current()->is_Java_thread(), > 46 "Expected main thread to be a JavaThread"); > > This was an intentional redundancy with the following JavaThread::current(), > to provide a more informative error message. > > [Sorry about missing this on my first pass through.] Reverted. > ------------------------------------------------------------------------------ > src/hotspot/share/jvmci/jvmciEnv.cpp > 243 void JVMCIEnv::describe_pending_exception(bool clear) { > 244 JavaThread* THREAD = JavaThread::current(); > > This change looks suspicious. The old code used Thread::current() here and > later cast to a JavaThread*. But that use and cast is conditional, and > might not be executed at all, depending on the result of !is_hotspot(). So > previously if !is_hotspot() then the current thread could be a non-JavaThread. > > (At least locally; there could be things being called in the !is_hotspot() > case that also require a current JavaThread.) Yes - if you look at JNIAccessMark it manifests JavaThread::current() by default. > > It also looks like the THREAD variable could be eliminated and it's one use > changed to JavaThread::current(). Or I can keep it and also use it for the JNIAccessMark constructor. > ------------------------------------------------------------------------------ > src/hotspot/share/prims/jvm.cpp > 992 assert(THREAD->is_Java_thread(), "must be a JavaThread"); > > It's not obvious why this assert is being removed. The fact THREAD must be a JavaThread is already established by the JVM_ENTRY calls that then invoke this local method. > ------------------------------------------------------------------------------ > src/hotspot/share/gc/shared/concurrentGCBreakpoints.cpp > > 63 #define assert_Java_thread() \ > 64 assert(Thread::current()->is_Java_thread(), "precondition") > 65 > 66 void ConcurrentGCBreakpoints::run_to_idle_impl(bool acquiring_control) { > 67 assert_Java_thread(); > 68 MonitorLocker ml(monitor()); > > => > > 63 void ConcurrentGCBreakpoints::run_to_idle_impl(bool acquiring_control) { > 64 MonitorLocker ml(JavaThread::current(), monitor()); > > and related later changes in this file. > > I prefer the original code, which intentionally made the precondition check > explicit. The same precondition is already present in the use of JavaThread::current(). Is that not explicit enough? Plus the old code will manifest the current thread twice in debug builds. Cleaning up this kind of redundancy is one of the key aims here. :( > > [Sorry about missing this on my first pass through.] > > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/objectMonitor.cpp > 1255 bool ObjectMonitor::reenter(intx recursions, TRAPS) { > 1256 Thread * const Self = THREAD; > 1257 JavaThread * jt = Self->as_Java_thread(); > > The only use of Self could just be THREAD, which is also used in this > function. And I don't see any references to jt at all here. Maybe that > should just be an `assert(THREAD->is_Java_thread(), "precondition");`. > > Hm, there are other functions in this file that have a peculiar mix of > Self/THREAD usage and bound but unused jt. > > Cleaning that up should probably be a separate task; this changeset is > already quite big enough! Right, I tried to avoid the temptation of dealing with the Self/THREAD/jt mess in this change. I have another RFE filed that will do further cleanup here: https://bugs.openjdk.java.net/browse/JDK-8252685 > ------------------------------------------------------------------------------ > src/hotspot/share/services/management.cpp > 2074 if (thread_id == 0) { // current thread > 2075 return thread->cooked_allocated_bytes(); > > Indentation got messed up. Fixed. (I must remember to try the emacs fix to handle the JVM_ENTRY and other macros.) > ------------------------------------------------------------------------------ > > It seems like there are some places where if a function parameter were > JavaThread* rather than Thread* then there wouldn't need to be a call to > as_Java_thread. That is, use the type system to make sure the types are > correct, rather than a debug-only runtime check. But that's something to > look at as a followup. Yep - that same RFE: https://bugs.openjdk.java.net/browse/JDK-8252685 Thanks, David ----- > ------------------------------------------------------------------------------ > > From dholmes at openjdk.java.net Wed Sep 9 07:13:53 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 9 Sep 2020 07:13:53 GMT Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v6] In-Reply-To: References: Message-ID: > This is a rather large but generally simple cleanup. > > We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify > this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(), > which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was > also added to allow use in cases where we start with "const Thread *". Summary of changes: > - changed raw casts to use as_Java_thread() > - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread() > - Removed checks that are checking the type system e.g. > void foo(JavaThread* t) { > assert(t->is_Java_thread(), "must be") > the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry > about that then we would need asserts like this on every method that expects a JavaThread! The right place for the > assertion is at the head of any such call chain. > - Removed asserts that are already guaranteed in the caller. > - Use JavaThread::current() where appropriate. > - Use pre-existing "thread" variable where available rather than casting THREAD > > Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have > been missed. > Testing: tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Minor fixups from Kim's review. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/37/files - new: https://git.openjdk.java.net/jdk/pull/37/files/50dd8b38..9426d53b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=04-05 Stats: 15 lines in 4 files changed: 2 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/37.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37 PR: https://git.openjdk.java.net/jdk/pull/37 From rehn at openjdk.java.net Wed Sep 9 07:25:51 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 9 Sep 2020 07:25:51 GMT Subject: RFR: 8252794: Creation of JNIMethodBlock should be done with a leaf lock [v2] In-Reply-To: <4v19DvtX5ykcCzTGeQ2tJ-mrRsfwsruMMS-XE9rLPMw=.6f419fd6-2bec-4c9e-a432-16497d589264@github.com> References: <4v19DvtX5ykcCzTGeQ2tJ-mrRsfwsruMMS-XE9rLPMw=.6f419fd6-2bec-4c9e-a432-16497d589264@github.com> Message-ID: > JVM TI uses handshakes and sometimes need jmethod ids. > The CLD have an area where these ids are saved, which is created on first request for an id. > > The creation of this area should be done with a leaf lock. > In W.I.P. asynchronous handshake change-set we use a mutex instead of a semaphore for serializing the handshakes, > we thus get into lock ranks asserts. > > The CLD metaspace lock cannot be pushed down but we can use the same lock as for creating jmethod ids: > JmethodIdCreation_lock. And push that down. (special-2 is picked to be compatible with W.I.P. asynchronous handshake > change-set) > The reason for CLD metaspace lock being used now is that we have one per CLD instead of one global one. > > Testing passes: t1-3 Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Corrected comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/53/files - new: https://git.openjdk.java.net/jdk/pull/53/files/ec4eb407..0ca8c6cd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=53&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=53&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/53.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/53/head:pull/53 PR: https://git.openjdk.java.net/jdk/pull/53 From kbarrett at openjdk.java.net Wed Sep 9 07:32:00 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 9 Sep 2020 07:32:00 GMT Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space Message-ID: This is rework of initial change from before the transition to git. The initial RFR email is attached below. The primary change is to limit the number of partial array tasks in the queues for any given array. The original change just split up an array into N tasks that were all enqueued at once. But for a large array this could be a lot of tasks, leading to significant and unnecessary queue expansion. Instead we now limit the number of tasks for a given array based on the number of workers, and only gradually add tasks up to that limit. This gives other threads an opportunity to steal such tasks, while still keeping queue growth under control. Most of the calculation for this is handled by a new helper class, so this can later be shared with ParallelGC. The dispatch on array klass type for has also been changed. It now affirmatively breaks Project Valhalla, rather than quietly doing something that probably isn't what is actually wanted. I'll discuss with them so there is a plan for dealing with it when they take this update. Ran tier1-6 in mach5 and some local stress tests. Performance testing was unchanged from previous, except I wasn't able to reproduce the small specjbb2015 critical-jops improvement previously seen on one platform. My suspicion is that improvement was a statistical abberation. --- Initial RFR email --- RFR: 8158045: Improve large object handling during evacuation RFR: 8027761: Investigate fast-path for scanning only objects with references during gc RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space Please review this change to type dispatching and handling in G1's evacuation copying, in order to improve the hot paths and improve array handling. This change addresses several closely co-located enhancement requests; it seemed difficult to split them up in a sensible way. do_copy_to_survivor_space now gets the klass of the object being copied once, up front, for use in multiple places. This avoids fetching (including re-decoding when compressed) the klass multiple times. This addresses part of JDK-8027545. Moved check for and handling of string deduplication later, only applying it after the special array cases have been dealt with, since strings are not arrays. (They are header objects pointing to an array of character values.) Special case typeArray, doing nothing other than the copy, since they contain no oops that need to be processed. This addresses JDK-8027761. Changed handling of objArray, pushing all of the partial array tasks up front, rather than processing the current chunk after pushing a single task for the remaining work. This addresses JDK-8158045. As part of these, cached some more frequently accessed values in G1ParScanThreadState member variables. This addresses part of part of JDK-8027545. While both the old and new code will work for Project Valhalla, the handling of arrays should be updated for that project, which introduces new array types. Deleted a lingering reference to G1ParScanPartialArrayClosure that was deleted long ago (JDK-8035330, JDK 9). CR: https://bugs.openjdk.java.net/browse/JDK-8158045 https://bugs.openjdk.java.net/browse/JDK-8027761 https://bugs.openjdk.java.net/browse/JDK-8027545 Webrev: https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ Testing: tier1-3 performance testing - seems to be at worst performance neutral, with a statistically significant 3% improvement in specjbb2015 critical-jops seen on one platform. ------------- Commit messages: - limit partial array tasks, add length_addr() rather than breaking abstraction - Initial RFR for partial_arrays Changes: https://git.openjdk.java.net/jdk/pull/90/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=90&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8027545 Stats: 357 lines in 7 files changed: 298 ins; 29 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/90.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/90/head:pull/90 PR: https://git.openjdk.java.net/jdk/pull/90 From rehn at openjdk.java.net Wed Sep 9 07:33:08 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 9 Sep 2020 07:33:08 GMT Subject: RFR: 8252794: Creation of JNIMethodBlock should be done with a leaf lock [v2] In-Reply-To: References: <4v19DvtX5ykcCzTGeQ2tJ-mrRsfwsruMMS-XE9rLPMw=.6f419fd6-2bec-4c9e-a432-16497d589264@github.com> Message-ID: On Wed, 9 Sep 2020 01:15:26 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Corrected comment > > src/hotspot/share/oops/method.cpp line 2190: > >> 2188: // Also have to add the method to the list safely, which the cld lock >> 2189: // protects as well. >> 2190: MutexLocker ml(JmethodIdCreation_lock, Mutex::_no_safepoint_check_flag); > > The comment above this states: > // Also have to add the method to the list safely, which the cld lock > // protects as well. > I don't know what list is being referred to here but either the comment is incorrect or else the change of lock is > incorrect! We create the list with: `cld->set_jmethod_ids(new JNIMethodBlock(capacity));` And add to the list: `return (jmethodID)cld->jmethod_ids()->add_method(m);` I removed 'cld' from comment. > src/hotspot/share/oops/method.cpp line 2214: > >> 2212: // Also have to add the method to the list safely, which the cld lock >> 2213: // protects as well. >> 2214: MutexLocker ml(JmethodIdCreation_lock, Mutex::_no_safepoint_check_flag); > > Ditto Ditto fix ------------- PR: https://git.openjdk.java.net/jdk/pull/53 From aph at redhat.com Wed Sep 9 08:27:14 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 Sep 2020 09:27:14 +0100 Subject: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: <3834f328-d31f-0111-6ed3-afbe3fe3d9f7@redhat.com> <72a22b1b-2670-014d-8964-d08b0158fa46@azul.com> Message-ID: On 08/09/2020 20:09, Ludovic Henry wrote: > All our Windows-AArch64 changes have been made public (through upstreaming it directly to jdk/jdk or by publishing webrevs), and we have no major work in progress, other than getting the current patches to land. To land where? aarch64/windows or jdk/jdk? If you're actually ready for mainline, it'll be time to prepare the integrated patch for import. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From kustos at gmx.net Wed Sep 9 08:27:16 2020 From: kustos at gmx.net (Philippe Marschall) Date: Wed, 9 Sep 2020 10:27:16 +0200 Subject: How to proceed with 8138732 Message-ID: Hello I started working on 8138732 [2] as described in the issue [1]. However the question about the impact and coordination with other projects came up, eg.: - projects that implement their own intrinsics - Graal - somebody else? How do we want to address this and coordinate with these projects? Given all the possible impact do we still want the issue to be implemented as described? Or do we want to have it implemented differently or not at all? [1] https://bugs.openjdk.java.net/browse/JDK-8138732 [2] https://github.com/openjdk/jdk/pull/45 Cheers Philippe From kbarrett at openjdk.java.net Wed Sep 9 08:52:55 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 9 Sep 2020 08:52:55 GMT Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space In-Reply-To: References: Message-ID: <7qUN9LOG-BBHkL3IplZui752G0MagF3tDpNuXePDrzQ=.15d64a60-d6de-4373-8ced-d21c6172261d@github.com> On Wed, 9 Sep 2020 07:24:27 GMT, Kim Barrett wrote: > This is rework of initial change from before the transition to git. > The initial RFR email is attached below. > > The primary change is to limit the number of partial array tasks in > the queues for any given array. The original change just split up an > array into N tasks that were all enqueued at once. But for a large > array this could be a lot of tasks, leading to significant and > unnecessary queue expansion. Instead we now limit the number of tasks > for a given array based on the number of workers, and only gradually > add tasks up to that limit. This gives other threads an opportunity > to steal such tasks, while still keeping queue growth under control. > > Most of the calculation for this is handled by a new helper class, so > this can later be shared with ParallelGC. > > The dispatch on array klass type for has also been changed. It now > affirmatively breaks Project Valhalla, rather than quietly doing > something that probably isn't what is actually wanted. I'll discuss > with them so there is a plan for dealing with it when they take this > update. > > Ran tier1-6 in mach5 and some local stress tests. > > Performance testing was unchanged from previous, except I wasn't able > to reproduce the small specjbb2015 critical-jops improvement > previously seen on one platform. My suspicion is that improvement was > a statistical abberation. > > --- Initial RFR email --- > > RFR: 8158045: Improve large object handling during evacuation > RFR: 8027761: Investigate fast-path for scanning only objects with references during gc > RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space > > Please review this change to type dispatching and handling in G1's > evacuation copying, in order to improve the hot paths and improve array > handling. This change addresses several closely co-located enhancement > requests; it seemed difficult to split them up in a sensible way. > > do_copy_to_survivor_space now gets the klass of the object being copied > once, up front, for use in multiple places. This avoids fetching (including > re-decoding when compressed) the klass multiple times. This addresses part > of JDK-8027545. > > Moved check for and handling of string deduplication later, only applying it > after the special array cases have been dealt with, since strings are not > arrays. (They are header objects pointing to an array of character values.) > > Special case typeArray, doing nothing other than the copy, since they > contain no oops that need to be processed. This addresses JDK-8027761. > > Changed handling of objArray, pushing all of the partial array tasks up > front, rather than processing the current chunk after pushing a single task > for the remaining work. This addresses JDK-8158045. > > As part of these, cached some more frequently accessed values in > G1ParScanThreadState member variables. This addresses part of part of > JDK-8027545. > > While both the old and new code will work for Project Valhalla, the handling > of arrays should be updated for that project, which introduces new array > types. > > Deleted a lingering reference to G1ParScanPartialArrayClosure that was > deleted long ago (JDK-8035330, JDK 9). > > CR: > https://bugs.openjdk.java.net/browse/JDK-8158045 > https://bugs.openjdk.java.net/browse/JDK-8027761 > https://bugs.openjdk.java.net/browse/JDK-8027545 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ > > Testing: > tier1-3 > > performance testing - seems to be at worst performance neutral, with a > statistically significant 3% improvement in specjbb2015 critical-jops seen > on one platform. The title for this review was supposed to be based on JDK-8158045 "Improve large object handling during evacuation", but because of [SKARA-634](https://bugs.openjdk.java.net/browse/SKARA-634) the last of the three associated issue commands was used, rather than the first. ------------- PR: https://git.openjdk.java.net/jdk/pull/90 From Alan.Bateman at oracle.com Wed Sep 9 08:55:23 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 9 Sep 2020 09:55:23 +0100 Subject: How to proceed with 8138732 In-Reply-To: References: Message-ID: <3f54e471-596a-c18b-014b-4b57e55d65fa@oracle.com> On 09/09/2020 09:27, Philippe Marschall wrote: > Hello > > I started working on 8138732 [2] as described in the issue [1]. However > the question about the impact and coordination with other projects came > up, eg.: > > ?- projects that implement their own intrinsics > ?- Graal > ?- somebody else? > > How do we want to address this and coordinate with these projects? > > Given all the possible impact do we still want the issue to be > implemented as described? Or do we want to have it implemented > differently or not at all? Maybe Igor Veresov or someone else on hotspot-compiler-dev that is familiar with the process for pulling Graal compiler changes from upstream could comment in case there is coordination needed. It's just a move/rename so shouldn't be too disruptive. There are several projects in OpenJDK with additional instrinics and they'll just need to switch over when they pull the change from the main repo, shouldn't be an issue. I did comment on the update to java.base's module-info.java as I don't expect that jdk.internal needs to be exported to jdk.jfr with the change. Once @PreviewFeature moves to java.lang.annotation then that package will be likely be "empty" so won't be exported to anyone. -Alan From kim.barrett at oracle.com Wed Sep 9 09:09:12 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 9 Sep 2020 05:09:12 -0400 Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v5] In-Reply-To: References: <7247893F-B0B5-468D-A9CD-9B9295750B62@oracle.com> Message-ID: Hi David. Thanks for clarifying some bits I was confused abut. >> src/hotspot/share/jvmci/jvmciEnv.cpp >> 243 void JVMCIEnv::describe_pending_exception(bool clear) { >> 244 JavaThread* THREAD = JavaThread::current(); >> This change looks suspicious. The old code used Thread::current() here and >> later cast to a JavaThread*. But that use and cast is conditional, and >> might not be executed at all, depending on the result of !is_hotspot(). So >> previously if !is_hotspot() then the current thread could be a non-JavaThread. >> (At least locally; there could be things being called in the !is_hotspot() >> case that also require a current JavaThread.) > > Yes - if you look at JNIAccessMark it manifests JavaThread::current() by default. > >> It also looks like the THREAD variable could be eliminated and it's one use >> changed to JavaThread::current(). > > Or I can keep it and also use it for the JNIAccessMark constructor. I see; good. >> src/hotspot/share/prims/jvm.cpp >> 992 assert(THREAD->is_Java_thread(), "must be a JavaThread"); >> It's not obvious why this assert is being removed. > > The fact THREAD must be a JavaThread is already established by the JVM_ENTRY calls that then invoke this local method. Right. I keep forgetting which of these macros does what with which kinds of threads. >> src/hotspot/share/gc/shared/concurrentGCBreakpoints.cpp >> 63 #define assert_Java_thread() \ >> 64 assert(Thread::current()->is_Java_thread(), "precondition") >> 65 >> 66 void ConcurrentGCBreakpoints::run_to_idle_impl(bool acquiring_control) { >> 67 assert_Java_thread(); >> 68 MonitorLocker ml(monitor()); >> => >> 63 void ConcurrentGCBreakpoints::run_to_idle_impl(bool acquiring_control) { >> 64 MonitorLocker ml(JavaThread::current(), monitor()); >> and related later changes in this file. >> I prefer the original code, which intentionally made the precondition check >> explicit. > > The same precondition is already present in the use of JavaThread::current(). Is that not explicit enough? Plus the old code will manifest the current thread twice in debug builds. Cleaning up this kind of redundancy is one of the key aims here. :( I'm not that concerned by a little redundant work in a debug build. I think the explicit assert is clearer here. It removes the question for the future reader of why it's asking for a JavaThread for the mutex locker, when any thread can be used there. It's not obvious that the reason is to get the associated assertion. >> src/hotspot/share/runtime/objectMonitor.cpp >> 1255 bool ObjectMonitor::reenter(intx recursions, TRAPS) { >> 1256 Thread * const Self = THREAD; >> 1257 JavaThread * jt = Self->as_Java_thread(); >> The only use of Self could just be THREAD, which is also used in this >> function. And I don't see any references to jt at all here. Maybe that >> should just be an `assert(THREAD->is_Java_thread(), "precondition");`. >> Hm, there are other functions in this file that have a peculiar mix of >> Self/THREAD usage and bound but unused jt. >> Cleaning that up should probably be a separate task; this changeset is >> already quite big enough! > > Right, I tried to avoid the temptation of dealing with the Self/THREAD/jt mess in this change. I have another RFE filed that will do further cleanup here: > > https://bugs.openjdk.java.net/browse/JDK-8252685 Good. From philippe.marschall at gmail.com Wed Sep 9 09:45:37 2020 From: philippe.marschall at gmail.com (Philippe Marschall) Date: Wed, 9 Sep 2020 11:45:37 +0200 Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Mon, Sep 7, 2020 at 7:54 PM Alan Bateman wrote: > > On Mon, 7 Sep 2020 09:44:09 GMT, Philippe Marschall wrote: > > > Hello, newbie here > > > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > > > - I tried to update the copyright year to 2020 in every file. > > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > > - All tier1 tests pass. > > - One jpackage/jlink tier2 test fails but I don't believe it is related. > > - Some tier3 Swing tests fail but I don't think they are related. > > This one probably needs discussion on hotspot-dev to get agreement on the rename/move. It might need coordination with > Graal. I sent out mails to hotspot-dev and graal-dev. > If the change does go ahead then please check if java.base's module-info.java still needs to export jdk.internal > to jdk.jfr, I suspect that qualified export can be removed. You're correct we can replace the jdk.internal export with the jdk.internal.vm.annotation export. I updated the PR accordingly. Cheers Philippe From github.com+471021+marschall at openjdk.java.net Wed Sep 9 09:49:44 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Wed, 9 Sep 2020 09:49:44 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. Philippe Marschall has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/45/files - new: https://git.openjdk.java.net/jdk/pull/45/files/47328f4b..1c9dd9da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk/pull/45 From dholmes at openjdk.java.net Wed Sep 9 12:41:31 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 9 Sep 2020 12:41:31 GMT Subject: RFR: 8252794: Creation of JNIMethodBlock should be done with a leaf lock [v2] In-Reply-To: References: <4v19DvtX5ykcCzTGeQ2tJ-mrRsfwsruMMS-XE9rLPMw=.6f419fd6-2bec-4c9e-a432-16497d589264@github.com> Message-ID: On Wed, 9 Sep 2020 07:25:51 GMT, Robbin Ehn wrote: >> JVM TI uses handshakes and sometimes need jmethod ids. >> The CLD have an area where these ids are saved, which is created on first request for an id. >> >> The creation of this area should be done with a leaf lock. >> In W.I.P. asynchronous handshake change-set we use a mutex instead of a semaphore for serializing the handshakes, >> we thus get into lock ranks asserts. >> >> The CLD metaspace lock cannot be pushed down but we can use the same lock as for creating jmethod ids: >> JmethodIdCreation_lock. And push that down. (special-2 is picked to be compatible with W.I.P. asynchronous handshake >> change-set) >> The reason for CLD metaspace lock being used now is that we have one per CLD instead of one global one. >> >> Testing passes: t1-3 > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Corrected comment Update is good. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/53 From ayang at openjdk.java.net Wed Sep 9 12:43:02 2020 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 9 Sep 2020 12:43:02 GMT Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space In-Reply-To: References: Message-ID: <20eOaz9cH8FXrZxXMnRrAHsWOejOJIuYtppWGjgupwQ=.bf82cf62-d93a-4d83-bcb8-bd5919fb130f@github.com> On Wed, 9 Sep 2020 07:24:27 GMT, Kim Barrett wrote: > This is rework of initial change from before the transition to git. > The initial RFR email is attached below. > > The primary change is to limit the number of partial array tasks in > the queues for any given array. The original change just split up an > array into N tasks that were all enqueued at once. But for a large > array this could be a lot of tasks, leading to significant and > unnecessary queue expansion. Instead we now limit the number of tasks > for a given array based on the number of workers, and only gradually > add tasks up to that limit. This gives other threads an opportunity > to steal such tasks, while still keeping queue growth under control. > > Most of the calculation for this is handled by a new helper class, so > this can later be shared with ParallelGC. > > The dispatch on array klass type for has also been changed. It now > affirmatively breaks Project Valhalla, rather than quietly doing > something that probably isn't what is actually wanted. I'll discuss > with them so there is a plan for dealing with it when they take this > update. > > Ran tier1-6 in mach5 and some local stress tests. > > Performance testing was unchanged from previous, except I wasn't able > to reproduce the small specjbb2015 critical-jops improvement > previously seen on one platform. My suspicion is that improvement was > a statistical abberation. > > --- Initial RFR email --- > > RFR: 8158045: Improve large object handling during evacuation > RFR: 8027761: Investigate fast-path for scanning only objects with references during gc > RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space > > Please review this change to type dispatching and handling in G1's > evacuation copying, in order to improve the hot paths and improve array > handling. This change addresses several closely co-located enhancement > requests; it seemed difficult to split them up in a sensible way. > > do_copy_to_survivor_space now gets the klass of the object being copied > once, up front, for use in multiple places. This avoids fetching (including > re-decoding when compressed) the klass multiple times. This addresses part > of JDK-8027545. > > Moved check for and handling of string deduplication later, only applying it > after the special array cases have been dealt with, since strings are not > arrays. (They are header objects pointing to an array of character values.) > > Special case typeArray, doing nothing other than the copy, since they > contain no oops that need to be processed. This addresses JDK-8027761. > > Changed handling of objArray, pushing all of the partial array tasks up > front, rather than processing the current chunk after pushing a single task > for the remaining work. This addresses JDK-8158045. > > As part of these, cached some more frequently accessed values in > G1ParScanThreadState member variables. This addresses part of part of > JDK-8027545. > > While both the old and new code will work for Project Valhalla, the handling > of arrays should be updated for that project, which introduces new array > types. > > Deleted a lingering reference to G1ParScanPartialArrayClosure that was > deleted long ago (JDK-8035330, JDK 9). > > CR: > https://bugs.openjdk.java.net/browse/JDK-8158045 > https://bugs.openjdk.java.net/browse/JDK-8027761 > https://bugs.openjdk.java.net/browse/JDK-8027545 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ > > Testing: > tier1-3 > > performance testing - seems to be at worst performance neutral, with a > statistically significant 3% improvement in specjbb2015 critical-jops seen > on one platform. src/hotspot/share/gc/g1/g1ParScanThreadState.cpp line 253: > 251: for (uint i = 0; i < step._ncreate; ++i) { > 252: push_on_queue(ScannerTask(PartialArrayScanTask(from_obj))); > 253: } I think the intention would be clearer, if `start` returns a pair `` instead of reusing `Step` struct. src/hotspot/share/gc/g1/g1ParScanThreadState.cpp line 498: > 496: } > 497: > 498: if (G1StringDedup::is_enabled() && (klass == SystemDictionary::String_klass())) { It's unclear to me why the additional checking with `String_klass()`. src/hotspot/share/oops/arrayOop.hpp line 107: > 105: // Accessors for instance variable which is not a C++ declared nonstatic > 106: // field. > 107: int length() const { return *length_addr(); } Personally, I find the original code easier to read, since the identical content, `*(int*)(((char*)mem) + length_offset_in_bytes())` exists in both `length()` and `set_length(HeapWord* mem, int length)`. ------------- PR: https://git.openjdk.java.net/jdk/pull/90 From dholmes at openjdk.java.net Wed Sep 9 12:48:11 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 9 Sep 2020 12:48:11 GMT Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v7] In-Reply-To: References: Message-ID: > This is a rather large but generally simple cleanup. > > We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify > this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(), > which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was > also added to allow use in cases where we start with "const Thread *". Summary of changes: > - changed raw casts to use as_Java_thread() > - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread() > - Removed checks that are checking the type system e.g. > void foo(JavaThread* t) { > assert(t->is_Java_thread(), "must be") > the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry > about that then we would need asserts like this on every method that expects a JavaThread! The right place for the > assertion is at the head of any such call chain. > - Removed asserts that are already guaranteed in the caller. > - Use JavaThread::current() where appropriate. > - Use pre-existing "thread" variable where available rather than casting THREAD > > Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have > been missed. > Testing: tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Reverted to the original code as the explicit assertion is preferred. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/37/files - new: https://git.openjdk.java.net/jdk/pull/37/files/9426d53b..50575621 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=05-06 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/37.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37 PR: https://git.openjdk.java.net/jdk/pull/37 From david.holmes at oracle.com Wed Sep 9 12:50:18 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Sep 2020 22:50:18 +1000 Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v5] In-Reply-To: References: <7247893F-B0B5-468D-A9CD-9B9295750B62@oracle.com> Message-ID: <8eacd775-d484-eb4d-d18e-44a36d632ea1@oracle.com> Trimming ... On 9/09/2020 7:09 pm, Kim Barrett wrote: >>> src/hotspot/share/gc/shared/concurrentGCBreakpoints.cpp >>> 63 #define assert_Java_thread() \ >>> 64 assert(Thread::current()->is_Java_thread(), "precondition") >>> 65 >>> 66 void ConcurrentGCBreakpoints::run_to_idle_impl(bool acquiring_control) { >>> 67 assert_Java_thread(); >>> 68 MonitorLocker ml(monitor()); >>> => >>> 63 void ConcurrentGCBreakpoints::run_to_idle_impl(bool acquiring_control) { >>> 64 MonitorLocker ml(JavaThread::current(), monitor()); >>> and related later changes in this file. >>> I prefer the original code, which intentionally made the precondition check >>> explicit. >> >> The same precondition is already present in the use of JavaThread::current(). Is that not explicit enough? Plus the old code will manifest the current thread twice in debug builds. Cleaning up this kind of redundancy is one of the key aims here. :( > > I'm not that concerned by a little redundant work in a debug build. I think > the explicit assert is clearer here. It removes the question for the future > reader of why it's asking for a JavaThread for the mutex locker, when any > thread can be used there. It's not obvious that the reason is to get the > associated assertion. I personally think that the use of JavaThread::current() makes a clear statement that a JavaThread is expected here, but I have reverted the change. Thanks, David ----- > >>> src/hotspot/share/runtime/objectMonitor.cpp >>> 1255 bool ObjectMonitor::reenter(intx recursions, TRAPS) { >>> 1256 Thread * const Self = THREAD; >>> 1257 JavaThread * jt = Self->as_Java_thread(); >>> The only use of Self could just be THREAD, which is also used in this >>> function. And I don't see any references to jt at all here. Maybe that >>> should just be an `assert(THREAD->is_Java_thread(), "precondition");`. >>> Hm, there are other functions in this file that have a peculiar mix of >>> Self/THREAD usage and bound but unused jt. >>> Cleaning that up should probably be a separate task; this changeset is >>> already quite big enough! >> >> Right, I tried to avoid the temptation of dealing with the Self/THREAD/jt mess in this change. I have another RFE filed that will do further cleanup here: >> >> https://bugs.openjdk.java.net/browse/JDK-8252685 > > Good. > > From dholmes at openjdk.java.net Wed Sep 9 13:23:48 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 9 Sep 2020 13:23:48 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v3] In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 06:28:59 GMT, Ioi Lam wrote: >> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the >> same patch as >> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/) >> published in >> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html). The >> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed JVMFlag::is_writeable() Updates seem okay. One query below. src/hotspot/share/runtime/flags/jvmFlag.cpp line 266: > 264: > 265: bool JVMFlag::is_writeable() const { > 266: return is_manageable(); Unclear why is_writeable() reduces to is_manageable(). Aren't all product flags writeable? And aren't all develop flags writeable in non-product builds? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/82 From rehn at openjdk.java.net Wed Sep 9 13:24:24 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 9 Sep 2020 13:24:24 GMT Subject: RFR: 8252794: Creation of JNIMethodBlock should be done with a leaf lock [v2] In-Reply-To: References: <4v19DvtX5ykcCzTGeQ2tJ-mrRsfwsruMMS-XE9rLPMw=.6f419fd6-2bec-4c9e-a432-16497d589264@github.com> Message-ID: On Wed, 9 Sep 2020 12:39:12 GMT, David Holmes wrote: > Update is good. Thank you. As the update was trivial I'll go head and integrate. ------------- PR: https://git.openjdk.java.net/jdk/pull/53 From rehn at openjdk.java.net Wed Sep 9 13:24:24 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 9 Sep 2020 13:24:24 GMT Subject: Integrated: 8252794: Creation of JNIMethodBlock should be done with a leaf lock In-Reply-To: <4v19DvtX5ykcCzTGeQ2tJ-mrRsfwsruMMS-XE9rLPMw=.6f419fd6-2bec-4c9e-a432-16497d589264@github.com> References: <4v19DvtX5ykcCzTGeQ2tJ-mrRsfwsruMMS-XE9rLPMw=.6f419fd6-2bec-4c9e-a432-16497d589264@github.com> Message-ID: On Mon, 7 Sep 2020 12:16:17 GMT, Robbin Ehn wrote: > JVM TI uses handshakes and sometimes need jmethod ids. > The CLD have an area where these ids are saved, which is created on first request for an id. > > The creation of this area should be done with a leaf lock. > In W.I.P. asynchronous handshake change-set we use a mutex instead of a semaphore for serializing the handshakes, > we thus get into lock ranks asserts. > > The CLD metaspace lock cannot be pushed down but we can use the same lock as for creating jmethod ids: > JmethodIdCreation_lock. And push that down. (special-2 is picked to be compatible with W.I.P. asynchronous handshake > change-set) > The reason for CLD metaspace lock being used now is that we have one per CLD instead of one global one. > > Testing passes: t1-3 This pull request has now been integrated. Changeset: d5609647 Author: Robbin Ehn URL: https://git.openjdk.java.net/jdk/commit/d5609647 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod 8252794: Creation of JNIMethodBlock should be done with a leaf lock Reviewed-by: coleenp, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/53 From kbarrett at openjdk.java.net Wed Sep 9 14:08:42 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 9 Sep 2020 14:08:42 GMT Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v7] In-Reply-To: References: Message-ID: <25gLwDU6TwR83OHYC_PK7FBFFJvU2dtTtXvnDACEIzM=.9b094697-ae68-4e6d-a1ba-7a6a58a9326d@github.com> On Wed, 9 Sep 2020 12:48:11 GMT, David Holmes wrote: >> This is a rather large but generally simple cleanup. >> >> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify >> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(), >> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was >> also added to allow use in cases where we start with "const Thread *". Summary of changes: >> - changed raw casts to use as_Java_thread() >> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread() >> - Removed checks that are checking the type system e.g. >> void foo(JavaThread* t) { >> assert(t->is_Java_thread(), "must be") >> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry >> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the >> assertion is at the head of any such call chain. >> - Removed asserts that are already guaranteed in the caller. >> - Use JavaThread::current() where appropriate. >> - Use pre-existing "thread" variable where available rather than casting THREAD >> >> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have >> been missed. >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Reverted to the original code as the explicit assertion is preferred. Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/37 From coleenp at openjdk.java.net Wed Sep 9 14:20:02 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Sep 2020 14:20:02 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v3] In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 06:28:59 GMT, Ioi Lam wrote: >> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the >> same patch as >> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/) >> published in >> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html). The >> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed JVMFlag::is_writeable() Marked as reviewed by coleenp (Reviewer). src/hotspot/share/runtime/flags/jvmFlag.hpp line 36: > 34: typedef const char* (*RangeStrFunc)(void); > 35: > 36: struct JVMFlag { I'm still getting used to git diffs, but can you change this from struct to class? Because it looks like it does have private and public sections. src/hotspot/share/runtime/flags/jvmFlagLimit.cpp line 102: > 100: static constexpr const JVMFlagLimit* get_limit(const JVMTypedFlagLimit* p, int dummy, ConstraintMarker > dummy2, short func, int phase, T min, T max) { 101: return p; > 102: } Instead of the 'no_limit' functions, could you have get_limit have PRODUCT_RETURN(NULL) ? Otherwise, fine to get the macros working. src/hotspot/share/runtime/flags/jvmFlagLookup.hpp line 44: > 42: } > 43: return h; > 44: } Can this function just call hash_code(s, strlen(s)) ? ------------- PR: https://git.openjdk.java.net/jdk/pull/82 From coleenp at openjdk.java.net Wed Sep 9 14:20:03 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Sep 2020 14:20:03 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v3] In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 13:11:12 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed JVMFlag::is_writeable() > > src/hotspot/share/runtime/flags/jvmFlag.cpp line 266: > >> 264: >> 265: bool JVMFlag::is_writeable() const { >> 266: return is_manageable(); > > Unclear why is_writeable() reduces to is_manageable(). Aren't all product flags writeable? And aren't all develop flags > writeable in non-product builds? All flags shouldn't be also writeable. Interpreter code generation depends on static value of some flags, for instance. ------------- PR: https://git.openjdk.java.net/jdk/pull/82 From coleenp at openjdk.java.net Wed Sep 9 14:20:02 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Sep 2020 14:20:02 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v3] In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 14:16:10 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed JVMFlag::is_writeable() > > Marked as reviewed by coleenp (Reviewer). Looks good. I had a couple of minor comments. > In JDK-8081833, I plan to use templates to replaces the nearly identical code in > jvmFlagRangeList.cpp/jvmFlagConstraintList.cpp, and these macros should go away. Good! ------------- PR: https://git.openjdk.java.net/jdk/pull/82 From iklam at openjdk.java.net Wed Sep 9 15:41:40 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Sep 2020 15:41:40 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v3] In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 14:06:05 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/flags/jvmFlag.cpp line 266: >> >>> 264: >>> 265: bool JVMFlag::is_writeable() const { >>> 266: return is_manageable(); >> >> Unclear why is_writeable() reduces to is_manageable(). Aren't all product flags writeable? And aren't all develop flags >> writeable in non-product builds? > > All flags shouldn't be also writeable. Interpreter code generation depends on static value of some flags, for instance. is_writeable() doesn't mean "modifiable". The meaning is // manageable flags are writeable external product flags. // They are dynamically writeable through the JDK management interface // (com.sun.management.HotSpotDiagnosticMXBean API) and also through JConsole. See also [writeableFlags.cpp](https://github.com/openjdk/jdk/blob/433394203dce55db95caefcb57bac9ec114ebc47/src/hotspot/share/services/writeableFlags.cpp#L283). There used to be `product_rw` flags, which were "writeable" but not "manageable". However, there aren't any of them anymore. So I have deleted product_rw() from the comments. /**** removed comments ****/ // product_rw flags are writeable internal product flags. // They are like "manageable" flags but for internal/private use. // The list of product_rw flags are internal/private flags which // may be changed/removed in a future release. It can be set // through the management interface to get/set value // when the name of flag is supplied. // // A flag can be made as "product_rw" only if // - the VM implementation supports dynamic setting of the flag. // This implies that the VM must *always* query the flag variable // and not reuse state related to the flag state at any given time. // // Note that when there is a need to support develop flags to be writeable, // it can be done in the same way as product_rw. I also removed the implementation of product_rw(). Line 269 is part of the product_rw() removal. I considered adding support for product_rw() in the new flags implementation. It would be fairly trivial (similar to how MANAGEABLE is supported) but I am hesitant to do it because: - No one uses it currently - There are no test cases I don't want to have an untested implementation which someone might accidently use in the future without any testing. If anyone indeed finds producy_rw useful, they can easily implement the functionality and can write tests for it at the same time. ------------- PR: https://git.openjdk.java.net/jdk/pull/82 From sjohanss at openjdk.java.net Wed Sep 9 18:37:45 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 9 Sep 2020 18:37:45 GMT Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 07:24:27 GMT, Kim Barrett wrote: > This is rework of initial change from before the transition to git. > The initial RFR email is attached below. > > The primary change is to limit the number of partial array tasks in > the queues for any given array. The original change just split up an > array into N tasks that were all enqueued at once. But for a large > array this could be a lot of tasks, leading to significant and > unnecessary queue expansion. Instead we now limit the number of tasks > for a given array based on the number of workers, and only gradually > add tasks up to that limit. This gives other threads an opportunity > to steal such tasks, while still keeping queue growth under control. > > Most of the calculation for this is handled by a new helper class, so > this can later be shared with ParallelGC. > > The dispatch on array klass type for has also been changed. It now > affirmatively breaks Project Valhalla, rather than quietly doing > something that probably isn't what is actually wanted. I'll discuss > with them so there is a plan for dealing with it when they take this > update. > > Ran tier1-6 in mach5 and some local stress tests. > > Performance testing was unchanged from previous, except I wasn't able > to reproduce the small specjbb2015 critical-jops improvement > previously seen on one platform. My suspicion is that improvement was > a statistical abberation. > > --- Initial RFR email --- > > RFR: 8158045: Improve large object handling during evacuation > RFR: 8027761: Investigate fast-path for scanning only objects with references during gc > RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space > > Please review this change to type dispatching and handling in G1's > evacuation copying, in order to improve the hot paths and improve array > handling. This change addresses several closely co-located enhancement > requests; it seemed difficult to split them up in a sensible way. > > do_copy_to_survivor_space now gets the klass of the object being copied > once, up front, for use in multiple places. This avoids fetching (including > re-decoding when compressed) the klass multiple times. This addresses part > of JDK-8027545. > > Moved check for and handling of string deduplication later, only applying it > after the special array cases have been dealt with, since strings are not > arrays. (They are header objects pointing to an array of character values.) > > Special case typeArray, doing nothing other than the copy, since they > contain no oops that need to be processed. This addresses JDK-8027761. > > Changed handling of objArray, pushing all of the partial array tasks up > front, rather than processing the current chunk after pushing a single task > for the remaining work. This addresses JDK-8158045. > > As part of these, cached some more frequently accessed values in > G1ParScanThreadState member variables. This addresses part of part of > JDK-8027545. > > While both the old and new code will work for Project Valhalla, the handling > of arrays should be updated for that project, which introduces new array > types. > > Deleted a lingering reference to G1ParScanPartialArrayClosure that was > deleted long ago (JDK-8035330, JDK 9). > > CR: > https://bugs.openjdk.java.net/browse/JDK-8158045 > https://bugs.openjdk.java.net/browse/JDK-8027761 > https://bugs.openjdk.java.net/browse/JDK-8027545 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ > > Testing: > tier1-3 > > performance testing - seems to be at worst performance neutral, with a > statistically significant 3% improvement in specjbb2015 critical-jops seen > on one platform. Overall a very nice improvement. Some comments and ideas below. src/hotspot/share/gc/g1/g1ParScanThreadState.hpp line 84: > 82: bool _old_gen_is_full; > 83: // Size (in elements) of a partial objArray task chunk. > 84: int _partial_objarray_chunk_size; I would prefer to skip the "obj"-part here to have more consistent naming or, as mentioned above, include it in the stepper instead. src/hotspot/share/gc/g1/g1ParScanThreadState.hpp line 165: > 163: private: > 164: inline void do_partial_array(PartialArrayScanTask task); > 165: inline void start_partial_objArray(G1HeapRegionAttr dest_dir, oop from, oop to); Same here, drop "obj" for consistent naming and avoiding the camel-case. src/hotspot/share/gc/shared/partialArrayTaskStepper.cpp line 34: > 32: // that maximizes available parallelism. > 33: return n_workers; > 34: } In preparation for a more advanced logic for the limit, or why not just use the input at the call-site? src/hotspot/share/gc/shared/partialArrayTaskStepper.inline.hpp line 71: > 69: // The from-space object contains the real length. > 70: int length = from->length(); > 71: assert(start < length, "invariant: start %d, length %d", start, length); Just so I'm not missing anything. There will never be more tasks than chunks left, so there is no risk that we have a race for the last chunk and thus hit this assertion? src/hotspot/share/gc/g1/g1ParScanThreadState.cpp line 68: > 66: _old_gen_is_full(false), > 67: _partial_objarray_chunk_size(ParGCArrayScanChunk), > 68: _partial_array_stepper(n_workers), What do you think about saving the chunk size in the stepper instead? Then we don't need to pass it in to `start()` and `next()`. To avoid needing it for the call to `oop_iterate_range()` we could instead have the `Step` include both the start and end index. src/hotspot/share/gc/shared/partialArrayTaskStepper.hpp line 57: > 55: int _index; // Array index for the step. > 56: uint _ncreate; // Number of new tasks to create. > 57: }; I wouldn't mind having getters for those, but it's not a hard request :) src/hotspot/share/gc/shared/partialArrayTaskStepper.inline.hpp line 103: > 101: uint ncreate = MIN2(_task_fannout, MIN2(remaining_tasks, _task_limit + 1) - pending); > 102: Step result = { start, ncreate }; > 103: return result; Similar to my comment above, what do you think about trying to write some test for this to verify we never get to many "tasks". ------------- Changes requested by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/90 From iklam at openjdk.java.net Wed Sep 9 19:41:05 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Sep 2020 19:41:05 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v3] In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 14:09:23 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed JVMFlag::is_writeable() > > src/hotspot/share/runtime/flags/jvmFlag.hpp line 36: > >> 34: typedef const char* (*RangeStrFunc)(void); >> 35: >> 36: struct JVMFlag { > > I'm still getting used to git diffs, but can you change this from struct to class? Because it looks like it does have > private and public sections. I want to limit the changes in this PR, so I plan to do this in a future RFE, probably [JDK-8081833](https://bugs.openjdk.java.net/browse/JDK-8081833). I'll also change all the fields to private, and add accessor methods to them. And also add proper iterators for the flags (instead of walking JVMFlag::flags[] directly). ------------- PR: https://git.openjdk.java.net/jdk/pull/82 From coleenp at openjdk.java.net Wed Sep 9 19:56:20 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Sep 2020 19:56:20 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v3] In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 19:38:44 GMT, Ioi Lam wrote: >> src/hotspot/share/runtime/flags/jvmFlag.hpp line 36: >> >>> 34: typedef const char* (*RangeStrFunc)(void); >>> 35: >>> 36: struct JVMFlag { >> >> I'm still getting used to git diffs, but can you change this from struct to class? Because it looks like it does have >> private and public sections. > > I want to limit the changes in this PR, so I plan to do this in a future RFE, probably > [JDK-8081833](https://bugs.openjdk.java.net/browse/JDK-8081833). I'll also change all the fields to private, and add > accessor methods to them. And also add proper iterators for the flags (instead of walking JVMFlag::flags[] directly). Ok that would be fine as a further change. ------------- PR: https://git.openjdk.java.net/jdk/pull/82 From gerard.ziemski at oracle.com Wed Sep 9 20:15:37 2020 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Wed, 9 Sep 2020 15:15:37 -0500 Subject: RFR(L) 8243208 Clean up JVMFlag implementation In-Reply-To: <871070c2-0175-7833-0280-cb2e86302e5c@oracle.com> References: <871070c2-0175-7833-0280-cb2e86302e5c@oracle.com> Message-ID: <7378f6c3-7fdf-a0f2-4bad-9a34d33ba8ef@oracle.com> (I'm re-sending my previous email with more feedback added to it) hi Ioi, Very nice work! I reviewed most of the files already (they look good), but the core implementation is taking me more time, so for now I?m going to share what I have so far: #1 In "src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp" the API JVMFlagLimit::get_constraint(flag) says ?constraint?, but it returns JVMFlagLimit* using different names for the same thing - one calls it ?limit", the other uses ?constraint?. Maybe instead of 282 JVMFlagRangeChecker range = JVMFlagRangeList::find(flag); 283 if (range.exists()) { 284 range.print(st); 285 } else { 286 const JVMFlagLimit* limit = JVMFlagLimit::get_constraint(flag); 287 if (limit != NULL) { we could have this: 282 JVMFlagRangeChecker range = JVMFlagRangeList::find(flag); 283 if (range.exists()) { 284 range.print(st); 285 } else { 286 const JVMFlagLimit* limit = JVMFlagLimit::find(flag); 287 if (limit != NULL) { or alternatively rename ?JVMFlagLimit? to ?JVMFlagConstraint? ? #2 In "src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp" comment: 290?????? // Two special cases who's range lower limit is an os:: function call and cannot should be: 290?????? // Two special cases whose range lower limit is an os:: function call and cannot #3 In "src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp" dsn?t there a better way to treat the special cases in "JVMFlagRangeList::print?, without explicitly checking for hardcoded function pointers? Or is it just not worth the effort, with only 2 such cases for now? #4 In "src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp" inconsistent white space usage in: 245 #define DEFINE_RANGE_CHECK(T) \ 246 JVMFlag::Error JVMFlagRangeChecker::check_ ## T(T value, bool verbose) const {????????? \ 247?? assert(exists(), "must be");????????????????????????????????????????????????????????? \ 248?? JVMFlagRange_ ## T range(_flag, _limit->as_##T()->min(), _limit->as_ ## T()->max()); \ 249?? return range.check_ ## T(value, verbose);???????????????????????????????????????????? \ For example, at line 248 we have "_limit->as_##T()->min()? (no spaces around ##) then "_limit->as_ ## T()->max()" #5 In "src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp" I'm not sure how others feel about it, but I think I personally would find it helpful for macros like ?DEFINE_RANGE_CHECK? to see a comment with a concrete example of macro expansion for some flag, just to see what it works out to be. #6 Do we need to provide base of the enums (https://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/hotspot-style.html#enum) in files: a) open/src/hotspot/share/runtime/globals_extension.hpp ? 43 typedef enum { ? 44?? ALL_FLAGS(FLAG_MEMBER_ENUM_DEVELOP, ? 45???????????? FLAG_MEMBER_ENUM_PD_DEVELOP, ? 46???????????? FLAG_MEMBER_ENUM_PRODUCT, ? 47???????????? FLAG_MEMBER_ENUM_PD_PRODUCT, ? 48???????????? FLAG_MEMBER_ENUM_NOTPRODUCT, ? 49???????????? IGNORE_RANGE, ? 50???????????? IGNORE_CONSTRAINT) ? 51?? NUM_JVMFlagsEnum ? 52 } JVMFlagsEnum; b) src/hotspot/share/runtime/flags/jvmFlagLimit.cpp ? 46 enum JVMFlagConstraintsEnum { ? 47?? ALL_CONSTRAINTS(CONSTRAINT_ENUM_) ? 48?? NUM_JVMFlagConstraintsEnum ? 49 }; #7 Should these enums be replaced with ordinary constants (https://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/hotspot-style.html#enum) in files: a) open/src/hotspot/share/runtime/flags/jvmFlagLimit.hpp ? 44 class JVMFlagLimit { ? 45?? enum { ? 46???? HAS_RANGE = 1, ? 47???? HAS_CONSTRAINT = 2 ? 48?? }; #8 Can we add a description to "src/hotspot/share/runtime/flags/jvmFlagLookup.hpp? on how ?constexpr" makes this hash table possible at the compile time? #9 Shouldn?t the code in JVMFlagLookup::JVMFlagLookup() initializing the internal tables be more like: constexpr JVMFlagLookup::JVMFlagLookup() : _buckets(), _table(), _hashes() { ? for (int i = 0; i < NUM_BUCKETS; i++) { ??? _buckets[i] = -1; ? } ? for (int i = 0; i < NUM_JVMFlagsEnum; i++) { ??? _hashes[i] = 0; ??? _table[i] = -1; ? } ?... #10 ?flagTable_verify_constexpr" and ?flagTable?, in "src/hotspot/share/runtime/flags/jvmFlag.cpp?, are almost identical - can we find a way to create just one table (of the ?constexpr? type)? Almost done with my review, just one more feedback I will have shortly. cheers On 9/2/20 1:37 PM, Ioi Lam wrote: > I have an updated version (with fewer changes!) as suggested to me > Stefan Karlsson offline: > > http://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/ > > [1] More consistent white spaces in the macro definitions > > [2] Reverted the renaming of JVMFlag::Flags. This renaming is not > really needed by > ??? the cleanup. Doing it later will avoid unnecessary clutter in the > changeset. > > ??? Also Stefan suggested renaming to JVMFlag::Attributes (instead of > ::Attrs). > > [3] Removed some TODO comments as they are already captured in JBS issues. > > Thanks > - Ioi > > > > On 9/1/20 6:29 PM, Ioi Lam wrote: >> https://bugs.openjdk.java.net/browse/JDK-8243208 >> http://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v01/ >> >> https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags+Clean+Up+-+Design+Proposal+for+JDK-8243208 >> >> >> >> >> Please review this major clean up of HotSpot command-line flags. The >> goals are: >> >> ??? + Reduce the complexity of the implementation >> ??? + Improvement footprint/performance (with C++ constexpr) >> ??? + Allow more flexibility in flag declaration (see also JDK-7123237) >> >> >> >> **** Notable interface changes: >> >> ??? I tried to make the changes non-intrusive. Most HotSpot developers >> ? ? should not be affected at all, unless you touch the following areas: >> >> [1] The declaration of diagnostic/experimental/manageable flags is >> changed. >> ? ? See globals.hpp for examples: >> >> ??? OLD: experimental(intx, hashCode, 5, "..docs...") >> ??? NEW: product(intx, hashCode, 5, EXPERIMENTAL, "..docs...") >> >> ??? The reason is to support more flexible combinations. Before, >> ? ? all experimental flags must be "product". Now they can be "develop" >> ? ? as well. >> >> [2] Declaration of constraint functions is changed to use a macro. >> ??? See jvmFlagConstraintsRuntime.hpp >> >> [3] The confusing type JVMFlag::Flags is renamed to JVMFlag::Attrs to be >> ? ? clear it's about "attributes of the flags" and not "the flags >> ? ? themselves". >> >> [4] The min/max of all ranges must be compile-time constants. We had >> ? ? two cases where the min/max was specified via os::xxx function >> ? ? calls. These are converted to constraint functions: >> >> ??? OLD: >> ??? product_pd(uintx, InitialCodeCacheSize, "...") \ >> ??????????? range(os::vm_page_size(), max_uintx) >> >> ??? product(size_t, NUMAInterleaveGranularity, 2*M, "...")? \ >> ??????????? range(os::vm_allocation_granularity(), \ >> ????????????????? NOT_LP64(2*G) LP64_ONLY(8192*G)) \ >> >> ??? NEW: >> ??? product_pd(uintx, InitialCodeCacheSize, "...") \ >> ??????????? constraint(VMPageSizeConstraintFunc, AtParse) >> >> ??? product(size_t, NUMAInterleaveGranularity, 2*M, "...")? \ >> constraint(NUMAInterleaveGranularityConstraintFunc, \ >> ??????????????????????? AtParse) >> >> >> >> **** Notable implementation changes: >> >> [1] C++ constexpr is used extensively for build-time initialization of >> ? ? various tables. >> >> [2] All XXX_FLAGS() macros now consistent take 7 arguments. Application >> ??? of these macros in jvmFlag.cpp have been greatly simplified. >> >> ??? This also makes it possible for further modularization in the future >> ? ? (see JDK-8243205). >> >> ??? example: >> >> ??? #define RUNTIME_FLAGS(develop, \ >> ??? ? ?? ???????????????? develop_pd, \ >> ??????? ? ?? ???????????? product, \ >> ??????????? ? ?? ???????? product_pd, \ >> ??????????????? ? ?? ???? notproduct, \ >> ??????????????????? ? ? ? range, \ >> ????????????????????????? constraint) \ >> >> [3] When processing the command-line arguments, the JVM flags are now >> ??? searched using a build-time generated hashtable. See >> jvmFlagLookup.cpp >> >> [4] Tables for range/constraint check used to be dynamically constructed >> ??? and linearly searched. Now they are build-time generated, with O(1) >> ? ? access time (a simple array index). >> >> For detailed discussion on the new design, please see >> https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags+Clean+Up+-+Design+Proposal+for+JDK-8243208 >> >> >> >> >> **** Next steps >> >> ??? I tried to keep this changeset small. So some changes are deferred: >> >> [1] In an separate RFE (JDK-8081833) I will use C++ templates >> ??? to consolidate the large amount of duplicated code in jvmFlag.cpp, >> ? ? jvmFlagRangeList.cpp and jvmFlagConstraintList.cpp. >> >> [2] There are archaic test cases that assume that experimental flags >> ? ? must be product flags. See JVMFlag::JVMFlag() constructor in >> jvmFlag.cpp. >> ? ? I'll relax this in JDK-7123237 and update the test cases. >> >> >> Thanks >> - Ioi > From iklam at openjdk.java.net Wed Sep 9 20:47:33 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Sep 2020 20:47:33 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v3] In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 14:13:15 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed JVMFlag::is_writeable() > > src/hotspot/share/runtime/flags/jvmFlagLookup.hpp line 44: > >> 42: } >> 43: return h; >> 44: } > > Can this function just call hash_code(s, strlen(s)) ? strlen() is not constexpr so it can't be used here. I added my hand-rolled string_len function in [bf90a37](https://github.com/openjdk/jdk/pull/82/commits/bf90a3765720267a8770f7bb0cc6957471ccb21b) so we can share a single copy of the hash calculation loop. ------------- PR: https://git.openjdk.java.net/jdk/pull/82 From iklam at openjdk.java.net Wed Sep 9 20:47:32 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Sep 2020 20:47:32 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v4] In-Reply-To: References: Message-ID: > The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the > same patch as > [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/) > published in > [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html). The > rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Refactored JVMFlagLookup::hash_code(); Cleaned up LimitGetter::no_limit() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/82/files - new: https://git.openjdk.java.net/jdk/pull/82/files/10246284..bf90a376 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=02-03 Stats: 24 lines in 2 files changed: 7 ins; 12 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/82.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/82/head:pull/82 PR: https://git.openjdk.java.net/jdk/pull/82 From iklam at openjdk.java.net Wed Sep 9 20:53:13 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Sep 2020 20:53:13 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v3] In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 14:12:04 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed JVMFlag::is_writeable() > > src/hotspot/share/runtime/flags/jvmFlagLimit.cpp line 102: > >> 100: static constexpr const JVMFlagLimit* get_limit(const JVMTypedFlagLimit* p, int dummy, ConstraintMarker >> dummy2, short func, int phase, T min, T max) { 101: return p; >> 102: } > > Instead of the 'no_limit' functions, could you have get_limit have PRODUCT_RETURN(NULL) ? Otherwise, fine to get the > macros working. I think your suggestion would simply the macro materialization from #ifdef PRODUCT ALL_FLAGS(FLAG_LIMIT_PTR_NONE, FLAG_LIMIT_PTR_NONE, FLAG_LIMIT_PTR, FLAG_LIMIT_PTR, FLAG_LIMIT_PTR_NONE, APPLY_FLAG_RANGE, APPLY_FLAG_CONSTRAINT) #else ALL_FLAGS(FLAG_LIMIT_PTR, FLAG_LIMIT_PTR, FLAG_LIMIT_PTR, FLAG_LIMIT_PTR, FLAG_LIMIT_PTR, APPLY_FLAG_RANGE, APPLY_FLAG_CONSTRAINT) #endif to ALL_FLAGS(FLAG_LIMIT_PTR_NOT_PRODUCT, FLAG_LIMIT_PTR_NOT_PRODUCT, FLAG_LIMIT_PTR, FLAG_LIMIT_PTR, FLAG_LIMIT_PTR_NOT_PRODUCT, APPLY_FLAG_RANGE, APPLY_FLAG_CONSTRAINT) But I would need twice the number of the get_limit functions, like: static constexpr const JVMFlagLimit* get_limit(const JVMTypedFlagLimit* p, int dummy, T min, T max) { return p; // return product flag for all builds } static constexpr const JVMFlagLimit* get_limit_not_product(const JVMTypedFlagLimit* p, int dummy, T min, T max) { NOT_PRODUCT(return p); // return non-product flag only in non-product builds PRODUCT_ONLY(return NULL); // .... but not in product build } So the code will be more verbose than before. Instead, in [bf90a37](https://github.com/openjdk/jdk/pull/82/commits/bf90a3765720267a8770f7bb0cc6957471ccb21b), I changed no_limit to a varargs function so now there's only one version of it. ------------- PR: https://git.openjdk.java.net/jdk/pull/82 From coleenp at openjdk.java.net Wed Sep 9 21:09:28 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Sep 2020 21:09:28 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v4] In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 20:47:32 GMT, Ioi Lam wrote: >> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the >> same patch as >> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/) >> published in >> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html). The >> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Refactored JVMFlagLookup::hash_code(); Cleaned up LimitGetter::no_limit() Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/82 From coleenp at openjdk.java.net Wed Sep 9 21:09:28 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Sep 2020 21:09:28 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v3] In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 20:44:11 GMT, Ioi Lam wrote: >> src/hotspot/share/runtime/flags/jvmFlagLookup.hpp line 44: >> >>> 42: } >>> 43: return h; >>> 44: } >> >> Can this function just call hash_code(s, strlen(s)) ? > > strlen() is not constexpr so it can't be used here. I added my hand-rolled string_len function in > [bf90a37](https://github.com/openjdk/jdk/pull/82/commits/bf90a3765720267a8770f7bb0cc6957471ccb21b) so we can share a > single copy of the hash calculation loop. Nice! ------------- PR: https://git.openjdk.java.net/jdk/pull/82 From iklam at openjdk.java.net Wed Sep 9 21:23:32 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Sep 2020 21:23:32 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v5] In-Reply-To: References: Message-ID: > The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the > same patch as > [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/) > published in > [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html). The > rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Feedback by Gerard (hotspot-dev/2020-September/043019.html) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/82/files - new: https://git.openjdk.java.net/jdk/pull/82/files/bf90a376..15547ebe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=03-04 Stats: 23 lines in 6 files changed: 8 ins; 3 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/82.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/82/head:pull/82 PR: https://git.openjdk.java.net/jdk/pull/82 From iklam at openjdk.java.net Wed Sep 9 21:36:49 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Sep 2020 21:36:49 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v4] In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 21:06:47 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactored JVMFlagLookup::hash_code(); Cleaned up LimitGetter::no_limit() > > Marked as reviewed by coleenp (Reviewer). Re: [Gerard Ziemski's comments on hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/043019.html): I made the changes in [15547eb](https://github.com/openjdk/jdk/pull/82/commits/15547ebe703fcc3a4ce154f2a01f45b756051c26) Gerard #6 Do we need to provide base of the enums (https://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/hotspot-style.html#enum) in files: a) open/src/hotspot/share/runtime/globals_extension.hpp 43 typedef enum { 44 ALL_FLAGS(FLAG_MEMBER_ENUM_DEVELOP, 45 FLAG_MEMBER_ENUM_PD_DEVELOP, 46 FLAG_MEMBER_ENUM_PRODUCT, 47 FLAG_MEMBER_ENUM_PD_PRODUCT, 48 FLAG_MEMBER_ENUM_NOTPRODUCT, 49 IGNORE_RANGE, 50 IGNORE_CONSTRAINT) 51 NUM_JVMFlagsEnum 52 } JVMFlagsEnum; b) src/hotspot/share/runtime/flags/jvmFlagLimit.cpp 46 enum JVMFlagConstraintsEnum { 47 ALL_CONSTRAINTS(CONSTRAINT_ENUM_) 48 NUM_JVMFlagConstraintsEnum 49 }; I added `enum ... : int` as the base. Gerard #7 Should these enums be replaced with ordinary constants (https://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/hotspot-style.html#enum) in files: a) open/src/hotspot/share/runtime/flags/jvmFlagLimit.hpp 44 class JVMFlagLimit { 45 enum { 46 HAS_RANGE = 1, 47 HAS_CONSTRAINT = 2 48 }; Changed to static constexpr int HAS_RANGE = 1, etc. Gerard #8 Can we add a description to "src/hotspot/share/runtime/flags/jvmFlagLookup.hpp? on how ?constexpr" makes this hash table possible at the compile time? I added // This is a hashtable that maps from (const char*) to (JVMFlag*) to speed up // the processing of JVM command-line argument at runtime. // // With constexpr, this table is generated at C++ compile time so there's // no set up cost at runtime. class JVMFlagLookup { ... Gerard #9 Shouldn?t the code in JVMFlagLookup::JVMFlagLookup() initializing the internal tables be more like: constexpr JVMFlagLookup::JVMFlagLookup() : _buckets(), _table(), _hashes() { for (int i = 0; i < NUM_BUCKETS; i++) { _buckets[i] = -1; } for (int i = 0; i < NUM_JVMFlagsEnum; i++) { _hashes[i] = 0; _table[i] = -1; } There's no need to initialize _hashes and _table in a loop. Each of the elements in these two arrays are individually initialized by the expansion of this macro: #define DO_HASH(flag_enum, flag_name) { \ unsigned int hash = hash_code(flag_name); \ int bucket_index = (int)(hash % NUM_BUCKETS); \ _hashes[flag_enum] = (u2)(hash); \ _table[flag_enum] = _buckets[bucket_index]; \ _buckets[bucket_index] = (short)flag_enum; \ } ... ALL_FLAGS(DO_FLAG, DO_FLAG, DO_FLAG, DO_FLAG, DO_FLAG, IGNORE_RANGE, IGNORE_CONSTRAINT) There was a bug in my previous version that unnecessarily initialized ` _hashes[i] = 0` in the loop. I've removed it. Gerard #10 ?flagTable_verify_constexpr" and ?flagTable?, in "src/hotspot/share/runtime/flags/jvmFlag.cpp?, are almost identical - can we find a way to create just one table (of the ?constexpr? type)? flagTable_verify_constexpr[] is needed for build-time checking only, and cannot be combined with flagTable[]. I've updated the comments to clarify: // We want flagTable[] to be completely initialized at C++ compilation time, which requires // that all arguments passed to JVMFlag() constructors to be constexpr. The following line // checks for this this -- if any non-constexpr arguments are passed, the C++ compiler will // generate an error. // // constexpr implies internal linkage. This means the flagTable_verify_constexpr[] variable // will not be included in jvmFlag.o, so there's no footprint cost for having this variable. // // Note that we cannot declare flagTable[] as constexpr because JVMFlag::_flags is modified // at runtime. constexpr JVMFlag flagTable_verify_constexpr[] = { MATERIALIZE_ALL_FLAGS }; ------------- PR: https://git.openjdk.java.net/jdk/pull/82 From dcubed at openjdk.java.net Wed Sep 9 23:26:50 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 9 Sep 2020 23:26:50 GMT Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v7] In-Reply-To: <25gLwDU6TwR83OHYC_PK7FBFFJvU2dtTtXvnDACEIzM=.9b094697-ae68-4e6d-a1ba-7a6a58a9326d@github.com> References: <25gLwDU6TwR83OHYC_PK7FBFFJvU2dtTtXvnDACEIzM=.9b094697-ae68-4e6d-a1ba-7a6a58a9326d@github.com> Message-ID: On Wed, 9 Sep 2020 14:06:02 GMT, Kim Barrett wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Reverted to the original code as the explicit assertion is preferred. > > Marked as reviewed by kbarrett (Reviewer). This is a really nice set of cleanup changes. I have a few comments. https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-33 51 if (thread->is_Java_thread()) 52 return thread->as_Java_thread()->thread_state() == _thread_in_vm; 53 else 54 return thread->is_VM_thread(); nit - this code needs braces. Not your bug, but since you've touched this code, do you mind fixing it? Note: I included the link the webrev had me on, but I have no idea what file that is... https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-80 276 guarantee(current == get_thread() || current == get_thread()->active_handshaker(), 277 "must be current thread or direct handshake"); nit - the indent on L277 looks wrong in the webrev, but it looks right in this paste. I don't know which is telling the truth. https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-101 358 this->as_Java_thread()->set_stack_overflow_limit(); 359 this->as_Java_thread()->set_reserved_stack_activation(stack_base()); nit - do you really need 'this->' here? https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-107 old code: 2074 if (thread_id == 0) { 2075 // current thread 2076 if (THREAD->is_Java_thread()) { 2077 return ((JavaThread*)THREAD)->cooked_allocated_bytes(); 2078 } 2079 return -1; new code: 2074 if (thread_id == 0) { // current thread 2075 return thread->cooked_allocated_bytes(); If the calling thread is not a JavaThread and passes a thread_id ==0, I don't think the returns are equivalent. The craziness in the JavaThread::pd_get_top_frame() functions made my head hurt. Thanks for cleaning that up! ------------- PR: https://git.openjdk.java.net/jdk/pull/37 From dcubed at openjdk.java.net Wed Sep 9 23:30:54 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 9 Sep 2020 23:30:54 GMT Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v7] In-Reply-To: References: <25gLwDU6TwR83OHYC_PK7FBFFJvU2dtTtXvnDACEIzM=.9b094697-ae68-4e6d-a1ba-7a6a58a9326d@github.com> Message-ID: On Wed, 9 Sep 2020 23:24:26 GMT, Daniel D. Daugherty wrote: >> Marked as reviewed by kbarrett (Reviewer). > > This is a really nice set of cleanup changes. > > I have a few comments. > > https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-33 > 51 if (thread->is_Java_thread()) > 52 return thread->as_Java_thread()->thread_state() == _thread_in_vm; > 53 else > 54 return thread->is_VM_thread(); > nit - this code needs braces. Not your bug, but since you've touched this > code, do you mind fixing it? > > Note: I included the link the webrev had me on, but I have no idea what > file that is... > > https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-80 > > 276 guarantee(current == get_thread() || current == get_thread()->active_handshaker(), > 277 "must be current thread or direct handshake"); > > nit - the indent on L277 looks wrong in the webrev, but it looks right in > this paste. I don't know which is telling the truth. > > https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-101 > > 358 this->as_Java_thread()->set_stack_overflow_limit(); > 359 this->as_Java_thread()->set_reserved_stack_activation(stack_base()); > nit - do you really need 'this->' here? > > https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-107 > > old code: > 2074 if (thread_id == 0) { > 2075 // current thread > 2076 if (THREAD->is_Java_thread()) { > 2077 return ((JavaThread*)THREAD)->cooked_allocated_bytes(); > 2078 } > 2079 return -1; > > new code: > 2074 if (thread_id == 0) { // current thread > 2075 return thread->cooked_allocated_bytes(); > > If the calling thread is not a JavaThread and passes a thread_id ==0, > I don't think the returns are equivalent. > > The craziness in the JavaThread::pd_get_top_frame() functions made my head hurt. > Thanks for cleaning that up! I don't see how to add myself as a reviewer... what am I missing? ------------- PR: https://git.openjdk.java.net/jdk/pull/37 From dcubed at openjdk.java.net Wed Sep 9 23:42:59 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 9 Sep 2020 23:42:59 GMT Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v7] In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 12:48:11 GMT, David Holmes wrote: >> This is a rather large but generally simple cleanup. >> >> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify >> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(), >> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was >> also added to allow use in cases where we start with "const Thread *". Summary of changes: >> - changed raw casts to use as_Java_thread() >> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread() >> - Removed checks that are checking the type system e.g. >> void foo(JavaThread* t) { >> assert(t->is_Java_thread(), "must be") >> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry >> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the >> assertion is at the head of any such call chain. >> - Removed asserts that are already guaranteed in the caller. >> - Use JavaThread::current() where appropriate. >> - Use pre-existing "thread" variable where available rather than casting THREAD >> >> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have >> been missed. >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Reverted to the original code as the explicit assertion is preferred. Marked as reviewed by dcubed (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/37 From david.holmes at oracle.com Thu Sep 10 00:51:29 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Sep 2020 10:51:29 +1000 Subject: RFR: 8243208: Clean up JVMFlag implementation [v3] In-Reply-To: References: Message-ID: <18822b11-cc68-7c20-3f9f-c7885c1156ac@oracle.com> Hi Ioi, On 10/09/2020 1:41 am, Ioi Lam wrote: > On Wed, 9 Sep 2020 14:06:05 GMT, Coleen Phillimore wrote: > >>> src/hotspot/share/runtime/flags/jvmFlag.cpp line 266: >>> >>>> 264: >>>> 265: bool JVMFlag::is_writeable() const { >>>> 266: return is_manageable(); >>> >>> Unclear why is_writeable() reduces to is_manageable(). Aren't all product flags writeable? And aren't all develop flags >>> writeable in non-product builds? >> >> All flags shouldn't be also writeable. Interpreter code generation depends on static value of some flags, for instance. > > is_writeable() doesn't mean "modifiable". The meaning is > > // manageable flags are writeable external product flags. > // They are dynamically writeable through the JDK management interface > // (com.sun.management.HotSpotDiagnosticMXBean API) and also through JConsole. > > See also > [writeableFlags.cpp](https://github.com/openjdk/jdk/blob/433394203dce55db95caefcb57bac9ec114ebc47/src/hotspot/share/services/writeableFlags.cpp#L283). > > There used to be `product_rw` flags, which were "writeable" but not "manageable". However, there aren't any of them > anymore. So I have deleted product_rw() from the comments. > /**** removed comments ****/ > // product_rw flags are writeable internal product flags. > // They are like "manageable" flags but for internal/private use. > // The list of product_rw flags are internal/private flags which > // may be changed/removed in a future release. It can be set > // through the management interface to get/set value > // when the name of flag is supplied. > // > // A flag can be made as "product_rw" only if > // - the VM implementation supports dynamic setting of the flag. > // This implies that the VM must *always* query the flag variable > // and not reuse state related to the flag state at any given time. > // > // Note that when there is a need to support develop flags to be writeable, > // it can be done in the same way as product_rw. > > I also removed the implementation of product_rw(). Line 269 is part of the product_rw() removal. > > I considered adding support for product_rw() in the new flags implementation. It would be fairly trivial (similar to > how MANAGEABLE is supported) but I am hesitant to do it because: > > - No one uses it currently > - There are no test cases > > I don't want to have an untested implementation which someone might accidently use in the future without any testing. > If anyone indeed finds producy_rw useful, they can easily implement the functionality and can write tests for it at the > same time. Yes sorry for the noise. Obviously most flags are not writeable - their value has to be fixed at startup. Doh! I was confused by your earlier webrev which showed "|| is_product()" and which seemed "obviously" correct. :) I'm somewhat surprised that none of our product or develop flags are writeable any more. It used to be some Print/Trace flags that were writeable and they have been replaced by UL. I can imagine wanting to dynamically enable/disable diagnostic flags though ... I wonder if "writeable" should be an attribute like diagnostic/experimental, so that manageable flags are just writeable product flags? That would be a future RFE of course (if appropriate). Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/82 > From dholmes at openjdk.java.net Thu Sep 10 01:04:17 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Sep 2020 01:04:17 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v5] In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 21:23:32 GMT, Ioi Lam wrote: >> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the >> same patch as >> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/) >> published in >> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html). The >> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Feedback by Gerard (hotspot-dev/2020-September/043019.html) Marked as reviewed by dholmes (Reviewer). src/hotspot/share/runtime/flags/jvmFlag.cpp line 714: > 712: > 713: // We want flagTable[] to be completely initialized at C++ compilation time, which requires > 714: // that all arguments passed to JVMFlag() constructors to be constexpr. The following line line 714: s/to be/be/ src/hotspot/share/runtime/flags/jvmFlag.cpp line 715: > 713: // We want flagTable[] to be completely initialized at C++ compilation time, which requires > 714: // that all arguments passed to JVMFlag() constructors to be constexpr. The following line > 715: // checks for this this -- if any non-constexpr arguments are passed, the C++ compiler will typo: this this src/hotspot/share/runtime/flags/jvmFlagLookup.hpp line 32: > 30: > 31: // This is a hashtable that maps from (const char*) to (JVMFlag*) to speed up > 32: // the processing of JVM command-line argument at runtime. s/argument/arguments/ src/hotspot/share/runtime/flags/jvmFlagLookup.hpp line 46: > 44: size_t len = 0; > 45: while (*s != 0) { > 46: len ++; Unwanted space before ++ ------------- PR: https://git.openjdk.java.net/jdk/pull/82 From david.holmes at oracle.com Thu Sep 10 03:11:32 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Sep 2020 13:11:32 +1000 Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v7] In-Reply-To: References: <25gLwDU6TwR83OHYC_PK7FBFFJvU2dtTtXvnDACEIzM=.9b094697-ae68-4e6d-a1ba-7a6a58a9326d@github.com> Message-ID: Hi Dan, Thanks for looking at this one. On 10/09/2020 9:26 am, Daniel D.Daugherty wrote: > On Wed, 9 Sep 2020 14:06:02 GMT, Kim Barrett wrote: > >>> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Reverted to the original code as the explicit assertion is preferred. >> >> Marked as reviewed by kbarrett (Reviewer). > > This is a really nice set of cleanup changes. > > I have a few comments. > > https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-33 > 51 if (thread->is_Java_thread()) > 52 return thread->as_Java_thread()->thread_state() == _thread_in_vm; > 53 else > 54 return thread->is_VM_thread(); > nit - this code needs braces. Not your bug, but since you've touched this > code, do you mind fixing it? Yes will add braces. So glad you picked on this though as I messed up one of my commits and rolled back to the v1 version, forgetting that it was broken in v1. The original line is: return true; //something like this: thread->is_VM_thread(); so I tried: return thread->is_VM_thread(); but it causes the assertion to fail as GC threads also execute this. So I've restored to the original "return true;" but updated the comment. > Note: I included the link the webrev had me on, but I have no idea what > file that is... Yeah those links are pretty obscure, and even the webrev frames view it takes you to doesn't give the name of the file. :( > https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-80 > > 276 guarantee(current == get_thread() || current == get_thread()->active_handshaker(), > 277 "must be current thread or direct handshake"); > > nit - the indent on L277 looks wrong in the webrev, but it looks right in > this paste. I don't know which is telling the truth. It was wrong - fixed. > https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-101 > > 358 this->as_Java_thread()->set_stack_overflow_limit(); > 359 this->as_Java_thread()->set_reserved_stack_activation(stack_base()); > nit - do you really need 'this->' here? Nope. Fixed. > https://openjdk.github.io/cr/?repo=jdk&pr=37&range=06#frames-107 > > old code: > 2074 if (thread_id == 0) { > 2075 // current thread > 2076 if (THREAD->is_Java_thread()) { > 2077 return ((JavaThread*)THREAD)->cooked_allocated_bytes(); > 2078 } > 2079 return -1; > > new code: > 2074 if (thread_id == 0) { // current thread > 2075 return thread->cooked_allocated_bytes(); > > If the calling thread is not a JavaThread and passes a thread_id ==0, > I don't think the returns are equivalent. This code is in a JVM_ENTRY - so both THREAD and thread refer to JavaThread::current(), so we can never hit the "return -1;". > The craziness in the JavaThread::pd_get_top_frame() functions made my head hurt. > Thanks for cleaning that up! Thanks again for the review. v8 will be appearing shortly. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/37 > From dholmes at openjdk.java.net Thu Sep 10 03:18:23 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Sep 2020 03:18:23 GMT Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v8] In-Reply-To: References: Message-ID: > This is a rather large but generally simple cleanup. > > We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify > this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(), > which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was > also added to allow use in cases where we start with "const Thread *". Summary of changes: > - changed raw casts to use as_Java_thread() > - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread() > - Removed checks that are checking the type system e.g. > void foo(JavaThread* t) { > assert(t->is_Java_thread(), "must be") > the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry > about that then we would need asserts like this on every method that expects a JavaThread! The right place for the > assertion is at the head of any such call chain. > - Removed asserts that are already guaranteed in the caller. > - Use JavaThread::current() where appropriate. > - Use pre-existing "thread" variable where available rather than casting THREAD > > Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have > been missed. > Testing: tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Fixed serious bug in dependencies.cpp. The v1 change was wrong and got restored but not commited, then a later rollback to v1 lost the fix. Minor issues Dan spotted now fixed. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/37/files - new: https://git.openjdk.java.net/jdk/pull/37/files/50575621..f3d26024 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=37&range=06-07 Stats: 7 lines in 3 files changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/37.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/37/head:pull/37 PR: https://git.openjdk.java.net/jdk/pull/37 From iklam at openjdk.java.net Thu Sep 10 04:36:51 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 10 Sep 2020 04:36:51 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v6] In-Reply-To: References: Message-ID: <6RkbfFegd6pZ44iajJiHrorU2QL91PZApb08Rvp20Fk=.248ba4f6-7572-4cba-9cb8-781cbc192d26@github.com> > The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the > same patch as > [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/) > published in > [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html). The > rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge branch 'master' into 8243208-cleanup-jvmflag-impl - Minor code clean up suggested by David Holmes - Feedback by Gerard (hotspot-dev/2020-September/043019.html) - Refactored JVMFlagLookup::hash_code(); Cleaned up LimitGetter::no_limit() - Fixed JVMFlag::is_writeable() - (a) coding style nits and comments, (b) updated HOWTO in globals.hpp, (c) added JVMFlag::check_all_flag_declarations(), (d) removed product_rw which is not used by any flags - 8243208: Clean up JVMFlag implementation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/82/files - new: https://git.openjdk.java.net/jdk/pull/82/files/15547ebe..1b63ac6f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=04-05 Stats: 452 lines in 56 files changed: 165 ins; 165 del; 122 mod Patch: https://git.openjdk.java.net/jdk/pull/82.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/82/head:pull/82 PR: https://git.openjdk.java.net/jdk/pull/82 From thartmann at openjdk.java.net Thu Sep 10 05:44:39 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 10 Sep 2020 05:44:39 GMT Subject: Integrated: 8252889: Obsolete -XX:+InsertMemBarAfterArraycopy In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 10:04:35 GMT, Tobias Hartmann wrote: > The InsertMemBarAfterArraycopy product flag (enabled by default) is broken. I propose to simply remove it. > The corresponding CSR (JDK-8252890) is still waiting for approval. > > Thanks, > Tobias This pull request has now been integrated. Changeset: f78f7805 Author: Tobias Hartmann URL: https://git.openjdk.java.net/jdk/commit/f78f7805 Stats: 17 lines in 3 files changed: 15 ins; 1 del; 1 mod 8252889: Obsolete -XX:+InsertMemBarAfterArraycopy Reviewed-by: shade, adityam ------------- PR: https://git.openjdk.java.net/jdk/pull/69 From kbarrett at openjdk.java.net Thu Sep 10 06:19:13 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 10 Sep 2020 06:19:13 GMT Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v8] In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 03:18:23 GMT, David Holmes wrote: >> This is a rather large but generally simple cleanup. >> >> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify >> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(), >> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was >> also added to allow use in cases where we start with "const Thread *". Summary of changes: >> - changed raw casts to use as_Java_thread() >> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread() >> - Removed checks that are checking the type system e.g. >> void foo(JavaThread* t) { >> assert(t->is_Java_thread(), "must be") >> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry >> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the >> assertion is at the head of any such call chain. >> - Removed asserts that are already guaranteed in the caller. >> - Use JavaThread::current() where appropriate. >> - Use pre-existing "thread" variable where available rather than casting THREAD >> >> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have >> been missed. >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fixed serious bug in dependencies.cpp. The v1 change was wrong and got restored but > not commited, then a later rollback to v1 lost the fix. > > Minor issues Dan spotted now fixed. Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/37 From alanb at openjdk.java.net Thu Sep 10 06:58:57 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 10 Sep 2020 06:58:57 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Wed, 9 Sep 2020 09:49:44 GMT, Philippe Marschall wrote: >> Hello, newbie here >> >> I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. >> >> - I tried to update the copyright year to 2020 in every file. >> - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. >> - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of >> imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. >> - All tier1 tests pass. >> - One jpackage/jlink tier2 test fails but I don't believe it is related. >> - Some tier3 Swing tests fail but I don't think they are related. > > Philippe Marschall has refreshed the contents of this pull request, and previous commits have been removed. The > incremental views will show differences compared to the previous content of the PR. The pull request contains one new > commit since the last revision: > 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From dholmes at openjdk.java.net Thu Sep 10 07:40:40 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Sep 2020 07:40:40 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v6] In-Reply-To: <6RkbfFegd6pZ44iajJiHrorU2QL91PZApb08Rvp20Fk=.248ba4f6-7572-4cba-9cb8-781cbc192d26@github.com> References: <6RkbfFegd6pZ44iajJiHrorU2QL91PZApb08Rvp20Fk=.248ba4f6-7572-4cba-9cb8-781cbc192d26@github.com> Message-ID: On Thu, 10 Sep 2020 04:36:51 GMT, Ioi Lam wrote: >> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the >> same patch as >> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/) >> published in >> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html). The >> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes > the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last > revision: > - Merge branch 'master' into 8243208-cleanup-jvmflag-impl > - Minor code clean up suggested by David Holmes > - Feedback by Gerard (hotspot-dev/2020-September/043019.html) > - Refactored JVMFlagLookup::hash_code(); Cleaned up LimitGetter::no_limit() > - Fixed JVMFlag::is_writeable() > - (a) coding style nits and comments, (b) updated HOWTO in globals.hpp, (c) added JVMFlag::check_all_flag_declarations(), > (d) removed product_rw which is not used by any flags > - 8243208: Clean up JVMFlag implementation Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/82 From github.com+2210496+thatsIch at openjdk.java.net Thu Sep 10 08:52:25 2020 From: github.com+2210496+thatsIch at openjdk.java.net (thatsIch) Date: Thu, 10 Sep 2020 08:52:25 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). @doom369 jcheck requires an associated issue ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Thu Sep 10 08:52:21 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Thu, 10 Sep 2020 08:52:21 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() Message-ID: **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). ------------- Commit messages: - Merge branch 'master' of https://github.com/doom369/jdk into reaplce_equals_with_is_empty - revert change in classes that maintain jdk 1.4 compatibility - Improvement: replace all occurrences of the .equals("") usages with .isEmpty() Changes: https://git.openjdk.java.net/jdk/pull/29/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=29&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252999 Stats: 234 lines in 150 files changed: 0 ins; 0 del; 234 mod Patch: https://git.openjdk.java.net/jdk/pull/29.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/29/head:pull/29 PR: https://git.openjdk.java.net/jdk/pull/29 From kcr at openjdk.java.net Thu Sep 10 08:52:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 10 Sep 2020 08:52:25 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 07:57:48 GMT, Dmitriy Dumanskiy wrote: >> @doom369 jcheck requires an associated issue > > @mrserb hello. Thanks for the review. Any further actions required from me? Before this Enhancement can be formally reviewed, you will need a JBS bug ID. If you are already working with a Committer or Reviewer in the `jdk` project who has agreed to sponsor your change, they can file the Enhancement request. Otherwise, you can file it using the web interface at [bugreport.java.com](https://bugreport.java.com/). Once you have a JBS bug ID, you need to edit the PR title to include that bug ID (without the `JDK-`) replacing "Improvement". Since this PR cuts across many functional areas (each gray label represents a functional area), you should expect a longer review process, since someone from each functional area will need to look at the changes in their area (like @mrserb started to do for the `2d` area). ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Thu Sep 10 08:52:25 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Thu, 10 Sep 2020 08:52:25 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 18:08:15 GMT, thatsIch wrote: >> **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found >> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). > > @doom369 jcheck requires an associated issue @mrserb hello. Thanks for the review. Any further actions required from me? ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From serb at openjdk.java.net Thu Sep 10 08:52:29 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 10 Sep 2020 08:52:29 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). src/demo/share/java2d/J2DBench/src/j2dbench/tests/iio/InputImageTests.java line 187: > 185: String format = spi.getFormatNames()[0].toLowerCase(); > 186: String suffix = spi.getFileSuffixes()[0].toLowerCase(); > 187: if (suffix == null || suffix.equals("")) { This file intentionally maintains compatibility to jdk1.4, so equals("") should be used. src/demo/share/java2d/J2DBench/src/j2dbench/tests/iio/OutputImageTests.java line 146: > 144: String format = spi.getFormatNames()[0].toLowerCase(); > 145: String suffix = spi.getFileSuffixes()[0].toLowerCase(); > 146: if (suffix == null || suffix.equals("")) { This file intentionally maintains compatibility to jdk1.4, so equals("") should be used. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Thu Sep 10 08:52:26 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Thu, 10 Sep 2020 08:52:26 GMT Subject: RFR: 8252999: replace all String.equals("") usages with String.isEmpty() In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 20:21:44 GMT, Kevin Rushforth wrote: >> @mrserb hello. Thanks for the review. Any further actions required from me? > > Before this Enhancement can be formally reviewed, you will need a JBS bug ID. If you are already working with a > Committer or Reviewer in the `jdk` project who has agreed to sponsor your change, they can file the Enhancement > request. Otherwise, you can file it using the web interface at [bugreport.java.com](https://bugreport.java.com/). Once > you have a JBS bug ID, you need to edit the PR title to include that bug ID (without the `JDK-`) replacing > "Improvement". Since this PR cuts across many functional areas (each gray label represents a functional area), you > should expect a longer review process, since someone from each functional area will need to look at the changes in > their area (like @mrserb started to do for the `2d` area). @kevinrushforth thanks. Done. Similar issues: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215014 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8251246 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8223237 could be joined somehow? ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From adam.farley at uk.ibm.com Thu Sep 10 09:11:45 2020 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 10 Sep 2020 10:11:45 +0100 Subject: RFR: 8252997: Null-proofing for linker_md.c Message-ID: Hi All, Small change proposed here to protect against null return values from jvmtiAllocation. Requesting reviews and sponsor, please. Bug: https://bugs.openjdk.java.net/browse/JDK-8252997 Webrev: http://cr.openjdk.java.net/~afarley/8252997/webrev/ Best Regards Adam Farley IBM Runtimes Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From sgehwolf at redhat.com Thu Sep 10 09:53:58 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 10 Sep 2020 11:53:58 +0200 Subject: RFR: 8252997: Null-proofing for linker_md.c In-Reply-To: References: Message-ID: <3beab2e98420de53d9f7fd9125759fc033c27476.camel@redhat.com> Hi Adam, jdk/jdk moved to skara[1]. Please re-create the patch as a github PR (or with the skara CLI tooling). Thanks, Severin [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004694.html On Thu, 2020-09-10 at 10:11 +0100, Adam Farley8 wrote: > Hi All, > > Small change proposed here to protect against null return values from > jvmtiAllocation. > > Requesting reviews and sponsor, please. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252997 > > Webrev: http://cr.openjdk.java.net/~afarley/8252997/webrev/ > > Best Regards > > Adam Farley > IBM Runtimes > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From alanb at openjdk.java.net Thu Sep 10 10:42:57 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 10 Sep 2020 10:42:57 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 08:47:35 GMT, Dmitriy Dumanskiy wrote: >> Before this Enhancement can be formally reviewed, you will need a JBS bug ID. If you are already working with a >> Committer or Reviewer in the `jdk` project who has agreed to sponsor your change, they can file the Enhancement >> request. Otherwise, you can file it using the web interface at [bugreport.java.com](https://bugreport.java.com/). Once >> you have a JBS bug ID, you need to edit the PR title to include that bug ID (without the `JDK-`) replacing >> "Improvement". Since this PR cuts across many functional areas (each gray label represents a functional area), you >> should expect a longer review process, since someone from each functional area will need to look at the changes in >> their area (like @mrserb started to do for the `2d` area). > > @kevinrushforth thanks. Done. > > Similar issues: > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215014 > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8251246 > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8223237 > > could be joined somehow? The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use JDK-8215014 rather than creating a new issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From dholmes at openjdk.java.net Thu Sep 10 11:24:10 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Sep 2020 11:24:10 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 10:40:15 GMT, Alan Bateman wrote: >> @kevinrushforth thanks. Done. >> >> Similar issues: >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215014 >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8251246 >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8223237 >> >> could be joined somehow? > > The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do > the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more > more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code > (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan > code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use > JDK-8215014 rather than creating a new issue. This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. Thank you. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Thu Sep 10 12:07:57 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Thu, 10 Sep 2020 12:07:57 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote: >> The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do >> the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more >> more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code >> (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan >> code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use >> JDK-8215014 rather than creating a new issue. > > This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise > the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. > Thank you. I have in mind dozens of improvements all over the code like this one. I already did some further review and in most cases, those tiny changes go trough all codebase. I can create PR for every separate module, but in general, it would multiply x5 the number of PRs in total. If you think it's a better way to go, no problem, I can do that. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From kcr at openjdk.java.net Thu Sep 10 12:21:25 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 10 Sep 2020 12:21:25 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote: >> The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do >> the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more >> more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code >> (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan >> code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use >> JDK-8215014 rather than creating a new issue. > > This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise > the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. > Thank you. @dholmes-ora raises a good point. Hopefully there is a balance point between a dozen different bugs / pull requests each targeting one area and one bug / PR targeting a dozen separate areas. I don't have a good general rule to suggest. Maybe @AlanBateman or @jddarcy can offer some advice? ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From kbarrett at openjdk.java.net Thu Sep 10 13:34:21 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 10 Sep 2020 13:34:21 GMT Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space In-Reply-To: <20eOaz9cH8FXrZxXMnRrAHsWOejOJIuYtppWGjgupwQ=.bf82cf62-d93a-4d83-bcb8-bd5919fb130f@github.com> References: <20eOaz9cH8FXrZxXMnRrAHsWOejOJIuYtppWGjgupwQ=.bf82cf62-d93a-4d83-bcb8-bd5919fb130f@github.com> Message-ID: On Wed, 9 Sep 2020 12:36:11 GMT, Albert Mingkun Yang wrote: >> This is rework of initial change from before the transition to git. >> The initial RFR email is attached below. >> >> The primary change is to limit the number of partial array tasks in >> the queues for any given array. The original change just split up an >> array into N tasks that were all enqueued at once. But for a large >> array this could be a lot of tasks, leading to significant and >> unnecessary queue expansion. Instead we now limit the number of tasks >> for a given array based on the number of workers, and only gradually >> add tasks up to that limit. This gives other threads an opportunity >> to steal such tasks, while still keeping queue growth under control. >> >> Most of the calculation for this is handled by a new helper class, so >> this can later be shared with ParallelGC. >> >> The dispatch on array klass type for has also been changed. It now >> affirmatively breaks Project Valhalla, rather than quietly doing >> something that probably isn't what is actually wanted. I'll discuss >> with them so there is a plan for dealing with it when they take this >> update. >> >> Ran tier1-6 in mach5 and some local stress tests. >> >> Performance testing was unchanged from previous, except I wasn't able >> to reproduce the small specjbb2015 critical-jops improvement >> previously seen on one platform. My suspicion is that improvement was >> a statistical abberation. >> >> --- Initial RFR email --- >> >> RFR: 8158045: Improve large object handling during evacuation >> RFR: 8027761: Investigate fast-path for scanning only objects with references during gc >> RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space >> >> Please review this change to type dispatching and handling in G1's >> evacuation copying, in order to improve the hot paths and improve array >> handling. This change addresses several closely co-located enhancement >> requests; it seemed difficult to split them up in a sensible way. >> >> do_copy_to_survivor_space now gets the klass of the object being copied >> once, up front, for use in multiple places. This avoids fetching (including >> re-decoding when compressed) the klass multiple times. This addresses part >> of JDK-8027545. >> >> Moved check for and handling of string deduplication later, only applying it >> after the special array cases have been dealt with, since strings are not >> arrays. (They are header objects pointing to an array of character values.) >> >> Special case typeArray, doing nothing other than the copy, since they >> contain no oops that need to be processed. This addresses JDK-8027761. >> >> Changed handling of objArray, pushing all of the partial array tasks up >> front, rather than processing the current chunk after pushing a single task >> for the remaining work. This addresses JDK-8158045. >> >> As part of these, cached some more frequently accessed values in >> G1ParScanThreadState member variables. This addresses part of part of >> JDK-8027545. >> >> While both the old and new code will work for Project Valhalla, the handling >> of arrays should be updated for that project, which introduces new array >> types. >> >> Deleted a lingering reference to G1ParScanPartialArrayClosure that was >> deleted long ago (JDK-8035330, JDK 9). >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8158045 >> https://bugs.openjdk.java.net/browse/JDK-8027761 >> https://bugs.openjdk.java.net/browse/JDK-8027545 >> >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ >> >> Testing: >> tier1-3 >> >> performance testing - seems to be at worst performance neutral, with a >> statistically significant 3% improvement in specjbb2015 critical-jops seen >> on one platform. > > src/hotspot/share/gc/g1/g1ParScanThreadState.cpp line 498: > >> 496: } >> 497: >> 498: if (G1StringDedup::is_enabled() && (klass == SystemDictionary::String_klass())) { > > It's unclear to me why the additional checking with `String_klass()`. Faster fast-path, avoiding some of the other calculations before going into G1StringDedup::enqueue_from_evacuation and only there discovering we're not dealing with a String at all. But this doesn't belong in this changeset. I'll remove it. > src/hotspot/share/gc/g1/g1ParScanThreadState.cpp line 253: > >> 251: for (uint i = 0; i < step._ncreate; ++i) { >> 252: push_on_queue(ScannerTask(PartialArrayScanTask(from_obj))); >> 253: } > > I think the intention would be clearer, if `start` returns a pair `` instead > of reusing `Step` struct. I reused Step intentionally, to not commit at this layer to only creating one partial task. The stepper can change its calculations and this layer won't care. > src/hotspot/share/oops/arrayOop.hpp line 107: > >> 105: // Accessors for instance variable which is not a C++ declared nonstatic >> 106: // field. >> 107: int length() const { return *length_addr(); } > > Personally, I find the original code easier to read, since the identical content, `*(int*)(((char*)mem) + > length_offset_in_bytes())` exists in both `length()` and `set_length(HeapWord* mem, int length)`. I should have included the 2-arg set_length in the changes to make everything consistent. I'll revise in the next update. ------------- PR: https://git.openjdk.java.net/jdk/pull/90 From dholmes at openjdk.java.net Thu Sep 10 13:56:10 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Sep 2020 13:56:10 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> References: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> Message-ID: On Thu, 10 Sep 2020 12:18:51 GMT, Kevin Rushforth wrote: >> This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise >> the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. >> Thank you. > > @dholmes-ora raises a good point. Hopefully there is a balance point between a dozen different bugs / pull requests > each targeting one area and one bug / PR targeting a dozen separate areas. I don't have a good general rule to suggest. > Maybe @AlanBateman or @jddarcy can offer some advice? 14 cc'd mailing lists is unworkable. You need to be subscribed to lists to post, but even if you are a reply-all will be delayed due to all of the mails being held up for moderator approval due to: " Too many recipients to the message" I have a longer email coming once it gets through the moderator approval delay. :( ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From kbarrett at openjdk.java.net Thu Sep 10 13:57:48 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 10 Sep 2020 13:57:48 GMT Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 12:07:38 GMT, Stefan Johansson wrote: >> This is rework of initial change from before the transition to git. >> The initial RFR email is attached below. >> >> The primary change is to limit the number of partial array tasks in >> the queues for any given array. The original change just split up an >> array into N tasks that were all enqueued at once. But for a large >> array this could be a lot of tasks, leading to significant and >> unnecessary queue expansion. Instead we now limit the number of tasks >> for a given array based on the number of workers, and only gradually >> add tasks up to that limit. This gives other threads an opportunity >> to steal such tasks, while still keeping queue growth under control. >> >> Most of the calculation for this is handled by a new helper class, so >> this can later be shared with ParallelGC. >> >> The dispatch on array klass type for has also been changed. It now >> affirmatively breaks Project Valhalla, rather than quietly doing >> something that probably isn't what is actually wanted. I'll discuss >> with them so there is a plan for dealing with it when they take this >> update. >> >> Ran tier1-6 in mach5 and some local stress tests. >> >> Performance testing was unchanged from previous, except I wasn't able >> to reproduce the small specjbb2015 critical-jops improvement >> previously seen on one platform. My suspicion is that improvement was >> a statistical abberation. >> >> --- Initial RFR email --- >> >> RFR: 8158045: Improve large object handling during evacuation >> RFR: 8027761: Investigate fast-path for scanning only objects with references during gc >> RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space >> >> Please review this change to type dispatching and handling in G1's >> evacuation copying, in order to improve the hot paths and improve array >> handling. This change addresses several closely co-located enhancement >> requests; it seemed difficult to split them up in a sensible way. >> >> do_copy_to_survivor_space now gets the klass of the object being copied >> once, up front, for use in multiple places. This avoids fetching (including >> re-decoding when compressed) the klass multiple times. This addresses part >> of JDK-8027545. >> >> Moved check for and handling of string deduplication later, only applying it >> after the special array cases have been dealt with, since strings are not >> arrays. (They are header objects pointing to an array of character values.) >> >> Special case typeArray, doing nothing other than the copy, since they >> contain no oops that need to be processed. This addresses JDK-8027761. >> >> Changed handling of objArray, pushing all of the partial array tasks up >> front, rather than processing the current chunk after pushing a single task >> for the remaining work. This addresses JDK-8158045. >> >> As part of these, cached some more frequently accessed values in >> G1ParScanThreadState member variables. This addresses part of part of >> JDK-8027545. >> >> While both the old and new code will work for Project Valhalla, the handling >> of arrays should be updated for that project, which introduces new array >> types. >> >> Deleted a lingering reference to G1ParScanPartialArrayClosure that was >> deleted long ago (JDK-8035330, JDK 9). >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8158045 >> https://bugs.openjdk.java.net/browse/JDK-8027761 >> https://bugs.openjdk.java.net/browse/JDK-8027545 >> >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ >> >> Testing: >> tier1-3 >> >> performance testing - seems to be at worst performance neutral, with a >> statistically significant 3% improvement in specjbb2015 critical-jops seen >> on one platform. > > src/hotspot/share/gc/g1/g1ParScanThreadState.hpp line 84: > >> 82: bool _old_gen_is_full; >> 83: // Size (in elements) of a partial objArray task chunk. >> 84: int _partial_objarray_chunk_size; > > I would prefer to skip the "obj"-part here to have more consistent naming or, as mentioned above, include it in the > stepper instead. Some of the naming and factoring I've done is forward looking. I think we should consider splitting the copying part as well as the scanning, and chunking the copy of typeArrays. For example, JDK-8031565 suggests copying large typeArrays as part of termination waiting; I think splitting them into partial array tasks to use the normal parallelism in the framework is better than some new side channel. The chunk size for that should probably be substantially larger (and depend on the element size) than for objArray. Also, Project Valhalla is going to add new kinds of arrays that are neither objArray nor typeArray. We'll want to split them too. The same splitting calculations can apply, even though the chunk size may be different (and probably depends on the element klass). ------------- PR: https://git.openjdk.java.net/jdk/pull/90 From kbarrett at openjdk.java.net Thu Sep 10 14:00:28 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 10 Sep 2020 14:00:28 GMT Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 12:14:31 GMT, Stefan Johansson wrote: >> This is rework of initial change from before the transition to git. >> The initial RFR email is attached below. >> >> The primary change is to limit the number of partial array tasks in >> the queues for any given array. The original change just split up an >> array into N tasks that were all enqueued at once. But for a large >> array this could be a lot of tasks, leading to significant and >> unnecessary queue expansion. Instead we now limit the number of tasks >> for a given array based on the number of workers, and only gradually >> add tasks up to that limit. This gives other threads an opportunity >> to steal such tasks, while still keeping queue growth under control. >> >> Most of the calculation for this is handled by a new helper class, so >> this can later be shared with ParallelGC. >> >> The dispatch on array klass type for has also been changed. It now >> affirmatively breaks Project Valhalla, rather than quietly doing >> something that probably isn't what is actually wanted. I'll discuss >> with them so there is a plan for dealing with it when they take this >> update. >> >> Ran tier1-6 in mach5 and some local stress tests. >> >> Performance testing was unchanged from previous, except I wasn't able >> to reproduce the small specjbb2015 critical-jops improvement >> previously seen on one platform. My suspicion is that improvement was >> a statistical abberation. >> >> --- Initial RFR email --- >> >> RFR: 8158045: Improve large object handling during evacuation >> RFR: 8027761: Investigate fast-path for scanning only objects with references during gc >> RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space >> >> Please review this change to type dispatching and handling in G1's >> evacuation copying, in order to improve the hot paths and improve array >> handling. This change addresses several closely co-located enhancement >> requests; it seemed difficult to split them up in a sensible way. >> >> do_copy_to_survivor_space now gets the klass of the object being copied >> once, up front, for use in multiple places. This avoids fetching (including >> re-decoding when compressed) the klass multiple times. This addresses part >> of JDK-8027545. >> >> Moved check for and handling of string deduplication later, only applying it >> after the special array cases have been dealt with, since strings are not >> arrays. (They are header objects pointing to an array of character values.) >> >> Special case typeArray, doing nothing other than the copy, since they >> contain no oops that need to be processed. This addresses JDK-8027761. >> >> Changed handling of objArray, pushing all of the partial array tasks up >> front, rather than processing the current chunk after pushing a single task >> for the remaining work. This addresses JDK-8158045. >> >> As part of these, cached some more frequently accessed values in >> G1ParScanThreadState member variables. This addresses part of part of >> JDK-8027545. >> >> While both the old and new code will work for Project Valhalla, the handling >> of arrays should be updated for that project, which introduces new array >> types. >> >> Deleted a lingering reference to G1ParScanPartialArrayClosure that was >> deleted long ago (JDK-8035330, JDK 9). >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8158045 >> https://bugs.openjdk.java.net/browse/JDK-8027761 >> https://bugs.openjdk.java.net/browse/JDK-8027545 >> >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ >> >> Testing: >> tier1-3 >> >> performance testing - seems to be at worst performance neutral, with a >> statistically significant 3% improvement in specjbb2015 critical-jops seen >> on one platform. > > src/hotspot/share/gc/g1/g1ParScanThreadState.hpp line 165: > >> 163: private: >> 164: inline void do_partial_array(PartialArrayScanTask task); >> 165: inline void start_partial_objArray(G1HeapRegionAttr dest_dir, oop from, oop to); > > Same here, drop "obj" for consistent naming and avoiding the camel-case. See response above about the name of _partial_objarray_chunk_size. But I should probably be consistent about objarray vs objArray. Since objArray is what it is over in runtime oop-land I'm going to go with that. ------------- PR: https://git.openjdk.java.net/jdk/pull/90 From kbarrett at openjdk.java.net Thu Sep 10 14:05:17 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 10 Sep 2020 14:05:17 GMT Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 12:19:34 GMT, Stefan Johansson wrote: >> This is rework of initial change from before the transition to git. >> The initial RFR email is attached below. >> >> The primary change is to limit the number of partial array tasks in >> the queues for any given array. The original change just split up an >> array into N tasks that were all enqueued at once. But for a large >> array this could be a lot of tasks, leading to significant and >> unnecessary queue expansion. Instead we now limit the number of tasks >> for a given array based on the number of workers, and only gradually >> add tasks up to that limit. This gives other threads an opportunity >> to steal such tasks, while still keeping queue growth under control. >> >> Most of the calculation for this is handled by a new helper class, so >> this can later be shared with ParallelGC. >> >> The dispatch on array klass type for has also been changed. It now >> affirmatively breaks Project Valhalla, rather than quietly doing >> something that probably isn't what is actually wanted. I'll discuss >> with them so there is a plan for dealing with it when they take this >> update. >> >> Ran tier1-6 in mach5 and some local stress tests. >> >> Performance testing was unchanged from previous, except I wasn't able >> to reproduce the small specjbb2015 critical-jops improvement >> previously seen on one platform. My suspicion is that improvement was >> a statistical abberation. >> >> --- Initial RFR email --- >> >> RFR: 8158045: Improve large object handling during evacuation >> RFR: 8027761: Investigate fast-path for scanning only objects with references during gc >> RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space >> >> Please review this change to type dispatching and handling in G1's >> evacuation copying, in order to improve the hot paths and improve array >> handling. This change addresses several closely co-located enhancement >> requests; it seemed difficult to split them up in a sensible way. >> >> do_copy_to_survivor_space now gets the klass of the object being copied >> once, up front, for use in multiple places. This avoids fetching (including >> re-decoding when compressed) the klass multiple times. This addresses part >> of JDK-8027545. >> >> Moved check for and handling of string deduplication later, only applying it >> after the special array cases have been dealt with, since strings are not >> arrays. (They are header objects pointing to an array of character values.) >> >> Special case typeArray, doing nothing other than the copy, since they >> contain no oops that need to be processed. This addresses JDK-8027761. >> >> Changed handling of objArray, pushing all of the partial array tasks up >> front, rather than processing the current chunk after pushing a single task >> for the remaining work. This addresses JDK-8158045. >> >> As part of these, cached some more frequently accessed values in >> G1ParScanThreadState member variables. This addresses part of part of >> JDK-8027545. >> >> While both the old and new code will work for Project Valhalla, the handling >> of arrays should be updated for that project, which introduces new array >> types. >> >> Deleted a lingering reference to G1ParScanPartialArrayClosure that was >> deleted long ago (JDK-8035330, JDK 9). >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8158045 >> https://bugs.openjdk.java.net/browse/JDK-8027761 >> https://bugs.openjdk.java.net/browse/JDK-8027545 >> >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ >> >> Testing: >> tier1-3 >> >> performance testing - seems to be at worst performance neutral, with a >> statistically significant 3% improvement in specjbb2015 critical-jops seen >> on one platform. > > src/hotspot/share/gc/shared/partialArrayTaskStepper.cpp line 34: > >> 32: // that maximizes available parallelism. >> 33: return n_workers; >> 34: } > > In preparation for a more advanced logic for the limit, or why not just use the input at the call-site? Being noncommittal about whether something more "clever" could or should be done. > src/hotspot/share/gc/shared/partialArrayTaskStepper.inline.hpp line 71: > >> 69: // The from-space object contains the real length. >> 70: int length = from->length(); >> 71: assert(start < length, "invariant: start %d, length %d", start, length); > > Just so I'm not missing anything. There will never be more tasks than chunks left, so there is no risk that we have a > race for the last chunk and thus hit this assertion? That's correct. Unless there's a bug in the analysis or implementation I haven't found. That's why it's an invariant. ------------- PR: https://git.openjdk.java.net/jdk/pull/90 From kbarrett at openjdk.java.net Thu Sep 10 14:08:07 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 10 Sep 2020 14:08:07 GMT Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 12:49:56 GMT, Stefan Johansson wrote: >> This is rework of initial change from before the transition to git. >> The initial RFR email is attached below. >> >> The primary change is to limit the number of partial array tasks in >> the queues for any given array. The original change just split up an >> array into N tasks that were all enqueued at once. But for a large >> array this could be a lot of tasks, leading to significant and >> unnecessary queue expansion. Instead we now limit the number of tasks >> for a given array based on the number of workers, and only gradually >> add tasks up to that limit. This gives other threads an opportunity >> to steal such tasks, while still keeping queue growth under control. >> >> Most of the calculation for this is handled by a new helper class, so >> this can later be shared with ParallelGC. >> >> The dispatch on array klass type for has also been changed. It now >> affirmatively breaks Project Valhalla, rather than quietly doing >> something that probably isn't what is actually wanted. I'll discuss >> with them so there is a plan for dealing with it when they take this >> update. >> >> Ran tier1-6 in mach5 and some local stress tests. >> >> Performance testing was unchanged from previous, except I wasn't able >> to reproduce the small specjbb2015 critical-jops improvement >> previously seen on one platform. My suspicion is that improvement was >> a statistical abberation. >> >> --- Initial RFR email --- >> >> RFR: 8158045: Improve large object handling during evacuation >> RFR: 8027761: Investigate fast-path for scanning only objects with references during gc >> RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space >> >> Please review this change to type dispatching and handling in G1's >> evacuation copying, in order to improve the hot paths and improve array >> handling. This change addresses several closely co-located enhancement >> requests; it seemed difficult to split them up in a sensible way. >> >> do_copy_to_survivor_space now gets the klass of the object being copied >> once, up front, for use in multiple places. This avoids fetching (including >> re-decoding when compressed) the klass multiple times. This addresses part >> of JDK-8027545. >> >> Moved check for and handling of string deduplication later, only applying it >> after the special array cases have been dealt with, since strings are not >> arrays. (They are header objects pointing to an array of character values.) >> >> Special case typeArray, doing nothing other than the copy, since they >> contain no oops that need to be processed. This addresses JDK-8027761. >> >> Changed handling of objArray, pushing all of the partial array tasks up >> front, rather than processing the current chunk after pushing a single task >> for the remaining work. This addresses JDK-8158045. >> >> As part of these, cached some more frequently accessed values in >> G1ParScanThreadState member variables. This addresses part of part of >> JDK-8027545. >> >> While both the old and new code will work for Project Valhalla, the handling >> of arrays should be updated for that project, which introduces new array >> types. >> >> Deleted a lingering reference to G1ParScanPartialArrayClosure that was >> deleted long ago (JDK-8035330, JDK 9). >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8158045 >> https://bugs.openjdk.java.net/browse/JDK-8027761 >> https://bugs.openjdk.java.net/browse/JDK-8027545 >> >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ >> >> Testing: >> tier1-3 >> >> performance testing - seems to be at worst performance neutral, with a >> statistically significant 3% improvement in specjbb2015 critical-jops seen >> on one platform. > > src/hotspot/share/gc/g1/g1ParScanThreadState.cpp line 68: > >> 66: _old_gen_is_full(false), >> 67: _partial_objarray_chunk_size(ParGCArrayScanChunk), >> 68: _partial_array_stepper(n_workers), > > What do you think about saving the chunk size in the stepper instead? Then we don't need to pass it in to `start()` and > `next()`. To avoid needing it for the call to `oop_iterate_range()` we could instead have the `Step` include both the > start and end index. See above discussion about naming and factoring. The same stepper can support multiple array types if the chunk size is external to the stepper. ------------- PR: https://git.openjdk.java.net/jdk/pull/90 From kbarrett at openjdk.java.net Thu Sep 10 14:10:51 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 10 Sep 2020 14:10:51 GMT Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 12:55:12 GMT, Stefan Johansson wrote: >> This is rework of initial change from before the transition to git. >> The initial RFR email is attached below. >> >> The primary change is to limit the number of partial array tasks in >> the queues for any given array. The original change just split up an >> array into N tasks that were all enqueued at once. But for a large >> array this could be a lot of tasks, leading to significant and >> unnecessary queue expansion. Instead we now limit the number of tasks >> for a given array based on the number of workers, and only gradually >> add tasks up to that limit. This gives other threads an opportunity >> to steal such tasks, while still keeping queue growth under control. >> >> Most of the calculation for this is handled by a new helper class, so >> this can later be shared with ParallelGC. >> >> The dispatch on array klass type for has also been changed. It now >> affirmatively breaks Project Valhalla, rather than quietly doing >> something that probably isn't what is actually wanted. I'll discuss >> with them so there is a plan for dealing with it when they take this >> update. >> >> Ran tier1-6 in mach5 and some local stress tests. >> >> Performance testing was unchanged from previous, except I wasn't able >> to reproduce the small specjbb2015 critical-jops improvement >> previously seen on one platform. My suspicion is that improvement was >> a statistical abberation. >> >> --- Initial RFR email --- >> >> RFR: 8158045: Improve large object handling during evacuation >> RFR: 8027761: Investigate fast-path for scanning only objects with references during gc >> RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space >> >> Please review this change to type dispatching and handling in G1's >> evacuation copying, in order to improve the hot paths and improve array >> handling. This change addresses several closely co-located enhancement >> requests; it seemed difficult to split them up in a sensible way. >> >> do_copy_to_survivor_space now gets the klass of the object being copied >> once, up front, for use in multiple places. This avoids fetching (including >> re-decoding when compressed) the klass multiple times. This addresses part >> of JDK-8027545. >> >> Moved check for and handling of string deduplication later, only applying it >> after the special array cases have been dealt with, since strings are not >> arrays. (They are header objects pointing to an array of character values.) >> >> Special case typeArray, doing nothing other than the copy, since they >> contain no oops that need to be processed. This addresses JDK-8027761. >> >> Changed handling of objArray, pushing all of the partial array tasks up >> front, rather than processing the current chunk after pushing a single task >> for the remaining work. This addresses JDK-8158045. >> >> As part of these, cached some more frequently accessed values in >> G1ParScanThreadState member variables. This addresses part of part of >> JDK-8027545. >> >> While both the old and new code will work for Project Valhalla, the handling >> of arrays should be updated for that project, which introduces new array >> types. >> >> Deleted a lingering reference to G1ParScanPartialArrayClosure that was >> deleted long ago (JDK-8035330, JDK 9). >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8158045 >> https://bugs.openjdk.java.net/browse/JDK-8027761 >> https://bugs.openjdk.java.net/browse/JDK-8027545 >> >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ >> >> Testing: >> tier1-3 >> >> performance testing - seems to be at worst performance neutral, with a >> statistically significant 3% improvement in specjbb2015 critical-jops seen >> on one platform. > > src/hotspot/share/gc/shared/partialArrayTaskStepper.hpp line 57: > >> 55: int _index; // Array index for the step. >> 56: uint _ncreate; // Number of new tasks to create. >> 57: }; > > I wouldn't mind having getters for those, but it's not a hard request :) Step is intended to be a trivial data carrier. A (HotSpot) Pair or std::pair (if we used stdlib) would do, except I like named data items. ------------- PR: https://git.openjdk.java.net/jdk/pull/90 From dnsimon at openjdk.java.net Thu Sep 10 14:14:05 2020 From: dnsimon at openjdk.java.net (Doug Simon) Date: Thu, 10 Sep 2020 14:14:05 GMT Subject: RFR: 8252898: remove bulk registration of JFR CompilerPhaseType names In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 15:07:04 GMT, Doug Simon wrote: > The changes made in [JDK-8193210](https://bugs.openjdk.java.net/browse/JDK-8193210) support only [bulk > registration](https://github.com/openjdk/jdk/blob/4e6a4af1866d0007d368b78bf78b6a8e1c8be425/src/hotspot/share/compiler/compilerEvent.hpp#L75) > of compiler phase names with JFR. However, Graal only registers compiler phase names upon first execution of the phase > since the set of phases is not known during VM initialization. This means registration of a Graal phase name needs to > do unnecessary work, wrapping a single name into an array to conform to the bulk registration API. This pull request > updates the registration API to be in terms of a registering a single phase name. @jamsheedcm could you please have a look at this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/77 From kbarrett at openjdk.java.net Thu Sep 10 14:19:45 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 10 Sep 2020 14:19:45 GMT Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 18:34:45 GMT, Stefan Johansson wrote: >> This is rework of initial change from before the transition to git. >> The initial RFR email is attached below. >> >> The primary change is to limit the number of partial array tasks in >> the queues for any given array. The original change just split up an >> array into N tasks that were all enqueued at once. But for a large >> array this could be a lot of tasks, leading to significant and >> unnecessary queue expansion. Instead we now limit the number of tasks >> for a given array based on the number of workers, and only gradually >> add tasks up to that limit. This gives other threads an opportunity >> to steal such tasks, while still keeping queue growth under control. >> >> Most of the calculation for this is handled by a new helper class, so >> this can later be shared with ParallelGC. >> >> The dispatch on array klass type for has also been changed. It now >> affirmatively breaks Project Valhalla, rather than quietly doing >> something that probably isn't what is actually wanted. I'll discuss >> with them so there is a plan for dealing with it when they take this >> update. >> >> Ran tier1-6 in mach5 and some local stress tests. >> >> Performance testing was unchanged from previous, except I wasn't able >> to reproduce the small specjbb2015 critical-jops improvement >> previously seen on one platform. My suspicion is that improvement was >> a statistical abberation. >> >> --- Initial RFR email --- >> >> RFR: 8158045: Improve large object handling during evacuation >> RFR: 8027761: Investigate fast-path for scanning only objects with references during gc >> RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space >> >> Please review this change to type dispatching and handling in G1's >> evacuation copying, in order to improve the hot paths and improve array >> handling. This change addresses several closely co-located enhancement >> requests; it seemed difficult to split them up in a sensible way. >> >> do_copy_to_survivor_space now gets the klass of the object being copied >> once, up front, for use in multiple places. This avoids fetching (including >> re-decoding when compressed) the klass multiple times. This addresses part >> of JDK-8027545. >> >> Moved check for and handling of string deduplication later, only applying it >> after the special array cases have been dealt with, since strings are not >> arrays. (They are header objects pointing to an array of character values.) >> >> Special case typeArray, doing nothing other than the copy, since they >> contain no oops that need to be processed. This addresses JDK-8027761. >> >> Changed handling of objArray, pushing all of the partial array tasks up >> front, rather than processing the current chunk after pushing a single task >> for the remaining work. This addresses JDK-8158045. >> >> As part of these, cached some more frequently accessed values in >> G1ParScanThreadState member variables. This addresses part of part of >> JDK-8027545. >> >> While both the old and new code will work for Project Valhalla, the handling >> of arrays should be updated for that project, which introduces new array >> types. >> >> Deleted a lingering reference to G1ParScanPartialArrayClosure that was >> deleted long ago (JDK-8035330, JDK 9). >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8158045 >> https://bugs.openjdk.java.net/browse/JDK-8027761 >> https://bugs.openjdk.java.net/browse/JDK-8027545 >> >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ >> >> Testing: >> tier1-3 >> >> performance testing - seems to be at worst performance neutral, with a >> statistically significant 3% improvement in specjbb2015 critical-jops seen >> on one platform. > > src/hotspot/share/gc/shared/partialArrayTaskStepper.inline.hpp line 103: > >> 101: uint ncreate = MIN2(_task_fannout, MIN2(remaining_tasks, _task_limit + 1) - pending); >> 102: Step result = { start, ncreate }; >> 103: return result; > > Similar to my comment above, what do you think about trying to write some test for this to verify we never get to many > "tasks". The asserts in the stepper's next() after the increment of to's length verify that we haven't overrun. I haven't thought of a way to verify the algorithm doesn't generate too few tasks though. Well, other than getting crashes because some array elements didn't get processed. But maybe you mean unit tests? I will try to write some; I should have done so already. ------------- PR: https://git.openjdk.java.net/jdk/pull/90 From kim.barrett at oracle.com Thu Sep 10 14:24:08 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 10 Sep 2020 10:24:08 -0400 Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space In-Reply-To: References: Message-ID: <8D351A8D-727B-457E-8254-4A5A4D503DA8@oracle.com> > On Sep 10, 2020, at 10:08 AM, Kim Barrett wrote: > > On Wed, 9 Sep 2020 12:49:56 GMT, Stefan Johansson wrote: >> >> src/hotspot/share/gc/g1/g1ParScanThreadState.cpp line 68: >> >>> 66: _old_gen_is_full(false), >>> 67: _partial_objarray_chunk_size(ParGCArrayScanChunk), >>> 68: _partial_array_stepper(n_workers), >> >> What do you think about saving the chunk size in the stepper instead? Then we don't need to pass it in to `start()` and >> `next()`. To avoid needing it for the call to `oop_iterate_range()` we could instead have the `Step` include both the >> start and end index. > > See above discussion about naming and factoring. The same stepper can support multiple array types if the chunk size > is external to the stepper. Well, that discussion is only ?above" in the github UI tool. Now that I see what happens when I reply there, maybe I won?t do that so much. That?s seriously chatty and massively quoting redundant. From dcubed at openjdk.java.net Thu Sep 10 14:46:40 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 10 Sep 2020 14:46:40 GMT Subject: RFR: 8252406: Introduce Thread::as_Java_thread() convenience function [v8] In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 03:18:23 GMT, David Holmes wrote: >> This is a rather large but generally simple cleanup. >> >> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify >> this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(), >> which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was >> also added to allow use in cases where we start with "const Thread *". Summary of changes: >> - changed raw casts to use as_Java_thread() >> - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread() >> - Removed checks that are checking the type system e.g. >> void foo(JavaThread* t) { >> assert(t->is_Java_thread(), "must be") >> the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry >> about that then we would need asserts like this on every method that expects a JavaThread! The right place for the >> assertion is at the head of any such call chain. >> - Removed asserts that are already guaranteed in the caller. >> - Use JavaThread::current() where appropriate. >> - Use pre-existing "thread" variable where available rather than casting THREAD >> >> Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have >> been missed. >> Testing: tiers 1-3 >> >> Thanks, >> David > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fixed serious bug in dependencies.cpp. The v1 change was wrong and got restored but > not commited, then a later rollback to v1 lost the fix. > > Minor issues Dan spotted now fixed. Incremental looks good to me. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/37 From gziemski at openjdk.java.net Thu Sep 10 15:35:12 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 10 Sep 2020 15:35:12 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v6] In-Reply-To: <6RkbfFegd6pZ44iajJiHrorU2QL91PZApb08Rvp20Fk=.248ba4f6-7572-4cba-9cb8-781cbc192d26@github.com> References: <6RkbfFegd6pZ44iajJiHrorU2QL91PZApb08Rvp20Fk=.248ba4f6-7572-4cba-9cb8-781cbc192d26@github.com> Message-ID: On Thu, 10 Sep 2020 04:36:51 GMT, Ioi Lam wrote: >> The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the >> same patch as >> [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/) >> published in >> [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html). The >> rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes > the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last > revision: > - Merge branch 'master' into 8243208-cleanup-jvmflag-impl > - Minor code clean up suggested by David Holmes > - Feedback by Gerard (hotspot-dev/2020-September/043019.html) > - Refactored JVMFlagLookup::hash_code(); Cleaned up LimitGetter::no_limit() > - Fixed JVMFlag::is_writeable() > - (a) coding style nits and comments, (b) updated HOWTO in globals.hpp, (c) added JVMFlag::check_all_flag_declarations(), > (d) removed product_rw which is not used by any flags > - 8243208: Clean up JVMFlag implementation Marked as reviewed by gziemski (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/82 From gziemski at openjdk.java.net Thu Sep 10 15:45:26 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 10 Sep 2020 15:45:26 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v3] In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 21:06:41 GMT, Coleen Phillimore wrote: >> strlen() is not constexpr so it can't be used here. I added my hand-rolled string_len function in >> [bf90a37](https://github.com/openjdk/jdk/pull/82/commits/bf90a3765720267a8770f7bb0cc6957471ccb21b) so we can share a >> single copy of the hash calculation loop. > > Nice! I had the same question, cool. ------------- PR: https://git.openjdk.java.net/jdk/pull/82 From alanb at openjdk.java.net Thu Sep 10 15:53:05 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 10 Sep 2020 15:53:05 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> Message-ID: <50JcAGF8QbzHSjiilInuGqZqR4A1eil1uYZPH21gcjY=.52e6da5f-de51-4457-9dc0-cfb4c5fc043c@github.com> On Thu, 10 Sep 2020 13:53:10 GMT, David Holmes wrote: >> @dholmes-ora raises a good point. Hopefully there is a balance point between a dozen different bugs / pull requests >> each targeting one area and one bug / PR targeting a dozen separate areas. I don't have a good general rule to suggest. >> Maybe @AlanBateman or @jddarcy can offer some advice? > > 14 cc'd mailing lists is unworkable. You need to be subscribed to lists to post, but even if you are a reply-all will > be delayed due to all of the mails being held up for moderator approval due to: > " Too many recipients to the message" > > I have a longer email coming once it gets through the moderator approval delay. :( Patches that do global replace are always awkward. In this case, there are 150 files changed and most seem to be tests or changes to tools used in the build (includes src/hotspot/share/prims/jvmtiEnvFill.java). If these are dropped from the patch then it leaves just 43 files, many of which are from 3rd party code that can also be dropped. This should reduce the patch down to a manageable 24 or so files that should be trivial to review. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From david.holmes at oracle.com Thu Sep 10 13:49:24 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Sep 2020 23:49:24 +1000 Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On 10/09/2020 10:07 pm, Dmitriy Dumanskiy wrote: > On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote: > >>> The code in java.base was updated to use String::isEmpty in JDK 12 (JDK-8215281). There was follow-up in JDK 13 to do >>> the same in the java.desktop module (JDK-8223237). Changing the remaining usages make sense although I see that more >>> more than half are in tests. It would be good to hear from security-dev on the changes to the Apache Santuario code >>> (in java.xml.crypto module) in case it would be better to contribute those upstream instead. Ditto for the Apache Xalan >>> code (in the java.xml module) but it may be significantly forked already that it doesn't matter. I assume you can use >>> JDK-8215014 rather than creating a new issue. >> >> This should be broken up to deal with the files in different functional areas under different bugids and PRs. Otherwise >> the cross-posting to so many lists is prohibitive. Files in different areas need to be reviewed by different teams. >> Thank you. > > I have in mind dozens of improvements all over the code like this one. I already did some further review and in most > cases, those tiny changes go trough all codebase. I can create PR for every separate module, but in general, it would > multiply x5 the number of PRs in total. If you think it's a better way to go, no problem, I can do that. Find a reasonable middle ground. You have around 14 mailing lists cc'd here, for changes on 150 files. It is very unlikely anyone will review all 150, and files in different areas are, by convention, reviewed by Reviewers for those areas. Even if people only look at a subset of files, communicating that to you effectively so you can figure out when all 150 have been reviewed, is not very practical. My initial breakdown would be: - build - desktop (awt/swing/2d) - serviceability/jmx (the SA and JVMTI changes) - security - core-libs Also note that while the original PR email went out to 14 lists, most people trying to reply-all won't be able to as they don't subscribe to all 14 lists, so the review threads will get very fragmented. Cheers, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/29 > From daniel.daugherty at oracle.com Thu Sep 10 15:06:32 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 10 Sep 2020 11:06:32 -0400 Subject: RFR: 8252997: Null-proofing for linker_md.c In-Reply-To: <3beab2e98420de53d9f7fd9125759fc033c27476.camel@redhat.com> References: <3beab2e98420de53d9f7fd9125759fc033c27476.camel@redhat.com> Message-ID: <9557b513-26f6-7823-bf80-af6f311765a9@oracle.com> Also this fix needs to be reviewed by the Serviceability team. I've moved hotspot-dev at ... to Bcc and added serviceability-dev at ... Dan On 9/10/20 5:53 AM, Severin Gehwolf wrote: > Hi Adam, > > jdk/jdk moved to skara[1]. Please re-create the patch as a github PR > (or with the skara CLI tooling). > > Thanks, > Severin > > [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004694.html > > On Thu, 2020-09-10 at 10:11 +0100, Adam Farley8 wrote: >> Hi All, >> >> Small change proposed here to protect against null return values from >> jvmtiAllocation. >> >> Requesting reviews and sponsor, please. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8252997 >> >> Webrev: http://cr.openjdk.java.net/~afarley/8252997/webrev/ >> >> Best Regards >> >> Adam Farley >> IBM Runtimes >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> From jvernee at openjdk.java.net Thu Sep 10 16:40:57 2020 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 10 Sep 2020 16:40:57 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: <50JcAGF8QbzHSjiilInuGqZqR4A1eil1uYZPH21gcjY=.52e6da5f-de51-4457-9dc0-cfb4c5fc043c@github.com> References: <6drWa_0thvT1k2sn1DI5b-0dHKXc1M7UL2gfwDGb894=.5f2f6415-9b4b-4cfb-a271-96ed185d7018@github.com> <50JcAGF8QbzHSjiilInuGqZqR4A1eil1uYZPH21gcjY=.52e6da5f-de51-4457-9dc0-cfb4c5fc043c@github.com> Message-ID: On Thu, 10 Sep 2020 15:50:39 GMT, Alan Bateman wrote: >> 14 cc'd mailing lists is unworkable. You need to be subscribed to lists to post, but even if you are a reply-all will >> be delayed due to all of the mails being held up for moderator approval due to: >> " Too many recipients to the message" >> >> I have a longer email coming once it gets through the moderator approval delay. :( > > Patches that do global replace are always awkward. In this case, there are 150 files changed and most seem to be tests > or changes to tools used in the build (includes src/hotspot/share/prims/jvmtiEnvFill.java). If these are dropped from > the patch then it leaves just 43 files, many of which are from 3rd party code that can also be dropped. This should > reduce the patch down to a manageable 24 or so files that should be trivial to review. Since one of the motivations for this change is micro benchmark performance, please add a benchmark to the JDKs micro benchmark suite as well. (see e.g. https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench/java/lang). Also, what testing has been done for these changes? ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From psandoz at openjdk.java.net Thu Sep 10 18:02:26 2020 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 10 Sep 2020 18:02:26 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: <9vXfRW4SRrizofvC6H9WecRjoXNNMwvscj7I5nlfj1Q=.c3760baf-604b-4a61-ae24-59500edca721@github.com> On Wed, 9 Sep 2020 09:49:44 GMT, Philippe Marschall wrote: >> Hello, newbie here >> >> I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. >> >> - I tried to update the copyright year to 2020 in every file. >> - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. >> - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of >> imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. >> - All tier1 tests pass. >> - One jpackage/jlink tier2 test fails but I don't believe it is related. >> - Some tier3 Swing tests fail but I don't think they are related. > > Philippe Marschall has refreshed the contents of this pull request, and previous commits have been removed. The > incremental views will show differences compared to the previous content of the PR. The pull request contains one new > commit since the last revision: > 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From gil at azul.com Thu Sep 10 18:25:00 2020 From: gil at azul.com (Gil Tene) Date: Thu, 10 Sep 2020 18:25:00 +0000 Subject: Coordinated Restore at Checkpoint: A new project for start-up optimization? Message-ID: <9884BB85-1950-4C61-930B-FD8FA7852C8E@azul.com> Hello, We would like to open a discussion about a new project focused on "Coordinated Restore at Checkpoint". A possible relevant project name might be Tubthumpting [9]. Over the years, we [at Azul] have tinkered with various ways to improve java start-up time and warmup behavior for different use cases for such improvements. One of the interesting focus areas has been the "starting of a new instance" of an application that has already run instances using identical code, a similar expected profile, and potentially a similar initialization sequence in the past. This is a common scenario in modern application deployments, when e.g. rolling out new code in continuous deployment environment, and when e.g. elastically changing instance counts in e.g. auto-scaling situations. Checkpoint/Restore technologies have evolved in various forms over the past few years, and are available in the multiple forms, including e.g. CRIU [1] and Docker Checkpoint & Restore [2]. While Checkpoint/Restore capabilities have been shown to work across a wide range of applications for e.g. live process or application migration, there are various challenges present for their generic application for new instance deployment. Many of these challenges have to do with the need to deal with a checkpointed state that may not be validly reproducible when restoring multiple instances from the same checkpoint image. This is where Coordinate Restore at Checkpoint (CRaC) comes in. At a high level, CRaC aims to systemically address these challenges by facilitating explicit and intentional coordination between checkpointed applications and a checkpointing mechanism. Such coordination will allow applications to proactively discard problematic state ahead of checkpointing and to reestablish needed state upon restoration. [e.g. closing open file descriptors ahead of a checkpoint, and recreating and binding them after a restore]. Coordination is a powerful enabler in this space. Contrary to the approaches attempting transparent, uncoordinated checkpoint/restore, CRaC's approach to the date has focused on assisting with the detection of situations that would prevent a successful checkpoint, and simply refusing to checkpoint if such conditions are identified. This approach leaves it up to the application frameworks and the applications themselves to remedy the situation during development, and before attempting actual deployment (or simply accept non-CRaC startup times since a restorable checkpoint state will not be available). In the Java arena, we aim to create a generic CRaC API that would allow applications and/or application frameworks to coordinate with an arbitrary checkpoint/restore mechanism, without being tied to a specific implementation or to the operational means by which checkpointing and restoration is achieved. Such an API would allow application frameworks (e.g. Tomcat, Quarkus, MicroNaut, etc.) to perform the needed coordination in a portable way, which would not require coding that is specific to a checkpoint/restore mechanism. E.g. the same Tomcat CRaC coordination code would be able to properly coordinate with a generic Linux CRIU utility, with Docker Checkpoint & Restore, or with future OpenJDK implementations that may support checkpoint/restore functionality directly or via the use of libraries or system services. Our hope is to start a project that will focus on specifying a CRaC API, and will provide at least one CRaC-supporting checkpoint/restore OpenJDK implementation with the hope of eventual upstream inclusion in a future OpenJDK version via associated JEPs. We would potentially want to include the API in a future Java SE specification as well. In reality, we expect that more than one checkpoint/restore mechanism may be supported, as we have already identified at least two probable modes of operation that would be useful for OpenJDK: - We have prototyped [3] a JDK-driven, modified-CRIU [4] based checkpoint/restore implementation that leverages on-demand paging during startup to deliver very promising start times for e.g microservices running on Quarkus, Micronaut, and Tomcat, and reaching "full speed" condition in sub-50-msec times.[5] - We anticipate external-to-the-JDK checkpoint/restore implementations such as Docker Checkpoint & Restore [2] and potential possible support within orchestration frameworks (such as future Kubernetes versions) will drive a need for non-Java-specific means of coordinating restoration from checkpointed conditions, and that in such environments JDKs will likely wish to provide external controls (such jcmd or other APIs) that would deal with coordination, but leave the actual checkpointing and restore work to external entities. Below are short summaries of: - CRaC API concepts - What a prototype OpenJDK implementation looks like - Preliminary uses of CRaC API in some application frameworks - Some promising preliminary results What do you think? Please chime in. ? Gil. P.S. Anton Kozlov has done the vast majority of the technical work on this so far, and will be joining the discussion here. ????????????????? CRaC API, conceptually The high-level concepts of a CRaC API as we see it thus far include: - Application code (a "resource") can register its interest in coordinating with checkpoint/restore operations. - When a checkpoint operation attempt is initiated, and before a checkpoint is actually taken, all registered "resources" will be notified that a checkpoint is being attempted via e.g. a beforeCheckpoint() call. - A JDK may (and likely will) refuse to complete a checkpoint attempt if it encounters any application state that it does not know how to checkpoint or restore. E.g. a JDK may (and likely will) refuse to complete a checkpoint attempt if any file descriptors that are not private to the JDK itself are open after all registered resources have been notified about the coming checkpoint attempt. - When a restore operation occurs, all registered resources will be notified via e.g. an afterRestore() callback. - Upon being notified of a coming checkpoint, a resource is responsible for destroying any state that may prevent the capturing of a checkpoint (e.g. close any objects that it is responsible and that may keep open file descriptors), as well as for capturing whatever information it may need in order to continue successfully after a restore (e.g. the knowledge of what needs to be "opened" before a restore is complete). - A resource may cause a checkpoint attempt to fail by throwing an exception when notified. - Upon being notified that a restore has occurred, a resource is responsible for any required restoration or recreation of the state that it destroyed before the checkpoint occurred. [e.g. opening, binding, listening, and possibly selecting on server ports that were closed for the checkpoint]. Note that although restoration is not functionally required in some cases, it may still be beneficial for faster functional startup upon restoration. E.g. outbound connections in a connection pool may not have to be reconnected, as normal connection failure handling will likely deal with their re-establishment in any case. However, initiating such reconnection upon restore will likely improve functional startup time. - A resource may indicate that a restore attempt should fail by throwing an exception when notified. ????????????????? Prototype JDK implementation The prototype JDK implementation [3] implements Coordinated Checkpoint and Restore using a modified version of CRIU. A snapshot image of the JDK process created at an arbitrary point of time, the image is later used to start a copy of the process that is identical to the original one. Hotspot change highlights: - Adds a Coordinated Checkpoint and Restore implementation for Linux - the checkpoint is performed in a JVM safepoint - currently depends on being able to reuse the checkpointed process pid. [not a problem in containers] - Adds a jcmd command for initiating Checkpoint (does not yet pass error information on failure) - Enforces no java user-visible file or socket resources are allowed at the checkpoint time. Exception message indicates the problematic resource information. - Changes in PerfMemory (/tmp/hsperfdata/) to work across multiple restores - Performs GC on checkpoint and zeros unused heap memory to minimize image size JDK change highlights: - a jdk.crac API providing Checkpoint and Restore notifications - uses of the jdk.crac API within the JDK: - support in sun.nio.ch.EPollSelectorImpl to handle epoll and pipe - jar file handling by the JDK - support in java.net.PlainSocketImpl and sun.nio.ch.FileDispatcherImpl to handle internal socket used for preclose ????????????????? Preliminary uses of CRaC API in some application frameworks AKA: What modifying common application frameworks to use a proposed CRaC API successfully on a prototype OpenJDK implementation looks like. The CRaC API was used to create modified versions of Quarkus [6], Micrnoaut [7] and Tomcat [8] (used by Spring Boot in our examples). The amount of code changes required has been surprisingly small. All three frameworks successfully coordinate checkpoint and restore operations with the prototype JDK without requiring any changes to the example code that runs on the framework. It is hoped that a large majority of applications that run on such frameworks would not require any CRaC API use, and CRaC awareness will only be needed at the framework and potentially at the library levels in most cases. ????????????????? Promising Preliminary Results The current prototype has demonstrated <50msec startup times [5] for fully warmed microservice examples running on modified Spring Boot, Quarkus, and Micronaut[4]. The examples demonstrate fully-JIT'ed performance out of the box: the immediate throughout of these <50msec starts matches the throughput achieved by a normal OpenJDK start only after the latter has fully warmed up, and after it had executed >10,000 example operations at significantly slower speeds. ????????????????? References [1] https://github.com/checkpoint-restore/criu [2] https://github.com/docker/cli/blob/master/experimental/checkpoint-restore.md [3] https://github.com/org-crac/jdk/compare/jdk-base..jdk-crac [4] https://github.com/org-crac/criu/compare/v3.14..crac [5] https://github.com/org-crac/docs#results [6] https://github.com/org-crac/quarkus/compare/master..crac-master [7] https://github.com/org-crac/micronaut-core/compare/1.3.x..crac-1.3.x [8] https://github.com/org-crac/tomcat/compare/8.5.x..crac [9] https://en.wikipedia.org/wiki/Tubthumping From mdoerr at openjdk.java.net Thu Sep 10 19:59:24 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 10 Sep 2020 19:59:24 GMT Subject: RFR: 8253029: [PPC64] Remove obsolete Power6 code Message-ID: <_3Dj2yHMngMuxQKL1Q1DKdB1W1kcUawtFg6YDZSuFPM=.63336975-a03a-4e6d-9823-3c336fdc30ae@github.com> The recent PPC64 platform files still contain code which is part of a Power6 optimization called Power6Scheduler. However, this functionality was never completely contributed so it was never usable in the OpenJDK. We should remove it since we're no longer optimizing for Power6. ------------- Commit messages: - Remove obsolete Power6 code Changes: https://git.openjdk.java.net/jdk/pull/116/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=116&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253029 Stats: 916 lines in 5 files changed: 0 ins; 899 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/116.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/116/head:pull/116 PR: https://git.openjdk.java.net/jdk/pull/116 From glaubitz at physik.fu-berlin.de Thu Sep 10 20:28:46 2020 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 10 Sep 2020 22:28:46 +0200 Subject: RFR: 8253029: [PPC64] Remove obsolete Power6 code In-Reply-To: <_3Dj2yHMngMuxQKL1Q1DKdB1W1kcUawtFg6YDZSuFPM=.63336975-a03a-4e6d-9823-3c336fdc30ae@github.com> References: <_3Dj2yHMngMuxQKL1Q1DKdB1W1kcUawtFg6YDZSuFPM=.63336975-a03a-4e6d-9823-3c336fdc30ae@github.com> Message-ID: On 9/10/20 9:59 PM, Martin Doerr wrote: > The recent PPC64 platform files still contain code which is part of a Power6 optimization called Power6Scheduler. > However, this functionality was never completely contributed so it was never usable in the OpenJDK. We should remove it > since we're no longer optimizing for Power6. I love that it has German comments in the code: "// Schleife 1" ;-) Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From rrich at openjdk.java.net Thu Sep 10 21:33:04 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 10 Sep 2020 21:33:04 GMT Subject: RFR: 8227745, 8233915: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents Message-ID: Hi, this is the continuation of the review of the implementation for: https://bugs.openjdk.java.net/browse/JDK-8227745 https://bugs.openjdk.java.net/browse/JDK-8233915 It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ Thanks, Richard. ------------- Commit messages: - 8227745, 8233915: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents Changes: https://git.openjdk.java.net/jdk/pull/119/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8227745 Stats: 5390 lines in 47 files changed: 5266 ins; 23 del; 101 mod Patch: https://git.openjdk.java.net/jdk/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119 PR: https://git.openjdk.java.net/jdk/pull/119 From sjohanss at openjdk.java.net Thu Sep 10 21:49:04 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 10 Sep 2020 21:49:04 GMT Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 14:05:25 GMT, Kim Barrett wrote: >> src/hotspot/share/gc/g1/g1ParScanThreadState.cpp line 68: >> >>> 66: _old_gen_is_full(false), >>> 67: _partial_objarray_chunk_size(ParGCArrayScanChunk), >>> 68: _partial_array_stepper(n_workers), >> >> What do you think about saving the chunk size in the stepper instead? Then we don't need to pass it in to `start()` and >> `next()`. To avoid needing it for the call to `oop_iterate_range()` we could instead have the `Step` include both the >> start and end index. > > See above discussion about naming and factoring. The same stepper can support multiple array types if the chunk size > is external to the stepper. It can, but I think I would prefer multiple "steppers" for that case. This is of course just a matter of taste and I'm fine with leaving the chunk size external. >> src/hotspot/share/gc/g1/g1ParScanThreadState.hpp line 84: >> >>> 82: bool _old_gen_is_full; >>> 83: // Size (in elements) of a partial objArray task chunk. >>> 84: int _partial_objarray_chunk_size; >> >> I would prefer to skip the "obj"-part here to have more consistent naming or, as mentioned above, include it in the >> stepper instead. > > Some of the naming and factoring I've done is forward looking. > > I think we should consider splitting the copying part as well as the scanning, and chunking the copy of typeArrays. For > example, JDK-8031565 suggests copying large typeArrays as part of termination waiting; I think splitting them into > partial array tasks to use the normal parallelism in the framework is better than some new side channel. The chunk size > for that should probably be substantially larger (and depend on the element size) than for objArray. Also, Project > Valhalla is going to add new kinds of arrays that are neither objArray nor typeArray. We'll want to split them too. The > same splitting calculations can apply, even though the chunk size may be different (and probably depends on the element > klass). Ok, keeping the "obj"-part sounds reasonable. >> src/hotspot/share/gc/g1/g1ParScanThreadState.hpp line 165: >> >>> 163: private: >>> 164: inline void do_partial_array(PartialArrayScanTask task); >>> 165: inline void start_partial_objArray(G1HeapRegionAttr dest_dir, oop from, oop to); >> >> Same here, drop "obj" for consistent naming and avoiding the camel-case. > > See response above about the name of _partial_objarray_chunk_size. But I should probably be consistent about objarray > vs objArray. Since objArray is what it is over in runtime oop-land I'm going to go with that. Again, we have different taste. We very seldom go with camel-case in members and especially in the middle it looks strange. Looking through the GC-code I find mostly `objarray` or `obj_array` >> src/hotspot/share/gc/shared/partialArrayTaskStepper.cpp line 34: >> >>> 32: // that maximizes available parallelism. >>> 33: return n_workers; >>> 34: } >> >> In preparation for a more advanced logic for the limit, or why not just use the input at the call-site? > > Being noncommittal about whether something more "clever" could or should be done. ?? >> src/hotspot/share/gc/shared/partialArrayTaskStepper.hpp line 57: >> >>> 55: int _index; // Array index for the step. >>> 56: uint _ncreate; // Number of new tasks to create. >>> 57: }; >> >> I wouldn't mind having getters for those, but it's not a hard request :) > > Step is intended to be a trivial data carrier. A (HotSpot) Pair or std::pair (if we used stdlib) would do, except I > like named data items. I prefer them named as well ?? >> src/hotspot/share/gc/shared/partialArrayTaskStepper.inline.hpp line 103: >> >>> 101: uint ncreate = MIN2(_task_fannout, MIN2(remaining_tasks, _task_limit + 1) - pending); >>> 102: Step result = { start, ncreate }; >>> 103: return result; >> >> Similar to my comment above, what do you think about trying to write some test for this to verify we never get to many >> "tasks". > > The asserts in the stepper's next() after the increment of to's length verify that we haven't overrun. I haven't > thought of a way to verify the algorithm doesn't generate too few tasks though. Well, other than getting crashes > because some array elements didn't get processed. But maybe you mean unit tests? I will try to write some; I should > have done so already. Should have been a bit more clear. I'm talking about unit tests, so if you plan writing some that's great. ------------- PR: https://git.openjdk.java.net/jdk/pull/90 From jjg at openjdk.java.net Thu Sep 10 23:31:29 2020 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Thu, 10 Sep 2020 23:31:29 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 12:04:48 GMT, Dmitriy Dumanskiy wrote: > I have in mind dozens of improvements all over the code like this one. That sounds scary. Broad updates like these cause unnecessary churn in the codebase, and can make merging and back porting harder. Changes should be discussed ahead of time with the appropriate teams. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From prr at openjdk.java.net Fri Sep 11 00:00:15 2020 From: prr at openjdk.java.net (Phil Race) Date: Fri, 11 Sep 2020 00:00:15 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). 1) This is un-necessary churn. 2) I can't even be sure I am finding the ones in my area because there's so much here 3) The ones I can find have no need of whatever performance improvement this might bring. I think this whole PR should be withdrawn, and there may an attempt at measuring the benefits of this for the various cases before submitting in appropriate smaller chunks. But I'll tell you now I don't see a need for the test updates you are making. ------------- Changes requested by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/29 From ysuenaga at openjdk.java.net Fri Sep 11 00:26:07 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 11 Sep 2020 00:26:07 GMT Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> Message-ID: On Sat, 5 Sep 2020 14:26:17 GMT, Yasumasa Suenaga wrote: > If `Agent_OnAttach()` in JVMTI agent which is attempted to load via JVMTI.agent_load dcmd is failed, it would not be > unloaded. We've [discussed it on > serviceability-dev](https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-September/032839.html). This PR is > a continuation of that. This PR also includes to call `Agent_OnUnload()` when `Agent_OnAttach()` failed. > > How to reproduce: > > 1. Build JVMTI agent for test > $ git clone https://github.com/YaSuenag/jvmti-examples.git > $ cd jvmti-examples/helloworld/out/build > $ cmake ../.. > > 2. Run JShell > > 3. Load JVMTI agent via `jcmd JVMTI.agent_load` with "error" ("error" means `Agent_OnAttach()` returns JNI_ERR) > $ jcmd > 89456 jdk.jshell.execution.RemoteExecutionControl 45651 > 89547 sun.tools.jcmd.JCmd > 89436 jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider > $ jcmd 89436 JVMTI.agent_load `pwd`/libhelloworld.so error > 89436: > return code: -1 > > 4. Check loaded libraries via `jcmd VM.dynlibs` > $ jcmd 89436 VM.dynlibs | grep libhelloworld > 7f2f8b06b000-7f2f8b06c000 r--p 00000000 fd:00 11818202 > /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so 7f2f8b06c000-7f2f8b06d000 r-xp 00001000 > fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so 7f2f8b06d000-7f2f8b06e000 > r--p 00002000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so > 7f2f8b06e000-7f2f8b06f000 r--p 00002000 fd:00 11818202 > /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so 7f2f8b06f000-7f2f8b070000 rw-p 00003000 > fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so @edvbld Can you approve me to run tier1 tests with /test PR command again? ------------- PR: https://git.openjdk.java.net/jdk/pull/19 From ysuenaga at openjdk.java.net Fri Sep 11 00:26:07 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 11 Sep 2020 00:26:07 GMT Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed Message-ID: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> If `Agent_OnAttach()` in JVMTI agent which is attempted to load via JVMTI.agent_load dcmd is failed, it would not be unloaded. We've [discussed it on serviceability-dev](https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-September/032839.html). This PR is a continuation of that. This PR also includes to call `Agent_OnUnload()` when `Agent_OnAttach()` failed. How to reproduce: 1. Build JVMTI agent for test $ git clone https://github.com/YaSuenag/jvmti-examples.git $ cd jvmti-examples/helloworld/out/build $ cmake ../.. 2. Run JShell 3. Load JVMTI agent via `jcmd JVMTI.agent_load` with "error" ("error" means `Agent_OnAttach()` returns JNI_ERR) $ jcmd 89456 jdk.jshell.execution.RemoteExecutionControl 45651 89547 sun.tools.jcmd.JCmd 89436 jdk.jshell/jdk.internal.jshell.tool.JShellToolProvider $ jcmd 89436 JVMTI.agent_load `pwd`/libhelloworld.so error 89436: return code: -1 4. Check loaded libraries via `jcmd VM.dynlibs` $ jcmd 89436 VM.dynlibs | grep libhelloworld 7f2f8b06b000-7f2f8b06c000 r--p 00000000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so 7f2f8b06c000-7f2f8b06d000 r-xp 00001000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so 7f2f8b06d000-7f2f8b06e000 r--p 00002000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so 7f2f8b06e000-7f2f8b06f000 r--p 00002000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so 7f2f8b06f000-7f2f8b070000 rw-p 00003000 fd:00 11818202 /home/ysuenaga/github/jvmti-examples/helloworld/out/build/libhelloworld.so ------------- Commit messages: - JVMTI agent is not unloaded when Agent_OnAttach is failed Changes: https://git.openjdk.java.net/jdk/pull/19/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=19&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252657 Stats: 44 lines in 4 files changed: 32 ins; 6 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/19.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/19/head:pull/19 PR: https://git.openjdk.java.net/jdk/pull/19 From dholmes at openjdk.java.net Fri Sep 11 01:35:12 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 11 Sep 2020 01:35:12 GMT Subject: Integrated: 8252406: Introduce Thread::as_Java_thread() convenience function In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 05:56:14 GMT, David Holmes wrote: > This is a rather large but generally simple cleanup. > > We use a lot of raw C-style casts to "(JavaThread*)" typically after checking "thread->is_Java_thread()". To simplify > this pattern, and make the code look somewhat cleaner we introduce a convenience function Thread::as_Java_thread(), > which asserts is_Java_thread() and returns "this" cast to "JavaThread*". A const version, as_const_Java_thread(), was > also added to allow use in cases where we start with "const Thread *". Summary of changes: > - changed raw casts to use as_Java_thread() > - removed redundant checks of is_Java_thread() as it is now done in as_Java_thread() > - Removed checks that are checking the type system e.g. > void foo(JavaThread* t) { > assert(t->is_Java_thread(), "must be") > the only way the assert can fire is if someone deliberately bypasses the type system, and if we are going to worry > about that then we would need asserts like this on every method that expects a JavaThread! The right place for the > assertion is at the head of any such call chain. > - Removed asserts that are already guaranteed in the caller. > - Use JavaThread::current() where appropriate. > - Use pre-existing "thread" variable where available rather than casting THREAD > > Change locations found by grepping for variations of the cast syntax "(JavaThread*)" - it is possible some may have > been missed. > Testing: tiers 1-3 > > Thanks, > David This pull request has now been integrated. Changeset: 976acdde Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/976acdde Stats: 476 lines in 110 files changed: 116 ins; 20 del; 340 mod 8252406: Introduce Thread::as_Java_thread() convenience function Reviewed-by: shade, coleenp, kbarrett, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/37 From dholmes at openjdk.java.net Fri Sep 11 02:42:30 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 11 Sep 2020 02:42:30 GMT Subject: RFR: 8253029: [PPC64] Remove obsolete Power6 code In-Reply-To: <_3Dj2yHMngMuxQKL1Q1DKdB1W1kcUawtFg6YDZSuFPM=.63336975-a03a-4e6d-9823-3c336fdc30ae@github.com> References: <_3Dj2yHMngMuxQKL1Q1DKdB1W1kcUawtFg6YDZSuFPM=.63336975-a03a-4e6d-9823-3c336fdc30ae@github.com> Message-ID: On Thu, 10 Sep 2020 19:52:08 GMT, Martin Doerr wrote: > The recent PPC64 platform files still contain code which is part of a Power6 optimization called Power6Scheduler. > However, this functionality was never completely contributed so it was never usable in the OpenJDK. We should remove it > since we're no longer optimizing for Power6. Code changes seem fine but this will need a CSR request as the flags are product flags. The CSR request can argue for immediate obsoletion (will need to be added to flags table in arguments.cpp) or even expiry (as per current webrev). ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/116 From iklam at openjdk.java.net Fri Sep 11 04:01:52 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Sep 2020 04:01:52 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v7] In-Reply-To: References: Message-ID: > The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the > same patch as > [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/) > published in > [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html). The > rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'master' into 8243208-cleanup-jvmflag-impl - Merge branch 'master' into 8243208-cleanup-jvmflag-impl - Minor code clean up suggested by David Holmes - Feedback by Gerard (hotspot-dev/2020-September/043019.html) - Refactored JVMFlagLookup::hash_code(); Cleaned up LimitGetter::no_limit() - Fixed JVMFlag::is_writeable() - (a) coding style nits and comments, (b) updated HOWTO in globals.hpp, (c) added JVMFlag::check_all_flag_declarations(), (d) removed product_rw which is not used by any flags - 8243208: Clean up JVMFlag implementation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/82/files - new: https://git.openjdk.java.net/jdk/pull/82/files/1b63ac6f..af373e44 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=82&range=05-06 Stats: 1879 lines in 195 files changed: 584 ins; 641 del; 654 mod Patch: https://git.openjdk.java.net/jdk/pull/82.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/82/head:pull/82 PR: https://git.openjdk.java.net/jdk/pull/82 From iklam at openjdk.java.net Fri Sep 11 04:08:07 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Sep 2020 04:08:07 GMT Subject: Integrated: 8243208: Clean up JVMFlag implementation In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 18:33:41 GMT, Ioi Lam wrote: > The initial commit [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee9a92d10e1ac19d9bb2f8) is the > same patch as > [8243208-cleanup-jvmflag-impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup-jvmflag-impl.v02/) > published in > [hotspot-dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/042863.html). The > rest of the review will continue on GitHub. I will add new commits to respond to comments to the above e-mail. This pull request has now been integrated. Changeset: 5144190e Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/5144190e Stats: 2127 lines in 45 files changed: 533 ins; 755 del; 839 mod 8243208: Clean up JVMFlag implementation Reviewed-by: dholmes, coleenp, gziemski ------------- PR: https://git.openjdk.java.net/jdk/pull/82 From kbarrett at openjdk.java.net Fri Sep 11 04:52:11 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 11 Sep 2020 04:52:11 GMT Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 21:42:01 GMT, Stefan Johansson wrote: >> See response above about the name of _partial_objarray_chunk_size. But I should probably be consistent about objarray >> vs objArray. Since objArray is what it is over in runtime oop-land I'm going to go with that. > > Again, we have different taste. We very seldom go with camel-case in members and especially in the middle it looks > strange. Looking through the GC-code I find mostly `objarray` or `obj_array` You are right; in gc code, it seems "objarray" is used almost exclusively. The one exception I found seems to be around the G1CMObjArrayProcessor, where some camel-case has snuck in, such as G1ConcurrentMark::_objArray_processor. So I'll use "objarray". ------------- PR: https://git.openjdk.java.net/jdk/pull/90 From avoitylov at openjdk.java.net Fri Sep 11 07:03:37 2020 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Fri, 11 Sep 2020 07:03:37 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2] In-Reply-To: References: Message-ID: > continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html > >> The download side of using JNI in these tests is that it complicates the >> setup a bit for those that run jtreg directly and/or just build the JDK >> and not the test libraries. You could reduce this burden a bit by >> limiting the load library/isMusl check to Linux only, meaning isMusl >> would not be called on other platforms. >> >> The alternative you suggest above might indeed be better. I assume you >> don't mean splitting the tests but rather just adding a second @test >> description so that the vm.musl case runs the test with a system >> property that allows the test know the expected load library path behavior. > > I have updated the PR to split the two tests in multiple @test s. > >> The updated comment in java_md.c in this looks good. A minor comment on >> Platform.isBusybox is Files.isSymbolicLink returning true implies that >> the link exists so no need to check for exists too. Also the >> if-then-else style for the new class in ProcessBuilder/Basic.java is >> inconsistent with the rest of the test so it stands out. > > Thank you, these changes are done in the updated PR. > >> Given the repo transition this weekend then I assume you'll create a PR >> for the final review at least. Also I see JEP 386 hasn't been targeted >> yet but I assume Boris, as owner, will propose-to-target and wait for it >> to be targeted before it is integrated. > > Yes. How can this be best accomplished with the new git workflow? > - we can continue the review process till the end and I will request the integration to happen only after the JEP is > targeted. I guess this step is now done by typing "slash integrate" in a comment. > - we can pause the review process now until the JEP is targeted. > > In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here. Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: JDK-8247589: Implementation of Alpine Linux/x64 Port ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/49/files - new: https://git.openjdk.java.net/jdk/pull/49/files/f61f546a..d5994cb5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=49&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=49&range=00-01 Stats: 19 lines in 4 files changed: 7 ins; 4 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/49.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/49/head:pull/49 PR: https://git.openjdk.java.net/jdk/pull/49 From github.com+1536494+doom369 at openjdk.java.net Fri Sep 11 07:18:17 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Fri, 11 Sep 2020 07:18:17 GMT Subject: Withdrawn: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy wrote: > **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found > [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From github.com+1536494+doom369 at openjdk.java.net Fri Sep 11 07:18:17 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Fri, 11 Sep 2020 07:18:17 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 23:57:38 GMT, Phil Race wrote: >> **isEmpty** is faster + has less byte code + easier to read. Benchmarks could be found >> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416). > > 1) This is un-necessary churn. > 2) I can't even be sure I am finding the ones in my area because there's so much here > 3) The ones I can find have no need of whatever performance improvement this might bring. > I think this whole PR should be withdrawn, and there may an attempt at measuring the benefits of this for the various > cases before submitting in appropriate smaller chunks. But I'll tell you now I don't see a need for the test updates > you are making. Ok, sorry for the distraction. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From avoitylov at openjdk.java.net Fri Sep 11 07:39:47 2020 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Fri, 11 Sep 2020 07:39:47 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2] In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 23:44:58 GMT, David Holmes wrote: >> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8247589: Implementation of Alpine Linux/x64 Port > > make/autoconf/platform.m4 line 536: > >> 534: AC_SUBST(HOTSPOT_$1_CPU_DEFINE) >> 535: >> 536: if test "x$OPENJDK_$1_LIBC" = "xmusl"; then > > I'm not clear why we only check for musl when setting the HOTSPOT_$1_LIBC variable this check is removed in the updated version. As a consequence, LIBC variable is added to the release file for all platforms, which is probably a good thing. > src/hotspot/os/linux/os_linux.cpp line 624: > >> 622: // confstr() from musl libc returns EINVAL for >> 623: // _CS_GNU_LIBC_VERSION and _CS_GNU_LIBPTHREAD_VERSION >> 624: os::Linux::set_libc_version("unknown"); > > This should be "musl - unknown" as we don't know an exact version but we do know that it is musl. Right, this should be more consistent with glibc which here returns name and version. Updated as suggested. > src/hotspot/os/linux/os_linux.cpp line 625: > >> 623: // _CS_GNU_LIBC_VERSION and _CS_GNU_LIBPTHREAD_VERSION >> 624: os::Linux::set_libc_version("unknown"); >> 625: os::Linux::set_libpthread_version("unknown"); > > This should be "musl - unknown" as we don't know an exact version but we do know that it is musl. The pthread version is also updated to "musl - unknown". Reason being, pthread functionality for musl is built into the library. > src/hotspot/share/runtime/abstract_vm_version.cpp line 263: > >> 261: #define LIBC_STR "-" XSTR(LIBC) >> 262: #else >> 263: #define LIBC_STR "" > > Again I'm not clear why we do nothing in the non-musl case? Shouldn't we be reporting glibc or musl? Unlike the case above, I think it's best to keep it as is. I'd expect there to be a bunch of scripts in the wild which parse it and may get broken when facing a triplet for existing platforms. > src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c line 284: > >> 282: // To improve portability across platforms and avoid conflicts >> 283: // between GNU and XSI versions of strerror_r, plain strerror is used. >> 284: // It's safe because this code is not used in any multithreaded environment. > > I still question this assertion. The issue is not that the current code path that leads to strerror use may be executed > concurrently but that any other strerror use could be concurrent with this one. I would consider this a "must fix" if > not for the fact we already use strerror in the code and so this doesn't really change the exposure to the problem. You are right! The updated version #ifdefs the XSI or GNU versions of strerror_r in this place. Note to self: file a bug to address the usage of strerror in other places, at least for HotSpot. > test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c line 282: > >> 280: >> 281: pthread_attr_init(&thread_attr); >> 282: pthread_attr_setstacksize(&thread_attr, stack_size); > > Just a comment in response to the explanation as to why this change is needed. If the default thread stacksize under > musl is insufficient to successfully attach such a thread to the VM then this will cause problems for applications that > embed the VM directly (or which otherwise directly attach existing threads). This fix https://git.musl-libc.org/cgit/musl/commit/src/aio/aio.c?id=1a6d6f131bd60ec2a858b34100049f0c042089f2 addresses the problem for recent versions of musl. The test passes on a recent Alpine Linux 3.11.6 (musl 1.1.24) and fails on Alpine Linux 3.8.2 (musl 1.1.19) without this test fix. There are still older versions of the library in the wild, hence the test fix. The mitigation for such users would be a distro upgrade. > test/hotspot/jtreg/runtime/TLS/exestack-tls.c line 60: > >> 58: } >> 59: >> 60: #if defined(__GLIBC) > > Why do we use this form here but at line 30 we have: > #ifdef __GLIBC__ > ? Fixed to be consistent. ------------- PR: https://git.openjdk.java.net/jdk/pull/49 From kbarrett at openjdk.java.net Fri Sep 11 08:50:54 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 11 Sep 2020 08:50:54 GMT Subject: RFR: 8247910: Improve alignment and power-of-2 utilities using C++14 Message-ID: Please review this change which updates the alignment and power-of-2 utilities (utilities/align.hpp and utilities/powerOfTwo.hpp) to use C++14 features. Where possible, the alignment functions are now constexpr. This eliminates the need for alternate macros that needed to be used in constexpr contexts. Use and rather than HotSpot workalikes. We no longer need max_value(), as the problematic platform for std::numeric_limits::max() was Solaris. Testing: tier1 ------------- Commit messages: - Update alignment and power-of-2 functions for C++14 Changes: https://git.openjdk.java.net/jdk/pull/126/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=126&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247910 Stats: 291 lines in 12 files changed: 129 ins; 90 del; 72 mod Patch: https://git.openjdk.java.net/jdk/pull/126.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/126/head:pull/126 PR: https://git.openjdk.java.net/jdk/pull/126 From kbarrett at openjdk.java.net Fri Sep 11 09:01:18 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 11 Sep 2020 09:01:18 GMT Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space [v2] In-Reply-To: References: Message-ID: > This is rework of initial change from before the transition to git. > The initial RFR email is attached below. > > The primary change is to limit the number of partial array tasks in > the queues for any given array. The original change just split up an > array into N tasks that were all enqueued at once. But for a large > array this could be a lot of tasks, leading to significant and > unnecessary queue expansion. Instead we now limit the number of tasks > for a given array based on the number of workers, and only gradually > add tasks up to that limit. This gives other threads an opportunity > to steal such tasks, while still keeping queue growth under control. > > Most of the calculation for this is handled by a new helper class, so > this can later be shared with ParallelGC. > > The dispatch on array klass type for has also been changed. It now > affirmatively breaks Project Valhalla, rather than quietly doing > something that probably isn't what is actually wanted. I'll discuss > with them so there is a plan for dealing with it when they take this > update. > > Ran tier1-6 in mach5 and some local stress tests. > > Performance testing was unchanged from previous, except I wasn't able > to reproduce the small specjbb2015 critical-jops improvement > previously seen on one platform. My suspicion is that improvement was > a statistical abberation. > > --- Initial RFR email --- > > RFR: 8158045: Improve large object handling during evacuation > RFR: 8027761: Investigate fast-path for scanning only objects with references during gc > RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space > > Please review this change to type dispatching and handling in G1's > evacuation copying, in order to improve the hot paths and improve array > handling. This change addresses several closely co-located enhancement > requests; it seemed difficult to split them up in a sensible way. > > do_copy_to_survivor_space now gets the klass of the object being copied > once, up front, for use in multiple places. This avoids fetching (including > re-decoding when compressed) the klass multiple times. This addresses part > of JDK-8027545. > > Moved check for and handling of string deduplication later, only applying it > after the special array cases have been dealt with, since strings are not > arrays. (They are header objects pointing to an array of character values.) > > Special case typeArray, doing nothing other than the copy, since they > contain no oops that need to be processed. This addresses JDK-8027761. > > Changed handling of objArray, pushing all of the partial array tasks up > front, rather than processing the current chunk after pushing a single task > for the remaining work. This addresses JDK-8158045. > > As part of these, cached some more frequently accessed values in > G1ParScanThreadState member variables. This addresses part of part of > JDK-8027545. > > While both the old and new code will work for Project Valhalla, the handling > of arrays should be updated for that project, which introduces new array > types. > > Deleted a lingering reference to G1ParScanPartialArrayClosure that was > deleted long ago (JDK-8035330, JDK 9). > > CR: > https://bugs.openjdk.java.net/browse/JDK-8158045 > https://bugs.openjdk.java.net/browse/JDK-8027761 > https://bugs.openjdk.java.net/browse/JDK-8027545 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ > > Testing: > tier1-3 > > performance testing - seems to be at worst performance neutral, with a > statistically significant 3% improvement in specjbb2015 critical-jops seen > on one platform. Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: Respond to reviews by ayang and sjohanss. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/90/files - new: https://git.openjdk.java.net/jdk/pull/90/files/9397514e..1981c392 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=90&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=90&range=00-01 Stats: 152 lines in 6 files changed: 122 ins; 14 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/90.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/90/head:pull/90 PR: https://git.openjdk.java.net/jdk/pull/90 From mdoerr at openjdk.java.net Fri Sep 11 09:10:05 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 11 Sep 2020 09:10:05 GMT Subject: RFR: 8227745, 8233915: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 20:48:23 GMT, Richard Reingruber wrote: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. Hi Richard, I had reviewed an older webrev. Your newest improvements look good. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/119 From thomas.schatzl at oracle.com Fri Sep 11 09:16:33 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 11 Sep 2020 11:16:33 +0200 Subject: RFR: 8247910: Improve alignment and power-of-2 utilities using C++14 In-Reply-To: References: Message-ID: Hi, On 11.09.20 10:50, Kim Barrett wrote: > Please review this change which updates the alignment and power-of-2 > utilities (utilities/align.hpp and utilities/powerOfTwo.hpp) to use > C++14 features. > > Where possible, the alignment functions are now constexpr. This > eliminates the need for alternate macros that needed to be used in > constexpr contexts. > > Use and rather than HotSpot workalikes. > We no longer need max_value(), as the problematic platform for > std::numeric_limits::max() was Solaris. > > Testing: tier1 > in utilities/align.hpp:63: 62 constexpr T align_down(T size, A alignment) { The comment mentions "lognot" twice, at least it took me a while to understand that it is an abbreviation for "logical not". Probably it's common in LISP context?. I still think it might be worth just typing it out for easier reading. If you think it's better to keep lognot, fine with me too, I'll mark this as reviewed. Thanks, Thomas From tschatzl at openjdk.java.net Fri Sep 11 09:20:24 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 11 Sep 2020 09:20:24 GMT Subject: RFR: 8247910: Improve alignment and power-of-2 utilities using C++14 In-Reply-To: References: Message-ID: <2V_OpCWhz5NDcruyhOTYKSsETPgt4_0juLBvaugnlPI=.c470c6e1-12fc-4987-b911-dce47fba5f47@github.com> On Fri, 11 Sep 2020 08:44:49 GMT, Kim Barrett wrote: > Please review this change which updates the alignment and power-of-2 > utilities (utilities/align.hpp and utilities/powerOfTwo.hpp) to use > C++14 features. > > Where possible, the alignment functions are now constexpr. This > eliminates the need for alternate macros that needed to be used in > constexpr contexts. > > Use and rather than HotSpot workalikes. > We no longer need max_value(), as the problematic platform for > std::numeric_limits::max() was Solaris. > > Testing: tier1 Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/126 From rrich at openjdk.java.net Fri Sep 11 09:28:44 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 11 Sep 2020 09:28:44 GMT Subject: RFR: 8227745, 8233915: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 09:22:06 GMT, Richard Reingruber wrote: >> Hi Richard, >> I had reviewed an older webrev. Your newest improvements look good. > >> >> >> Hi Richard, >> I had reviewed an older webrev. Your newest improvements look good. > > Thanks Martin! > > > @reinrich This change now passes all automated pre-integration checks. In addition to the automated checks, the change > must also fulfill all [project specific requirements](https://github.com/openjdk/jdk/blob/master/CONTRIBUTING.md) > After integration, the commit message will be: > > ``` > 8227745: 8233915: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents > 8233915: JVMTI FollowReferences: Java Heap Leak not found because of C2 Scalar Replacement > > Reviewed-by: mdoerr > ``` The commit message looks odd to me. Should I remove ", 8233915" from the title of this request? I used the old scheme "JBS-Id[, JBS-Id]*" and this might be wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From kim.barrett at oracle.com Fri Sep 11 09:49:57 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 11 Sep 2020 05:49:57 -0400 Subject: RFR: 8247910: Improve alignment and power-of-2 utilities using C++14 In-Reply-To: References: Message-ID: <43A7ADA4-FBB7-42DE-84F1-C1DA3936594F@oracle.com> > On Sep 11, 2020, at 5:16 AM, Thomas Schatzl wrote: > > Hi, > > On 11.09.20 10:50, Kim Barrett wrote: >> Please review this change which updates the alignment and power-of-2 >> utilities (utilities/align.hpp and utilities/powerOfTwo.hpp) to use >> C++14 features. >> Where possible, the alignment functions are now constexpr. This >> eliminates the need for alternate macros that needed to be used in >> constexpr contexts. >> Use and rather than HotSpot workalikes. >> We no longer need max_value(), as the problematic platform for >> std::numeric_limits::max() was Solaris. >> Testing: tier1 > > in utilities/align.hpp:63: > > 62 constexpr T align_down(T size, A alignment) { > > The comment mentions "lognot" twice, at least it took me a while to understand that it is an abbreviation for "logical not". Probably it's common in LISP context?. I still think it might be worth just typing it out for easier reading. I thought that was widespread usage; I guess my roots are showing. I'll expand it to logical_not (which is the name of the corresponding C++ function object class). > If you think it's better to keep lognot, fine with me too, I'll mark this as reviewed. > > Thanks, > Thomas Thanks for reviewing. From mdoerr at openjdk.java.net Fri Sep 11 09:52:36 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 11 Sep 2020 09:52:36 GMT Subject: RFR: 8253029: [PPC64] Remove obsolete Power6 code [v2] In-Reply-To: <_3Dj2yHMngMuxQKL1Q1DKdB1W1kcUawtFg6YDZSuFPM=.63336975-a03a-4e6d-9823-3c336fdc30ae@github.com> References: <_3Dj2yHMngMuxQKL1Q1DKdB1W1kcUawtFg6YDZSuFPM=.63336975-a03a-4e6d-9823-3c336fdc30ae@github.com> Message-ID: > The recent PPC64 platform files still contain code which is part of a Power6 optimization called Power6Scheduler. > However, this functionality was never completely contributed so it was never usable in the OpenJDK. We should remove it > since we're no longer optimizing for Power6. Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: Remove obsolete Power6 code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/116/files - new: https://git.openjdk.java.net/jdk/pull/116/files/a4e2ecff..f820714a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=116&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=116&range=00-01 Stats: 207 lines in 10 files changed: 50 ins; 10 del; 147 mod Patch: https://git.openjdk.java.net/jdk/pull/116.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/116/head:pull/116 PR: https://git.openjdk.java.net/jdk/pull/116 From ehelin at openjdk.java.net Fri Sep 11 09:57:34 2020 From: ehelin at openjdk.java.net (Erik Helin) Date: Fri, 11 Sep 2020 09:57:34 GMT Subject: RFR: 8227745, 8233915: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 09:26:28 GMT, Richard Reingruber wrote: >>> >>> >>> Hi Richard, >>> I had reviewed an older webrev. Your newest improvements look good. >> >> Thanks Martin! > >> >> >> @reinrich This change now passes all automated pre-integration checks. In addition to the automated checks, the change >> must also fulfill all [project specific requirements](https://github.com/openjdk/jdk/blob/master/CONTRIBUTING.md) >> After integration, the commit message will be: >> >> ``` >> 8227745: 8233915: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents >> 8233915: JVMTI FollowReferences: Java Heap Leak not found because of C2 Scalar Replacement >> >> Reviewed-by: mdoerr >> ``` > > The commit message looks odd to me. Should I remove ", 8233915" from the title of this request? I used the old scheme > "JBS-Id[, JBS-Id]*" and this might be wrong. The commit message is correct according to [JEP 357](http://openjdk.java.net/jeps/357) ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From ehelin at openjdk.java.net Fri Sep 11 09:57:34 2020 From: ehelin at openjdk.java.net (Erik Helin) Date: Fri, 11 Sep 2020 09:57:34 GMT Subject: RFR: 8227745, 8233915: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 09:54:06 GMT, Erik Helin wrote: >>> >>> >>> @reinrich This change now passes all automated pre-integration checks. In addition to the automated checks, the change >>> must also fulfill all [project specific requirements](https://github.com/openjdk/jdk/blob/master/CONTRIBUTING.md) >>> After integration, the commit message will be: >>> >>> ``` >>> 8227745: 8233915: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents >>> 8233915: JVMTI FollowReferences: Java Heap Leak not found because of C2 Scalar Replacement >>> >>> Reviewed-by: mdoerr >>> ``` >> >> The commit message looks odd to me. Should I remove ", 8233915" from the title of this request? I used the old scheme >> "JBS-Id[, JBS-Id]*" and this might be wrong. > > The commit message is correct according to [JEP 357](http://openjdk.java.net/jeps/357) Sorry, now I see. Yes, please remove `, 8233915` from the title! ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From rrich at openjdk.java.net Fri Sep 11 09:24:49 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 11 Sep 2020 09:24:49 GMT Subject: RFR: 8227745, 8233915: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 09:07:43 GMT, Martin Doerr wrote: > > > Hi Richard, > I had reviewed an older webrev. Your newest improvements look good. Thanks Martin! ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From goetz.lindenmaier at sap.com Fri Sep 11 10:16:43 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 11 Sep 2020 10:16:43 +0000 Subject: RFR: 8227745, 8233915: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: Hi Richard, I think you can add a second bug fixed by your pull request by issueing comment /issue JDK-8233915 in the pull request. Erik, please correct me if wrong. (The change fixes/implements two JBS issues.) Best regards, Goetz. > -----Original Message----- > From: hotspot-dev On Behalf Of Erik > Helin > Sent: Friday, September 11, 2020 11:58 AM > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR: 8227745, 8233915: Enable Escape Analysis for Better > Performance in the Presence of JVMTI Agents > > On Fri, 11 Sep 2020 09:54:06 GMT, Erik Helin wrote: > > >>> > >>> > >>> @reinrich This change now passes all automated pre-integration checks. > In addition to the automated checks, the change > >>> must also fulfill all [project specific > requirements](https://github.com/openjdk/jdk/blob/master/CONTRIBUTING > .md) > >>> After integration, the commit message will be: > >>> > >>> ``` > >>> 8227745: 8233915: Enable Escape Analysis for Better Performance in the > Presence of JVMTI Agents > >>> 8233915: JVMTI FollowReferences: Java Heap Leak not found because > of C2 Scalar Replacement > >>> > >>> Reviewed-by: mdoerr > >>> ``` > >> > >> The commit message looks odd to me. Should I remove ", 8233915" from > the title of this request? I used the old scheme > >> "JBS-Id[, JBS-Id]*" and this might be wrong. > > > > The commit message is correct according to [JEP > 357](http://openjdk.java.net/jeps/357) > > Sorry, now I see. Yes, please remove `, 8233915` from the title! > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/119 From mdoerr at openjdk.java.net Fri Sep 11 10:20:30 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 11 Sep 2020 10:20:30 GMT Subject: RFR: 8253029: [PPC64] Remove obsolete Power6 code [v3] In-Reply-To: <_3Dj2yHMngMuxQKL1Q1DKdB1W1kcUawtFg6YDZSuFPM=.63336975-a03a-4e6d-9823-3c336fdc30ae@github.com> References: <_3Dj2yHMngMuxQKL1Q1DKdB1W1kcUawtFg6YDZSuFPM=.63336975-a03a-4e6d-9823-3c336fdc30ae@github.com> Message-ID: > The recent PPC64 platform files still contain code which is part of a Power6 optimization called Power6Scheduler. > However, this functionality was never completely contributed so it was never usable in the OpenJDK. We should remove it > since we're no longer optimizing for Power6. Martin Doerr has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/116/files - new: https://git.openjdk.java.net/jdk/pull/116/files/f820714a..ff21696b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=116&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=116&range=01-02 Stats: 934 lines in 5 files changed: 899 ins; 0 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/116.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/116/head:pull/116 PR: https://git.openjdk.java.net/jdk/pull/116 From mdoerr at openjdk.java.net Fri Sep 11 10:20:35 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 11 Sep 2020 10:20:35 GMT Subject: Integrated: 8253029: [PPC64] Remove obsolete Power6 code In-Reply-To: <_3Dj2yHMngMuxQKL1Q1DKdB1W1kcUawtFg6YDZSuFPM=.63336975-a03a-4e6d-9823-3c336fdc30ae@github.com> References: <_3Dj2yHMngMuxQKL1Q1DKdB1W1kcUawtFg6YDZSuFPM=.63336975-a03a-4e6d-9823-3c336fdc30ae@github.com> Message-ID: On Thu, 10 Sep 2020 19:52:08 GMT, Martin Doerr wrote: > The recent PPC64 platform files still contain code which is part of a Power6 optimization called Power6Scheduler. > However, this functionality was never completely contributed so it was never usable in the OpenJDK. We should remove it > since we're no longer optimizing for Power6. This pull request has now been integrated. Changeset: ff21696b Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/ff21696b Stats: 142 lines in 7 files changed: 6 ins; 14 del; 122 mod 8252817: Cleanup the classes in the java.awt.color package Reviewed-by: jdv, pbansal ------------- PR: https://git.openjdk.java.net/jdk/pull/116 From github.com+70893615+jasontatton-aws at openjdk.java.net Fri Sep 11 10:23:31 2020 From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton) Date: Fri, 11 Sep 2020 10:23:31 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) Message-ID: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as code for C2. Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and java/lang/StringLatin1.java https://bugs.openjdk.java.net/browse/JDK-8173585 Details of testing: ============ I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the input String. Hence the test has been designed to cover all these cases. In summary they are: - A ?short? string of < 16 characters. - A SIMD String of 16 ? 31 characters. - A AVX2 SIMD String of 32 characters+. Hardware used for testing: ----------------------------- - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support). - AWS Graviton 2 (ARM 64 processor). I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64. Possible future enhancements: ==================== For the x86 implementation there may be two further improvements we can make in order to improve performance of both the StringUTF16 and StringLatin1 indexOf(char) intrinsics: 1. Make use of AVX-512 instructions. 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD instructions instead of a loop. Benchmark results: ============ **Without** the new StringLatin1 indexOf(char) intrinsic: | Benchmark | Mode | Cnt | Score | Error | Units | | ------------- | ------------- |------------- |------------- |------------- |------------- | | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op | | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933 | ns/op | **With** the new StringLatin1 indexOf(char) intrinsic: | Benchmark | Mode | Cnt | Score | Error | Units | | ------------- | ------------- |------------- |------------- |------------- |------------- | | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716 | ns/op | | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306 | ns/op | The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when running on ARM. ------------- Commit messages: - 8173585: further whitespace changes required by jcheck - JDK-8173585 - whitespace changes required by jcheck - JDK-8173585 Changes: https://git.openjdk.java.net/jdk/pull/71/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=71&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8173585 Stats: 522 lines in 15 files changed: 506 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/71.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/71/head:pull/71 PR: https://git.openjdk.java.net/jdk/pull/71 From mdoerr at openjdk.java.net Fri Sep 11 10:28:43 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 11 Sep 2020 10:28:43 GMT Subject: RFR: 8253029: [PPC64] Remove obsolete Power6 code [v3] In-Reply-To: References: <_3Dj2yHMngMuxQKL1Q1DKdB1W1kcUawtFg6YDZSuFPM=.63336975-a03a-4e6d-9823-3c336fdc30ae@github.com> Message-ID: On Fri, 11 Sep 2020 02:39:45 GMT, David Holmes wrote: >> Martin Doerr has refreshed the contents of this pull request, and previous commits have been removed. The incremental >> views will show differences compared to the previous content of the PR. > > Code changes seem fine but this will need a CSR request as the flags are product flags. The CSR request can argue for > immediate obsoletion (will need to be added to flags table in arguments.cpp) or even expiry (as per current webrev). Sorry, folks, I had to create a new PR because I had forgotten to create a branch. CSR is created. New PR contains Copyright update. ------------- PR: https://git.openjdk.java.net/jdk/pull/116 From mdoerr at openjdk.java.net Fri Sep 11 10:29:05 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 11 Sep 2020 10:29:05 GMT Subject: RFR: 8253029: Remove obsolete Power6 code Message-ID: New pull request: Using a branch, updated Copyright, removed some more unused code. [Previous text] The recent PPC64 platform files still contain code which is part of a Power6 optimization called Power6Scheduler. However, this functionality was never completely contributed so it was never usable in the OpenJDK. We should remove it since we're no longer optimizing for Power6. ------------- Commit messages: - Remove obsolete Power6 code Changes: https://git.openjdk.java.net/jdk/pull/127/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=127&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253029 Stats: 936 lines in 5 files changed: 0 ins; 899 del; 37 mod Patch: https://git.openjdk.java.net/jdk/pull/127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/127/head:pull/127 PR: https://git.openjdk.java.net/jdk/pull/127 From github.com+4676506+javeleon at openjdk.java.net Fri Sep 11 10:39:02 2020 From: github.com+4676506+javeleon at openjdk.java.net (Allan Gregersen) Date: Fri, 11 Sep 2020 10:39:02 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread Message-ID: The idea is to add a more powerful API for cases where the current iterateFrames API cannot be used. For example, a debugger needs access to the content of stack frames such as local variables or monitors. In cases where threads execute in the runtime or in native code, it's not possible to obtain a thread suspension hook, for which iterateFrames can be used on the suspended thread. The getStackFrames method enables an immediate stack frames lookup regardless of the status of the underlying thread. Another use case would be for lookup of backtraces for non-current threads. The implementation is done by means of a VM operation that collects vframe data for each thread during a safepoint, whereafter required object reallocation/reassign fields is performed based on the collected snapshot. ------------- Commit messages: - Implement new getStackFrames API for fetching stack frames from a set of threads at once Changes: https://git.openjdk.java.net/jdk/pull/110/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=110&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253001 Stats: 2572 lines in 17 files changed: 2316 ins; 63 del; 193 mod Patch: https://git.openjdk.java.net/jdk/pull/110.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/110/head:pull/110 PR: https://git.openjdk.java.net/jdk/pull/110 From sjohanss at openjdk.java.net Fri Sep 11 10:47:14 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 11 Sep 2020 10:47:14 GMT Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space [v2] In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 09:01:18 GMT, Kim Barrett wrote: >> This is rework of initial change from before the transition to git. >> The initial RFR email is attached below. >> >> The primary change is to limit the number of partial array tasks in >> the queues for any given array. The original change just split up an >> array into N tasks that were all enqueued at once. But for a large >> array this could be a lot of tasks, leading to significant and >> unnecessary queue expansion. Instead we now limit the number of tasks >> for a given array based on the number of workers, and only gradually >> add tasks up to that limit. This gives other threads an opportunity >> to steal such tasks, while still keeping queue growth under control. >> >> Most of the calculation for this is handled by a new helper class, so >> this can later be shared with ParallelGC. >> >> The dispatch on array klass type for has also been changed. It now >> affirmatively breaks Project Valhalla, rather than quietly doing >> something that probably isn't what is actually wanted. I'll discuss >> with them so there is a plan for dealing with it when they take this >> update. >> >> Ran tier1-6 in mach5 and some local stress tests. >> >> Performance testing was unchanged from previous, except I wasn't able >> to reproduce the small specjbb2015 critical-jops improvement >> previously seen on one platform. My suspicion is that improvement was >> a statistical abberation. >> >> --- Initial RFR email --- >> >> RFR: 8158045: Improve large object handling during evacuation >> RFR: 8027761: Investigate fast-path for scanning only objects with references during gc >> RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space >> >> Please review this change to type dispatching and handling in G1's >> evacuation copying, in order to improve the hot paths and improve array >> handling. This change addresses several closely co-located enhancement >> requests; it seemed difficult to split them up in a sensible way. >> >> do_copy_to_survivor_space now gets the klass of the object being copied >> once, up front, for use in multiple places. This avoids fetching (including >> re-decoding when compressed) the klass multiple times. This addresses part >> of JDK-8027545. >> >> Moved check for and handling of string deduplication later, only applying it >> after the special array cases have been dealt with, since strings are not >> arrays. (They are header objects pointing to an array of character values.) >> >> Special case typeArray, doing nothing other than the copy, since they >> contain no oops that need to be processed. This addresses JDK-8027761. >> >> Changed handling of objArray, pushing all of the partial array tasks up >> front, rather than processing the current chunk after pushing a single task >> for the remaining work. This addresses JDK-8158045. >> >> As part of these, cached some more frequently accessed values in >> G1ParScanThreadState member variables. This addresses part of part of >> JDK-8027545. >> >> While both the old and new code will work for Project Valhalla, the handling >> of arrays should be updated for that project, which introduces new array >> types. >> >> Deleted a lingering reference to G1ParScanPartialArrayClosure that was >> deleted long ago (JDK-8035330, JDK 9). >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8158045 >> https://bugs.openjdk.java.net/browse/JDK-8027761 >> https://bugs.openjdk.java.net/browse/JDK-8027545 >> >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ >> >> Testing: >> tier1-3 >> >> performance testing - seems to be at worst performance neutral, with a >> statistically significant 3% improvement in specjbb2015 critical-jops seen >> on one platform. > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > Respond to reviews by ayang and sjohanss. Nice test and thanks for going with "objarray". Looks good and I'll approve this now, but please fix the indent issue in the test before integrating. test/hotspot/gtest/gc/shared/test_partialArrayTaskStepper.cpp line 55: > 53: int length, > 54: int* to_length_addr, > 55: uint chunk_size) { Indent looks to be one-off here. ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/90 From akozlov at azul.com Fri Sep 11 11:12:52 2020 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 11 Sep 2020 14:12:52 +0300 Subject: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: <3834f328-d31f-0111-6ed3-afbe3fe3d9f7@redhat.com> <72a22b1b-2670-014d-8964-d08b0158fa46@azul.com> Message-ID: The cleanup in cpu/aarch64/vm_version may be considered as a work in general or a work toward landing patches, depends on the terminology :) Since we've are on par in understanding, I've created JDK-8253015 and drafted a patch[1] consisting mostly of what we have discussed. Would it be OK if I make a formal review request (now PR) for integration? I mean, it will create some burden for you if you have made steps in this direction as well. After the patch the common and linux code do not use code generation. But it is still possible in os-specific code, like [2]. It returns memory to the code cache, but as far as I can see the block ends up in a free-list, creating small fragmentation. So I would stick to a static code if possible or would use a buffer on a stack if it has execute permission. I hope changes for windows-aarch64 on top of [1] will be straightforward. But unfortunately, I don't have a setup to test that. So I hope to get your review, now or after the possible PR. Thanks, Anton [1] https://github.com/openjdk/jdk/compare/master..AntonKozlov:8253015#diff-914c0b9083f9d7ee2d08f5dbd3c54ebe [2] https://github.com/AntonKozlov/jdk/compare/8253015..8253015-codegen On 08.09.2020 22:09, Ludovic Henry wrote: > Hi Anton, > > You can find the diff at https://gist.github.com/luhenry/d981f5fe7e9f1a1ad8cd3292b5e75cc4 (we are in the process of upstreaming it). > >> 1. The linux part of feature detection should probably go to os_cpu/xxx/vm_version_xxx.cpp. > > It probably should indeed. I'd do the work for the macOS-AArch64 port, and I would adapt the windows-AArch64 port whichever lands first. > >> 2. CPU features detection stub [1] for some reason takes 550 bytes (and is allocated permanently in the code cache), constructs a frame, and probably can be replaced with just inline assembly at least for Linux. > > I agree, especially since `ctr_el0` is not even accessible on Windows. I'm happy to go for inline assembly or a dedicated assembly file. We need to keep it in `os_cpu` (especially for inline assembly) as it will need to be different for Windows at least (even for macOS, since the compiler is different and some platform specifics quirks). > >> 3. dcpop feature is taken from /proc/cpuinfo[2], although it is also there in HWCAP[3]. > > There is no equivalent of /proc/cpuinfo on Windows, and we can only rely on `IsProcessorFeaturePresent`. I would make sure to keep that check in `os_cpu` for the same reason as above. > >> 4. I'm a bit concerned about Feature_Flags[4] implicitly mirrors of Linux HWCAP. I think some code (e.g assert) should provide a hint about mapping. For example, HWCAP_ATOMIC implicitly mapped to CPU_LSE. As a note, Feature_Flags had also leaked into Graal, which should also be considered. > > In the case of Feature_Falgs, I would not implicitly define Feature_Flags with HWCAP_*, so I would make sure that `_features` is not simply assigned with the result of `getauxval`. I would also do the mapping HWCAP -> Feature_Flags in the Linux-AArch64 specific code, so that HWCAP doesn't have to leak into the Windows or macOS codebase. > >> I'm asking to avoid duplicating efforts. If you have done some significant work for vm_version that you're not ready to share yet, then OK, there is no rush. Otherwise, I can try to do something with these and anything else that may jump out after some work. In that case, the success criteria will be a better separation of common and Linux code, which should also simplify the Windows-aarch64 patch. > > All our Windows-AArch64 changes have been made public (through upstreaming it directly to jdk/jdk or by publishing webrevs), and we have no major work in progress, other than getting the current patches to land. > > I would be very happy to follow along what you're doing on a public repository, and contribute whatever we can. As we discussed offline last week, we are working on our end to publish what we have so far. > > Thank you, > Ludovic > From jzhu at openjdk.java.net Fri Sep 11 12:29:42 2020 From: jzhu at openjdk.java.net (Joshua Zhu) Date: Fri, 11 Sep 2020 12:29:42 GMT Subject: RFR: 8253048: AArch64: When CallLeaf, no need to preserve callee-saved registers in caller Message-ID: <9K43aYMMk0zdBfxGBwRA336lvjqGZyLFtZcQKVWLOec=.4a194ce2-db80-4dcc-9ef2-ed2a0d2cd088@github.com> 8253048: AArch64: When CallLeaf, no need to preserve callee-saved registers in caller ------------- Commit messages: - 8253048: AArch64: When CallLeaf, no need to preserve callee-saved registers in caller Changes: https://git.openjdk.java.net/jdk/pull/129/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=129&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253048 Stats: 22 lines in 2 files changed: 0 ins; 0 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/129.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/129/head:pull/129 PR: https://git.openjdk.java.net/jdk/pull/129 From thomas.schatzl at oracle.com Fri Sep 11 12:50:56 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 11 Sep 2020 14:50:56 +0200 Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space [v2] In-Reply-To: References: Message-ID: Hi, On 11.09.20 11:01, Kim Barrett wrote: [...] > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > Respond to reviews by ayang and sjohanss. > > Changes: > - all: https://git.openjdk.java.net/jdk/pull/90/files > - new: https://git.openjdk.java.net/jdk/pull/90/files/9397514e..1981c392 > > Webrevs: > - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=90&range=01 > - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=90&range=00-01 > > Stats: 152 lines in 6 files changed: 122 ins; 14 del; 16 mod > Patch: https://git.openjdk.java.net/jdk/pull/90.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/90/head:pull/90 > > PR: https://git.openjdk.java.net/jdk/pull/90 > - partialArrayTaskStepper.hpp: s/_task_fannout/_task_fanout (or maybe _task_fan_out) - since _task_fannout and _task_limit are only assigned in the constructor of PartialArrayTaskStepper, maybe make them const? - also the asserts in PartialArrayTaskStepper::next_impl could be moved to the constructor initialization list but otoh the fannout > 0 assert does make the calculation below immediately obviously safe. Looks good otherwise. Thanks, Thomas From rrich at openjdk.java.net Fri Sep 11 12:51:29 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 11 Sep 2020 12:51:29 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: <5gn4kpaWm8gsnaLTyRdt5Dctl01I210lRJRpaFFhpP0=.ea91bc22-588f-4d7f-a271-4bcbb88129d5@github.com> On Fri, 11 Sep 2020 09:54:50 GMT, Erik Helin wrote: > > > Sorry, now I see. Yes, please remove `, 8233915` from the title! Thanks for helping. The commit message does look better now. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From wetmore at openjdk.java.net Fri Sep 11 15:20:36 2020 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 11 Sep 2020 15:20:36 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 07:15:26 GMT, Dmitriy Dumanskiy wrote: >> 1) This is un-necessary churn. >> 2) I can't even be sure I am finding the ones in my area because there's so much here >> 3) The ones I can find have no need of whatever performance improvement this might bring. >> I think this whole PR should be withdrawn, and there may an attempt at measuring the benefits of this for the various >> cases before submitting in appropriate smaller chunks. But I'll tell you now I don't see a need for the test updates >> you are making. > > Ok, sorry for the distraction. Our local Santuario maintainer says: In general, changes to Apache Santuario should also be made at Apache so we stay in sync. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From aph at redhat.com Fri Sep 11 15:35:35 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Sep 2020 16:35:35 +0100 Subject: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: <3834f328-d31f-0111-6ed3-afbe3fe3d9f7@redhat.com> <72a22b1b-2670-014d-8964-d08b0158fa46@azul.com> Message-ID: On 11/09/2020 12:12, Anton Kozlov wrote: > Since we've are on par in understanding, I've created JDK-8253015 and drafted a > patch[1] consisting mostly of what we have discussed. Would it be OK if I make > a formal review request (now PR) for integration? I mean, it will create some > burden for you if you have made steps in this direction as well. What is the Matcher::stack_direction() code in this patch for? > [1] https://github.com/openjdk/jdk/compare/master..AntonKozlov:8253015#diff-914c0b9083f9d7ee2d08f5dbd3c54ebe > [2] https://github.com/AntonKozlov/jdk/compare/8253015..8253015-codegen -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Sep 11 15:44:01 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Sep 2020 16:44:01 +0100 Subject: RFR: 8253048: AArch64: When CallLeaf, no need to preserve callee-saved registers in caller In-Reply-To: <9K43aYMMk0zdBfxGBwRA336lvjqGZyLFtZcQKVWLOec=.4a194ce2-db80-4dcc-9ef2-ed2a0d2cd088@github.com> References: <9K43aYMMk0zdBfxGBwRA336lvjqGZyLFtZcQKVWLOec=.4a194ce2-db80-4dcc-9ef2-ed2a0d2cd088@github.com> Message-ID: <6f6717b1-1d91-657b-d28c-ecbb4b7bb33a@redhat.com> On 11/09/2020 13:29, Joshua Zhu wrote: > 8253048: AArch64: When CallLeaf, no need to preserve callee-saved registers in caller > > ------------- > > Commit messages: > - 8253048: AArch64: When CallLeaf, no need to preserve callee-saved registers in caller > > Changes: https://git.openjdk.java.net/jdk/pull/129/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=129&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8253048 > Stats: 22 lines in 2 files changed: 0 ins; 0 del; 22 mod > Patch: https://git.openjdk.java.net/jdk/pull/129.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/129/head:pull/129 > > PR: https://git.openjdk.java.net/jdk/pull/129 That looks right. I take it that you've checked everywhere else for misuse of callee-saved vector registers. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From akozlov at azul.com Fri Sep 11 15:44:28 2020 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 11 Sep 2020 18:44:28 +0300 Subject: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: <3834f328-d31f-0111-6ed3-afbe3fe3d9f7@redhat.com> <72a22b1b-2670-014d-8964-d08b0158fa46@azul.com> Message-ID: <2d74e89c-ae37-6862-b898-6872e56828cc@azul.com> On 11.09.2020 18:35, Andrew Haley wrote: > On 11/09/2020 12:12, Anton Kozlov wrote: >> Since we've are on par in understanding, I've created JDK-8253015 and drafted a >> patch[1] consisting mostly of what we have discussed. Would it be OK if I make >> a formal review request (now PR) for integration? I mean, it will create some >> burden for you if you have made steps in this direction as well. > > What is the Matcher::stack_direction() code in this patch for? Sorry, wrong urls. Correct ones: [1] https://github.com/openjdk/jdk/compare/master...AntonKozlov:8253015 [2] https://github.com/AntonKozlov/jdk/compare/8253015...8253015-codegen ".." generates a plain diff (that was correct at the moment of writing, but after that master have updated). "..." is changes on my branch only. I'll send a proper RFR (PR) once Ludovic or Bernhard confirm I'll not wreck their work. Thanks, Anton From aph at redhat.com Fri Sep 11 15:59:00 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Sep 2020 16:59:00 +0100 Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> Message-ID: <531cacb8-ae5e-0b4c-3a98-7ff8f2b7a054@redhat.com> On 11/09/2020 11:23, Jason Tatton wrote: > For the x86 implementation there may be two further improvements we > can make in order to improve performance of both the StringUTF16 and > StringLatin1 indexOf(char) intrinsics: > > 1. Make use of AVX-512 instructions. Is this really a good idea? When the processor detects Intel AVX instructions, additional voltage is applied to the core. With the additional voltage applied, the processor could run hotter, requiring the operating frequency to be reduced to maintain operations within the TDP limits. The higher voltage is maintained for 1 millisecond after the last Intel AVX instruction completes, and then the voltage returns to the nominal TDP voltage level. https://computing.llnl.gov/tutorials/linux_clusters/intelAVXperformanceWhitePaper.pdf So, if StringLatin1.indexOf(char) executes enough to make a difference to any real-world program, the effect may well be to slow down the clock for all of the code that does not use AVX. > 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD > instructions instead of a loop. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From iignatyev at openjdk.java.net Fri Sep 11 16:39:58 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 11 Sep 2020 16:39:58 GMT Subject: RFR: 8253060: remove test/hotspot/jtreg/test_env.sh Message-ID: [JDK-8252402](https://bugs.openjdk.java.net/browse/JDK-8252402) removed the last shell test from `test/hotspot/jtreg`, and now `test_env.sh` can be removed so it won't trick anyone into believing that shell tests are acceptable/desirable/supported in hotspot testbase. ------------- Commit messages: - 8253060: remove test/hotspot/jtreg/test_env.sh Changes: https://git.openjdk.java.net/jdk/pull/132/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=132&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253060 Stats: 212 lines in 1 file changed: 0 ins; 212 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/132.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/132/head:pull/132 PR: https://git.openjdk.java.net/jdk/pull/132 From dcubed at openjdk.java.net Fri Sep 11 16:58:22 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 11 Sep 2020 16:58:22 GMT Subject: RFR: 8253060: remove test/hotspot/jtreg/test_env.sh In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 16:32:04 GMT, Igor Ignatyev wrote: > [JDK-8252402](https://bugs.openjdk.java.net/browse/JDK-8252402) removed the last shell test from `test/hotspot/jtreg`, > and now `test_env.sh` can be removed so it won't trick anyone into believing that shell tests are > acceptable/desirable/supported in hotspot testbase. Simple file removal so this is a trivial change. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/132 From richard.reingruber at sap.com Fri Sep 11 17:14:14 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Fri, 11 Sep 2020 17:14:14 +0000 Subject: RFR: 8227745, 8233915: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: Hi G?tz, > I think you can add a second bug fixed by your pull request by > issueing comment > /issue JDK-8233915 > in the pull request. Yes, I did that before. And the PR reflects it correctly. I wasn't sure if I should mention the second bug id in the PR title. Turns out that the title is supposed to have exactly one bug id. Cheers, Richard. PS: I'll take notice sooner if you add me in the recipients list :) -----Original Message----- From: hotspot-dev On Behalf Of Lindenmaier, Goetz Sent: Freitag, 11. September 2020 12:17 To: 'Erik Helin' ; hotspot-dev at openjdk.java.net Subject: [CAUTION] RE: RFR: 8227745, 8233915: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents Hi Richard, I think you can add a second bug fixed by your pull request by issueing comment /issue JDK-8233915 in the pull request. Erik, please correct me if wrong. (The change fixes/implements two JBS issues.) Best regards, Goetz. > -----Original Message----- > From: hotspot-dev On Behalf Of Erik > Helin > Sent: Friday, September 11, 2020 11:58 AM > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR: 8227745, 8233915: Enable Escape Analysis for Better > Performance in the Presence of JVMTI Agents > > On Fri, 11 Sep 2020 09:54:06 GMT, Erik Helin wrote: > > >>> > >>> > >>> @reinrich This change now passes all automated pre-integration checks. > In addition to the automated checks, the change > >>> must also fulfill all [project specific > requirements](https://github.com/openjdk/jdk/blob/master/CONTRIBUTING > .md) > >>> After integration, the commit message will be: > >>> > >>> ``` > >>> 8227745: 8233915: Enable Escape Analysis for Better Performance in the > Presence of JVMTI Agents > >>> 8233915: JVMTI FollowReferences: Java Heap Leak not found because > of C2 Scalar Replacement > >>> > >>> Reviewed-by: mdoerr > >>> ``` > >> > >> The commit message looks odd to me. Should I remove ", 8233915" from > the title of this request? I used the old scheme > >> "JBS-Id[, JBS-Id]*" and this might be wrong. > > > > The commit message is correct according to [JEP > 357](http://openjdk.java.net/jeps/357) > > Sorry, now I see. Yes, please remove `, 8233915` from the title! > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/119 From iignatyev at openjdk.java.net Fri Sep 11 17:25:32 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 11 Sep 2020 17:25:32 GMT Subject: RFR: 8253060: remove test/hotspot/jtreg/test_env.sh In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 16:56:05 GMT, Daniel D. Daugherty wrote: >> [JDK-8252402](https://bugs.openjdk.java.net/browse/JDK-8252402) removed the last shell test from `test/hotspot/jtreg`, >> and now `test_env.sh` can be removed so it won't trick anyone into believing that shell tests are >> acceptable/desirable/supported in hotspot testbase. > > Simple file removal so this is a trivial change. Thanks, Dan! ------------- PR: https://git.openjdk.java.net/jdk/pull/132 From iignatyev at openjdk.java.net Fri Sep 11 17:25:35 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 11 Sep 2020 17:25:35 GMT Subject: Integrated: 8253060: remove test/hotspot/jtreg/test_env.sh In-Reply-To: References: Message-ID: <9L2_HP6Jj6drdMvvnmz5ZDXFRUw3O8W0Fx05EyONDlI=.9581dc82-18f5-4329-a113-ee636738779d@github.com> On Fri, 11 Sep 2020 16:32:04 GMT, Igor Ignatyev wrote: > [JDK-8252402](https://bugs.openjdk.java.net/browse/JDK-8252402) removed the last shell test from `test/hotspot/jtreg`, > and now `test_env.sh` can be removed so it won't trick anyone into believing that shell tests are > acceptable/desirable/supported in hotspot testbase. This pull request has now been integrated. Changeset: 5c0d985a Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk/commit/5c0d985a Stats: 212 lines in 1 file changed: 212 ins; 0 del; 0 mod 8253060: remove test/hotspot/jtreg/test_env.sh Reviewed-by: dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/132 From kvn at openjdk.java.net Fri Sep 11 21:57:54 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 11 Sep 2020 21:57:54 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> <9vXfRW4SRrizofvC6H9WecRjoXNNMwvscj7I5nlfj1Q=.c3760baf-604b-4a61-ae24-59500edca721@github.com> Message-ID: On Fri, 11 Sep 2020 21:53:12 GMT, Vladimir Kozlov wrote: >> Marked as reviewed by psandoz (Reviewer). > > You should consider upstreaming Graal changes (jdk.internal.vm.compiler) into https://github.com/oracle/graal > Otherwise next time we do "Update Graal" in JDK they will be overwritten. Changes look good. I ran hs-tier1 and hs-tier3 test jobs which run Graal tests and they passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From kvn at openjdk.java.net Fri Sep 11 21:57:54 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 11 Sep 2020 21:57:54 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: <9vXfRW4SRrizofvC6H9WecRjoXNNMwvscj7I5nlfj1Q=.c3760baf-604b-4a61-ae24-59500edca721@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> <9vXfRW4SRrizofvC6H9WecRjoXNNMwvscj7I5nlfj1Q=.c3760baf-604b-4a61-ae24-59500edca721@github.com> Message-ID: On Thu, 10 Sep 2020 17:59:54 GMT, Paul Sandoz wrote: >> Philippe Marschall has refreshed the contents of this pull request, and previous commits have been removed. The >> incremental views will show differences compared to the previous content of the PR. > > Marked as reviewed by psandoz (Reviewer). You should consider upstreaming Graal changes (jdk.internal.vm.compiler) into https://github.com/oracle/graal Otherwise next time we do "Update Graal" in JDK they will be overwritten. ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From jptatton at amazon.com Fri Sep 11 22:44:39 2020 From: jptatton at amazon.com (Tatton, Jason) Date: Fri, 11 Sep 2020 22:44:39 +0000 Subject: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> Message-ID: Hi Everyone, Please could some reviewers volunteer their time to have a look at this patch? It was marked as a starter bug so I don't expect it will consume a lot of time. Thanks, Jason -----Original Message----- From: hotspot-dev On Behalf Of Jason Tatton Sent: 11 September 2020 11:24 To: core-libs-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as code for C2. Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and java/lang/StringLatin1.java https://bugs.openjdk.java.net/browse/JDK-8173585 Details of testing: ============ I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the input String. Hence the test has been designed to cover all these cases. In summary they are: - A ?short? string of < 16 characters. - A SIMD String of 16 ? 31 characters. - A AVX2 SIMD String of 32 characters+. Hardware used for testing: ----------------------------- - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support). - AWS Graviton 2 (ARM 64 processor). I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64. Possible future enhancements: ==================== For the x86 implementation there may be two further improvements we can make in order to improve performance of both the StringUTF16 and StringLatin1 indexOf(char) intrinsics: 1. Make use of AVX-512 instructions. 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD instructions instead of a loop. Benchmark results: ============ **Without** the new StringLatin1 indexOf(char) intrinsic: | Benchmark | Mode | Cnt | Score | Error | Units | | ------------- | ------------- |------------- |------------- | |------------- |------------- | IndexOfBenchmark.latin1_mixed_char | | avgt | 5 | **26,389.129** | ? 182.581 | ns/op | | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933 | | ns/op | **With** the new StringLatin1 indexOf(char) intrinsic: | Benchmark | Mode | Cnt | Score | Error | Units | | ------------- | ------------- |------------- |------------- | |------------- |------------- | IndexOfBenchmark.latin1_mixed_char | | avgt | 5 | **17,875.185** | ? 407.716 | ns/op | | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306 | | ns/op | The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when running on ARM. ------------- Commit messages: - 8173585: further whitespace changes required by jcheck - JDK-8173585 - whitespace changes required by jcheck - JDK-8173585 Changes: https://git.openjdk.java.net/jdk/pull/71/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=71&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8173585 Stats: 522 lines in 15 files changed: 506 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/71.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/71/head:pull/71 PR: https://git.openjdk.java.net/jdk/pull/71 From github.com+70893615+jasontatton-aws at openjdk.java.net Fri Sep 11 23:06:42 2020 From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton) Date: Fri, 11 Sep 2020 23:06:42 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> Message-ID: On Tue, 8 Sep 2020 11:59:36 GMT, Jason Tatton wrote: > This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for > x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it > I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as > code for C2. Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and > java/lang/StringLatin1.java https://bugs.openjdk.java.net/browse/JDK-8173585 > > Details of testing: > ============ > I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note > that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the > input String. Hence the test has been designed to cover all these cases. In summary they are: > - A ?short? string of < 16 characters. > - A SIMD String of 16 ? 31 characters. > - A AVX2 SIMD String of 32 characters+. > > Hardware used for testing: > ----------------------------- > > - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support). > - AWS Graviton 2 (ARM 64 processor). > > I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64. > > Possible future enhancements: > ==================== > For the x86 implementation there may be two further improvements we can make in order to improve performance of both > the StringUTF16 and StringLatin1 indexOf(char) intrinsics: > 1. Make use of AVX-512 instructions. > 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD > instructions instead of a loop. > Benchmark results: > ============ > **Without** the new StringLatin1 indexOf(char) intrinsic: > > | Benchmark | Mode | Cnt | Score | Error | Units | > | ------------- | ------------- |------------- |------------- |------------- |------------- | > | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op | > | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933 | ns/op | > > > **With** the new StringLatin1 indexOf(char) intrinsic: > > | Benchmark | Mode | Cnt | Score | Error | Units | > | ------------- | ------------- |------------- |------------- |------------- |------------- | > | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716 | ns/op | > | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306 | ns/op | > > > The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 > indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when > running on ARM. Hi Andrew, The current indexOf char intrinsics for StringUTF16 and the new one here for StringLatin1 both use the AVX2 ? i.e. 256 bit instructions, these are also affected by the frequency scaling which affects the AVX-512 instructions you pointed out. Of course in a world where all the work taking place is AVX instructions this wouldn?t be an issue but in mixed mode execution this is a problem. However, the compiler does have knowledge of the capability of the CPU upon which it?s optimizing code for and is able to decide whether to use AVX instructions if they are supported by the CPU AND if it wouldn?t be detrimental for performance. In fact, there is a flag which one can use to interact with this: -XX:UseAVX=version. This of course made testing this patch an interesting experience as the AVX2 instructions were not enabled on the Xeon processors which I had access to at AWS, but in the end I was able to use an i7 on my corporate macbook to validate the code. From: mlbridge[bot] Sent: 11 September 2020 17:01 To: openjdk/jdk Cc: Tatton, Jason ; Mention Subject: Re: [openjdk/jdk] 8173585: Intrinsify StringLatin1.indexOf(char) (#71) Mailing list message from Andrew Haley on hotspot-dev: On 11/09/2020 11:23, Jason Tatton wrote: For the x86 implementation there may be two further improvements we can make in order to improve performance of both the StringUTF16 and StringLatin1 indexOf(char) intrinsics: 1. Make use of AVX-512 instructions. Is this really a good idea? When the processor detects Intel AVX instructions, additional voltage is applied to the core. With the additional voltage applied, the processor could run hotter, requiring the operating frequency to be reduced to maintain operations within the TDP limits. The higher voltage is maintained for 1 millisecond after the last Intel AVX instruction completes, and then the voltage returns to the nominal TDP voltage level. https://computing.llnl.gov/tutorials/linux_clusters/intelAVXperformanceWhitePaper.pdf So, if StringLatin1.indexOf(char) executes enough to make a difference to any real-world program, the effect may well be to slow down the clock for all of the code that does not use AVX. 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD instructions instead of a loop. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 ? You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. ------------- PR: https://git.openjdk.java.net/jdk/pull/71 From kvn at openjdk.java.net Sat Sep 12 00:21:29 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Sat, 12 Sep 2020 00:21:29 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Wed, 9 Sep 2020 09:49:44 GMT, Philippe Marschall wrote: >> Hello, newbie here >> >> I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. >> >> - I tried to update the copyright year to 2020 in every file. >> - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. >> - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of >> imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. >> - All tier1 tests pass. >> - One jpackage/jlink tier2 test fails but I don't believe it is related. >> - Some tier3 Swing tests fail but I don't think they are related. > > Philippe Marschall has refreshed the contents of this pull request, and previous commits have been removed. The > incremental views will show differences compared to the previous content of the PR. Marked as reviewed by kvn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From kim.barrett at oracle.com Sat Sep 12 00:30:44 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 11 Sep 2020 20:30:44 -0400 Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space [v2] In-Reply-To: References: Message-ID: <3A79ED67-A961-422B-9F4B-4D1D0EF40475@oracle.com> > On Sep 11, 2020, at 6:47 AM, Stefan Johansson wrote: > > On Fri, 11 Sep 2020 09:01:18 GMT, Kim Barrett wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to reviews by ayang and sjohanss. > > Nice test and thanks for going with "objarray". > > Looks good and I'll approve this now, but please fix the indent issue in the test before integrating. Thanks, will do. > test/hotspot/gtest/gc/shared/test_partialArrayTaskStepper.cpp line 55: > >> 53: int length, >> 54: int* to_length_addr, >> 55: uint chunk_size) { > > Indent looks to be one-off here. Yeah, changed return type from void to int at some point and missed adjusting the indentation. From kim.barrett at oracle.com Sat Sep 12 01:02:10 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 11 Sep 2020 21:02:10 -0400 Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space [v2] In-Reply-To: References: Message-ID: > On Sep 11, 2020, at 8:50 AM, Thomas Schatzl wrote: > > Hi, > > On 11.09.20 11:01, Kim Barrett wrote: > [...] >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> Respond to reviews by ayang and sjohanss. > > >> Changes: >> - all: https://git.openjdk.java.net/jdk/pull/90/files >> - new: https://git.openjdk.java.net/jdk/pull/90/files/9397514e..1981c392 >> Webrevs: >> - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=90&range=01 >> - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=90&range=00-01 >> Stats: 152 lines in 6 files changed: 122 ins; 14 del; 16 mod >> Patch: https://git.openjdk.java.net/jdk/pull/90.diff >> Fetch: git fetch https://git.openjdk.java.net/jdk pull/90/head:pull/90 >> PR: https://git.openjdk.java.net/jdk/pull/90 > > - partialArrayTaskStepper.hpp: > > s/_task_fannout/_task_fanout (or maybe _task_fan_out) I thought it looked a little odd at first, but never got around to spell checking it, and after a while it looked fine by familiarity. Will fix ("fanout"). > - since _task_fannout and _task_limit are only assigned in the constructor of PartialArrayTaskStepper, maybe make them const? I'd rather not. I've been down that road and didn't like the results. Just as an example, doing that sort of thing renders a class copyable but not assignable, swappable, or (in some cases) moveable from. That's an odd combination. I already (though recently) made start() and next() const. > - also the asserts in PartialArrayTaskStepper::next_impl could be moved to the constructor initialization list but otoh the fannout > 0 assert does make the calculation below immediately obviously safe. As you say, the current location shows the requirements for the nearby calculations. > Looks good otherwise. Thanks. > Thanks, > Thomas From kvn at openjdk.java.net Sat Sep 12 01:09:40 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Sat, 12 Sep 2020 01:09:40 GMT Subject: RFR: 8252898: remove bulk registration of JFR CompilerPhaseType names [v2] In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 21:05:21 GMT, Doug Simon wrote: >> The changes made in [JDK-8193210](https://bugs.openjdk.java.net/browse/JDK-8193210) support only [bulk >> registration](https://github.com/openjdk/jdk/blob/4e6a4af1866d0007d368b78bf78b6a8e1c8be425/src/hotspot/share/compiler/compilerEvent.hpp#L75) >> of compiler phase names with JFR. However, Graal only registers compiler phase names upon first execution of the phase >> since the set of phases is not known during VM initialization. This means registration of a Graal phase name needs to >> do unnecessary work, wrapping a single name into an array to conform to the bulk registration API. This pull request >> updates the registration API to be in terms of a registering a single phase name. > > Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental > views will show differences compared to the previous content of the PR. Looks good. I ran jfr/event/compiler tests with changes and they passed except TestCompilerInlining.java which failed before changes. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/77 From kvn at openjdk.java.net Sat Sep 12 01:09:40 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Sat, 12 Sep 2020 01:09:40 GMT Subject: RFR: 8252898: remove bulk registration of JFR CompilerPhaseType names [v2] In-Reply-To: References: Message-ID: On Sat, 12 Sep 2020 01:05:41 GMT, Vladimir Kozlov wrote: >> Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental >> views will show differences compared to the previous content of the PR. > > Looks good. > I ran jfr/event/compiler tests with changes and they passed except TestCompilerInlining.java which failed before > changes. I still want @jamsheedcm to review it too. ------------- PR: https://git.openjdk.java.net/jdk/pull/77 From kbarrett at openjdk.java.net Sun Sep 13 07:37:00 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 13 Sep 2020 07:37:00 GMT Subject: RFR: 8247909: Improve PrimitiveConversions::cast using C++14 Message-ID: <1BYMg9eOMQD2HA2MVjBpJ8BQeDmWXtI1LItGWlyTR5A=.6a00ed66-a78f-401e-935e-04e85a6d33f6@github.com> Please review this reimplementation of PrimitiveConversions::cast, using facilities from C++14. In particular, conversions involving only integral values or integral and enum values are now constexpr. Also using rather than HotSpot work-alikes. Had to update zForwardingEntry.hpp because of a class no longer being implicitly included. Improved a friend declaration while in the vicinity. Testing mach5 tier1 ------------- Commit messages: - Reimpliment PC::cast, with some cases now constexpr. Changes: https://git.openjdk.java.net/jdk/pull/143/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=143&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247909 Stats: 237 lines in 3 files changed: 111 ins; 110 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/143.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/143/head:pull/143 PR: https://git.openjdk.java.net/jdk/pull/143 From kustos at gmx.net Sun Sep 13 11:45:41 2020 From: kustos at gmx.net (Philippe Marschall) Date: Sun, 13 Sep 2020 13:45:41 +0200 Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> <9vXfRW4SRrizofvC6H9WecRjoXNNMwvscj7I5nlfj1Q=.c3760baf-604b-4a61-ae24-59500edca721@github.com> Message-ID: On 11.09.20 23:57, Vladimir Kozlov wrote: > On Thu, 10 Sep 2020 17:59:54 GMT, Paul Sandoz wrote: > >>> Philippe Marschall has refreshed the contents of this pull request, and previous commits have been removed. The >>> incremental views will show differences compared to the previous content of the PR. >> >> Marked as reviewed by psandoz (Reviewer). > > You should consider upstreaming Graal changes (jdk.internal.vm.compiler) into https://github.com/oracle/graal > Otherwise next time we do "Update Graal" in JDK they will be overwritten. Done https://github.com/oracle/graal/pull/2846 Philippe From jbhateja at openjdk.java.net Sun Sep 13 19:12:03 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Sun, 13 Sep 2020 19:12:03 GMT Subject: RFR: 8252848: Optimize small primitive arrayCopy operations through partial inlining using AVX-512 masked instructions Message-ID: Summary: 1) Partial in-lining technique avoids call overhead penalty for sub-word type small array copy operations with size less than 32 bytes. 2) At runtime, a conditional check based on copy length either calls an array-copy stub or executes an optimized instruction sequence using AVX-512 masked instructions emitted at the call site. 3) New runtime flag ArrayCopyPartialInlineSize=0/32(default)/64 bytes determines the maximum size for partial in-lining. Performance Results: System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java ArrayCopyPartialInlineSize : 32 JMH | Block Size | Baseline (ns/op) | Partial Inling (ns/op) | Gain -- | -- | -- | -- | -- ArrayCopyAligned.testByte | 1 | 5.417 | 2.696 | 2.009272997 ArrayCopyAligned.testByte | 3 | 5.494 | 2.702 | 2.03330866 ArrayCopyAligned.testByte | 5 | 5.417 | 2.637 | 2.05422829 ArrayCopyAligned.testByte | 10 | 5.343 | 2.703 | 1.976692564 ArrayCopyAligned.testByte | 20 | 5.837 | 2.636 | 2.214339909 ArrayCopyAligned.testByte | 70 | 5.86 | 6 | 0.976666667 ArrayCopyAligned.testByte | 150 | 6.766 | 6.906 | 0.979727773 ArrayCopyAligned.testByte | 300 | 7.605 | 7.952 | 0.956363179 ArrayCopyAligned.testByte | 600 | 11.989 | 12.007 | 0.998500874 ArrayCopyAligned.testByte | 1200 | 16.447 | 16.585 | 0.991679228 ArrayCopyAligned.testChar | 1 | 5.02 | 2.828 | 1.775106082 ArrayCopyAligned.testChar | 3 | 5.129 | 2.762 | 1.85698769 ArrayCopyAligned.testChar | 5 | 5.041 | 2.762 | 1.82512672 ArrayCopyAligned.testChar | 10 | 5.716 | 2.762 | 2.069514844 ArrayCopyAligned.testChar | 20 | 5.111 | 5.399 | 0.946656788 ArrayCopyAligned.testChar | 70 | 6.271 | 6.242 | 1.004645947 ArrayCopyAligned.testChar | 150 | 7.45 | 7.599 | 0.980392157 ArrayCopyAligned.testChar | 300 | 9.904 | 10.112 | 0.97943038 ArrayCopyAligned.testChar | 600 | 17.131 | 17.167 | 0.997902953 ArrayCopyAligned.testChar | 1200 | 29.556 | 29.851 | 0.990117584 ArrayCopyUnalignedBoth.testByte | 1 | 5.419 | 2.702 | 2.005551443 ArrayCopyUnalignedBoth.testByte | 3 | 5.558 | 2.636 | 2.108497724 ArrayCopyUnalignedBoth.testByte | 5 | 5.43 | 2.636 | 2.059939302 ArrayCopyUnalignedBoth.testByte | 10 | 5.378 | 2.637 | 2.039438756 ArrayCopyUnalignedBoth.testByte | 20 | 5.914 | 2.636 | 2.243550835 ArrayCopyUnalignedBoth.testByte | 70 | 5.882 | 5.954 | 0.987907289 ArrayCopyUnalignedBoth.testByte | 150 | 6.784 | 6.88 | 0.986046512 ArrayCopyUnalignedBoth.testByte | 300 | 7.635 | 7.968 | 0.958207831 ArrayCopyUnalignedBoth.testByte | 600 | 12.226 | 12.129 | 1.007997362 ArrayCopyUnalignedBoth.testByte | 1200 | 16.992 | 20.717 | 0.820195974 ArrayCopyUnalignedBoth.testChar | 1 | 5.019 | 2.828 | 1.774752475 ArrayCopyUnalignedBoth.testChar | 3 | 5.163 | 2.763 | 1.868621064 ArrayCopyUnalignedBoth.testChar | 5 | 5.042 | 2.827 | 1.783516095 ArrayCopyUnalignedBoth.testChar | 10 | 5.718 | 2.828 | 2.021923621 ArrayCopyUnalignedBoth.testChar | 20 | 5.111 | 5.404 | 0.945780903 ArrayCopyUnalignedBoth.testChar | 70 | 6.367 | 6.235 | 1.02117081 ArrayCopyUnalignedBoth.testChar | 150 | 7.367 | 8.269 | 0.890917886 ArrayCopyUnalignedBoth.testChar | 300 | 10.358 | 10.642 | 0.973313287 ArrayCopyUnalignedBoth.testChar | 600 | 20.84 | 17.522 | 1.189361945 ArrayCopyUnalignedBoth.testChar | 1200 | 31.895 | 31.892 | 1.000094067 ArrayCopyUnalignedDst.testByte | 1 | 5.455 | 2.637 | 2.068638604 ArrayCopyUnalignedDst.testByte | 3 | 5.562 | 2.702 | 2.058475204 ArrayCopyUnalignedDst.testByte | 5 | 5.427 | 2.702 | 2.008512213 ArrayCopyUnalignedDst.testByte | 10 | 5.367 | 2.696 | 1.990727003 ArrayCopyUnalignedDst.testByte | 20 | 5.839 | 2.637 | 2.214258627 ArrayCopyUnalignedDst.testByte | 70 | 5.888 | 5.968 | 0.986595174 ArrayCopyUnalignedDst.testByte | 150 | 6.785 | 6.773 | 1.001771741 ArrayCopyUnalignedDst.testByte | 300 | 7.606 | 7.972 | 0.954089313 ArrayCopyUnalignedDst.testByte | 600 | 11.986 | 21.195 | 0.565510734 ArrayCopyUnalignedDst.testByte | 1200 | 16.54 | 16.784 | 0.985462345 ArrayCopyUnalignedDst.testChar | 1 | 5.02 | 2.827 | 1.775733994 ArrayCopyUnalignedDst.testChar | 3 | 5.131 | 2.762 | 1.857711803 ArrayCopyUnalignedDst.testChar | 5 | 5.038 | 2.762 | 1.82404055 ArrayCopyUnalignedDst.testChar | 10 | 5.718 | 2.762 | 2.070238957 ArrayCopyUnalignedDst.testChar | 20 | 5.113 | 5.401 | 0.946676541 ArrayCopyUnalignedDst.testChar | 70 | 6.222 | 6.214 | 1.001287416 ArrayCopyUnalignedDst.testChar | 150 | 7.367 | 8.125 | 0.906707692 ArrayCopyUnalignedDst.testChar | 300 | 10.204 | 10.082 | 1.012100774 ArrayCopyUnalignedDst.testChar | 600 | 16.978 | 17.135 | 0.990837467 ArrayCopyUnalignedDst.testChar | 1200 | 32.351 | 31.996 | 1.011095137 ArrayCopyUnalignedSrc.testByte | 1 | 5.414 | 2.696 | 2.008160237 ArrayCopyUnalignedSrc.testByte | 3 | 5.494 | 2.637 | 2.083428138 ArrayCopyUnalignedSrc.testByte | 5 | 5.431 | 2.637 | 2.059537353 ArrayCopyUnalignedSrc.testByte | 10 | 5.344 | 2.703 | 1.977062523 ArrayCopyUnalignedSrc.testByte | 20 | 5.834 | 2.696 | 2.163946588 ArrayCopyUnalignedSrc.testByte | 70 | 5.883 | 6.009 | 0.979031453 ArrayCopyUnalignedSrc.testByte | 150 | 6.729 | 6.87 | 0.979475983 ArrayCopyUnalignedSrc.testByte | 300 | 7.603 | 7.97 | 0.953952321 ArrayCopyUnalignedSrc.testByte | 600 | 12.004 | 12.16 | 0.987171053 ArrayCopyUnalignedSrc.testByte | 1200 | 16.534 | 16.643 | 0.9934507 ArrayCopyUnalignedSrc.testChar | 1 | 5.021 | 2.762 | 1.81788559 ArrayCopyUnalignedSrc.testChar | 3 | 5.13 | 2.762 | 1.857349747 ArrayCopyUnalignedSrc.testChar | 5 | 5.042 | 2.827 | 1.783516095 ArrayCopyUnalignedSrc.testChar | 10 | 5.726 | 2.761 | 2.073886273 ArrayCopyUnalignedSrc.testChar | 20 | 5.112 | 5.401 | 0.94649139 ArrayCopyUnalignedSrc.testChar | 70 | 6.113 | 6.227 | 0.981692629 ArrayCopyUnalignedSrc.testChar | 150 | 7.493 | 7.888 | 0.949923935 ArrayCopyUnalignedSrc.testChar | 300 | 10.234 | 10.501 | 0.97457385 ArrayCopyUnalignedSrc.testChar | 600 | 17.175 | 17.142 | 1.001925096 ArrayCopyUnalignedSrc.testChar | 1200 | 31.926 | 31.987 | 0.998092975 Detailed Reports: Baseline : [http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_Baseline.txt]() WithOpt : [http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_With_PI_Opts.txt](url) ------------- Commit messages: - 8252848: Optimize small primitive arrayCopy operations through partial inlining using AVX-512 masked instructions. Changes: https://git.openjdk.java.net/jdk/pull/144/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=144&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252848 Stats: 561 lines in 27 files changed: 545 ins; 1 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/144.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/144/head:pull/144 PR: https://git.openjdk.java.net/jdk/pull/144 From david.holmes at oracle.com Mon Sep 14 00:36:38 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Sep 2020 10:36:38 +1000 Subject: Integrated: 8253029: [PPC64] Remove obsolete Power6 code In-Reply-To: References: <_3Dj2yHMngMuxQKL1Q1DKdB1W1kcUawtFg6YDZSuFPM=.63336975-a03a-4e6d-9823-3c336fdc30ae@github.com> Message-ID: Something got messed up here. So for the mailing list record this PR was cancelled not integrated! And now idea how the 8252817 info got included here ??? David On 11/09/2020 8:20 pm, Martin Doerr wrote: > On Thu, 10 Sep 2020 19:52:08 GMT, Martin Doerr wrote: > >> The recent PPC64 platform files still contain code which is part of a Power6 optimization called Power6Scheduler. >> However, this functionality was never completely contributed so it was never usable in the OpenJDK. We should remove it >> since we're no longer optimizing for Power6. > > This pull request has now been integrated. > > Changeset: ff21696b > Author: Sergey Bylokhov > URL: https://git.openjdk.java.net/jdk/commit/ff21696b > Stats: 142 lines in 7 files changed: 6 ins; 14 del; 122 mod > > 8252817: Cleanup the classes in the java.awt.color package > > Reviewed-by: jdv, pbansal > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/116 > From dholmes at openjdk.java.net Mon Sep 14 00:43:38 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 14 Sep 2020 00:43:38 GMT Subject: RFR: 8253029: Remove obsolete Power6 code In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 10:22:52 GMT, Martin Doerr wrote: > New pull request: > Using a branch, updated Copyright, removed some more unused code. > > [Previous text] > The recent PPC64 platform files still contain code which is part of a Power6 optimization called Power6Scheduler. > However, this functionality was never completely contributed so it was never usable in the OpenJDK. We should remove it > since we're no longer optimizing for Power6. Code changes seem fine. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/127 From david.holmes at oracle.com Mon Sep 14 02:31:54 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Sep 2020 12:31:54 +1000 Subject: RFR: 8247909: Improve PrimitiveConversions::cast using C++14 In-Reply-To: <1BYMg9eOMQD2HA2MVjBpJ8BQeDmWXtI1LItGWlyTR5A=.6a00ed66-a78f-401e-935e-04e85a6d33f6@github.com> References: <1BYMg9eOMQD2HA2MVjBpJ8BQeDmWXtI1LItGWlyTR5A=.6a00ed66-a78f-401e-935e-04e85a6d33f6@github.com> Message-ID: <8da38728-ca7a-613d-9b1d-7056f349dac3@oracle.com> Hi Kim, On 13/09/2020 5:37 pm, Kim Barrett wrote: > Please review this reimplementation of PrimitiveConversions::cast, > using facilities from C++14. In particular, conversions involving > only integral values or integral and enum values are now constexpr. > Also using rather than HotSpot work-alikes. > > Had to update zForwardingEntry.hpp because of a class no longer being > implicitly included. Improved a friend declaration while in the > vicinity. Can't comment on C++ specifics but all the changes seem reasonable to me. Thanks, David > Testing > mach5 tier1 > > ------------- > > Commit messages: > - Reimpliment PC::cast, with some cases now constexpr. > > Changes: https://git.openjdk.java.net/jdk/pull/143/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=143&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8247909 > Stats: 237 lines in 3 files changed: 111 ins; 110 del; 16 mod > Patch: https://git.openjdk.java.net/jdk/pull/143.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/143/head:pull/143 > > PR: https://git.openjdk.java.net/jdk/pull/143 > From dholmes at openjdk.java.net Mon Sep 14 02:34:52 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 14 Sep 2020 02:34:52 GMT Subject: RFR: 8247909: Improve PrimitiveConversions::cast using C++14 In-Reply-To: <1BYMg9eOMQD2HA2MVjBpJ8BQeDmWXtI1LItGWlyTR5A=.6a00ed66-a78f-401e-935e-04e85a6d33f6@github.com> References: <1BYMg9eOMQD2HA2MVjBpJ8BQeDmWXtI1LItGWlyTR5A=.6a00ed66-a78f-401e-935e-04e85a6d33f6@github.com> Message-ID: On Sun, 13 Sep 2020 07:27:13 GMT, Kim Barrett wrote: > Please review this reimplementation of PrimitiveConversions::cast, > using facilities from C++14. In particular, conversions involving > only integral values or integral and enum values are now constexpr. > Also using rather than HotSpot work-alikes. > > Had to update zForwardingEntry.hpp because of a class no longer being > implicitly included. Improved a friend declaration while in the > vicinity. > > Testing > mach5 tier1 Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/143 From dholmes at openjdk.java.net Mon Sep 14 04:04:52 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 14 Sep 2020 04:04:52 GMT Subject: RFR: 8252848: Optimize small primitive arrayCopy operations through partial inlining using AVX-512 masked instructions In-Reply-To: References: Message-ID: On Sun, 13 Sep 2020 19:02:59 GMT, Jatin Bhateja wrote: > Summary: > > 1) Partial in-lining technique avoids call overhead penalty for sub-word type small array copy operations with size > less than 32 bytes. 2) At runtime, a conditional check based on copy length either calls an array-copy stub or executes > an optimized instruction sequence using AVX-512 masked instructions emitted at the call site. 3) New runtime flag > ArrayCopyPartialInlineSize=0/32(default)/64 bytes determines the maximum size for partial in-lining. > Performance Results: > System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz > Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java > ArrayCopyPartialInlineSize : 32 > > JMH | Block Size | Baseline (ns/op) | Partial Inling (ns/op) | Gain > -- | -- | -- | -- | -- > ArrayCopyAligned.testByte | 1 | 5.417 | 2.696 | 2.009272997 > ArrayCopyAligned.testByte | 3 | 5.494 | 2.702 | 2.03330866 > ArrayCopyAligned.testByte | 5 | 5.417 | 2.637 | 2.05422829 > ArrayCopyAligned.testByte | 10 | 5.343 | 2.703 | 1.976692564 > ArrayCopyAligned.testByte | 20 | 5.837 | 2.636 | 2.214339909 > ArrayCopyAligned.testByte | 70 | 5.86 | 6 | 0.976666667 > ArrayCopyAligned.testByte | 150 | 6.766 | 6.906 | 0.979727773 > ArrayCopyAligned.testByte | 300 | 7.605 | 7.952 | 0.956363179 > ArrayCopyAligned.testByte | 600 | 11.989 | 12.007 | 0.998500874 > ArrayCopyAligned.testByte | 1200 | 16.447 | 16.585 | 0.991679228 > ArrayCopyAligned.testChar | 1 | 5.02 | 2.828 | 1.775106082 > ArrayCopyAligned.testChar | 3 | 5.129 | 2.762 | 1.85698769 > ArrayCopyAligned.testChar | 5 | 5.041 | 2.762 | 1.82512672 > ArrayCopyAligned.testChar | 10 | 5.716 | 2.762 | 2.069514844 > ArrayCopyAligned.testChar | 20 | 5.111 | 5.399 | 0.946656788 > ArrayCopyAligned.testChar | 70 | 6.271 | 6.242 | 1.004645947 > ArrayCopyAligned.testChar | 150 | 7.45 | 7.599 | 0.980392157 > ArrayCopyAligned.testChar | 300 | 9.904 | 10.112 | 0.97943038 > ArrayCopyAligned.testChar | 600 | 17.131 | 17.167 | 0.997902953 > ArrayCopyAligned.testChar | 1200 | 29.556 | 29.851 | 0.990117584 > ArrayCopyUnalignedBoth.testByte | 1 | 5.419 | 2.702 | 2.005551443 > ArrayCopyUnalignedBoth.testByte | 3 | 5.558 | 2.636 | 2.108497724 > ArrayCopyUnalignedBoth.testByte | 5 | 5.43 | 2.636 | 2.059939302 > ArrayCopyUnalignedBoth.testByte | 10 | 5.378 | 2.637 | 2.039438756 > ArrayCopyUnalignedBoth.testByte | 20 | 5.914 | 2.636 | 2.243550835 > ArrayCopyUnalignedBoth.testByte | 70 | 5.882 | 5.954 | 0.987907289 > ArrayCopyUnalignedBoth.testByte | 150 | 6.784 | 6.88 | 0.986046512 > ArrayCopyUnalignedBoth.testByte | 300 | 7.635 | 7.968 | 0.958207831 > ArrayCopyUnalignedBoth.testByte | 600 | 12.226 | 12.129 | 1.007997362 > ArrayCopyUnalignedBoth.testByte | 1200 | 16.992 | 20.717 | 0.820195974 > ArrayCopyUnalignedBoth.testChar | 1 | 5.019 | 2.828 | 1.774752475 > ArrayCopyUnalignedBoth.testChar | 3 | 5.163 | 2.763 | 1.868621064 > ArrayCopyUnalignedBoth.testChar | 5 | 5.042 | 2.827 | 1.783516095 > ArrayCopyUnalignedBoth.testChar | 10 | 5.718 | 2.828 | 2.021923621 > ArrayCopyUnalignedBoth.testChar | 20 | 5.111 | 5.404 | 0.945780903 > ArrayCopyUnalignedBoth.testChar | 70 | 6.367 | 6.235 | 1.02117081 > ArrayCopyUnalignedBoth.testChar | 150 | 7.367 | 8.269 | 0.890917886 > ArrayCopyUnalignedBoth.testChar | 300 | 10.358 | 10.642 | 0.973313287 > ArrayCopyUnalignedBoth.testChar | 600 | 20.84 | 17.522 | 1.189361945 > ArrayCopyUnalignedBoth.testChar | 1200 | 31.895 | 31.892 | 1.000094067 > ArrayCopyUnalignedDst.testByte | 1 | 5.455 | 2.637 | 2.068638604 > ArrayCopyUnalignedDst.testByte | 3 | 5.562 | 2.702 | 2.058475204 > ArrayCopyUnalignedDst.testByte | 5 | 5.427 | 2.702 | 2.008512213 > ArrayCopyUnalignedDst.testByte | 10 | 5.367 | 2.696 | 1.990727003 > ArrayCopyUnalignedDst.testByte | 20 | 5.839 | 2.637 | 2.214258627 > ArrayCopyUnalignedDst.testByte | 70 | 5.888 | 5.968 | 0.986595174 > ArrayCopyUnalignedDst.testByte | 150 | 6.785 | 6.773 | 1.001771741 > ArrayCopyUnalignedDst.testByte | 300 | 7.606 | 7.972 | 0.954089313 > ArrayCopyUnalignedDst.testByte | 600 | 11.986 | 21.195 | 0.565510734 > ArrayCopyUnalignedDst.testByte | 1200 | 16.54 | 16.784 | 0.985462345 > ArrayCopyUnalignedDst.testChar | 1 | 5.02 | 2.827 | 1.775733994 > ArrayCopyUnalignedDst.testChar | 3 | 5.131 | 2.762 | 1.857711803 > ArrayCopyUnalignedDst.testChar | 5 | 5.038 | 2.762 | 1.82404055 > ArrayCopyUnalignedDst.testChar | 10 | 5.718 | 2.762 | 2.070238957 > ArrayCopyUnalignedDst.testChar | 20 | 5.113 | 5.401 | 0.946676541 > ArrayCopyUnalignedDst.testChar | 70 | 6.222 | 6.214 | 1.001287416 > ArrayCopyUnalignedDst.testChar | 150 | 7.367 | 8.125 | 0.906707692 > ArrayCopyUnalignedDst.testChar | 300 | 10.204 | 10.082 | 1.012100774 > ArrayCopyUnalignedDst.testChar | 600 | 16.978 | 17.135 | 0.990837467 > ArrayCopyUnalignedDst.testChar | 1200 | 32.351 | 31.996 | 1.011095137 > ArrayCopyUnalignedSrc.testByte | 1 | 5.414 | 2.696 | 2.008160237 > ArrayCopyUnalignedSrc.testByte | 3 | 5.494 | 2.637 | 2.083428138 > ArrayCopyUnalignedSrc.testByte | 5 | 5.431 | 2.637 | 2.059537353 > ArrayCopyUnalignedSrc.testByte | 10 | 5.344 | 2.703 | 1.977062523 > ArrayCopyUnalignedSrc.testByte | 20 | 5.834 | 2.696 | 2.163946588 > ArrayCopyUnalignedSrc.testByte | 70 | 5.883 | 6.009 | 0.979031453 > ArrayCopyUnalignedSrc.testByte | 150 | 6.729 | 6.87 | 0.979475983 > ArrayCopyUnalignedSrc.testByte | 300 | 7.603 | 7.97 | 0.953952321 > ArrayCopyUnalignedSrc.testByte | 600 | 12.004 | 12.16 | 0.987171053 > ArrayCopyUnalignedSrc.testByte | 1200 | 16.534 | 16.643 | 0.9934507 > ArrayCopyUnalignedSrc.testChar | 1 | 5.021 | 2.762 | 1.81788559 > ArrayCopyUnalignedSrc.testChar | 3 | 5.13 | 2.762 | 1.857349747 > ArrayCopyUnalignedSrc.testChar | 5 | 5.042 | 2.827 | 1.783516095 > ArrayCopyUnalignedSrc.testChar | 10 | 5.726 | 2.761 | 2.073886273 > ArrayCopyUnalignedSrc.testChar | 20 | 5.112 | 5.401 | 0.94649139 > ArrayCopyUnalignedSrc.testChar | 70 | 6.113 | 6.227 | 0.981692629 > ArrayCopyUnalignedSrc.testChar | 150 | 7.493 | 7.888 | 0.949923935 > ArrayCopyUnalignedSrc.testChar | 300 | 10.234 | 10.501 | 0.97457385 > ArrayCopyUnalignedSrc.testChar | 600 | 17.175 | 17.142 | 1.001925096 > ArrayCopyUnalignedSrc.testChar | 1200 | 31.926 | 31.987 | 0.998092975 > > Detailed Reports: > Baseline : [http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_Baseline.txt]() > WithOpt : [http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_With_PI_Opts.txt](url) Adding a new product flag requires a CSR request to be filed. ------------- PR: https://git.openjdk.java.net/jdk/pull/144 From dholmes at openjdk.java.net Mon Sep 14 04:21:26 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 14 Sep 2020 04:21:26 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2] In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 07:03:37 GMT, Aleksei Voitylov wrote: >> continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html >> >>> The download side of using JNI in these tests is that it complicates the >>> setup a bit for those that run jtreg directly and/or just build the JDK >>> and not the test libraries. You could reduce this burden a bit by >>> limiting the load library/isMusl check to Linux only, meaning isMusl >>> would not be called on other platforms. >>> >>> The alternative you suggest above might indeed be better. I assume you >>> don't mean splitting the tests but rather just adding a second @test >>> description so that the vm.musl case runs the test with a system >>> property that allows the test know the expected load library path behavior. >> >> I have updated the PR to split the two tests in multiple @test s. >> >>> The updated comment in java_md.c in this looks good. A minor comment on >>> Platform.isBusybox is Files.isSymbolicLink returning true implies that >>> the link exists so no need to check for exists too. Also the >>> if-then-else style for the new class in ProcessBuilder/Basic.java is >>> inconsistent with the rest of the test so it stands out. >> >> Thank you, these changes are done in the updated PR. >> >>> Given the repo transition this weekend then I assume you'll create a PR >>> for the final review at least. Also I see JEP 386 hasn't been targeted >>> yet but I assume Boris, as owner, will propose-to-target and wait for it >>> to be targeted before it is integrated. >> >> Yes. How can this be best accomplished with the new git workflow? >> - we can continue the review process till the end and I will request the integration to happen only after the JEP is >> targeted. I guess this step is now done by typing "slash integrate" in a comment. >> - we can pause the review process now until the JEP is targeted. >> >> In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here. > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8247589: Implementation of Alpine Linux/x64 Port Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/49 From dholmes at openjdk.java.net Mon Sep 14 04:21:27 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 14 Sep 2020 04:21:27 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2] In-Reply-To: References: Message-ID: <6y6Cyk85aOiF6smCGSK5VH-rBadloV2gW8iVIW1e9BE=.47f56d70-2a7a-4951-a058-10add4118b31@github.com> On Wed, 9 Sep 2020 00:08:35 GMT, David Holmes wrote: >> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8247589: Implementation of Alpine Linux/x64 Port > > Attempting to use the GitHub UI for further review. If this doesn't work out well I will revert to direct email. Updates look good. Nothing further from me. ------------- PR: https://git.openjdk.java.net/jdk/pull/49 From dholmes at openjdk.java.net Mon Sep 14 04:21:27 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 14 Sep 2020 04:21:27 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2] In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 07:36:57 GMT, Aleksei Voitylov wrote: >> test/hotspot/jtreg/runtime/StackGuardPages/exeinvoke.c line 282: >> >>> 280: >>> 281: pthread_attr_init(&thread_attr); >>> 282: pthread_attr_setstacksize(&thread_attr, stack_size); >> >> Just a comment in response to the explanation as to why this change is needed. If the default thread stacksize under >> musl is insufficient to successfully attach such a thread to the VM then this will cause problems for applications that >> embed the VM directly (or which otherwise directly attach existing threads). > > This fix https://git.musl-libc.org/cgit/musl/commit/src/aio/aio.c?id=1a6d6f131bd60ec2a858b34100049f0c042089f2 > addresses the problem for recent versions of musl. The test passes on a recent Alpine Linux 3.11.6 (musl 1.1.24) and > fails on Alpine Linux 3.8.2 (musl 1.1.19) without this test fix. There are still older versions of the library in the > wild, hence the test fix. The mitigation for such users would be a distro upgrade. Thanks for the additional info on this. ------------- PR: https://git.openjdk.java.net/jdk/pull/49 From jbhateja at openjdk.java.net Mon Sep 14 05:04:24 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 14 Sep 2020 05:04:24 GMT Subject: RFR: 8252848: Optimize small primitive arrayCopy operations through partial inlining using AVX-512 masked instructions In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 04:02:10 GMT, David Holmes wrote: >> Summary: >> >> 1) Partial in-lining technique avoids call overhead penalty for sub-word type small array copy operations with size >> less than 32 bytes. 2) At runtime, a conditional check based on copy length either calls an array-copy stub or executes >> an optimized instruction sequence using AVX-512 masked instructions emitted at the call site. 3) New runtime flag >> ArrayCopyPartialInlineSize=0/32(default)/64 bytes determines the maximum size for partial in-lining. >> Performance Results: >> System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz >> Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java >> ArrayCopyPartialInlineSize : 32 >> >> JMH | Block Size | Baseline (ns/op) | Partial Inling (ns/op) | Gain >> -- | -- | -- | -- | -- >> ArrayCopyAligned.testByte | 1 | 5.417 | 2.696 | 2.009272997 >> ArrayCopyAligned.testByte | 3 | 5.494 | 2.702 | 2.03330866 >> ArrayCopyAligned.testByte | 5 | 5.417 | 2.637 | 2.05422829 >> ArrayCopyAligned.testByte | 10 | 5.343 | 2.703 | 1.976692564 >> ArrayCopyAligned.testByte | 20 | 5.837 | 2.636 | 2.214339909 >> ArrayCopyAligned.testByte | 70 | 5.86 | 6 | 0.976666667 >> ArrayCopyAligned.testByte | 150 | 6.766 | 6.906 | 0.979727773 >> ArrayCopyAligned.testByte | 300 | 7.605 | 7.952 | 0.956363179 >> ArrayCopyAligned.testByte | 600 | 11.989 | 12.007 | 0.998500874 >> ArrayCopyAligned.testByte | 1200 | 16.447 | 16.585 | 0.991679228 >> ArrayCopyAligned.testChar | 1 | 5.02 | 2.828 | 1.775106082 >> ArrayCopyAligned.testChar | 3 | 5.129 | 2.762 | 1.85698769 >> ArrayCopyAligned.testChar | 5 | 5.041 | 2.762 | 1.82512672 >> ArrayCopyAligned.testChar | 10 | 5.716 | 2.762 | 2.069514844 >> ArrayCopyAligned.testChar | 20 | 5.111 | 5.399 | 0.946656788 >> ArrayCopyAligned.testChar | 70 | 6.271 | 6.242 | 1.004645947 >> ArrayCopyAligned.testChar | 150 | 7.45 | 7.599 | 0.980392157 >> ArrayCopyAligned.testChar | 300 | 9.904 | 10.112 | 0.97943038 >> ArrayCopyAligned.testChar | 600 | 17.131 | 17.167 | 0.997902953 >> ArrayCopyAligned.testChar | 1200 | 29.556 | 29.851 | 0.990117584 >> ArrayCopyUnalignedBoth.testByte | 1 | 5.419 | 2.702 | 2.005551443 >> ArrayCopyUnalignedBoth.testByte | 3 | 5.558 | 2.636 | 2.108497724 >> ArrayCopyUnalignedBoth.testByte | 5 | 5.43 | 2.636 | 2.059939302 >> ArrayCopyUnalignedBoth.testByte | 10 | 5.378 | 2.637 | 2.039438756 >> ArrayCopyUnalignedBoth.testByte | 20 | 5.914 | 2.636 | 2.243550835 >> ArrayCopyUnalignedBoth.testByte | 70 | 5.882 | 5.954 | 0.987907289 >> ArrayCopyUnalignedBoth.testByte | 150 | 6.784 | 6.88 | 0.986046512 >> ArrayCopyUnalignedBoth.testByte | 300 | 7.635 | 7.968 | 0.958207831 >> ArrayCopyUnalignedBoth.testByte | 600 | 12.226 | 12.129 | 1.007997362 >> ArrayCopyUnalignedBoth.testByte | 1200 | 16.992 | 20.717 | 0.820195974 >> ArrayCopyUnalignedBoth.testChar | 1 | 5.019 | 2.828 | 1.774752475 >> ArrayCopyUnalignedBoth.testChar | 3 | 5.163 | 2.763 | 1.868621064 >> ArrayCopyUnalignedBoth.testChar | 5 | 5.042 | 2.827 | 1.783516095 >> ArrayCopyUnalignedBoth.testChar | 10 | 5.718 | 2.828 | 2.021923621 >> ArrayCopyUnalignedBoth.testChar | 20 | 5.111 | 5.404 | 0.945780903 >> ArrayCopyUnalignedBoth.testChar | 70 | 6.367 | 6.235 | 1.02117081 >> ArrayCopyUnalignedBoth.testChar | 150 | 7.367 | 8.269 | 0.890917886 >> ArrayCopyUnalignedBoth.testChar | 300 | 10.358 | 10.642 | 0.973313287 >> ArrayCopyUnalignedBoth.testChar | 600 | 20.84 | 17.522 | 1.189361945 >> ArrayCopyUnalignedBoth.testChar | 1200 | 31.895 | 31.892 | 1.000094067 >> ArrayCopyUnalignedDst.testByte | 1 | 5.455 | 2.637 | 2.068638604 >> ArrayCopyUnalignedDst.testByte | 3 | 5.562 | 2.702 | 2.058475204 >> ArrayCopyUnalignedDst.testByte | 5 | 5.427 | 2.702 | 2.008512213 >> ArrayCopyUnalignedDst.testByte | 10 | 5.367 | 2.696 | 1.990727003 >> ArrayCopyUnalignedDst.testByte | 20 | 5.839 | 2.637 | 2.214258627 >> ArrayCopyUnalignedDst.testByte | 70 | 5.888 | 5.968 | 0.986595174 >> ArrayCopyUnalignedDst.testByte | 150 | 6.785 | 6.773 | 1.001771741 >> ArrayCopyUnalignedDst.testByte | 300 | 7.606 | 7.972 | 0.954089313 >> ArrayCopyUnalignedDst.testByte | 600 | 11.986 | 21.195 | 0.565510734 >> ArrayCopyUnalignedDst.testByte | 1200 | 16.54 | 16.784 | 0.985462345 >> ArrayCopyUnalignedDst.testChar | 1 | 5.02 | 2.827 | 1.775733994 >> ArrayCopyUnalignedDst.testChar | 3 | 5.131 | 2.762 | 1.857711803 >> ArrayCopyUnalignedDst.testChar | 5 | 5.038 | 2.762 | 1.82404055 >> ArrayCopyUnalignedDst.testChar | 10 | 5.718 | 2.762 | 2.070238957 >> ArrayCopyUnalignedDst.testChar | 20 | 5.113 | 5.401 | 0.946676541 >> ArrayCopyUnalignedDst.testChar | 70 | 6.222 | 6.214 | 1.001287416 >> ArrayCopyUnalignedDst.testChar | 150 | 7.367 | 8.125 | 0.906707692 >> ArrayCopyUnalignedDst.testChar | 300 | 10.204 | 10.082 | 1.012100774 >> ArrayCopyUnalignedDst.testChar | 600 | 16.978 | 17.135 | 0.990837467 >> ArrayCopyUnalignedDst.testChar | 1200 | 32.351 | 31.996 | 1.011095137 >> ArrayCopyUnalignedSrc.testByte | 1 | 5.414 | 2.696 | 2.008160237 >> ArrayCopyUnalignedSrc.testByte | 3 | 5.494 | 2.637 | 2.083428138 >> ArrayCopyUnalignedSrc.testByte | 5 | 5.431 | 2.637 | 2.059537353 >> ArrayCopyUnalignedSrc.testByte | 10 | 5.344 | 2.703 | 1.977062523 >> ArrayCopyUnalignedSrc.testByte | 20 | 5.834 | 2.696 | 2.163946588 >> ArrayCopyUnalignedSrc.testByte | 70 | 5.883 | 6.009 | 0.979031453 >> ArrayCopyUnalignedSrc.testByte | 150 | 6.729 | 6.87 | 0.979475983 >> ArrayCopyUnalignedSrc.testByte | 300 | 7.603 | 7.97 | 0.953952321 >> ArrayCopyUnalignedSrc.testByte | 600 | 12.004 | 12.16 | 0.987171053 >> ArrayCopyUnalignedSrc.testByte | 1200 | 16.534 | 16.643 | 0.9934507 >> ArrayCopyUnalignedSrc.testChar | 1 | 5.021 | 2.762 | 1.81788559 >> ArrayCopyUnalignedSrc.testChar | 3 | 5.13 | 2.762 | 1.857349747 >> ArrayCopyUnalignedSrc.testChar | 5 | 5.042 | 2.827 | 1.783516095 >> ArrayCopyUnalignedSrc.testChar | 10 | 5.726 | 2.761 | 2.073886273 >> ArrayCopyUnalignedSrc.testChar | 20 | 5.112 | 5.401 | 0.94649139 >> ArrayCopyUnalignedSrc.testChar | 70 | 6.113 | 6.227 | 0.981692629 >> ArrayCopyUnalignedSrc.testChar | 150 | 7.493 | 7.888 | 0.949923935 >> ArrayCopyUnalignedSrc.testChar | 300 | 10.234 | 10.501 | 0.97457385 >> ArrayCopyUnalignedSrc.testChar | 600 | 17.175 | 17.142 | 1.001925096 >> ArrayCopyUnalignedSrc.testChar | 1200 | 31.926 | 31.987 | 0.998092975 >> >> Detailed Reports: >> Baseline : [http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_Baseline.txt]() >> WithOpt : [http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_With_PI_Opts.txt](url) > > Adding a new product flag requires a CSR request to be filed. > /csr needed > > Adding a new product flag requires a CSR request to be filed. @dholmes-ora , with https://github.com/openjdk/jdk/commit/5144190e there has been a clean up of options and product options now accept DIAGNOSTIC as an additional parameter. Newly added flag is a DIAGNOSTIC flag. ------------- PR: https://git.openjdk.java.net/jdk/pull/144 From yueshi.zwj at alibaba-inc.com Mon Sep 14 06:02:11 2020 From: yueshi.zwj at alibaba-inc.com (Joshua Zhu) Date: Mon, 14 Sep 2020 14:02:11 +0800 Subject: RFR: 8253048: AArch64: When CallLeaf, no need to preserve callee-saved registers in caller In-Reply-To: <6f6717b1-1d91-657b-d28c-ecbb4b7bb33a@redhat.com> References: <9K43aYMMk0zdBfxGBwRA336lvjqGZyLFtZcQKVWLOec=.4a194ce2-db80-4dcc-9ef2-ed2a0d2cd088@github.com> <6f6717b1-1d91-657b-d28c-ecbb4b7bb33a@redhat.com> Message-ID: <005501d68a5c$9617e120$c247a360$@alibaba-inc.com> > > - 8253048: AArch64: When CallLeaf, no need to preserve callee-saved > > registers in caller > > > > Changes: https://git.openjdk.java.net/jdk/pull/129/files > > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=129&range=00 > > Issue: https://bugs.openjdk.java.net/browse/JDK-8253048 > > Stats: 22 lines in 2 files changed: 0 ins; 0 del; 22 mod > > Patch: https://git.openjdk.java.net/jdk/pull/129.diff > > Fetch: git fetch https://git.openjdk.java.net/jdk > > pull/129/head:pull/129 > > > > PR: https://git.openjdk.java.net/jdk/pull/129 > > That looks right. I take it that you've checked everywhere else for misuse of > callee-saved vector registers. Andrew, Thanks a lot for your review. Yes. I checked all occurrences of "V8-V15" in aarch64 codes. Best Regards, Joshua From dholmes at openjdk.java.net Mon Sep 14 06:05:36 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 14 Sep 2020 06:05:36 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 20:48:23 GMT, Richard Reingruber wrote: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. I can't review this in-depth as I am not familiar with too much of the code. I have looked at some of the key threading related parts and have made a number of comments. src/hotspot/share/compiler/compileBroker.cpp line 831: > 829: MonitorLocker ml(dt, EscapeBarrier_lock, Mutex::_no_safepoint_check_flag); > 830: static int single_thread_count = 0; > 831: enter_single_loop = single_thread_count++ < DeoptimizeObjectsALotThreadCountSingle; The update to `single_thread_count` is not atomic. src/hotspot/share/compiler/compileBroker.cpp line 844: > 842: void DeoptimizeObjectsALotThread::deoptimize_objects_alot_loop_single() { > 843: HandleMark hm(this); > 844: while (!this->is_terminated()) { The terminated state of a thread is used to communicate to other threads whether this thread has terminated. It isn't something that can be used to control the work-loop of the thread itself! This is an infinite loop as far as I can see. src/hotspot/share/compiler/compileBroker.cpp line 862: > 860: void DeoptimizeObjectsALotThread::deoptimize_objects_alot_loop_all() { > 861: HandleMark hm(this); > 862: while (!is_terminated()) { Same comment as above. src/hotspot/share/opto/macro.cpp line 1096: > 1094: // interpreter frames for this compiled frame and that won't play > 1095: // nice with JVMTI popframe. > 1096: if (!EliminateAllocations || !alloc->_is_non_escaping) { The comment needs to be updated to match the new code. src/hotspot/share/prims/whitebox.cpp line 884: > 882: > 883: WB_ENTRY(jboolean, WB_IsFrameDeoptimized(JNIEnv* env, jobject o, jint depth)) > 884: JavaThread* t = JavaThread::current(); A WB_ENTRY is a JNI_ENTRY which means the current JavaThread is already available via the `thread` variable. src/hotspot/share/runtime/thread.cpp line 2647: > 2645: bool should_spin_wait = true; > 2646: do { > 2647: set_thread_state(_thread_blocked); It isn't obvious that this raw thread state change is safe. src/hotspot/share/runtime/thread.cpp line 2660: > 2658: // showed 5% better performance when spinning. > 2659: if (should_spin_wait) { > 2660: // Inspired by HandshakeSpinYield Can we not reuse any existing spinning code in the VM? src/hotspot/share/runtime/thread.cpp line 2640: > 2638: } > 2639: > 2640: void JavaThread::wait_for_object_deoptimization() { I find this method very complex, and the fact it needs to recheck many of the conditions already checked in the calling code, suggests to me that the structure here is not quite right. Perhaps JavaThread::handle_special_runtime_exit_condition should be the place where we loop over each of the potential conditions, instead of calling per-condition code that then loops and potentially rechecks other conditions. src/hotspot/share/runtime/thread.cpp line 1926: > 1924: delete dlv; > 1925: } while (deferred->length() != 0); > 1926: delete deferred_updates(); This looks suspect - we delete what is pointed to but we don't NULL the field. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From goetz.lindenmaier at sap.com Mon Sep 14 06:13:43 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 14 Sep 2020 06:13:43 +0000 Subject: Integrated: 8243208: Clean up JVMFlag implementation In-Reply-To: References: Message-ID: Hi, Since this change was pushed, we see the following build error on Windows: .../src/hotspot/share/runtime/flags/jvmFlagLookup.cpp(54): error C2220: warning treated as error - no 'object' file generated .../src/hotspot/share/runtime/flags/jvmFlagLookup.cpp(54): warning C4307: '*': integral constant overflow We are compiling with Microsoft Visual Studio 2017. (Is it the right way to write a mail to bring this up, or should I comment the PullRequest or the like?) Best regards, Goetz > -----Original Message----- > From: hotspot-dev On Behalf Of Ioi > Lam > Sent: Friday, September 11, 2020 6:08 AM > To: hotspot-dev at openjdk.java.net; shenandoah-dev at openjdk.java.net > Subject: Integrated: 8243208: Clean up JVMFlag implementation > > On Tue, 8 Sep 2020 18:33:41 GMT, Ioi Lam wrote: > > > The initial commit > [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee > 9a92d10e1ac19d9bb2f8) is the > > same patch as > > [8243208-cleanup-jvmflag- > impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup- > jvmflag-impl.v02/) > > published in > > [hotspot- > dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot- > dev/2020-September/042863.html). The > > rest of the review will continue on GitHub. I will add new commits to > respond to comments to the above e-mail. > > This pull request has now been integrated. > > Changeset: 5144190e > Author: Ioi Lam > URL: https://git.openjdk.java.net/jdk/commit/5144190e > Stats: 2127 lines in 45 files changed: 533 ins; 755 del; 839 mod > > 8243208: Clean up JVMFlag implementation > > Reviewed-by: dholmes, coleenp, gziemski > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/82 From avoitylov at openjdk.java.net Mon Sep 14 06:33:20 2020 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Mon, 14 Sep 2020 06:33:20 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2] In-Reply-To: References: Message-ID: <6jqlCPXe69fPRvYFrytJsECkaa9tJ1hYWISNgyPP4Eg=.40944ef5-93b0-4db4-948b-80bb7898e9e8@github.com> On Mon, 14 Sep 2020 04:18:39 GMT, David Holmes wrote: >> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8247589: Implementation of Alpine Linux/x64 Port > > Marked as reviewed by dholmes (Reviewer). thank you Alan, Erik, and David! When the JEP becomes Targeted, I'll use this PR to integrate the changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/49 From david.holmes at oracle.com Mon Sep 14 06:44:56 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Sep 2020 16:44:56 +1000 Subject: Integrated: 8243208: Clean up JVMFlag implementation In-Reply-To: References: Message-ID: Hi Goetz, On 14/09/2020 4:13 pm, Lindenmaier, Goetz wrote: > Hi, > > Since this change was pushed, we see the following build error on Windows: > .../src/hotspot/share/runtime/flags/jvmFlagLookup.cpp(54): error C2220: warning treated as error - no 'object' file generated > .../src/hotspot/share/runtime/flags/jvmFlagLookup.cpp(54): warning C4307: '*': integral constant overflow > > We are compiling with Microsoft Visual Studio 2017. > > (Is it the right way to write a mail to bring this up, or > should I comment the PullRequest or the like?) You can write a mail or just file a bug. :) Is this 32-bit Windows? We have not seen any issue in our 64-bit builds. Thanks, David > Best regards, > Goetz > >> -----Original Message----- >> From: hotspot-dev On Behalf Of Ioi >> Lam >> Sent: Friday, September 11, 2020 6:08 AM >> To: hotspot-dev at openjdk.java.net; shenandoah-dev at openjdk.java.net >> Subject: Integrated: 8243208: Clean up JVMFlag implementation >> >> On Tue, 8 Sep 2020 18:33:41 GMT, Ioi Lam wrote: >> >>> The initial commit >> [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee >> 9a92d10e1ac19d9bb2f8) is the >>> same patch as >>> [8243208-cleanup-jvmflag- >> impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup- >> jvmflag-impl.v02/) >>> published in >>> [hotspot- >> dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot- >> dev/2020-September/042863.html). The >>> rest of the review will continue on GitHub. I will add new commits to >> respond to comments to the above e-mail. >> >> This pull request has now been integrated. >> >> Changeset: 5144190e >> Author: Ioi Lam >> URL: https://git.openjdk.java.net/jdk/commit/5144190e >> Stats: 2127 lines in 45 files changed: 533 ins; 755 del; 839 mod >> >> 8243208: Clean up JVMFlag implementation >> >> Reviewed-by: dholmes, coleenp, gziemski >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/82 From jcm at openjdk.java.net Mon Sep 14 06:49:09 2020 From: jcm at openjdk.java.net (Jamsheed Mohammed C M) Date: Mon, 14 Sep 2020 06:49:09 GMT Subject: RFR: 8252898: remove bulk registration of JFR CompilerPhaseType names [v2] In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 21:05:21 GMT, Doug Simon wrote: >> The changes made in [JDK-8193210](https://bugs.openjdk.java.net/browse/JDK-8193210) support only [bulk >> registration](https://github.com/openjdk/jdk/blob/4e6a4af1866d0007d368b78bf78b6a8e1c8be425/src/hotspot/share/compiler/compilerEvent.hpp#L75) >> of compiler phase names with JFR. However, Graal only registers compiler phase names upon first execution of the phase >> since the set of phases is not known during VM initialization. This means registration of a Graal phase name needs to >> do unnecessary work, wrapping a single name into an array to conform to the bulk registration API. This pull request >> updates the registration API to be in terms of a registering a single phase name. > > Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental > views will show differences compared to the previous content of the PR. The pull request contains one new commit since > the last revision: > 8252898: remove bulk registration of JFR CompilerPhaseType names Marked as reviewed by jcm (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/77 From goetz.lindenmaier at sap.com Mon Sep 14 07:02:28 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 14 Sep 2020 07:02:28 +0000 Subject: Integrated: 8243208: Clean up JVMFlag implementation In-Reply-To: References: Message-ID: Hi David, It fails in the 32 and 64-bit build with the same message. Best regards, Goetz > -----Original Message----- > From: David Holmes > Sent: Monday, September 14, 2020 8:45 AM > To: Lindenmaier, Goetz ; Ioi Lam > ; hotspot-dev at openjdk.java.net; shenandoah- > dev at openjdk.java.net > Subject: Re: Integrated: 8243208: Clean up JVMFlag implementation > > Hi Goetz, > > On 14/09/2020 4:13 pm, Lindenmaier, Goetz wrote: > > Hi, > > > > Since this change was pushed, we see the following build error on Windows: > > .../src/hotspot/share/runtime/flags/jvmFlagLookup.cpp(54): error C2220: > warning treated as error - no 'object' file generated > > .../src/hotspot/share/runtime/flags/jvmFlagLookup.cpp(54): warning > C4307: '*': integral constant overflow > > > > We are compiling with Microsoft Visual Studio 2017. > > > > (Is it the right way to write a mail to bring this up, or > > should I comment the PullRequest or the like?) > > You can write a mail or just file a bug. :) > > Is this 32-bit Windows? We have not seen any issue in our 64-bit builds. > > Thanks, > David > > > > Best regards, > > Goetz > > > >> -----Original Message----- > >> From: hotspot-dev On Behalf Of > Ioi > >> Lam > >> Sent: Friday, September 11, 2020 6:08 AM > >> To: hotspot-dev at openjdk.java.net; shenandoah-dev at openjdk.java.net > >> Subject: Integrated: 8243208: Clean up JVMFlag implementation > >> > >> On Tue, 8 Sep 2020 18:33:41 GMT, Ioi Lam wrote: > >> > >>> The initial commit > >> > [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee > >> 9a92d10e1ac19d9bb2f8) is the > >>> same patch as > >>> [8243208-cleanup-jvmflag- > >> impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup- > >> jvmflag-impl.v02/) > >>> published in > >>> [hotspot- > >> dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot- > >> dev/2020-September/042863.html). The > >>> rest of the review will continue on GitHub. I will add new commits to > >> respond to comments to the above e-mail. > >> > >> This pull request has now been integrated. > >> > >> Changeset: 5144190e > >> Author: Ioi Lam > >> URL: https://git.openjdk.java.net/jdk/commit/5144190e > >> Stats: 2127 lines in 45 files changed: 533 ins; 755 del; 839 mod > >> > >> 8243208: Clean up JVMFlag implementation > >> > >> Reviewed-by: dholmes, coleenp, gziemski > >> > >> ------------- > >> > >> PR: https://git.openjdk.java.net/jdk/pull/82 From david.holmes at oracle.com Mon Sep 14 07:19:20 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Sep 2020 17:19:20 +1000 Subject: Integrated: 8243208: Clean up JVMFlag implementation In-Reply-To: References: Message-ID: <0e5113fe-94fe-6471-ab80-94c9ff3358a8@oracle.com> On 14/09/2020 5:02 pm, Lindenmaier, Goetz wrote: > Hi David, > > It fails in the 32 and 64-bit build with the same message. We are building with VS2019, so may be a VS bug - possibly constExpr related. AFAICS line 54 is simply: constexpr JVMFlagLookup _flag_lookup_table; David > Best regards, > Goetz > > >> -----Original Message----- >> From: David Holmes >> Sent: Monday, September 14, 2020 8:45 AM >> To: Lindenmaier, Goetz ; Ioi Lam >> ; hotspot-dev at openjdk.java.net; shenandoah- >> dev at openjdk.java.net >> Subject: Re: Integrated: 8243208: Clean up JVMFlag implementation >> >> Hi Goetz, >> >> On 14/09/2020 4:13 pm, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> Since this change was pushed, we see the following build error on Windows: >>> .../src/hotspot/share/runtime/flags/jvmFlagLookup.cpp(54): error C2220: >> warning treated as error - no 'object' file generated >>> .../src/hotspot/share/runtime/flags/jvmFlagLookup.cpp(54): warning >> C4307: '*': integral constant overflow >>> >>> We are compiling with Microsoft Visual Studio 2017. >>> >>> (Is it the right way to write a mail to bring this up, or >>> should I comment the PullRequest or the like?) >> >> You can write a mail or just file a bug. :) >> >> Is this 32-bit Windows? We have not seen any issue in our 64-bit builds. >> >> Thanks, >> David >> >> >>> Best regards, >>> Goetz >>> >>>> -----Original Message----- >>>> From: hotspot-dev On Behalf Of >> Ioi >>>> Lam >>>> Sent: Friday, September 11, 2020 6:08 AM >>>> To: hotspot-dev at openjdk.java.net; shenandoah-dev at openjdk.java.net >>>> Subject: Integrated: 8243208: Clean up JVMFlag implementation >>>> >>>> On Tue, 8 Sep 2020 18:33:41 GMT, Ioi Lam wrote: >>>> >>>>> The initial commit >>>> >> [d85cbd6](https://github.com/openjdk/jdk/commit/d85cbd638f5b87c80eee >>>> 9a92d10e1ac19d9bb2f8) is the >>>>> same patch as >>>>> [8243208-cleanup-jvmflag- >>>> impl.v02](https://cr.openjdk.java.net/~iklam/jdk16/8243208-cleanup- >>>> jvmflag-impl.v02/) >>>>> published in >>>>> [hotspot- >>>> dev at openjdk.java.net](https://mail.openjdk.java.net/pipermail/hotspot- >>>> dev/2020-September/042863.html). The >>>>> rest of the review will continue on GitHub. I will add new commits to >>>> respond to comments to the above e-mail. >>>> >>>> This pull request has now been integrated. >>>> >>>> Changeset: 5144190e >>>> Author: Ioi Lam >>>> URL: https://git.openjdk.java.net/jdk/commit/5144190e >>>> Stats: 2127 lines in 45 files changed: 533 ins; 755 del; 839 mod >>>> >>>> 8243208: Clean up JVMFlag implementation >>>> >>>> Reviewed-by: dholmes, coleenp, gziemski >>>> >>>> ------------- >>>> >>>> PR: https://git.openjdk.java.net/jdk/pull/82 From iklam at openjdk.java.net Mon Sep 14 07:31:01 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 14 Sep 2020 07:31:01 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v6] In-Reply-To: References: <6RkbfFegd6pZ44iajJiHrorU2QL91PZApb08Rvp20Fk=.248ba4f6-7572-4cba-9cb8-781cbc192d26@github.com> Message-ID: On Thu, 10 Sep 2020 15:32:30 GMT, Gerard Ziemski wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes >> the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last >> revision: >> - Merge branch 'master' into 8243208-cleanup-jvmflag-impl >> - Minor code clean up suggested by David Holmes >> - Feedback by Gerard (hotspot-dev/2020-September/043019.html) >> - Refactored JVMFlagLookup::hash_code(); Cleaned up LimitGetter::no_limit() >> - Fixed JVMFlag::is_writeable() >> - (a) coding style nits and comments, (b) updated HOWTO in globals.hpp, (c) added JVMFlag::check_all_flag_declarations(), >> (d) removed product_rw which is not used by any flags >> - 8243208: Clean up JVMFlag implementation > > Marked as reviewed by gziemski (Committer). Maybe it's complaining about this "*" in jvmFlagLookup.hpp? How about this: static constexpr unsigned int hash_code(const char* s, size_t len) { unsigned int h = 0; while (len -- > 0) { - h = 31*h + (unsigned int) *s; + h = ((unsigned int)31)*h + (unsigned int) *s; s++; } return h; ------------- PR: https://git.openjdk.java.net/jdk/pull/82 From shade at openjdk.java.net Mon Sep 14 07:41:57 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 14 Sep 2020 07:41:57 GMT Subject: RFR: 8243208: Clean up JVMFlag implementation [v6] In-Reply-To: References: <6RkbfFegd6pZ44iajJiHrorU2QL91PZApb08Rvp20Fk=.248ba4f6-7572-4cba-9cb8-781cbc192d26@github.com> Message-ID: On Mon, 14 Sep 2020 07:28:07 GMT, Ioi Lam wrote: >> Marked as reviewed by gziemski (Committer). > > Maybe it's complaining about this "*" in jvmFlagLookup.hpp? How about this: > > static constexpr unsigned int hash_code(const char* s, size_t len) { > unsigned int h = 0; > while (len -- > 0) { > - h = 31*h + (unsigned int) *s; > + h = ((unsigned int)31)*h + (unsigned int) *s; > s++; > } > return h; Seeing Windows build failures on some of my Windows build nodes as well. Filed https://bugs.openjdk.java.net/browse/JDK-8253089, please discuss there. ------------- PR: https://git.openjdk.java.net/jdk/pull/82 From stefank at openjdk.java.net Mon Sep 14 07:43:02 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 14 Sep 2020 07:43:02 GMT Subject: RFR: 8247910: Improve alignment and power-of-2 utilities using C++14 In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 08:44:49 GMT, Kim Barrett wrote: > Please review this change which updates the alignment and power-of-2 > utilities (utilities/align.hpp and utilities/powerOfTwo.hpp) to use > C++14 features. > > Where possible, the alignment functions are now constexpr. This > eliminates the need for alternate macros that needed to be used in > constexpr contexts. > > Use and rather than HotSpot workalikes. > We no longer need max_value(), as the problematic platform for > std::numeric_limits::max() was Solaris. > > Testing: tier1 Looks good! ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/126 From dnsimon at openjdk.java.net Mon Sep 14 07:51:39 2020 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 14 Sep 2020 07:51:39 GMT Subject: Integrated: 8252898: remove bulk registration of JFR CompilerPhaseType names In-Reply-To: References: Message-ID: On Tue, 8 Sep 2020 15:07:04 GMT, Doug Simon wrote: > The changes made in [JDK-8193210](https://bugs.openjdk.java.net/browse/JDK-8193210) support only [bulk > registration](https://github.com/openjdk/jdk/blob/4e6a4af1866d0007d368b78bf78b6a8e1c8be425/src/hotspot/share/compiler/compilerEvent.hpp#L75) > of compiler phase names with JFR. However, Graal only registers compiler phase names upon first execution of the phase > since the set of phases is not known during VM initialization. This means registration of a Graal phase name needs to > do unnecessary work, wrapping a single name into an array to conform to the bulk registration API. This pull request > updates the registration API to be in terms of a registering a single phase name. This pull request has now been integrated. Changeset: b05290aa Author: Doug Simon URL: https://git.openjdk.java.net/jdk/commit/b05290aa Stats: 114 lines in 6 files changed: 43 ins; 31 del; 40 mod 8252898: remove bulk registration of JFR CompilerPhaseType names Reviewed-by: kvn, jcm ------------- PR: https://git.openjdk.java.net/jdk/pull/77 From stefank at openjdk.java.net Mon Sep 14 08:07:58 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 14 Sep 2020 08:07:58 GMT Subject: RFR: 8247909: Improve PrimitiveConversions::cast using C++14 In-Reply-To: <1BYMg9eOMQD2HA2MVjBpJ8BQeDmWXtI1LItGWlyTR5A=.6a00ed66-a78f-401e-935e-04e85a6d33f6@github.com> References: <1BYMg9eOMQD2HA2MVjBpJ8BQeDmWXtI1LItGWlyTR5A=.6a00ed66-a78f-401e-935e-04e85a6d33f6@github.com> Message-ID: <8AJobBLlL4dSJXE8Y_6qAuTDMQJw3-TeKOgcYPZr8Js=.328dcb78-59bb-4e7a-a243-f190e3b9f9d6@github.com> On Sun, 13 Sep 2020 07:27:13 GMT, Kim Barrett wrote: > Please review this reimplementation of PrimitiveConversions::cast, > using facilities from C++14. In particular, conversions involving > only integral values or integral and enum values are now constexpr. > Also using rather than HotSpot work-alikes. > > Had to update zForwardingEntry.hpp because of a class no longer being > implicitly included. Improved a friend declaration while in the > vicinity. > > Testing > mach5 tier1 I think this looks good. The patch updates ZForwardingEntry to use std::true_type. Why isn't that done for the handful other places where we use PrimitiveConversions::Translate? src/hotspot/share/metaprogramming/primitiveConversions.hpp line 35: > 33: class PrimitiveConversions : public AllStatic { > 34: > 35: // True if types are the same size and either is integral then int. I don't get the " then int." part. Is this from an earlier version using "enable if" with types? ------------- PR: https://git.openjdk.java.net/jdk/pull/143 From rrich at openjdk.java.net Mon Sep 14 08:18:04 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 14 Sep 2020 08:18:04 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: <59VhddIbMR3X24jGMsDpR_wOSWypMFIeXbs5l5rhLYs=.2c5e00e4-8b16-4237-8a7c-4cdceaaebe18@github.com> On Mon, 14 Sep 2020 04:57:21 GMT, David Holmes wrote: >> Hi, >> >> this is the continuation of the review of the implementation for: >> >> https://bugs.openjdk.java.net/browse/JDK-8227745 >> https://bugs.openjdk.java.net/browse/JDK-8233915 >> >> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references >> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such >> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka >> "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: >> >> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ >> >> Thanks, Richard. > > src/hotspot/share/compiler/compileBroker.cpp line 831: > >> 829: MonitorLocker ml(dt, EscapeBarrier_lock, Mutex::_no_safepoint_check_flag); >> 830: static int single_thread_count = 0; >> 831: enter_single_loop = single_thread_count++ < DeoptimizeObjectsALotThreadCountSingle; > > The update to `single_thread_count` is not atomic. I think it is atomic because it is never accessed without holding EscapeBarrier_lock ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From aph at redhat.com Mon Sep 14 08:37:39 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 14 Sep 2020 09:37:39 +0100 Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> Message-ID: On 12/09/2020 00:06, Jason Tatton wrote: > The current indexOf char intrinsics for StringUTF16 and the new one > here for StringLatin1 both use the AVX2 ? i.e. 256 bit instructions, > these are also affected by the frequency scaling which affects the > AVX-512 instructions you pointed out. Of course in a world where all > the work taking place is AVX instructions this wouldn?t be an issue > but in mixed mode execution this is a problem. Right. > However, the compiler does have knowledge of the capability of the > CPU upon which it?s optimizing code for and is able to decide > whether to use AVX instructions if they are supported by the CPU AND > if it wouldn?t be detrimental for performance. In fact, there is a > flag which one can use to interact with this: -XX:UseAVX=version. Sure. But the question to be answered is this: we can use AVX for this, but should we? "It's there, so we should use it" isn't sound reasoning. My guess is that there are no (non-FP) workloads where AVX dominates. And that therefore throwing AVX at trivial jobs may make our programs slower; this is a pessimization. I have to emphahsize that I don't know the answer to this question. > This of course made testing this patch an interesting experience as > the AVX2 instructions were not enabled on the Xeon processors which > I had access to at AWS, but in the end I was able to use an i7 on my > corporate macbook to validate the code. So: is this worth doing? Are there workloads where this helps? Where this hinders? This is the kind of systems thinking we should be doing when optimizing. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Sep 14 08:40:14 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 14 Sep 2020 09:40:14 +0100 Subject: RFR: 8252848: Optimize small primitive arrayCopy operations through partial inlining using AVX-512 masked instructions In-Reply-To: References: Message-ID: On 13/09/2020 20:12, Jatin Bhateja wrote: > 1) Partial in-lining technique avoids call overhead penalty for > sub-word type small array copy operations with size less than 32 > bytes. 2) At runtime, a conditional check based on copy length > either calls an array-copy stub or executes an optimized instruction > sequence using AVX-512 masked instructions emitted at the call site. This may not be a good idea. See my reply at https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/043114.html https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/043155.html -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From github.com+1981974+kuaiwei at openjdk.java.net Mon Sep 14 10:52:44 2020 From: github.com+1981974+kuaiwei at openjdk.java.net (kuaiwei) Date: Mon, 14 Sep 2020 10:52:44 GMT Subject: RFR: 8253049: Enhance itable_stub for AArch64 and x86_64 Message-ID: Now itable_stub will go through instanceKlass's itable twice to look up a method entry. resolved klass is used for type checking and method holder klass is used to find method entry. In many cases , we observed resolved klass is as same as holder klass. So we can improve itable stub based on it. If they are same klass, stub uses a fast loop to check only one klass. If not, a slow loop is used to checking both klasses. Even entering in slow loop, new implementation can be better than old one in some cases. Because new stub just need go through itable once and reduce memory operations. bug: https://bugs.openjdk.java.net/browse/JDK-8253049 ------------- Commit messages: - 8253049: Enhance itable_stub for AArch64 and x86_64 Changes: https://git.openjdk.java.net/jdk/pull/128/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=128&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253049 Stats: 220 lines in 7 files changed: 172 ins; 35 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/128.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/128/head:pull/128 PR: https://git.openjdk.java.net/jdk/pull/128 From vladimir.x.ivanov at oracle.com Mon Sep 14 12:25:16 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 14 Sep 2020 15:25:16 +0300 Subject: RFR: 8253049: Enhance itable_stub for AArch64 and x86_64 In-Reply-To: References: Message-ID: <7640e033-f590-0b63-79e3-59dd5b96f55f@oracle.com> Hi Kevin, Very interesting observations. I like the idea to optimize for the case when REFC == DECC. Fusing 2 passes over the itable into one does look attractive, but I'm not sure the proposed variant is correct. I suggest to split the patch into 2 enhancements and handle them separately. I'm curious what kind of benchmarks you used and what are the improvements observed with the patch. One suggestion about the implementation: src/hotspot/cpu/x86/macroAssembler_x86.cpp: +void MacroAssembler::lookup_interface_method_in_stub(Register recv_klass, I'd like to avoid having 2 independent implementations of itable lookup (MacroAssembler::lookup_interface_method_in_stub() and MacroAssembler::lookup_interface_method()). It would be nice to keep the implementation unified between itable and MethodHandle linkToInterface linker stubs. What MacroAssembler::lookup_interface_method(..., true /*return_method*/) does is interface method lookup w/o proper subtype check and it is equivalent to fast loop in MacroAssembler::lookup_interface_method_in_stub(). As a possible path forward, you could introduce the fast path check first by moving the fast path check into VtableStubs::create_itable_stub() and guard the first path over the itable. It would make the type checking pass over itable optional based on runtime check. Then you could refactor MacroAssembler::lookup_interface_method() to optionally do REFC and DECC checks on every iteration and migrate VtableStubs::create_itable_stub() and MethodHandles::generate_method_handle_dispatch() to it. Best regards, Vladimir Ivanov On 14.09.2020 13:52, kuaiwei wrote: > Now itable_stub will go through instanceKlass's itable twice to look up a method entry. resolved klass is used for type > checking and method holder klass is used to find method entry. In many cases , we observed resolved klass is as same as > holder klass. So we can improve itable stub based on it. If they are same klass, stub uses a fast loop to check only > one klass. If not, a slow loop is used to checking both klasses. > > Even entering in slow loop, new implementation can be better than old one in some cases. Because new stub just need go > through itable once and reduce memory operations. > > > bug: https://bugs.openjdk.java.net/browse/JDK-8253049 > > ------------- > > Commit messages: > - 8253049: Enhance itable_stub for AArch64 and x86_64 > > Changes: https://git.openjdk.java.net/jdk/pull/128/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=128&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8253049 > Stats: 220 lines in 7 files changed: 172 ins; 35 del; 13 mod > Patch: https://git.openjdk.java.net/jdk/pull/128.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/128/head:pull/128 > > PR: https://git.openjdk.java.net/jdk/pull/128 > From jbhateja at openjdk.java.net Mon Sep 14 13:18:39 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 14 Sep 2020 13:18:39 GMT Subject: RFR: 8252848: Optimize small primitive arrayCopy operations through partial inlining using AVX-512 masked instructions In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 05:01:24 GMT, Jatin Bhateja wrote: >> Adding a new product flag requires a CSR request to be filed. > >> /csr needed >> >> Adding a new product flag requires a CSR request to be filed. > > @dholmes-ora , with https://github.com/openjdk/jdk/commit/5144190e there has been a clean up of options and product > options now accept DIAGNOSTIC as an additional parameter. Newly added flag is a DIAGNOSTIC flag. > Mailing list message from Andrew Haley on hotspot-dev: > On 13/09/2020 20:12, Jatin Bhateja wrote: > > 1) Partial in-lining technique avoids call overhead penalty for > sub-word type small array copy operations with size less than 32 > bytes. 2) At runtime, a conditional check based on copy length > either calls an array-copy stub or executes an optimized instruction > sequence using AVX-512 masked instructions emitted at the call site. > > This may not be a good idea. See my reply at > https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/043114.html > https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/043155.html Frequency level switchover is sensitive to vector size, this has been taken care of by using a 32 byte vector masked operations in default mode. Default value of ArrayCopyPartialInlineSize is 32 i.e. copy sizes b/w 1-32 are partially in lined at the call site using masked vector moves operating over YMM registers. Only if user sets it to 64 we use ZMMs registers which forces a frequency level switch over to a lower frequency level (LVL1). So an AVX512 lite instruction working over a 32 byte vector (YMM) will operate a maximum frequency level (LVL0). > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 ------------- PR: https://git.openjdk.java.net/jdk/pull/144 From lucy at openjdk.java.net Mon Sep 14 13:32:48 2020 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Mon, 14 Sep 2020 13:32:48 GMT Subject: RFR: 8253029: Remove obsolete Power6 code In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 10:22:52 GMT, Martin Doerr wrote: > New pull request: > Using a branch, updated Copyright, removed some more unused code. > > [Previous text] > The recent PPC64 platform files still contain code which is part of a Power6 optimization called Power6Scheduler. > However, this functionality was never completely contributed so it was never usable in the OpenJDK. We should remove it > since we're no longer optimizing for Power6. Marked as reviewed by lucy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/127 From lucy at openjdk.java.net Mon Sep 14 13:32:48 2020 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Mon, 14 Sep 2020 13:32:48 GMT Subject: RFR: 8253029: Remove obsolete Power6 code In-Reply-To: References: Message-ID: <8As-OYOnCG0lRiH_Lg3eua_SP6JyONNLDzGt_TDqGMk=.4dbbe1de-6ea9-44a9-83f1-f92a1ee7bca6@github.com> On Mon, 14 Sep 2020 13:27:58 GMT, Lutz Schmidt wrote: >> New pull request: >> Using a branch, updated Copyright, removed some more unused code. >> >> [Previous text] >> The recent PPC64 platform files still contain code which is part of a Power6 optimization called Power6Scheduler. >> However, this functionality was never completely contributed so it was never usable in the OpenJDK. We should remove it >> since we're no longer optimizing for Power6. > > Marked as reviewed by lucy (Reviewer). Hi Martin, your changes look good to me. Thanks for the tedious comments removal! Not a task you been for. Best, Lutz ------------- PR: https://git.openjdk.java.net/jdk/pull/127 From mdoerr at openjdk.java.net Mon Sep 14 13:54:37 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 14 Sep 2020 13:54:37 GMT Subject: RFR: 8253029: Remove obsolete Power6 code In-Reply-To: <8As-OYOnCG0lRiH_Lg3eua_SP6JyONNLDzGt_TDqGMk=.4dbbe1de-6ea9-44a9-83f1-f92a1ee7bca6@github.com> References: <8As-OYOnCG0lRiH_Lg3eua_SP6JyONNLDzGt_TDqGMk=.4dbbe1de-6ea9-44a9-83f1-f92a1ee7bca6@github.com> Message-ID: On Mon, 14 Sep 2020 13:30:06 GMT, Lutz Schmidt wrote: >> Marked as reviewed by lucy (Reviewer). > > Hi Martin, > your changes look good to me. > Thanks for the tedious comments removal! Not a task you been for. > Best, > Lutz Thanks for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/127 From rrich at openjdk.java.net Mon Sep 14 14:45:23 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 14 Sep 2020 14:45:23 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: <8Lj5TsrafBhGgAbA8-w3VNsexX-mIzxLUOpXtL_5wJ0=.00530c0a-2187-4be6-97c2-5174815191b3@github.com> On Mon, 14 Sep 2020 04:58:47 GMT, David Holmes wrote: >> Hi, >> >> this is the continuation of the review of the implementation for: >> >> https://bugs.openjdk.java.net/browse/JDK-8227745 >> https://bugs.openjdk.java.net/browse/JDK-8233915 >> >> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references >> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such >> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka >> "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: >> >> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ >> >> Thanks, Richard. > > src/hotspot/share/compiler/compileBroker.cpp line 844: > >> 842: void DeoptimizeObjectsALotThread::deoptimize_objects_alot_loop_single() { >> 843: HandleMark hm(this); >> 844: while (!this->is_terminated()) { > > The terminated state of a thread is used to communicate to other threads whether this thread has terminated. It isn't > something that can be used to control the work-loop of the thread itself! This is an infinite loop as far as I can see. You're right. Thanks. I'll make it an explicit infinite loop. This should be ok because DeoptimizeObjectsALotThread's as the other threads created in CompileBroker::make_thread() are daemon threads. > src/hotspot/share/compiler/compileBroker.cpp line 862: > >> 860: void DeoptimizeObjectsALotThread::deoptimize_objects_alot_loop_all() { >> 861: HandleMark hm(this); >> 862: while (!is_terminated()) { > > Same comment as above. Same reply :) ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From luhenry at microsoft.com Mon Sep 14 16:31:38 2020 From: luhenry at microsoft.com (Ludovic Henry) Date: Mon, 14 Sep 2020 16:31:38 +0000 Subject: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: <2d74e89c-ae37-6862-b898-6872e56828cc@azul.com> References: <3834f328-d31f-0111-6ed3-afbe3fe3d9f7@redhat.com> <72a22b1b-2670-014d-8964-d08b0158fa46@azul.com> <2d74e89c-ae37-6862-b898-6872e56828cc@azul.com> Message-ID: Hi, > https://github.com/openjdk/jdk/compare/master...AntonKozlov:8253015 I confirm that this works with Windows-AArch64 with minimum changes. And I'm also much happier with this approach than with the "all in vm_version_aarch64.cpp" that we have taken so far. I am not a reviewer but I approve this change. Thank you, Ludovic From aph at redhat.com Mon Sep 14 16:43:53 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 14 Sep 2020 17:43:53 +0100 Subject: RFR: 8252848: Optimize small primitive arrayCopy operations through partial inlining using AVX-512 masked instructions In-Reply-To: References: Message-ID: <5fa811bb-59f2-1b33-0b87-1eb82e69c136@redhat.com> On 14/09/2020 14:18, Jatin Bhateja wrote: > Frequency level switchover is sensitive to vector size, this has > been taken care of by using a 32 byte vector masked operations in > default mode. > > Default value of ArrayCopyPartialInlineSize is 32 i.e. copy sizes > b/w 1-32 are partially in lined at the call site using masked vector > moves operating over YMM registers. Only if user sets it to 64 we > use ZMMs registers which forces a frequency level switch over to a > lower frequency level (LVL1). > > So an AVX512 lite instruction working over a 32 byte vector (YMM) > will operate a maximum frequency level (LVL0). OK, as long as you're keeping watch on this issue. We really do not want all Java workloads to be running at lower frequency or higher power just because of some intrinsics. Sure, if we're doing high-power vector calculations that's fine. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From mdoerr at openjdk.java.net Mon Sep 14 17:37:19 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 14 Sep 2020 17:37:19 GMT Subject: Integrated: 8253029: [PPC64] Remove obsolete Power6 code In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 10:22:52 GMT, Martin Doerr wrote: > New pull request: > Using a branch, updated Copyright, removed some more unused code. > > [Previous text] > The recent PPC64 platform files still contain code which is part of a Power6 optimization called Power6Scheduler. > However, this functionality was never completely contributed so it was never usable in the OpenJDK. We should remove it > since we're no longer optimizing for Power6. This pull request has now been integrated. Changeset: 9c24a563 Author: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/9c24a563 Stats: 936 lines in 5 files changed: 899 ins; 0 del; 37 mod 8253029: [PPC64] Remove obsolete Power6 code Reviewed-by: dholmes, lucy ------------- PR: https://git.openjdk.java.net/jdk/pull/127 From akozlov at openjdk.java.net Mon Sep 14 19:49:42 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 14 Sep 2020 19:49:42 GMT Subject: RFR: 8253015: Aarch64: Move linux code out from generic CPU feature detection Message-ID: Please review a change to remove Linux-specific code from hotspot/cpu/aarch64. The change is made to prepare for non-linux aarch64 platforms. vm_version no longer contains any "raw" values that were obtained directly from the platform registers. Some of them may be unavailable on certain architectures, like `ctr_el0` is not available on windows [1]. Few opportunities to improve linux code were taken: 1. `HWCAP_` flags now explicitly mapped to `CPU_` 2. `_dcpop` boolean was replaced with `CPU_DCPOP` 3. Code generation to get the platform register values was replaced with inline assembly. There is no a code buffer allocation anymore. Testing: * local hotspot tier1 * looking at detected features [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-September/009690.html ------------- Commit messages: - Reduce includes - Move linux code from aarch64 feature detection Changes: https://git.openjdk.java.net/jdk/pull/154/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=154&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253015 Stats: 372 lines in 7 files changed: 163 ins; 153 del; 56 mod Patch: https://git.openjdk.java.net/jdk/pull/154.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/154/head:pull/154 PR: https://git.openjdk.java.net/jdk/pull/154 From akozlov at azul.com Mon Sep 14 20:00:07 2020 From: akozlov at azul.com (Anton Kozlov) Date: Mon, 14 Sep 2020 23:00:07 +0300 Subject: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: <3834f328-d31f-0111-6ed3-afbe3fe3d9f7@redhat.com> <72a22b1b-2670-014d-8964-d08b0158fa46@azul.com> <2d74e89c-ae37-6862-b898-6872e56828cc@azul.com> Message-ID: <59e1c6fd-667b-e220-8a4f-2699079b0830@azul.com> On 14.09.2020 19:31, Ludovic Henry wrote: > I confirm that this works with Windows-AArch64 with minimum changes. And I'm also much happier with this approach than with the "all in vm_version_aarch64.cpp" that we have taken so far. > > I am not a reviewer but I approve this change. Thanks for looking. I've sent RFR as PR #154. -- Anton From luhenry at openjdk.java.net Mon Sep 14 20:09:37 2020 From: luhenry at openjdk.java.net (Ludovic Henry) Date: Mon, 14 Sep 2020 20:09:37 GMT Subject: RFR: 8253015: Aarch64: Move linux code out from generic CPU feature detection In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 19:42:21 GMT, Anton Kozlov wrote: > Please review a change to remove Linux-specific code from hotspot/cpu/aarch64. > > The change is made to prepare for non-linux aarch64 platforms. > > vm_version no longer contains any "raw" values that were obtained directly from the platform registers. Some of them > may be unavailable on certain architectures, like `ctr_el0` is not available on windows [1]. > Few opportunities to improve linux code were taken: > 1. `HWCAP_` flags now explicitly mapped to `CPU_` > 2. `_dcpop` boolean was replaced with `CPU_DCPOP` > 3. Code generation to get the platform register values was replaced with inline assembly. There is no a code buffer > allocation anymore. > Testing: > * local hotspot tier1 > * looking at detected features > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-September/009690.html I've verified that this code works for the Windows-AArch64 port with minimal changes to the new `vm_version_windows_aarch64.cpp` file. ------------- PR: https://git.openjdk.java.net/jdk/pull/154 From kim.barrett at oracle.com Mon Sep 14 22:06:58 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 14 Sep 2020 18:06:58 -0400 Subject: RFR: 8247910: Improve alignment and power-of-2 utilities using C++14 In-Reply-To: References: Message-ID: > On Sep 14, 2020, at 3:43 AM, Stefan Karlsson wrote: > > On Fri, 11 Sep 2020 08:44:49 GMT, Kim Barrett wrote: > >> Please review this change which updates the alignment and power-of-2 >> utilities (utilities/align.hpp and utilities/powerOfTwo.hpp) to use >> C++14 features. >> >> Where possible, the alignment functions are now constexpr. This >> eliminates the need for alternate macros that needed to be used in >> constexpr contexts. >> >> Use and rather than HotSpot workalikes. >> We no longer need max_value(), as the problematic platform for >> std::numeric_limits::max() was Solaris. >> >> Testing: tier1 > > Looks good! > > ------------- > > Marked as reviewed by stefank (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/126 Thanks. From david.holmes at oracle.com Tue Sep 15 01:35:12 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Sep 2020 11:35:12 +1000 Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: <59VhddIbMR3X24jGMsDpR_wOSWypMFIeXbs5l5rhLYs=.2c5e00e4-8b16-4237-8a7c-4cdceaaebe18@github.com> References: <59VhddIbMR3X24jGMsDpR_wOSWypMFIeXbs5l5rhLYs=.2c5e00e4-8b16-4237-8a7c-4cdceaaebe18@github.com> Message-ID: <1f5d5fb8-7d59-058d-e313-565dede697c3@oracle.com> On 14/09/2020 6:18 pm, Richard Reingruber wrote: > On Mon, 14 Sep 2020 04:57:21 GMT, David Holmes wrote: > >>> Hi, >>> >>> this is the continuation of the review of the implementation for: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8227745 >>> https://bugs.openjdk.java.net/browse/JDK-8233915 >>> >>> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references >>> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such >>> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka >>> "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: >>> >>> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ >>> >>> Thanks, Richard. >> >> src/hotspot/share/compiler/compileBroker.cpp line 831: >> >>> 829: MonitorLocker ml(dt, EscapeBarrier_lock, Mutex::_no_safepoint_check_flag); >>> 830: static int single_thread_count = 0; >>> 831: enter_single_loop = single_thread_count++ < DeoptimizeObjectsALotThreadCountSingle; >> >> The update to `single_thread_count` is not atomic. > > I think it is atomic because it is never accessed without holding EscapeBarrier_lock Doh! My bad. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/119 > From dholmes at openjdk.java.net Tue Sep 15 02:25:13 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 15 Sep 2020 02:25:13 GMT Subject: RFR: 8252848: Optimize small primitive arrayCopy operations through partial inlining using AVX-512 masked instructions In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 13:16:02 GMT, Jatin Bhateja wrote: >>> /csr needed >>> >>> Adding a new product flag requires a CSR request to be filed. >> >> @dholmes-ora , with https://github.com/openjdk/jdk/commit/5144190e there has been a clean up of options and product >> options now accept DIAGNOSTIC as an additional parameter. Newly added flag is a DIAGNOSTIC flag. > >> Mailing list message from Andrew Haley on hotspot-dev: >> On 13/09/2020 20:12, Jatin Bhateja wrote: >> >> 1) Partial in-lining technique avoids call overhead penalty for >> sub-word type small array copy operations with size less than 32 >> bytes. 2) At runtime, a conditional check based on copy length >> either calls an array-copy stub or executes an optimized instruction >> sequence using AVX-512 masked instructions emitted at the call site. >> >> This may not be a good idea. See my reply at >> https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/043114.html >> https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-September/043155.html > > Frequency level switchover is sensitive to vector size, this has been taken care of by using a 32 byte vector masked > operations in default mode. > Default value of ArrayCopyPartialInlineSize is 32 i.e. copy sizes b/w 1-32 are partially in lined at the call site > using masked vector moves operating over YMM registers. Only if user sets it to 64 we use ZMMs registers which forces > a frequency level switch over to a lower frequency level (LVL1). > So an AVX512 lite instruction working over a 32 byte vector (YMM) will operate a maximum frequency level (LVL0). > >> -- >> Andrew Haley (he/him) >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> https://keybase.io/andrewhaley >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > > > /csr needed > > Adding a new product flag requires a CSR request to be filed. > > @dholmes-ora , with [5144190](https://github.com/openjdk/jdk/commit/5144190e) there has been a clean up of options and > product options now accept DIAGNOSTIC as an additional parameter. Newly added flag is a DIAGNOSTIC flag. Apologies for that. Yes I got caught out by the new format. ------------- PR: https://git.openjdk.java.net/jdk/pull/144 From kbarrett at openjdk.java.net Tue Sep 15 04:37:20 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 15 Sep 2020 04:37:20 GMT Subject: Integrated: 8247910: Improve alignment and power-of-2 utilities using C++14 In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 08:44:49 GMT, Kim Barrett wrote: > Please review this change which updates the alignment and power-of-2 > utilities (utilities/align.hpp and utilities/powerOfTwo.hpp) to use > C++14 features. > > Where possible, the alignment functions are now constexpr. This > eliminates the need for alternate macros that needed to be used in > constexpr contexts. > > Use and rather than HotSpot workalikes. > We no longer need max_value(), as the problematic platform for > std::numeric_limits::max() was Solaris. > > Testing: tier1 This pull request has now been integrated. Changeset: af8c6780 Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/af8c6780 Stats: 288 lines in 12 files changed: 87 ins; 126 del; 75 mod 8247910: Improve alignment and power-of-2 utilities using C++14 8238956: Replace powerOfTwo::max_value with std::numeric_limits Reviewed-by: tschatzl, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/126 From iklam at openjdk.java.net Tue Sep 15 05:18:08 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 15 Sep 2020 05:18:08 GMT Subject: RFR: 8081833: Clean up JVMFlag getter/setter code Message-ID: This is a follow to [JDK-8243208 Clean up JVMFlag implementation](https://bugs.openjdk.java.net/browse/JDK-8243208). I try to use templates and inheritance (and a bit of macros) to get rid of the large amount of duplicated code in the JVMFlag getters/setters. Stefan Karlsson and I have tried this several times already, but I think the current attempt probably has the least amount of hacks and most functionality: - Type safety is enforced up to the point of loading/storing `JVMFlag::_addr`, without any unchecked typecasts. - Runtime type checking is implemented by the `JVM_FLAG_TYPE(t)` macro (see jvmFlagAccess.hpp), by passing along an integer (`JVMFlag::TYPE_int`, etc). This is more efficient than previous attempts that passed along a function pointer (see http://cr.openjdk.java.net/~stefank/8081833/webrev.04/) - The old `JVMFlag::xxxAtPut` functions were undocumented. There are actually two groups that have different usage. I added documentation in jvmFlagAccess.hpp to explain this. - I got rid of the `JVMFlagEx` class and moved the code into `JVMFlag`. This is possible with C++11 which allows forward declaration of `enum JVMFlagsEnum : int;` - I changed `JVMFlag::_type` from a string into an enum. I am surprised this had lasted for over 20 years. - I also changed `JVMFlag` from a struct into a class and made some fields private. I probably will do more cleanup in a separate RFE. Please start with jvmFlagAccess.hpp, jvmFlagAccess.hpp and then globals_extension.hpp. Probably not everyone is in love with the `JVM_FLAG_TYPE(t)` macro. I'll be happy to try out alternatives. ------------- Commit messages: - 8081833: Clean up JVMFlag getter/setter code Changes: https://git.openjdk.java.net/jdk/pull/163/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=163&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8081833 Stats: 2260 lines in 26 files changed: 668 ins; 1397 del; 195 mod Patch: https://git.openjdk.java.net/jdk/pull/163.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/163/head:pull/163 PR: https://git.openjdk.java.net/jdk/pull/163 From kbarrett at openjdk.java.net Tue Sep 15 06:49:33 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 15 Sep 2020 06:49:33 GMT Subject: RFR: 8253148: Fix terminology in align_down comment Message-ID: <-STw2HXgIUpfuGIZdNzsFcS05MTerCGgHtaWB30owWQ=.707b0a65-89c2-4cb8-9bb5-1c66f1a1270f@github.com> Please review this trivial terminology change in a comment. This was supposed to be part of JDK-8247910, but I forgot to push this comment change before integrating. ------------- Commit messages: - Change lognot => logical_not in comment Changes: https://git.openjdk.java.net/jdk/pull/166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=166&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253148 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/166/head:pull/166 PR: https://git.openjdk.java.net/jdk/pull/166 From shade at openjdk.java.net Tue Sep 15 07:00:28 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 15 Sep 2020 07:00:28 GMT Subject: RFR: 8253148: Fix terminology in align_down comment In-Reply-To: <-STw2HXgIUpfuGIZdNzsFcS05MTerCGgHtaWB30owWQ=.707b0a65-89c2-4cb8-9bb5-1c66f1a1270f@github.com> References: <-STw2HXgIUpfuGIZdNzsFcS05MTerCGgHtaWB30owWQ=.707b0a65-89c2-4cb8-9bb5-1c66f1a1270f@github.com> Message-ID: <59OJM7zjHYUtyHBSstVmbZlGNjCfYchvMbdKwHikVw0=.b83a647b-d028-46ca-a842-b68aca06b1ed@github.com> On Tue, 15 Sep 2020 06:40:41 GMT, Kim Barrett wrote: > Please review this trivial terminology change in a comment. This was supposed to be part of JDK-8247910, but I forgot > to push this comment change before integrating. Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/166 From kim.barrett at oracle.com Tue Sep 15 07:03:25 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 15 Sep 2020 03:03:25 -0400 Subject: RFR: 8081833: Clean up JVMFlag getter/setter code In-Reply-To: References: Message-ID: > On Sep 15, 2020, at 1:18 AM, Ioi Lam wrote: > > This is a follow to [JDK-8243208 Clean up JVMFlag implementation](https://bugs.openjdk.java.net/browse/JDK-8243208). > > [?] > Commit messages: > - 8081833: Clean up JVMFlag getter/setter code > > Changes: https://git.openjdk.java.net/jdk/pull/163/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=163&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8081833 > Stats: 2260 lines in 26 files changed: 668 ins; 1397 del; 195 mod > Patch: https://git.openjdk.java.net/jdk/pull/163.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/163/head:pull/163 > > PR: https://git.openjdk.java.net/jdk/pull/163 The webrev for this is broken by https://bugs.openjdk.java.net/browse/SKARA-619 See, for example, jvmFlagAccess.hpp lines 88, 98, and lines 103-110. From kim.barrett at oracle.com Tue Sep 15 07:05:10 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 15 Sep 2020 03:05:10 -0400 Subject: RFR: 8253148: Fix terminology in align_down comment In-Reply-To: <59OJM7zjHYUtyHBSstVmbZlGNjCfYchvMbdKwHikVw0=.b83a647b-d028-46ca-a842-b68aca06b1ed@github.com> References: <-STw2HXgIUpfuGIZdNzsFcS05MTerCGgHtaWB30owWQ=.707b0a65-89c2-4cb8-9bb5-1c66f1a1270f@github.com> <59OJM7zjHYUtyHBSstVmbZlGNjCfYchvMbdKwHikVw0=.b83a647b-d028-46ca-a842-b68aca06b1ed@github.com> Message-ID: <9042A61A-CA76-40F6-8D64-DCBC20D9AA30@oracle.com> > On Sep 15, 2020, at 3:00 AM, Aleksey Shipilev wrote: > > On Tue, 15 Sep 2020 06:40:41 GMT, Kim Barrett wrote: > >> Please review this trivial terminology change in a comment. This was supposed to be part of JDK-8247910, but I forgot >> to push this comment change before integrating. > > Marked as reviewed by shade (Reviewer). > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/166 Thanks. From kbarrett at openjdk.java.net Tue Sep 15 07:10:48 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 15 Sep 2020 07:10:48 GMT Subject: Integrated: 8253148: Fix terminology in align_down comment In-Reply-To: <-STw2HXgIUpfuGIZdNzsFcS05MTerCGgHtaWB30owWQ=.707b0a65-89c2-4cb8-9bb5-1c66f1a1270f@github.com> References: <-STw2HXgIUpfuGIZdNzsFcS05MTerCGgHtaWB30owWQ=.707b0a65-89c2-4cb8-9bb5-1c66f1a1270f@github.com> Message-ID: On Tue, 15 Sep 2020 06:40:41 GMT, Kim Barrett wrote: > Please review this trivial terminology change in a comment. This was supposed to be part of JDK-8247910, but I forgot > to push this comment change before integrating. This pull request has now been integrated. Changeset: 9ea43a92 Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/9ea43a92 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8253148: Fix terminology in align_down comment Change lognot => logical_not in comment Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/166 From github.com+1981974+kuaiwei at openjdk.java.net Tue Sep 15 07:14:32 2020 From: github.com+1981974+kuaiwei at openjdk.java.net (kuaiwei) Date: Tue, 15 Sep 2020 07:14:32 GMT Subject: RFR: 8253049: Enhance itable_stub for AArch64 and x86_64 [v2] In-Reply-To: References: Message-ID: > Now itable_stub will go through instanceKlass's itable twice to look up a method entry. resolved klass is used for type > checking and method holder klass is used to find method entry. In many cases , we observed resolved klass is as same as > holder klass. So we can improve itable stub based on it. If they are same klass, stub uses a fast loop to check only > one klass. If not, a slow loop is used to checking both klasses. Even entering in slow loop, new implementation can be > better than old one in some cases. Because new stub just need go through itable once and reduce memory operations. > bug: https://bugs.openjdk.java.net/browse/JDK-8253049 kuaiwei has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8253049: Enhance itable_stub for AArch64 and x86_64 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/128/files - new: https://git.openjdk.java.net/jdk/pull/128/files/b2f12ccc..6d79d5ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=128&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=128&range=00-01 Stats: 126 lines in 1 file changed: 126 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/128.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/128/head:pull/128 PR: https://git.openjdk.java.net/jdk/pull/128 From kim.barrett at oracle.com Tue Sep 15 07:34:37 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 15 Sep 2020 03:34:37 -0400 Subject: RFR: 8247909: Improve PrimitiveConversions::cast using C++14 In-Reply-To: <8AJobBLlL4dSJXE8Y_6qAuTDMQJw3-TeKOgcYPZr8Js=.328dcb78-59bb-4e7a-a243-f190e3b9f9d6@github.com> References: <1BYMg9eOMQD2HA2MVjBpJ8BQeDmWXtI1LItGWlyTR5A=.6a00ed66-a78f-401e-935e-04e85a6d33f6@github.com> <8AJobBLlL4dSJXE8Y_6qAuTDMQJw3-TeKOgcYPZr8Js=.328dcb78-59bb-4e7a-a243-f190e3b9f9d6@github.com> Message-ID: <5562C78E-488A-477C-BADE-0DFC3B67A1D2@oracle.com> > On Sep 14, 2020, at 4:07 AM, Stefan Karlsson wrote: > > On Sun, 13 Sep 2020 07:27:13 GMT, Kim Barrett wrote: > >> Please review this reimplementation of PrimitiveConversions::cast, >> using facilities from C++14. In particular, conversions involving >> only integral values or integral and enum values are now constexpr. >> Also using rather than HotSpot work-alikes. >> >> Had to update zForwardingEntry.hpp because of a class no longer being >> implicitly included. Improved a friend declaration while in the >> vicinity. >> >> Testing >> mach5 tier1 > > I think this looks good. Thanks. > The patch updates ZForwardingEntry to use std::true_type. Why isn't that done for the handful > other places where we use PrimitiveConversions::Translate? zForwardingEntry.hpp needed to be touched to address the dependency on integralConstant.hpp, which is no longer included by primitiveConversions.hpp. Other uses of PrimitiveConversions::Translate didn't run into that problem for one reason or another. I have a collection of other C++11/14-based changes still to be worked through, including some that change the HotSpot workalikes for various type traits. In some cases they might be eliminated, replacing uses with facilities. In other cases where there are many uses we might reimplement them using and incrementally replace uses. Changing the base class for PrimitiveConversions::Translate specializations is somewhere in there. > src/hotspot/share/metaprogramming/primitiveConversions.hpp line 35: > >> 33: class PrimitiveConversions : public AllStatic { >> 34: >> 35: // True if types are the same size and either is integral then int. > > I don't get the " then int." part. Is this from an earlier version using "enable if" with types? Well spotted; your guess is correct. I?ll delete that phrase. > PR: https://git.openjdk.java.net/jdk/pull/143 From kuaiwei.kw at alibaba-inc.com Tue Sep 15 07:38:33 2020 From: kuaiwei.kw at alibaba-inc.com (Kuai Wei) Date: Tue, 15 Sep 2020 15:38:33 +0800 Subject: =?UTF-8?B?UmU6IFJGUjogODI1MzA0OTogRW5oYW5jZSBpdGFibGVfc3R1YiBmb3IgQUFyY2g2NCBhbmQg?= =?UTF-8?B?eDg2XzY0?= In-Reply-To: <7640e033-f590-0b63-79e3-59dd5b96f55f@oracle.com> References: , <7640e033-f590-0b63-79e3-59dd5b96f55f@oracle.com> Message-ID: <522cf585-60c4-4662-bbbd-d51158d11f3a.kuaiwei.kw@alibaba-inc.com> Hi Vladimir, Thanks for your review. I updated my test cases in test/micro/org/openjdk/bench/vm/compiler/InterfaceCalls.java . My tests will not inline interface methods and most cpu are used by itable_stub. every test will run 10 warmup iterations and 5 measure iterations for one score. I took 3 score for every test. Below is test result on my machines, it looks slow loop has more improvement than origin one. aarch64: === testStubPoly3 === orig: 38430308.215 38438769.040 38325616.152 opt : 39425275.311 39626194.985 39374242.065 === testStubPoly5 === orig: 23227433.053 23210843.937 23212518.073 opt : 23805995.657 23797837.061 23861764.978 === testSlowStubPoly3 === orig: 30838750.839 30886603.202 30841314.152 opt : 36166775.967 36242733.807 36041506.263 === testSlowStubPoly5 === orig: 18713218.115 18706994.686 18686729.040 opt : 21827549.808 21836822.173 21861920.069 x86: === testStubPoly3 === orig: 36339726.912 36322863.060 36363196.132 opt : 38631086.341 38465649.400 38466044.926 === testStubPoly5 === orig: 22240149.674 22218724.450 22225970.358 opt : 23498941.840 23454580.221 23497053.570 === testSlowStubPoly3 === orig: 28693696.199 28700714.257 28587900.429 opt : 34187319.519 34171321.762 34138648.599 === testSlowStubPoly5 === orig: 17388480.977 17389247.386 17177206.666 opt : 20697609.518 20771108.051 20699215.655 I think lookup_interface_method can be reused as fast path. And it is also used by templateTable::invoke_interface and generate_method_handle_dispatch. My implementation in slow path need more registers (6 registers so far), I need to check if there's register conflict in these methods. I'd like to keep a separate slow path implementation. How do you think about it? Thanks, Kevin ------------------------------------------------------------------ From:Vladimir Ivanov Send Time:2020?9?14?(???) 22:10 To:kuaiwei ; hotspot-dev ; hotspot-compiler-dev Subject:Re: RFR: 8253049: Enhance itable_stub for AArch64 and x86_64 Hi Kevin, Very interesting observations. I like the idea to optimize for the case when REFC == DECC. Fusing 2 passes over the itable into one does look attractive, but I'm not sure the proposed variant is correct. I suggest to split the patch into 2 enhancements and handle them separately. I'm curious what kind of benchmarks you used and what are the improvements observed with the patch. One suggestion about the implementation: src/hotspot/cpu/x86/macroAssembler_x86.cpp: +void MacroAssembler::lookup_interface_method_in_stub(Register recv_klass, I'd like to avoid having 2 independent implementations of itable lookup (MacroAssembler::lookup_interface_method_in_stub() and MacroAssembler::lookup_interface_method()). It would be nice to keep the implementation unified between itable and MethodHandle linkToInterface linker stubs. What MacroAssembler::lookup_interface_method(..., true /*return_method*/) does is interface method lookup w/o proper subtype check and it is equivalent to fast loop in MacroAssembler::lookup_interface_method_in_stub(). As a possible path forward, you could introduce the fast path check first by moving the fast path check into VtableStubs::create_itable_stub() and guard the first path over the itable. It would make the type checking pass over itable optional based on runtime check. Then you could refactor MacroAssembler::lookup_interface_method() to optionally do REFC and DECC checks on every iteration and migrate VtableStubs::create_itable_stub() and MethodHandles::generate_method_handle_dispatch() to it. Best regards, Vladimir Ivanov On 14.09.2020 13:52, kuaiwei wrote: > Now itable_stub will go through instanceKlass's itable twice to look up a method entry. resolved klass is used for type > checking and method holder klass is used to find method entry. In many cases , we observed resolved klass is as same as > holder klass. So we can improve itable stub based on it. If they are same klass, stub uses a fast loop to check only > one klass. If not, a slow loop is used to checking both klasses. > > Even entering in slow loop, new implementation can be better than old one in some cases. Because new stub just need go > through itable once and reduce memory operations. > > > bug: https://bugs.openjdk.java.net/browse/JDK-8253049 > > ------------- > > Commit messages: > - 8253049: Enhance itable_stub for AArch64 and x86_64 > > Changes: https://git.openjdk.java.net/jdk/pull/128/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=128&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8253049 > Stats: 220 lines in 7 files changed: 172 ins; 35 del; 13 mod > Patch: https://git.openjdk.java.net/jdk/pull/128.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/128/head:pull/128 > > PR: https://git.openjdk.java.net/jdk/pull/128 > From rehn at openjdk.java.net Tue Sep 15 07:39:56 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 15 Sep 2020 07:39:56 GMT Subject: RFR: 8238761: Asynchronous handshakes Message-ID: This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there is now only one method to call when handshaking one thread. Some comments about the changes: - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much worse then this. - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that thread. - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. - Added WB testing method. - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a safepoint and half of them after, in many handshake all operations. - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to the NoSafepointVerifyer. - Added filtered queue and gtest for it. Passes multiple t1-8 runs. Been through some pre-reviwing. ------------- Commit messages: - Rebase version 1.0 Changes: https://git.openjdk.java.net/jdk/pull/151/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=151&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8238761 Stats: 1047 lines in 24 files changed: 693 ins; 150 del; 204 mod Patch: https://git.openjdk.java.net/jdk/pull/151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/151/head:pull/151 PR: https://git.openjdk.java.net/jdk/pull/151 From kbarrett at openjdk.java.net Tue Sep 15 07:40:16 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 15 Sep 2020 07:40:16 GMT Subject: RFR: 8247909: Improve PrimitiveConversions::cast using C++14 [v2] In-Reply-To: <1BYMg9eOMQD2HA2MVjBpJ8BQeDmWXtI1LItGWlyTR5A=.6a00ed66-a78f-401e-935e-04e85a6d33f6@github.com> References: <1BYMg9eOMQD2HA2MVjBpJ8BQeDmWXtI1LItGWlyTR5A=.6a00ed66-a78f-401e-935e-04e85a6d33f6@github.com> Message-ID: > Please review this reimplementation of PrimitiveConversions::cast, > using facilities from C++14. In particular, conversions involving > only integral values or integral and enum values are now constexpr. > Also using rather than HotSpot work-alikes. > > Had to update zForwardingEntry.hpp because of a class no longer being > implicitly included. Improved a friend declaration while in the > vicinity. > > Testing > mach5 tier1 Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: fix comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/143/files - new: https://git.openjdk.java.net/jdk/pull/143/files/105932c1..f451696d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=143&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=143&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/143.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/143/head:pull/143 PR: https://git.openjdk.java.net/jdk/pull/143 From ayang at openjdk.java.net Tue Sep 15 07:53:14 2020 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 15 Sep 2020 07:53:14 GMT Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space [v2] In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 09:01:18 GMT, Kim Barrett wrote: >> This is rework of initial change from before the transition to git. >> The initial RFR email is attached below. >> >> The primary change is to limit the number of partial array tasks in >> the queues for any given array. The original change just split up an >> array into N tasks that were all enqueued at once. But for a large >> array this could be a lot of tasks, leading to significant and >> unnecessary queue expansion. Instead we now limit the number of tasks >> for a given array based on the number of workers, and only gradually >> add tasks up to that limit. This gives other threads an opportunity >> to steal such tasks, while still keeping queue growth under control. >> >> Most of the calculation for this is handled by a new helper class, so >> this can later be shared with ParallelGC. >> >> The dispatch on array klass type for has also been changed. It now >> affirmatively breaks Project Valhalla, rather than quietly doing >> something that probably isn't what is actually wanted. I'll discuss >> with them so there is a plan for dealing with it when they take this >> update. >> >> Ran tier1-6 in mach5 and some local stress tests. >> >> Performance testing was unchanged from previous, except I wasn't able >> to reproduce the small specjbb2015 critical-jops improvement >> previously seen on one platform. My suspicion is that improvement was >> a statistical abberation. >> >> --- Initial RFR email --- >> >> RFR: 8158045: Improve large object handling during evacuation >> RFR: 8027761: Investigate fast-path for scanning only objects with references during gc >> RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space >> >> Please review this change to type dispatching and handling in G1's >> evacuation copying, in order to improve the hot paths and improve array >> handling. This change addresses several closely co-located enhancement >> requests; it seemed difficult to split them up in a sensible way. >> >> do_copy_to_survivor_space now gets the klass of the object being copied >> once, up front, for use in multiple places. This avoids fetching (including >> re-decoding when compressed) the klass multiple times. This addresses part >> of JDK-8027545. >> >> Moved check for and handling of string deduplication later, only applying it >> after the special array cases have been dealt with, since strings are not >> arrays. (They are header objects pointing to an array of character values.) >> >> Special case typeArray, doing nothing other than the copy, since they >> contain no oops that need to be processed. This addresses JDK-8027761. >> >> Changed handling of objArray, pushing all of the partial array tasks up >> front, rather than processing the current chunk after pushing a single task >> for the remaining work. This addresses JDK-8158045. >> >> As part of these, cached some more frequently accessed values in >> G1ParScanThreadState member variables. This addresses part of part of >> JDK-8027545. >> >> While both the old and new code will work for Project Valhalla, the handling >> of arrays should be updated for that project, which introduces new array >> types. >> >> Deleted a lingering reference to G1ParScanPartialArrayClosure that was >> deleted long ago (JDK-8035330, JDK 9). >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8158045 >> https://bugs.openjdk.java.net/browse/JDK-8027761 >> https://bugs.openjdk.java.net/browse/JDK-8027545 >> >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ >> >> Testing: >> tier1-3 >> >> performance testing - seems to be at worst performance neutral, with a >> statistically significant 3% improvement in specjbb2015 critical-jops seen >> on one platform. > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > Respond to reviews by ayang and sjohanss. Marked as reviewed by ayang (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/90 From kbarrett at openjdk.java.net Tue Sep 15 08:13:10 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 15 Sep 2020 08:13:10 GMT Subject: RFR: 8247909: Improve PrimitiveConversions::cast using C++14 [v3] In-Reply-To: <1BYMg9eOMQD2HA2MVjBpJ8BQeDmWXtI1LItGWlyTR5A=.6a00ed66-a78f-401e-935e-04e85a6d33f6@github.com> References: <1BYMg9eOMQD2HA2MVjBpJ8BQeDmWXtI1LItGWlyTR5A=.6a00ed66-a78f-401e-935e-04e85a6d33f6@github.com> Message-ID: > Please review this reimplementation of PrimitiveConversions::cast, > using facilities from C++14. In particular, conversions involving > only integral values or integral and enum values are now constexpr. > Also using rather than HotSpot work-alikes. > > Had to update zForwardingEntry.hpp because of a class no longer being > implicitly included. Improved a friend declaration while in the > vicinity. > > Testing > mach5 tier1 Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: fix implict dependency by test on integralConstant.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/143/files - new: https://git.openjdk.java.net/jdk/pull/143/files/f451696d..c55dfce8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=143&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=143&range=01-02 Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/143.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/143/head:pull/143 PR: https://git.openjdk.java.net/jdk/pull/143 From jcm at openjdk.java.net Tue Sep 15 08:41:26 2020 From: jcm at openjdk.java.net (Jamsheed Mohammed C M) Date: Tue, 15 Sep 2020 08:41:26 GMT Subject: RFR: 8249451: Unconditional exceptions clearing logic in compiler code should honor Async Exceptions. Message-ID: <2zjS36Nz0zH4AorRbppunfKPFkciaMD865WyBdMzOFI=.fc7a6fd1-96b4-4769-ab0b-b71e7f5bdc9b@github.com> Hi Moving the review that is based on mercurial repo to github. The history of conversation is [here](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039861.html) Issue:[ JDK-8249451 ](https://bugs.openjdk.java.net/browse/JDK-8249451) @dholmes-ora could you please have a look. ------------- Commit messages: - webrev.03 Changes: https://git.openjdk.java.net/jdk/pull/169/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=169&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249451 Stats: 217 lines in 20 files changed: 104 ins; 38 del; 75 mod Patch: https://git.openjdk.java.net/jdk/pull/169.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/169/head:pull/169 PR: https://git.openjdk.java.net/jdk/pull/169 From vladimir.x.ivanov at oracle.com Tue Sep 15 09:02:49 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 15 Sep 2020 12:02:49 +0300 Subject: RFR: 8253049: Enhance itable_stub for AArch64 and x86_64 In-Reply-To: <522cf585-60c4-4662-bbbd-d51158d11f3a.kuaiwei.kw@alibaba-inc.com> References: <7640e033-f590-0b63-79e3-59dd5b96f55f@oracle.com> <522cf585-60c4-4662-bbbd-d51158d11f3a.kuaiwei.kw@alibaba-inc.com> Message-ID: <08236fa7-213b-a84f-a927-59b74baee5d8@oracle.com> > I updated my test cases in test/micro/org/openjdk/bench/vm/compiler/InterfaceCalls.java . My tests will not inline interface methods and most cpu are used by itable_stub. > every test will run 10 warmup iterations and 5 measure iterations for one score. I took 3 score for every test. > Below is test result on my machines, it looks slow loop has more improvement than origin one. Good, thanks for the numbers. I'm curious have you observed any improvements on larger scale benchmarks or real world apps? I'm asking because linear scan is already far from optimal when there are many superinterfaces present. > I think lookup_interface_method can be reused as fast path. And it is also used by templateTable::invoke_interface and generate_method_handle_dispatch. > My implementation in slow path need more registers (6 registers so far), I need to check if there's register conflict in these methods. I'd like to keep a separate > slow path implementation. How do you think about it? Frankly speaking, I'd like to avoid the duplication. Also, absence of guarantees about order of interfaces in the itable complicates things: REFC and DECC can be encountered in arbitrary order and the pass should take that into account. For example, I don't see early exit on success in slow variant, so every lookup has to go through the whole itable irrespective of whether it succeeds or fails. I attribute that to the complications induced by aforementioned aspect. And speaking of the overall approach (as it is implemented now), IMO increased complexity doesn't worth it. If interface calls become a bottleneck, the problem lies not in itable stub, but the overall design which requires linear scan over itables. It's better to put the effort there than micro-optimizing the stub. But I'm happy to change my mind if the rewritten implementation makes it easier to reason about the code. (FTR subtype checks suffer from a similar problem: unless Klass::_secondary_super_cache catches it, subtype check for an interface does a linear scan over _secondary_supers array.) Best regards, Vladimir Ivanov > ------------------------------------------------------------------ > From:Vladimir Ivanov > Send Time:2020?9?14?(???) 22:10 > To:kuaiwei ; hotspot-dev ; hotspot-compiler-dev > Subject:Re: RFR: 8253049: Enhance itable_stub for AArch64 and x86_64 > > Hi Kevin, > > Very interesting observations. I like the idea to optimize for the case > when REFC == DECC. > > Fusing 2 passes over the itable into one does look attractive, but I'm > not sure the proposed variant is correct. I suggest to split the patch > into 2 enhancements and handle them separately. > > I'm curious what kind of benchmarks you used and what are the > improvements observed with the patch. > > One suggestion about the implementation: > > src/hotspot/cpu/x86/macroAssembler_x86.cpp: > > +void MacroAssembler::lookup_interface_method_in_stub(Register recv_klass, > > I'd like to avoid having 2 independent implementations of itable lookup > (MacroAssembler::lookup_interface_method_in_stub() and > MacroAssembler::lookup_interface_method()). It would be nice to keep the > implementation unified between itable and MethodHandle linkToInterface > linker stubs. > > What MacroAssembler::lookup_interface_method(..., true > /*return_method*/) does is interface method lookup w/o proper subtype > check and it is equivalent to fast loop in > MacroAssembler::lookup_interface_method_in_stub(). > > As a possible path forward, you could introduce the fast path check > first by moving the fast path check into > VtableStubs::create_itable_stub() and guard the first path over the > itable. It would make the type checking pass over itable optional based > on runtime check. > > Then you could refactor MacroAssembler::lookup_interface_method() to > optionally do REFC and DECC checks on every iteration and migrate > VtableStubs::create_itable_stub() and > MethodHandles::generate_method_handle_dispatch() to it. > > Best regards, > Vladimir Ivanov > > On 14.09.2020 13:52, kuaiwei wrote: >> Now itable_stub will go through instanceKlass's itable twice to look up a method entry. resolved klass is used for type >> checking and method holder klass is used to find method entry. In many cases , we observed resolved klass is as same as >> holder klass. So we can improve itable stub based on it. If they are same klass, stub uses a fast loop to check only >> one klass. If not, a slow loop is used to checking both klasses. >> >> Even entering in slow loop, new implementation can be better than old one in some cases. Because new stub just need go >> through itable once and reduce memory operations. >> >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8253049 >> >> ------------- >> >> Commit messages: >> - 8253049: Enhance itable_stub for AArch64 and x86_64 >> >> Changes: https://git.openjdk.java.net/jdk/pull/128/files >> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=128&range=00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8253049 >> Stats: 220 lines in 7 files changed: 172 ins; 35 del; 13 mod >> Patch: https://git.openjdk.java.net/jdk/pull/128.diff >> Fetch: git fetch https://git.openjdk.java.net/jdk pull/128/head:pull/128 >> >> PR: https://git.openjdk.java.net/jdk/pull/128 >> > From aph at redhat.com Tue Sep 15 09:13:58 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 15 Sep 2020 10:13:58 +0100 Subject: RFR: 8253049: Enhance itable_stub for AArch64 and x86_64 In-Reply-To: <08236fa7-213b-a84f-a927-59b74baee5d8@oracle.com> References: <7640e033-f590-0b63-79e3-59dd5b96f55f@oracle.com> <522cf585-60c4-4662-bbbd-d51158d11f3a.kuaiwei.kw@alibaba-inc.com> <08236fa7-213b-a84f-a927-59b74baee5d8@oracle.com> Message-ID: On 15/09/2020 10:02, Vladimir Ivanov wrote: > And speaking of the overall approach (as it is implemented now), IMO > increased complexity doesn't worth it. If interface calls become a > bottleneck, the problem lies not in itable stub, but the overall design > which requires linear scan over itables. It's better to put the effort > there than micro-optimizing the stub. Indeed. When I first came to HotSpot after working on GCJ for years I was very surprised to see a linear scan used for interface dispatch. The code improvements look to be fairly minor. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.schatzl at oracle.com Tue Sep 15 09:35:27 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 15 Sep 2020 11:35:27 +0200 Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space [v2] In-Reply-To: References: Message-ID: Hi, On 12.09.20 03:02, Kim Barrett wrote: >> On Sep 11, 2020, at 8:50 AM, Thomas Schatzl wrote: >> >> Hi, >> >> On 11.09.20 11:01, Kim Barrett wrote: >> [...] >>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >>> Respond to reviews by ayang and sjohanss. >>> >>> Changes: >>> - all: https://git.openjdk.java.net/jdk/pull/90/files >>> - new: https://git.openjdk.java.net/jdk/pull/90/files/9397514e..1981c392 >>> Webrevs: >>> - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=90&range=01 >>> - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=90&range=00-01 >>> Stats: 152 lines in 6 files changed: 122 ins; 14 del; 16 mod >>> Patch: https://git.openjdk.java.net/jdk/pull/90.diff >>> Fetch: git fetch https://git.openjdk.java.net/jdk pull/90/head:pull/90 >>> PR: https://git.openjdk.java.net/jdk/pull/90 >> >> - partialArrayTaskStepper.hpp: >> >> s/_task_fannout/_task_fanout (or maybe _task_fan_out) > > I thought it looked a little odd at first, but never got around to spell > checking it, and after a while it looked fine by familiarity. Will fix > ("fanout"). > >> - since _task_fannout and _task_limit are only assigned in the constructor of PartialArrayTaskStepper, maybe make them const? > > I'd rather not. I've been down that road and didn't like the results. Just > as an example, doing that sort of thing renders a class copyable but not > assignable, swappable, or (in some cases) moveable from. That's an odd > combination. I already (though recently) made start() and next() const. > >> - also the asserts in PartialArrayTaskStepper::next_impl could be moved to the constructor initialization list but otoh the fannout > 0 assert does make the calculation below immediately obviously safe. > > As you say, the current location shows the requirements for the nearby > calculations. > >> Looks good otherwise. Okay. Going to mark this as reviewed assuming the rename will be done. Thanks, Thomas From tschatzl at openjdk.java.net Tue Sep 15 09:38:57 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 15 Sep 2020 09:38:57 GMT Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space [v2] In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 09:01:18 GMT, Kim Barrett wrote: >> This is rework of initial change from before the transition to git. >> The initial RFR email is attached below. >> >> The primary change is to limit the number of partial array tasks in >> the queues for any given array. The original change just split up an >> array into N tasks that were all enqueued at once. But for a large >> array this could be a lot of tasks, leading to significant and >> unnecessary queue expansion. Instead we now limit the number of tasks >> for a given array based on the number of workers, and only gradually >> add tasks up to that limit. This gives other threads an opportunity >> to steal such tasks, while still keeping queue growth under control. >> >> Most of the calculation for this is handled by a new helper class, so >> this can later be shared with ParallelGC. >> >> The dispatch on array klass type for has also been changed. It now >> affirmatively breaks Project Valhalla, rather than quietly doing >> something that probably isn't what is actually wanted. I'll discuss >> with them so there is a plan for dealing with it when they take this >> update. >> >> Ran tier1-6 in mach5 and some local stress tests. >> >> Performance testing was unchanged from previous, except I wasn't able >> to reproduce the small specjbb2015 critical-jops improvement >> previously seen on one platform. My suspicion is that improvement was >> a statistical abberation. >> >> --- Initial RFR email --- >> >> RFR: 8158045: Improve large object handling during evacuation >> RFR: 8027761: Investigate fast-path for scanning only objects with references during gc >> RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space >> >> Please review this change to type dispatching and handling in G1's >> evacuation copying, in order to improve the hot paths and improve array >> handling. This change addresses several closely co-located enhancement >> requests; it seemed difficult to split them up in a sensible way. >> >> do_copy_to_survivor_space now gets the klass of the object being copied >> once, up front, for use in multiple places. This avoids fetching (including >> re-decoding when compressed) the klass multiple times. This addresses part >> of JDK-8027545. >> >> Moved check for and handling of string deduplication later, only applying it >> after the special array cases have been dealt with, since strings are not >> arrays. (They are header objects pointing to an array of character values.) >> >> Special case typeArray, doing nothing other than the copy, since they >> contain no oops that need to be processed. This addresses JDK-8027761. >> >> Changed handling of objArray, pushing all of the partial array tasks up >> front, rather than processing the current chunk after pushing a single task >> for the remaining work. This addresses JDK-8158045. >> >> As part of these, cached some more frequently accessed values in >> G1ParScanThreadState member variables. This addresses part of part of >> JDK-8027545. >> >> While both the old and new code will work for Project Valhalla, the handling >> of arrays should be updated for that project, which introduces new array >> types. >> >> Deleted a lingering reference to G1ParScanPartialArrayClosure that was >> deleted long ago (JDK-8035330, JDK 9). >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8158045 >> https://bugs.openjdk.java.net/browse/JDK-8027761 >> https://bugs.openjdk.java.net/browse/JDK-8027545 >> >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ >> >> Testing: >> tier1-3 >> >> performance testing - seems to be at worst performance neutral, with a >> statistically significant 3% improvement in specjbb2015 critical-jops seen >> on one platform. > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > Respond to reviews by ayang and sjohanss. Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/90 From kuaiwei.kw at alibaba-inc.com Tue Sep 15 10:04:10 2020 From: kuaiwei.kw at alibaba-inc.com (Kuai Wei) Date: Tue, 15 Sep 2020 18:04:10 +0800 Subject: =?UTF-8?B?UmU6IFJGUjogODI1MzA0OTogRW5oYW5jZSBpdGFibGVfc3R1YiBmb3IgQUFyY2g2NCBhbmQg?= =?UTF-8?B?eDg2XzY0?= In-Reply-To: <08236fa7-213b-a84f-a927-59b74baee5d8@oracle.com> References: <7640e033-f590-0b63-79e3-59dd5b96f55f@oracle.com> <522cf585-60c4-4662-bbbd-d51158d11f3a.kuaiwei.kw@alibaba-inc.com>, <08236fa7-213b-a84f-a927-59b74baee5d8@oracle.com> Message-ID: <8dc563d3-7aff-48cc-b44f-30171562c208.kuaiwei.kw@alibaba-inc.com> Thanks for your quick reply. > I updated my test cases in test/micro/org/openjdk/bench/vm/compiler/InterfaceCalls.java . My tests will not inline interface methods and most cpu are used by itable_stub. > every test will run 10 warmup iterations and 5 measure iterations for one score. I took 3 score for every test. > Below is test result on my machines, it looks slow loop has more improvement than origin one. Good, thanks for the numbers. I'm curious have you observed any improvements on larger scale benchmarks or real world apps? I'm asking because linear scan is already far from optimal when there are many superinterfaces present. Kevin: itable_stub was found hot on several online applications. So I started to work on this. Now I don't have chance to verify it online. So I uses microbenchmarks to verify. I will test with some benchmarks. > I think lookup_interface_method can be reused as fast path. And it is also used by templateTable::invoke_interface and generate_method_handle_dispatch. > My implementation in slow path need more registers (6 registers so far), I need to check if there's register conflict in these methods. I'd like to keep a separate > slow path implementation. How do you think about it? Frankly speaking, I'd like to avoid the duplication. Kevin: Ok, I will try to merge them. Also, absence of guarantees about order of interfaces in the itable complicates things: REFC and DECC can be encountered in arbitrary order and the pass should take that into account. For example, I don't see early exit on success in slow variant, so every lookup has to go through the whole itable irrespective of whether it succeeds or fails. I attribute that to the complications induced by aforementioned aspect. Kevin: I use a counter for matching. If it reaches zero, the iteration can exit early. And speaking of the overall approach (as it is implemented now), IMO increased complexity doesn't worth it. If interface calls become a bottleneck, the problem lies not in itable stub, but the overall design which requires linear scan over itables. It's better to put the effort there than micro-optimizing the stub. Kevin: I agree we can improve itable design. My initial think is jvm may reorder itable at safepoint. I can take it as a follow up optimization. But I'm happy to change my mind if the rewritten implementation makes it easier to reason about the code. (FTR subtype checks suffer from a similar problem: unless Klass::_secondary_super_cache catches it, subtype check for an interface does a linear scan over _secondary_supers array.) Regards, Kevin ------------------------------------------------------------------ From:Vladimir Ivanov Send Time:2020?9?15?(???) 17:03 To:??(??) ; hotspot-dev ; kuaiwei ; hotspot-dev ; hotspot-compiler-dev Subject:Re: RFR: 8253049: Enhance itable_stub for AArch64 and x86_64 > I updated my test cases in test/micro/org/openjdk/bench/vm/compiler/InterfaceCalls.java . My tests will not inline interface methods and most cpu are used by itable_stub. > every test will run 10 warmup iterations and 5 measure iterations for one score. I took 3 score for every test. > Below is test result on my machines, it looks slow loop has more improvement than origin one. Good, thanks for the numbers. I'm curious have you observed any improvements on larger scale benchmarks or real world apps? I'm asking because linear scan is already far from optimal when there are many superinterfaces present. > I think lookup_interface_method can be reused as fast path. And it is also used by templateTable::invoke_interface and generate_method_handle_dispatch. > My implementation in slow path need more registers (6 registers so far), I need to check if there's register conflict in these methods. I'd like to keep a separate > slow path implementation. How do you think about it? Frankly speaking, I'd like to avoid the duplication. Also, absence of guarantees about order of interfaces in the itable complicates things: REFC and DECC can be encountered in arbitrary order and the pass should take that into account. For example, I don't see early exit on success in slow variant, so every lookup has to go through the whole itable irrespective of whether it succeeds or fails. I attribute that to the complications induced by aforementioned aspect. And speaking of the overall approach (as it is implemented now), IMO increased complexity doesn't worth it. If interface calls become a bottleneck, the problem lies not in itable stub, but the overall design which requires linear scan over itables. It's better to put the effort there than micro-optimizing the stub. But I'm happy to change my mind if the rewritten implementation makes it easier to reason about the code. (FTR subtype checks suffer from a similar problem: unless Klass::_secondary_super_cache catches it, subtype check for an interface does a linear scan over _secondary_supers array.) Best regards, Vladimir Ivanov > ------------------------------------------------------------------ > From:Vladimir Ivanov > Send Time:2020?9?14?(???) 22:10 > To:kuaiwei ; hotspot-dev ; hotspot-compiler-dev > Subject:Re: RFR: 8253049: Enhance itable_stub for AArch64 and x86_64 > > Hi Kevin, > > Very interesting observations. I like the idea to optimize for the case > when REFC == DECC. > > Fusing 2 passes over the itable into one does look attractive, but I'm > not sure the proposed variant is correct. I suggest to split the patch > into 2 enhancements and handle them separately. > > I'm curious what kind of benchmarks you used and what are the > improvements observed with the patch. > > One suggestion about the implementation: > > src/hotspot/cpu/x86/macroAssembler_x86.cpp: > > +void MacroAssembler::lookup_interface_method_in_stub(Register recv_klass, > > I'd like to avoid having 2 independent implementations of itable lookup > (MacroAssembler::lookup_interface_method_in_stub() and > MacroAssembler::lookup_interface_method()). It would be nice to keep the > implementation unified between itable and MethodHandle linkToInterface > linker stubs. > > What MacroAssembler::lookup_interface_method(..., true > /*return_method*/) does is interface method lookup w/o proper subtype > check and it is equivalent to fast loop in > MacroAssembler::lookup_interface_method_in_stub(). > > As a possible path forward, you could introduce the fast path check > first by moving the fast path check into > VtableStubs::create_itable_stub() and guard the first path over the > itable. It would make the type checking pass over itable optional based > on runtime check. > > Then you could refactor MacroAssembler::lookup_interface_method() to > optionally do REFC and DECC checks on every iteration and migrate > VtableStubs::create_itable_stub() and > MethodHandles::generate_method_handle_dispatch() to it. > > Best regards, > Vladimir Ivanov > > On 14.09.2020 13:52, kuaiwei wrote: >> Now itable_stub will go through instanceKlass's itable twice to look up a method entry. resolved klass is used for type >> checking and method holder klass is used to find method entry. In many cases , we observed resolved klass is as same as >> holder klass. So we can improve itable stub based on it. If they are same klass, stub uses a fast loop to check only >> one klass. If not, a slow loop is used to checking both klasses. >> >> Even entering in slow loop, new implementation can be better than old one in some cases. Because new stub just need go >> through itable once and reduce memory operations. >> >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8253049 >> >> ------------- >> >> Commit messages: >> - 8253049: Enhance itable_stub for AArch64 and x86_64 >> >> Changes: https://git.openjdk.java.net/jdk/pull/128/files >> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=128&range=00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8253049 >> Stats: 220 lines in 7 files changed: 172 ins; 35 del; 13 mod >> Patch: https://git.openjdk.java.net/jdk/pull/128.diff >> Fetch: git fetch https://git.openjdk.java.net/jdk pull/128/head:pull/128 >> >> PR: https://git.openjdk.java.net/jdk/pull/128 >> > From stefank at openjdk.java.net Tue Sep 15 10:23:50 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 15 Sep 2020 10:23:50 GMT Subject: RFR: 8247909: Improve PrimitiveConversions::cast using C++14 [v3] In-Reply-To: References: <1BYMg9eOMQD2HA2MVjBpJ8BQeDmWXtI1LItGWlyTR5A=.6a00ed66-a78f-401e-935e-04e85a6d33f6@github.com> Message-ID: On Tue, 15 Sep 2020 08:13:10 GMT, Kim Barrett wrote: >> Please review this reimplementation of PrimitiveConversions::cast, >> using facilities from C++14. In particular, conversions involving >> only integral values or integral and enum values are now constexpr. >> Also using rather than HotSpot work-alikes. >> >> Had to update zForwardingEntry.hpp because of a class no longer being >> implicitly included. Improved a friend declaration while in the >> vicinity. >> >> Testing >> mach5 tier1 > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > fix implict dependency by test on integralConstant.hpp Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/143 From jbhateja at openjdk.java.net Tue Sep 15 10:26:04 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 15 Sep 2020 10:26:04 GMT Subject: RFR: 8252848: Optimize small primitive arrayCopy operations through partial inlining using AVX-512 masked instructions [v2] In-Reply-To: References: Message-ID: > Summary: > > 1) Partial in-lining technique avoids call overhead penalty for sub-word type small array copy operations with size > less than 32 bytes. 2) At runtime, a conditional check based on copy length either calls an array-copy stub or executes > an optimized instruction sequence using AVX-512 masked instructions emitted at the call site. 3) New runtime flag > ArrayCopyPartialInlineSize=0/32(default)/64 bytes determines the maximum size for partial in-lining. > Performance Results: > System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz > Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java > ArrayCopyPartialInlineSize : 32 > > JMH | Block Size | Baseline (ns/op) | Partial Inling (ns/op) | Gain > -- | -- | -- | -- | -- > ArrayCopyAligned.testByte | 1 | 5.417 | 2.696 | 2.009272997 > ArrayCopyAligned.testByte | 3 | 5.494 | 2.702 | 2.03330866 > ArrayCopyAligned.testByte | 5 | 5.417 | 2.637 | 2.05422829 > ArrayCopyAligned.testByte | 10 | 5.343 | 2.703 | 1.976692564 > ArrayCopyAligned.testByte | 20 | 5.837 | 2.636 | 2.214339909 > ArrayCopyAligned.testByte | 70 | 5.86 | 6 | 0.976666667 > ArrayCopyAligned.testByte | 150 | 6.766 | 6.906 | 0.979727773 > ArrayCopyAligned.testByte | 300 | 7.605 | 7.952 | 0.956363179 > ArrayCopyAligned.testByte | 600 | 11.989 | 12.007 | 0.998500874 > ArrayCopyAligned.testByte | 1200 | 16.447 | 16.585 | 0.991679228 > ArrayCopyAligned.testChar | 1 | 5.02 | 2.828 | 1.775106082 > ArrayCopyAligned.testChar | 3 | 5.129 | 2.762 | 1.85698769 > ArrayCopyAligned.testChar | 5 | 5.041 | 2.762 | 1.82512672 > ArrayCopyAligned.testChar | 10 | 5.716 | 2.762 | 2.069514844 > ArrayCopyAligned.testChar | 20 | 5.111 | 5.399 | 0.946656788 > ArrayCopyAligned.testChar | 70 | 6.271 | 6.242 | 1.004645947 > ArrayCopyAligned.testChar | 150 | 7.45 | 7.599 | 0.980392157 > ArrayCopyAligned.testChar | 300 | 9.904 | 10.112 | 0.97943038 > ArrayCopyAligned.testChar | 600 | 17.131 | 17.167 | 0.997902953 > ArrayCopyAligned.testChar | 1200 | 29.556 | 29.851 | 0.990117584 > ArrayCopyUnalignedBoth.testByte | 1 | 5.419 | 2.702 | 2.005551443 > ArrayCopyUnalignedBoth.testByte | 3 | 5.558 | 2.636 | 2.108497724 > ArrayCopyUnalignedBoth.testByte | 5 | 5.43 | 2.636 | 2.059939302 > ArrayCopyUnalignedBoth.testByte | 10 | 5.378 | 2.637 | 2.039438756 > ArrayCopyUnalignedBoth.testByte | 20 | 5.914 | 2.636 | 2.243550835 > ArrayCopyUnalignedBoth.testByte | 70 | 5.882 | 5.954 | 0.987907289 > ArrayCopyUnalignedBoth.testByte | 150 | 6.784 | 6.88 | 0.986046512 > ArrayCopyUnalignedBoth.testByte | 300 | 7.635 | 7.968 | 0.958207831 > ArrayCopyUnalignedBoth.testByte | 600 | 12.226 | 12.129 | 1.007997362 > ArrayCopyUnalignedBoth.testByte | 1200 | 16.992 | 20.717 | 0.820195974 > ArrayCopyUnalignedBoth.testChar | 1 | 5.019 | 2.828 | 1.774752475 > ArrayCopyUnalignedBoth.testChar | 3 | 5.163 | 2.763 | 1.868621064 > ArrayCopyUnalignedBoth.testChar | 5 | 5.042 | 2.827 | 1.783516095 > ArrayCopyUnalignedBoth.testChar | 10 | 5.718 | 2.828 | 2.021923621 > ArrayCopyUnalignedBoth.testChar | 20 | 5.111 | 5.404 | 0.945780903 > ArrayCopyUnalignedBoth.testChar | 70 | 6.367 | 6.235 | 1.02117081 > ArrayCopyUnalignedBoth.testChar | 150 | 7.367 | 8.269 | 0.890917886 > ArrayCopyUnalignedBoth.testChar | 300 | 10.358 | 10.642 | 0.973313287 > ArrayCopyUnalignedBoth.testChar | 600 | 20.84 | 17.522 | 1.189361945 > ArrayCopyUnalignedBoth.testChar | 1200 | 31.895 | 31.892 | 1.000094067 > ArrayCopyUnalignedDst.testByte | 1 | 5.455 | 2.637 | 2.068638604 > ArrayCopyUnalignedDst.testByte | 3 | 5.562 | 2.702 | 2.058475204 > ArrayCopyUnalignedDst.testByte | 5 | 5.427 | 2.702 | 2.008512213 > ArrayCopyUnalignedDst.testByte | 10 | 5.367 | 2.696 | 1.990727003 > ArrayCopyUnalignedDst.testByte | 20 | 5.839 | 2.637 | 2.214258627 > ArrayCopyUnalignedDst.testByte | 70 | 5.888 | 5.968 | 0.986595174 > ArrayCopyUnalignedDst.testByte | 150 | 6.785 | 6.773 | 1.001771741 > ArrayCopyUnalignedDst.testByte | 300 | 7.606 | 7.972 | 0.954089313 > ArrayCopyUnalignedDst.testByte | 600 | 11.986 | 21.195 | 0.565510734 > ArrayCopyUnalignedDst.testByte | 1200 | 16.54 | 16.784 | 0.985462345 > ArrayCopyUnalignedDst.testChar | 1 | 5.02 | 2.827 | 1.775733994 > ArrayCopyUnalignedDst.testChar | 3 | 5.131 | 2.762 | 1.857711803 > ArrayCopyUnalignedDst.testChar | 5 | 5.038 | 2.762 | 1.82404055 > ArrayCopyUnalignedDst.testChar | 10 | 5.718 | 2.762 | 2.070238957 > ArrayCopyUnalignedDst.testChar | 20 | 5.113 | 5.401 | 0.946676541 > ArrayCopyUnalignedDst.testChar | 70 | 6.222 | 6.214 | 1.001287416 > ArrayCopyUnalignedDst.testChar | 150 | 7.367 | 8.125 | 0.906707692 > ArrayCopyUnalignedDst.testChar | 300 | 10.204 | 10.082 | 1.012100774 > ArrayCopyUnalignedDst.testChar | 600 | 16.978 | 17.135 | 0.990837467 > ArrayCopyUnalignedDst.testChar | 1200 | 32.351 | 31.996 | 1.011095137 > ArrayCopyUnalignedSrc.testByte | 1 | 5.414 | 2.696 | 2.008160237 > ArrayCopyUnalignedSrc.testByte | 3 | 5.494 | 2.637 | 2.083428138 > ArrayCopyUnalignedSrc.testByte | 5 | 5.431 | 2.637 | 2.059537353 > ArrayCopyUnalignedSrc.testByte | 10 | 5.344 | 2.703 | 1.977062523 > ArrayCopyUnalignedSrc.testByte | 20 | 5.834 | 2.696 | 2.163946588 > ArrayCopyUnalignedSrc.testByte | 70 | 5.883 | 6.009 | 0.979031453 > ArrayCopyUnalignedSrc.testByte | 150 | 6.729 | 6.87 | 0.979475983 > ArrayCopyUnalignedSrc.testByte | 300 | 7.603 | 7.97 | 0.953952321 > ArrayCopyUnalignedSrc.testByte | 600 | 12.004 | 12.16 | 0.987171053 > ArrayCopyUnalignedSrc.testByte | 1200 | 16.534 | 16.643 | 0.9934507 > ArrayCopyUnalignedSrc.testChar | 1 | 5.021 | 2.762 | 1.81788559 > ArrayCopyUnalignedSrc.testChar | 3 | 5.13 | 2.762 | 1.857349747 > ArrayCopyUnalignedSrc.testChar | 5 | 5.042 | 2.827 | 1.783516095 > ArrayCopyUnalignedSrc.testChar | 10 | 5.726 | 2.761 | 2.073886273 > ArrayCopyUnalignedSrc.testChar | 20 | 5.112 | 5.401 | 0.94649139 > ArrayCopyUnalignedSrc.testChar | 70 | 6.113 | 6.227 | 0.981692629 > ArrayCopyUnalignedSrc.testChar | 150 | 7.493 | 7.888 | 0.949923935 > ArrayCopyUnalignedSrc.testChar | 300 | 10.234 | 10.501 | 0.97457385 > ArrayCopyUnalignedSrc.testChar | 600 | 17.175 | 17.142 | 1.001925096 > ArrayCopyUnalignedSrc.testChar | 1200 | 31.926 | 31.987 | 0.998092975 > > Detailed Reports: > Baseline : > [http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_Baseline.txt](http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_Baseline.txt) > WithOpt : > [http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_With_PI_Opts.txt](http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_With_PI_Opts.txt) Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Update arraycopynode.cpp Missed safety check. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/144/files - new: https://git.openjdk.java.net/jdk/pull/144/files/1601fba2..f6c46479 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=144&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=144&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/144.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/144/head:pull/144 PR: https://git.openjdk.java.net/jdk/pull/144 From kbarrett at openjdk.java.net Tue Sep 15 10:29:04 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 15 Sep 2020 10:29:04 GMT Subject: RFR: 8247909: Improve PrimitiveConversions::cast using C++14 [v4] In-Reply-To: <1BYMg9eOMQD2HA2MVjBpJ8BQeDmWXtI1LItGWlyTR5A=.6a00ed66-a78f-401e-935e-04e85a6d33f6@github.com> References: <1BYMg9eOMQD2HA2MVjBpJ8BQeDmWXtI1LItGWlyTR5A=.6a00ed66-a78f-401e-935e-04e85a6d33f6@github.com> Message-ID: > Please review this reimplementation of PrimitiveConversions::cast, > using facilities from C++14. In particular, conversions involving > only integral values or integral and enum values are now constexpr. > Also using rather than HotSpot work-alikes. > > Had to update zForwardingEntry.hpp because of a class no longer being > implicitly included. Improved a friend declaration while in the > vicinity. > > Testing > mach5 tier1 Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into update_primitive_conversions - fix implict dependency by test on integralConstant.hpp - fix comment - Reimpliment PC::cast, with some cases now constexpr. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/143/files - new: https://git.openjdk.java.net/jdk/pull/143/files/c55dfce8..174dbec3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=143&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=143&range=02-03 Stats: 5387 lines in 118 files changed: 3393 ins; 1472 del; 522 mod Patch: https://git.openjdk.java.net/jdk/pull/143.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/143/head:pull/143 PR: https://git.openjdk.java.net/jdk/pull/143 From kbarrett at openjdk.java.net Tue Sep 15 10:56:02 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 15 Sep 2020 10:56:02 GMT Subject: Integrated: 8247909: Improve PrimitiveConversions::cast using C++14 In-Reply-To: <1BYMg9eOMQD2HA2MVjBpJ8BQeDmWXtI1LItGWlyTR5A=.6a00ed66-a78f-401e-935e-04e85a6d33f6@github.com> References: <1BYMg9eOMQD2HA2MVjBpJ8BQeDmWXtI1LItGWlyTR5A=.6a00ed66-a78f-401e-935e-04e85a6d33f6@github.com> Message-ID: On Sun, 13 Sep 2020 07:27:13 GMT, Kim Barrett wrote: > Please review this reimplementation of PrimitiveConversions::cast, > using facilities from C++14. In particular, conversions involving > only integral values or integral and enum values are now constexpr. > Also using rather than HotSpot work-alikes. > > Had to update zForwardingEntry.hpp because of a class no longer being > implicitly included. Improved a friend declaration while in the > vicinity. > > Testing > mach5 tier1 This pull request has now been integrated. Changeset: 7eb4d4aa Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/7eb4d4aa Stats: 241 lines in 4 files changed: 111 ins; 113 del; 17 mod 8247909: Improve PrimitiveConversions::cast using C++14 Reimpliment PrimitiveConversions::cast, with some cases now constexpr. --------- ### Progress - [x] Change must not contain extraneous whitespace - [x] Commit message must refer to an issue - [ ] Change must be properly reviewed ### Issue * [JDK-8247909](https://bugs.openjdk.java.net/browse/JDK-8247909): Improve PrimitiveConversions::cast using C++14 ### Download `$ git fetch https://git.openjdk.java.net/jdk pull/143/head:pull/143` `$ git checkout pull/143` Reviewed-by: dholmes, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/143 From jcm at openjdk.java.net Tue Sep 15 10:59:06 2020 From: jcm at openjdk.java.net (Jamsheed Mohammed C M) Date: Tue, 15 Sep 2020 10:59:06 GMT Subject: RFR: 8249451: Unconditional exceptions clearing logic in compiler code should honor Async Exceptions. [v2] In-Reply-To: <2zjS36Nz0zH4AorRbppunfKPFkciaMD865WyBdMzOFI=.fc7a6fd1-96b4-4769-ab0b-b71e7f5bdc9b@github.com> References: <2zjS36Nz0zH4AorRbppunfKPFkciaMD865WyBdMzOFI=.fc7a6fd1-96b4-4769-ab0b-b71e7f5bdc9b@github.com> Message-ID: <_2RfxBOE39VhwtDZe2F2qLb52IfF_JiCWwE2cJsEuiM=.01bb1177-808a-45ea-a8bf-3dccfab6ea38@github.com> > Hi > > Moving the review that is based on mercurial repo to github. > The history of conversation is > [here](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039861.html) > Issue:[ JDK-8249451 ](https://bugs.openjdk.java.net/browse/JDK-8249451) > > @dholmes-ora could you please have a look. Jamsheed Mohammed C M has updated the pull request incrementally with one additional commit since the last revision: removing unused definition load_class_by_index ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/169/files - new: https://git.openjdk.java.net/jdk/pull/169/files/cfc2d719..1c0786a5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=169&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=169&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/169.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/169/head:pull/169 PR: https://git.openjdk.java.net/jdk/pull/169 From stefank at openjdk.java.net Tue Sep 15 11:17:34 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 15 Sep 2020 11:17:34 GMT Subject: RFR: 8253162: Make frame::oops_do const Message-ID: Make frame::oops_do const, so that we can use a const frame& receiver when appropriate. With this, we can get rid of the temporary copies made just to make the frame variable non-const. See for example: https://github.com/openjdk/zgc/blob/c4765b5599d07124410f8a80b1acef9349a998e0/src/hotspot/share/gc/z/zStackWatermark.cpp#L96 ------------- Commit messages: - Make frame::oops_do const Changes: https://git.openjdk.java.net/jdk/pull/175/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=175&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253162 Stats: 35 lines in 2 files changed: 0 ins; 1 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/175/head:pull/175 PR: https://git.openjdk.java.net/jdk/pull/175 From kim.barrett at oracle.com Tue Sep 15 11:29:06 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 15 Sep 2020 07:29:06 -0400 Subject: RFR: 8253162: Make frame::oops_do const In-Reply-To: References: Message-ID: > On Sep 15, 2020, at 7:17 AM, Stefan Karlsson wrote: > > Make frame::oops_do const, so that we can use a const frame& receiver when appropriate. With this, we can get rid of > the temporary copies made just to make the frame variable non-const. See for example: > https://github.com/openjdk/zgc/blob/c4765b5599d07124410f8a80b1acef9349a998e0/src/hotspot/share/gc/z/zStackWatermark.cpp#L96 > > ------------- > > Commit messages: > - Make frame::oops_do const > > Changes: https://git.openjdk.java.net/jdk/pull/175/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=175&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8253162 > Stats: 35 lines in 2 files changed: 0 ins; 1 del; 34 mod > Patch: https://git.openjdk.java.net/jdk/pull/175.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/175/head:pull/175 > > PR: https://git.openjdk.java.net/jdk/pull/175 ------------------------------------------------------------------------------ src/hotspot/share/runtime/frame.cpp 1039 void frame::oops_do_internal(OopClosure* f, CodeBlobClosure* cf, RegisterMap* map, bool use_interpreter_oop_map_cache) const { Why is this register map not const? ------------------------------------------------------------------------------ Looks good other than that. From kbarrett at openjdk.java.net Tue Sep 15 11:37:46 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 15 Sep 2020 11:37:46 GMT Subject: RFR: 8253162: Make frame::oops_do const In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 11:08:55 GMT, Stefan Karlsson wrote: > Make frame::oops_do const, so that we can use a const frame& receiver when appropriate. With this, we can get rid of > the temporary copies made just to make the frame variable non-const. See for example: > https://github.com/openjdk/zgc/blob/c4765b5599d07124410f8a80b1acef9349a998e0/src/hotspot/share/gc/z/zStackWatermark.cpp#L96 Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/175 From coleenp at openjdk.java.net Tue Sep 15 11:50:03 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Sep 2020 11:50:03 GMT Subject: RFR: 8253162: Make frame::oops_do const In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 11:08:55 GMT, Stefan Karlsson wrote: > Make frame::oops_do const, so that we can use a const frame& receiver when appropriate. With this, we can get rid of > the temporary copies made just to make the frame variable non-const. See for example: > https://github.com/openjdk/zgc/blob/c4765b5599d07124410f8a80b1acef9349a998e0/src/hotspot/share/gc/z/zStackWatermark.cpp#L96 Looks good to me. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/175 From kbarrett at openjdk.java.net Tue Sep 15 11:51:46 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 15 Sep 2020 11:51:46 GMT Subject: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space [v3] In-Reply-To: References: Message-ID: > This is rework of initial change from before the transition to git. > The initial RFR email is attached below. > > The primary change is to limit the number of partial array tasks in > the queues for any given array. The original change just split up an > array into N tasks that were all enqueued at once. But for a large > array this could be a lot of tasks, leading to significant and > unnecessary queue expansion. Instead we now limit the number of tasks > for a given array based on the number of workers, and only gradually > add tasks up to that limit. This gives other threads an opportunity > to steal such tasks, while still keeping queue growth under control. > > Most of the calculation for this is handled by a new helper class, so > this can later be shared with ParallelGC. > > The dispatch on array klass type for has also been changed. It now > affirmatively breaks Project Valhalla, rather than quietly doing > something that probably isn't what is actually wanted. I'll discuss > with them so there is a plan for dealing with it when they take this > update. > > Ran tier1-6 in mach5 and some local stress tests. > > Performance testing was unchanged from previous, except I wasn't able > to reproduce the small specjbb2015 critical-jops improvement > previously seen on one platform. My suspicion is that improvement was > a statistical abberation. > > --- Initial RFR email --- > > RFR: 8158045: Improve large object handling during evacuation > RFR: 8027761: Investigate fast-path for scanning only objects with references during gc > RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space > > Please review this change to type dispatching and handling in G1's > evacuation copying, in order to improve the hot paths and improve array > handling. This change addresses several closely co-located enhancement > requests; it seemed difficult to split them up in a sensible way. > > do_copy_to_survivor_space now gets the klass of the object being copied > once, up front, for use in multiple places. This avoids fetching (including > re-decoding when compressed) the klass multiple times. This addresses part > of JDK-8027545. > > Moved check for and handling of string deduplication later, only applying it > after the special array cases have been dealt with, since strings are not > arrays. (They are header objects pointing to an array of character values.) > > Special case typeArray, doing nothing other than the copy, since they > contain no oops that need to be processed. This addresses JDK-8027761. > > Changed handling of objArray, pushing all of the partial array tasks up > front, rather than processing the current chunk after pushing a single task > for the remaining work. This addresses JDK-8158045. > > As part of these, cached some more frequently accessed values in > G1ParScanThreadState member variables. This addresses part of part of > JDK-8027545. > > While both the old and new code will work for Project Valhalla, the handling > of arrays should be updated for that project, which introduces new array > types. > > Deleted a lingering reference to G1ParScanPartialArrayClosure that was > deleted long ago (JDK-8035330, JDK 9). > > CR: > https://bugs.openjdk.java.net/browse/JDK-8158045 > https://bugs.openjdk.java.net/browse/JDK-8027761 > https://bugs.openjdk.java.net/browse/JDK-8027545 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ > > Testing: > tier1-3 > > performance testing - seems to be at worst performance neutral, with a > statistically significant 3% improvement in specjbb2015 critical-jops seen > on one platform. Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: Respond to reviews by sjohanss and tschatzl ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/90/files - new: https://git.openjdk.java.net/jdk/pull/90/files/1981c392..1c8c0a82 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=90&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=90&range=01-02 Stats: 11 lines in 4 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/90.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/90/head:pull/90 PR: https://git.openjdk.java.net/jdk/pull/90 From stefank at openjdk.java.net Tue Sep 15 11:54:21 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 15 Sep 2020 11:54:21 GMT Subject: RFR: 8253162: Make frame::oops_do const [v2] In-Reply-To: References: Message-ID: > Make frame::oops_do const, so that we can use a const frame& receiver when appropriate. With this, we can get rid of > the temporary copies made just to make the frame variable non-const. See for example: > https://github.com/openjdk/zgc/blob/c4765b5599d07124410f8a80b1acef9349a998e0/src/hotspot/share/gc/z/zStackWatermark.cpp#L96 Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Make frame::oops_do RegisterMap const ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/175/files - new: https://git.openjdk.java.net/jdk/pull/175/files/7d44eec8..093bfa91 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=175&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=175&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/175.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/175/head:pull/175 PR: https://git.openjdk.java.net/jdk/pull/175 From kbarrett at openjdk.java.net Tue Sep 15 12:07:23 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 15 Sep 2020 12:07:23 GMT Subject: RFR: 8253162: Make frame::oops_do const [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 11:54:21 GMT, Stefan Karlsson wrote: >> Make frame::oops_do const, so that we can use a const frame& receiver when appropriate. With this, we can get rid of >> the temporary copies made just to make the frame variable non-const. See for example: >> https://github.com/openjdk/zgc/blob/c4765b5599d07124410f8a80b1acef9349a998e0/src/hotspot/share/gc/z/zStackWatermark.cpp#L96 > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Make frame::oops_do RegisterMap const Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/175 From kbarrett at openjdk.java.net Tue Sep 15 12:21:42 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 15 Sep 2020 12:21:42 GMT Subject: Integrated: 8027545: Improve object array chunking test in G1's copy_to_survivor_space In-Reply-To: References: Message-ID: On Wed, 9 Sep 2020 07:24:27 GMT, Kim Barrett wrote: > This is rework of initial change from before the transition to git. > The initial RFR email is attached below. > > The primary change is to limit the number of partial array tasks in > the queues for any given array. The original change just split up an > array into N tasks that were all enqueued at once. But for a large > array this could be a lot of tasks, leading to significant and > unnecessary queue expansion. Instead we now limit the number of tasks > for a given array based on the number of workers, and only gradually > add tasks up to that limit. This gives other threads an opportunity > to steal such tasks, while still keeping queue growth under control. > > Most of the calculation for this is handled by a new helper class, so > this can later be shared with ParallelGC. > > The dispatch on array klass type for has also been changed. It now > affirmatively breaks Project Valhalla, rather than quietly doing > something that probably isn't what is actually wanted. I'll discuss > with them so there is a plan for dealing with it when they take this > update. > > Ran tier1-6 in mach5 and some local stress tests. > > Performance testing was unchanged from previous, except I wasn't able > to reproduce the small specjbb2015 critical-jops improvement > previously seen on one platform. My suspicion is that improvement was > a statistical abberation. > > --- Initial RFR email --- > > RFR: 8158045: Improve large object handling during evacuation > RFR: 8027761: Investigate fast-path for scanning only objects with references during gc > RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space > > Please review this change to type dispatching and handling in G1's > evacuation copying, in order to improve the hot paths and improve array > handling. This change addresses several closely co-located enhancement > requests; it seemed difficult to split them up in a sensible way. > > do_copy_to_survivor_space now gets the klass of the object being copied > once, up front, for use in multiple places. This avoids fetching (including > re-decoding when compressed) the klass multiple times. This addresses part > of JDK-8027545. > > Moved check for and handling of string deduplication later, only applying it > after the special array cases have been dealt with, since strings are not > arrays. (They are header objects pointing to an array of character values.) > > Special case typeArray, doing nothing other than the copy, since they > contain no oops that need to be processed. This addresses JDK-8027761. > > Changed handling of objArray, pushing all of the partial array tasks up > front, rather than processing the current chunk after pushing a single task > for the remaining work. This addresses JDK-8158045. > > As part of these, cached some more frequently accessed values in > G1ParScanThreadState member variables. This addresses part of part of > JDK-8027545. > > While both the old and new code will work for Project Valhalla, the handling > of arrays should be updated for that project, which introduces new array > types. > > Deleted a lingering reference to G1ParScanPartialArrayClosure that was > deleted long ago (JDK-8035330, JDK 9). > > CR: > https://bugs.openjdk.java.net/browse/JDK-8158045 > https://bugs.openjdk.java.net/browse/JDK-8027761 > https://bugs.openjdk.java.net/browse/JDK-8027545 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ > > Testing: > tier1-3 > > performance testing - seems to be at worst performance neutral, with a > statistically significant 3% improvement in specjbb2015 critical-jops seen > on one platform. This pull request has now been integrated. Changeset: dafcf105 Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/dafcf105 Stats: 467 lines in 8 files changed: 28 ins; 405 del; 34 mod 8027545: Improve object array chunking test in G1's copy_to_survivor_space 8158045: Improve large object handling during evacuation 8027761: Investigate fast-path for scanning only objects with references during gc Generate multiple partial array tasks for large objArrays. Reviewed-by: sjohanss, ayang, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/90 From neliasso at openjdk.java.net Tue Sep 15 13:18:30 2020 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Tue, 15 Sep 2020 13:18:30 GMT Subject: RFR: 8252847: New AVX512 optimized stubs for both conjoint and disjoint arraycopy In-Reply-To: References: Message-ID: On Mon, 7 Sep 2020 14:28:18 GMT, Jatin Bhateja wrote: > Summary: > > 1) New AVX3 optimized stubs for both conjoint and disjoint arraycopy. > 2) Special instruction sequence blocks for copy sizes b/w 32-192 bytes. > 3) Block copy operation above 192 bytes is performed using destination address aligned PRE-MAIN-POST loop. Main loop > copies 192 byte in one iteration and tail part fall over special instruction sequence blocks. 4) Both small copy block > and aligned loop use 32 byte vector register to prevent and frequency penalty for copy sizes less than AVX3Threshold. > 5) For block size above AVX3Theshold both special blocks and loop operate using 64 byte register. 6) In case user > sets the maximum vector size to 32 bytes, forward copy (disjoint) operations are done using efficient REP MOVS for copy > sizes above 4096 bytes. JMH Results: > System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz > Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java > Baseline : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_Baseline.txt]() > WithOpt : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_WithOpts.txt]() Changes requested by neliasso (Reviewer). src/hotspot/cpu/x86/macroAssembler_x86.cpp line 7972: > 7970: assert(MaxVectorSize >= 32, "vector length < 32"); > 7971: use64byteVector |= MaxVectorSize > 32 && AVX3Threshold == 0; > 7972: if (use64byteVector == false) { Change to "!use64byteVector" src/hotspot/cpu/x86/macroAssembler_x86.cpp line 8012: > 8010: assert(MaxVectorSize == 64 || MaxVectorSize == 32, "vector length mismatch"); > 8011: use64byteVector |= MaxVectorSize > 32 && AVX3Threshold == 0; > 8012: if (use64byteVector == false) { Change to "!use64byteVector" src/hotspot/cpu/x86/macroAssembler_x86.cpp line 8026: > 8024: assert(MaxVectorSize == 64 || MaxVectorSize == 32, "vector length mismatch"); > 8025: use64byteVector |= MaxVectorSize > 32 && AVX3Threshold == 0; > 8026: if (use64byteVector == false) { Change to "!use64byteVector" src/hotspot/cpu/x86/vm_version_x86.cpp line 1167: > 1165: > 1166: if (!FLAG_IS_DEFAULT(AVX3Threshold)) { > 1167: if (AVX3Threshold !=0 && !is_power_of_2(AVX3Threshold)) { Missing space before '0' src/hotspot/cpu/x86/macroAssembler_x86.cpp line 7970: > 7968: KRegister mask, Register length, Register temp, > 7969: BasicType type, int offset, bool use64byteVector) { > 7970: assert(MaxVectorSize >= 32, "vector length < 32"); Why does "MaxVectorSize >= 32" imply that "vector length < 32"? This assert appears in multiple locations. src/hotspot/cpu/x86/macroAssembler_x86.cpp line 7971: > 7969: BasicType type, int offset, bool use64byteVector) { > 7970: assert(MaxVectorSize >= 32, "vector length < 32"); > 7971: use64byteVector |= MaxVectorSize > 32 && AVX3Threshold == 0; When do you expect AVX3Threshold to be 0? ------------- PR: https://git.openjdk.java.net/jdk/pull/61 From pliden at openjdk.java.net Tue Sep 15 13:20:04 2020 From: pliden at openjdk.java.net (Per =?UTF-8?B?TGlkw6lu?=) Date: Tue, 15 Sep 2020 13:20:04 GMT Subject: RFR: 8253162: Make frame::oops_do const [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 11:54:21 GMT, Stefan Karlsson wrote: >> Make frame::oops_do const, so that we can use a const frame& receiver when appropriate. With this, we can get rid of >> the temporary copies made just to make the frame variable non-const. See for example: >> https://github.com/openjdk/zgc/blob/c4765b5599d07124410f8a80b1acef9349a998e0/src/hotspot/share/gc/z/zStackWatermark.cpp#L96 > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Make frame::oops_do RegisterMap const Marked as reviewed by pliden (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/175 From neliasso at openjdk.java.net Tue Sep 15 13:54:29 2020 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Tue, 15 Sep 2020 13:54:29 GMT Subject: RFR: 8252848: Optimize small primitive arrayCopy operations through partial inlining using AVX-512 masked instructions [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 10:26:04 GMT, Jatin Bhateja wrote: >> Summary: >> >> 1) Partial in-lining technique avoids call overhead penalty for sub-word type small array copy operations with size >> less than 32 bytes. 2) At runtime, a conditional check based on copy length either calls an array-copy stub or executes >> an optimized instruction sequence using AVX-512 masked instructions emitted at the call site. 3) New runtime flag >> ArrayCopyPartialInlineSize=0/32(default)/64 bytes determines the maximum size for partial in-lining. >> Performance Results: >> System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz >> Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java >> ArrayCopyPartialInlineSize : 32 >> >> JMH | Block Size | Baseline (ns/op) | Partial Inling (ns/op) | Gain >> -- | -- | -- | -- | -- >> ArrayCopyAligned.testByte | 1 | 5.417 | 2.696 | 2.009272997 >> ArrayCopyAligned.testByte | 3 | 5.494 | 2.702 | 2.03330866 >> ArrayCopyAligned.testByte | 5 | 5.417 | 2.637 | 2.05422829 >> ArrayCopyAligned.testByte | 10 | 5.343 | 2.703 | 1.976692564 >> ArrayCopyAligned.testByte | 20 | 5.837 | 2.636 | 2.214339909 >> ArrayCopyAligned.testByte | 70 | 5.86 | 6 | 0.976666667 >> ArrayCopyAligned.testByte | 150 | 6.766 | 6.906 | 0.979727773 >> ArrayCopyAligned.testByte | 300 | 7.605 | 7.952 | 0.956363179 >> ArrayCopyAligned.testByte | 600 | 11.989 | 12.007 | 0.998500874 >> ArrayCopyAligned.testByte | 1200 | 16.447 | 16.585 | 0.991679228 >> ArrayCopyAligned.testChar | 1 | 5.02 | 2.828 | 1.775106082 >> ArrayCopyAligned.testChar | 3 | 5.129 | 2.762 | 1.85698769 >> ArrayCopyAligned.testChar | 5 | 5.041 | 2.762 | 1.82512672 >> ArrayCopyAligned.testChar | 10 | 5.716 | 2.762 | 2.069514844 >> ArrayCopyAligned.testChar | 20 | 5.111 | 5.399 | 0.946656788 >> ArrayCopyAligned.testChar | 70 | 6.271 | 6.242 | 1.004645947 >> ArrayCopyAligned.testChar | 150 | 7.45 | 7.599 | 0.980392157 >> ArrayCopyAligned.testChar | 300 | 9.904 | 10.112 | 0.97943038 >> ArrayCopyAligned.testChar | 600 | 17.131 | 17.167 | 0.997902953 >> ArrayCopyAligned.testChar | 1200 | 29.556 | 29.851 | 0.990117584 >> ArrayCopyUnalignedBoth.testByte | 1 | 5.419 | 2.702 | 2.005551443 >> ArrayCopyUnalignedBoth.testByte | 3 | 5.558 | 2.636 | 2.108497724 >> ArrayCopyUnalignedBoth.testByte | 5 | 5.43 | 2.636 | 2.059939302 >> ArrayCopyUnalignedBoth.testByte | 10 | 5.378 | 2.637 | 2.039438756 >> ArrayCopyUnalignedBoth.testByte | 20 | 5.914 | 2.636 | 2.243550835 >> ArrayCopyUnalignedBoth.testByte | 70 | 5.882 | 5.954 | 0.987907289 >> ArrayCopyUnalignedBoth.testByte | 150 | 6.784 | 6.88 | 0.986046512 >> ArrayCopyUnalignedBoth.testByte | 300 | 7.635 | 7.968 | 0.958207831 >> ArrayCopyUnalignedBoth.testByte | 600 | 12.226 | 12.129 | 1.007997362 >> ArrayCopyUnalignedBoth.testByte | 1200 | 16.992 | 20.717 | 0.820195974 >> ArrayCopyUnalignedBoth.testChar | 1 | 5.019 | 2.828 | 1.774752475 >> ArrayCopyUnalignedBoth.testChar | 3 | 5.163 | 2.763 | 1.868621064 >> ArrayCopyUnalignedBoth.testChar | 5 | 5.042 | 2.827 | 1.783516095 >> ArrayCopyUnalignedBoth.testChar | 10 | 5.718 | 2.828 | 2.021923621 >> ArrayCopyUnalignedBoth.testChar | 20 | 5.111 | 5.404 | 0.945780903 >> ArrayCopyUnalignedBoth.testChar | 70 | 6.367 | 6.235 | 1.02117081 >> ArrayCopyUnalignedBoth.testChar | 150 | 7.367 | 8.269 | 0.890917886 >> ArrayCopyUnalignedBoth.testChar | 300 | 10.358 | 10.642 | 0.973313287 >> ArrayCopyUnalignedBoth.testChar | 600 | 20.84 | 17.522 | 1.189361945 >> ArrayCopyUnalignedBoth.testChar | 1200 | 31.895 | 31.892 | 1.000094067 >> ArrayCopyUnalignedDst.testByte | 1 | 5.455 | 2.637 | 2.068638604 >> ArrayCopyUnalignedDst.testByte | 3 | 5.562 | 2.702 | 2.058475204 >> ArrayCopyUnalignedDst.testByte | 5 | 5.427 | 2.702 | 2.008512213 >> ArrayCopyUnalignedDst.testByte | 10 | 5.367 | 2.696 | 1.990727003 >> ArrayCopyUnalignedDst.testByte | 20 | 5.839 | 2.637 | 2.214258627 >> ArrayCopyUnalignedDst.testByte | 70 | 5.888 | 5.968 | 0.986595174 >> ArrayCopyUnalignedDst.testByte | 150 | 6.785 | 6.773 | 1.001771741 >> ArrayCopyUnalignedDst.testByte | 300 | 7.606 | 7.972 | 0.954089313 >> ArrayCopyUnalignedDst.testByte | 600 | 11.986 | 21.195 | 0.565510734 >> ArrayCopyUnalignedDst.testByte | 1200 | 16.54 | 16.784 | 0.985462345 >> ArrayCopyUnalignedDst.testChar | 1 | 5.02 | 2.827 | 1.775733994 >> ArrayCopyUnalignedDst.testChar | 3 | 5.131 | 2.762 | 1.857711803 >> ArrayCopyUnalignedDst.testChar | 5 | 5.038 | 2.762 | 1.82404055 >> ArrayCopyUnalignedDst.testChar | 10 | 5.718 | 2.762 | 2.070238957 >> ArrayCopyUnalignedDst.testChar | 20 | 5.113 | 5.401 | 0.946676541 >> ArrayCopyUnalignedDst.testChar | 70 | 6.222 | 6.214 | 1.001287416 >> ArrayCopyUnalignedDst.testChar | 150 | 7.367 | 8.125 | 0.906707692 >> ArrayCopyUnalignedDst.testChar | 300 | 10.204 | 10.082 | 1.012100774 >> ArrayCopyUnalignedDst.testChar | 600 | 16.978 | 17.135 | 0.990837467 >> ArrayCopyUnalignedDst.testChar | 1200 | 32.351 | 31.996 | 1.011095137 >> ArrayCopyUnalignedSrc.testByte | 1 | 5.414 | 2.696 | 2.008160237 >> ArrayCopyUnalignedSrc.testByte | 3 | 5.494 | 2.637 | 2.083428138 >> ArrayCopyUnalignedSrc.testByte | 5 | 5.431 | 2.637 | 2.059537353 >> ArrayCopyUnalignedSrc.testByte | 10 | 5.344 | 2.703 | 1.977062523 >> ArrayCopyUnalignedSrc.testByte | 20 | 5.834 | 2.696 | 2.163946588 >> ArrayCopyUnalignedSrc.testByte | 70 | 5.883 | 6.009 | 0.979031453 >> ArrayCopyUnalignedSrc.testByte | 150 | 6.729 | 6.87 | 0.979475983 >> ArrayCopyUnalignedSrc.testByte | 300 | 7.603 | 7.97 | 0.953952321 >> ArrayCopyUnalignedSrc.testByte | 600 | 12.004 | 12.16 | 0.987171053 >> ArrayCopyUnalignedSrc.testByte | 1200 | 16.534 | 16.643 | 0.9934507 >> ArrayCopyUnalignedSrc.testChar | 1 | 5.021 | 2.762 | 1.81788559 >> ArrayCopyUnalignedSrc.testChar | 3 | 5.13 | 2.762 | 1.857349747 >> ArrayCopyUnalignedSrc.testChar | 5 | 5.042 | 2.827 | 1.783516095 >> ArrayCopyUnalignedSrc.testChar | 10 | 5.726 | 2.761 | 2.073886273 >> ArrayCopyUnalignedSrc.testChar | 20 | 5.112 | 5.401 | 0.94649139 >> ArrayCopyUnalignedSrc.testChar | 70 | 6.113 | 6.227 | 0.981692629 >> ArrayCopyUnalignedSrc.testChar | 150 | 7.493 | 7.888 | 0.949923935 >> ArrayCopyUnalignedSrc.testChar | 300 | 10.234 | 10.501 | 0.97457385 >> ArrayCopyUnalignedSrc.testChar | 600 | 17.175 | 17.142 | 1.001925096 >> ArrayCopyUnalignedSrc.testChar | 1200 | 31.926 | 31.987 | 0.998092975 >> >> Detailed Reports: >> Baseline : >> [http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_Baseline.txt](http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_Baseline.txt) >> WithOpt : >> [http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_With_PI_Opts.txt](http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_With_PI_Opts.txt) > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Update arraycopynode.cpp > > Missed safety check. This PR includes the changes for JDK-8252847. It makes it hard to review. ------------- PR: https://git.openjdk.java.net/jdk/pull/144 From github.com+2249648+JohnTortugo at openjdk.java.net Tue Sep 15 15:07:20 2020 From: github.com+2249648+JohnTortugo at openjdk.java.net (John Tortugo) Date: Tue, 15 Sep 2020 15:07:20 GMT Subject: RFR: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file Message-ID: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> Relates to: https://bugs.openjdk.java.net/browse/JDK-8243066 Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} Small change to move VM_INTRINSICS_DO out of vmSymbols.hpp into its own file. ------------- Commit messages: - Remove whitespaces - Update vmSymbols.hpp - Create vmIntrinsics.hpp Changes: https://git.openjdk.java.net/jdk/pull/160/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=160&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8243066 Stats: 1724 lines in 2 files changed: 878 ins; 846 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/160.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/160/head:pull/160 PR: https://git.openjdk.java.net/jdk/pull/160 From github.com+2249648+JohnTortugo at openjdk.java.net Tue Sep 15 15:08:17 2020 From: github.com+2249648+JohnTortugo at openjdk.java.net (John Tortugo) Date: Tue, 15 Sep 2020 15:08:17 GMT Subject: RFR: 8250668 : Clean up method_oop names in adlc Message-ID: Relates to: https://bugs.openjdk.java.net/browse/JDK-8250668 Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} Follow up from this thread: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039846.html Rename occurrences of 'method_oop' under `src/` to just `method'. ------------- Commit messages: - Rename 'method_oop' references to just 'method' Changes: https://git.openjdk.java.net/jdk/pull/164/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=164&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250668 Stats: 61 lines in 15 files changed: 4 ins; 0 del; 57 mod Patch: https://git.openjdk.java.net/jdk/pull/164.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/164/head:pull/164 PR: https://git.openjdk.java.net/jdk/pull/164 From bulasevich at openjdk.java.net Tue Sep 15 15:33:32 2020 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Tue, 15 Sep 2020 15:33:32 GMT Subject: RFR: 8252311: AArch64: save two words in itable lookup stub Message-ID: The change was reviewed on hotspot-compiler-dev, but I missed the time to complete the commit to the mercural repo. Can I get it approved once again? Issue: [JDK-8252311](https://bugs.openjdk.java.net/browse/JDK-8252311) Description: The interface method lookup stub becomes hot when interface calls are performed frequently. The stub assembly code can be made shorter (132->124 bytes) by using a pre-increment instruction variant. Review by Andrew Dinn && Andrew Haley: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039818.html http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039833.html For the reference, benchmark scores with higher iteration number: Neoverse Cnt Score Error -> Score Error Units InvokeInterface.bench 25 6163.804 ? 5.116 -> 6303.035 ? 5.450 ops/ms InvokeInterface.bench:L1-icache-loads 5 305.408 ? 1.895 -> 272.891 ? 0.750 #/op InvokeInterface.bench:iTLB-loads 5 221.755 ? 0.990 -> 207.635 ? 0.566 #/op InvokeInterface.bench:instructions 5 1035.468 ? 2.701 -> 953.466 ? 1.667 #/op ------------- Commit messages: - 8252311: AArch64: save two words in itable lookup stub Changes: https://git.openjdk.java.net/jdk/pull/189/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=189&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252311 Stats: 24 lines in 1 file changed: 5 ins; 10 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/189.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/189/head:pull/189 PR: https://git.openjdk.java.net/jdk/pull/189 From vladimir.x.ivanov at oracle.com Tue Sep 15 15:36:38 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 15 Sep 2020 18:36:38 +0300 Subject: RFR: 8253049: Enhance itable_stub for AArch64 and x86_64 In-Reply-To: References: <7640e033-f590-0b63-79e3-59dd5b96f55f@oracle.com> <522cf585-60c4-4662-bbbd-d51158d11f3a.kuaiwei.kw@alibaba-inc.com> <08236fa7-213b-a84f-a927-59b74baee5d8@oracle.com> Message-ID: <52ff5a6e-f134-8cd5-94a3-be6e0d5549bf@oracle.com> >> And speaking of the overall approach (as it is implemented now), IMO >> increased complexity doesn't worth it. If interface calls become a >> bottleneck, the problem lies not in itable stub, but the overall design >> which requires linear scan over itables. It's better to put the effort >> there than micro-optimizing the stub. > > Indeed. When I first came to HotSpot after working on GCJ for years > I was very surprised to see a linear scan used for interface dispatch. FTR Erik? has been looking into rewriting virtual dispatch logic: http://openjdk.java.net/jeps/8221828 Best regards, Vladimir Ivanov > > The code improvements look to be fairly minor. > From iklam at openjdk.java.net Tue Sep 15 15:57:38 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 15 Sep 2020 15:57:38 GMT Subject: RFR: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file In-Reply-To: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> References: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> Message-ID: <5ngJEecVLfvhSbX9PbaRHBvAJA2qRpqYGiBT3yhKsVw=.32367aa8-f288-4724-86b7-9a2baecad886@github.com> On Mon, 14 Sep 2020 23:00:06 GMT, John Tortugo wrote: > Relates to: https://bugs.openjdk.java.net/browse/JDK-8243066 > Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} > > Small change to move VM_INTRINSICS_DO out of vmSymbols.hpp into its own file. This looks good. I did a 3-way diff between the new and old versions of the files and vmIntrinsics.hpp has identical content as the removed part of vmSymbols.hpp. `#endif //SHARE_CLASSFILE_VMINTRINSICS_HPP` is missing in the new header file. I am surprised how that passed the build. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/160 From dtitov at openjdk.java.net Tue Sep 15 16:49:31 2020 From: dtitov at openjdk.java.net (Daniil Titov) Date: Tue, 15 Sep 2020 16:49:31 GMT Subject: RFR: 8241390: 'Deadlock' with VM_RedefineClasses::lock_classes() Message-ID: The change fixes a 'deadlock' situation in VM_RedefineClasses::lock_classes() when the current thread is in the middle of redefining the same class. The change is based on the fix [1] suggested in the Jira issue [2] comment. [1] http://cr.openjdk.java.net/~jiangli/8241390/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8241390 Testing: :jdk_instrument, tier1-tier3, and tier5 tests pass. ------------- Commit messages: - 8241390: 'Deadlock' with VM_RedefineClasses::lock_classes() Changes: https://git.openjdk.java.net/jdk/pull/190/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=190&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241390 Stats: 202 lines in 6 files changed: 193 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/190/head:pull/190 PR: https://git.openjdk.java.net/jdk/pull/190 From vlivanov at openjdk.java.net Tue Sep 15 16:55:47 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 15 Sep 2020 16:55:47 GMT Subject: RFR: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file In-Reply-To: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> References: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> Message-ID: <-pg1re505fpvfZXY_3Be7RyqmoQup1wt-5WDvWmFg6U=.e884c39a-16e0-4766-82b6-fddec49586ad@github.com> On Mon, 14 Sep 2020 23:00:06 GMT, John Tortugo wrote: > Relates to: https://bugs.openjdk.java.net/browse/JDK-8243066 > Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} > > Small change to move VM_INTRINSICS_DO out of vmSymbols.hpp into its own file. Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/160 From vladimir.x.ivanov at oracle.com Tue Sep 15 17:11:27 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 15 Sep 2020 20:11:27 +0300 Subject: RFR: 8253049: Enhance itable_stub for AArch64 and x86_64 In-Reply-To: <8dc563d3-7aff-48cc-b44f-30171562c208.kuaiwei.kw@alibaba-inc.com> References: <7640e033-f590-0b63-79e3-59dd5b96f55f@oracle.com> <522cf585-60c4-4662-bbbd-d51158d11f3a.kuaiwei.kw@alibaba-inc.com> <08236fa7-213b-a84f-a927-59b74baee5d8@oracle.com> <8dc563d3-7aff-48cc-b44f-30171562c208.kuaiwei.kw@alibaba-inc.com> Message-ID: >>????I?updated?my?test?cases?in?test/micro/org/openjdk/bench/vm/compiler/InterfaceCalls.java?.?My?tests?will?not?inline?interface?methods?and?most?cpu?are?used?by?itable_stub. >>?every?test?will?run?10?warmup?iterations?and?5?measure?iterations?for?one?score.?I?took?3?score?for?every?test. >>????Below?is?test?result?on?my?machines,?it?looks?slow?loop?has?more?improvement?than?origin?one. > > Good,?thanks?for?the?numbers.?I'm?curious?have?you?observed?any > improvements?on?larger?scale?benchmarks?or?real?world?apps? > > I'm?asking?because?linear?scan?is?already?far?from?optimal?when?there > are?many?superinterfaces?present. > > Kevin: itable_stub was found hot on several online applications. So I > started to work on this. Now I don't have chance to verify it online. So > I uses microbenchmarks to verify. I will > test with some benchmarks. That's unfortunate. It would be very helpful to confirm the results of the micro-benchmarks (nano-, in this particular case). >>????I?think?lookup_interface_method?can?be?reused?as?fast?path.?And?it?is?also?used?by?templateTable::invoke_interface?and?generate_method_handle_dispatch. >>?My?implementation?in?slow?path?need?more?registers?(6?registers?so?far),?I?need?to?check?if?there's?register?conflict?in?these?methods.?I'd?like?to?keep?a?separate >>?slow?path?implementation.?How?do?you?think?about?it? > > Frankly?speaking,?I'd?like?to?avoid?the?duplication. > > Kevin: Ok, I will try to merge them. > > Also,?absence?of?guarantees?about?order?of?interfaces?in?the?itable > complicates?things:?REFC?and?DECC?can?be?encountered?in?arbitrary?order > and?the?pass?should?take?that?into?account.?For?example,?I?don't?see > early?exit?on?success?in?slow?variant,?so?every?lookup?has?to?go?through > the?whole?itable?irrespective?of?whether?it?succeeds?or?fails.?I > attribute?that?to?the?complications?induced?by?aforementioned?aspect. > > Kevin: I use a counter for matching. If it reaches zero, the iteration > can exit early. Good. Thanks for the clarification. Alternatively, you could use 2 bits in the temp register to code the state. IMO it's clearer and more robust w.r.t. possible bugs. Or even explicitly encode the state in the code as an automaton by generating 3 loop variants (check REFC + check DECC + check both). But IMO it falls into over-engineering category :-) Also, on naming: I find it hard to reason about the logic. Registers are re-used for different purposes and the names don't help at all (even adds to the confusion). As an example: movptr(method_result, Address(recv_klass, holder_klass, Address::times_1)); > And?speaking?of?the?overall?approach?(as?it?is?implemented?now),?IMO > increased?complexity?doesn't?worth?it.?If?interface?calls?become?a > bottleneck,?the?problem?lies?not?in?itable?stub,?but?the?overall?design > which?requires?linear?scan?over?itables.?It's?better?to?put?the?effort > there?than?micro-optimizing?the?stub. > > Kevin: I agree we can improve itable design. My initial think is jvm may > reorder itable at safepoint. I can take it as a follow up optimization. Well, I would definitely prefer to avoid additional runtime changes (to sort interfaces in itables and verify their order later) just to support minor improvements in itable stubs. Best regards, Vladimir Ivanov > ------------------------------------------------------------------ > From:Vladimir Ivanov > Send Time:2020?9?15?(???) 17:03 > To:??(??) ; hotspot-dev > ; kuaiwei > ; hotspot-dev > ; hotspot-compiler-dev > > Subject:Re: RFR: 8253049: Enhance itable_stub for AArch64 and x86_64 > > > >????I?updated?my?test?cases?in?test/micro/org/openjdk/bench/vm/compiler/InterfaceCalls.java?.?My?tests?will?not?inline?interface?methods?and?most?cpu?are?used?by?itable_stub. > >?every?test?will?run?10?warmup?iterations?and?5?measure?iterations?for?one?score.?I?took?3?score?for?every?test. > >????Below?is?test?result?on?my?machines,?it?looks?slow?loop?has?more?improvement?than?origin?one. > > Good,?thanks?for?the?numbers.?I'm?curious?have?you?observed?any > improvements?on?larger?scale?benchmarks?or?real?world?apps? > > I'm?asking?because?linear?scan?is?already?far?from?optimal?when?there > are?many?superinterfaces?present. > > >????I?think?lookup_interface_method?can?be?reused?as?fast?path.?And?it?is?also?used?by?templateTable::invoke_interface?and?generate_method_handle_dispatch. > >?My?implementation?in?slow?path?need?more?registers?(6?registers?so?far),?I?need?to?check?if?there's?register?conflict?in?these?methods.?I'd?like?to?keep?a?separate > >?slow?path?implementation.?How?do?you?think?about?it? > > Frankly?speaking,?I'd?like?to?avoid?the?duplication. > > Also,?absence?of?guarantees?about?order?of?interfaces?in?the?itable > complicates?things:?REFC?and?DECC?can?be?encountered?in?arbitrary?order > and?the?pass?should?take?that?into?account.?For?example,?I?don't?see > early?exit?on?success?in?slow?variant,?so?every?lookup?has?to?go?through > > the?whole?itable?irrespective?of?whether?it?succeeds?or?fails.?I > attribute?that?to?the?complications?induced?by?aforementioned?aspect. > > And?speaking?of?the?overall?approach?(as?it?is?implemented?now),?IMO > increased?complexity?doesn't?worth?it.?If?interface?calls?become?a > bottleneck,?the?problem?lies?not?in?itable?stub,?but?the?overall?design > which?requires?linear?scan?over?itables.?It's?better?to?put?the?effort > there?than?micro-optimizing?the?stub. > > But?I'm?happy?to?change?my?mind?if?the?rewritten?implementation?makes?it > > easier?to?reason?about?the?code. > > (FTR?subtype?checks?suffer?from?a?similar?problem:?unless > Klass::_secondary_super_cache?catches?it,?subtype?check?for?an?interface > > does?a?linear?scan?over?_secondary_supers?array.) > > Best?regards, > Vladimir?Ivanov > > > >?------------------------------------------------------------------ > >?From:Vladimir?Ivanov? > >?Send?Time:2020?9?14?(???)?22:10 > >?To:kuaiwei?;?hotspot-dev?;?hotspot-compiler-dev? > >?Subject:Re:?RFR:?8253049:?Enhance?itable_stub?for?AArch64?and?x86_64 > > > >?Hi?Kevin, > > > >?Very?interesting?observations.?I?like?the?idea?to?optimize?for?the?case > >?when?REFC?==?DECC. > > > >?Fusing?2?passes?over?the?itable?into?one?does?look?attractive,?but?I'm > >?not?sure?the?proposed?variant?is?correct.?I?suggest?to?split?the?patch > >?into?2?enhancements?and?handle?them?separately. > > > >?I'm?curious?what?kind?of?benchmarks?you?used?and?what?are?the > >?improvements?observed?with?the?patch. > > > >?One?suggestion?about?the?implementation: > > > >?src/hotspot/cpu/x86/macroAssembler_x86.cpp: > > > >?+void?MacroAssembler::lookup_interface_method_in_stub(Register?recv_klass, > > > >?I'd?like?to?avoid?having?2?independent?implementations?of?itable?lookup > >?(MacroAssembler::lookup_interface_method_in_stub()?and > >?MacroAssembler::lookup_interface_method()).?It?would?be?nice?to?keep?the > >?implementation?unified?between?itable?and?MethodHandle?linkToInterface > >?linker?stubs. > > > >?What?MacroAssembler::lookup_interface_method(...,?true > >?/*return_method*/)?does?is?interface?method?lookup?w/o?proper?subtype > >?check?and?it?is?equivalent?to?fast?loop?in > >?MacroAssembler::lookup_interface_method_in_stub(). > > > >?As?a?possible?path?forward,?you?could?introduce?the?fast?path?check > >?first?by?moving?the?fast?path?check?into > >?VtableStubs::create_itable_stub()?and?guard?the?first?path?over?the > >?itable.?It?would?make?the?type?checking?pass?over?itable?optional?based > >?on?runtime?check. > > > >?Then?you?could?refactor?MacroAssembler::lookup_interface_method()?to > >?optionally?do?REFC?and?DECC?checks?on?every?iteration?and?migrate > >?VtableStubs::create_itable_stub()??and > >?MethodHandles::generate_method_handle_dispatch()?to?it. > > > >?Best?regards, > >?Vladimir?Ivanov > > > >?On?14.09.2020?13:52,?kuaiwei?wrote: > >>?Now?itable_stub?will?go?through?instanceKlass's?itable?twice?to?look?up?a?method?entry.?resolved?klass?is?used?for?type > >>?checking?and?method?holder?klass?is?used?to?find?method?entry.?In?many?cases?,?we?observed?resolved?klass?is?as?same?as > >>?holder?klass.?So?we?can?improve?itable?stub?based?on?it.?If?they?are?same?klass,?stub?uses?a?fast?loop?to?check?only > >>?one?klass.?If?not,?a?slow?loop?is?used?to?checking?both?klasses. > >> > >>?Even?entering?in?slow?loop,?new?implementation?can?be?better?than?old?one?in?some?cases.?Because?new?stub?just?need?go > >>?through?itable?once?and?reduce?memory?operations. > >> > >> > >>?bug: https://bugs.openjdk.java.net/browse/JDK-8253049 > >> > >>?------------- > >> > >>?Commit?messages: > >>????-?8253049:?Enhance?itable_stub?for?AArch64?and?x86_64 > >> > >>?Changes: https://git.openjdk.java.net/jdk/pull/128/files > >>????Webrev: > https://webrevs.openjdk.java.net/?repo=jdk&pr=128&range=00 > >>?????Issue: https://bugs.openjdk.java.net/browse/JDK-8253049 > >>?????Stats:?220?lines?in?7?files?changed:?172?ins;?35?del;?13?mod > >>?????Patch: https://git.openjdk.java.net/jdk/pull/128.diff > >>?????Fetch:?git?fetch > https://git.openjdk.java.net/jdk?pull/128/head:pull/128 > >> > >>?PR: https://git.openjdk.java.net/jdk/pull/128 > >> > > > > From tschatzl at openjdk.java.net Tue Sep 15 17:24:21 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 15 Sep 2020 17:24:21 GMT Subject: RFR: 8253177: outputStream not declared in markWord.hpp Message-ID: Hi all, can I have reviews for this trivial change that adds outputStream declaration(s) to the markWord files? Apparently they have been missing forever, and in some last-minute testing about some unrelated change the ARM compilers complained about it. Testing: local compilation, tier1 Thanks, Thomas ------------- Commit messages: - Initial version Changes: https://git.openjdk.java.net/jdk/pull/188/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=188&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253177 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/188.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/188/head:pull/188 PR: https://git.openjdk.java.net/jdk/pull/188 From iklam at openjdk.java.net Tue Sep 15 18:39:19 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 15 Sep 2020 18:39:19 GMT Subject: RFR: 8253177: outputStream not declared in markWord.hpp In-Reply-To: References: Message-ID: <7NJXw4g-UL4NDpp9vzVO5jNZxFSGg-DkpfOlmCApevc=.0f453dbe-84ea-4429-a572-3ba9e3f17044@github.com> On Tue, 15 Sep 2020 15:16:41 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this trivial change that adds outputStream declaration(s) to the markWord files? Apparently they > have been missing forever, and in some last-minute testing about some unrelated change the ARM compilers complained > about it. > > Testing: local compilation, tier1 > > Thanks, > Thomas Looks good and I agree this is a trivial change. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/188 From tschatzl at openjdk.java.net Tue Sep 15 19:01:36 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 15 Sep 2020 19:01:36 GMT Subject: RFR: 8253177: outputStream not declared in markWord.hpp In-Reply-To: <7NJXw4g-UL4NDpp9vzVO5jNZxFSGg-DkpfOlmCApevc=.0f453dbe-84ea-4429-a572-3ba9e3f17044@github.com> References: <7NJXw4g-UL4NDpp9vzVO5jNZxFSGg-DkpfOlmCApevc=.0f453dbe-84ea-4429-a572-3ba9e3f17044@github.com> Message-ID: <5Es8mAUZ2cq2HewRP-t316vP2zW2PtO5FPaA7EkTbZ0=.529f768b-f308-4908-a214-4d2a5e62c983@github.com> On Tue, 15 Sep 2020 18:37:01 GMT, Ioi Lam wrote: >> Hi all, >> >> can I have reviews for this trivial change that adds outputStream declaration(s) to the markWord files? Apparently they >> have been missing forever, and in some last-minute testing about some unrelated change the ARM compilers complained >> about it. >> >> Testing: local compilation, tier1 >> >> Thanks, >> Thomas > > Looks good and I agree this is a trivial change. Thanks for your review ------------- PR: https://git.openjdk.java.net/jdk/pull/188 From tschatzl at openjdk.java.net Tue Sep 15 19:01:37 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 15 Sep 2020 19:01:37 GMT Subject: Integrated: 8253177: outputStream not declared in markWord.hpp In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 15:16:41 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this trivial change that adds outputStream declaration(s) to the markWord files? Apparently they > have been missing forever, and in some last-minute testing about some unrelated change the ARM compilers complained > about it. > > Testing: local compilation, tier1 > > Thanks, > Thomas This pull request has now been integrated. Changeset: 46598c86 Author: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/46598c86 Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod 8253177: outputStream not declared in markWord.hpp Reviewed-by: iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/188 From minqi at openjdk.java.net Tue Sep 15 19:15:50 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 15 Sep 2020 19:15:50 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive Message-ID: This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses function. Tests: tier1-4 ------------- Commit messages: - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - Merge remote-tracking branch 'upstream/master' into jdk-8247536 - Merge remote-tracking branch 'upstream/master' into jdk-8247536 - Merge remote-tracking branch 'origin/jdk-8252689' - 8252689: Classes are loaded from jrt:/java.base even when CDS is used - 8252689: Classes are loaded from jrt:/java.base even when CDS is used - 8252689: Classes are loaded from jrt:/java.base even when CDS is used Changes: https://git.openjdk.java.net/jdk/pull/193/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247536 Stats: 368 lines in 18 files changed: 344 ins; 13 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/193.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193 PR: https://git.openjdk.java.net/jdk/pull/193 From github.com+2249648+JohnTortugo at openjdk.java.net Tue Sep 15 19:18:12 2020 From: github.com+2249648+JohnTortugo at openjdk.java.net (John Tortugo) Date: Tue, 15 Sep 2020 19:18:12 GMT Subject: RFR: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file In-Reply-To: <-pg1re505fpvfZXY_3Be7RyqmoQup1wt-5WDvWmFg6U=.e884c39a-16e0-4766-82b6-fddec49586ad@github.com> References: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> <-pg1re505fpvfZXY_3Be7RyqmoQup1wt-5WDvWmFg6U=.e884c39a-16e0-4766-82b6-fddec49586ad@github.com> Message-ID: On Tue, 15 Sep 2020 16:52:34 GMT, Vladimir Ivanov wrote: >> Relates to: https://bugs.openjdk.java.net/browse/JDK-8243066 >> Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} >> >> Small change to move VM_INTRINSICS_DO out of vmSymbols.hpp into its own file. > > Looks good. Before integrating this PR I need to include a change requested by @coleenp on the maillist: There's also vmIntrinsics code in vmSymbols.cpp, so there should also be a vmIntrinsics.cpp file. ------------- PR: https://git.openjdk.java.net/jdk/pull/160 From coleenp at openjdk.java.net Tue Sep 15 19:30:53 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Sep 2020 19:30:53 GMT Subject: RFR: 8250668 : Clean up method_oop names in adlc In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 05:46:21 GMT, John Tortugo wrote: > Relates to: https://bugs.openjdk.java.net/browse/JDK-8250668 > Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} > Follow up from this thread: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039846.html > > Rename occurrences of 'method_oop' under `src/` to just `method'. Looks good! You found a couple that I missed as well. Thank you! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/164 From coleenp at openjdk.java.net Tue Sep 15 20:04:56 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Sep 2020 20:04:56 GMT Subject: RFR: 8241390: 'Deadlock' with VM_RedefineClasses::lock_classes() In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 16:43:01 GMT, Daniil Titov wrote: > The change fixes a 'deadlock' situation in VM_RedefineClasses::lock_classes() when the current thread is in the middle > of redefining the same class. The change is based on the fix [1] suggested in the Jira issue [2] comment. > [1] http://cr.openjdk.java.net/~jiangli/8241390/webrev.00/ > [2] https://bugs.openjdk.java.net/browse/JDK-8241390 > > Testing: :jdk_instrument, tier1-tier3, and tier5 tests pass. Changes requested by coleenp (Reviewer). test/jdk/java/lang/instrument/MakeAgentJAR.sh line 1: > 1: #!/bin/sh There are tests in test/hotspot/jtreg/serviceability/jvmti/RedefineClasses that don't use shell scripts that are much better. Can you add this test using that framework instead? src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 159: > 157: if (!cls->contains(def_ik)) { > 158: def_ik->set_is_being_redefined(false); > 159: } Ok, so adding the Klass to the thread local list for each recursion works like ref counting. Can't think of a simpler way to do this. Looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/190 From gziemski at openjdk.java.net Tue Sep 15 20:57:37 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 15 Sep 2020 20:57:37 GMT Subject: RFR: 8081833: Clean up JVMFlag getter/setter code In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 05:01:13 GMT, Ioi Lam wrote: > This is a follow to [JDK-8243208 Clean up JVMFlag implementation](https://bugs.openjdk.java.net/browse/JDK-8243208). > > I try to use templates and inheritance (and a bit of macros) to get rid of the large amount of duplicated code in the > JVMFlag getters/setters. > Stefan Karlsson and I have tried this several times already, but I think the current attempt probably has the least > amount of hacks and most functionality: > - Type safety is enforced up to the point of loading/storing `JVMFlag::_addr`, without any unchecked typecasts. > - Runtime type checking is implemented by the `JVM_FLAG_TYPE(t)` macro (see jvmFlagAccess.hpp), by passing along an > integer (`JVMFlag::TYPE_int`, etc). This is more efficient than previous attempts that passed along a function pointer > (see http://cr.openjdk.java.net/~stefank/8081833/webrev.04/) > - The old `JVMFlag::xxxAtPut` functions were undocumented. There are actually two groups that have different usage. I > added documentation in jvmFlagAccess.hpp to explain this. > - I got rid of the `JVMFlagEx` class and moved the code into `JVMFlag`. This is possible with C++11 which allows forward > declaration of `enum JVMFlagsEnum : int;` > - I changed `JVMFlag::_type` from a string into an enum. I am surprised this had lasted for over 20 years. > - I also changed `JVMFlag` from a struct into a class and made some fields private. I probably will do more cleanup in a > separate RFE. > > Please start with jvmFlagAccess.hpp, jvmFlagAccess.hpp and then globals_extension.hpp. > > Probably not everyone is in love with the `JVM_FLAG_TYPE(t)` macro. I'll be happy to try out alternatives. Changes requested by gziemski (Committer). src/hotspot/share/runtime/flags/jvmFlagLimit.cpp line 156: > 154: for (int i = 0; i < NUM_JVMFlagsEnum; i++) { > 155: JVMFlagsEnum flag_enum = static_cast(i); > 156: if (get_range_at(flag_enum) != NULL && VMFlagAccess::check_range(JVMFlag::flag_from_enum(flag_enum) will check for "get_range_at(flag_enum) != NULL", so no need for this check here? src/hotspot/share/runtime/globals_extension.hpp line 38: > 36: #define FLAG_MEMBER_ENUM_(name) FLAG_MEMBER_ENUM(name), > 37: > 38: #define FLAG_MEMBER_ENUM_DECLARE(type, name, ...) FLAG_MEMBER_ENUM_(name) We have other macros named: DECLARE_PRODUCT_FLAG MATERIALIZE_PRODUCT_FLAG Can we rename this one as ENUMERATE_FLAG_MEMBER, (with the verb first in the name) to be more clear and consistent? src/hotspot/share/runtime/globals_extension.hpp line 59: > 57: } > 58: > 59: #define FLAG_MEMBER_SET_DECLARE(type, name, ...) FLAG_MEMBER_SET_(type, name) We have other macros named: DECLARE_PRODUCT_FLAG MATERIALIZE_PRODUCT_FLAG Can we rename this one as SET_FLAG_MEMBER or DECLARE_FLAG_MEMBER, (with the verb first in the name) to be more clear and consistent? src/hotspot/share/runtime/flags/jvmFlag.cpp line 523: > 521: #define PRODUCT_FLAG_INIT( type, name, value, ...) JVMFlag(FLAG_MEMBER_ENUM(name), FLAG_TYPE(type), XSTR(name), > (void*)&name, PRODUCT_KIND, __VA_ARGS__), 522: #define PRODUCT_FLAG_INIT_PD(type, name, ...) > JVMFlag(FLAG_MEMBER_ENUM(name), FLAG_TYPE(type), XSTR(name), (void*)&name, PRODUCT_KIND_PD, __VA_ARGS__), 523: #define > NOTPROD_FLAG_INIT( type, name, value, ...) JVMFlag(FLAG_MEMBER_ENUM(name), FLAG_TYPE(type), XSTR(name), (void*)&name, > NOTPROD_KIND, __VA_ARGS__), We have other macros named: DECLARE_PRODUCT_FLAG MATERIALIZE_PRODUCT_FLAG Can we rename these macros: DEVELOP_FLAG_INIT --> INITIALIZE_DEVELOP_FLAG DEVELOP_FLAG_INIT_PD --> INITIALIZE_PD_DEVELOP_FLAG etc. ? src/hotspot/share/runtime/flags/jvmFlag.hpp line 128: > 126: TYPE_ccstrlist, > 127: NUM_FLAG_TYPES > 128: }; Are those macros really needed here and better than simply saying: enum FlagType : int { TYPE_bool, TYPE_int, TYPE_uint, TYPE_intx, TYPE_uintx, TYPE_uint64_t, TYPE_size_t, TYPE_double, TYPE_ccstr, TYPE_ccstrlist, NUM_FLAG_TYPES }; src/hotspot/share/runtime/flags/jvmFlag.hpp line 259: > 257: bool is_writeable() const { return is_manageable(); } > 258: // All flags except "manageable" are assumed to be internal flags. > 259: bool is_external() const { return is_manageable(); } Do we need is_writeable() and/or is_external() if all they do is return is_manageable() ? ------------- PR: https://git.openjdk.java.net/jdk/pull/163 From adityam at openjdk.java.net Tue Sep 15 22:32:13 2020 From: adityam at openjdk.java.net (Aditya Mandaleeka) Date: Tue, 15 Sep 2020 22:32:13 GMT Subject: RFR: 8250668 : Clean up method_oop names in adlc In-Reply-To: References: Message-ID: <0wZyOf4k5nHBLn9iP_gSf2gN4Gn4u57khUCVv5euNbA=.34077599-19d8-4b79-9c8b-20550bbff47f@github.com> On Tue, 15 Sep 2020 05:46:21 GMT, John Tortugo wrote: > Relates to: https://bugs.openjdk.java.net/browse/JDK-8250668 > Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} > Follow up from this thread: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039846.html > > Rename occurrences of 'method_oop' under `src/` to just `method'. Marked as reviewed by adityam (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/164 From mandy.chung at oracle.com Tue Sep 15 23:04:40 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 15 Sep 2020 16:04:40 -0700 Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive In-Reply-To: References: Message-ID: <7047f476-0635-58f2-fc0f-163e69f56ac4@oracle.com> src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java 367 /** 368 * called from vm to generate MethodHandle holder classes 369 * @return @code { Object[] } if holder classes can be generated. 370 * @param lines the output lines from @code { VM.cdsTraceResolve } 371 */ @code {....} is wrong syntax. It should be {@code ....} 372 static Object[] cdsGenerateHolderClasses(String[] lines) { this can be made private as it's invoked by VM only. Can you move it to the end of the file. 373 try { 374 Map result = generateHolderClasses(Arrays.stream(lines)); 375 if (result == null) { 376 return null; 377 } generateHolderClasses should never return null and so line 371-377 can be dropped. ? I also suggest to add in the generateHolderClasses method to add Objects.requireNonNull(traces). 379???????????? Object[] ret_array = new Object[size * 2]; Rename `ret_array` to retArray to follow the naming convention using camel case. src/java.base/share/classes/jdk/internal/misc/VM.java 457 isDumpLoadedClassListSetAndOpen = isDumpLoadedClassListSetAndOpen0(); This should be cached in the caller who checks if -XX:+DumpLoadedClassList instead of every VM initialization. Since there are many CDS-related methods, I think it's time to introduce a new CDS class for these methods to reside (maybe jdk.internal.vm.CDS?). I suggest to add CDS:logTraceResolve(String line) method that will check if isDumpLoadedClassListSetAndOpen is true, then call the native cdsTraceResolve (or whatever name). This way, GenerateJLIClassesHelper can simply call CDS::logTraceResolve. 493 * Output to DumpLoadedClassList, format is simimar to LF_RESOLVE s/simimar/similar 494 * @see InvokerBytecodeGenerator 495 * @param line the line to output. @see is typically placed after @param. Should it say @see java.lang.invoke.GenerateJLIClassesHelper::traceLambdaForm instead of InvokerBytecodeGenerator? Mandy On 9/15/20 12:15 PM, Yumin Qi wrote: > This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous > webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the > regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. > > Tests: tier1-4 > > ------------- > > Commit messages: > - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive > - Merge remote-tracking branch 'upstream/master' into jdk-8247536 > - Merge remote-tracking branch 'upstream/master' into jdk-8247536 > - Merge remote-tracking branch 'origin/jdk-8252689' > - 8252689: Classes are loaded from jrt:/java.base even when CDS is used > - 8252689: Classes are loaded from jrt:/java.base even when CDS is used > - 8252689: Classes are loaded from jrt:/java.base even when CDS is used > > Changes: https://git.openjdk.java.net/jdk/pull/193/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8247536 > Stats: 368 lines in 18 files changed: 344 ins; 13 del; 11 mod > Patch: https://git.openjdk.java.net/jdk/pull/193.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193 > > PR: https://git.openjdk.java.net/jdk/pull/193 From iignatyev at openjdk.java.net Wed Sep 16 00:27:17 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 16 Sep 2020 00:27:17 GMT Subject: RFR: 8253207: enable problemlists jcheck's check Message-ID: problemlists[[1]] check verifies that there are no problem-list entries w/ the bug-id used in the commit message. [1]: https://github.com/openjdk/skara/pull/518 ------------- Commit messages: - 8253207: enable problemlists jcheck's check Changes: https://git.openjdk.java.net/jdk/pull/196/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=196&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253207 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/196.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/196/head:pull/196 PR: https://git.openjdk.java.net/jdk/pull/196 From github.com+2249648+JohnTortugo at openjdk.java.net Wed Sep 16 04:05:55 2020 From: github.com+2249648+JohnTortugo at openjdk.java.net (John Tortugo) Date: Wed, 16 Sep 2020 04:05:55 GMT Subject: RFR: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file [v2] In-Reply-To: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> References: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> Message-ID: > Relates to: https://bugs.openjdk.java.net/browse/JDK-8243066 > Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} > > Small change to move VM_INTRINSICS_DO out of vmSymbols.hpp into its own file. John Tortugo has updated the pull request incrementally with one additional commit since the last revision: Add vmIntrinsics.cpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/160/files - new: https://git.openjdk.java.net/jdk/pull/160/files/90da335f..8c87b655 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=160&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=160&range=00-01 Stats: 1683 lines in 3 files changed: 864 ins; 819 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/160.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/160/head:pull/160 PR: https://git.openjdk.java.net/jdk/pull/160 From github.com+2249648+JohnTortugo at openjdk.java.net Wed Sep 16 05:14:51 2020 From: github.com+2249648+JohnTortugo at openjdk.java.net (John Tortugo) Date: Wed, 16 Sep 2020 05:14:51 GMT Subject: RFR: 8250668 : Clean up method_oop names in adlc In-Reply-To: References: Message-ID: <7s1eCYS66oxdMs2nvJKlPTu4ntXk48J_J-oyy7CxjKY=.1c6f53c6-ffe7-47d8-954b-c5ae8cf93dc4@github.com> On Tue, 15 Sep 2020 19:28:14 GMT, Coleen Phillimore wrote: >> Relates to: https://bugs.openjdk.java.net/browse/JDK-8250668 >> Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} >> Follow up from this thread: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039846.html >> >> Rename occurrences of 'method_oop' under `src/` to just `method'. > > Looks good! You found a couple that I missed as well. Thank you! @coleenp - Can you please merge this PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/164 From github.com+2249648+JohnTortugo at openjdk.java.net Wed Sep 16 05:48:43 2020 From: github.com+2249648+JohnTortugo at openjdk.java.net (John Tortugo) Date: Wed, 16 Sep 2020 05:48:43 GMT Subject: RFR: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file [v3] In-Reply-To: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> References: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> Message-ID: <7XFYgoof_hvcuhJGHwwi3W8nv5W6D2mkDO8Lvd9kKy8=.c6505c5f-3123-4748-8f91-631e15d4dd08@github.com> > Relates to: https://bugs.openjdk.java.net/browse/JDK-8243066 > Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} > > Small change to move VM_INTRINSICS_DO out of vmSymbols.hpp into its own file. John Tortugo has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'jdk-8243066' of https://github.com/JohnTortugo/jdk into jdk-8243066 - Add vmIntrinsics.cpp. Fix commit author. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/160/files - new: https://git.openjdk.java.net/jdk/pull/160/files/8c87b655..868eee7a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=160&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=160&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/160.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/160/head:pull/160 PR: https://git.openjdk.java.net/jdk/pull/160 From github.com+2249648+JohnTortugo at openjdk.java.net Wed Sep 16 05:55:31 2020 From: github.com+2249648+JohnTortugo at openjdk.java.net (John Tortugo) Date: Wed, 16 Sep 2020 05:55:31 GMT Subject: RFR: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file [v4] In-Reply-To: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> References: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> Message-ID: > Relates to: https://bugs.openjdk.java.net/browse/JDK-8243066 > Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} > > Small change to move VM_INTRINSICS_DO out of vmSymbols.hpp into its own file. John Tortugo has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/160/files - new: https://git.openjdk.java.net/jdk/pull/160/files/868eee7a..e711a53e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=160&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=160&range=02-03 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/160.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/160/head:pull/160 PR: https://git.openjdk.java.net/jdk/pull/160 From thartmann at openjdk.java.net Wed Sep 16 05:56:49 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 16 Sep 2020 05:56:49 GMT Subject: RFR: 8250668 : Clean up method_oop names in adlc In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 05:46:21 GMT, John Tortugo wrote: > Relates to: https://bugs.openjdk.java.net/browse/JDK-8250668 > Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} > Follow up from this thread: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039846.html > > Rename occurrences of 'method_oop' under `src/` to just `method'. Looks good. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/164 From github.com+2249648+JohnTortugo at openjdk.java.net Wed Sep 16 05:56:50 2020 From: github.com+2249648+JohnTortugo at openjdk.java.net (John Tortugo) Date: Wed, 16 Sep 2020 05:56:50 GMT Subject: Integrated: 8250668 : Clean up method_oop names in adlc In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 05:46:21 GMT, John Tortugo wrote: > Relates to: https://bugs.openjdk.java.net/browse/JDK-8250668 > Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} > Follow up from this thread: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039846.html > > Rename occurrences of 'method_oop' under `src/` to just `method'. This pull request has now been integrated. Changeset: 2caa20a7 Author: Cesar Committer: Tobias Hartmann URL: https://git.openjdk.java.net/jdk/commit/2caa20a7 Stats: 61 lines in 15 files changed: 0 ins; 4 del; 57 mod 8250668: Clean up method_oop names in adlc Reviewed-by: coleenp, adityam, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/164 From yueshi.zwj at alibaba-inc.com Wed Sep 16 06:11:39 2020 From: yueshi.zwj at alibaba-inc.com (Joshua Zhu) Date: Wed, 16 Sep 2020 14:11:39 +0800 Subject: RFR: 8253048: AArch64: When CallLeaf, no need to preserve callee-saved registers in caller In-Reply-To: <005501d68a5c$9617e120$c247a360$@alibaba-inc.com> References: <9K43aYMMk0zdBfxGBwRA336lvjqGZyLFtZcQKVWLOec=.4a194ce2-db80-4dcc-9ef2-ed2a0d2cd088@github.com> <6f6717b1-1d91-657b-d28c-ecbb4b7bb33a@redhat.com> <005501d68a5c$9617e120$c247a360$@alibaba-inc.com> Message-ID: <001201d68bf0$3dc71f00$b9555d00$@alibaba-inc.com> > > > - 8253048: AArch64: When CallLeaf, no need to preserve callee-saved > > > registers in caller > > > > > > Changes: https://git.openjdk.java.net/jdk/pull/129/files > > > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=129&range=00 > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8253048 > > > Stats: 22 lines in 2 files changed: 0 ins; 0 del; 22 mod > > > Patch: https://git.openjdk.java.net/jdk/pull/129.diff > > > Fetch: git fetch https://git.openjdk.java.net/jdk > > > pull/129/head:pull/129 > > > > > > PR: https://git.openjdk.java.net/jdk/pull/129 > > > > That looks right. I take it that you've checked everywhere else for > > misuse of callee-saved vector registers. > > Andrew, Thanks a lot for your review. > Yes. I checked all occurrences of "V8-V15" in aarch64 codes. > Andrew, can I get this change approved? Thanks. Best Regards, Joshua From sspitsyn at openjdk.java.net Wed Sep 16 06:52:16 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 16 Sep 2020 06:52:16 GMT Subject: RFR: 8241390: 'Deadlock' with VM_RedefineClasses::lock_classes() In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 20:02:33 GMT, Coleen Phillimore wrote: >> The change fixes a 'deadlock' situation in VM_RedefineClasses::lock_classes() when the current thread is in the middle >> of redefining the same class. The change is based on the fix [1] suggested in the Jira issue [2] comment. >> [1] http://cr.openjdk.java.net/~jiangli/8241390/webrev.00/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8241390 >> >> Testing: :jdk_instrument, tier1-tier3, and tier5 tests pass. > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 159: > >> 157: if (!cls->contains(def_ik)) { >> 158: def_ik->set_is_being_redefined(false); >> 159: } > > Ok, so adding the Klass to the thread local list for each recursion works like ref counting. Can't think of a simpler > way to do this. Looks good. Yes, the same class can be pushed to the list multiple times (not more than once by each recursive redefinition). It'd make sense to add a comment about it as it is not obvious. > test/jdk/java/lang/instrument/MakeAgentJAR.sh line 1: > >> 1: #!/bin/sh > > There are tests in test/hotspot/jtreg/serviceability/jvmti/RedefineClasses that don't use shell scripts that are much > better. Can you add this test using that framework instead? I'm second for this suggestion from Coleen to get rid of the shell script in the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/190 From sspitsyn at openjdk.java.net Wed Sep 16 06:59:02 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 16 Sep 2020 06:59:02 GMT Subject: RFR: 8241390: 'Deadlock' with VM_RedefineClasses::lock_classes() In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 20:02:38 GMT, Coleen Phillimore wrote: >> The change fixes a 'deadlock' situation in VM_RedefineClasses::lock_classes() when the current thread is in the middle >> of redefining the same class. The change is based on the fix [1] suggested in the Jira issue [2] comment. >> [1] http://cr.openjdk.java.net/~jiangli/8241390/webrev.00/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8241390 >> >> Testing: :jdk_instrument, tier1-tier3, and tier5 tests pass. > > Changes requested by coleenp (Reviewer). The identifier 'cls' does not reflect the nature of the object and needs to be replaces with something like: classes, redef_classes or classes_list This impacts the files: jvmtiThreadState.hpp and jvmtiRedefineClasses.cpp. ------------- PR: https://git.openjdk.java.net/jdk/pull/190 From patricio.chilano.mateo at oracle.com Wed Sep 16 08:20:08 2020 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Wed, 16 Sep 2020 05:20:08 -0300 Subject: RFR: 8238761: Asynchronous handshakes In-Reply-To: References: Message-ID: Hi Robbin, Changes look good to me! Some minor comments: src/hotspot/share/prims/jvmtiThreadState.cpp 222:?? assert(current_thread == get_thread() || 223:????????? SafepointSynchronize::is_at_safepoint() || 224: get_thread()->is_handshake_safe_for(current_thread), 225:????????? "call by myself / at safepoint / at handshake"); Extra current_thread == get_thread() is already handled by is_handshake_safe_for(). src/hotspot/share/prims/jvmtiEnvBase.cpp Same as above. src/hotspot/share/runtime/handshake.cpp 198:???? log_info(handshake)("Handshake \"%s\", Targeted threads: %d, Executed by targeted threads: %d, Total completion time: " JLONG_FORMAT " ns%s%s", 199:???????????????????????? name, targets, 200:???????????????????????? targets - vmt_executed, In the calls to log_handshake_info() in VM_HandshakeAllThreads and Handshake::execute() we are passing as vmt_executed the number of handshakes that the driver executed which could be more than the targets parameter. So the operation "targets - vmt_executed" to calculate the handshakes executed by the targets would no longer be valid. Personally I would just leave ProcessResult as an enum and log as before. We still have a log_trace() in try_process(), so that already keeps track of extra handshakes executed by the handshaker. src/hotspot/share/runtime/handshake.cpp 387:???? NoSafepointVerifier nsv; 388:???? process_self_inner(); 389:?? } Shouldn't NoSafepointVerifier be placed before the execution of the handshake closure so that we also cover the case when the handshake is executed by the handshaker? As in: // Only actually execute the operation for non terminated threads. if (!thread->is_terminated()) { ??? NoSafepointVerifier nsv; ??? _handshake_cl->do_thread(thread); } src/hotspot/share/runtime/interfaceSupport.inline.hpp 156:???? // Threads shouldn't block if they are in the middle of printing, but... 157: ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); What's the issue of having NoSafepointVerifier inside the handshake? Thanks! Patricio On 9/15/20 4:39 AM, Robbin Ehn wrote: > This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes > are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) > Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an > arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a > singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first > pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first > pointer also CAS. > > The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake operations matching > the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything except asynchronous > handshakes. In this initial change-set there is no need to do any other filtering. If needed filtering can easily be > exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake operation to be done > out-order. Since the filter determins who execute the operation and not the invoked method, there is now only one > method to call when handshaking one thread. > > Some comments about the changes: > - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake > all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much > worse then this. > > - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that > thread. > > - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a > handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. > > - Added WB testing method. > > - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. > > - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. > > - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a > safepoint and half of them after, in many handshake all operations. > > - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. > > - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the > moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. > > - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to the NoSafepointVerifyer. > > - Added filtered queue and gtest for it. > > Passes multiple t1-8 runs. > Been through some pre-reviwing. > > ------------- > > Commit messages: > - Rebase version 1.0 > > Changes: https://git.openjdk.java.net/jdk/pull/151/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=151&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8238761 > Stats: 1047 lines in 24 files changed: 693 ins; 150 del; 204 mod > Patch: https://git.openjdk.java.net/jdk/pull/151.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/151/head:pull/151 > > PR: https://git.openjdk.java.net/jdk/pull/151 From stefank at openjdk.java.net Wed Sep 16 12:24:53 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 16 Sep 2020 12:24:53 GMT Subject: Integrated: 8253162: Make frame::oops_do const In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 11:08:55 GMT, Stefan Karlsson wrote: > Make frame::oops_do const, so that we can use a const frame& receiver when appropriate. With this, we can get rid of > the temporary copies made just to make the frame variable non-const. See for example: > https://github.com/openjdk/zgc/blob/c4765b5599d07124410f8a80b1acef9349a998e0/src/hotspot/share/gc/z/zStackWatermark.cpp#L96 This pull request has now been integrated. Changeset: e2196f88 Author: Stefan Karlsson URL: https://git.openjdk.java.net/jdk/commit/e2196f88 Stats: 36 lines in 2 files changed: 1 ins; 0 del; 35 mod 8253162: Make frame::oops_do const Reviewed-by: kbarrett, coleenp, pliden ------------- PR: https://git.openjdk.java.net/jdk/pull/175 From jbhateja at openjdk.java.net Wed Sep 16 12:42:12 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 16 Sep 2020 12:42:12 GMT Subject: RFR: 8252848: Optimize small primitive arrayCopy operations through partial inlining using AVX-512 masked instructions [v3] In-Reply-To: References: Message-ID: > Summary: > > 1) Partial in-lining technique avoids call overhead penalty for sub-word type small array copy operations with size > less than 32 bytes. 2) At runtime, a conditional check based on copy length either calls an array-copy stub or executes > an optimized instruction sequence using AVX-512 masked instructions emitted at the call site. 3) New runtime flag > ArrayCopyPartialInlineSize=0/32(default)/64 bytes determines the maximum size for partial in-lining. > Performance Results: > System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz > Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java > ArrayCopyPartialInlineSize : 32 > > JMH | Block Size | Baseline (ns/op) | Partial Inling (ns/op) | Gain > -- | -- | -- | -- | -- > ArrayCopyAligned.testByte | 1 | 5.417 | 2.696 | 2.009272997 > ArrayCopyAligned.testByte | 3 | 5.494 | 2.702 | 2.03330866 > ArrayCopyAligned.testByte | 5 | 5.417 | 2.637 | 2.05422829 > ArrayCopyAligned.testByte | 10 | 5.343 | 2.703 | 1.976692564 > ArrayCopyAligned.testByte | 20 | 5.837 | 2.636 | 2.214339909 > ArrayCopyAligned.testByte | 70 | 5.86 | 6 | 0.976666667 > ArrayCopyAligned.testByte | 150 | 6.766 | 6.906 | 0.979727773 > ArrayCopyAligned.testByte | 300 | 7.605 | 7.952 | 0.956363179 > ArrayCopyAligned.testByte | 600 | 11.989 | 12.007 | 0.998500874 > ArrayCopyAligned.testByte | 1200 | 16.447 | 16.585 | 0.991679228 > ArrayCopyAligned.testChar | 1 | 5.02 | 2.828 | 1.775106082 > ArrayCopyAligned.testChar | 3 | 5.129 | 2.762 | 1.85698769 > ArrayCopyAligned.testChar | 5 | 5.041 | 2.762 | 1.82512672 > ArrayCopyAligned.testChar | 10 | 5.716 | 2.762 | 2.069514844 > ArrayCopyAligned.testChar | 20 | 5.111 | 5.399 | 0.946656788 > ArrayCopyAligned.testChar | 70 | 6.271 | 6.242 | 1.004645947 > ArrayCopyAligned.testChar | 150 | 7.45 | 7.599 | 0.980392157 > ArrayCopyAligned.testChar | 300 | 9.904 | 10.112 | 0.97943038 > ArrayCopyAligned.testChar | 600 | 17.131 | 17.167 | 0.997902953 > ArrayCopyAligned.testChar | 1200 | 29.556 | 29.851 | 0.990117584 > ArrayCopyUnalignedBoth.testByte | 1 | 5.419 | 2.702 | 2.005551443 > ArrayCopyUnalignedBoth.testByte | 3 | 5.558 | 2.636 | 2.108497724 > ArrayCopyUnalignedBoth.testByte | 5 | 5.43 | 2.636 | 2.059939302 > ArrayCopyUnalignedBoth.testByte | 10 | 5.378 | 2.637 | 2.039438756 > ArrayCopyUnalignedBoth.testByte | 20 | 5.914 | 2.636 | 2.243550835 > ArrayCopyUnalignedBoth.testByte | 70 | 5.882 | 5.954 | 0.987907289 > ArrayCopyUnalignedBoth.testByte | 150 | 6.784 | 6.88 | 0.986046512 > ArrayCopyUnalignedBoth.testByte | 300 | 7.635 | 7.968 | 0.958207831 > ArrayCopyUnalignedBoth.testByte | 600 | 12.226 | 12.129 | 1.007997362 > ArrayCopyUnalignedBoth.testByte | 1200 | 16.992 | 20.717 | 0.820195974 > ArrayCopyUnalignedBoth.testChar | 1 | 5.019 | 2.828 | 1.774752475 > ArrayCopyUnalignedBoth.testChar | 3 | 5.163 | 2.763 | 1.868621064 > ArrayCopyUnalignedBoth.testChar | 5 | 5.042 | 2.827 | 1.783516095 > ArrayCopyUnalignedBoth.testChar | 10 | 5.718 | 2.828 | 2.021923621 > ArrayCopyUnalignedBoth.testChar | 20 | 5.111 | 5.404 | 0.945780903 > ArrayCopyUnalignedBoth.testChar | 70 | 6.367 | 6.235 | 1.02117081 > ArrayCopyUnalignedBoth.testChar | 150 | 7.367 | 8.269 | 0.890917886 > ArrayCopyUnalignedBoth.testChar | 300 | 10.358 | 10.642 | 0.973313287 > ArrayCopyUnalignedBoth.testChar | 600 | 20.84 | 17.522 | 1.189361945 > ArrayCopyUnalignedBoth.testChar | 1200 | 31.895 | 31.892 | 1.000094067 > ArrayCopyUnalignedDst.testByte | 1 | 5.455 | 2.637 | 2.068638604 > ArrayCopyUnalignedDst.testByte | 3 | 5.562 | 2.702 | 2.058475204 > ArrayCopyUnalignedDst.testByte | 5 | 5.427 | 2.702 | 2.008512213 > ArrayCopyUnalignedDst.testByte | 10 | 5.367 | 2.696 | 1.990727003 > ArrayCopyUnalignedDst.testByte | 20 | 5.839 | 2.637 | 2.214258627 > ArrayCopyUnalignedDst.testByte | 70 | 5.888 | 5.968 | 0.986595174 > ArrayCopyUnalignedDst.testByte | 150 | 6.785 | 6.773 | 1.001771741 > ArrayCopyUnalignedDst.testByte | 300 | 7.606 | 7.972 | 0.954089313 > ArrayCopyUnalignedDst.testByte | 600 | 11.986 | 21.195 | 0.565510734 > ArrayCopyUnalignedDst.testByte | 1200 | 16.54 | 16.784 | 0.985462345 > ArrayCopyUnalignedDst.testChar | 1 | 5.02 | 2.827 | 1.775733994 > ArrayCopyUnalignedDst.testChar | 3 | 5.131 | 2.762 | 1.857711803 > ArrayCopyUnalignedDst.testChar | 5 | 5.038 | 2.762 | 1.82404055 > ArrayCopyUnalignedDst.testChar | 10 | 5.718 | 2.762 | 2.070238957 > ArrayCopyUnalignedDst.testChar | 20 | 5.113 | 5.401 | 0.946676541 > ArrayCopyUnalignedDst.testChar | 70 | 6.222 | 6.214 | 1.001287416 > ArrayCopyUnalignedDst.testChar | 150 | 7.367 | 8.125 | 0.906707692 > ArrayCopyUnalignedDst.testChar | 300 | 10.204 | 10.082 | 1.012100774 > ArrayCopyUnalignedDst.testChar | 600 | 16.978 | 17.135 | 0.990837467 > ArrayCopyUnalignedDst.testChar | 1200 | 32.351 | 31.996 | 1.011095137 > ArrayCopyUnalignedSrc.testByte | 1 | 5.414 | 2.696 | 2.008160237 > ArrayCopyUnalignedSrc.testByte | 3 | 5.494 | 2.637 | 2.083428138 > ArrayCopyUnalignedSrc.testByte | 5 | 5.431 | 2.637 | 2.059537353 > ArrayCopyUnalignedSrc.testByte | 10 | 5.344 | 2.703 | 1.977062523 > ArrayCopyUnalignedSrc.testByte | 20 | 5.834 | 2.696 | 2.163946588 > ArrayCopyUnalignedSrc.testByte | 70 | 5.883 | 6.009 | 0.979031453 > ArrayCopyUnalignedSrc.testByte | 150 | 6.729 | 6.87 | 0.979475983 > ArrayCopyUnalignedSrc.testByte | 300 | 7.603 | 7.97 | 0.953952321 > ArrayCopyUnalignedSrc.testByte | 600 | 12.004 | 12.16 | 0.987171053 > ArrayCopyUnalignedSrc.testByte | 1200 | 16.534 | 16.643 | 0.9934507 > ArrayCopyUnalignedSrc.testChar | 1 | 5.021 | 2.762 | 1.81788559 > ArrayCopyUnalignedSrc.testChar | 3 | 5.13 | 2.762 | 1.857349747 > ArrayCopyUnalignedSrc.testChar | 5 | 5.042 | 2.827 | 1.783516095 > ArrayCopyUnalignedSrc.testChar | 10 | 5.726 | 2.761 | 2.073886273 > ArrayCopyUnalignedSrc.testChar | 20 | 5.112 | 5.401 | 0.94649139 > ArrayCopyUnalignedSrc.testChar | 70 | 6.113 | 6.227 | 0.981692629 > ArrayCopyUnalignedSrc.testChar | 150 | 7.493 | 7.888 | 0.949923935 > ArrayCopyUnalignedSrc.testChar | 300 | 10.234 | 10.501 | 0.97457385 > ArrayCopyUnalignedSrc.testChar | 600 | 17.175 | 17.142 | 1.001925096 > ArrayCopyUnalignedSrc.testChar | 1200 | 31.926 | 31.987 | 0.998092975 > > Detailed Reports: > Baseline : > [http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_Baseline.txt](http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_Baseline.txt) > WithOpt : > [http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_With_PI_Opts.txt](http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_With_PI_Opts.txt) Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - 8252848: Rebase patch with branch tip. - Update arraycopynode.cpp Missed safety check. - 8252848: Optimize small primitive arrayCopy operations through partial inlining using AVX-512 masked instructions. - 8252848: Strengthening the check to detect partially in-lined array copy before Memory Barrier. - 8252848: Updating pull request-144, added a safety check on node type during pattern matching in ArrayCopyNode::may_modify(). - 8252848: Optimize small primitive arrayCopy operations through partial inlining using AVX-512 masked instructions. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/144/files - new: https://git.openjdk.java.net/jdk/pull/144/files/f6c46479..b9eaa468 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=144&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=144&range=01-02 Stats: 4673 lines in 137 files changed: 2387 ins; 1700 del; 586 mod Patch: https://git.openjdk.java.net/jdk/pull/144.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/144/head:pull/144 PR: https://git.openjdk.java.net/jdk/pull/144 From jbhateja at openjdk.java.net Wed Sep 16 12:52:53 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 16 Sep 2020 12:52:53 GMT Subject: Withdrawn: 8252848: Optimize small primitive arrayCopy operations through partial inlining using AVX-512 masked instructions In-Reply-To: References: Message-ID: On Sun, 13 Sep 2020 19:02:59 GMT, Jatin Bhateja wrote: > Summary: > > 1) Partial in-lining technique avoids call overhead penalty for sub-word type small array copy operations with size > less than 32 bytes. 2) At runtime, a conditional check based on copy length either calls an array-copy stub or executes > an optimized instruction sequence using AVX-512 masked instructions emitted at the call site. 3) New runtime flag > ArrayCopyPartialInlineSize=0/32(default)/64 bytes determines the maximum size for partial in-lining. > Performance Results: > System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz > Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java > ArrayCopyPartialInlineSize : 32 > > JMH | Block Size | Baseline (ns/op) | Partial Inling (ns/op) | Gain > -- | -- | -- | -- | -- > ArrayCopyAligned.testByte | 1 | 5.417 | 2.696 | 2.009272997 > ArrayCopyAligned.testByte | 3 | 5.494 | 2.702 | 2.03330866 > ArrayCopyAligned.testByte | 5 | 5.417 | 2.637 | 2.05422829 > ArrayCopyAligned.testByte | 10 | 5.343 | 2.703 | 1.976692564 > ArrayCopyAligned.testByte | 20 | 5.837 | 2.636 | 2.214339909 > ArrayCopyAligned.testByte | 70 | 5.86 | 6 | 0.976666667 > ArrayCopyAligned.testByte | 150 | 6.766 | 6.906 | 0.979727773 > ArrayCopyAligned.testByte | 300 | 7.605 | 7.952 | 0.956363179 > ArrayCopyAligned.testByte | 600 | 11.989 | 12.007 | 0.998500874 > ArrayCopyAligned.testByte | 1200 | 16.447 | 16.585 | 0.991679228 > ArrayCopyAligned.testChar | 1 | 5.02 | 2.828 | 1.775106082 > ArrayCopyAligned.testChar | 3 | 5.129 | 2.762 | 1.85698769 > ArrayCopyAligned.testChar | 5 | 5.041 | 2.762 | 1.82512672 > ArrayCopyAligned.testChar | 10 | 5.716 | 2.762 | 2.069514844 > ArrayCopyAligned.testChar | 20 | 5.111 | 5.399 | 0.946656788 > ArrayCopyAligned.testChar | 70 | 6.271 | 6.242 | 1.004645947 > ArrayCopyAligned.testChar | 150 | 7.45 | 7.599 | 0.980392157 > ArrayCopyAligned.testChar | 300 | 9.904 | 10.112 | 0.97943038 > ArrayCopyAligned.testChar | 600 | 17.131 | 17.167 | 0.997902953 > ArrayCopyAligned.testChar | 1200 | 29.556 | 29.851 | 0.990117584 > ArrayCopyUnalignedBoth.testByte | 1 | 5.419 | 2.702 | 2.005551443 > ArrayCopyUnalignedBoth.testByte | 3 | 5.558 | 2.636 | 2.108497724 > ArrayCopyUnalignedBoth.testByte | 5 | 5.43 | 2.636 | 2.059939302 > ArrayCopyUnalignedBoth.testByte | 10 | 5.378 | 2.637 | 2.039438756 > ArrayCopyUnalignedBoth.testByte | 20 | 5.914 | 2.636 | 2.243550835 > ArrayCopyUnalignedBoth.testByte | 70 | 5.882 | 5.954 | 0.987907289 > ArrayCopyUnalignedBoth.testByte | 150 | 6.784 | 6.88 | 0.986046512 > ArrayCopyUnalignedBoth.testByte | 300 | 7.635 | 7.968 | 0.958207831 > ArrayCopyUnalignedBoth.testByte | 600 | 12.226 | 12.129 | 1.007997362 > ArrayCopyUnalignedBoth.testByte | 1200 | 16.992 | 20.717 | 0.820195974 > ArrayCopyUnalignedBoth.testChar | 1 | 5.019 | 2.828 | 1.774752475 > ArrayCopyUnalignedBoth.testChar | 3 | 5.163 | 2.763 | 1.868621064 > ArrayCopyUnalignedBoth.testChar | 5 | 5.042 | 2.827 | 1.783516095 > ArrayCopyUnalignedBoth.testChar | 10 | 5.718 | 2.828 | 2.021923621 > ArrayCopyUnalignedBoth.testChar | 20 | 5.111 | 5.404 | 0.945780903 > ArrayCopyUnalignedBoth.testChar | 70 | 6.367 | 6.235 | 1.02117081 > ArrayCopyUnalignedBoth.testChar | 150 | 7.367 | 8.269 | 0.890917886 > ArrayCopyUnalignedBoth.testChar | 300 | 10.358 | 10.642 | 0.973313287 > ArrayCopyUnalignedBoth.testChar | 600 | 20.84 | 17.522 | 1.189361945 > ArrayCopyUnalignedBoth.testChar | 1200 | 31.895 | 31.892 | 1.000094067 > ArrayCopyUnalignedDst.testByte | 1 | 5.455 | 2.637 | 2.068638604 > ArrayCopyUnalignedDst.testByte | 3 | 5.562 | 2.702 | 2.058475204 > ArrayCopyUnalignedDst.testByte | 5 | 5.427 | 2.702 | 2.008512213 > ArrayCopyUnalignedDst.testByte | 10 | 5.367 | 2.696 | 1.990727003 > ArrayCopyUnalignedDst.testByte | 20 | 5.839 | 2.637 | 2.214258627 > ArrayCopyUnalignedDst.testByte | 70 | 5.888 | 5.968 | 0.986595174 > ArrayCopyUnalignedDst.testByte | 150 | 6.785 | 6.773 | 1.001771741 > ArrayCopyUnalignedDst.testByte | 300 | 7.606 | 7.972 | 0.954089313 > ArrayCopyUnalignedDst.testByte | 600 | 11.986 | 21.195 | 0.565510734 > ArrayCopyUnalignedDst.testByte | 1200 | 16.54 | 16.784 | 0.985462345 > ArrayCopyUnalignedDst.testChar | 1 | 5.02 | 2.827 | 1.775733994 > ArrayCopyUnalignedDst.testChar | 3 | 5.131 | 2.762 | 1.857711803 > ArrayCopyUnalignedDst.testChar | 5 | 5.038 | 2.762 | 1.82404055 > ArrayCopyUnalignedDst.testChar | 10 | 5.718 | 2.762 | 2.070238957 > ArrayCopyUnalignedDst.testChar | 20 | 5.113 | 5.401 | 0.946676541 > ArrayCopyUnalignedDst.testChar | 70 | 6.222 | 6.214 | 1.001287416 > ArrayCopyUnalignedDst.testChar | 150 | 7.367 | 8.125 | 0.906707692 > ArrayCopyUnalignedDst.testChar | 300 | 10.204 | 10.082 | 1.012100774 > ArrayCopyUnalignedDst.testChar | 600 | 16.978 | 17.135 | 0.990837467 > ArrayCopyUnalignedDst.testChar | 1200 | 32.351 | 31.996 | 1.011095137 > ArrayCopyUnalignedSrc.testByte | 1 | 5.414 | 2.696 | 2.008160237 > ArrayCopyUnalignedSrc.testByte | 3 | 5.494 | 2.637 | 2.083428138 > ArrayCopyUnalignedSrc.testByte | 5 | 5.431 | 2.637 | 2.059537353 > ArrayCopyUnalignedSrc.testByte | 10 | 5.344 | 2.703 | 1.977062523 > ArrayCopyUnalignedSrc.testByte | 20 | 5.834 | 2.696 | 2.163946588 > ArrayCopyUnalignedSrc.testByte | 70 | 5.883 | 6.009 | 0.979031453 > ArrayCopyUnalignedSrc.testByte | 150 | 6.729 | 6.87 | 0.979475983 > ArrayCopyUnalignedSrc.testByte | 300 | 7.603 | 7.97 | 0.953952321 > ArrayCopyUnalignedSrc.testByte | 600 | 12.004 | 12.16 | 0.987171053 > ArrayCopyUnalignedSrc.testByte | 1200 | 16.534 | 16.643 | 0.9934507 > ArrayCopyUnalignedSrc.testChar | 1 | 5.021 | 2.762 | 1.81788559 > ArrayCopyUnalignedSrc.testChar | 3 | 5.13 | 2.762 | 1.857349747 > ArrayCopyUnalignedSrc.testChar | 5 | 5.042 | 2.827 | 1.783516095 > ArrayCopyUnalignedSrc.testChar | 10 | 5.726 | 2.761 | 2.073886273 > ArrayCopyUnalignedSrc.testChar | 20 | 5.112 | 5.401 | 0.94649139 > ArrayCopyUnalignedSrc.testChar | 70 | 6.113 | 6.227 | 0.981692629 > ArrayCopyUnalignedSrc.testChar | 150 | 7.493 | 7.888 | 0.949923935 > ArrayCopyUnalignedSrc.testChar | 300 | 10.234 | 10.501 | 0.97457385 > ArrayCopyUnalignedSrc.testChar | 600 | 17.175 | 17.142 | 1.001925096 > ArrayCopyUnalignedSrc.testChar | 1200 | 31.926 | 31.987 | 0.998092975 > > Detailed Reports: > Baseline : > [http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_Baseline.txt](http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_Baseline.txt) > WithOpt : > [http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_With_PI_Opts.txt](http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_With_PI_Opts.txt) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/144 From tschatzl at openjdk.java.net Wed Sep 16 12:59:36 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 16 Sep 2020 12:59:36 GMT Subject: RFR: 8252041: G1: Fix incorrect uses of HeapRegionManager::max_length Message-ID: <-KIbxrG-S2bp4vwCP7sG2RU1wPR8rejiqWyRNynZLRA=.1a1fa97d-94c4-4507-98af-fa2e317ab716@github.com> Hi all, can I have reviews for this change that fixes some uses of HeapRegionManager::max_regions()/max_expandable_regions() in our code to use the correct variant? HeapRegionManager::max_length gives the absolute maximum number of regions reserved for the heap based on the reservation. HeapRegionmanager::max_expandable_regions() returns the maximum number of regions the heap can grow to (can be committed). Typically they are exchangeable, but if the reservation is larger than what -Xmx allows (like when file-mapping old gen), this is not the case, and causes assertions. In some cases the existing region manager code could (if it reserved more than -Xmx) give back more than -Xmx allows. Testing: tier1-5. ------------- Commit messages: - Initial import Changes: https://git.openjdk.java.net/jdk/pull/178/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=178&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252041 Stats: 45 lines in 6 files changed: 15 ins; 0 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/178.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/178/head:pull/178 PR: https://git.openjdk.java.net/jdk/pull/178 From sjohanss at openjdk.java.net Wed Sep 16 12:59:36 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 16 Sep 2020 12:59:36 GMT Subject: RFR: 8252041: G1: Fix incorrect uses of HeapRegionManager::max_length In-Reply-To: <-KIbxrG-S2bp4vwCP7sG2RU1wPR8rejiqWyRNynZLRA=.1a1fa97d-94c4-4507-98af-fa2e317ab716@github.com> References: <-KIbxrG-S2bp4vwCP7sG2RU1wPR8rejiqWyRNynZLRA=.1a1fa97d-94c4-4507-98af-fa2e317ab716@github.com> Message-ID: On Tue, 15 Sep 2020 13:10:28 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that fixes some uses of HeapRegionManager::max_regions()/max_expandable_regions() in > our code to use the correct variant? > > HeapRegionManager::max_length gives the absolute maximum number of regions reserved for the heap based on the > reservation. > HeapRegionmanager::max_expandable_regions() returns the maximum number of regions the heap can grow to (can be > committed). > Typically they are exchangeable, but if the reservation is larger than what -Xmx allows (like when file-mapping old > gen), this is not the case, and causes assertions. In some cases the existing region manager code could (if it reserved > more than -Xmx) give back more than -Xmx allows. Testing: tier1-5. Thanks for cleaning this up Thomas. The changes look good but I find these two names a bit confusing since that are so similar, what do you think about: `max_regions()` -> `reserved_regions()` `max_expandable_regions()` -> `max_regions()` And similar for the functions in the HeapRegionManager, what do you think about this? ------------- PR: https://git.openjdk.java.net/jdk/pull/178 From tschatzl at openjdk.java.net Wed Sep 16 12:59:36 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 16 Sep 2020 12:59:36 GMT Subject: RFR: 8252041: G1: Fix incorrect uses of HeapRegionManager::max_length In-Reply-To: References: <-KIbxrG-S2bp4vwCP7sG2RU1wPR8rejiqWyRNynZLRA=.1a1fa97d-94c4-4507-98af-fa2e317ab716@github.com> Message-ID: <2CrpeiBbRATGUPEEmgPH64iv21ureCXvQke_DKXU5Js=.edffd301-b4fc-4d08-a1ef-23eaf518bed1@github.com> On Wed, 16 Sep 2020 08:50:38 GMT, Stefan Johansson wrote: >> Hi all, >> >> can I have reviews for this change that fixes some uses of HeapRegionManager::max_regions()/max_expandable_regions() in >> our code to use the correct variant? >> >> HeapRegionManager::max_length gives the absolute maximum number of regions reserved for the heap based on the >> reservation. >> HeapRegionmanager::max_expandable_regions() returns the maximum number of regions the heap can grow to (can be >> committed). >> Typically they are exchangeable, but if the reservation is larger than what -Xmx allows (like when file-mapping old >> gen), this is not the case, and causes assertions. In some cases the existing region manager code could (if it reserved >> more than -Xmx) give back more than -Xmx allows. Testing: tier1-5. > > Thanks for cleaning this up Thomas. > > The changes look good but I find these two names a bit confusing since that are so similar, what do you think about: > `max_regions()` -> `reserved_regions()` > `max_expandable_regions()` -> `max_regions()` > > And similar for the functions in the HeapRegionManager, what do you think about this? Hi, On 16.09.20 10:50, Stefan Johansson wrote: > *@kstefanj* commented on this pull request. > > Thanks for cleaning this up Thomas. > > The changes look good but I find these two names a bit confusing since > that are so similar, what do you think about: > |max_regions()| -> |reserved_regions()| > |max_expandable_regions()| -> |max_regions()| > > And similar for the functions in the HeapRegionManager, what do you > think about this? > Fine with me - I considered this but then kept this. Thanks for your early feedback! Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/178 From tschatzl at openjdk.java.net Wed Sep 16 12:59:37 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 16 Sep 2020 12:59:37 GMT Subject: RFR: 8252041: G1: Fix incorrect uses of HeapRegionManager::max_length In-Reply-To: <2CrpeiBbRATGUPEEmgPH64iv21ureCXvQke_DKXU5Js=.edffd301-b4fc-4d08-a1ef-23eaf518bed1@github.com> References: <-KIbxrG-S2bp4vwCP7sG2RU1wPR8rejiqWyRNynZLRA=.1a1fa97d-94c4-4507-98af-fa2e317ab716@github.com> <2CrpeiBbRATGUPEEmgPH64iv21ureCXvQke_DKXU5Js=.edffd301-b4fc-4d08-a1ef-23eaf518bed1@github.com> Message-ID: On Wed, 16 Sep 2020 09:14:20 GMT, Thomas Schatzl wrote: >> Thanks for cleaning this up Thomas. >> >> The changes look good but I find these two names a bit confusing since that are so similar, what do you think about: >> `max_regions()` -> `reserved_regions()` >> `max_expandable_regions()` -> `max_regions()` >> >> And similar for the functions in the HeapRegionManager, what do you think about this? > > Hi, > > On 16.09.20 10:50, Stefan Johansson wrote: >> *@kstefanj* commented on this pull request. >> >> Thanks for cleaning this up Thomas. >> >> The changes look good but I find these two names a bit confusing since >> that are so similar, what do you think about: >> |max_regions()| -> |reserved_regions()| >> |max_expandable_regions()| -> |max_regions()| >> >> And similar for the functions in the HeapRegionManager, what do you >> think about this? >> > > Fine with me - I considered this but then kept this. Thanks for your > early feedback! > > Thanks, > Thomas Actually I have second thoughts about the suggestions: this would introduce a "_regions" prefix to just these two members in HeapRegionManager. What about "max_length" and "reserved_length" in HRM? The suggested names are fine with me in other code not directly using HRM (pretty much all of it). ------------- PR: https://git.openjdk.java.net/jdk/pull/178 From erikj at openjdk.java.net Wed Sep 16 13:11:12 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 16 Sep 2020 13:11:12 GMT Subject: RFR: 8253207: enable problemlists jcheck's check In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 00:15:54 GMT, Igor Ignatyev wrote: > problemlists[[1]] check verifies that there are no problem-list entries w/ the bug-id used in the commit message. > > [1]: https://github.com/openjdk/skara/pull/518 Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/196 From gziemski at openjdk.java.net Wed Sep 16 15:22:40 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 16 Sep 2020 15:22:40 GMT Subject: RFR: 8081833: Clean up JVMFlag getter/setter code In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 05:01:13 GMT, Ioi Lam wrote: > This is a follow to [JDK-8243208 Clean up JVMFlag implementation](https://bugs.openjdk.java.net/browse/JDK-8243208). > > I try to use templates and inheritance (and a bit of macros) to get rid of the large amount of duplicated code in the > JVMFlag getters/setters. > Stefan Karlsson and I have tried this several times already, but I think the current attempt probably has the least > amount of hacks and most functionality: > - Type safety is enforced up to the point of loading/storing `JVMFlag::_addr`, without any unchecked typecasts. > - Runtime type checking is implemented by the `JVM_FLAG_TYPE(t)` macro (see jvmFlagAccess.hpp), by passing along an > integer (`JVMFlag::TYPE_int`, etc). This is more efficient than previous attempts that passed along a function pointer > (see http://cr.openjdk.java.net/~stefank/8081833/webrev.04/) > - The old `JVMFlag::xxxAtPut` functions were undocumented. There are actually two groups that have different usage. I > added documentation in jvmFlagAccess.hpp to explain this. > - I got rid of the `JVMFlagEx` class and moved the code into `JVMFlag`. This is possible with C++11 which allows forward > declaration of `enum JVMFlagsEnum : int;` > - I changed `JVMFlag::_type` from a string into an enum. I am surprised this had lasted for over 20 years. > - I also changed `JVMFlag` from a struct into a class and made some fields private. I probably will do more cleanup in a > separate RFE. > > Please start with jvmFlagAccess.hpp, jvmFlagAccess.hpp and then globals_extension.hpp. > > Probably not everyone is in love with the `JVM_FLAG_TYPE(t)` macro. I'll be happy to try out alternatives. Changes requested by gziemski (Committer). src/hotspot/share/runtime/flags/jvmFlagLimit.cpp line 147: > 145: }; > 146: > 147: JVMFlagsEnum JVMFlagLimit::_last_checked = static_cast(-1); Can we add some "unchecked" enum value to JVMFlagsEnum enums (ex. UNCHECKED_FLAG) and use that instead of hardcoding to -1 ? src/hotspot/share/runtime/flags/jvmFlagAccess.hpp line 78: > 76: if (flag->type() != type_enum) { > 77: return JVMFlag::WRONG_FORMAT; > 78: } Can this normally happen at runtime? Maybe replace it with assert_type() instead? src/hotspot/share/runtime/flags/jvmFlagAccess.cpp line 91: > 89: public: > 90: JVMFlag::Error set_impl(JVMFlag* flag, void* value_addr, JVMFlag::Flags origin) const { > 91: bool verbose = !JVMFlagLimit::validated_after_ergo(); Why only verbose when not AfterErgo? Maybe add comment explaining that. ------------- PR: https://git.openjdk.java.net/jdk/pull/163 From tschatzl at openjdk.java.net Wed Sep 16 16:05:06 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 16 Sep 2020 16:05:06 GMT Subject: RFR: 8240556: Abort concurrent mark after effective eager reclamation of humongous objects Message-ID: Hi all, please review this change that implements concurrent mark abort as proposed by Liang Mao from Alibaba. Basically, if at the end of the concurrent start pause we notice that we went below the IHOP threshold (and it has been a concurrent start pause caused by humongous allocation), instead of scheduling a mark operation, we schedule a "concurrent undo" operation that undoes the changes. Regarding the removal of the test/hotspot/jtreg/gc/stress/jfr/TestStressBigAllocationGCEventsWithG1.java test: it only ever accidentally worked in G1. G1 never sent the AllocationRequiringGC events for GCs caused by going over the IHOP threshold for humongous allocations that the test actually expects. That test previously only worked because G1 could not reclaim the humongous objects fast enough so crossing the IHOP threshold causes a full concurrent mark. Allocations during that concurrent mark do not cause a GC that can reclaim these objects, so ultimately some young GC that sends the AllocationRequiringGC event will be sent. With concurrent undo this is not guaranteed any more, i.e. only in environments where concurrent undo is slow (and we'll improve it soon) this test works. The test is too timing dependent, and checking for the wrong thing in this case, so removing it. Testing: tbd. ------------- Commit messages: - Remove test that only accidentally worked: G1 never sent the AllocationRequiringGC - Fixed test - Initial import Changes: https://git.openjdk.java.net/jdk/pull/177/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=177&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240556 Stats: 336 lines in 12 files changed: 216 ins; 66 del; 54 mod Patch: https://git.openjdk.java.net/jdk/pull/177.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/177/head:pull/177 PR: https://git.openjdk.java.net/jdk/pull/177 From thomas.schatzl at oracle.com Wed Sep 16 16:14:02 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 16 Sep 2020 18:14:02 +0200 Subject: RFR: 8240556: Abort concurrent mark after effective eager reclamation of humongous objects In-Reply-To: References: Message-ID: <559b4f62-2203-ccab-0b04-a4e90c149558@oracle.com> Hi, On 16.09.20 18:05, Thomas Schatzl wrote: > Hi all, > > please review this change that implements concurrent mark abort as proposed by Liang Mao from Alibaba. > > Basically, if at the end of the concurrent start pause we notice that we went below the IHOP threshold (and it has been > a concurrent start pause caused by humongous allocation), instead of scheduling a mark operation, we schedule a > "concurrent undo" operation that undoes the changes. > > Regarding the removal of the test/hotspot/jtreg/gc/stress/jfr/TestStressBigAllocationGCEventsWithG1.java test: it only > ever accidentally worked in G1. G1 never sent the AllocationRequiringGC events for GCs caused by going over the IHOP > threshold for humongous allocations that the test actually expects. > > That test previously only worked because G1 could not reclaim the humongous objects fast enough so crossing the IHOP > threshold causes a full concurrent mark. Allocations during that concurrent mark do not cause a GC that can reclaim > these objects, so ultimately some young GC that sends the AllocationRequiringGC event will be sent. > > With concurrent undo this is not guaranteed any more, i.e. only in environments where concurrent undo is slow (and > we'll improve it soon) this test works. > > The test is too timing dependent, and checking for the wrong thing in this case, so removing it. We could also change that GC pause to send the AllocationRequiringGC event in case of these GCs caused by crossing the IHOP threshold. Not sure if that is in the intent of the AllocationRequiringGC event. That GC is not strictly required (we are not out of eden) but a "random" proactive GC. Adding jfr-dev label for their comments. Thanks, Thomas From iignatyev at openjdk.java.net Wed Sep 16 17:23:39 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 16 Sep 2020 17:23:39 GMT Subject: RFR: 8253207: enable problemlists jcheck's check In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 13:08:17 GMT, Erik Joelsson wrote: >> problemlists[[1]] check verifies that there are no problem-list entries w/ the bug-id used in the commit message. >> >> [1]: https://github.com/openjdk/skara/pull/518 > > Marked as reviewed by erikj (Reviewer). thanks for your review, Erik. ------------- PR: https://git.openjdk.java.net/jdk/pull/196 From iignatyev at openjdk.java.net Wed Sep 16 17:23:40 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 16 Sep 2020 17:23:40 GMT Subject: Integrated: 8253207: enable problemlists jcheck's check In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 00:15:54 GMT, Igor Ignatyev wrote: > problemlists[[1]] check verifies that there are no problem-list entries w/ the bug-id used in the commit message. > > [1]: https://github.com/openjdk/skara/pull/518 This pull request has now been integrated. Changeset: d38c97dd Author: Igor Ignatyev URL: https://git.openjdk.java.net/jdk/commit/d38c97dd Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod 8253207: enable problemlists jcheck's check Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/196 From iklam at openjdk.java.net Wed Sep 16 18:21:21 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 16 Sep 2020 18:21:21 GMT Subject: RFR: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file [v4] In-Reply-To: References: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> <-pg1re505fpvfZXY_3Be7RyqmoQup1wt-5WDvWmFg6U=.e884c39a-16e0-4766-82b6-fddec49586ad@github.com> Message-ID: On Tue, 15 Sep 2020 19:15:37 GMT, John Tortugo wrote: >> Looks good. > > Before integrating this PR I need to include a change requested by @coleenp on the maillist: > > There's also vmIntrinsics code in vmSymbols.cpp, so there should also be a vmIntrinsics.cpp file. `@JohnTortugo JohnTortugo force-pushed the JohnTortugo:jdk-8243066 branch from 868eee7 to e711a53 12 hours ago` Was this an attempt to fix the missing new-line character? It doesn't seem to work. ------------- PR: https://git.openjdk.java.net/jdk/pull/160 From coleenp at openjdk.java.net Wed Sep 16 18:32:42 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 16 Sep 2020 18:32:42 GMT Subject: RFR: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file [v4] In-Reply-To: References: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> Message-ID: On Wed, 16 Sep 2020 05:55:31 GMT, John Tortugo wrote: >> Relates to: https://bugs.openjdk.java.net/browse/JDK-8243066 >> Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} >> >> Small change to move VM_INTRINSICS_DO out of vmSymbols.hpp into its own file. > > John Tortugo has refreshed the contents of this pull request, and previous commits have been removed. The incremental > views will show differences compared to the previous content of the PR. Changes requested by coleenp (Reviewer). src/hotspot/share/classfile/vmIntrinsics.hpp line 2: > 1: /* > 2: * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved. The copyright should just be 2020 (with trailing comma). src/hotspot/share/classfile/vmIntrinsics.cpp line 2: > 1: /* > 2: * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved. The copyright should start out with 2020 (with trailing comma) since this is a new file. src/hotspot/share/classfile/vmIntrinsics.cpp line 32: > 30: #include "compiler/compilerDirectives.hpp" > 31: #include "memory/allocation.inline.hpp" > 32: #include "memory/oopFactory.hpp" Can you make sure it needs all of these header files? I don't see a direct reference to SymbolTable:: or OopFactory. ------------- PR: https://git.openjdk.java.net/jdk/pull/160 From iklam at openjdk.java.net Wed Sep 16 19:08:27 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 16 Sep 2020 19:08:27 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 18:57:55 GMT, Yumin Qi wrote: > This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous > webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the > regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. Tests: tier1-4 Changes requested by iklam (Reviewer). src/hotspot/share/classfile/lambdaFormInvokers.cpp line 51: > 49: #include "runtime/os.hpp" > 50: #include "runtime/signature.hpp" > 51: Are all these header files needed? E.g., typeArrayKlass.hpp doesn't seem to be needed. src/hotspot/share/classfile/lambdaFormInvokers.cpp line 121: > 119: log_info(cds)("Class %s not present, skip", name); > 120: return; > 121: } Since the classlist can be generated by the user, it may cause the assert at line 115 to fail. For example, no java.lang.invoke.*$Holder classes are used by HelloWorld: $ java -verbose -Xshare:off -cp . HelloWorld | grep Holder [0.030s][info][class,load] java.util.KeyValueHolder source: jrt:/java.base [0.080s][info][class,load] java.security.SecureClassLoader$DebugHolder source: jrt:/java.base $ But it's possible for the user to generate a classlist using HelloWorld, and then manually add LF_RESOLVE lines into the classlist. So I think line 114 should be changed to a regular lookup (the symbol is created if it doesn't exist), and line 115 should be removed. Also, we should add some test cases for invalid LF_RESOLVE input. You can see examples in [appcds/customLoader/ClassListFormatA.java](https://github.com/openjdk/jdk/blob/d250f9e08c4a0c047cd3e619918c116f568e31d4/test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassListFormatA.java#L51). Since the new tests aren't related to custom loader, we should probably move [appcds/customLoader/ClassListFormatBase.java](https://github.com/openjdk/jdk/blob/d250f9e08c4a0c047cd3e619918c116f568e31d4/test/hotspot/jtreg/runtime/cds/appcds/customLoader/ClassListFormatBase.java#L30) under appcds/, and add a new file like appcds/ClassListFormat.java src/hotspot/share/classfile/lambdaFormInvokers.cpp line 158: > 156: // find_class assert on SystemDictionary_lock or safepoint > 157: MutexLocker lock(SystemDictionary_lock); > 158: InstanceKlass* old = SystemDictionary::find_class(class_name, cld); There's no need to call `find_class` here, since it will return the same class as `klass` on line 117. src/hotspot/share/classfile/lambdaFormInvokers.hpp line 27: > 25: #ifndef SHARE_MEMORY_LAMBDAFORMINVOKERS_HPP > 26: #define SHARE_MEMORY_LAMBDAFORMINVOKERS_HPP > 27: #include "memory/allocation.hpp" For the AllStatic base class, you should use memory/allStatic.hpp instead. src/hotspot/share/classfile/systemDictionary.cpp line 1875: > 1873: VerifyDuringStartup || > 1874: VerifyAfterGC || > 1875: DumpSharedSpaces, "too expensive"); This may not be needed if you remove the find_class() call from LambdaFormInvokers::regenerate_holder_classes? src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 67: > 65: if (VM.isDumpLoadedClassListSetAndOpen) { > 66: VM.cdsTraceResolve(traceLF); > 67: } GenerateJLIClassesHelper shouldn't need to know why the trace is needed. Also, "cdsTraceResolve" is too generic. I think it's better to have if (TRACE_RESOLVE || VM.CDS_TRACE_JLINV_RESOLVE) { ... VM.cdsTraceJLINVResolve(traceLF); The acronym JLINV is used in [methodHandles.cpp](https://github.com/openjdk/jdk/blob/ce93cbce77e1f4baa52676826c8ae27d474360b6/src/hotspot/share/prims/methodHandles.cpp#L1524) src/java.base/share/classes/jdk/internal/misc/VM.java line 490: > 488: */ > 489: public static boolean isDumpLoadedClassListSetAndOpen; > 490: private static native boolean isDumpLoadedClassListSetAndOpen0(); I would suggest to rename to `isDumpingLoadedClassList` ------------- PR: https://git.openjdk.java.net/jdk/pull/193 From coleenp at openjdk.java.net Wed Sep 16 21:29:59 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 16 Sep 2020 21:29:59 GMT Subject: RFR: 8081833: Clean up JVMFlag getter/setter code In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 05:01:13 GMT, Ioi Lam wrote: > This is a follow to [JDK-8243208 Clean up JVMFlag implementation](https://bugs.openjdk.java.net/browse/JDK-8243208). > > I try to use templates and inheritance (and a bit of macros) to get rid of the large amount of duplicated code in the > JVMFlag getters/setters. > Stefan Karlsson and I have tried this several times already, but I think the current attempt probably has the least > amount of hacks and most functionality: > - Type safety is enforced up to the point of loading/storing `JVMFlag::_addr`, without any unchecked typecasts. > - Runtime type checking is implemented by the `JVM_FLAG_TYPE(t)` macro (see jvmFlagAccess.hpp), by passing along an > integer (`JVMFlag::TYPE_int`, etc). This is more efficient than previous attempts that passed along a function pointer > (see http://cr.openjdk.java.net/~stefank/8081833/webrev.04/) > - The old `JVMFlag::xxxAtPut` functions were undocumented. There are actually two groups that have different usage. I > added documentation in jvmFlagAccess.hpp to explain this. > - I got rid of the `JVMFlagEx` class and moved the code into `JVMFlag`. This is possible with C++11 which allows forward > declaration of `enum JVMFlagsEnum : int;` > - I changed `JVMFlag::_type` from a string into an enum. I am surprised this had lasted for over 20 years. > - I also changed `JVMFlag` from a struct into a class and made some fields private. I probably will do more cleanup in a > separate RFE. > > Please start with jvmFlagAccess.hpp, jvmFlagAccess.hpp and then globals_extension.hpp. > > Probably not everyone is in love with the `JVM_FLAG_TYPE(t)` macro. I'll be happy to try out alternatives. I like all the consolidation (red!). src/hotspot/share/prims/whitebox.cpp line 1423: > 1421: { > 1422: ThreadInVMfromNative ttvfn(thread); // back to VM > 1423: needFree = SetVMFlag (thread, env, name, &ccstrResult); I wonder if these whitebox methods could be rewritten as macros, like the jni.cpp methods, like: DEFINE_GETFIELD, etc, in a future RFE. src/hotspot/share/runtime/flags/jvmFlagAccess.cpp line 339: > 337: } > 338: > 339: // This is called by the FLAG_SET_XXX macros. There are both FLAG_SET_XXX and SET_FLAG_XXX macros ? Is this a typo in the comment? ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/163 From coleenp at openjdk.java.net Wed Sep 16 21:30:00 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 16 Sep 2020 21:30:00 GMT Subject: RFR: 8081833: Clean up JVMFlag getter/setter code In-Reply-To: References: Message-ID: <2JTh7F6ztTcCnqB3jIiD9mWsrWKsB8HA3DkB7aIglro=.1e77bb73-1c5d-47e7-bf61-43166a84ab27@github.com> On Tue, 15 Sep 2020 20:47:02 GMT, Gerard Ziemski wrote: >> This is a follow to [JDK-8243208 Clean up JVMFlag implementation](https://bugs.openjdk.java.net/browse/JDK-8243208). >> >> I try to use templates and inheritance (and a bit of macros) to get rid of the large amount of duplicated code in the >> JVMFlag getters/setters. >> Stefan Karlsson and I have tried this several times already, but I think the current attempt probably has the least >> amount of hacks and most functionality: >> - Type safety is enforced up to the point of loading/storing `JVMFlag::_addr`, without any unchecked typecasts. >> - Runtime type checking is implemented by the `JVM_FLAG_TYPE(t)` macro (see jvmFlagAccess.hpp), by passing along an >> integer (`JVMFlag::TYPE_int`, etc). This is more efficient than previous attempts that passed along a function pointer >> (see http://cr.openjdk.java.net/~stefank/8081833/webrev.04/) >> - The old `JVMFlag::xxxAtPut` functions were undocumented. There are actually two groups that have different usage. I >> added documentation in jvmFlagAccess.hpp to explain this. >> - I got rid of the `JVMFlagEx` class and moved the code into `JVMFlag`. This is possible with C++11 which allows forward >> declaration of `enum JVMFlagsEnum : int;` >> - I changed `JVMFlag::_type` from a string into an enum. I am surprised this had lasted for over 20 years. >> - I also changed `JVMFlag` from a struct into a class and made some fields private. I probably will do more cleanup in a >> separate RFE. >> >> Please start with jvmFlagAccess.hpp, jvmFlagAccess.hpp and then globals_extension.hpp. >> >> Probably not everyone is in love with the `JVM_FLAG_TYPE(t)` macro. I'll be happy to try out alternatives. > > src/hotspot/share/runtime/flags/jvmFlag.hpp line 259: > >> 257: bool is_writeable() const { return is_manageable(); } >> 258: // All flags except "manageable" are assumed to be internal flags. >> 259: bool is_external() const { return is_manageable(); } > > Do we need is_writeable() and/or is_external() if all they do is return is_manageable() ? is_external() is odd and only has one caller. You could just fix the caller and remove is_external. ------------- PR: https://git.openjdk.java.net/jdk/pull/163 From david.holmes at oracle.com Thu Sep 17 00:31:35 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Sep 2020 10:31:35 +1000 Subject: RFR: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file [v4] In-Reply-To: References: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> <-pg1re505fpvfZXY_3Be7RyqmoQup1wt-5WDvWmFg6U=.e884c39a-16e0-4766-82b6-fddec49586ad@github.com> Message-ID: On 17/09/2020 4:21 am, Ioi Lam wrote: > On Tue, 15 Sep 2020 19:15:37 GMT, John Tortugo wrote: > >>> Looks good. >> >> Before integrating this PR I need to include a change requested by @coleenp on the maillist: >> >> There's also vmIntrinsics code in vmSymbols.cpp, so there should also be a vmIntrinsics.cpp file. > > `@JohnTortugo JohnTortugo force-pushed the JohnTortugo:jdk-8243066 branch from 868eee7 to e711a53 12 hours ago` Please do not force-push changes in an active PR as they just mess things up. It is fine to add a new commit to the PR to address any updates. All commits will be flattened before the changes are committed to the master branch of the main repo. Thanks, David ----- > Was this an attempt to fix the missing new-line character? It doesn't seem to work. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/160 > From iklam at openjdk.java.net Thu Sep 17 00:42:06 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 17 Sep 2020 00:42:06 GMT Subject: RFR: 8081833: Clean up JVMFlag getter/setter code In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 16:57:12 GMT, Gerard Ziemski wrote: >> This is a follow to [JDK-8243208 Clean up JVMFlag implementation](https://bugs.openjdk.java.net/browse/JDK-8243208). >> >> I try to use templates and inheritance (and a bit of macros) to get rid of the large amount of duplicated code in the >> JVMFlag getters/setters. >> Stefan Karlsson and I have tried this several times already, but I think the current attempt probably has the least >> amount of hacks and most functionality: >> - Type safety is enforced up to the point of loading/storing `JVMFlag::_addr`, without any unchecked typecasts. >> - Runtime type checking is implemented by the `JVM_FLAG_TYPE(t)` macro (see jvmFlagAccess.hpp), by passing along an >> integer (`JVMFlag::TYPE_int`, etc). This is more efficient than previous attempts that passed along a function pointer >> (see http://cr.openjdk.java.net/~stefank/8081833/webrev.04/) >> - The old `JVMFlag::xxxAtPut` functions were undocumented. There are actually two groups that have different usage. I >> added documentation in jvmFlagAccess.hpp to explain this. >> - I got rid of the `JVMFlagEx` class and moved the code into `JVMFlag`. This is possible with C++11 which allows forward >> declaration of `enum JVMFlagsEnum : int;` >> - I changed `JVMFlag::_type` from a string into an enum. I am surprised this had lasted for over 20 years. >> - I also changed `JVMFlag` from a struct into a class and made some fields private. I probably will do more cleanup in a >> separate RFE. >> >> Please start with jvmFlagAccess.hpp, jvmFlagAccess.hpp and then globals_extension.hpp. >> >> Probably not everyone is in love with the `JVM_FLAG_TYPE(t)` macro. I'll be happy to try out alternatives. > > src/hotspot/share/runtime/flags/jvmFlagLimit.cpp line 156: > >> 154: for (int i = 0; i < NUM_JVMFlagsEnum; i++) { >> 155: JVMFlagsEnum flag_enum = static_cast(i); >> 156: if (get_range_at(flag_enum) != NULL && > > VMFlagAccess::check_range(JVMFlag::flag_from_enum(flag_enum) will check for "get_range_at(flag_enum) != NULL", so no > need for this check here? This function is called during VM start-up, so I want to short-circuit the check, and avoid calling VMFlagAccess::check_range if the flag has no ranges. ------------- PR: https://git.openjdk.java.net/jdk/pull/163 From iklam at openjdk.java.net Thu Sep 17 00:50:25 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 17 Sep 2020 00:50:25 GMT Subject: RFR: 8081833: Clean up JVMFlag getter/setter code In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 19:40:58 GMT, Gerard Ziemski wrote: >> This is a follow to [JDK-8243208 Clean up JVMFlag implementation](https://bugs.openjdk.java.net/browse/JDK-8243208). >> >> I try to use templates and inheritance (and a bit of macros) to get rid of the large amount of duplicated code in the >> JVMFlag getters/setters. >> Stefan Karlsson and I have tried this several times already, but I think the current attempt probably has the least >> amount of hacks and most functionality: >> - Type safety is enforced up to the point of loading/storing `JVMFlag::_addr`, without any unchecked typecasts. >> - Runtime type checking is implemented by the `JVM_FLAG_TYPE(t)` macro (see jvmFlagAccess.hpp), by passing along an >> integer (`JVMFlag::TYPE_int`, etc). This is more efficient than previous attempts that passed along a function pointer >> (see http://cr.openjdk.java.net/~stefank/8081833/webrev.04/) >> - The old `JVMFlag::xxxAtPut` functions were undocumented. There are actually two groups that have different usage. I >> added documentation in jvmFlagAccess.hpp to explain this. >> - I got rid of the `JVMFlagEx` class and moved the code into `JVMFlag`. This is possible with C++11 which allows forward >> declaration of `enum JVMFlagsEnum : int;` >> - I changed `JVMFlag::_type` from a string into an enum. I am surprised this had lasted for over 20 years. >> - I also changed `JVMFlag` from a struct into a class and made some fields private. I probably will do more cleanup in a >> separate RFE. >> >> Please start with jvmFlagAccess.hpp, jvmFlagAccess.hpp and then globals_extension.hpp. >> >> Probably not everyone is in love with the `JVM_FLAG_TYPE(t)` macro. I'll be happy to try out alternatives. > > src/hotspot/share/runtime/globals_extension.hpp line 38: > >> 36: #define FLAG_MEMBER_ENUM_(name) FLAG_MEMBER_ENUM(name), >> 37: >> 38: #define FLAG_MEMBER_ENUM_DECLARE(type, name, ...) FLAG_MEMBER_ENUM_(name) > > We have other macros named: > > DECLARE_PRODUCT_FLAG > MATERIALIZE_PRODUCT_FLAG > > Can we rename this one as ENUMERATE_FLAG_MEMBER, (with the verb first in the name) to be more clear and consistent? How about DEFINE_FLAG_MEMBER_ENUM? In C++ terminology (https://en.cppreference.com/w/cpp/language/enum), we are building an "comma-separated list of enumerator definitions". > src/hotspot/share/runtime/globals_extension.hpp line 59: > >> 57: } >> 58: >> 59: #define FLAG_MEMBER_SET_DECLARE(type, name, ...) FLAG_MEMBER_SET_(type, name) > > We have other macros named: > > DECLARE_PRODUCT_FLAG > MATERIALIZE_PRODUCT_FLAG > > Can we rename this one as SET_FLAG_MEMBER or DECLARE_FLAG_MEMBER, (with the verb first in the name) to be more clear > and consistent? Here, we are defining a "flag member setter function". I think we should rename to #define FLAG_MEMBER_SETTER(name) Flag_##name##_set #define FLAG_MEMBER_SETTER_(type, name) \ inline JVMFlag::Error FLAG_MEMBER_SETER(name)(type value, JVMFlag::Flags origin) { \ return JVMFlagAccess::set(FLAG_MEMBER_ENUM(name), value, origin); \ } #define DEFINE_FLAG_MEMBER_SETTER(type, name, ...) FLAG_MEMBER_SETTER_(type, name) ALL_FLAGS(DEFINE_FLAG_MEMBER_SETTER, ... > src/hotspot/share/runtime/flags/jvmFlag.cpp line 523: > >> 521: #define PRODUCT_FLAG_INIT( type, name, value, ...) JVMFlag(FLAG_MEMBER_ENUM(name), FLAG_TYPE(type), XSTR(name), >> (void*)&name, PRODUCT_KIND, __VA_ARGS__), 522: #define PRODUCT_FLAG_INIT_PD(type, name, ...) >> JVMFlag(FLAG_MEMBER_ENUM(name), FLAG_TYPE(type), XSTR(name), (void*)&name, PRODUCT_KIND_PD, __VA_ARGS__), 523: #define >> NOTPROD_FLAG_INIT( type, name, value, ...) JVMFlag(FLAG_MEMBER_ENUM(name), FLAG_TYPE(type), XSTR(name), (void*)&name, >> NOTPROD_KIND, __VA_ARGS__), > > We have other macros named: > > DECLARE_PRODUCT_FLAG > MATERIALIZE_PRODUCT_FLAG > > Can we rename these macros: > > DEVELOP_FLAG_INIT --> INITIALIZE_DEVELOP_FLAG > DEVELOP_FLAG_INIT_PD --> INITIALIZE_PD_DEVELOP_FLAG > etc. ? OK ------------- PR: https://git.openjdk.java.net/jdk/pull/163 From iklam at openjdk.java.net Thu Sep 17 00:57:58 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 17 Sep 2020 00:57:58 GMT Subject: RFR: 8081833: Clean up JVMFlag getter/setter code In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 20:34:48 GMT, Gerard Ziemski wrote: >> This is a follow to [JDK-8243208 Clean up JVMFlag implementation](https://bugs.openjdk.java.net/browse/JDK-8243208). >> >> I try to use templates and inheritance (and a bit of macros) to get rid of the large amount of duplicated code in the >> JVMFlag getters/setters. >> Stefan Karlsson and I have tried this several times already, but I think the current attempt probably has the least >> amount of hacks and most functionality: >> - Type safety is enforced up to the point of loading/storing `JVMFlag::_addr`, without any unchecked typecasts. >> - Runtime type checking is implemented by the `JVM_FLAG_TYPE(t)` macro (see jvmFlagAccess.hpp), by passing along an >> integer (`JVMFlag::TYPE_int`, etc). This is more efficient than previous attempts that passed along a function pointer >> (see http://cr.openjdk.java.net/~stefank/8081833/webrev.04/) >> - The old `JVMFlag::xxxAtPut` functions were undocumented. There are actually two groups that have different usage. I >> added documentation in jvmFlagAccess.hpp to explain this. >> - I got rid of the `JVMFlagEx` class and moved the code into `JVMFlag`. This is possible with C++11 which allows forward >> declaration of `enum JVMFlagsEnum : int;` >> - I changed `JVMFlag::_type` from a string into an enum. I am surprised this had lasted for over 20 years. >> - I also changed `JVMFlag` from a struct into a class and made some fields private. I probably will do more cleanup in a >> separate RFE. >> >> Please start with jvmFlagAccess.hpp, jvmFlagAccess.hpp and then globals_extension.hpp. >> >> Probably not everyone is in love with the `JVM_FLAG_TYPE(t)` macro. I'll be happy to try out alternatives. > > src/hotspot/share/runtime/flags/jvmFlag.hpp line 128: > >> 126: TYPE_ccstrlist, >> 127: NUM_FLAG_TYPES >> 128: }; > > Are those macros really needed here and better than simply saying: > > enum FlagType : int { > TYPE_bool, > TYPE_int, > TYPE_uint, > TYPE_intx, > TYPE_uintx, > TYPE_uint64_t, > TYPE_size_t, > TYPE_double, > TYPE_ccstr, > TYPE_ccstrlist, > NUM_FLAG_TYPES > }; `JVM_FLAG_NON_STRING_TYPES_DO` is used in several places, such as declaring functions like `is_int()`, `get_int()`, `set_int()`, etc. I think it's less tedious/error prone than writing the same code 9 times. > src/hotspot/share/runtime/flags/jvmFlagAccess.hpp line 78: > >> 76: if (flag->type() != type_enum) { >> 77: return JVMFlag::WRONG_FORMAT; >> 78: } > > Can this normally happen at runtime? Maybe replace it with assert_type() instead? To be honest I am not sure. It's the same behavior as the olde code. ------------- PR: https://git.openjdk.java.net/jdk/pull/163 From iklam at openjdk.java.net Thu Sep 17 00:57:58 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 17 Sep 2020 00:57:58 GMT Subject: RFR: 8081833: Clean up JVMFlag getter/setter code In-Reply-To: <2JTh7F6ztTcCnqB3jIiD9mWsrWKsB8HA3DkB7aIglro=.1e77bb73-1c5d-47e7-bf61-43166a84ab27@github.com> References: <2JTh7F6ztTcCnqB3jIiD9mWsrWKsB8HA3DkB7aIglro=.1e77bb73-1c5d-47e7-bf61-43166a84ab27@github.com> Message-ID: On Wed, 16 Sep 2020 21:05:52 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/flags/jvmFlag.hpp line 259: >> >>> 257: bool is_writeable() const { return is_manageable(); } >>> 258: // All flags except "manageable" are assumed to be internal flags. >>> 259: bool is_external() const { return is_manageable(); } >> >> Do we need is_writeable() and/or is_external() if all they do is return is_manageable() ? > > is_external() is odd and only has one caller. You could just fix the caller and remove is_external. Since I am doing a "syntactic" clean up, I want to keep the code behavior the same, without doing any "semantic" changes. The caller of `is_external()` may have a (historically) different intention than the caller of `is_manageable()`. I want to leave such clean up in separate RFEs. ------------- PR: https://git.openjdk.java.net/jdk/pull/163 From iklam at openjdk.java.net Thu Sep 17 01:00:39 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 17 Sep 2020 01:00:39 GMT Subject: RFR: 8081833: Clean up JVMFlag getter/setter code In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 15:01:52 GMT, Gerard Ziemski wrote: >> This is a follow to [JDK-8243208 Clean up JVMFlag implementation](https://bugs.openjdk.java.net/browse/JDK-8243208). >> >> I try to use templates and inheritance (and a bit of macros) to get rid of the large amount of duplicated code in the >> JVMFlag getters/setters. >> Stefan Karlsson and I have tried this several times already, but I think the current attempt probably has the least >> amount of hacks and most functionality: >> - Type safety is enforced up to the point of loading/storing `JVMFlag::_addr`, without any unchecked typecasts. >> - Runtime type checking is implemented by the `JVM_FLAG_TYPE(t)` macro (see jvmFlagAccess.hpp), by passing along an >> integer (`JVMFlag::TYPE_int`, etc). This is more efficient than previous attempts that passed along a function pointer >> (see http://cr.openjdk.java.net/~stefank/8081833/webrev.04/) >> - The old `JVMFlag::xxxAtPut` functions were undocumented. There are actually two groups that have different usage. I >> added documentation in jvmFlagAccess.hpp to explain this. >> - I got rid of the `JVMFlagEx` class and moved the code into `JVMFlag`. This is possible with C++11 which allows forward >> declaration of `enum JVMFlagsEnum : int;` >> - I changed `JVMFlag::_type` from a string into an enum. I am surprised this had lasted for over 20 years. >> - I also changed `JVMFlag` from a struct into a class and made some fields private. I probably will do more cleanup in a >> separate RFE. >> >> Please start with jvmFlagAccess.hpp, jvmFlagAccess.hpp and then globals_extension.hpp. >> >> Probably not everyone is in love with the `JVM_FLAG_TYPE(t)` macro. I'll be happy to try out alternatives. > > src/hotspot/share/runtime/flags/jvmFlagAccess.cpp line 91: > >> 89: public: >> 90: JVMFlag::Error set_impl(JVMFlag* flag, void* value_addr, JVMFlag::Flags origin) const { >> 91: bool verbose = !JVMFlagLimit::validated_after_ergo(); > > Why only verbose when not AfterErgo? Maybe add comment explaining that. If I understand the old code correctly, we print out error messages only when parsing the command-line given by the user. When we later override values that are set programmatically by the FLAG_SET_XXX() macros, we don't print out error messages (or else the user will be confused). I will rewrite the code to make it clear, and add comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/163 From iklam at openjdk.java.net Thu Sep 17 01:04:31 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 17 Sep 2020 01:04:31 GMT Subject: RFR: 8081833: Clean up JVMFlag getter/setter code In-Reply-To: References: Message-ID: <4lPFH2IyTlvGQmqDAmJsHk9zx4y7EzBJOsSDcilYL2Q=.602e666a-3728-4643-a08e-59be0c3c6e4b@github.com> On Wed, 16 Sep 2020 20:57:40 GMT, Coleen Phillimore wrote: >> This is a follow to [JDK-8243208 Clean up JVMFlag implementation](https://bugs.openjdk.java.net/browse/JDK-8243208). >> >> I try to use templates and inheritance (and a bit of macros) to get rid of the large amount of duplicated code in the >> JVMFlag getters/setters. >> Stefan Karlsson and I have tried this several times already, but I think the current attempt probably has the least >> amount of hacks and most functionality: >> - Type safety is enforced up to the point of loading/storing `JVMFlag::_addr`, without any unchecked typecasts. >> - Runtime type checking is implemented by the `JVM_FLAG_TYPE(t)` macro (see jvmFlagAccess.hpp), by passing along an >> integer (`JVMFlag::TYPE_int`, etc). This is more efficient than previous attempts that passed along a function pointer >> (see http://cr.openjdk.java.net/~stefank/8081833/webrev.04/) >> - The old `JVMFlag::xxxAtPut` functions were undocumented. There are actually two groups that have different usage. I >> added documentation in jvmFlagAccess.hpp to explain this. >> - I got rid of the `JVMFlagEx` class and moved the code into `JVMFlag`. This is possible with C++11 which allows forward >> declaration of `enum JVMFlagsEnum : int;` >> - I changed `JVMFlag::_type` from a string into an enum. I am surprised this had lasted for over 20 years. >> - I also changed `JVMFlag` from a struct into a class and made some fields private. I probably will do more cleanup in a >> separate RFE. >> >> Please start with jvmFlagAccess.hpp, jvmFlagAccess.hpp and then globals_extension.hpp. >> >> Probably not everyone is in love with the `JVM_FLAG_TYPE(t)` macro. I'll be happy to try out alternatives. > > src/hotspot/share/prims/whitebox.cpp line 1423: > >> 1421: { >> 1422: ThreadInVMfromNative ttvfn(thread); // back to VM >> 1423: needFree = SetVMFlag (thread, env, name, &ccstrResult); > > I wonder if these whitebox methods could be rewritten as macros, like the jni.cpp methods, like: DEFINE_GETFIELD, etc, > in a future RFE. I am not quite sure. On the one hand I like code reduction, but on the other hand macro-generated code will be difficult to debug. ------------- PR: https://git.openjdk.java.net/jdk/pull/163 From minqi at openjdk.java.net Thu Sep 17 01:16:45 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 17 Sep 2020 01:16:45 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 19:05:56 GMT, Ioi Lam wrote: >> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous >> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the >> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses >> function. Tests: tier1-4 > > Changes requested by iklam (Reviewer). > _Mailing list message from [Mandy Chung](mailto:mandy.chung at oracle.com) on > [build-dev](mailto:build-dev at openjdk.java.net):_ > src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java > 367 /** 368 * called from vm to generate MethodHandle holder classes 369 > * @return @code { Object[] } if holder classes can be generated. 370 * > @param lines the output lines from @code { VM.cdsTraceResolve } 371 */ > @code {....} is wrong syntax. It should be {@code ....} 372 static > Object[] cdsGenerateHolderClasses(String[] lines) { this can be made > private as it's invoked by VM only. Can you move it to the end of the Will change access to 'private' > file. 373 try { 374 Map result = > generateHolderClasses(Arrays.stream(lines)); 375 if (result == null) { > 376 return null; 377 } > > generateHolderClasses should never return null and so line 371-377 can > be dropped. ? I also suggest to add in the generateHolderClasses method > to add Objects.requireNonNull(traces). > Will drop the check and add Objects.requireNonNull(traces). > 379???????????? Object[] ret_array = new Object[size * 2]; > > Rename `ret_array` to retArray to follow the naming convention using camel case. > > src/java.base/share/classes/jdk/internal/misc/VM.java > 457 isDumpLoadedClassListSetAndOpen = isDumpLoadedClassListSetAndOpen0(); > > This should be cached in the caller who checks if -XX:+DumpLoadedClassList > instead of every VM initialization. > > Since there are many CDS-related methods, I think it's time to introduce > a new CDS class for these methods to reside (maybe jdk.internal.vm.CDS?). > > I suggest to add CDS:logTraceResolve(String line) method that > will check if isDumpLoadedClassListSetAndOpen is true, then call the > native cdsTraceResolve (or whatever name). This way, > GenerateJLIClassesHelper can simply call CDS::logTraceResolve. > Created a separate issue https://bugs.openjdk.java.net/browse/JDK-8253208 to move CDS method to CDS.java All CDS related code will be added to CDS.java > 493 * Output to DumpLoadedClassList, format is simimar to LF_RESOLVE > > s/simimar/similar > > 494 * @see InvokerBytecodeGenerator > 495 * @param line the line to output. > > @see is typically placed after @param. > > Should it say @see java.lang.invoke.GenerateJLIClassesHelper::traceLambdaForm > instead of InvokerBytecodeGenerator? > Right, will change that to the suggestion. > Mandy > > On 9/15/20 12:15 PM, Yumin Qi wrote: ------------- PR: https://git.openjdk.java.net/jdk/pull/193 From fyang at openjdk.java.net Thu Sep 17 04:26:15 2020 From: fyang at openjdk.java.net (Fei Yang) Date: Thu, 17 Sep 2020 04:26:15 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic Message-ID: Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. Patch passed jtreg tier1-3 tests with QEMU system emulator. Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make sure that there's no regression. We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java We measured the performance benefit with an aarch64 cycle-accurate simulator. Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is detected. ------------- Commit messages: - Fix trailing whitespace issue - 8252204: AArch64: Implement SHA3 accelerator/intrinsic Changes: https://git.openjdk.java.net/jdk/pull/207/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252204 Stats: 1021 lines in 31 files changed: 947 ins; 13 del; 61 mod Patch: https://git.openjdk.java.net/jdk/pull/207.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207 PR: https://git.openjdk.java.net/jdk/pull/207 From iklam at openjdk.java.net Thu Sep 17 04:44:48 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 17 Sep 2020 04:44:48 GMT Subject: RFR: 8081833: Clean up JVMFlag getter/setter code [v2] In-Reply-To: References: Message-ID: > This is a follow to [JDK-8243208 Clean up JVMFlag implementation](https://bugs.openjdk.java.net/browse/JDK-8243208). > > I try to use templates and inheritance (and a bit of macros) to get rid of the large amount of duplicated code in the > JVMFlag getters/setters. > Stefan Karlsson and I have tried this several times already, but I think the current attempt probably has the least > amount of hacks and most functionality: > - Type safety is enforced up to the point of loading/storing `JVMFlag::_addr`, without any unchecked typecasts. > - Runtime type checking is implemented by the `JVM_FLAG_TYPE(t)` macro (see jvmFlagAccess.hpp), by passing along an > integer (`JVMFlag::TYPE_int`, etc). This is more efficient than previous attempts that passed along a function pointer > (see http://cr.openjdk.java.net/~stefank/8081833/webrev.04/) > - The old `JVMFlag::xxxAtPut` functions were undocumented. There are actually two groups that have different usage. I > added documentation in jvmFlagAccess.hpp to explain this. > - I got rid of the `JVMFlagEx` class and moved the code into `JVMFlag`. This is possible with C++11 which allows forward > declaration of `enum JVMFlagsEnum : int;` > - I changed `JVMFlag::_type` from a string into an enum. I am surprised this had lasted for over 20 years. > - I also changed `JVMFlag` from a struct into a class and made some fields private. I probably will do more cleanup in a > separate RFE. > > Please start with jvmFlagAccess.hpp, jvmFlagAccess.hpp and then globals_extension.hpp. > > Probably not everyone is in love with the `JVM_FLAG_TYPE(t)` macro. I'll be happy to try out alternatives. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Updated according to feedback from Gerard and Coleen ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/163/files - new: https://git.openjdk.java.net/jdk/pull/163/files/52fc6fd9..696a9412 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=163&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=163&range=00-01 Stats: 58 lines in 6 files changed: 16 ins; 6 del; 36 mod Patch: https://git.openjdk.java.net/jdk/pull/163.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/163/head:pull/163 PR: https://git.openjdk.java.net/jdk/pull/163 From minqi at openjdk.java.net Thu Sep 17 04:58:54 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 17 Sep 2020 04:58:54 GMT Subject: RFR: 8253262: Allocate in DumpRegion is not thread safe Message-ID: At CDS dump, the symbols are allocated from _dump_region (DumpRegion) which is global, and not thread safe when executed in JavaThread. Add a lock DumpRegoin_lock to guard symbol allocation from it. Tests: tier1-4 ------------- Commit messages: - 8253262: Allocate in DumpRegion is not thread safe Changes: https://git.openjdk.java.net/jdk/pull/216/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=216&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253262 Stats: 12 lines in 3 files changed: 5 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/216.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/216/head:pull/216 PR: https://git.openjdk.java.net/jdk/pull/216 From iklam at openjdk.java.net Thu Sep 17 05:15:49 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 17 Sep 2020 05:15:49 GMT Subject: RFR: 8253271: vm_version_x86.hpp should not include globals_extension.hpp Message-ID: [vm_version_x86.hpp](https://github.com/openjdk/jdk/blob/b87a1599674b8a73f489330decf051d1be9e9fba/src/hotspot/cpu/x86/vm_version_x86.hpp#L30) is a popular header file (which in itself is a problem but I'll fix that in a separate RFE) and it unnecessarily includes globals_extension.hpp. Removing this dependency reduces the number of cpp files that include globals_extension.hpp from 814 to 67. I need to fix cpp files that use macros like FLAG_SET_ERGO but forgot to include globals_extension.hpp. ------------- Commit messages: - 8253271: vm_version_x86.hpp should not include globals_extension.hpp Changes: https://git.openjdk.java.net/jdk/pull/217/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=217&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253271 Stats: 29 lines in 26 files changed: 24 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/217.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/217/head:pull/217 PR: https://git.openjdk.java.net/jdk/pull/217 From jbhateja at openjdk.java.net Thu Sep 17 05:16:52 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 17 Sep 2020 05:16:52 GMT Subject: RFR: 8252847: New AVX512 optimized stubs for both conjoint and disjoint arraycopy [v2] In-Reply-To: References: Message-ID: > Summary: > > 1) New AVX3 optimized stubs for both conjoint and disjoint arraycopy. > 2) Special instruction sequence blocks for copy sizes b/w 32-192 bytes. > 3) Block copy operation above 192 bytes is performed using destination address aligned PRE-MAIN-POST loop. Main loop > copies 192 byte in one iteration and tail part fall over special instruction sequence blocks. 4) Both small copy block > and aligned loop use 32 byte vector register to prevent and frequency penalty for copy sizes less than AVX3Threshold. > 5) For block size above AVX3Theshold both special blocks and loop operate using 64 byte register. 6) In case user > sets the maximum vector size to 32 bytes, forward copy (disjoint) operations are done using efficient REP MOVS for copy > sizes above 4096 bytes. JMH Results: > System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz > Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java > Baseline : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_Baseline.txt]() > WithOpt : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_WithOpts.txt]() Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8252847: Review comments resolution ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/61/files - new: https://git.openjdk.java.net/jdk/pull/61/files/b4f4081f..0cd42ccb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=61&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=61&range=00-01 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/61.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/61/head:pull/61 PR: https://git.openjdk.java.net/jdk/pull/61 From jbhateja at openjdk.java.net Thu Sep 17 05:20:24 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 17 Sep 2020 05:20:24 GMT Subject: RFR: 8252847: New AVX512 optimized stubs for both conjoint and disjoint arraycopy [v2] In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 13:12:48 GMT, Nils Eliasson wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8252847: Review comments resolution > > src/hotspot/cpu/x86/macroAssembler_x86.cpp line 7971: > >> 7969: BasicType type, int offset, bool use64byteVector) { >> 7970: assert(MaxVectorSize >= 32, "vector length < 32"); >> 7971: use64byteVector |= MaxVectorSize > 32 && AVX3Threshold == 0; > > When do you expect AVX3Threshold to be 0? As of now when user explicitly pass -XX:AVX3Threshold=0 , default value of AVX3Threshold is 4096. ------------- PR: https://git.openjdk.java.net/jdk/pull/61 From fyang at openjdk.java.net Thu Sep 17 05:21:04 2020 From: fyang at openjdk.java.net (Fei Yang) Date: Thu, 17 Sep 2020 05:21:04 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 16:36:54 GMT, Fei Yang wrote: > Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com > > This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. > Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 > > Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. > For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. > "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. > > We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. > Patch passed jtreg tier1-3 tests with QEMU system emulator. > Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make > sure that there's no regression. > We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java > We measured the performance benefit with an aarch64 cycle-accurate simulator. > Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. > > For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on > real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is > detected. @ardbiesheuvel : Ard, could you please ack this patch? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/207 From github.com+2249648+JohnTortugo at openjdk.java.net Thu Sep 17 05:31:53 2020 From: github.com+2249648+JohnTortugo at openjdk.java.net (John Tortugo) Date: Thu, 17 Sep 2020 05:31:53 GMT Subject: RFR: 8253271: vm_version_x86.hpp should not include globals_extension.hpp In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 05:05:06 GMT, Ioi Lam wrote: > [vm_version_x86.hpp](https://github.com/openjdk/jdk/blob/b87a1599674b8a73f489330decf051d1be9e9fba/src/hotspot/cpu/x86/vm_version_x86.hpp#L30) > is a popular header file (which in itself is a problem but I'll fix that in a separate RFE) and it unnecessarily > includes globals_extension.hpp. Removing this dependency reduces the number of cpp files that include > globals_extension.hpp from 814 to 67. > I need to fix cpp files that use macros like FLAG_SET_ERGO but forgot to include globals_extension.hpp. LGTM :-) ------------- Marked as reviewed by JohnTortugo at github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/217 From dholmes at openjdk.java.net Thu Sep 17 06:26:20 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 17 Sep 2020 06:26:20 GMT Subject: RFR: 8253262: Allocate in DumpRegion is not thread safe In-Reply-To: References: Message-ID: <7E5bn2lcjNgS4ufEklr-ljg6_rLVaGnTBka9iqvo6Js=.c9cdbbcf-4713-48a3-9e57-dac745cdc580@github.com> On Thu, 17 Sep 2020 04:52:29 GMT, Yumin Qi wrote: > At CDS dump, the symbols are allocated from _dump_region (DumpRegion) which is global, and not thread safe when > executed in JavaThread. Add a lock DumpRegoin_lock to guard symbol allocation from it. > Tests: tier1-4 This seems okay but isn't dumping done at a safepoint? ------------- PR: https://git.openjdk.java.net/jdk/pull/216 From dholmes at openjdk.java.net Thu Sep 17 06:31:51 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 17 Sep 2020 06:31:51 GMT Subject: RFR: 8253271: vm_version_x86.hpp should not include globals_extension.hpp In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 05:05:06 GMT, Ioi Lam wrote: > [vm_version_x86.hpp](https://github.com/openjdk/jdk/blob/b87a1599674b8a73f489330decf051d1be9e9fba/src/hotspot/cpu/x86/vm_version_x86.hpp#L30) > is a popular header file (which in itself is a problem but I'll fix that in a separate RFE) and it unnecessarily > includes globals_extension.hpp. Removing this dependency reduces the number of cpp files that include > globals_extension.hpp from 814 to 67. > I need to fix cpp files that use macros like FLAG_SET_ERGO but forgot to include globals_extension.hpp. Looks good - and trivial assuming all builds are good. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/217 From goetz at openjdk.java.net Thu Sep 17 07:48:38 2020 From: goetz at openjdk.java.net (Goetz Lindenmaier) Date: Thu, 17 Sep 2020 07:48:38 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 20:48:23 GMT, Richard Reingruber wrote: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. Marked as reviewed by goetz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From goetz at openjdk.java.net Thu Sep 17 07:48:38 2020 From: goetz at openjdk.java.net (Goetz Lindenmaier) Date: Thu, 17 Sep 2020 07:48:38 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 07:44:09 GMT, Goetz Lindenmaier wrote: >> Hi, >> >> this is the continuation of the review of the implementation for: >> >> https://bugs.openjdk.java.net/browse/JDK-8227745 >> https://bugs.openjdk.java.net/browse/JDK-8233915 >> >> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references >> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such >> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka >> "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: >> >> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ >> >> Thanks, Richard. > > Marked as reviewed by goetz (Reviewer). Reviewed in the good old hg times :) See also http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041453.html ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From shade at openjdk.java.net Thu Sep 17 08:24:23 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 17 Sep 2020 08:24:23 GMT Subject: RFR: 8253275: Remove unused methods after CMS removal Message-ID: <1w-I-vXmBTNCpZOzNVjkQPiqifIc8GuyI8begawVUkU=.06f66f48-f6ab-462c-a039-8fa39faf3e0d@github.com> Static analysis shows a few examples of methods that are not used/implemented after CMS removal. We can purge them. Testing: text searches over the code base, no hits; Linux x86_64 builds ------------- Commit messages: - 8253275: Remove unused methods after CMS removal Changes: https://git.openjdk.java.net/jdk/pull/219/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=219&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253275 Stats: 12 lines in 2 files changed: 0 ins; 12 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/219.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/219/head:pull/219 PR: https://git.openjdk.java.net/jdk/pull/219 From pliden at openjdk.java.net Thu Sep 17 08:34:33 2020 From: pliden at openjdk.java.net (Per =?UTF-8?B?TGlkw6lu?=) Date: Thu, 17 Sep 2020 08:34:33 GMT Subject: RFR: 8253275: Remove unused methods after CMS removal In-Reply-To: <1w-I-vXmBTNCpZOzNVjkQPiqifIc8GuyI8begawVUkU=.06f66f48-f6ab-462c-a039-8fa39faf3e0d@github.com> References: <1w-I-vXmBTNCpZOzNVjkQPiqifIc8GuyI8begawVUkU=.06f66f48-f6ab-462c-a039-8fa39faf3e0d@github.com> Message-ID: On Thu, 17 Sep 2020 08:17:49 GMT, Aleksey Shipilev wrote: > Static analysis shows a few examples of methods that are not used/implemented after CMS removal. We can purge them. > > Testing: text searches over the code base, no hits; Linux x86_64 builds Thanks for cleaning! ------------- Marked as reviewed by pliden (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/219 From thomas.schatzl at oracle.com Thu Sep 17 08:41:54 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 17 Sep 2020 10:41:54 +0200 Subject: RFR: 8253275: Remove unused methods after CMS removal In-Reply-To: <1w-I-vXmBTNCpZOzNVjkQPiqifIc8GuyI8begawVUkU=.06f66f48-f6ab-462c-a039-8fa39faf3e0d@github.com> References: <1w-I-vXmBTNCpZOzNVjkQPiqifIc8GuyI8begawVUkU=.06f66f48-f6ab-462c-a039-8fa39faf3e0d@github.com> Message-ID: <93cd59ce-27f4-dd29-65f3-d676241c0b80@oracle.com> Hi, On 17.09.20 10:24, Aleksey Shipilev wrote: > Static analysis shows a few examples of methods that are not used/implemented after CMS removal. We can purge them. > > Testing: text searches over the code base, no hits; Linux x86_64 builds Please also remove Generation::sample_eden_chunk(). There is apparently no one overriding this empty method. Thanks, Thomas From shade at openjdk.java.net Thu Sep 17 08:44:09 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 17 Sep 2020 08:44:09 GMT Subject: RFR: 8253278: Refactor/cleanup oopDesc::*_klass_addr Message-ID: Right now this one has the comment mentioning CMS: Klass** oopDesc::klass_addr(HeapWord* mem) { // Only used internally and with CMS and will not work with // UseCompressedOops assert(!UseCompressedClassPointers, "only supported with uncompressed klass pointers"); ByteSize offset = byte_offset_of(oopDesc, _metadata._klass); return (Klass**) (((char*)mem) + in_bytes(offset)); } But that is not true, it is used on the generic paths. The rest are the snowballing changes: - in `load_klass_raw` and `set_klass`: `compressed_klass_addr` and `klass_addr` are used where the direct access to `_metadata` can be done, avoiding these methods - the leftover use is in `set_klass_release`, where we can simplify things by inlining `_addr` methods directly - `CHECK_SET_KLASS` macro seems too much ceremony for just two asserts Note that new code uses the universal `klass_offset_in_bytes`, that is technically `offset_of(..., _metadata._klass)`. This is different from the previous code, but it matches what other code is doing -- it trusts that both `_metadata._klass` and `_metadata._compressed_klass` are on the same offsets. I thought to add a very paranoid assert there, but decided not to. Testing: Linux x86_64 fastdebug tier1 ------------- Commit messages: - Whitespace - Simplify it even more - 8253278: Refactor/cleanup oopDesc::*_klass_addr Changes: https://git.openjdk.java.net/jdk/pull/221/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=221&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253278 Stats: 46 lines in 3 files changed: 1 ins; 34 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/221.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/221/head:pull/221 PR: https://git.openjdk.java.net/jdk/pull/221 From shade at openjdk.java.net Thu Sep 17 09:00:30 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 17 Sep 2020 09:00:30 GMT Subject: RFR: 8253275: Remove unused methods after CMS removal [v2] In-Reply-To: <1w-I-vXmBTNCpZOzNVjkQPiqifIc8GuyI8begawVUkU=.06f66f48-f6ab-462c-a039-8fa39faf3e0d@github.com> References: <1w-I-vXmBTNCpZOzNVjkQPiqifIc8GuyI8begawVUkU=.06f66f48-f6ab-462c-a039-8fa39faf3e0d@github.com> Message-ID: <5eu_OJfscRYQT-CDyJ1EgJJHcLe0rpGN9E0TZV2n1tI=.4548a352-93b3-452b-8dc4-6dc3c5eb9f54@github.com> > Static analysis shows a few examples of methods that are not used/implemented after CMS removal. We can purge them. > > Testing: text searches over the code base, no hits; Linux x86_64 builds Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Remove Generation::sample_eden_chunk() too and rewire some code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/219/files - new: https://git.openjdk.java.net/jdk/pull/219/files/1b7c966f..0b131007 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=219&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=219&range=00-01 Stats: 12 lines in 2 files changed: 0 ins; 10 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/219.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/219/head:pull/219 PR: https://git.openjdk.java.net/jdk/pull/219 From shade at openjdk.java.net Thu Sep 17 09:00:34 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 17 Sep 2020 09:00:34 GMT Subject: RFR: 8253275: Remove unused methods after CMS removal [v2] In-Reply-To: References: <1w-I-vXmBTNCpZOzNVjkQPiqifIc8GuyI8begawVUkU=.06f66f48-f6ab-462c-a039-8fa39faf3e0d@github.com> Message-ID: On Thu, 17 Sep 2020 08:32:12 GMT, Per Lid?n wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove Generation::sample_eden_chunk() too and rewire some code > > Thanks for cleaning! > Please also remove Generation::sample_eden_chunk(). There is apparently > no one overriding this empty method. Right. Did so! Running some tests to make sure my rewire did not break stuff. ------------- PR: https://git.openjdk.java.net/jdk/pull/219 From tschatzl at openjdk.java.net Thu Sep 17 09:14:46 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 17 Sep 2020 09:14:46 GMT Subject: RFR: 8253275: Remove unused methods after CMS removal [v2] In-Reply-To: <5eu_OJfscRYQT-CDyJ1EgJJHcLe0rpGN9E0TZV2n1tI=.4548a352-93b3-452b-8dc4-6dc3c5eb9f54@github.com> References: <1w-I-vXmBTNCpZOzNVjkQPiqifIc8GuyI8begawVUkU=.06f66f48-f6ab-462c-a039-8fa39faf3e0d@github.com> <5eu_OJfscRYQT-CDyJ1EgJJHcLe0rpGN9E0TZV2n1tI=.4548a352-93b3-452b-8dc4-6dc3c5eb9f54@github.com> Message-ID: On Thu, 17 Sep 2020 09:00:30 GMT, Aleksey Shipilev wrote: >> Static analysis shows a few examples of methods that are not used/implemented after CMS removal. We can purge them. >> >> Testing: text searches over the code base, no hits; Linux x86_64 builds > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Remove Generation::sample_eden_chunk() too and rewire some code Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/219 From pliden at openjdk.java.net Thu Sep 17 10:04:58 2020 From: pliden at openjdk.java.net (Per =?UTF-8?B?TGlkw6lu?=) Date: Thu, 17 Sep 2020 10:04:58 GMT Subject: RFR: 8253275: Remove unused methods after CMS removal [v2] In-Reply-To: References: <1w-I-vXmBTNCpZOzNVjkQPiqifIc8GuyI8begawVUkU=.06f66f48-f6ab-462c-a039-8fa39faf3e0d@github.com> <5eu_OJfscRYQT-CDyJ1EgJJHcLe0rpGN9E0TZV2n1tI=.4548a352-93b3-452b-8dc4-6dc3c5eb9f54@github.com> Message-ID: <7OOoeVgmWyPcOXZHHmQfmjvXn3ya0JQNDaCOuosizp0=.9744cbdd-9683-41e1-bcf2-c08206fc0812@github.com> On Thu, 17 Sep 2020 09:12:19 GMT, Thomas Schatzl wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove Generation::sample_eden_chunk() too and rewire some code > > Lgtm. @shipilev Looks good! ------------- PR: https://git.openjdk.java.net/jdk/pull/219 From shade at openjdk.java.net Thu Sep 17 10:04:58 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 17 Sep 2020 10:04:58 GMT Subject: Integrated: 8253275: Remove unused methods after CMS removal In-Reply-To: <1w-I-vXmBTNCpZOzNVjkQPiqifIc8GuyI8begawVUkU=.06f66f48-f6ab-462c-a039-8fa39faf3e0d@github.com> References: <1w-I-vXmBTNCpZOzNVjkQPiqifIc8GuyI8begawVUkU=.06f66f48-f6ab-462c-a039-8fa39faf3e0d@github.com> Message-ID: On Thu, 17 Sep 2020 08:17:49 GMT, Aleksey Shipilev wrote: > Static analysis shows a few examples of methods that are not used/implemented after CMS removal. We can purge them. > > Testing: text searches over the code base, no hits; Linux x86_64 builds This pull request has now been integrated. Changeset: a9993f94 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/a9993f94 Stats: 24 lines in 3 files changed: 22 ins; 0 del; 2 mod 8253275: Remove unused methods after CMS removal Reviewed-by: pliden, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/219 From shade at openjdk.java.net Thu Sep 17 10:08:24 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 17 Sep 2020 10:08:24 GMT Subject: RFR: 8253278: Refactor/cleanup oopDesc::*_klass_addr In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 08:37:26 GMT, Aleksey Shipilev wrote: > Right now this one has the comment mentioning CMS: > > Klass** oopDesc::klass_addr(HeapWord* mem) { > // Only used internally and with CMS and will not work with > // UseCompressedOops > assert(!UseCompressedClassPointers, "only supported with uncompressed klass pointers"); > ByteSize offset = byte_offset_of(oopDesc, _metadata._klass); > return (Klass**) (((char*)mem) + in_bytes(offset)); > } > > But that is not true, it is used on the generic paths. > > The rest are the snowballing changes: > - in `load_klass_raw` and `set_klass`: `compressed_klass_addr` and `klass_addr` are used where the direct access to > `_metadata` can be done, avoiding these methods > - the leftover use is in `set_klass_release`, where we can simplify things by inlining `_addr` methods directly > - `CHECK_SET_KLASS` macro seems too much ceremony for just two asserts > > Note that new code uses the universal `klass_offset_in_bytes`, that is technically `offset_of(..., _metadata._klass)`. > This is different from the previous code, but it matches what other code is doing -- it trusts that both > `_metadata._klass` and `_metadata._compressed_klass` are on the same offsets. I thought to add a very paranoid assert > there, but decided not to. Testing: Linux x86_64 fastdebug tier1 objdumped `MemAllocator::finish` that uses `oop::set_klass_release`, and it has no differences. Looks like this before/after: 0000000000000000 <_ZNK12MemAllocator6finishEPP12HeapWordImpl>: 0: f3 0f 1e fa endbr64 4: 48 8b 0d 00 00 00 00 mov 0x0(%rip),%rcx # b <_ZNK12MemAllocator6finishEPP12HeapWordImpl+0xb> b: 48 89 f0 mov %rsi,%rax e: ba 01 00 00 00 mov $0x1,%edx 13: 80 39 00 cmpb $0x0,(%rcx) 16: 74 0b je 23 <_ZNK12MemAllocator6finishEPP12HeapWordImpl+0x23> 18: 48 8b 57 10 mov 0x10(%rdi),%rdx 1c: 48 8b 92 b8 00 00 00 mov 0xb8(%rdx),%rdx 23: 48 8b 0d 00 00 00 00 mov 0x0(%rip),%rcx # 2a <_ZNK12MemAllocator6finishEPP12HeapWordImpl+0x2a> 2a: 48 89 10 mov %rdx,(%rax) 2d: 48 8b 57 10 mov 0x10(%rdi),%rdx 31: 80 39 00 cmpb $0x0,(%rcx) 34: 74 1a je 50 <_ZNK12MemAllocator6finishEPP12HeapWordImpl+0x50> 36: 48 8b 0d 00 00 00 00 mov 0x0(%rip),%rcx # 3d <_ZNK12MemAllocator6finishEPP12HeapWordImpl+0x3d> 3d: 48 2b 11 sub (%rcx),%rdx 40: 8b 49 08 mov 0x8(%rcx),%ecx 43: 48 d3 ea shr %cl,%rdx 46: 89 50 08 mov %edx,0x8(%rax) 49: c3 retq 4a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) 50: 48 89 50 08 mov %rdx,0x8(%rax) 54: c3 retq 55: 90 nop 56: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) 5d: 00 00 00 ------------- PR: https://git.openjdk.java.net/jdk/pull/221 From coleenp at openjdk.java.net Thu Sep 17 11:49:39 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Sep 2020 11:49:39 GMT Subject: RFR: 8253278: Refactor/cleanup oopDesc::*_klass_addr In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 08:37:26 GMT, Aleksey Shipilev wrote: > Right now this one has the comment mentioning CMS: > > Klass** oopDesc::klass_addr(HeapWord* mem) { > // Only used internally and with CMS and will not work with > // UseCompressedOops > assert(!UseCompressedClassPointers, "only supported with uncompressed klass pointers"); > ByteSize offset = byte_offset_of(oopDesc, _metadata._klass); > return (Klass**) (((char*)mem) + in_bytes(offset)); > } > > But that is not true, it is used on the generic paths. > > The rest are the snowballing changes: > - in `load_klass_raw` and `set_klass`: `compressed_klass_addr` and `klass_addr` are used where the direct access to > `_metadata` can be done, avoiding these methods > - the leftover use is in `set_klass_release`, where we can simplify things by inlining `_addr` methods directly > - `CHECK_SET_KLASS` macro seems too much ceremony for just two asserts > > Note that new code uses the universal `klass_offset_in_bytes`, that is technically `offset_of(..., _metadata._klass)`. > This is different from the previous code, but it matches what other code is doing -- it trusts that both > `_metadata._klass` and `_metadata._compressed_klass` are on the same offsets. I thought to add a very paranoid assert > there, but decided not to. Testing: Linux x86_64 fastdebug tier1 Nice cleanup!! I'm happy to see klass_addr go. It took me a while to reconcile that klass_offset_in_bytes points to _metadata._compressed_klass but I believe it's correct, and used everywhere else so it better be. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/221 From coleenp at openjdk.java.net Thu Sep 17 11:54:19 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Sep 2020 11:54:19 GMT Subject: RFR: 8081833: Clean up JVMFlag getter/setter code [v2] In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 04:44:48 GMT, Ioi Lam wrote: >> This is a follow to [JDK-8243208 Clean up JVMFlag implementation](https://bugs.openjdk.java.net/browse/JDK-8243208). >> >> I try to use templates and inheritance (and a bit of macros) to get rid of the large amount of duplicated code in the >> JVMFlag getters/setters. >> Stefan Karlsson and I have tried this several times already, but I think the current attempt probably has the least >> amount of hacks and most functionality: >> - Type safety is enforced up to the point of loading/storing `JVMFlag::_addr`, without any unchecked typecasts. >> - Runtime type checking is implemented by the `JVM_FLAG_TYPE(t)` macro (see jvmFlagAccess.hpp), by passing along an >> integer (`JVMFlag::TYPE_int`, etc). This is more efficient than previous attempts that passed along a function pointer >> (see http://cr.openjdk.java.net/~stefank/8081833/webrev.04/) >> - The old `JVMFlag::xxxAtPut` functions were undocumented. There are actually two groups that have different usage. I >> added documentation in jvmFlagAccess.hpp to explain this. >> - I got rid of the `JVMFlagEx` class and moved the code into `JVMFlag`. This is possible with C++11 which allows forward >> declaration of `enum JVMFlagsEnum : int;` >> - I changed `JVMFlag::_type` from a string into an enum. I am surprised this had lasted for over 20 years. >> - I also changed `JVMFlag` from a struct into a class and made some fields private. I probably will do more cleanup in a >> separate RFE. >> >> Please start with jvmFlagAccess.hpp, jvmFlagAccess.hpp and then globals_extension.hpp. >> >> Probably not everyone is in love with the `JVM_FLAG_TYPE(t)` macro. I'll be happy to try out alternatives. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Updated according to feedback from Gerard and Coleen The new names are nice. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/163 From rehn at openjdk.java.net Thu Sep 17 12:07:15 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 17 Sep 2020 12:07:15 GMT Subject: RFR: 8238761: Asynchronous handshakes [v2] In-Reply-To: References: Message-ID: > This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes > are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) > Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an > arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a > singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first > pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first > pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake > operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything > except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed > filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake > operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there > is now only one method to call when handshaking one thread. Some comments about the changes: > - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake > all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much > worse then this. > > - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that > thread. > > - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a > handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. > > - Added WB testing method. > > - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. > > - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. > > - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a > safepoint and half of them after, in many handshake all operations. > > - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. > > - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the > moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. > > - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to the NoSafepointVerifyer. > > - Added filtered queue and gtest for it. > > Passes multiple t1-8 runs. > Been through some pre-reviwing. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Fixed double checks Added NSV ProcessResult to enum Fixed logging Moved _active_handshaker to private ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/151/files - new: https://git.openjdk.java.net/jdk/pull/151/files/efbee6f0..86b83d05 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=151&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=151&range=00-01 Stats: 72 lines in 4 files changed: 32 ins; 15 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/151/head:pull/151 PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Thu Sep 17 12:12:28 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 17 Sep 2020 12:12:28 GMT Subject: RFR: 8238761: Asynchronous handshakes In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 13:00:59 GMT, Robbin Ehn wrote: > This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes > are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) > Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an > arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a > singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first > pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first > pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake > operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything > except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed > filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake > operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there > is now only one method to call when handshaking one thread. Some comments about the changes: > - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake > all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much > worse then this. > > - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that > thread. > > - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a > handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. > > - Added WB testing method. > > - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. > > - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. > > - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a > safepoint and half of them after, in many handshake all operations. > > - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. > > - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the > moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. > > - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to the NoSafepointVerifyer. > > - Added filtered queue and gtest for it. > > Passes multiple t1-8 runs. > Been through some pre-reviwing. > src/hotspot/share/prims/jvmtiThreadState.cpp > src/hotspot/share/prims/jvmtiEnvBase.cpp Removed double checks. > src/hotspot/share/runtime/handshake.cpp > ... > I would just leave ProcessResult as an enum and log as before. Reverted to plain enum and updated logs. (better?) > src/hotspot/share/runtime/handshake.cpp > 387: NoSafepointVerifier nsv; > 388: process_self_inner(); I wanted a NSV to cover the process_self_inner method. So I added a second one in suggested place: > NoSafepointVerifier nsv; > _handshake_cl->do_thread(thread); > } > src/hotspot/share/runtime/interfaceSupport.inline.hpp > 156: // Threads shouldn't block if they are in the middle of > printing, but... > 157: ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); > What's the issue of having NoSafepointVerifier inside the handshake? Sorry, the issue is the lock rank. Right now the semaphore hides this issue. Please see commit 86b83d0. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From neliasso at openjdk.java.net Thu Sep 17 13:24:54 2020 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Thu, 17 Sep 2020 13:24:54 GMT Subject: RFR: 8252847: New AVX512 optimized stubs for both conjoint and disjoint arraycopy [v2] In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 05:16:52 GMT, Jatin Bhateja wrote: >> Summary: >> >> 1) New AVX3 optimized stubs for both conjoint and disjoint arraycopy. >> 2) Special instruction sequence blocks for copy sizes b/w 32-192 bytes. >> 3) Block copy operation above 192 bytes is performed using destination address aligned PRE-MAIN-POST loop. Main loop >> copies 192 byte in one iteration and tail part fall over special instruction sequence blocks. 4) Both small copy block >> and aligned loop use 32 byte vector register to prevent and frequency penalty for copy sizes less than AVX3Threshold. >> 5) For block size above AVX3Theshold both special blocks and loop operate using 64 byte register. 6) In case user >> sets the maximum vector size to 32 bytes, forward copy (disjoint) operations are done using efficient REP MOVS for copy >> sizes above 4096 bytes. JMH Results: >> System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz >> Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java >> Baseline : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_Baseline.txt]() >> WithOpt : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_WithOpts.txt]() > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8252847: Review comments resolution I like that you have extracted the avx512 stub code from the rest - that makes it a lot more readable! Overall the new code feels easy to understand and read. I found one more minor issue (appears in four places). My only concern is that it's getting hard to follow under what circumstances avx3 instructions are used: Could it be the case that different thresholds are needed for when you are using avx3 instructions with 32 or 64 byte vectors? Are we sure all variants are tested? Also - have you thought about supporting oop-copies? You only have to call the BarrierSetAssembler::arraycopy_prologue/epilogue like in the old versions. It's not a requirement for me to approve this - but an encouragement for a future patch. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2390: > 2388: address *entry, const char *name, > 2389: bool dest_uninitialized = false) { > 2390: if (VM_Version::supports_avx512vlbw() && false == is_oop && MaxVectorSize >= 32) { "false == is_oop" => !is_oop src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2501: > 2499: address generate_disjoint_long_oop_copy(bool aligned, bool is_oop, address *entry, > 2500: const char *name, bool dest_uninitialized = false) { > 2501: if (VM_Version::supports_avx512vlbw() && false == is_oop && MaxVectorSize >= 32) { false == is_oop => !is_oop src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2608: > 2606: address nooverlap_target, address *entry, > 2607: const char *name, bool dest_uninitialized = false) { > 2608: if (VM_Version::supports_avx512vlbw() && false == is_oop && MaxVectorSize >= 32) { false == is_oop => !is_oop src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 2282: > 2280: address generate_disjoint_int_oop_copy(bool aligned, bool is_oop, address* entry, > 2281: const char *name, bool dest_uninitialized = false) { > 2282: if (VM_Version::supports_avx512vlbw() && false == is_oop && MaxVectorSize >= 32) { false == is_oop => !is_oop ------------- Changes requested by neliasso (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/61 From dnsimon at openjdk.java.net Thu Sep 17 14:29:34 2020 From: dnsimon at openjdk.java.net (Doug Simon) Date: Thu, 17 Sep 2020 14:29:34 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: References: Message-ID: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> On Thu, 10 Sep 2020 11:52:34 GMT, Allan Gregersen wrote: > The idea is to add a more powerful API for cases where the current iterateFrames API cannot be used. > > For example, a debugger needs access to the content of stack frames such as local variables or monitors. In cases where > threads execute in the runtime or in native code, it's not possible to obtain a thread suspension hook, for which > iterateFrames can be used on the suspended thread. The getStackFrames method enables an immediate stack frames lookup > regardless of the status of the underlying thread. Another use case would be for lookup of backtraces for non-current > threads. The implementation is done by means of a VM operation that collects vframe data for each thread during a > safepoint, whereafter required object reallocation/reassign fields is performed based on the collected snapshot. @vnkozlov @veresov @dean-long it would be great to get some reviews of this soon. To assist, let me try provide a little more context on the area of JVMCI which is motivated by [Truffle](https://www.graalvm.org/truffle/javadoc/com/oracle/truffle/api/package-summary.html). The [`StackIntrospection.iterateFrames()`](https://github.com/openjdk/jdk/blob/6bab0f539fba8fb441697846347597b4a0ade428/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/stack/StackIntrospection.java#L45) API exists for Truffle to support walking guest language frames. In Truffle, all values, including primitives, are boxed which explains why there is no `InspectedFrame.setLocal(int index, Object value)` method. All Truffle guest language frame locals are accessed/updated by reading/updating the boxed value returned by `InspectedFrame.getLocal()`. With this existing API, a thread can only inspect its own stack frames. As the description of this PR states, it extends `StackIntrospection.iterateFrames()` with `StackIntrospection.getStackFrames()` so that a thread can inspect the frames of other threads. It is somewhat analogous to `java.lang.Thread.getAllStackTraces()` except it allows the local variables of the frames to be accessed as well. src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/stack/StackIntrospection.java line 52: > 50: * that any client inspecting and possibly mutating the frame contents will do so under the > 51: * assumption that the underlying threads might have continued, executing potentially > 52: * invalidating the frame state. "... might have continued, executing potentially invalidating the frame state." Not sure what this is trying to say. Maybe you mean something like "... might have continued, in which case mutations are not reflected in the running thread state." src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/stack/StackIntrospection.java line 55: > 53: * > 54: * Note that the locals of the {@link InspectedFrame}s will be collected as copies when the > 55: * underlying frame was compiled, whereas they'll be references for interpreted frames. Use "will be collected as copies when the underlying frame was compiled" - what does that mean? ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From github.com+8448088+ardbiesheuvel at openjdk.java.net Thu Sep 17 15:35:28 2020 From: github.com+8448088+ardbiesheuvel at openjdk.java.net (Ard Biesheuvel) Date: Thu, 17 Sep 2020 15:35:28 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 05:18:28 GMT, Fei Yang wrote: >> Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com >> >> This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. >> Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 >> >> Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. >> For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. >> "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. >> >> We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. >> Patch passed jtreg tier1-3 tests with QEMU system emulator. >> Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make >> sure that there's no regression. >> We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java >> We measured the performance benefit with an aarch64 cycle-accurate simulator. >> Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. >> >> For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on >> real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is >> detected. > > @ardbiesheuvel : Ard, could you please ack this patch? Thanks. Acked-by: Ard Biesheuvel ------------- PR: https://git.openjdk.java.net/jdk/pull/207 From minqi at openjdk.java.net Thu Sep 17 15:37:01 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 17 Sep 2020 15:37:01 GMT Subject: RFR: 8253262: Allocate in DumpRegion is not thread safe In-Reply-To: <7E5bn2lcjNgS4ufEklr-ljg6_rLVaGnTBka9iqvo6Js=.c9cdbbcf-4713-48a3-9e57-dac745cdc580@github.com> References: <7E5bn2lcjNgS4ufEklr-ljg6_rLVaGnTBka9iqvo6Js=.c9cdbbcf-4713-48a3-9e57-dac745cdc580@github.com> Message-ID: <8oyagd-kWmHIVA31fptnrwze6nwaKVyeuIywtTFI4q0=.8c4d6af9-57ec-4fde-8d7e-b89129600ee8@github.com> On Thu, 17 Sep 2020 06:23:50 GMT, David Holmes wrote: > This seems okay but isn't dumping done at a safepoint? There is case the code is executed in other JavaThread (seen in Finalizer thread) other than the JavaThread which does loading classes and creating symbols. That is before the dump starts. The word 'at dump' seems misleading. ------------- PR: https://git.openjdk.java.net/jdk/pull/216 From ccheung at openjdk.java.net Thu Sep 17 16:16:01 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 17 Sep 2020 16:16:01 GMT Subject: RFR: 8253262: Allocate in DumpRegion is not thread safe In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 04:52:29 GMT, Yumin Qi wrote: > At CDS dump, the symbols are allocated from _dump_region (DumpRegion) which is global, and not thread safe when > executed in JavaThread. Add a lock DumpRegoin_lock to guard symbol allocation from it. > Tests: tier1-4 Looks good. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/216 From gziemski at openjdk.java.net Thu Sep 17 16:21:21 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 17 Sep 2020 16:21:21 GMT Subject: RFR: 8081833: Clean up JVMFlag getter/setter code [v2] In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 00:39:43 GMT, Ioi Lam wrote: >> src/hotspot/share/runtime/flags/jvmFlagLimit.cpp line 156: >> >>> 154: for (int i = 0; i < NUM_JVMFlagsEnum; i++) { >>> 155: JVMFlagsEnum flag_enum = static_cast(i); >>> 156: if (get_range_at(flag_enum) != NULL && >> >> VMFlagAccess::check_range(JVMFlag::flag_from_enum(flag_enum) will check for "get_range_at(flag_enum) != NULL", so no >> need for this check here? > > This function is called during VM start-up, so I want to short-circuit the check, and avoid calling > VMFlagAccess::check_range if the flag has no ranges. Nice >> src/hotspot/share/runtime/flags/jvmFlagAccess.cpp line 91: >> >>> 89: public: >>> 90: JVMFlag::Error set_impl(JVMFlag* flag, void* value_addr, JVMFlag::Flags origin) const { >>> 91: bool verbose = !JVMFlagLimit::validated_after_ergo(); >> >> Why only verbose when not AfterErgo? Maybe add comment explaining that. > > If I understand the old code correctly, we print out error messages only when parsing the command-line given by the > user. When we later override values that are set programmatically by the FLAG_SET_XXX() macros, we don't print out > error messages (or else the user will be confused). I will rewrite the code to make it clear, and add comments. Thank you ------------- PR: https://git.openjdk.java.net/jdk/pull/163 From gziemski at openjdk.java.net Thu Sep 17 16:21:21 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 17 Sep 2020 16:21:21 GMT Subject: RFR: 8081833: Clean up JVMFlag getter/setter code [v2] In-Reply-To: References: <2JTh7F6ztTcCnqB3jIiD9mWsrWKsB8HA3DkB7aIglro=.1e77bb73-1c5d-47e7-bf61-43166a84ab27@github.com> Message-ID: On Thu, 17 Sep 2020 00:53:22 GMT, Ioi Lam wrote: >> is_external() is odd and only has one caller. You could just fix the caller and remove is_external. > > Since I am doing a "syntactic" clean up, I want to keep the code behavior the same, without doing any "semantic" > changes. The caller of `is_external()` may have a (historically) different intention than the caller of > `is_manageable()`. I want to leave such clean up in separate RFEs. Makes sense ------------- PR: https://git.openjdk.java.net/jdk/pull/163 From gziemski at openjdk.java.net Thu Sep 17 16:21:22 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 17 Sep 2020 16:21:22 GMT Subject: RFR: 8081833: Clean up JVMFlag getter/setter code [v2] In-Reply-To: <4lPFH2IyTlvGQmqDAmJsHk9zx4y7EzBJOsSDcilYL2Q=.602e666a-3728-4643-a08e-59be0c3c6e4b@github.com> References: <4lPFH2IyTlvGQmqDAmJsHk9zx4y7EzBJOsSDcilYL2Q=.602e666a-3728-4643-a08e-59be0c3c6e4b@github.com> Message-ID: On Thu, 17 Sep 2020 01:01:54 GMT, Ioi Lam wrote: >> src/hotspot/share/prims/whitebox.cpp line 1423: >> >>> 1421: { >>> 1422: ThreadInVMfromNative ttvfn(thread); // back to VM >>> 1423: needFree = SetVMFlag (thread, env, name, &ccstrResult); >> >> I wonder if these whitebox methods could be rewritten as macros, like the jni.cpp methods, like: DEFINE_GETFIELD, etc, >> in a future RFE. > > I am not quite sure. On the one hand I like code reduction, but on the other hand macro-generated code will be > difficult to debug. I was unsure here whether to suggest the same change, and decided against. It's a fine line... ------------- PR: https://git.openjdk.java.net/jdk/pull/163 From gziemski at openjdk.java.net Thu Sep 17 16:27:48 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 17 Sep 2020 16:27:48 GMT Subject: RFR: 8081833: Clean up JVMFlag getter/setter code [v2] In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 04:44:48 GMT, Ioi Lam wrote: >> This is a follow to [JDK-8243208 Clean up JVMFlag implementation](https://bugs.openjdk.java.net/browse/JDK-8243208). >> >> I try to use templates and inheritance (and a bit of macros) to get rid of the large amount of duplicated code in the >> JVMFlag getters/setters. >> Stefan Karlsson and I have tried this several times already, but I think the current attempt probably has the least >> amount of hacks and most functionality: >> - Type safety is enforced up to the point of loading/storing `JVMFlag::_addr`, without any unchecked typecasts. >> - Runtime type checking is implemented by the `JVM_FLAG_TYPE(t)` macro (see jvmFlagAccess.hpp), by passing along an >> integer (`JVMFlag::TYPE_int`, etc). This is more efficient than previous attempts that passed along a function pointer >> (see http://cr.openjdk.java.net/~stefank/8081833/webrev.04/) >> - The old `JVMFlag::xxxAtPut` functions were undocumented. There are actually two groups that have different usage. I >> added documentation in jvmFlagAccess.hpp to explain this. >> - I got rid of the `JVMFlagEx` class and moved the code into `JVMFlag`. This is possible with C++11 which allows forward >> declaration of `enum JVMFlagsEnum : int;` >> - I changed `JVMFlag::_type` from a string into an enum. I am surprised this had lasted for over 20 years. >> - I also changed `JVMFlag` from a struct into a class and made some fields private. I probably will do more cleanup in a >> separate RFE. >> >> Please start with jvmFlagAccess.hpp, jvmFlagAccess.hpp and then globals_extension.hpp. >> >> Probably not everyone is in love with the `JVM_FLAG_TYPE(t)` macro. I'll be happy to try out alternatives. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Updated according to feedback from Gerard and Coleen Marked as reviewed by gziemski (Committer). Marked as reviewed by gziemski (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/163 From gziemski at openjdk.java.net Thu Sep 17 16:27:49 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 17 Sep 2020 16:27:49 GMT Subject: RFR: 8081833: Clean up JVMFlag getter/setter code [v2] In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 11:51:47 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated according to feedback from Gerard and Coleen > > The new names are nice. Looks great, thank you Ioi for cleaning this up! ------------- PR: https://git.openjdk.java.net/jdk/pull/163 From minqi at openjdk.java.net Thu Sep 17 16:59:52 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 17 Sep 2020 16:59:52 GMT Subject: Integrated: 8253262: Allocate in DumpRegion is not thread safe In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 04:52:29 GMT, Yumin Qi wrote: > At CDS dump, the symbols are allocated from _dump_region (DumpRegion) which is global, and not thread safe when > executed in JavaThread. Add a lock DumpRegoin_lock to guard symbol allocation from it. > Tests: tier1-4 This pull request has now been integrated. Changeset: 12dfe1c9 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/12dfe1c9 Stats: 12 lines in 3 files changed: 0 ins; 5 del; 7 mod 8253262: Allocate in DumpRegion is not thread safe Reviewed-by: ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/216 From github.com+2249648+JohnTortugo at openjdk.java.net Thu Sep 17 17:10:09 2020 From: github.com+2249648+JohnTortugo at openjdk.java.net (John Tortugo) Date: Thu, 17 Sep 2020 17:10:09 GMT Subject: RFR: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file [v5] In-Reply-To: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> References: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> Message-ID: > Relates to: https://bugs.openjdk.java.net/browse/JDK-8243066 > Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} > > Small change to move VM_INTRINSICS_DO out of vmSymbols.hpp into its own file. John Tortugo has updated the pull request incrementally with three additional commits since the last revision: - Adjust whitespaces and included header files. - Merge branch 'jdk-8243066' of https://github.com/JohnTortugo/jdk into jdk-8243066 - Add vmIntrinsics.cpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/160/files - new: https://git.openjdk.java.net/jdk/pull/160/files/e711a53e..def0a59f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=160&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=160&range=03-04 Stats: 21 lines in 2 files changed: 0 ins; 17 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/160.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/160/head:pull/160 PR: https://git.openjdk.java.net/jdk/pull/160 From iklam at openjdk.java.net Thu Sep 17 17:57:21 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 17 Sep 2020 17:57:21 GMT Subject: RFR: 8253271: vm_version_x86.hpp should not include globals_extension.hpp [v2] In-Reply-To: References: Message-ID: > [vm_version_x86.hpp](https://github.com/openjdk/jdk/blob/b87a1599674b8a73f489330decf051d1be9e9fba/src/hotspot/cpu/x86/vm_version_x86.hpp#L30) > is a popular header file (which in itself is a problem but I'll fix that in a separate RFE) and it unnecessarily > includes globals_extension.hpp. Removing this dependency reduces the number of cpp files that include > globals_extension.hpp from 814 to 67. > I need to fix cpp files that use macros like FLAG_SET_ERGO but forgot to include globals_extension.hpp. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: added more missing includes found by CI testing ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/217/files - new: https://git.openjdk.java.net/jdk/pull/217/files/a5a2f03e..ce1508af Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=217&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=217&range=00-01 Stats: 19 lines in 17 files changed: 17 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/217.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/217/head:pull/217 PR: https://git.openjdk.java.net/jdk/pull/217 From iklam at openjdk.java.net Thu Sep 17 18:07:50 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 17 Sep 2020 18:07:50 GMT Subject: RFR: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file [v3] In-Reply-To: <7XFYgoof_hvcuhJGHwwi3W8nv5W6D2mkDO8Lvd9kKy8=.c6505c5f-3123-4748-8f91-631e15d4dd08@github.com> References: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> <7XFYgoof_hvcuhJGHwwi3W8nv5W6D2mkDO8Lvd9kKy8=.c6505c5f-3123-4748-8f91-631e15d4dd08@github.com> Message-ID: On Wed, 16 Sep 2020 05:48:43 GMT, John Tortugo wrote: >> Relates to: https://bugs.openjdk.java.net/browse/JDK-8243066 >> Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} >> >> Small change to move VM_INTRINSICS_DO out of vmSymbols.hpp into its own file. > > John Tortugo has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'jdk-8243066' of https://github.com/JohnTortugo/jdk into jdk-8243066 > - Add vmIntrinsics.cpp. Fix commit author. LGTM! src/hotspot/share/classfile/vmIntrinsics.hpp line 879: > 877: /*end*/ > 878: > 879: #endif // SHARE_CLASSFILE_VMINTRINSICS_HPP Please add a new line at the end of this file. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/160 From github.com+70893615+jasontatton-aws at openjdk.java.net Thu Sep 17 18:22:35 2020 From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton) Date: Thu, 17 Sep 2020 18:22:35 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> Message-ID: <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> On Fri, 11 Sep 2020 23:04:01 GMT, Jason Tatton wrote: >> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for >> x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it >> I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as >> code for C2. Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and >> java/lang/StringLatin1.java https://bugs.openjdk.java.net/browse/JDK-8173585 >> >> Details of testing: >> ============ >> I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note >> that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the >> input String. Hence the test has been designed to cover all these cases. In summary they are: >> - A ?short? string of < 16 characters. >> - A SIMD String of 16 ? 31 characters. >> - A AVX2 SIMD String of 32 characters+. >> >> Hardware used for testing: >> ----------------------------- >> >> - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support). >> - AWS Graviton 2 (ARM 64 processor). >> >> I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64. >> >> Possible future enhancements: >> ==================== >> For the x86 implementation there may be two further improvements we can make in order to improve performance of both >> the StringUTF16 and StringLatin1 indexOf(char) intrinsics: >> 1. Make use of AVX-512 instructions. >> 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD >> instructions instead of a loop. >> Benchmark results: >> ============ >> **Without** the new StringLatin1 indexOf(char) intrinsic: >> >> | Benchmark | Mode | Cnt | Score | Error | Units | >> | ------------- | ------------- |------------- |------------- |------------- |------------- | >> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op | >> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933 | ns/op | >> >> >> **With** the new StringLatin1 indexOf(char) intrinsic: >> >> | Benchmark | Mode | Cnt | Score | Error | Units | >> | ------------- | ------------- |------------- |------------- |------------- |------------- | >> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716 | ns/op | >> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306 | ns/op | >> >> >> The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 >> indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when >> running on ARM. > > Hi Andrew, > > The current indexOf char intrinsics for StringUTF16 and the new one here for StringLatin1 both use the AVX2 ? i.e. 256 > bit instructions, these are also affected by the frequency scaling which affects the AVX-512 instructions you pointed > out. Of course in a world where all the work taking place is AVX instructions this wouldn?t be an issue but in mixed > mode execution this is a problem. However, the compiler does have knowledge of the capability of the CPU upon which > it?s optimizing code for and is able to decide whether to use AVX instructions if they are supported by the CPU AND if > it wouldn?t be detrimental for performance. In fact, there is a flag which one can use to interact with > this: -XX:UseAVX=version. This of course made testing this patch an interesting experience as the AVX2 instructions > were not enabled on the Xeon processors which I had access to at AWS, but in the end I was able to use an i7 on my > corporate macbook to validate the code. From: mlbridge[bot] Sent: 11 September 2020 17:01 > To: openjdk/jdk Cc: Tatton, Jason ; Mention > Subject: Re: [openjdk/jdk] 8173585: Intrinsify StringLatin1.indexOf(char) (#71) > > > Mailing list message from Andrew Haley on hotspot-dev: > > On 11/09/2020 11:23, Jason Tatton wrote: > > For the x86 implementation there may be two further improvements we > can make in order to improve performance of both the StringUTF16 and > StringLatin1 indexOf(char) intrinsics: > > 1. Make use of AVX-512 instructions. > > Is this really a good idea? > > When the processor detects Intel AVX instructions, additional > voltage is applied to the core. With the additional voltage applied, > the processor could run hotter, requiring the operating frequency to > be reduced to maintain operations within the TDP limits. The higher > voltage is maintained for 1 millisecond after the last Intel AVX > instruction completes, and then the voltage returns to the nominal > TDP voltage level. > > https://computing.llnl.gov/tutorials/linux_clusters/intelAVXperformanceWhitePaper.pdf > > So, if StringLatin1.indexOf(char) executes enough to make a difference > to any real-world program, the effect may well be to slow down the clock > for all of the code that does not use AVX. > > 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD > instructions instead of a loop. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > ? > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or > unsubscribe. Hi everyone, This patch is just missing a couple of reviewers... Please can someone step forward? I think it's a fairly straightforward change. -Jason ------------- PR: https://git.openjdk.java.net/jdk/pull/71 From github.com+2249648+JohnTortugo at openjdk.java.net Thu Sep 17 18:28:08 2020 From: github.com+2249648+JohnTortugo at openjdk.java.net (John Tortugo) Date: Thu, 17 Sep 2020 18:28:08 GMT Subject: RFR: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file [v6] In-Reply-To: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> References: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> Message-ID: > Relates to: https://bugs.openjdk.java.net/browse/JDK-8243066 > Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} > > Small change to move VM_INTRINSICS_DO out of vmSymbols.hpp into its own file. John Tortugo has updated the pull request incrementally with three additional commits since the last revision: - Merge branch 'jdk-8243066' of https://github.com/JohnTortugo/jdk into jdk-8243066 - Adjust whitespaces and included header files. - Add vmIntrinsics.cpp. Fix commit author. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/160/files - new: https://git.openjdk.java.net/jdk/pull/160/files/def0a59f..33bf0c3f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=160&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=160&range=04-05 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/160.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/160/head:pull/160 PR: https://git.openjdk.java.net/jdk/pull/160 From github.com+2249648+JohnTortugo at openjdk.java.net Thu Sep 17 18:28:11 2020 From: github.com+2249648+JohnTortugo at openjdk.java.net (John Tortugo) Date: Thu, 17 Sep 2020 18:28:11 GMT Subject: RFR: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file [v4] In-Reply-To: References: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> Message-ID: On Wed, 16 Sep 2020 18:27:53 GMT, Coleen Phillimore wrote: >> John Tortugo has refreshed the contents of this pull request, and previous commits have been removed. The incremental >> views will show differences compared to the previous content of the PR. > > src/hotspot/share/classfile/vmIntrinsics.cpp line 32: > >> 30: #include "compiler/compilerDirectives.hpp" >> 31: #include "memory/allocation.inline.hpp" >> 32: #include "memory/oopFactory.hpp" > > Can you make sure it needs all of these header files? I don't see a direct reference to SymbolTable:: or OopFactory. Done. Removed a bunch of them! ------------- PR: https://git.openjdk.java.net/jdk/pull/160 From github.com+2249648+JohnTortugo at openjdk.java.net Thu Sep 17 18:28:14 2020 From: github.com+2249648+JohnTortugo at openjdk.java.net (John Tortugo) Date: Thu, 17 Sep 2020 18:28:14 GMT Subject: RFR: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file [v3] In-Reply-To: References: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> <7XFYgoof_hvcuhJGHwwi3W8nv5W6D2mkDO8Lvd9kKy8=.c6505c5f-3123-4748-8f91-631e15d4dd08@github.com> Message-ID: On Wed, 16 Sep 2020 05:49:03 GMT, Ioi Lam wrote: >> John Tortugo has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge branch 'jdk-8243066' of https://github.com/JohnTortugo/jdk into jdk-8243066 >> - Add vmIntrinsics.cpp. Fix commit author. > > src/hotspot/share/classfile/vmIntrinsics.hpp line 879: > >> 877: /*end*/ >> 878: >> 879: #endif // SHARE_CLASSFILE_VMINTRINSICS_HPP > > Please add a new line at the end of this file. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/160 From github.com+2249648+JohnTortugo at openjdk.java.net Thu Sep 17 18:30:15 2020 From: github.com+2249648+JohnTortugo at openjdk.java.net (John Tortugo) Date: Thu, 17 Sep 2020 18:30:15 GMT Subject: RFR: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file [v3] In-Reply-To: References: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> <7XFYgoof_hvcuhJGHwwi3W8nv5W6D2mkDO8Lvd9kKy8=.c6505c5f-3123-4748-8f91-631e15d4dd08@github.com> Message-ID: On Thu, 17 Sep 2020 18:05:15 GMT, Ioi Lam wrote: >> John Tortugo has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge branch 'jdk-8243066' of https://github.com/JohnTortugo/jdk into jdk-8243066 >> - Add vmIntrinsics.cpp. Fix commit author. > > LGTM! @iklam @dholmes-ora - Sorry about the confusion (force push) - I was actually trying to fix the the author name of one of my previous commit (a PR check was complaining about it). Spaces / Copyright / List of include headers are not fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/160 From github.com+2249648+JohnTortugo at openjdk.java.net Thu Sep 17 18:30:15 2020 From: github.com+2249648+JohnTortugo at openjdk.java.net (John Tortugo) Date: Thu, 17 Sep 2020 18:30:15 GMT Subject: Withdrawn: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file In-Reply-To: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> References: <861vSW_ZarHtJYrRivGu8EBgqVebOBxqBuz0qeKCtMw=.ae19c170-73a5-4c45-9a56-e58e1a922ce7@github.com> Message-ID: On Mon, 14 Sep 2020 23:00:06 GMT, John Tortugo wrote: > Relates to: https://bugs.openjdk.java.net/browse/JDK-8243066 > Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} > > Small change to move VM_INTRINSICS_DO out of vmSymbols.hpp into its own file. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/160 From github.com+2249648+JohnTortugo at openjdk.java.net Thu Sep 17 18:55:04 2020 From: github.com+2249648+JohnTortugo at openjdk.java.net (John Tortugo) Date: Thu, 17 Sep 2020 18:55:04 GMT Subject: RFR: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file Message-ID: Relates to: https://bugs.openjdk.java.net/browse/JDK-8243066 Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} Move vmIntrinsics code out of vmSymbols.[c|h]pp into its own files. I closed a [previous PR](https://github.com/openjdk/jdk/pull/160) I had for this same work item because I accidentally pushed commits to the same branch using different author names and the PR checker was complaining about that - I didn't want to force push (amend) commits on the previous branch anymore. ------------- Commit messages: - Refactor vmIntrinsics out of vmSymbols Changes: https://git.openjdk.java.net/jdk/pull/226/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=226&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8243066 Stats: 3390 lines in 4 files changed: 1725 ins; 1665 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/226.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/226/head:pull/226 PR: https://git.openjdk.java.net/jdk/pull/226 From pchilanomate at openjdk.java.net Thu Sep 17 19:00:24 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 17 Sep 2020 19:00:24 GMT Subject: RFR: 8238761: Asynchronous handshakes [v2] In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 12:07:15 GMT, Robbin Ehn wrote: >> This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes >> are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) >> Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an >> arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a >> singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first >> pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first >> pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake >> operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything >> except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed >> filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake >> operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there >> is now only one method to call when handshaking one thread. Some comments about the changes: >> - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake >> all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much >> worse then this. >> >> - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that >> thread. >> >> - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a >> handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. >> >> - Added WB testing method. >> >> - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. >> >> - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. >> >> - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a >> safepoint and half of them after, in many handshake all operations. >> >> - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. >> >> - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the >> moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. >> >> - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. >> >> - Added filtered queue and gtest for it. >> >> Passes multiple t1-8 runs. >> Been through some pre-reviwing. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixed double checks > Added NSV > ProcessResult to enum > Fixed logging > Moved _active_handshaker to private Changes look good, thanks for fixing! I added some comments on the changes. src/hotspot/share/runtime/handshake.cpp line 464: > 462: > 463: const char* executioner_name(Thread* current_thread, Thread* handshakee, bool current_is_requester) { > 464: if (current_thread == handshakee) return "self(JavaThread)"; I think we can remove this line since executioner_name() is only called by the handshaker. src/hotspot/share/runtime/handshake.cpp line 508: > 506: assert(op->_target == NULL || _handshakee == op->_target, "Wrong thread"); > 507: log_trace(handshake)("Processing handshake " INTPTR_FORMAT " by %s", p2i(op), > 508: executioner_name(current_thread, _handshakee, op == match_op)); With the above change we could even avoid factoring the code into executioner_name() and just do: log_trace(handshake)("Processing handshake " INTPTR_FORMAT " by %s%s", p2i(op), op == match_op ? "handshaker" : "cooperative", current_thread->is_VM_thread() ? "(VM Thread)" : "(JavaThread)"); src/hotspot/share/prims/jvmtiEnvBase.cpp line 908: > 906: #endif > 907: Thread* current_thread = Thread::current(); > 908: assert(current_thread == java_thread || One extra check here. src/hotspot/share/prims/jvmtiEnvBase.cpp line 1164: > 1162: #ifdef ASSERT > 1163: Thread *current_thread = Thread::current(); > 1164: assert(current_thread == thr || One extra check here. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From iklam at openjdk.java.net Thu Sep 17 19:01:06 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 17 Sep 2020 19:01:06 GMT Subject: RFR: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 18:48:14 GMT, John Tortugo wrote: > Relates to: https://bugs.openjdk.java.net/browse/JDK-8243066 > Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} > > Move vmIntrinsics code out of vmSymbols.[c|h]pp into its own files. > > I closed a [previous PR](https://github.com/openjdk/jdk/pull/160) I had for this same work item because I accidentally > pushed commits to the same branch using different author names and the PR checker was complaining about that - I didn't > want to force push (amend) commits on the previous branch anymore. Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/226 From vlivanov at openjdk.java.net Thu Sep 17 19:14:13 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 17 Sep 2020 19:14:13 GMT Subject: RFR: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 18:48:14 GMT, John Tortugo wrote: > Relates to: https://bugs.openjdk.java.net/browse/JDK-8243066 > Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} > > Move vmIntrinsics code out of vmSymbols.[c|h]pp into its own files. > > I closed a [previous PR](https://github.com/openjdk/jdk/pull/160) I had for this same work item because I accidentally > pushed commits to the same branch using different author names and the PR checker was complaining about that - I didn't > want to force push (amend) commits on the previous branch anymore. Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/226 From rehn at openjdk.java.net Thu Sep 17 19:28:30 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 17 Sep 2020 19:28:30 GMT Subject: RFR: 8238761: Asynchronous handshakes [v2] In-Reply-To: References: Message-ID: <1NYgXmzZSEe4Bjew1P1JvHP-gtInrEU4FN6LzVPDpiw=.6b53dae2-2cbb-4262-ab7f-90d9f03dfa48@github.com> On Thu, 17 Sep 2020 18:28:20 GMT, Patricio Chilano Mateo wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed double checks >> Added NSV >> ProcessResult to enum >> Fixed logging >> Moved _active_handshaker to private > > src/hotspot/share/runtime/handshake.cpp line 464: > >> 462: >> 463: const char* executioner_name(Thread* current_thread, Thread* handshakee, bool current_is_requester) { >> 464: if (current_thread == handshakee) return "self(JavaThread)"; > > I think we can remove this line since executioner_name() is only called by the handshaker. Yes, fixing. > src/hotspot/share/runtime/handshake.cpp line 508: > >> 506: assert(op->_target == NULL || _handshakee == op->_target, "Wrong thread"); >> 507: log_trace(handshake)("Processing handshake " INTPTR_FORMAT " by %s", p2i(op), >> 508: executioner_name(current_thread, _handshakee, op == match_op)); > > With the above change we could even avoid factoring the code into executioner_name() and just do: > log_trace(handshake)("Processing handshake " INTPTR_FORMAT " by %s%s", p2i(op), > op == match_op ? "handshaker" : "cooperative", > current_thread->is_VM_thread() ? "(VM Thread)" : "(JavaThread)"); I added a second log line where I use that function also: log_trace(handshake)("Thread %s(" INTPTR_FORMAT ") executed %d ops for JavaThread: " INTPTR_FORMAT " %s target op: " INTPTR_FORMAT, executioner_name(current_thread, _handshakee, pr_ret == HandshakeState::_succeed), p2i(current_thread), executed, p2i(_handshakee), pr_ret == HandshakeState::_succeed ? "including" : "excluding", p2i(match_op)); > src/hotspot/share/prims/jvmtiEnvBase.cpp line 908: > >> 906: #endif >> 907: Thread* current_thread = Thread::current(); >> 908: assert(current_thread == java_thread || > > One extra check here. Fixing > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1164: > >> 1162: #ifdef ASSERT >> 1163: Thread *current_thread = Thread::current(); >> 1164: assert(current_thread == thr || > > One extra check here. Fixing ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Thu Sep 17 19:51:25 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 17 Sep 2020 19:51:25 GMT Subject: RFR: 8238761: Asynchronous handshakes [v2] In-Reply-To: <1NYgXmzZSEe4Bjew1P1JvHP-gtInrEU4FN6LzVPDpiw=.6b53dae2-2cbb-4262-ab7f-90d9f03dfa48@github.com> References: <1NYgXmzZSEe4Bjew1P1JvHP-gtInrEU4FN6LzVPDpiw=.6b53dae2-2cbb-4262-ab7f-90d9f03dfa48@github.com> Message-ID: On Thu, 17 Sep 2020 19:23:09 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/handshake.cpp line 508: >> >>> 506: assert(op->_target == NULL || _handshakee == op->_target, "Wrong thread"); >>> 507: log_trace(handshake)("Processing handshake " INTPTR_FORMAT " by %s", p2i(op), >>> 508: executioner_name(current_thread, _handshakee, op == match_op)); >> >> With the above change we could even avoid factoring the code into executioner_name() and just do: >> log_trace(handshake)("Processing handshake " INTPTR_FORMAT " by %s%s", p2i(op), >> op == match_op ? "handshaker" : "cooperative", >> current_thread->is_VM_thread() ? "(VM Thread)" : "(JavaThread)"); > > I added a second log line where I use that function also: > log_trace(handshake)("Thread %s(" INTPTR_FORMAT ") executed %d ops for JavaThread: " INTPTR_FORMAT " %s target op: " > INTPTR_FORMAT, > executioner_name(current_thread, _handshakee, pr_ret == HandshakeState::_succeed), > p2i(current_thread), executed, p2i(_handshakee), > pr_ret == HandshakeState::_succeed ? "including" : "excluding", p2i(match_op)); Push commit 469f8fc, please have a look. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Thu Sep 17 19:51:24 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 17 Sep 2020 19:51:24 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: > This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes > are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) > Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an > arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a > singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first > pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first > pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake > operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything > except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed > filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake > operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there > is now only one method to call when handshaking one thread. Some comments about the changes: > - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake > all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much > worse then this. > > - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that > thread. > > - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a > handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. > > - Added WB testing method. > > - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. > > - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. > > - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a > safepoint and half of them after, in many handshake all operations. > > - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. > > - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the > moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. > > - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. > > - Added filtered queue and gtest for it. > > Passes multiple t1-8 runs. > Been through some pre-reviwing. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Removed double check, fix comment, removed not needed function, updated logs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/151/files - new: https://git.openjdk.java.net/jdk/pull/151/files/86b83d05..469f8fc8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=151&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=151&range=01-02 Stats: 22 lines in 2 files changed: 1 ins; 12 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/151/head:pull/151 PR: https://git.openjdk.java.net/jdk/pull/151 From iklam at openjdk.java.net Thu Sep 17 19:59:11 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 17 Sep 2020 19:59:11 GMT Subject: RFR: 8253271: vm_version_x86.hpp should not include globals_extension.hpp [v2] In-Reply-To: References: Message-ID: <9656Nspmj41pw2RoSYiuIvZMD4Oa7uDvRA_1BfbVffw=.f5ba8275-315a-46d7-905b-bdd4f2d425e7@github.com> On Thu, 17 Sep 2020 06:28:47 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> added more missing includes found by CI testing > > Looks good - and trivial assuming all builds are good. [ce1508a](https://github.com/openjdk/jdk/pull/217/commits/ce1508afeb9089bfe5e276eb06de34b9bfe0459a) passed tiers1/2 in our CI pipeline. I also tested with a local build with shenandoah enabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/217 From rehn at openjdk.java.net Thu Sep 17 20:34:19 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 17 Sep 2020 20:34:19 GMT Subject: RFR: 8212107: VMThread issues and cleanup Message-ID: We simplify the vmThread by removing the queue and refactor the the main loop. This solves the issues listed: - It can create an extra safepoint directly after a safepoint. - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. - The exposure of the vm operation is dangerous if it's a handshake. - The code is a hornets nest with the repetition of checks and branches Passes t1-8, and a benchmark run. If you want a smaller diff the commits contains the incremental progress and each commit passed t1. ------------- Commit messages: - Fixed some indent misses - Fixed ws - Added assert - Restructured and simplified - Removed used linking in VM_Operation - Removed ticket and use only one Monitor - Removed queue - Basic simplifications, removed prio Changes: https://git.openjdk.java.net/jdk/pull/228/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=228&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8212107 Stats: 431 lines in 7 files changed: 111 ins; 229 del; 91 mod Patch: https://git.openjdk.java.net/jdk/pull/228.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/228/head:pull/228 PR: https://git.openjdk.java.net/jdk/pull/228 From dtitov at openjdk.java.net Thu Sep 17 20:57:24 2020 From: dtitov at openjdk.java.net (Daniil Titov) Date: Thu, 17 Sep 2020 20:57:24 GMT Subject: RFR: 8241390: 'Deadlock' with VM_RedefineClasses::lock_classes() [v2] In-Reply-To: References: Message-ID: <7IoV1woJroikqiVrV4xaXJ-UmQv9WkawKilI_ndiVZA=.0eb45818-b9f0-44fd-a11d-4effc7a5a666@github.com> > The change fixes a 'deadlock' situation in VM_RedefineClasses::lock_classes() when the current thread is in the middle > of redefining the same class. The change is based on the fix [1] suggested in the Jira issue [2] comment. > [1] http://cr.openjdk.java.net/~jiangli/8241390/webrev.00/ > [2] https://bugs.openjdk.java.net/browse/JDK-8241390 > > Testing: :jdk_instrument, tier1-tier3, and tier5 tests pass. Daniil Titov has updated the pull request incrementally with one additional commit since the last revision: Changed test to not use shell scripts Additional changes: - Replaced 'cls' identifier with 'redef_classes' - Added a comment that the same class can be pushed to the list multiple times. Testing: tier1-tier3 tests pass. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/190/files - new: https://git.openjdk.java.net/jdk/pull/190/files/6e6b1b81..3502f018 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=190&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=190&range=00-01 Stats: 275 lines in 6 files changed: 119 ins; 142 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/190/head:pull/190 PR: https://git.openjdk.java.net/jdk/pull/190 From github.com+2249648+JohnTortugo at openjdk.java.net Thu Sep 17 21:23:43 2020 From: github.com+2249648+JohnTortugo at openjdk.java.net (John Tortugo) Date: Thu, 17 Sep 2020 21:23:43 GMT Subject: Integrated: 8243066 - Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 18:48:14 GMT, John Tortugo wrote: > Relates to: https://bugs.openjdk.java.net/browse/JDK-8243066 > Tested on: x86_64 {windows, linux, os x} x {jdk-tier1-part1..3, hotspot-tier1-gc} > > Move vmIntrinsics code out of vmSymbols.[c|h]pp into its own files. > > I closed a [previous PR](https://github.com/openjdk/jdk/pull/160) I had for this same work item because I accidentally > pushed commits to the same branch using different author names and the PR checker was complaining about that - I didn't > want to force push (amend) commits on the previous branch anymore. This pull request has now been integrated. Changeset: 1e396499 Author: John Tortugo Committer: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/1e396499 Stats: 3390 lines in 4 files changed: 1665 ins; 1725 del; 0 mod 8243066: Move VM_INTRINSICS_DO into its own vmIntrinsics.hpp file Reviewed-by: iklam, vlivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/226 From iklam at openjdk.java.net Thu Sep 17 21:35:26 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 17 Sep 2020 21:35:26 GMT Subject: RFR: 8253271: vm_version_x86.hpp should not include globals_extension.hpp [v3] In-Reply-To: References: Message-ID: > [vm_version_x86.hpp](https://github.com/openjdk/jdk/blob/b87a1599674b8a73f489330decf051d1be9e9fba/src/hotspot/cpu/x86/vm_version_x86.hpp#L30) > is a popular header file (which in itself is a problem but I'll fix that in a separate RFE) and it unnecessarily > includes globals_extension.hpp. Removing this dependency reduces the number of cpp files that include > globals_extension.hpp from 814 to 67. > I need to fix cpp files that use macros like FLAG_SET_ERGO but forgot to include globals_extension.hpp. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into 8253271-remove-globals-extensions-from-vm-version-x86-hpp - added more missing includes found by CI testing - 8253271: vm_version_x86.hpp should not include globals_extension.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/217/files - new: https://git.openjdk.java.net/jdk/pull/217/files/ce1508af..28e894f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=217&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=217&range=01-02 Stats: 288 lines in 32 files changed: 131 ins; 29 del; 128 mod Patch: https://git.openjdk.java.net/jdk/pull/217.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/217/head:pull/217 PR: https://git.openjdk.java.net/jdk/pull/217 From iklam at openjdk.java.net Thu Sep 17 21:35:28 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 17 Sep 2020 21:35:28 GMT Subject: Integrated: 8253271: vm_version_x86.hpp should not include globals_extension.hpp In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 05:05:06 GMT, Ioi Lam wrote: > [vm_version_x86.hpp](https://github.com/openjdk/jdk/blob/b87a1599674b8a73f489330decf051d1be9e9fba/src/hotspot/cpu/x86/vm_version_x86.hpp#L30) > is a popular header file (which in itself is a problem but I'll fix that in a separate RFE) and it unnecessarily > includes globals_extension.hpp. Removing this dependency reduces the number of cpp files that include > globals_extension.hpp from 814 to 67. > I need to fix cpp files that use macros like FLAG_SET_ERGO but forgot to include globals_extension.hpp. This pull request has now been integrated. Changeset: 0a1dc50f Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/0a1dc50f Stats: 48 lines in 43 files changed: 3 ins; 41 del; 4 mod 8253271: vm_version_x86.hpp should not include globals_extension.hpp Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/217 From sspitsyn at openjdk.java.net Thu Sep 17 23:52:44 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 17 Sep 2020 23:52:44 GMT Subject: RFR: 8241390: 'Deadlock' with VM_RedefineClasses::lock_classes() [v2] In-Reply-To: <7IoV1woJroikqiVrV4xaXJ-UmQv9WkawKilI_ndiVZA=.0eb45818-b9f0-44fd-a11d-4effc7a5a666@github.com> References: <7IoV1woJroikqiVrV4xaXJ-UmQv9WkawKilI_ndiVZA=.0eb45818-b9f0-44fd-a11d-4effc7a5a666@github.com> Message-ID: On Thu, 17 Sep 2020 20:57:24 GMT, Daniil Titov wrote: >> The change fixes a 'deadlock' situation in VM_RedefineClasses::lock_classes() when the current thread is in the middle >> of redefining the same class. The change is based on the fix [1] suggested in the Jira issue [2] comment. >> [1] http://cr.openjdk.java.net/~jiangli/8241390/webrev.00/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8241390 >> >> Testing: :jdk_instrument, tier1-tier3, and tier5 tests pass. > > Daniil Titov has updated the pull request incrementally with one additional commit since the last revision: > > Changed test to not use shell scripts > > Additional changes: > - Replaced 'cls' identifier with 'redef_classes' > - Added a comment that the same class can be pushed to the list multiple times. > > Testing: tier1-tier3 tests pass. The following test @summary needs some tweaks: * @summary Test recursively redefines the same class. The test hangs if * a deadlock happens. Please, replace: redefines => retransforms. Also, it'd be nice to align "a deadlock happens" with the "Test recursively ...". ------------- Changes requested by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/190 From dtitov at openjdk.java.net Fri Sep 18 01:02:24 2020 From: dtitov at openjdk.java.net (Daniil Titov) Date: Fri, 18 Sep 2020 01:02:24 GMT Subject: RFR: 8241390: 'Deadlock' with VM_RedefineClasses::lock_classes() [v3] In-Reply-To: References: Message-ID: > The change fixes a 'deadlock' situation in VM_RedefineClasses::lock_classes() when the current thread is in the middle > of redefining the same class. The change is based on the fix [1] suggested in the Jira issue [2] comment. > [1] http://cr.openjdk.java.net/~jiangli/8241390/webrev.00/ > [2] https://bugs.openjdk.java.net/browse/JDK-8241390 > > Testing: :jdk_instrument, tier1-tier3, and tier5 tests pass. Daniil Titov has updated the pull request incrementally with one additional commit since the last revision: Corrected test summary ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/190/files - new: https://git.openjdk.java.net/jdk/pull/190/files/3502f018..a2609929 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=190&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=190&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/190.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/190/head:pull/190 PR: https://git.openjdk.java.net/jdk/pull/190 From smarks at openjdk.java.net Fri Sep 18 02:50:45 2020 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 18 Sep 2020 02:50:45 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: On Fri, 11 Sep 2020 15:17:58 GMT, Bradford Wetmore wrote: >> Ok, sorry for the distraction. > > Our local Santuario maintainer says: > > In general, changes to Apache Santuario should also be made at Apache so we stay in sync. Hi @doom369, I hope we didn't end up wasting too much of your time with this. I wanted to respond to a comment you made earlier in this PR, > I have in mind dozens of improvements all over the code like this one. It's hard to see, but as you discovered, the JDK has different groups of people maintaining different areas, and sometimes there are hidden constraints on those different areas, for example, to avoid divergence with upstream source bases. And as you discovered, sometimes those source bases might need to maintain compatibility with an older JDK ... so we don't want to update this code even though it's IN the JDK. Those kind of constraints generally don't apply to code in the java.base module, since there's nothing upstream of it, and by definition it cannot depend on anything outside the JDK. Generally -- though there are exceptions -- we're more receptive to keeping stuff in java.base (and sometimes related modules close to the core) on the latest and greatest stuff. There are some constraints, however. There are some things we can't use too early during initialization of the JDK, such as lambdas. Also, there is some code lurking around that is sometimes executed by the boot JDK, which is typically one release behind. (This is definitely the case for tools like javac, but I think it might also apply to some things in base.) Anyway, if you'd like to pursue some of these improvements, drop a note to core-libs-dev at openjdk and we can talk about it. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From shade at openjdk.java.net Fri Sep 18 05:36:57 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 18 Sep 2020 05:36:57 GMT Subject: RFR: 8212107: VMThread issues and cleanup In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 19:58:02 GMT, Robbin Ehn wrote: > We simplify the vmThread by removing the queue and refactor the the main loop. > This solves the issues listed: > - It can create an extra safepoint directly after a safepoint. > - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. > - The exposure of the vm operation is dangerous if it's a handshake. > - The code is a hornets nest with the repetition of checks and branches > > Passes t1-8, and a benchmark run. > > If you want a smaller diff the commits contains the incremental progress and each commit passed t1. I find juggling the `_next_vm_operation` a bit confusing at the first glance, but that seems superficially okay. src/hotspot/share/runtime/mutexLocker.cpp line 68: > 66: Mutex* TouchedMethodLog_lock = NULL; > 67: Mutex* RetData_lock = NULL; > 68: Monitor* VMOperation_lock = NULL; Indenting is a bit off here? src/hotspot/share/runtime/mutexLocker.hpp line 61: > 59: extern Mutex* TouchedMethodLog_lock; // a lock on allocation of LogExecutedMethods info > 60: extern Mutex* RetData_lock; // a lock on installation of RetData inside method data > 61: extern Monitor* VMOperation_lock; // a lock on queue of vm_operations waiting to execute Indenting is a bit off? src/hotspot/share/runtime/thread.hpp line 625: > 623: > 624: // For tracking the heavyweight monitor the thread is pending on. > 625: ObjectMonitor* current_pending_monitor() { If this goes, then the declaration of `_vm_operation_started_count` can also go? src/hotspot/share/runtime/thread.hpp line 627: > 625: ObjectMonitor* current_pending_monitor() { > 626: return _current_pending_monitor; > 627: } Ditto for `_vm_operation_completed_count`? src/hotspot/share/runtime/vmThread.cpp line 222: > 220: void VMThread::wait_for_vm_thread_exit() { > 221: assert(Thread::current()->is_Java_thread(), "Should be a JavaThread"); > 222: assert(((JavaThread*)Thread::current())->is_terminated(), "Should be terminated"); Looks like just `assert(JavaThread::current()->is_terminated(), "Should be terminated")`. src/hotspot/share/runtime/vmThread.cpp line 305: > 303: // we emit a handshake if it's been more than a second since last. > 304: jlong deadline_ms = GuaranteedSafepointInterval != 0 ? GuaranteedSafepointInterval : 1000; > 305: deadline_ms += last_halot_ms; It would seem more straight-forward to write it like this, to highlight the "base" `last_halot_ms` and the "addition" `interval`: // ... jlong interval = (GuaranteedSafepointInterval != 0 ? GuaranteedSafepointInterval : 1000); jlong deadline_ms = last_halot_ms + interval; if (now_ms > deadline_ms) { last_halot_ms = now_ms; return true; } return false; ...but that's just a personal preference. src/hotspot/share/runtime/vmThread.cpp line 313: > 311: } > 312: > 313: void VMThread::cleanup_safepoint_alot() { This handles `GuaranteedSafepointInterval` periodic op as well, so `cleanup_safepoint_alot` seems misnomer. src/hotspot/share/runtime/vmThread.hpp line 129: > 127: // VM_Operation support > 128: static VM_Operation* _cur_vm_operation; // Current VM operation > 129: static VM_Operation* _next_vm_operation; Comment to match `// Current VM operation` above? src/hotspot/share/runtime/vmThread.cpp line 344: > 342: } > 343: > 344: void VMThread::until_executed(VM_Operation* op) { ...`until_executed`? Feels like missing a verb, e.g. `wait_until_executed`? src/hotspot/share/runtime/vmThread.cpp line 355: > 353: } > 354: ml.notify_all(); > 355: ml.wait(); It is really odd to see back-to-back `notify_all` and `wait`. Would that mean two threads sitting in this loop would just wake one another continuously? src/hotspot/share/runtime/vmThread.cpp line 392: > 390: > 391: HandleMark hm(VMThread::vm_thread()); > 392: EventMark em("Executing %s VM operation: %s", prev_vm_operation ? "nested" : "", op->name()); Check `prev_vm_operation != NULL` explicitly? src/hotspot/share/runtime/vmThread.cpp line 427: > 425: > 426: // Notify previous op done > 427: mu_queue.notify(); So, `notify`, not `notifyAll` here? We sure we want to bet who -- of all current waiters -- gets the notification? src/hotspot/share/runtime/vmThread.cpp line 470: > 468: while (true) { > 469: wait_for_operation(); > 470: if (!should_terminate()) { This is a trailing block. So it might just be `do { ... } while (!should_terminate())`? src/hotspot/share/runtime/vmThread.hpp line 103: > 101: // Returns the current vm operation if any. > 102: static VM_Operation* vm_operation() { > 103: assert(Thread::current()->is_VM_thread(), "Must be);"); Typos in `Must be);`. ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/228 From shade at openjdk.java.net Fri Sep 18 05:43:23 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 18 Sep 2020 05:43:23 GMT Subject: RFR: 8253278: Refactor/cleanup oopDesc::*_klass_addr In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 11:47:19 GMT, Coleen Phillimore wrote: >> Right now this one has the comment mentioning CMS: >> >> Klass** oopDesc::klass_addr(HeapWord* mem) { >> // Only used internally and with CMS and will not work with >> // UseCompressedOops >> assert(!UseCompressedClassPointers, "only supported with uncompressed klass pointers"); >> ByteSize offset = byte_offset_of(oopDesc, _metadata._klass); >> return (Klass**) (((char*)mem) + in_bytes(offset)); >> } >> >> But that is not true, it is used on the generic paths. >> >> The rest are the snowballing changes: >> - in `load_klass_raw` and `set_klass`: `compressed_klass_addr` and `klass_addr` are used where the direct access to >> `_metadata` can be done, avoiding these methods >> - the leftover use is in `set_klass_release`, where we can simplify things by inlining `_addr` methods directly >> - `CHECK_SET_KLASS` macro seems too much ceremony for just two asserts >> >> Note that new code uses the universal `klass_offset_in_bytes`, that is technically `offset_of(..., _metadata._klass)`. >> This is different from the previous code, but it matches what other code is doing -- it trusts that both >> `_metadata._klass` and `_metadata._compressed_klass` are on the same offsets. I thought to add a very paranoid assert >> there, but decided not to. Testing: Linux x86_64 fastdebug tier1 > > Nice cleanup!! I'm happy to see klass_addr go. It took me a while to reconcile that klass_offset_in_bytes points to > _metadata._compressed_klass but I believe it's correct, and used everywhere else so it better be. It is a sensitive code, I'd like another reviewer. ------------- PR: https://git.openjdk.java.net/jdk/pull/221 From stefank at openjdk.java.net Fri Sep 18 05:52:39 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 18 Sep 2020 05:52:39 GMT Subject: RFR: 8253278: Refactor/cleanup oopDesc::*_klass_addr In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 08:37:26 GMT, Aleksey Shipilev wrote: > Right now this one has the comment mentioning CMS: > > Klass** oopDesc::klass_addr(HeapWord* mem) { > // Only used internally and with CMS and will not work with > // UseCompressedOops > assert(!UseCompressedClassPointers, "only supported with uncompressed klass pointers"); > ByteSize offset = byte_offset_of(oopDesc, _metadata._klass); > return (Klass**) (((char*)mem) + in_bytes(offset)); > } > > But that is not true, it is used on the generic paths. > > The rest are the snowballing changes: > - in `load_klass_raw` and `set_klass`: `compressed_klass_addr` and `klass_addr` are used where the direct access to > `_metadata` can be done, avoiding these methods > - the leftover use is in `set_klass_release`, where we can simplify things by inlining `_addr` methods directly > - `CHECK_SET_KLASS` macro seems too much ceremony for just two asserts > > Note that new code uses the universal `klass_offset_in_bytes`, that is technically `offset_of(..., _metadata._klass)`. > This is different from the previous code, but it matches what other code is doing -- it trusts that both > `_metadata._klass` and `_metadata._compressed_klass` are on the same offsets. I thought to add a very paranoid assert > there, but decided not to. Testing: Linux x86_64 fastdebug tier1 Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/221 From stefank at openjdk.java.net Fri Sep 18 07:59:45 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 18 Sep 2020 07:59:45 GMT Subject: RFR: 8253332: ZGC: Make heap views reservation platform independent Message-ID: ZVirtualMemoryManager::reserve_contiguous_platform tries to reserve three views of a given address range. The posix and windows versions are more or less duplicates, with calls to platform dependent versions of reserve/unreserve functions. I'd like to clean this up in preparation of an alternative implementation for heap memory allocation on Windows. I choose to prefix the OS dependent functions with os_. For consistency, initialize_os should have been renamed as well, but the plan is to change that in a separate patch that splits that function into two, so I skipped it for now. ------------- Commit messages: - 8253332: ZGC: Make heap views reservation platform independent Changes: https://git.openjdk.java.net/jdk/pull/236/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=236&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253332 Stats: 129 lines in 4 files changed: 50 ins; 62 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/236.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/236/head:pull/236 PR: https://git.openjdk.java.net/jdk/pull/236 From shade at openjdk.java.net Fri Sep 18 08:22:57 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 18 Sep 2020 08:22:57 GMT Subject: RFR: 8253332: ZGC: Make heap views reservation platform independent In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 07:51:28 GMT, Stefan Karlsson wrote: > ZVirtualMemoryManager::reserve_contiguous_platform tries to reserve three views of a given address range. The posix and > windows versions are more or less duplicates, with calls to platform dependent versions of reserve/unreserve functions. > I'd like to clean this up in preparation of an alternative implementation for heap memory allocation on Windows. > > I choose to prefix the OS dependent functions with os_. For consistency, initialize_os should have been renamed as > well, but the plan is to change that in a separate patch that splits that function into two, so I skipped it for now. Drive-by review below. src/hotspot/os/posix/gc/z/zVirtualMemory_posix.cpp line 45: > 43: if (res != addr) { > 44: // Failed to reserve memory at the requested address > 45: os_unreserve(res, size); A bit odd to see the assymetry here: `mmap` is used above, so `munmap` would be expected here? I see `os_unreserve` does the same thing, but does it guaranteed to do so? src/hotspot/share/gc/z/zVirtualMemory.cpp line 126: > 124: > 125: // Register address views with native memory tracker > 126: nmt_reserve(ZAddress::marked0(start), size); The first arguments are the same as locals `marked0`, `marked1`, `remapped` above, right? Can be reused then? ------------- PR: https://git.openjdk.java.net/jdk/pull/236 From shade at openjdk.java.net Fri Sep 18 08:26:03 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 18 Sep 2020 08:26:03 GMT Subject: Integrated: 8253278: Refactor/cleanup oopDesc::*_klass_addr In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 08:37:26 GMT, Aleksey Shipilev wrote: > Right now this one has the comment mentioning CMS: > > Klass** oopDesc::klass_addr(HeapWord* mem) { > // Only used internally and with CMS and will not work with > // UseCompressedOops > assert(!UseCompressedClassPointers, "only supported with uncompressed klass pointers"); > ByteSize offset = byte_offset_of(oopDesc, _metadata._klass); > return (Klass**) (((char*)mem) + in_bytes(offset)); > } > > But that is not true, it is used on the generic paths. > > The rest are the snowballing changes: > - in `load_klass_raw` and `set_klass`: `compressed_klass_addr` and `klass_addr` are used where the direct access to > `_metadata` can be done, avoiding these methods > - the leftover use is in `set_klass_release`, where we can simplify things by inlining `_addr` methods directly > - `CHECK_SET_KLASS` macro seems too much ceremony for just two asserts > > Note that new code uses the universal `klass_offset_in_bytes`, that is technically `offset_of(..., _metadata._klass)`. > This is different from the previous code, but it matches what other code is doing -- it trusts that both > `_metadata._klass` and `_metadata._compressed_klass` are on the same offsets. I thought to add a very paranoid assert > there, but decided not to. Testing: > - [x] Linux x86_64 fastdebug hotspot_gc_shenandoah > - [x] Linux x86_64 release hotspot_gc_shenandoah > - [x] Linux x86_64 fastdebug tier1 > - [x] Linux x86_64 fastdebug tier2 > - [x] Linux x86_64 fastdebug tier1, -XX:+UseShenandoahGC > - [x] Linux x86_64 fastdebug tier2, -XX:+UseShenandoahGC This pull request has now been integrated. Changeset: 11c4ea96 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/11c4ea96 Stats: 46 lines in 3 files changed: 34 ins; 1 del; 11 mod 8253278: Refactor/cleanup oopDesc::*_klass_addr Reviewed-by: coleenp, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/221 From stefank at openjdk.java.net Fri Sep 18 08:30:10 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 18 Sep 2020 08:30:10 GMT Subject: RFR: 8253332: ZGC: Make heap views reservation platform independent In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 08:17:57 GMT, Aleksey Shipilev wrote: >> ZVirtualMemoryManager::reserve_contiguous_platform tries to reserve three views of a given address range. The posix and >> windows versions are more or less duplicates, with calls to platform dependent versions of reserve/unreserve functions. >> I'd like to clean this up in preparation of an alternative implementation for heap memory allocation on Windows. >> >> I choose to prefix the OS dependent functions with os_. For consistency, initialize_os should have been renamed as >> well, but the plan is to change that in a separate patch that splits that function into two, so I skipped it for now. > > src/hotspot/os/posix/gc/z/zVirtualMemory_posix.cpp line 45: > >> 43: if (res != addr) { >> 44: // Failed to reserve memory at the requested address >> 45: os_unreserve(res, size); > > A bit odd to see the assymetry here: `mmap` is used above, so `munmap` would be expected here? I see `os_unreserve` > does the same thing, but does it guaranteed to do so? Yes. I agree. Will fix. > src/hotspot/share/gc/z/zVirtualMemory.cpp line 126: > >> 124: >> 125: // Register address views with native memory tracker >> 126: nmt_reserve(ZAddress::marked0(start), size); > > The first arguments are the same as locals `marked0`, `marked1`, `remapped` above, right? Can be reused then? Yes. At one point I had this part extracted into a separate function and had to re-resolve those values. ------------- PR: https://git.openjdk.java.net/jdk/pull/236 From adinn at redhat.com Fri Sep 18 08:48:42 2020 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 18 Sep 2020 09:48:42 +0100 Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> Message-ID: On 17/09/2020 19:22, Jason Tatton wrote: > This patch is just missing a couple of reviewers... Please can someone step forward? > > I think it's a fairly straightforward change. I believe you got a review from Andrew Haley -- it was quoted in your follow-up from which I selected the above response. What you did not get was license to proceed and push this change. That's because what is actually missing is the justification he asked for. As Andrew pointed out the change is simple but the reason for implementing it is not. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From jbhateja at openjdk.java.net Fri Sep 18 08:52:30 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 18 Sep 2020 08:52:30 GMT Subject: RFR: 8252847: New AVX512 optimized stubs for both conjoint and disjoint arraycopy [v3] In-Reply-To: References: Message-ID: > Summary: > > 1) New AVX3 optimized stubs for both conjoint and disjoint arraycopy. > 2) Special instruction sequence blocks for copy sizes b/w 32-192 bytes. > 3) Block copy operation above 192 bytes is performed using destination address aligned PRE-MAIN-POST loop. Main loop > copies 192 byte in one iteration and tail part fall over special instruction sequence blocks. 4) Both small copy block > and aligned loop use 32 byte vector register to prevent and frequency penalty for copy sizes less than AVX3Threshold. > 5) For block size above AVX3Theshold both special blocks and loop operate using 64 byte register. 6) In case user > sets the maximum vector size to 32 bytes, forward copy (disjoint) operations are done using efficient REP MOVS for copy > sizes above 4096 bytes. JMH Results: > System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz > Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java > Baseline : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_Baseline.txt]() > WithOpt : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_WithOpts.txt]() Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8252847: Review comments resolution ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/61/files - new: https://git.openjdk.java.net/jdk/pull/61/files/0cd42ccb..271b6457 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=61&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=61&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/61.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/61/head:pull/61 PR: https://git.openjdk.java.net/jdk/pull/61 From jbhateja at openjdk.java.net Fri Sep 18 08:52:30 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 18 Sep 2020 08:52:30 GMT Subject: RFR: 8252847: New AVX512 optimized stubs for both conjoint and disjoint arraycopy [v2] In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 13:22:07 GMT, Nils Eliasson wrote: > My only concern is that it's getting hard to follow under what circumstances avx3 instructions are used: > Could it be the case that different thresholds are needed for when you are using avx3 instructions with 32 or 64 byte > vectors? Are we sure all variants are tested? Following 2 runtime flags influence the implementation :- - MaxVectorSize: Determined during VM initialization based on the CPUID of the target. - AVX3Theshold: Set to a default value of 4096 bytes based on prior performance analysis. Following general rules were followed during implementation: 1) If target support AVX3 features (BW+VL+F) then copy will use 32 byte vectors (YMMs) for both special cases and aligned copy loop. This is default configuration. 2) If copy length is above AVX3Threshold, then we can safely use 64 byte vectors (ZMMs) for main copy loop (and tail) since bulk of the cycles will be consumed in it. 3) Leaf level Macro Assembly routines can dynamically choose b/w YMM or ZMM register based on the AVX3Threshold value. 4) If user forces MaxVectorSize=32 then above 4096 bytes its seen that REP MOVs shows a better performance for disjoint copies. For conjoint/backward copy vector based copy performs better. Thus, for 32 byte vector we do not need any threshold since they execute at max frequency level. tier1, tier2 and tier3 did not show any new issues with the changes. > Also - have you thought about supporting oop-copies? You only have to call the We may not see significant performance improvement considering prologue and epilogue barriers does considerable processing over object arrays. ------------- PR: https://git.openjdk.java.net/jdk/pull/61 From jbhateja at openjdk.java.net Fri Sep 18 09:10:05 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 18 Sep 2020 09:10:05 GMT Subject: RFR: 8252847: New AVX512 optimized stubs for both conjoint and disjoint arraycopy [v2] In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 13:22:07 GMT, Nils Eliasson wrote: > BarrierSetAssembler::arraycopy_prologue/epilogue like in the old versions. It's not a requirement for me to approve > this - but an encouragement for a future patch. Yes that's a good pointer, I can explore extending existing GC barriers for array copy as a separate next step. ------------- PR: https://git.openjdk.java.net/jdk/pull/61 From rehn at openjdk.java.net Fri Sep 18 09:10:59 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 18 Sep 2020 09:10:59 GMT Subject: RFR: 8212107: VMThread issues and cleanup In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 05:27:01 GMT, Aleksey Shipilev wrote: >> We simplify the vmThread by removing the queue and refactor the the main loop. >> This solves the issues listed: >> - It can create an extra safepoint directly after a safepoint. >> - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. >> - The exposure of the vm operation is dangerous if it's a handshake. >> - The code is a hornets nest with the repetition of checks and branches >> >> Passes t1-8, and a benchmark run. >> >> If you want a smaller diff the commits contains the incremental progress and each commit passed t1. > > src/hotspot/share/runtime/vmThread.cpp line 355: > >> 353: } >> 354: ml.notify_all(); >> 355: ml.wait(); > > It is really odd to see back-to-back `notify_all` and `wait`. Would that mean two threads sitting in this loop would > just wake one another continuously? This can theoretically be an issue if there is operation set and then two non-JavaThread trying set a operation. Or if there is a handshake operation set. I did not consider this scenario proper. I think we need two separate Monitors. Fixing ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From rehn at openjdk.java.net Fri Sep 18 09:20:08 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 18 Sep 2020 09:20:08 GMT Subject: RFR: 8212107: VMThread issues and cleanup In-Reply-To: References: Message-ID: <0nRBJII0rpZNU7YnTSqJ5qrxpQv75Ouzw4y3MPNqyCQ=.07e8d0b4-740e-448e-b690-b7ca0c1a7b6a@github.com> On Fri, 18 Sep 2020 05:04:30 GMT, Aleksey Shipilev wrote: >> We simplify the vmThread by removing the queue and refactor the the main loop. >> This solves the issues listed: >> - It can create an extra safepoint directly after a safepoint. >> - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. >> - The exposure of the vm operation is dangerous if it's a handshake. >> - The code is a hornets nest with the repetition of checks and branches >> >> Passes t1-8, and a benchmark run. >> >> If you want a smaller diff the commits contains the incremental progress and each commit passed t1. > > src/hotspot/share/runtime/mutexLocker.cpp line 68: > >> 66: Mutex* TouchedMethodLog_lock = NULL; >> 67: Mutex* RetData_lock = NULL; >> 68: Monitor* VMOperation_lock = NULL; > > Indenting is a bit off here? Fixing > src/hotspot/share/runtime/mutexLocker.hpp line 61: > >> 59: extern Mutex* TouchedMethodLog_lock; // a lock on allocation of LogExecutedMethods info >> 60: extern Mutex* RetData_lock; // a lock on installation of RetData inside method data >> 61: extern Monitor* VMOperation_lock; // a lock on queue of vm_operations waiting to execute > > Indenting is a bit off? Fixing > src/hotspot/share/runtime/thread.hpp line 625: > >> 623: >> 624: // For tracking the heavyweight monitor the thread is pending on. >> 625: ObjectMonitor* current_pending_monitor() { > > If this goes, then the declaration of `_vm_operation_started_count` can also go? Fixing > src/hotspot/share/runtime/thread.hpp line 627: > >> 625: ObjectMonitor* current_pending_monitor() { >> 626: return _current_pending_monitor; >> 627: } > > Ditto for `_vm_operation_completed_count`? Fixing > src/hotspot/share/runtime/vmThread.cpp line 222: > >> 220: void VMThread::wait_for_vm_thread_exit() { >> 221: assert(Thread::current()->is_Java_thread(), "Should be a JavaThread"); >> 222: assert(((JavaThread*)Thread::current())->is_terminated(), "Should be terminated"); > > Looks like just `assert(JavaThread::current()->is_terminated(), "Should be terminated")`. Fixing > src/hotspot/share/runtime/vmThread.cpp line 305: > >> 303: // we emit a handshake if it's been more than a second since last. >> 304: jlong deadline_ms = GuaranteedSafepointInterval != 0 ? GuaranteedSafepointInterval : 1000; >> 305: deadline_ms += last_halot_ms; > > It would seem more straight-forward to write it like this, to highlight the "base" `last_halot_ms` and the "addition" > `interval`: > // ... > jlong interval = (GuaranteedSafepointInterval != 0 ? GuaranteedSafepointInterval : 1000); > jlong deadline_ms = last_halot_ms + interval; > if (now_ms > deadline_ms) { > last_halot_ms = now_ms; > return true; > } > return false; > > ...but that's just a personal preference. Fixing > src/hotspot/share/runtime/vmThread.cpp line 313: > >> 311: } >> 312: >> 313: void VMThread::cleanup_safepoint_alot() { > > This handles `GuaranteedSafepointInterval` periodic op as well, so `cleanup_safepoint_alot` seems misnomer. Fixing, but not sure if you like. > src/hotspot/share/runtime/vmThread.cpp line 344: > >> 342: } >> 343: >> 344: void VMThread::until_executed(VM_Operation* op) { > > ...`until_executed`? Feels like missing a verb, e.g. `wait_until_executed`? Fixing > src/hotspot/share/runtime/vmThread.cpp line 392: > >> 390: >> 391: HandleMark hm(VMThread::vm_thread()); >> 392: EventMark em("Executing %s VM operation: %s", prev_vm_operation ? "nested" : "", op->name()); > > Check `prev_vm_operation != NULL` explicitly? Fixing > src/hotspot/share/runtime/vmThread.cpp line 427: > >> 425: >> 426: // Notify previous op done >> 427: mu_queue.notify(); > > So, `notify`, not `notifyAll` here? We sure we want to bet who -- of all current waiters -- gets the notification? Will be changed, due to above issue. > src/hotspot/share/runtime/vmThread.cpp line 470: > >> 468: while (true) { >> 469: wait_for_operation(); >> 470: if (!should_terminate()) { > > This is a trailing block. So it might just be `do { ... } while (!should_terminate())`? Fixing > src/hotspot/share/runtime/vmThread.hpp line 103: > >> 101: // Returns the current vm operation if any. >> 102: static VM_Operation* vm_operation() { >> 103: assert(Thread::current()->is_VM_thread(), "Must be);"); > > Typos in `Must be);`. Fixing > src/hotspot/share/runtime/vmThread.hpp line 129: > >> 127: // VM_Operation support >> 128: static VM_Operation* _cur_vm_operation; // Current VM operation >> 129: static VM_Operation* _next_vm_operation; > > Comment to match `// Current VM operation` above? Fixing ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From adinn at openjdk.java.net Fri Sep 18 10:10:53 2020 From: adinn at openjdk.java.net (Andrew Dinn) Date: Fri, 18 Sep 2020 10:10:53 GMT Subject: RFR: 8252311: AArch64: save two words in itable lookup stub In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 15:25:41 GMT, Boris Ulasevich wrote: > The change was reviewed on hotspot-compiler-dev, but I missed the time to complete > the commit to the mercural repo. Can I get it approved once again? > > Issue: [JDK-8252311](https://bugs.openjdk.java.net/browse/JDK-8252311) > > Description: > The interface method lookup stub becomes hot when interface calls > are performed frequently. The stub assembly code can be made > shorter (132->124 bytes) by using a pre-increment instruction variant. > > Review by Andrew Dinn && Andrew Haley: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039818.html > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039833.html > > For the reference, benchmark scores with higher iteration number: > Neoverse Cnt Score Error -> Score Error Units > InvokeInterface.bench 25 6163.804 ? 5.116 -> 6303.035 ? 5.450 ops/ms > InvokeInterface.bench:L1-icache-loads 5 305.408 ? 1.895 -> 272.891 ? 0.750 #/op > InvokeInterface.bench:iTLB-loads 5 221.755 ? 0.990 -> 207.635 ? 0.566 #/op > InvokeInterface.bench:instructions 5 1035.468 ? 2.701 -> 953.466 ? 1.667 #/op Marked as reviewed by adinn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/189 From mbeckwit at openjdk.java.net Fri Sep 18 10:14:22 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Fri, 18 Sep 2020 10:14:22 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support Message-ID: This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html Changes since then: * We've improved the write barrier as suggested by Andrew [1] * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but will be required for the upcoming macOS+Aarch64 [2] port as well. * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the Windows-specific CPU feature detection on top of it. [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html [2] https://openjdk.java.net/jeps/8251280 ------------- Commit messages: - 8248787: G1: Workaround MSVC bug - 8248670: Windows: Exception handling support on AArch64 - 8248660: AArch64: Make _clear_cache and _nop portable - 8248659: AArch64: Extend CPU Feature detection - 8248656: Add Windows AArch64 platform support code - 8248498: Add build system support for Windows AArch64 - 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__ - 8248663: AArch64: Avoid existing macros/keywords of MSVC - 8248676: AArch64: Add workaround for LITable constructor - 8248500: AArch64: Remove the r18 dependency on Windows AArch64 (regenerate tests) - ... and 3 more: https://git.openjdk.java.net/jdk/compare/68da63dc...26e4af3a Changes: https://git.openjdk.java.net/jdk/pull/212/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248238 Stats: 4230 lines in 69 files changed: 2406 ins; 273 del; 1551 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From avoitylov at openjdk.java.net Fri Sep 18 10:59:21 2020 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Fri, 18 Sep 2020 10:59:21 GMT Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2] In-Reply-To: <6jqlCPXe69fPRvYFrytJsECkaa9tJ1hYWISNgyPP4Eg=.40944ef5-93b0-4db4-948b-80bb7898e9e8@github.com> References: <6jqlCPXe69fPRvYFrytJsECkaa9tJ1hYWISNgyPP4Eg=.40944ef5-93b0-4db4-948b-80bb7898e9e8@github.com> Message-ID: On Mon, 14 Sep 2020 06:30:50 GMT, Aleksei Voitylov wrote: >> Marked as reviewed by dholmes (Reviewer). > > thank you Alan, Erik, and David! When the JEP becomes Targeted, I'll use this PR to integrate the changes. I added the contributors that could be found in the portola project commits. If anyone knows some other contributors I missed, I'll be happy to stand corrected. ------------- PR: https://git.openjdk.java.net/jdk/pull/49 From shade at openjdk.java.net Fri Sep 18 11:00:36 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 18 Sep 2020 11:00:36 GMT Subject: RFR: 8253349: Remove unimplemented SharedRuntime::native_method_throw_unsupported_operation_exception_entry Message-ID: The definition was removed in JDK-7196277 (confidential): https://github.com/openjdk/jdk/commit/149097fbb751155cba49de38f8da5b39635198af Declaration was left behind. Testing: - [x] Linux x86_64 fastdebug build - [x] Text search for `native_method_throw_unsupported_operation_exception_entry` in `src/hotspot` ------------- Commit messages: - 8253349: Remove unimplemented SharedRuntime::native_method_throw_unsupported_operation_exception_entry Changes: https://git.openjdk.java.net/jdk/pull/244/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=244&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253349 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/244.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/244/head:pull/244 PR: https://git.openjdk.java.net/jdk/pull/244 From github.com+70893615+jasontatton-aws at openjdk.java.net Fri Sep 18 11:06:55 2020 From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton) Date: Fri, 18 Sep 2020 11:06:55 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> Message-ID: <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> On Thu, 17 Sep 2020 18:20:08 GMT, Jason Tatton wrote: >> Hi Andrew, >> >> The current indexOf char intrinsics for StringUTF16 and the new one here for StringLatin1 both use the AVX2 ? i.e. 256 >> bit instructions, these are also affected by the frequency scaling which affects the AVX-512 instructions you pointed >> out. Of course in a world where all the work taking place is AVX instructions this wouldn?t be an issue but in mixed >> mode execution this is a problem. However, the compiler does have knowledge of the capability of the CPU upon which >> it?s optimizing code for and is able to decide whether to use AVX instructions if they are supported by the CPU AND if >> it wouldn?t be detrimental for performance. In fact, there is a flag which one can use to interact with >> this: -XX:UseAVX=version. This of course made testing this patch an interesting experience as the AVX2 instructions >> were not enabled on the Xeon processors which I had access to at AWS, but in the end I was able to use an i7 on my >> corporate macbook to validate the code. From: mlbridge[bot] Sent: 11 September 2020 17:01 >> To: openjdk/jdk Cc: Tatton, Jason ; Mention >> Subject: Re: [openjdk/jdk] 8173585: Intrinsify StringLatin1.indexOf(char) (#71) >> >> >> Mailing list message from Andrew Haley on hotspot-dev: >> >> On 11/09/2020 11:23, Jason Tatton wrote: >> >> For the x86 implementation there may be two further improvements we >> can make in order to improve performance of both the StringUTF16 and >> StringLatin1 indexOf(char) intrinsics: >> >> 1. Make use of AVX-512 instructions. >> >> Is this really a good idea? >> >> When the processor detects Intel AVX instructions, additional >> voltage is applied to the core. With the additional voltage applied, >> the processor could run hotter, requiring the operating frequency to >> be reduced to maintain operations within the TDP limits. The higher >> voltage is maintained for 1 millisecond after the last Intel AVX >> instruction completes, and then the voltage returns to the nominal >> TDP voltage level. >> >> https://computing.llnl.gov/tutorials/linux_clusters/intelAVXperformanceWhitePaper.pdf >> >> So, if StringLatin1.indexOf(char) executes enough to make a difference >> to any real-world program, the effect may well be to slow down the clock >> for all of the code that does not use AVX. >> >> 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD >> instructions instead of a loop. >> >> -- >> Andrew Haley (he/him) >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> https://keybase.io/andrewhaley >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> >> ? >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on GitHub, or >> unsubscribe. > > Hi everyone, > > This patch is just missing a couple of reviewers... Please can someone step forward? > > I think it's a fairly straightforward change. > > -Jason Hi Andrew, Thanks for coming back to me. Looking on the github [PR](https://github.com/openjdk/jdk/pull/71) nobody is tagged as a reviewer for this (perhaps this is a feature which is not being used). > That's > because what is actually missing is the justification he asked for. As > Andrew pointed out the change is simple but the reason for implementing > it is not. There are two separate things here: 1). Justification for the change itself: -The objective and justification for this patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 indexOf(char) for x86 and ARM64. This solves the problem as raised in [JDK-8173585](https://bugs.openjdk.java.net/browse/JDK-8173585), and also on the [mailing list](http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-January/005539.html). 2). Discussion around future enhancements - concerning potential use of AVX-512 instructions and a more optimal implementation for short strings. -These would be separate JBS's I'm not advocating for/against this, they are just ideas separate from this JBS. ------------- PR: https://git.openjdk.java.net/jdk/pull/71 From github.com+1536494+doom369 at openjdk.java.net Fri Sep 18 11:07:46 2020 From: github.com+1536494+doom369 at openjdk.java.net (Dmitriy Dumanskiy) Date: Fri, 18 Sep 2020 11:07:46 GMT Subject: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase In-Reply-To: References: Message-ID: <668fR1wEZWaC0TDCyRIeOZ4AddXZXnKQhyHQdXtOab8=.6cb419cb-632b-4524-980e-18a6e06958e8@github.com> On Fri, 18 Sep 2020 02:48:15 GMT, Stuart Marks wrote: >> Our local Santuario maintainer says: >> >> In general, changes to Apache Santuario should also be made at Apache so we stay in sync. > > Hi @doom369, I hope we didn't end up wasting too much of your time with this. I wanted to respond to a comment you made > earlier in this PR, >> I have in mind dozens of improvements all over the code like this one. > > It's hard to see, but as you discovered, the JDK has different groups of people maintaining different areas, and > sometimes there are hidden constraints on those different areas, for example, to avoid divergence with upstream source > bases. And as you discovered, sometimes those source bases might need to maintain compatibility with an older JDK ... > so we don't want to update this code even though it's IN the JDK. Those kind of constraints generally don't apply to > code in the java.base module, since there's nothing upstream of it, and by definition it cannot depend on anything > outside the JDK. Generally -- though there are exceptions -- we're more receptive to keeping stuff in java.base (and > sometimes related modules close to the core) on the latest and greatest stuff. There are some constraints, however. > There are some things we can't use too early during initialization of the JDK, such as lambdas. Also, there is some > code lurking around that is sometimes executed by the boot JDK, which is typically one release behind. (This is > definitely the case for tools like javac, but I think it might also apply to some things in base.) Anyway, if you'd > like to pursue some of these improvements, drop a note to core-libs-dev at openjdk and we can talk about it. Thanks. @stuart-marks thanks. Sure, I understand that maintaining OpenJDK is not a simple task. I thought as change is super simple without any side effects it can go through. But I was wrong. That's fine. I'll focus on `java.base` when I have some free time. ------------- PR: https://git.openjdk.java.net/jdk/pull/29 From shade at openjdk.java.net Fri Sep 18 11:08:46 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 18 Sep 2020 11:08:46 GMT Subject: RFR: 8253350: Remove unimplemented SharedRuntime::clean_*_entry Message-ID: Their existence seems to predate OpenJDK. There are no uses, no definitions. Testing: - [x] Linux x86_64 fastdebug build - [x] Text searches for `clean_*_entry` in `src/hotspot` ------------- Commit messages: - 8253350: Remove unimplemented SharedRuntime::clean_*_entry Changes: https://git.openjdk.java.net/jdk/pull/245/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=245&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253350 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/245.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/245/head:pull/245 PR: https://git.openjdk.java.net/jdk/pull/245 From neliasso at openjdk.java.net Fri Sep 18 11:22:43 2020 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Fri, 18 Sep 2020 11:22:43 GMT Subject: RFR: 8252847: New AVX512 optimized stubs for both conjoint and disjoint arraycopy [v3] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 08:52:30 GMT, Jatin Bhateja wrote: >> Summary: >> >> 1) New AVX3 optimized stubs for both conjoint and disjoint arraycopy. >> 2) Special instruction sequence blocks for copy sizes b/w 32-192 bytes. >> 3) Block copy operation above 192 bytes is performed using destination address aligned PRE-MAIN-POST loop. Main loop >> copies 192 byte in one iteration and tail part fall over special instruction sequence blocks. 4) Both small copy block >> and aligned loop use 32 byte vector register to prevent and frequency penalty for copy sizes less than AVX3Threshold. >> 5) For block size above AVX3Theshold both special blocks and loop operate using 64 byte register. 6) In case user >> sets the maximum vector size to 32 bytes, forward copy (disjoint) operations are done using efficient REP MOVS for copy >> sizes above 4096 bytes. JMH Results: >> System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz >> Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java >> Baseline : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_Baseline.txt]() >> WithOpt : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_WithOpts.txt]() > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8252847: Review comments resolution Thanks for the clarification och update! Reviewed. ------------- Marked as reviewed by neliasso (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/61 From github.com+70893615+jasontatton-aws at openjdk.java.net Fri Sep 18 11:56:09 2020 From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton) Date: Fri, 18 Sep 2020 11:56:09 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v2] In-Reply-To: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> Message-ID: <-DRWR4_f5u6DsSGHAuPnpHrhaG8Una8BXf4zDekQjLM=.469b08b6-a8b2-4a6b-8ab8-1a40810aede0@github.com> > This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for > x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it > I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as > code for C2. Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and > java/lang/StringLatin1.java https://bugs.openjdk.java.net/browse/JDK-8173585 > > Details of testing: > ============ > I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note > that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the > input String. Hence the test has been designed to cover all these cases. In summary they are: > - A ?short? string of < 16 characters. > - A SIMD String of 16 ? 31 characters. > - A AVX2 SIMD String of 32 characters+. > > Hardware used for testing: > ----------------------------- > > - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support). > - AWS Graviton 2 (ARM 64 processor). > > I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64. > > Possible future enhancements: > ==================== > For the x86 implementation there may be two further improvements we can make in order to improve performance of both > the StringUTF16 and StringLatin1 indexOf(char) intrinsics: > 1. Make use of AVX-512 instructions. > 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD > instructions instead of a loop. > Benchmark results: > ============ > **Without** the new StringLatin1 indexOf(char) intrinsic: > > | Benchmark | Mode | Cnt | Score | Error | Units | > | ------------- | ------------- |------------- |------------- |------------- |------------- | > | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op | > | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933 | ns/op | > > > **With** the new StringLatin1 indexOf(char) intrinsic: > > | Benchmark | Mode | Cnt | Score | Error | Units | > | ------------- | ------------- |------------- |------------- |------------- |------------- | > | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716 | ns/op | > | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306 | ns/op | > > > The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 > indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when > running on ARM. Jason Tatton has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge master - 8173585: further whitespace changes required by jcheck - JDK-8173585 - whitespace changes required by jcheck - JDK-8173585 ------------- Changes: https://git.openjdk.java.net/jdk/pull/71/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=71&range=01 Stats: 523 lines in 16 files changed: 506 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/71.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/71/head:pull/71 PR: https://git.openjdk.java.net/jdk/pull/71 From zgu at openjdk.java.net Fri Sep 18 12:27:38 2020 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 18 Sep 2020 12:27:38 GMT Subject: RFR: 8253350: Remove unimplemented SharedRuntime::clean_*_entry In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 11:02:28 GMT, Aleksey Shipilev wrote: > Their existence seems to predate OpenJDK. There are no uses, no definitions. > > Testing: > - [x] Linux x86_64 fastdebug build > - [x] Text searches for `clean_*_entry` in `src/hotspot` Looks good and trivial ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/245 From coleenp at openjdk.java.net Fri Sep 18 12:35:05 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 18 Sep 2020 12:35:05 GMT Subject: RFR: 8253278: Refactor/cleanup oopDesc::*_klass_addr In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 05:49:59 GMT, Stefan Karlsson wrote: >> Right now this one has the comment mentioning CMS: >> >> Klass** oopDesc::klass_addr(HeapWord* mem) { >> // Only used internally and with CMS and will not work with >> // UseCompressedOops >> assert(!UseCompressedClassPointers, "only supported with uncompressed klass pointers"); >> ByteSize offset = byte_offset_of(oopDesc, _metadata._klass); >> return (Klass**) (((char*)mem) + in_bytes(offset)); >> } >> >> But that is not true, it is used on the generic paths. >> >> The rest are the snowballing changes: >> - in `load_klass_raw` and `set_klass`: `compressed_klass_addr` and `klass_addr` are used where the direct access to >> `_metadata` can be done, avoiding these methods >> - the leftover use is in `set_klass_release`, where we can simplify things by inlining `_addr` methods directly >> - `CHECK_SET_KLASS` macro seems too much ceremony for just two asserts >> >> Note that new code uses the universal `klass_offset_in_bytes`, that is technically `offset_of(..., _metadata._klass)`. >> This is different from the previous code, but it matches what other code is doing -- it trusts that both >> `_metadata._klass` and `_metadata._compressed_klass` are on the same offsets. I thought to add a very paranoid assert >> there, but decided not to. Testing: >> - [x] Linux x86_64 fastdebug hotspot_gc_shenandoah >> - [x] Linux x86_64 release hotspot_gc_shenandoah >> - [x] Linux x86_64 fastdebug tier1 >> - [x] Linux x86_64 fastdebug tier2 >> - [x] Linux x86_64 fastdebug tier1, -XX:+UseShenandoahGC >> - [x] Linux x86_64 fastdebug tier2, -XX:+UseShenandoahGC > > Marked as reviewed by stefank (Reviewer). > It is a sensitive code, I'd like another reviewer. Yes, I didn't say it was trivial so yes, you needed another reviewer, which I see you got. Also, there should be an approximate 24 hr turnaround for PRs so that all the timezones have a chance to review it. ------------- PR: https://git.openjdk.java.net/jdk/pull/221 From shade at openjdk.java.net Fri Sep 18 12:37:32 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 18 Sep 2020 12:37:32 GMT Subject: RFR: 8253278: Refactor/cleanup oopDesc::*_klass_addr In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 12:32:43 GMT, Coleen Phillimore wrote: > > It is a sensitive code, I'd like another reviewer. > > Yes, I didn't say it was trivial so yes, you needed another reviewer, which I see you got. Also, there should be an > approximate 24 hr turnaround for PRs so that all the timezones have a chance to review it. Asked Skara folks to implemented this recently: https://bugs.openjdk.java.net/browse/SKARA-678 ------------- PR: https://git.openjdk.java.net/jdk/pull/221 From adinn at redhat.com Fri Sep 18 12:42:23 2020 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 18 Sep 2020 13:42:23 +0100 Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> Message-ID: On 18/09/2020 12:06, Jason Tatton wrote: > There are two separate things here: > 1). Justification for the change itself: > -The objective and justification for this patch is to bring the performance of StringLatin1 indexOf(char) in > line with StringUTF16 indexOf(char) for x86 and ARM64. This solves the problem as raised in > [JDK-8173585](https://bugs.openjdk.java.net/browse/JDK-8173585), and also on the [mailing > list](http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-January/005539.html). > 2). Discussion around future enhancements - concerning potential use of AVX-512 instructions and a more optimal > implementation for short strings. > -These would be separate JBS's I'm not advocating for/against this, they are just ideas separate from this JBS. I don't agree that these two things are separable. Andrew's point applies to both. In the first case the problem is that the 'evidence' we have does not testify to the possibility Andrew outlines. Both code examples used to justify the idea StringLatin1.indexOf(char) will perform 'better' with an AVX-based intrinsic are micro-benchmarks that do a lot of intensive String manipulation and nothing else i.e. they won't get hit by the possible cost of ramping up power for AVX because they make extensive use of AVX and then stop. That's very unlikely to happen in a real world case. So, the fact that this change removes the disparity seen with these benchmarks is still not evidence for a general improvement. So, I don't (yet) see a reason to make this change and the possibility still stands that adopting this change may end up making most code that uses StringLatin1.indexOf(char) worse. It might be a good idea to consider finding some way to test whether the cost Andrew has highlighted makes a difference before committing this change. I know the same argument might might be raised aginst the existing intrinsics but surely that's an a fortiori argument for not proceeding. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From coleenp at openjdk.java.net Fri Sep 18 13:07:03 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 18 Sep 2020 13:07:03 GMT Subject: RFR: 8253350: Remove unimplemented SharedRuntime::clean_*_entry In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 11:02:28 GMT, Aleksey Shipilev wrote: > Their existence seems to predate OpenJDK. There are no uses, no definitions. > > Testing: > - [x] Linux x86_64 fastdebug build > - [x] Text searches for `clean_*_entry` in `src/hotspot` Also appears trivial. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/245 From shade at openjdk.java.net Fri Sep 18 13:33:27 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 18 Sep 2020 13:33:27 GMT Subject: Integrated: 8253350: Remove unimplemented SharedRuntime::clean_*_entry In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 11:02:28 GMT, Aleksey Shipilev wrote: > Their existence seems to predate OpenJDK. There are no uses, no definitions. > > Testing: > - [x] Linux x86_64 fastdebug build > - [x] Text searches for `clean_*_entry` in `src/hotspot` This pull request has now been integrated. Changeset: 05572e86 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/05572e86 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8253350: Remove unimplemented SharedRuntime::clean_*_entry Reviewed-by: zgu, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/245 From erikj at openjdk.java.net Fri Sep 18 13:35:34 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 18 Sep 2020 13:35:34 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 20:26:10 GMT, Monica Beckwith wrote: > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Build changes look good to me. I will take this branch for a spin. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From aph at openjdk.java.net Fri Sep 18 13:45:51 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 18 Sep 2020 13:45:51 GMT Subject: RFR: 8252311: AArch64: save two words in itable lookup stub In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 15:25:41 GMT, Boris Ulasevich wrote: > The change was reviewed on hotspot-compiler-dev, but I missed the time to complete > the commit to the mercural repo. Can I get it approved once again? > > Issue: [JDK-8252311](https://bugs.openjdk.java.net/browse/JDK-8252311) > > Description: > The interface method lookup stub becomes hot when interface calls > are performed frequently. The stub assembly code can be made > shorter (132->124 bytes) by using a pre-increment instruction variant. > > Review by Andrew Dinn && Andrew Haley: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039818.html > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039833.html > > For the reference, benchmark scores with higher iteration number: > Neoverse Cnt Score Error -> Score Error Units > InvokeInterface.bench 25 6163.804 ? 5.116 -> 6303.035 ? 5.450 ops/ms > InvokeInterface.bench:L1-icache-loads 5 305.408 ? 1.895 -> 272.891 ? 0.750 #/op > InvokeInterface.bench:iTLB-loads 5 221.755 ? 0.990 -> 207.635 ? 0.566 #/op > InvokeInterface.bench:instructions 5 1035.468 ? 2.701 -> 953.466 ? 1.667 #/op Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/189 From aph at redhat.com Fri Sep 18 13:47:54 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 18 Sep 2020 14:47:54 +0100 Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: Message-ID: <28d501ee-0f96-48e0-bfc4-230721018968@redhat.com> On 17/09/2020 05:26, Fei Yang wrote: > For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on > real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is > detected. Given that there's no real hardware, it's extra-important to add the new instructions to cpu/aarch64/aarch64-asmtest.py and regenerate the test in assembler_aarch64.cc:asm_check. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From coleenp at openjdk.java.net Fri Sep 18 15:20:42 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 18 Sep 2020 15:20:42 GMT Subject: RFR: 8241390: 'Deadlock' with VM_RedefineClasses::lock_classes() [v3] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 01:02:24 GMT, Daniil Titov wrote: >> The change fixes a 'deadlock' situation in VM_RedefineClasses::lock_classes() when the current thread is in the middle >> of redefining the same class. The change is based on the fix [1] suggested in the Jira issue [2] comment. >> [1] http://cr.openjdk.java.net/~jiangli/8241390/webrev.00/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8241390 >> >> Testing: :jdk_instrument, tier1-tier3, and tier5 tests pass. > > Daniil Titov has updated the pull request incrementally with one additional commit since the last revision: > > Corrected test summary Nice! Thank you for fixing this. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/190 From pchilanomate at openjdk.java.net Fri Sep 18 15:28:32 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Fri, 18 Sep 2020 15:28:32 GMT Subject: RFR: 8238761: Asynchronous handshakes [v2] In-Reply-To: References: Message-ID: <-wc1ckdaxM1kpG5HN4pNbGrvUvFby33RuTFtJgZIiJ0=.6c930a8f-2fa6-4e0d-9e6e-4aa99cad66ce@github.com> On Thu, 17 Sep 2020 18:57:33 GMT, Patricio Chilano Mateo wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed double checks >> Added NSV >> ProcessResult to enum >> Fixed logging >> Moved _active_handshaker to private > > Changes look good, thanks for fixing! I added some comments on the changes. Update looks good, thanks Robbin! ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From erikj at openjdk.java.net Fri Sep 18 15:37:26 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 18 Sep 2020 15:37:26 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 13:33:07 GMT, Erik Joelsson wrote: >> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > Build changes look good to me. I will take this branch for a spin. Our linux-aarch64 build fails with this: cc: error: unrecognized command line option '-std=c++14' when compiling build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch I'm trying to configure a windows-aarch64 build, but it fails on fixpath. Is this something you are also experiencing, and if so, how are you addressing it? ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From fyang at openjdk.java.net Fri Sep 18 15:54:57 2020 From: fyang at openjdk.java.net (Fei Yang) Date: Fri, 18 Sep 2020 15:54:57 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v2] In-Reply-To: References: Message-ID: > Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com > > This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. > Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 > > Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. > For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. > "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. > > We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. > Patch passed jtreg tier1-3 tests with QEMU system emulator. > Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make > sure that there's no regression. > We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java > We measured the performance benefit with an aarch64 cycle-accurate simulator. > Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. > > For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on > real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is > detected. Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge master - Fix trailing whitespace issue - 8252204: AArch64: Implement SHA3 accelerator/intrinsic Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com ------------- Changes: https://git.openjdk.java.net/jdk/pull/207/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=01 Stats: 1012 lines in 29 files changed: 940 ins; 13 del; 59 mod Patch: https://git.openjdk.java.net/jdk/pull/207.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207 PR: https://git.openjdk.java.net/jdk/pull/207 From github.com+70893615+jasontatton-aws at openjdk.java.net Fri Sep 18 16:00:00 2020 From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton) Date: Fri, 18 Sep 2020 16:00:00 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> Message-ID: <2dlrgVtF5twY9WGHEKS2ZcLEm1jPmGgOfFF6o-ZyUHc=.c33e5814-724a-4569-9eed-97e8afaaa440@github.com> On Fri, 18 Sep 2020 11:04:34 GMT, Jason Tatton wrote: >> Hi everyone, >> >> This patch is just missing a couple of reviewers... Please can someone step forward? >> >> I think it's a fairly straightforward change. >> >> -Jason > > Hi Andrew, > > Thanks for coming back to me. Looking on the github [PR](https://github.com/openjdk/jdk/pull/71) nobody is tagged as a > reviewer for this (perhaps this is a feature which is not being used). >> That's >> because what is actually missing is the justification he asked for. As >> Andrew pointed out the change is simple but the reason for implementing >> it is not. > > There are two separate things here: > 1). Justification for the change itself: > -The objective and justification for this patch is to bring the performance of StringLatin1 indexOf(char) in line with > StringUTF16 indexOf(char) for x86 and ARM64. This solves the problem as raised in > [JDK-8173585](https://bugs.openjdk.java.net/browse/JDK-8173585), and also on the [mailing > list](http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-January/005539.html). > > 2). Discussion around future enhancements - concerning potential use of AVX-512 instructions and a more optimal > implementation for short strings. > -These would be separate JBS's I'm not advocating for/against this, they are just ideas separate from this JBS. The AVX2 code path represents approximately 1/6th of the patch (1/7th including the infrastructure ?code around this). I don?t think we should discard the entire patch because 1/6th of the code may have unintended consequences. This is especially the case when the rest of the code has been benchmarked, with certainty, to show the desired performance improvement has been achieved. ? Additionally, I do not see how those unintended consequences will ever be realised because the JVM has knowledge of the AVX capability of the chip it?s running on and disables the AVX2 code path for chips which suffer from the performance degradation which has been outlined in this discussion. Thus protecting us from unintended consequences. Unless we are asserting that this mechanism to globally control the use of AVX2 instructions is broken or otherwise non functional I see no reason to remove the AVX2 code. And to be consistent we would really need to look at removing all instances of AVX2 code in the JVM (of which there is quite a lot). ? As I see it there are three ways forward: 1. Accept the patch as is. 2. Modify the patch to remove the AVX code path for x86, and/or any other modifications needed. 3. Discard the patch entirely. At this point I am in favour of approach 1 but happy to accept 2 if advised that this is the right thing to do. ------------- PR: https://git.openjdk.java.net/jdk/pull/71 From fyang at openjdk.java.net Fri Sep 18 16:05:31 2020 From: fyang at openjdk.java.net (Fei Yang) Date: Fri, 18 Sep 2020 16:05:31 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v3] In-Reply-To: References: Message-ID: <0uUIKwe29qJd177yzRttb-vvIkccG_wV5YuEQG4VmNY=.d2b684c1-e098-4384-9ea6-bba1dded72cf@github.com> > Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com > > This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. > Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 > > Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. > For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. > "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. > > We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. > Patch passed jtreg tier1-3 tests with QEMU system emulator. > Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make > sure that there's no regression. > We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java > We measured the performance benefit with an aarch64 cycle-accurate simulator. > Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. > > For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on > real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is > detected. Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Rebase ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/207/files - new: https://git.openjdk.java.net/jdk/pull/207/files/32f0bdc3..3e155193 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=01-02 Stats: 9 lines in 2 files changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/207.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207 PR: https://git.openjdk.java.net/jdk/pull/207 From zgu at openjdk.java.net Fri Sep 18 16:09:11 2020 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 18 Sep 2020 16:09:11 GMT Subject: RFR: 8253361: Shenandoah: runtime barrier does not honor ShenandoahSelfFixing flag Message-ID: <7PdDOV4J-28DYlN004jvt14GEGZrKy62azlw5PO6J30=.0912c310-1d65-46f1-8d42-701fb5d3a4e3@github.com> ShenandoahSelfFixing flag is currently only honored by C2, not runtime barrier. Runtime barrier should check the check too. ------------- Commit messages: - Honor ShenandoahSelfFixing flag in runtime barrier - Tighten recusive reserveration handling - Fix trailing whitespace - Restore assertion - JDK-8252921 - JDK-8252921 Changes: https://git.openjdk.java.net/jdk/pull/254/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=254&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253361 Stats: 34 lines in 4 files changed: 18 ins; 13 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/254.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/254/head:pull/254 PR: https://git.openjdk.java.net/jdk/pull/254 From rkennke at openjdk.java.net Fri Sep 18 16:17:29 2020 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 18 Sep 2020 16:17:29 GMT Subject: RFR: 8253361: Shenandoah: runtime barrier does not honor ShenandoahSelfFixing flag In-Reply-To: <7PdDOV4J-28DYlN004jvt14GEGZrKy62azlw5PO6J30=.0912c310-1d65-46f1-8d42-701fb5d3a4e3@github.com> References: <7PdDOV4J-28DYlN004jvt14GEGZrKy62azlw5PO6J30=.0912c310-1d65-46f1-8d42-701fb5d3a4e3@github.com> Message-ID: On Fri, 18 Sep 2020 16:03:20 GMT, Zhengyu Gu wrote: > ShenandoahSelfFixing flag is currently only honored by C2, not runtime barrier. Runtime barrier should check the check > too. There seems to be a lot of unrelated changes in that patch, all that thread/NMT stuff... ------------- Changes requested by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/254 From adinn at openjdk.java.net Fri Sep 18 16:34:04 2020 From: adinn at openjdk.java.net (Andrew Dinn) Date: Fri, 18 Sep 2020 16:34:04 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: <2dlrgVtF5twY9WGHEKS2ZcLEm1jPmGgOfFF6o-ZyUHc=.c33e5814-724a-4569-9eed-97e8afaaa440@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> <2dlrgVtF5twY9WGHEKS2ZcLEm1jPmGgOfFF6o-ZyUHc=.c33e5814-724a-4569-9eed-97e8afaaa440@github.com> Message-ID: On Fri, 18 Sep 2020 15:55:52 GMT, Jason Tatton wrote: >> Hi Andrew, >> >> Thanks for coming back to me. Looking on the github [PR](https://github.com/openjdk/jdk/pull/71) nobody is tagged as a >> reviewer for this (perhaps this is a feature which is not being used). >>> That's >>> because what is actually missing is the justification he asked for. As >>> Andrew pointed out the change is simple but the reason for implementing >>> it is not. >> >> There are two separate things here: >> 1). Justification for the change itself: >> -The objective and justification for this patch is to bring the performance of StringLatin1 indexOf(char) in line with >> StringUTF16 indexOf(char) for x86 and ARM64. This solves the problem as raised in >> [JDK-8173585](https://bugs.openjdk.java.net/browse/JDK-8173585), and also on the [mailing >> list](http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-January/005539.html). >> >> 2). Discussion around future enhancements - concerning potential use of AVX-512 instructions and a more optimal >> implementation for short strings. >> -These would be separate JBS's I'm not advocating for/against this, they are just ideas separate from this JBS. > > The AVX2 code path represents approximately 1/6th of the patch (1/7th including the infrastructure ?code around this). > I don?t think we should discard the entire patch because 1/6th of the code may have unintended consequences. This is > especially the case when the rest of the code has been benchmarked, with certainty, to show the desired performance > improvement has been achieved. ? Additionally, I do not see how those unintended consequences will ever be realised > because the JVM has knowledge of the AVX capability of the chip it?s running on and disables the AVX2 code path for > chips which suffer from the performance degradation which has been outlined in this discussion. Thus protecting us from > unintended consequences. Unless we are asserting that this mechanism to globally control the use of AVX2 instructions > is broken or otherwise non functional I see no reason to remove the AVX2 code. And to be consistent we would really > need to look at removing all instances of AVX2 code in the JVM (of which there is quite a lot). ? As I see it there are > three ways forward: 1. Accept the patch as is. 2. Modify the patch to remove the AVX code path for x86, and/or any > other modifications needed. 3. Discard the patch entirely. At this point I am in favour of approach 1 but happy to > accept 2 if advised that this is the right thing to do. "the JVM has knowledge of the AVX capability of the chip it?s running on and disables the AVX2 code path for chips which suffer from the performance degradation which has been outlined in this discussion" Does it? The white paper Andrew cited doesn't mention this as being specific to only some chips that implement AVX2. Can you explain where this restricted effect is documented? Also, I assume you are referring to the code in vm_version_x86.cpp with this comment // Don't use AVX-512 on older Skylakes unless explicitly requested is that correct? ------------- PR: https://git.openjdk.java.net/jdk/pull/71 From sspitsyn at openjdk.java.net Fri Sep 18 16:41:29 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 18 Sep 2020 16:41:29 GMT Subject: RFR: 8241390: 'Deadlock' with VM_RedefineClasses::lock_classes() [v3] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 01:02:24 GMT, Daniil Titov wrote: >> The change fixes a 'deadlock' situation in VM_RedefineClasses::lock_classes() when the current thread is in the middle >> of redefining the same class. The change is based on the fix [1] suggested in the Jira issue [2] comment. >> [1] http://cr.openjdk.java.net/~jiangli/8241390/webrev.00/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8241390 >> >> Testing: :jdk_instrument, tier1-tier3, and tier5 tests pass. > > Daniil Titov has updated the pull request incrementally with one additional commit since the last revision: > > Corrected test summary Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/190 From zgu at openjdk.java.net Fri Sep 18 17:08:33 2020 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 18 Sep 2020 17:08:33 GMT Subject: RFR: 8253361: Shenandoah: runtime barrier does not honor ShenandoahSelfFixing flag [v2] In-Reply-To: <7PdDOV4J-28DYlN004jvt14GEGZrKy62azlw5PO6J30=.0912c310-1d65-46f1-8d42-701fb5d3a4e3@github.com> References: <7PdDOV4J-28DYlN004jvt14GEGZrKy62azlw5PO6J30=.0912c310-1d65-46f1-8d42-701fb5d3a4e3@github.com> Message-ID: > ShenandoahSelfFixing flag is currently only honored by C2, not runtime barrier. Runtime barrier should check the check > too. Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'JDK-8253361' of github.com:zhengyu123/jdk into JDK-8253361 - Honor ShenandoahSelfFixing flag in runtime barrier - Tighten recusive reserveration handling - Fix trailing whitespace - Restore assertion - JDK-8252921 - JDK-8252921 - Honor ShenandoahSelfFixing flag in runtime barrier ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/254/files - new: https://git.openjdk.java.net/jdk/pull/254/files/739124ff..953e9173 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=254&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=254&range=00-01 Stats: 7549 lines in 261 files changed: 3641 ins; 3125 del; 783 mod Patch: https://git.openjdk.java.net/jdk/pull/254.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/254/head:pull/254 PR: https://git.openjdk.java.net/jdk/pull/254 From burban at openjdk.java.net Fri Sep 18 18:41:13 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Fri, 18 Sep 2020 18:41:13 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: Message-ID: <1ZhTsmFbjf-c4lddQG53Y-D1PieCcxEOGBKe-CkpGAo=.8be414f0-d0a0-48d9-8be7-82615f733233@github.com> On Fri, 18 Sep 2020 15:34:26 GMT, Erik Joelsson wrote: >> Build changes look good to me. I will take this branch for a spin. > > Our linux-aarch64 build fails with this: > cc: error: unrecognized command line option '-std=c++14' > when compiling build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch > > I'm trying to configure a windows-aarch64 build, but it fails on fixpath. Is this something you are also experiencing, > and if so, how are you addressing it? Hey @erikj79, thank you so much for giving it a try! > Our linux-aarch64 build fails with this: > cc: error: unrecognized command line option '-std=c++14' > when compiling build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch Hmm, that's interesting. What environment is that exactly? What `configure` line are you using there? We have tested on such a system: $ cat /etc/issue Ubuntu 19.10 \n \l $ bash configure --with-boot-jdk=/home/beurba/work/jdk-16+13 --with-jtreg $ make clean CONF=linux-aarch64-server-release $ make images JOBS=255 LOG=info CONF=linux-aarch64-server-release $ ./build/linux-aarch64-server-release/images/jdk/bin/java -XshowSettings:properties -version 2>&1 | grep aarch64 java.home = /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk os.arch = aarch64 sun.boot.library.path = /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk/lib -------------------------------------------------------- > I'm trying to configure a windows-aarch64 build, but it fails on fixpath. Is this something you are also experiencing, > and if so, how are you addressing it? Yes. As far as I understand, the problem is that `fixpath.exe` isn't built properly when doing cross-compiling on Windows targets (as it hasn't been a thing so far). We use a workaround internally https://gist.github.com/lewurm/c099a4b5fcd8a182510cbdeebcb41f77 , but a proper solution is under discussion on build-dev: https://mail.openjdk.java.net/pipermail/build-dev/2020-July/027872.html ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From zgu at openjdk.java.net Fri Sep 18 19:07:50 2020 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 18 Sep 2020 19:07:50 GMT Subject: RFR: 8253361: Shenandoah: runtime barrier does not honor ShenandoahSelfFixing flag [v2] In-Reply-To: References: <7PdDOV4J-28DYlN004jvt14GEGZrKy62azlw5PO6J30=.0912c310-1d65-46f1-8d42-701fb5d3a4e3@github.com> Message-ID: On Fri, 18 Sep 2020 16:14:57 GMT, Roman Kennke wrote: >> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev >> excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since >> the last revision: >> - Merge branch 'JDK-8253361' of github.com:zhengyu123/jdk into JDK-8253361 >> - Honor ShenandoahSelfFixing flag in runtime barrier >> - Tighten recusive reserveration handling >> - Fix trailing whitespace >> - Restore assertion >> - JDK-8252921 >> - JDK-8252921 >> - Honor ShenandoahSelfFixing flag in runtime barrier > > There seems to be a lot of unrelated changes in that patch, all that thread/NMT stuff... Messed up with branching, will re-do. ------------- PR: https://git.openjdk.java.net/jdk/pull/254 From zgu at openjdk.java.net Fri Sep 18 19:07:50 2020 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 18 Sep 2020 19:07:50 GMT Subject: Withdrawn: 8253361: Shenandoah: runtime barrier does not honor ShenandoahSelfFixing flag In-Reply-To: <7PdDOV4J-28DYlN004jvt14GEGZrKy62azlw5PO6J30=.0912c310-1d65-46f1-8d42-701fb5d3a4e3@github.com> References: <7PdDOV4J-28DYlN004jvt14GEGZrKy62azlw5PO6J30=.0912c310-1d65-46f1-8d42-701fb5d3a4e3@github.com> Message-ID: On Fri, 18 Sep 2020 16:03:20 GMT, Zhengyu Gu wrote: > ShenandoahSelfFixing flag is currently only honored by C2, not runtime barrier. Runtime barrier should check the check > too. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/254 From dcubed at openjdk.java.net Fri Sep 18 19:48:05 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 18 Sep 2020 19:48:05 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 19:51:24 GMT, Robbin Ehn wrote: >> This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes >> are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) >> Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an >> arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a >> singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first >> pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first >> pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake >> operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything >> except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed >> filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake >> operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there >> is now only one method to call when handshaking one thread. Some comments about the changes: >> - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake >> all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much >> worse then this. >> >> - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that >> thread. >> >> - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a >> handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. >> >> - Added WB testing method. >> >> - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. >> >> - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. >> >> - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a >> safepoint and half of them after, in many handshake all operations. >> >> - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. >> >> - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the >> moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. >> >> - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. >> >> - Added filtered queue and gtest for it. >> >> Passes multiple t1-8 runs. >> Been through some pre-reviwing. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Removed double check, fix comment, removed not needed function, updated logs src/hotspot/share/prims/jvmtiEnvBase.cpp line 653: > 651: JvmtiEnvBase::get_current_contended_monitor(JavaThread *calling_thread, JavaThread *java_thread, > jobject *monitor_ptr) { 652: Thread *current_thread = Thread::current(); > 653: assert(java_thread->is_handshake_safe_for(current_thread), I like how this assert reads now! ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From erikj at openjdk.java.net Fri Sep 18 20:37:45 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 18 Sep 2020 20:37:45 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 20:26:10 GMT, Monica Beckwith wrote: > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 make/autoconf/toolchain.m4 line 902: > 900: BUILD_DEVKIT_TOOLCHAIN_PATH="$BUILD_DEVKIT_ROOT/bin" > 901: fi > 902: UTIL_PREPEND_TO_PATH([PATH],$BUILD_DEVKIT_TOOLCHAIN_PATH) Here is a problem. In our linux cross compile build, we rely on the PATH being completely overwritten with the paths from the devkit here. Otherwise the UTIL_REQUIRE_PROGS may find /usr/bin/cc before $BUILD_DEVKIT_TOOLCHAIN_PATH/gcc. This is the reason my linux-aarch64 (cross compile) build failed. The system installed cc was too old to recognize the -stdc=c++14 argument. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From erikj at openjdk.java.net Fri Sep 18 20:37:45 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 18 Sep 2020 20:37:45 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 20:32:36 GMT, Erik Joelsson wrote: >> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > make/autoconf/toolchain.m4 line 902: > >> 900: BUILD_DEVKIT_TOOLCHAIN_PATH="$BUILD_DEVKIT_ROOT/bin" >> 901: fi >> 902: UTIL_PREPEND_TO_PATH([PATH],$BUILD_DEVKIT_TOOLCHAIN_PATH) > > Here is a problem. In our linux cross compile build, we rely on the PATH being completely overwritten with the paths > from the devkit here. Otherwise the UTIL_REQUIRE_PROGS may find /usr/bin/cc before $BUILD_DEVKIT_TOOLCHAIN_PATH/gcc. > This is the reason my linux-aarch64 (cross compile) build failed. The system installed cc was too old to recognize > the -stdc=c++14 argument. I assume you need the rest of the PATH on Windows. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From dcubed at openjdk.java.net Fri Sep 18 21:01:00 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 18 Sep 2020 21:01:00 GMT Subject: RFR: 8238761: Asynchronous handshakes [v2] In-Reply-To: References: Message-ID: <-G5jT6J3J3UQwMRtEB9-PCvPtyZKNLI6wwtCFg6pUDI=.c669352c-ac48-4eac-a1e2-6c86ec32b894@github.com> On Thu, 17 Sep 2020 12:07:15 GMT, Robbin Ehn wrote: >> This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes >> are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) >> Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an >> arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a >> singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first >> pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first >> pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake >> operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything >> except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed >> filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake >> operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there >> is now only one method to call when handshaking one thread. Some comments about the changes: >> - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake >> all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much >> worse then this. >> >> - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that >> thread. >> >> - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a >> handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. >> >> - Added WB testing method. >> >> - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. >> >> - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. >> >> - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a >> safepoint and half of them after, in many handshake all operations. >> >> - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. >> >> - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the >> moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. >> >> - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. >> >> - Added filtered queue and gtest for it. >> >> Passes multiple t1-8 runs. >> Been through some pre-reviwing. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixed double checks > Added NSV > ProcessResult to enum > Fixed logging > Moved _active_handshaker to private src/hotspot/share/prims/jvmtiEventController.cpp line 340: > 338: } else { > 339: Handshake::execute(&hs, target); > 340: } This guarantee() that the handshake has executed doesn't have an equivalent in the rewritten code. Should there be some way of verifying this condition from this location? ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From dcubed at openjdk.java.net Fri Sep 18 21:00:59 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 18 Sep 2020 21:00:59 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 19:51:24 GMT, Robbin Ehn wrote: >> This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes >> are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) >> Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an >> arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a >> singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first >> pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first >> pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake >> operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything >> except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed >> filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake >> operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there >> is now only one method to call when handshaking one thread. Some comments about the changes: >> - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake >> all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much >> worse then this. >> >> - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that >> thread. >> >> - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a >> handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. >> >> - Added WB testing method. >> >> - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. >> >> - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. >> >> - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a >> safepoint and half of them after, in many handshake all operations. >> >> - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. >> >> - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the >> moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. >> >> - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. >> >> - Added filtered queue and gtest for it. >> >> Passes multiple t1-8 runs. >> Been through some pre-reviwing. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Removed double check, fix comment, removed not needed function, updated logs Thumbs up. I don't think I have anything that is in the must fix category. src/hotspot/share/prims/jvmtiEnvBase.cpp line 691: > 689: // Note: > 690: // calling_thread is the thread that requested the list of monitors for java_thread. > 691: // java_thread is thread owning the monitors. s/is thread/is the thread/ src/hotspot/share/prims/jvmtiEnvBase.cpp line 692: > 690: // calling_thread is the thread that requested the list of monitors for java_thread. > 691: // java_thread is thread owning the monitors. > 692: // current_thread is thread executint this code, can be a non-JavaThread (e.g. VM Thread). typo - s/executint/executing/ grammar - s/e.g./e.g.,/ src/hotspot/share/prims/jvmtiEnvBase.cpp line 693: > 691: // java_thread is thread owning the monitors. > 692: // current_thread is thread executint this code, can be a non-JavaThread (e.g. VM Thread). > 693: // And they all maybe different threads. typo - (in this context) - s/maybe/may be/ src/hotspot/share/prims/jvmtiEnvBase.hpp line 341: > 339: class JvmtiHandshakeClosure : public HandshakeClosure { > 340: protected: > 341: jvmtiError _result; Thanks for pushing the jvmtiError into common code for JVM/TI handshakes. src/hotspot/share/runtime/handshake.hpp line 108: > 106: _processed, > 107: _succeed, > 108: _number_states Why are these indented by 4 spaces instead of 2 spaces? src/hotspot/share/runtime/handshake.cpp line 70: > 68: : HandshakeOperation(cl, target), _start_time_ns(start_ns) {} > 69: virtual ~AsyncHandshakeOperation() { delete _handshake_cl; }; > 70: jlong start_time() { return _start_time_ns; } Should this be 'const'? Ignore it if it would fan out too much. src/hotspot/share/runtime/handshake.cpp line 349: > 347: target->handshake_state()->add_operation(op); > 348: } else { > 349: log_handshake_info(start_time_ns, op->name(), 0, 0, "(thread dead)"); It might be useful to also log the 'target' thread value here so: .... (thread= is dead)" Might be something like this: log_handshake_info(start_time_ns, op->name(), 0, 0, "(thread=" INTPTR_FORMAT " is dead)", p2i(target)); Although you'd probably have to form the string in a buffer and then pass it to the log_handshake_info() call... sigh... src/hotspot/share/runtime/handshake.cpp line 450: > 448: return false; > 449: } > 450: // Operations are added without lock and then the poll is armed. s/without lock/lock free/ src/hotspot/share/runtime/handshake.cpp line 479: > 477: } > 478: > 479: // If we own the mutex at this point and while owning the mutex grammar - s/owning the mutex/owning the mutex we/ src/hotspot/share/runtime/interfaceSupport.inline.hpp line 157: > 155: > 156: // Threads shouldn't block if they are in the middle of printing, but... > 157: ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); Can you explain why you had to add this? Did something show up in testing? src/hotspot/share/runtime/thread.cpp line 487: > 485: assert(!thread->is_Java_thread() || > 486: ((JavaThread *) thread)->is_handshake_safe_for(Thread::current()) || > 487: !((JavaThread *) thread)->on_thread_list() || Should use "thread->as_Java_thread()" instead of the cast here (2 places). src/hotspot/share/runtime/thread.hpp line 1360: > 1358: bool is_handshake_safe_for(Thread* th) const { > 1359: return _handshake.active_handshaker() == th || > 1360: this == th; I _think_ L1359-60 will fit on one line... src/hotspot/share/utilities/filterQueue.inline.hpp line 35: > 33: FilterQueueNode* head; > 34: FilterQueueNode* insnode = new FilterQueueNode(data); > 35: SpinYield yield(SpinYield::default_spin_limit * 10); // Very unlikely with mutiple failed CAS. Typo - s/mutiple/multiple/ src/hotspot/share/utilities/filterQueue.inline.hpp line 76: > 74: return (E)NULL; > 75: } > 76: SpinYield yield(SpinYield::default_spin_limit * 10); // Very unlikely with mutiple failed CAS. typo - s/mutiple/multiple/ src/hotspot/share/prims/whitebox.cpp line 2032: > 2030: void do_thread(Thread* th) { > 2031: assert(th->is_Java_thread(), "sanity"); > 2032: JavaThread* jt = (JavaThread*)th; Can whitebox.cpp code use the new as_Java_thread() call? src/hotspot/share/prims/whitebox.cpp line 2033: > 2031: assert(th->is_Java_thread(), "sanity"); > 2032: JavaThread* jt = (JavaThread*)th; > 2033: ResourceMark rm; It also might be interesting to print the "current thread" info here so that someone looking at the test output knows which thread handled the handshake (the target or a surrogate). src/hotspot/share/runtime/handshake.hpp line 45: > 43: // a single target/direct handshake or not, by the JavaThread that requested the > 44: // handshake or the VMThread respectively. > 45: class HandshakeClosure : public ThreadClosure, public CHeapObj { Just to be clear. You haven't added support for a handshake that must only be executed by the target thread yet, right? That's future work, if I remember correctly... ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/151 From kbarrett at openjdk.java.net Fri Sep 18 21:06:45 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 18 Sep 2020 21:06:45 GMT Subject: RFR: 8253167: ARM32 builds fail after JDK-8247910 Message-ID: Please review this fix for a build failure for arm32. nconstexpr functions cannot contain asm statements (until C++20), even if not executed by a constexpr invocation. This means assert (for example) can't be used in a constexpr function on arm32, because of the implementation of the BREAKPOINT macro as an asm statement for linux-arm. The current arm32 implementation is from JDK-8077648: "ARM: BREAKPOINT is wrong for thumb", which is a Confidential bug about Oracle's old closed source arm32 port. That port was open sourced by JDK-8168503: "JEP 297: Unified arm32/arm64 Port". The discussion of JDK-8077648 suggested making the arm32 port be like nearly all others. That is, have BREAKPOINT expand to a call to ::breakpoint(), with any empty body for that function and a comment that one should use a debugger to set a breakpoint there. This change takes that alternative approach. The same problem likely exists for win32, which also implements BREAKPOINT as an asm statement. However, I don't have the infrastructure to do a win32 build to demonstrate that. But I'm making a similar change there on spec. Note that the Windows implementation of ::breakpoint() ultimately calls the DebugBreak Win32 library function. That should work for the windows-x86 port too. I don't know why we have that difference of some platforms having an affirmative platform-specific breakpoint operation in place while others require a debugger to set one, but that difference already exists. This change does move arm32 from the former to the latter camp though. I'm guessing that won't matter; if it does then we'll need to conditionalize the body of ::breakpoint(). There may be some further cleanup that could be done after this change. We don't really need the BREAKPOINT macro anymore, and could just use ::breakpoint() directly. But I think that's out of scope for dealing with the build failure(s). Testing: build linux-arm. tier1 for Oracle supported platforms. ------------- Commit messages: - remove BREAKPOINT variants Changes: https://git.openjdk.java.net/jdk/pull/259/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=259&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253167 Stats: 19 lines in 2 files changed: 0 ins; 18 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/259.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/259/head:pull/259 PR: https://git.openjdk.java.net/jdk/pull/259 From coleenp at openjdk.java.net Fri Sep 18 21:19:21 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 18 Sep 2020 21:19:21 GMT Subject: RFR: 8253167: ARM32 builds fail after JDK-8247910 In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 20:52:40 GMT, Kim Barrett wrote: > Please review this fix for a build failure for arm32. > > nconstexpr functions cannot contain asm statements (until C++20), even if > not executed by a constexpr invocation. This means assert (for example) > can't be used in a constexpr function on arm32, because of the > implementation of the BREAKPOINT macro as an asm statement for linux-arm. > > The current arm32 implementation is from JDK-8077648: "ARM: BREAKPOINT is > wrong for thumb", which is a Confidential bug about Oracle's old closed > source arm32 port. That port was open sourced by JDK-8168503: "JEP 297: > Unified arm32/arm64 Port". The discussion of JDK-8077648 suggested making > the arm32 port be like nearly all others. That is, have BREAKPOINT expand to > a call to ::breakpoint(), with any empty body for that function and a > comment that one should use a debugger to set a breakpoint there. > > This change takes that alternative approach. > > The same problem likely exists for win32, which also implements BREAKPOINT > as an asm statement. However, I don't have the infrastructure to do a win32 > build to demonstrate that. But I'm making a similar change there on spec. > > Note that the Windows implementation of ::breakpoint() ultimately calls the > DebugBreak Win32 library function. That should work for the windows-x86 port > too. > > I don't know why we have that difference of some platforms having an > affirmative platform-specific breakpoint operation in place while others > require a debugger to set one, but that difference already exists. This > change does move arm32 from the former to the latter camp though. I'm > guessing that won't matter; if it does then we'll need to conditionalize the > body of ::breakpoint(). > > There may be some further cleanup that could be done after this change. > We don't really need the BREAKPOINT macro anymore, and could just > use ::breakpoint() directly. But I think that's out of scope for dealing > with the build failure(s). > > Testing: > build linux-arm. > tier1 for Oracle supported platforms. Looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/259 From mikael at openjdk.java.net Fri Sep 18 21:28:48 2020 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 18 Sep 2020 21:28:48 GMT Subject: RFR: 8253167: ARM32 builds fail after JDK-8247910 In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 20:52:40 GMT, Kim Barrett wrote: > Please review this fix for a build failure for arm32. > > nconstexpr functions cannot contain asm statements (until C++20), even if > not executed by a constexpr invocation. This means assert (for example) > can't be used in a constexpr function on arm32, because of the > implementation of the BREAKPOINT macro as an asm statement for linux-arm. > > The current arm32 implementation is from JDK-8077648: "ARM: BREAKPOINT is > wrong for thumb", which is a Confidential bug about Oracle's old closed > source arm32 port. That port was open sourced by JDK-8168503: "JEP 297: > Unified arm32/arm64 Port". The discussion of JDK-8077648 suggested making > the arm32 port be like nearly all others. That is, have BREAKPOINT expand to > a call to ::breakpoint(), with any empty body for that function and a > comment that one should use a debugger to set a breakpoint there. > > This change takes that alternative approach. > > The same problem likely exists for win32, which also implements BREAKPOINT > as an asm statement. However, I don't have the infrastructure to do a win32 > build to demonstrate that. But I'm making a similar change there on spec. > > Note that the Windows implementation of ::breakpoint() ultimately calls the > DebugBreak Win32 library function. That should work for the windows-x86 port > too. > > I don't know why we have that difference of some platforms having an > affirmative platform-specific breakpoint operation in place while others > require a debugger to set one, but that difference already exists. This > change does move arm32 from the former to the latter camp though. I'm > guessing that won't matter; if it does then we'll need to conditionalize the > body of ::breakpoint(). > > There may be some further cleanup that could be done after this change. > We don't really need the BREAKPOINT macro anymore, and could just > use ::breakpoint() directly. But I think that's out of scope for dealing > with the build failure(s). > > Testing: > build linux-arm. > tier1 for Oracle supported platforms. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/259 From dcubed at openjdk.java.net Fri Sep 18 21:40:40 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 18 Sep 2020 21:40:40 GMT Subject: RFR: 8212107: VMThread issues and cleanup In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 19:58:02 GMT, Robbin Ehn wrote: > We simplify the vmThread by removing the queue and refactor the the main loop. > This solves the issues listed: > - It can create an extra safepoint directly after a safepoint. > - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. > - The exposure of the vm operation is dangerous if it's a handshake. > - The code is a hornets nest with the repetition of checks and branches > > Passes t1-8, and a benchmark run. > > If you want a smaller diff the commits contains the incremental progress and each commit passed t1. I probably should have waited to review this after all of Aleksey's comments were resolved. I'm gonna have to take a look at src/hotspot/share/runtime/vmThread.cpp again via a webrev; it's just too hard to review via this snippet UI. I'll re-review after all of Aleksey's changes are done. src/hotspot/share/runtime/vmThread.hpp line 115: > 113: // Performance measurement > 114: static PerfCounter* perf_accumulated_vm_operation_time() > 115: { return _perf_accumulated_vm_operation_time; } Why was this broken into two lines? If keeping that, then the '{' belong on L114 at the end and not on L115. src/hotspot/share/runtime/vmThread.cpp line 240: > 238: { > 239: MonitorLocker ml(_terminate_lock, Mutex::_no_safepoint_check_flag); > 240: while(!VMThread::is_terminated()) { Not your bug, but can you add a space before the '('? ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From dcubed at openjdk.java.net Fri Sep 18 21:40:41 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 18 Sep 2020 21:40:41 GMT Subject: RFR: 8212107: VMThread issues and cleanup In-Reply-To: <0nRBJII0rpZNU7YnTSqJ5qrxpQv75Ouzw4y3MPNqyCQ=.07e8d0b4-740e-448e-b690-b7ca0c1a7b6a@github.com> References: <0nRBJII0rpZNU7YnTSqJ5qrxpQv75Ouzw4y3MPNqyCQ=.07e8d0b4-740e-448e-b690-b7ca0c1a7b6a@github.com> Message-ID: On Fri, 18 Sep 2020 09:14:32 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/vmThread.cpp line 222: >> >>> 220: void VMThread::wait_for_vm_thread_exit() { >>> 221: assert(Thread::current()->is_Java_thread(), "Should be a JavaThread"); >>> 222: assert(((JavaThread*)Thread::current())->is_terminated(), "Should be terminated"); >> >> Looks like just `assert(JavaThread::current()->is_terminated(), "Should be terminated")`. > > Fixing And delete the assert on L221. ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From github.com+70893615+jasontatton-aws at openjdk.java.net Fri Sep 18 23:14:30 2020 From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton) Date: Fri, 18 Sep 2020 23:14:30 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> <2dlrgVtF5twY9WGHEKS2ZcLEm1jPmGgOfFF6o-ZyUHc=.c33e5814-724a-4569-9eed-97e8afaaa440@github.com> Message-ID: On Fri, 18 Sep 2020 16:31:23 GMT, Andrew Dinn wrote: > Can you explain where this restricted effect is documented? Certainly! I?ve found that determining the capability of the CPU and whether to enable AVX2 support if the chip supports it is mostly controlled in: [vm_version_x86.cpp]( https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp) specifically: [get_processor_features](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L684-L755) and in [generate_get_cpu_info]( https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L69-L611). In order to test the patch comprehensively I had to track down an Intel Core i7 (I7-9750H) processor which the aforementioned code permitted AVX2 instructions for (maybe this is an error and it should not be enabled for this processor though) as most of the infrastructure I personally use here at AWS runs on Intel Xeon processors - I also tested on a E5-2680 which the JVM does not enable AVX2 for. However, this is just the Intel side of things. When it comes to AMD I read that the AMD Zen 2 architecture, of which the current flagship: Threadripper 3990X, is based, is able to support AVX2 [without the frequency scaling]( https://www.anandtech.com/Show/Index/14525?cPage=7&all=False&sort=0&page=9&slug=amd-zen-2-microarchitecture-analysis-ryzen-3000-and-epyc-rome) which some/all(?) of the Intel chips incur. I personally don?t have access to one of these chips so I cannot confirm how it is classified in the JVM. Also, I found when investigating this that there is actually a JVM flag which can be used to control what level of AVX is enabled: `-XX:UseAVX=version.` ------------- PR: https://git.openjdk.java.net/jdk/pull/71 From bulasevich at openjdk.java.net Sat Sep 19 07:50:24 2020 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Sat, 19 Sep 2020 07:50:24 GMT Subject: Integrated: 8252311: AArch64: save two words in itable lookup stub In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 15:25:41 GMT, Boris Ulasevich wrote: > The change was reviewed on hotspot-compiler-dev, but I missed the time to complete > the commit to the mercural repo. Can I get it approved once again? > > Issue: [JDK-8252311](https://bugs.openjdk.java.net/browse/JDK-8252311) > > Description: > The interface method lookup stub becomes hot when interface calls > are performed frequently. The stub assembly code can be made > shorter (132->124 bytes) by using a pre-increment instruction variant. > > Review by Andrew Dinn && Andrew Haley: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039818.html > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039833.html > > For the reference, benchmark scores with higher iteration number: > Neoverse Cnt Score Error -> Score Error Units > InvokeInterface.bench 25 6163.804 ? 5.116 -> 6303.035 ? 5.450 ops/ms > InvokeInterface.bench:L1-icache-loads 5 305.408 ? 1.895 -> 272.891 ? 0.750 #/op > InvokeInterface.bench:iTLB-loads 5 221.755 ? 0.990 -> 207.635 ? 0.566 #/op > InvokeInterface.bench:instructions 5 1035.468 ? 2.701 -> 953.466 ? 1.667 #/op This pull request has now been integrated. Changeset: 224a30f1 Author: Boris Ulasevich URL: https://git.openjdk.java.net/jdk/commit/224a30f1 Stats: 30 lines in 1 file changed: 16 ins; 11 del; 3 mod 8252311: AArch64: save two words in itable lookup stub Reviewed-by: adinn, aph ------------- PR: https://git.openjdk.java.net/jdk/pull/189 From aph at redhat.com Sat Sep 19 09:27:36 2020 From: aph at redhat.com (Andrew Haley) Date: Sat, 19 Sep 2020 10:27:36 +0100 Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: Message-ID: On 18/09/2020 11:14, Monica Beckwith wrote: > This is a continuation of > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] It's still wrong, I'm afraid. This is not a full barrier: +#define FULL_MEM_BARRIER atomic_thread_fence(std::memory_order_acq_rel); it is only StoreStore|LoadStore|LoadLoad, but you need StoreLoad as well. It might well be that you get the same DMB ISH instruction, but unless you use a StoreLoad barrier here it's theoretically possible for a compiler to reorder accesses so that a processor sees its own stores before other processors do. (And it's confusing for the reader too.) Use: +#define FULL_MEM_BARRIER atomic_thread_fence(std::memory_order_seq_cst); See here: https://en.cppreference.com/w/cpp/atomic/memory_order memory_order_seq_cst "...plus a single total order exists in which all threads observe all modifications in the same order (see Sequentially-consistent ordering below)" -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Sat Sep 19 10:21:05 2020 From: aph at redhat.com (Andrew Haley) Date: Sat, 19 Sep 2020 11:21:05 +0100 Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: Message-ID: On 18/09/2020 11:14, Monica Beckwith wrote: > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html The diffs in assembler_aarch64.cpp are mostly spurious. Please try this. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -------------- next part -------------- diff --git a/src/hotspot/cpu/aarch64/aarch64-asmtest.py b/src/hotspot/cpu/aarch64/aarch64-asmtest.py index f5a5c6b5aee..43bac8e8142 100644 --- a/src/hotspot/cpu/aarch64/aarch64-asmtest.py +++ b/src/hotspot/cpu/aarch64/aarch64-asmtest.py @@ -12,8 +12,11 @@ class Operand(object): class Register(Operand): def generate(self): - self.number = random.randint(0, 30) - return self + while True: + self.number = random.randint(0, 30) + # r18 is used for TLS on Windows ABI. + if self.number != 18: + return self def astr(self, prefix): return prefix + str(self.number) @@ -36,8 +39,10 @@ class GeneralRegister(Register): class GeneralRegisterOrZr(Register): def generate(self): - self.number = random.randint(0, 31) - return self + while True: + self.number = random.randint(0, 31) + if self.number != 18: + return self def astr(self, prefix = ""): if (self.number == 31): @@ -53,8 +58,10 @@ class GeneralRegisterOrZr(Register): class GeneralRegisterOrSp(Register): def generate(self): - self.number = random.randint(0, 31) - return self + while True: + self.number = random.randint(0, 31) + if self.number != 18: + return self def astr(self, prefix = ""): if (self.number == 31): @@ -1331,7 +1338,7 @@ generate(SpecialCases, [["ccmn", "__ ccmn(zr, zr, 3u, Assembler::LE);", ["st1w", "__ sve_st1w(z0, __ S, p1, Address(r0, 7));", "st1w\t{z0.s}, p1, [x0, #7, MUL VL]"], ["st1b", "__ sve_st1b(z0, __ B, p2, Address(sp, r1));", "st1b\t{z0.b}, p2, [sp, x1]"], ["st1h", "__ sve_st1h(z0, __ H, p3, Address(sp, r8));", "st1h\t{z0.h}, p3, [sp, x8, LSL #1]"], - ["st1d", "__ sve_st1d(z0, __ D, p4, Address(r0, r18));", "st1d\t{z0.d}, p4, [x0, x18, LSL #3]"], + ["st1d", "__ sve_st1d(z0, __ D, p4, Address(r0, r17));", "st1d\t{z0.d}, p4, [x0, x17, LSL #3]"], ["ldr", "__ sve_ldr(z0, Address(sp));", "ldr\tz0, [sp]"], ["ldr", "__ sve_ldr(z31, Address(sp, -256));", "ldr\tz31, [sp, #-256, MUL VL]"], ["str", "__ sve_str(z8, Address(r8, 255));", "str\tz8, [x8, #255, MUL VL]"], From fyang at openjdk.java.net Sun Sep 20 13:53:00 2020 From: fyang at openjdk.java.net (Fei Yang) Date: Sun, 20 Sep 2020 13:53:00 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v4] In-Reply-To: References: Message-ID: > Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com > > This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. > Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 > > Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. > For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. > "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. > > We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. > Patch passed jtreg tier1-3 tests with QEMU system emulator. > Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make > sure that there's no regression. > We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java > We measured the performance benefit with an aarch64 cycle-accurate simulator. > Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. > > For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on > real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is > detected. Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Add sha3 instructions to cpu/aarch64/aarch64-asmtest.py and regenerate the test in assembler_aarch64.cpp:asm_check ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/207/files - new: https://git.openjdk.java.net/jdk/pull/207/files/3e155193..04bdb42e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=02-03 Stats: 474 lines in 2 files changed: 61 ins; 9 del; 404 mod Patch: https://git.openjdk.java.net/jdk/pull/207.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207 PR: https://git.openjdk.java.net/jdk/pull/207 From boris.ulasevich at bell-sw.com Sun Sep 20 14:17:50 2020 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Sun, 20 Sep 2020 17:17:50 +0300 Subject: RFR: 8253167: ARM32 builds fail after JDK-8247910 In-Reply-To: References: Message-ID: Hi, Yes, the change is Ok. It will fix JDK-8213483 by the way. Thanks for doing this! regards, Boris On Sat, Sep 19, 2020 at 12:07 AM Kim Barrett wrote: > > Please review this fix for a build failure for arm32. > > nconstexpr functions cannot contain asm statements (until C++20), even if > not executed by a constexpr invocation. This means assert (for example) > can't be used in a constexpr function on arm32, because of the > implementation of the BREAKPOINT macro as an asm statement for linux-arm. > > The current arm32 implementation is from JDK-8077648: "ARM: BREAKPOINT is > wrong for thumb", which is a Confidential bug about Oracle's old closed > source arm32 port. That port was open sourced by JDK-8168503: "JEP 297: > Unified arm32/arm64 Port". The discussion of JDK-8077648 suggested making > the arm32 port be like nearly all others. That is, have BREAKPOINT expand to > a call to ::breakpoint(), with any empty body for that function and a > comment that one should use a debugger to set a breakpoint there. > > This change takes that alternative approach. > > The same problem likely exists for win32, which also implements BREAKPOINT > as an asm statement. However, I don't have the infrastructure to do a win32 > build to demonstrate that. But I'm making a similar change there on spec. > > Note that the Windows implementation of ::breakpoint() ultimately calls the > DebugBreak Win32 library function. That should work for the windows-x86 port > too. > > I don't know why we have that difference of some platforms having an > affirmative platform-specific breakpoint operation in place while others > require a debugger to set one, but that difference already exists. This > change does move arm32 from the former to the latter camp though. I'm > guessing that won't matter; if it does then we'll need to conditionalize the > body of ::breakpoint(). > > There may be some further cleanup that could be done after this change. > We don't really need the BREAKPOINT macro anymore, and could just > use ::breakpoint() directly. But I think that's out of scope for dealing > with the build failure(s). > > Testing: > build linux-arm. > tier1 for Oracle supported platforms. > > ------------- > > Commit messages: > - remove BREAKPOINT variants > > Changes: https://git.openjdk.java.net/jdk/pull/259/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=259&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8253167 > Stats: 19 lines in 2 files changed: 0 ins; 18 del; 1 mod > Patch: https://git.openjdk.java.net/jdk/pull/259.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/259/head:pull/259 > > PR: https://git.openjdk.java.net/jdk/pull/259 From kim.barrett at oracle.com Mon Sep 21 00:23:59 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 20 Sep 2020 20:23:59 -0400 Subject: RFR: 8253167: ARM32 builds fail after JDK-8247910 In-Reply-To: References: Message-ID: > On Sep 20, 2020, at 10:17 AM, Boris Ulasevich wrote: > > Hi, > > Yes, the change is Ok. > It will fix JDK-8213483 by the way. > Thanks for doing this! > > regards, > Boris Thanks. From kbarrett at openjdk.java.net Mon Sep 21 00:34:32 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 21 Sep 2020 00:34:32 GMT Subject: Integrated: 8253167: ARM32 builds fail after JDK-8247910 In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 20:52:40 GMT, Kim Barrett wrote: > Please review this fix for a build failure for arm32. > > nconstexpr functions cannot contain asm statements (until C++20), even if > not executed by a constexpr invocation. This means assert (for example) > can't be used in a constexpr function on arm32, because of the > implementation of the BREAKPOINT macro as an asm statement for linux-arm. > > The current arm32 implementation is from JDK-8077648: "ARM: BREAKPOINT is > wrong for thumb", which is a Confidential bug about Oracle's old closed > source arm32 port. That port was open sourced by JDK-8168503: "JEP 297: > Unified arm32/arm64 Port". The discussion of JDK-8077648 suggested making > the arm32 port be like nearly all others. That is, have BREAKPOINT expand to > a call to ::breakpoint(), with any empty body for that function and a > comment that one should use a debugger to set a breakpoint there. > > This change takes that alternative approach. > > The same problem likely exists for win32, which also implements BREAKPOINT > as an asm statement. However, I don't have the infrastructure to do a win32 > build to demonstrate that. But I'm making a similar change there on spec. > > Note that the Windows implementation of ::breakpoint() ultimately calls the > DebugBreak Win32 library function. That should work for the windows-x86 port > too. > > I don't know why we have that difference of some platforms having an > affirmative platform-specific breakpoint operation in place while others > require a debugger to set one, but that difference already exists. This > change does move arm32 from the former to the latter camp though. I'm > guessing that won't matter; if it does then we'll need to conditionalize the > body of ::breakpoint(). > > There may be some further cleanup that could be done after this change. > We don't really need the BREAKPOINT macro anymore, and could just > use ::breakpoint() directly. But I think that's out of scope for dealing > with the build failure(s). > > Testing: > build linux-arm. > tier1 for Oracle supported platforms. This pull request has now been integrated. Changeset: bca9e55b Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/bca9e55b Stats: 19 lines in 2 files changed: 18 ins; 0 del; 1 mod 8253167: ARM32 builds fail after JDK-8247910 8213483: ARM32: runtime/ErrorHandling/ShowRegistersOnAssertTest.java jtreg test fail Removed platform-dependent definitions of BREAKPOINT as asm(breakpoint instruction). Reviewed-by: coleenp, mikael, bulasevich ------------- PR: https://git.openjdk.java.net/jdk/pull/259 From felix.yang at huawei.com Mon Sep 21 02:59:47 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 21 Sep 2020 02:59:47 +0000 Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: <28d501ee-0f96-48e0-bfc4-230721018968@redhat.com> References: <28d501ee-0f96-48e0-bfc4-230721018968@redhat.com> Message-ID: Hi, > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-retn at openjdk.java.net] On Behalf > Of Andrew Haley > Sent: Friday, September 18, 2020 9:48 PM > To: Fei Yang ; hotspot-dev at openjdk.java.net; > security-dev at openjdk.java.net > Subject: Re: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic > > On 17/09/2020 05:26, Fei Yang wrote: > > For now, this feature will not be enabled automatically for aarch64. > > We can auto-enable this when it is fully tested on real hardware. But > > for the above testing purposes, this is auto-enabled when the > corresponding hardware feature is detected. > > Given that there's no real hardware, it's extra-important to add the new > instructions to cpu/aarch64/aarch64-asmtest.py and regenerate the test in > assembler_aarch64.cc:asm_check. I have added on commit in PR resolving this: https://github.com/openjdk/jdk/pull/207/commits/04bdb42e971aa1c2f78bb5c916db62910e167053?file-filters%5B%5D= I grouped SHA512SIMDOp, SHA3SIMDOp and SVEVectorOp after the # ARMv8.2A comment. So anticipate more changes in file assembler_aarch64.cpp. BTW: If this feature is not auto-enabled when the SHA3 hardware feature is there, we will have one failure for the following test: test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java 15 #-----testresult----- 16 description=file\:/home/yangfei/github/jdk/test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java 17 elapsed=31546 0\:00\:31.546 18 end=Mon Sep 21 10\:27\:58 CST 2020 19 environment=regtest 20 execStatus=Failed. Execution failed\: `main' threw exception\: java.lang.AssertionError\: Option 'UseSHA3Intrinsics' is expected to have 'true' value Option 'UseSHA3Intrinsics' should be enabled by default Any suggestions for this? Thanks, Felix From david.holmes at oracle.com Mon Sep 21 03:22:29 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Sep 2020 13:22:29 +1000 Subject: RFR: 8212107: VMThread issues and cleanup In-Reply-To: References: Message-ID: <3114f40f-77ea-d99c-1128-2226144e1fd8@oracle.com> Hi Robbin, On 18/09/2020 6:34 am, Robbin Ehn wrote: > We simplify the vmThread by removing the queue and refactor the the main loop. Can you explain why it was necessary to remove the queue and exactly what it has been replaced with? I'd like to understand the new higher-level design for VMOperation execution rather than trying to reverse engineer it from the code changes. Thanks, David ----- > This solves the issues listed: > - It can create an extra safepoint directly after a safepoint. > - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. > - The exposure of the vm operation is dangerous if it's a handshake. > - The code is a hornets nest with the repetition of checks and branches > > Passes t1-8, and a benchmark run. > > If you want a smaller diff the commits contains the incremental progress and each commit passed t1. > > ------------- > > Commit messages: > - Fixed some indent misses > - Fixed ws > - Added assert > - Restructured and simplified > - Removed used linking in VM_Operation > - Removed ticket and use only one Monitor > - Removed queue > - Basic simplifications, removed prio > > Changes: https://git.openjdk.java.net/jdk/pull/228/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=228&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8212107 > Stats: 431 lines in 7 files changed: 111 ins; 229 del; 91 mod > Patch: https://git.openjdk.java.net/jdk/pull/228.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/228/head:pull/228 > > PR: https://git.openjdk.java.net/jdk/pull/228 > From dholmes at openjdk.java.net Mon Sep 21 04:21:15 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 21 Sep 2020 04:21:15 GMT Subject: RFR: 8253262: Allocate in DumpRegion is not thread safe In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 16:13:39 GMT, Calvin Cheung wrote: >> At CDS dump, the symbols are allocated from _dump_region (DumpRegion) which is global, and not thread safe when >> executed in JavaThread. Add a lock DumpRegoin_lock to guard symbol allocation from it. >> Tests: tier1-4 > > Looks good. It seems to me that the need for locking should be an internal implementation detail of MetaspaceShared::symbol_space_alloc, rather than Symbol operator new. ------------- PR: https://git.openjdk.java.net/jdk/pull/216 From kbarrett at openjdk.java.net Mon Sep 21 04:24:25 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 21 Sep 2020 04:24:25 GMT Subject: RFR: 8247912: Make narrowOop a scoped enum Message-ID: Please review this change to the type narrowOop from a typedef for juint to a scoped enum with uint32_t as the representation type. This provides stronger type checking when using this type. For the most part this was fairly straightforward, and the patch size is relatively small. The implementation of some existing CompressedOops "primitives" required adjustment. An explicit conversion to narrowOop was added, with casts change to use it. There were a few places that were type punning and needed explicit conversions,, mostly in platform-specific assembly support. There are a couple of lingering problems. Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass as a narrowOop. I adjusted the code to accommodate the narrowOop change, but this probably ought to be done differently. There are a couple of `(narrowOop)` casts remaining in s390.ad. I'm not sure whether these can be safely converted to CompressedOops::narrow_oop_cast. There might still be some casts from narrowOop to an integral type. Those are hard to find in our cast-happy code base. Testing: tier1-6 for Oracle supported platforms. Build fastdebug linux-ppc64le and linux-s390x. ------------- Commit messages: - 8247912: Make narrowOop a scoped enum Changes: https://git.openjdk.java.net/jdk/pull/273/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=273&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247912 Stats: 83 lines in 22 files changed: 32 ins; 5 del; 46 mod Patch: https://git.openjdk.java.net/jdk/pull/273.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/273/head:pull/273 PR: https://git.openjdk.java.net/jdk/pull/273 From dholmes at openjdk.java.net Mon Sep 21 06:16:31 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 21 Sep 2020 06:16:31 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 19:51:24 GMT, Robbin Ehn wrote: >> This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes >> are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) >> Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an >> arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a >> singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first >> pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first >> pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake >> operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything >> except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed >> filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake >> operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there >> is now only one method to call when handshaking one thread. Some comments about the changes: >> - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake >> all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much >> worse then this. >> >> - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that >> thread. >> >> - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a >> handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. >> >> - Added WB testing method. >> >> - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. >> >> - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. >> >> - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a >> safepoint and half of them after, in many handshake all operations. >> >> - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. >> >> - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the >> moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. >> >> - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. >> >> - Added filtered queue and gtest for it. >> >> Passes multiple t1-8 runs. >> Been through some pre-reviwing. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Removed double check, fix comment, removed not needed function, updated logs Hi Robbin, There is still a lack of motivation for this feature in the JBS issue. What kind of handshakes need to be asynchronous? Any async operation implies that the requester doesn't care about when or even if, the operation gets executed - they are by definition fire-and-forget actions. So what are the usecases being envisaged here? Many of the changes included here seem unrelated to, and not reliant on, async handshakes, and could be factored out to simplify the review and allow focus on the actual async handshake part e.g. the JVM TI cleanups seem they could be mostly standalone. Specific comments below. A general concern I have is where the current thread is no longer guaranteed to be a JavaThread (which is a step in the wrong direction in relation to some of the cleanups I have planned!) and I can't see why this would be changing. Thanks. src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 320: > 318: op.do_thread(_thread); > 319: } else { > 320: Handshake::execute(&op, _thread); We should still have the guarantee check that the target was alive. src/hotspot/share/prims/jvmtiEventController.cpp line 339: > 337: hs.do_thread(target); > 338: } else { > 339: Handshake::execute(&hs, target); We should still have the guarantee check that the target is still alive. src/hotspot/share/prims/jvmtiEnvBase.cpp line 692: > 690: // calling_thread is the thread that requested the list of monitors for java_thread. > 691: // java_thread is thread owning the monitors. > 692: // current_thread is thread executint this code, can be a non-JavaThread (e.g. VM Thread). Where is the use of the VMThread introduced as I cannot see it? The code was changed to use direct handshakes so that we know that either the caller or the target (both JavaThreads) must be executing it. I don't see any VMOperation added to call this code. src/hotspot/share/runtime/handshake.cpp line 230: > 228: log_trace(handshake)("Threads signaled, begin processing blocked threads by VMThread"); > 229: HandshakeSpinYield hsy(start_time_ns); > 230: int executed_by_driver = 0; driver?? Isn't this still the VMThread? src/hotspot/share/runtime/handshake.cpp line 313: > 311: } > 312: > 313: int executed_by_driver = 0; Again why driver?? Isn't it either the current thread or the target that will execute the op? src/hotspot/share/runtime/handshake.cpp line 453: > 451: // If all handshake operations for the handshakee are finished and someone > 452: // just adds an operation we may see it here. But if the handshakee is not > 453: // armed yet it is not safe to procced. s/procced/proceed/ src/hotspot/share/runtime/handshake.hpp line 44: > 42: // by the target JavaThread itself or, depending on whether the operation is > 43: // a single target/direct handshake or not, by the JavaThread that requested the > 44: // handshake or the VMThread respectively. This comment now indicates that all single target handshakes are executed as direct-handshakes and never by the VMThread - is that correct? src/hotspot/share/runtime/handshake.hpp line 107: > 105: _claim_failed, > 106: _processed, > 107: _succeed, grammatically should be _succeeded src/hotspot/share/runtime/thread.cpp line 481: > 479: #ifdef ASSERT > 480: // A JavaThread is considered "dangling" if it is not the current > 481: // thread, his not handshaking with current thread, as been added the Threads s/his/is/ ? s/as been added the/has been added to the/ But rather than describe all the conditions, few of which are actually visible in the assertion below, why not just rephrase in terms of the conditions checked i.e. // A JavaThread is considered dangling if it not handshake-safe with respect to the current thread, or // it is not on a ThreadsList. The is_handshake_safe_for method should describe all the conditions that make a target handshake safe. src/hotspot/share/runtime/thread.cpp line 851: > 849: bool > 850: JavaThread::is_thread_fully_suspended(bool wait_for_suspend, uint32_t *bits) { > 851: if (this != Thread::current()) { Why/how is a non-JavaThread calling this? src/hotspot/share/runtime/thread.cpp line 2441: > 2439: assert(Thread::current()->is_VM_thread() || > 2440: is_handshake_safe_for(Thread::current()), > 2441: "should be in the vm thread, self or handshakee"); This seems too general. This should either be a VMoperation or a direct handshake, but not both. src/hotspot/share/utilities/filterQueue.hpp line 57: > 55: > 56: // MT-safe > 57: // Since pops and adds are allowed while we add, we do not know if _first is same even if it's the same address. This comment seems out of context on the declaration of add, as it is describing a detail of the implementation - to what are we comparing _first to be the same ?? If you want to just document the MT properties abstractedly then describing this a lock-free would suffice. Though if pop requires locking then it's implementation is also constrained to work with the lock-free version of add. Overall it is unclear how documenting "external serialization needed" actually helps the user of this API. ?? src/hotspot/share/utilities/filterQueue.inline.hpp line 42: > 40: break; > 41: } > 42: yield.wait(); Was the need for spinwaits identified through benchmarking? Do you really expect this to be hot? src/hotspot/share/utilities/filterQueue.inline.hpp line 63: > 61: } > 62: > 63: // MT-Unsafe, external serialization needed. So IIUC this queue supports multiple concurrent add()s, but has to be restricted to a single pop() at a time (although that is allowed to execute concurrently with the add()s) - correct? test/hotspot/jtreg/runtime/handshake/AsyncHandshakeWalkStackTest.java line 30: > 28: * @build AsyncHandshakeWalkStackTest > 29: * @run driver ClassFileInstaller sun.hotspot.WhiteBox > 30: * sun.hotspot.WhiteBox$WhiteBoxPermission This is not needed as ClassFileInstaller already handles WhiteBox's nested classes. test/hotspot/jtreg/runtime/handshake/MixedHandshakeWalkStackTest.java line 30: > 28: * @build MixedHandshakeWalkStackTest > 29: * @run driver ClassFileInstaller sun.hotspot.WhiteBox > 30: * sun.hotspot.WhiteBox$WhiteBoxPermission Not needed - see earlier comment. test/hotspot/jtreg/runtime/handshake/MixedHandshakeWalkStackTest.java line 38: > 36: > 37: public class MixedHandshakeWalkStackTest { > 38: public static Thread tthreads[]; why tthreads? It looks like a typo :) ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From dholmes at openjdk.java.net Mon Sep 21 06:16:33 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 21 Sep 2020 06:16:33 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 20:51:17 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed double check, fix comment, removed not needed function, updated logs > > src/hotspot/share/prims/whitebox.cpp line 2032: > >> 2030: void do_thread(Thread* th) { >> 2031: assert(th->is_Java_thread(), "sanity"); >> 2032: JavaThread* jt = (JavaThread*)th; > > Can whitebox.cpp code use the new as_Java_thread() call? Yes it can. :) > src/hotspot/share/runtime/handshake.hpp line 45: > >> 43: // a single target/direct handshake or not, by the JavaThread that requested the >> 44: // handshake or the VMThread respectively. >> 45: class HandshakeClosure : public ThreadClosure, public CHeapObj { > > Just to be clear. You haven't added support for a handshake that > must only be executed by the target thread yet, right? That's > future work, if I remember correctly... AsyncHandshakeClosures have operations that must, by definition, be executed by the target thread (if they are executed at all). > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 157: > >> 155: >> 156: // Threads shouldn't block if they are in the middle of printing, but... >> 157: ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); > > Can you explain why you had to add this? > Did something show up in testing? Yes please explain as this looks really bad. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From dholmes at openjdk.java.net Mon Sep 21 06:16:34 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 21 Sep 2020 06:16:34 GMT Subject: RFR: 8238761: Asynchronous handshakes [v2] In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 12:07:15 GMT, Robbin Ehn wrote: >> This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes >> are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) >> Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an >> arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a >> singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first >> pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first >> pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake >> operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything >> except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed >> filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake >> operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there >> is now only one method to call when handshaking one thread. Some comments about the changes: >> - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake >> all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much >> worse then this. >> >> - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that >> thread. >> >> - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a >> handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. >> >> - Added WB testing method. >> >> - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. >> >> - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. >> >> - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a >> safepoint and half of them after, in many handshake all operations. >> >> - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. >> >> - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the >> moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. >> >> - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. >> >> - Added filtered queue and gtest for it. >> >> Passes multiple t1-8 runs. >> Been through some pre-reviwing. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Fixed double checks > Added NSV > ProcessResult to enum > Fixed logging > Moved _active_handshaker to private src/hotspot/share/runtime/handshake.cpp line 336: > 334: // and thus prevents reading stale data modified in the handshake closure > 335: // by the Handshakee. > 336: OrderAccess::acquire(); How/why is this deleted? Surely there are still single-thread VMops that use a handshake?? src/hotspot/share/runtime/interfaceSupport.inline.hpp line 136: > 134: assert(_thread->thread_state() == _thread_in_vm, "should only call when leaving VM after handshake"); > 135: > 136: _thread->set_thread_state(_original_state); Can you clarify why this is no longer needed? What states can we be returning to? ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From david.holmes at oracle.com Mon Sep 21 06:33:39 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Sep 2020 16:33:39 +1000 Subject: RFR: 8238761: Asynchronous handshakes [v2] In-Reply-To: References: Message-ID: <9cb8feec-e50e-504e-4775-8dba8ed82f17@oracle.com> Correction ... On 21/09/2020 4:16 pm, David Holmes wrote: > On Thu, 17 Sep 2020 12:07:15 GMT, Robbin Ehn wrote: > >>> This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes >>> are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) >>> Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an >>> arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a >>> singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first >>> pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first >>> pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake >>> operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything >>> except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed >>> filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake >>> operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there >>> is now only one method to call when handshaking one thread. Some comments about the changes: >>> - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake >>> all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much >>> worse then this. >>> >>> - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that >>> thread. >>> >>> - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a >>> handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. >>> >>> - Added WB testing method. >>> >>> - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. >>> >>> - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. >>> >>> - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a >>> safepoint and half of them after, in many handshake all operations. >>> >>> - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. >>> >>> - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the >>> moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. >>> >>> - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. >>> >>> - Added filtered queue and gtest for it. >>> >>> Passes multiple t1-8 runs. >>> Been through some pre-reviwing. >> >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed double checks >> Added NSV >> ProcessResult to enum >> Fixed logging >> Moved _active_handshaker to private > > src/hotspot/share/runtime/handshake.cpp line 336: > >> 334: // and thus prevents reading stale data modified in the handshake closure >> 335: // by the Handshakee. >> 336: OrderAccess::acquire(); > > How/why is this deleted? Surely there are still single-thread VMops that use a handshake?? That comment was placed against the old line 336 which was the deletion of this method: bool Handshake::execute(HandshakeClosure* thread_cl, JavaThread* target) { (I'll file a skara/git bug). David ----- > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 136: > >> 134: assert(_thread->thread_state() == _thread_in_vm, "should only call when leaving VM after handshake"); >> 135: >> 136: _thread->set_thread_state(_original_state); > > Can you clarify why this is no longer needed? What states can we be returning to? > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/151 > From mbeckwit at openjdk.java.net Mon Sep 21 07:14:52 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Mon, 21 Sep 2020 07:14:52 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v2] In-Reply-To: References: Message-ID: <9ex1cWVOzjYIl9WtLrMt_hGrAQDKPNu5afUME7dfM9o=.e5cee81f-4bd6-4896-bd90-f713585bff37@github.com> > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains six new commits since the last revision: - 8248787: G1: Workaround MSVC bug Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248670: Windows: Exception handling support on AArch64 Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248660: AArch64: Make _clear_cache and _nop portable Summary: __builtin___clear_cache, etc. Contributed-by: mbeckwit, luhenry, burban - 8248659: AArch64: Extend CPU Feature detection Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248656: Add Windows AArch64 platform support code Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248498: Add build system support for Windows AArch64 Reviewed-by: Contributed-by: mbeckwit, luhenry, burban ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/212/files - new: https://git.openjdk.java.net/jdk/pull/212/files/26e4af3a..5f9b0d35 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From burban at openjdk.java.net Mon Sep 21 07:14:52 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Mon, 21 Sep 2020 07:14:52 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v2] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 20:34:55 GMT, Erik Joelsson wrote: > I assume you need the rest of the PATH on Windows. Doesn't look like it actually. I've reverted it, thanks for catching it. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From iklam at openjdk.java.net Mon Sep 21 07:22:00 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 21 Sep 2020 07:22:00 GMT Subject: RFR: 8253402: Convert vmSymbols::SID to enum class Message-ID: Convert `vmSymbols::SID` to an `enum class` to provide better type safety. - The original enum type `vmSymbols::SID` cannot be forward-declared. I moved it out of the `vmSymbols` class and renamed, so now it can be forward-declared as `enum class vmSymbolID : int;`, without including the large vmSymbols.hpp file. - This also breaks the mutual dependency between the `vmSymbols` and `vmIntrinsics` classes. Now the declaration of `vmIntrinsics` can be moved from vmSymbols.hpp to vmIntrinsics.hpp, where it naturally belongs. - Type-safe enumeration (contributed by Kim Barrett) for (vmSymbolID index : vmSymbolsIterator()) { vm_symbol_index[as_int(index)] = index; } - I moved `vmSymbols::_symbols[]` to `Symbol::_vm_symbols[]`, and made it accessible via `Symbol::vm_symbol_at()`. This way, header files (e.g. fieldInfo.hpp) that need to convert from `vmSymbolID` to `Symbol*` don't need to include the large vmSymbols.hpp file. - I changed the `VM_SYMBOL_ENUM_NAME` macro so that the users don't need to explicitly add the `vmSymbolID::` scope. - I removed many unnecessary casts between `int` and `vmSymbolID`. - The remaining casts are done via `vmSymbol::as_int()` and `vmSymbols::as_SID()` with range checks. ----- If this is successful, I will do the same for `vmIntrinsics::ID`. ------------- Commit messages: - clean up whitespaces and removed useless comment - removed unnecessary include - 8253402: Convert vmSymbols::SID to enum class Changes: https://git.openjdk.java.net/jdk/pull/276/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=276&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253402 Stats: 619 lines in 26 files changed: 304 ins; 143 del; 172 mod Patch: https://git.openjdk.java.net/jdk/pull/276.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/276/head:pull/276 PR: https://git.openjdk.java.net/jdk/pull/276 From rehn at openjdk.java.net Mon Sep 21 07:33:27 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 07:33:27 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v2] In-Reply-To: References: Message-ID: <8KYOSvjbrmDhnP3_WLOu0dO0saiWTHp1SBgE3ikOJkE=.dd9b9e50-2bb5-47cb-a67f-e7c5293ef1d2@github.com> > We simplify the vmThread by removing the queue and refactor the the main loop. > This solves the issues listed: > - It can create an extra safepoint directly after a safepoint. > - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. > - The exposure of the vm operation is dangerous if it's a handshake. > - The code is a hornets nest with the repetition of checks and branches > > Passes t1-8, and a benchmark run. > > If you want a smaller diff the commits contains the incremental progress and each commit passed t1. Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge branch 'master' into 8212107-vmthread - Fixed nits - Merge branch 'master' into 8212107-vmthread - Fixes after review from shipilev. - Fixed some indent misses - Fixed ws - Added assert - Restructured and simplified - Removed used linking in VM_Operation - Removed ticket and use only one Monitor - ... and 2 more: https://git.openjdk.java.net/jdk/compare/10ce2144...e49178a4 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/228/files - new: https://git.openjdk.java.net/jdk/pull/228/files/3866f067..e49178a4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=228&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=228&range=00-01 Stats: 5785 lines in 169 files changed: 3244 ins; 2189 del; 352 mod Patch: https://git.openjdk.java.net/jdk/pull/228.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/228/head:pull/228 PR: https://git.openjdk.java.net/jdk/pull/228 From rehn at openjdk.java.net Mon Sep 21 07:33:30 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 07:33:30 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 21:38:25 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev >> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since >> the last revision: >> - Merge branch 'master' into 8212107-vmthread >> - Fixed nits >> - Merge branch 'master' into 8212107-vmthread >> - Fixes after review from shipilev. >> - Fixed some indent misses >> - Fixed ws >> - Added assert >> - Restructured and simplified >> - Removed used linking in VM_Operation >> - Removed ticket and use only one Monitor >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/ecb5488e...e49178a4 > > I probably should have waited to review this after all of Aleksey's > comments were resolved. I'm gonna have to take a look at > src/hotspot/share/runtime/vmThread.cpp again via a webrev; > it's just too hard to review via this snippet UI. > > I'll re-review after all of Aleksey's changes are done. > Can you explain why it was necessary to remove the queue and exactly > what it has been replaced with? I'd like to understand the new > higher-level design for VMOperation execution rather than trying to > reverse engineer it from the code changes. VM operations now rare and when we do them they are now also faster compared to when the queue was introduced. (I believe way back the VM thread did all compiles in no-safepoint op, safepoint was on the higher prio vs lower prio non-safepoint ops) During a normal execution we do handshakes and safepoints. The handshakes we default do used to be safepoint, there is no reason to threat them with a lower prio. We reach the safepoint much faster nowadays, which means there is very little time to add anything to a queue. And to reach safepoint faster it would be better to stop for the safepoint than adding anything to a queue before stopping. So we replace the queue with a "next safepoint operation". Any other safepoint requester will have their operation on their stack until they succeed to set it as "next safepoint operation". > > Thanks, > David > ----- ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From rehn at openjdk.java.net Mon Sep 21 07:33:33 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 07:33:33 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 09:08:26 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/vmThread.cpp line 355: >> >>> 353: } >>> 354: ml.notify_all(); >>> 355: ml.wait(); >> >> It is really odd to see back-to-back `notify_all` and `wait`. Would that mean two threads sitting in this loop would >> just wake one another continuously? > > This can theoretically be an issue if there is operation set and then two non-JavaThread trying set a operation. > Or if there is a handshake operation set. > > I did not consider this scenario proper. > I think we need two separate Monitors. > Fixing Please go over the changes in fceebea and see if you agree that it is correct :) Passes t1-t8. ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From rehn at openjdk.java.net Mon Sep 21 07:37:07 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 07:37:07 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 21:25:25 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev >> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since >> the last revision: >> - Merge branch 'master' into 8212107-vmthread >> - Fixed nits >> - Merge branch 'master' into 8212107-vmthread >> - Fixes after review from shipilev. >> - Fixed some indent misses >> - Fixed ws >> - Added assert >> - Restructured and simplified >> - Removed used linking in VM_Operation >> - Removed ticket and use only one Monitor >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/2805a31f...e49178a4 > > src/hotspot/share/runtime/vmThread.hpp line 115: > >> 113: // Performance measurement >> 114: static PerfCounter* perf_accumulated_vm_operation_time() >> 115: { return _perf_accumulated_vm_operation_time; } > > Why was this broken into two lines? If keeping that, then > the '{' belong on L114 at the end and not on L115. This line is very long and kept bugging me. Fixed '{'. > src/hotspot/share/runtime/vmThread.cpp line 240: > >> 238: { >> 239: MonitorLocker ml(_terminate_lock, Mutex::_no_safepoint_check_flag); >> 240: while(!VMThread::is_terminated()) { > > Not your bug, but can you add a space before the '('? Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From rehn at openjdk.java.net Mon Sep 21 07:37:07 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 07:37:07 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v2] In-Reply-To: <0nRBJII0rpZNU7YnTSqJ5qrxpQv75Ouzw4y3MPNqyCQ=.07e8d0b4-740e-448e-b690-b7ca0c1a7b6a@github.com> References: <0nRBJII0rpZNU7YnTSqJ5qrxpQv75Ouzw4y3MPNqyCQ=.07e8d0b4-740e-448e-b690-b7ca0c1a7b6a@github.com> Message-ID: On Fri, 18 Sep 2020 09:15:49 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/vmThread.cpp line 427: >> >>> 425: >>> 426: // Notify previous op done >>> 427: mu_queue.notify(); >> >> So, `notify`, not `notifyAll` here? We sure we want to bet who -- of all current waiters -- gets the notification? > > Will be changed, due to above issue. Please go over the changes in fceebea and see if you agree that it is correct :) Passes t1-t8. ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From burban at openjdk.java.net Mon Sep 21 08:18:21 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Mon, 21 Sep 2020 08:18:21 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v2] In-Reply-To: <1ZhTsmFbjf-c4lddQG53Y-D1PieCcxEOGBKe-CkpGAo=.8be414f0-d0a0-48d9-8be7-82615f733233@github.com> References: <1ZhTsmFbjf-c4lddQG53Y-D1PieCcxEOGBKe-CkpGAo=.8be414f0-d0a0-48d9-8be7-82615f733233@github.com> Message-ID: On Fri, 18 Sep 2020 18:38:34 GMT, Bernhard Urban-Forster wrote: >> Our linux-aarch64 build fails with this: >> cc: error: unrecognized command line option '-std=c++14' >> when compiling build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch >> >> I'm trying to configure a windows-aarch64 build, but it fails on fixpath. Is this something you are also experiencing, >> and if so, how are you addressing it? > > Hey @erikj79, thank you so much for giving it a try! > >> Our linux-aarch64 build fails with this: >> cc: error: unrecognized command line option '-std=c++14' >> when compiling build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch > > Hmm, that's interesting. What environment is that exactly? What `configure` line are you using there? We have tested on > such a system: $ cat /etc/issue > Ubuntu 19.10 \n \l > $ bash configure --with-boot-jdk=/home/beurba/work/jdk-16+13 --with-jtreg > $ make clean CONF=linux-aarch64-server-release > $ make images JOBS=255 LOG=info CONF=linux-aarch64-server-release > $ ./build/linux-aarch64-server-release/images/jdk/bin/java -XshowSettings:properties -version 2>&1 | grep aarch64 > java.home = /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk > os.arch = aarch64 > sun.boot.library.path = /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk/lib > -------------------------------------------------------- >> I'm trying to configure a windows-aarch64 build, but it fails on fixpath. Is this something you are also experiencing, >> and if so, how are you addressing it? > > Yes. As far as I understand, the problem is that `fixpath.exe` isn't built properly when doing cross-compiling on > Windows targets (as it hasn't been a thing so far). We use a workaround internally > https://gist.github.com/lewurm/c099a4b5fcd8a182510cbdeebcb41f77 , but a proper solution is under discussion on > build-dev: https://mail.openjdk.java.net/pipermail/build-dev/2020-July/027872.html > _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ > > On 18/09/2020 11:14, Monica Beckwith wrote: > > > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > The diffs in assembler_aarch64.cpp are mostly spurious. Please try this. Thank you Andrew. Is the goal to reduce the patch diff in `assembler_aarch64.cpp`? If so, we need to get rid of the retry in your patch to avoid additional calls to `random`, e.g. something like this (the diff for the generated part would look indeed nicer with that: https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ): --- a/src/hotspot/cpu/aarch64/aarch64-asmtest.py +++ b/src/hotspot/cpu/aarch64/aarch64-asmtest.py @@ -13,6 +13,8 @@ class Register(Operand): def generate(self): self.number = random.randint(0, 30) + if self.number == 18: + self.number = 17 return self def astr(self, prefix): @@ -37,6 +39,8 @@ class GeneralRegisterOrZr(Register): def generate(self): self.number = random.randint(0, 31) + if self.number == 18: + self.number = 16 return self def astr(self, prefix = ""): @@ -54,6 +58,8 @@ class GeneralRegisterOrZr(Register): class GeneralRegisterOrSp(Register): def generate(self): self.number = random.randint(0, 31) + if self.number == 18: + self.number = 15 return self def astr(self, prefix = ""): @@ -1331,7 +1337,7 @@ generate(SpecialCases, [["ccmn", "__ ccmn(zr, zr, 3u, Assembler::LE);", ["st1w", "__ sve_st1w(z0, __ S, p1, Address(r0, 7));", "st1w\t{z0.s}, p1, [x0, #7, MUL VL]"], ["st1b", "__ sve_st1b(z0, __ B, p2, Address(sp, r1));", "st1b\t{z0.b}, p2, [sp, x1]"], ["st1h", "__ sve_st1h(z0, __ H, p3, Address(sp, r8));", "st1h\t{z0.h}, p3, [sp, x8, LSL #1]"], - ["st1d", "__ sve_st1d(z0, __ D, p4, Address(r0, r18));", "st1d\t{z0.d}, p4, [x0, x18, LSL #3]"], + ["st1d", "__ sve_st1d(z0, __ D, p4, Address(r0, r17));", "st1d\t{z0.d}, p4, [x0, x17, LSL #3]"], ["ldr", "__ sve_ldr(z0, Address(sp));", "ldr\tz0, [sp]"], ["ldr", "__ sve_ldr(z31, Address(sp, -256));", "ldr\tz31, [sp, #-256, MUL VL]"], ["str", "__ sve_str(z8, Address(r8, 255));", "str\tz8, [x8, #255, MUL VL]"], ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From rehn at openjdk.java.net Mon Sep 21 08:26:17 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 08:26:17 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 19:46:34 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed double check, fix comment, removed not needed function, updated logs > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 691: > >> 689: // Note: >> 690: // calling_thread is the thread that requested the list of monitors for java_thread. >> 691: // java_thread is thread owning the monitors. > > s/is thread/is the thread/ Fixed > src/hotspot/share/prims/jvmtiEnvBase.cpp line 692: > >> 690: // calling_thread is the thread that requested the list of monitors for java_thread. >> 691: // java_thread is thread owning the monitors. >> 692: // current_thread is thread executint this code, can be a non-JavaThread (e.g. VM Thread). > > typo - s/executint/executing/ > grammar - s/e.g./e.g.,/ Fixed > src/hotspot/share/prims/jvmtiEnvBase.cpp line 693: > >> 691: // java_thread is thread owning the monitors. >> 692: // current_thread is thread executint this code, can be a non-JavaThread (e.g. VM Thread). >> 693: // And they all maybe different threads. > > typo - (in this context) - s/maybe/may be/ Fixed > src/hotspot/share/prims/jvmtiEnvBase.hpp line 341: > >> 339: class JvmtiHandshakeClosure : public HandshakeClosure { >> 340: protected: >> 341: jvmtiError _result; > > Thanks for pushing the jvmtiError into common code for JVM/TI handshakes. Thanks > src/hotspot/share/prims/jvmtiEnvBase.cpp line 653: > >> 651: JvmtiEnvBase::get_current_contended_monitor(JavaThread *calling_thread, JavaThread *java_thread, >> jobject *monitor_ptr) { 652: Thread *current_thread = Thread::current(); >> 653: assert(java_thread->is_handshake_safe_for(current_thread), > > I like how this assert reads now! Great! ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rkennke at openjdk.java.net Mon Sep 21 08:34:44 2020 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 21 Sep 2020 08:34:44 GMT Subject: RFR: 8247912: Make narrowOop a scoped enum In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 04:01:34 GMT, Kim Barrett wrote: > Please review this change to the type narrowOop from a typedef for juint to a > scoped enum with uint32_t as the representation type. This provides stronger > type checking when using this type. > > For the most part this was fairly straightforward, and the patch size is > relatively small. The implementation of some existing CompressedOops > "primitives" required adjustment. An explicit conversion to narrowOop was > added, with casts change to use it. There were a few places that were type > punning and needed explicit conversions,, mostly in platform-specific assembly > support. > > There are a couple of lingering problems. > > Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass > as a narrowOop. I adjusted the code to accommodate the narrowOop change, but > this probably ought to be done differently. > > There are a couple of `(narrowOop)` casts remaining in s390.ad. I'm not sure > whether these can be safely converted to CompressedOops::narrow_oop_cast. > > There might still be some casts from narrowOop to an integral type. Those are > hard to find in our cast-happy code base. > > Testing: > tier1-6 for Oracle supported platforms. > Build fastdebug linux-ppc64le and linux-s390x. I'm not convinced. This reduces readability of the code for little gain IMO. A typedef is the logical C++ construct for something like a narrowOop. An enum class is not, or at least I don't see it. How's a narrowOop an enumeration? The next time somebody uninitiated comes across this declaration, this is going to cause headscratching. I'd rather avoid that. ------------- PR: https://git.openjdk.java.net/jdk/pull/273 From rehn at openjdk.java.net Mon Sep 21 08:41:56 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 08:41:56 GMT Subject: RFR: 8238761: Asynchronous handshakes [v2] In-Reply-To: <-G5jT6J3J3UQwMRtEB9-PCvPtyZKNLI6wwtCFg6pUDI=.c669352c-ac48-4eac-a1e2-6c86ec32b894@github.com> References: <-G5jT6J3J3UQwMRtEB9-PCvPtyZKNLI6wwtCFg6pUDI=.c669352c-ac48-4eac-a1e2-6c86ec32b894@github.com> Message-ID: On Fri, 18 Sep 2020 20:01:02 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed double checks >> Added NSV >> ProcessResult to enum >> Fixed logging >> Moved _active_handshaker to private > > src/hotspot/share/prims/jvmtiEventController.cpp line 340: > >> 338: } else { >> 339: Handshake::execute(&hs, target); >> 340: } > > This guarantee() that the handshake has executed doesn't have an > equivalent in the rewritten code. Should there be some way of verifying > this condition from this location? Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Mon Sep 21 08:41:57 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 08:41:57 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 20:40:42 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed double check, fix comment, removed not needed function, updated logs > > src/hotspot/share/utilities/filterQueue.inline.hpp line 35: > >> 33: FilterQueueNode* head; >> 34: FilterQueueNode* insnode = new FilterQueueNode(data); >> 35: SpinYield yield(SpinYield::default_spin_limit * 10); // Very unlikely with mutiple failed CAS. > > Typo - s/mutiple/multiple/ Fixed > src/hotspot/share/utilities/filterQueue.inline.hpp line 76: > >> 74: return (E)NULL; >> 75: } >> 76: SpinYield yield(SpinYield::default_spin_limit * 10); // Very unlikely with mutiple failed CAS. > > typo - s/mutiple/multiple/ Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Mon Sep 21 08:51:26 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 08:51:26 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: <95uLEj8gYajeYzYsdHsJ7H93GMBEStaDSDSwhSDCWY4=.58779d68-f017-4def-8a8e-6ad0273800e5@github.com> On Fri, 18 Sep 2020 20:07:47 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed double check, fix comment, removed not needed function, updated logs > > src/hotspot/share/runtime/handshake.hpp line 108: > >> 106: _processed, >> 107: _succeed, >> 108: _number_states > > Why are these indented by 4 spaces instead of 2 spaces? Fixed > src/hotspot/share/runtime/handshake.cpp line 70: > >> 68: : HandshakeOperation(cl, target), _start_time_ns(start_ns) {} >> 69: virtual ~AsyncHandshakeOperation() { delete _handshake_cl; }; >> 70: jlong start_time() { return _start_time_ns; } > > Should this be 'const'? Ignore it if it would fan out too much. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From stefank at openjdk.java.net Mon Sep 21 09:05:58 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 21 Sep 2020 09:05:58 GMT Subject: RFR: 8253407: Move max_pow2 from test to src Message-ID: Small refactoring to move test utility function over to src, so that it can be used in both places. Patch summary: - Moved the code - Replaced duplicate code in round_power_of_2 - Adjusted to the surrounding powerOfTwo.hpp code and only accept integral types. - Added small gtest. (On the fence whether it's worth it or not) ------------- Commit messages: - 8253407: Move max_pow2 from test to src Changes: https://git.openjdk.java.net/jdk/pull/279/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=279&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253407 Stats: 31 lines in 2 files changed: 17 ins; 6 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/279.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/279/head:pull/279 PR: https://git.openjdk.java.net/jdk/pull/279 From kim.barrett at oracle.com Mon Sep 21 09:18:03 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 21 Sep 2020 05:18:03 -0400 Subject: RFR: 8247912: Make narrowOop a scoped enum In-Reply-To: References: Message-ID: <0AD7BDBF-AC28-46C9-AD07-B4CD23C5916A@oracle.com> > On Sep 21, 2020, at 4:34 AM, Roman Kennke wrote: > > On Mon, 21 Sep 2020 04:01:34 GMT, Kim Barrett wrote: > >> [?] > > I'm not convinced. This reduces readability of the code for little gain IMO. A typedef is the logical C++ construct for > something like a narrowOop. An enum class is not, or at least I don't see it. How's a narrowOop an enumeration? The > next time somebody uninitiated comes across this declaration, this is going to cause headscratching. I'd rather avoid > that. This is a normal and well-established use of scoped enums as type-safe integral-like values. Examples from the C++17 Standard include std::byte and std::align_val_t. I've also seen type-safe integer arithmetic done this way, eliminating that nasty implicit promotion and conversion stuff that can get one into so much trouble. I'm sure I can produce more examples if needed. From adinn at openjdk.java.net Mon Sep 21 09:23:26 2020 From: adinn at openjdk.java.net (Andrew Dinn) Date: Mon, 21 Sep 2020 09:23:26 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> <2dlrgVtF5twY9WGHEKS2ZcLEm1jPmGgOfFF6o-ZyUHc=.c33e5814-724a-4569-9eed-97e8afaaa440@github.com> Message-ID: On Fri, 18 Sep 2020 23:11:46 GMT, Jason Tatton wrote: > > Can you explain where this restricted effect is documented? > Certainly! I?ve found that determining the capability of the CPU and whether to enable AVX2 support if the chip > supports it is mostly controlled in: vm_version_x86.cpp specifically: get_processor_features and in > generate_get_cpu_info. Yes, I can see what the code does. I was asking where the cpu behaviour is documented independent of the code. > In order to test the patch comprehensively I had to track down an Intel Core i7 (I7-9750H) processor which the > aforementioned code permitted AVX2 instructions for (maybe this is an error and it should not be enabled for this > processor though) as most of the infrastructure I personally use here at AWS runs on Intel Xeon processors - I also > tested on a E5-2680 which the JVM does not enable AVX2 for. 'maybe'? The documentation Andrew provided mentioned Xeon E5 v3 which I believe is a Skylake design. However, the code I pointed you at in vm_version_x86 which claims to detect 'early Skylake' designs is only disabling AVX512 support. It still enables AVX2. Similarly, the code generates machine code to check the processor capabilities has a special check if use_evex is set (i.e. AVX3 is requested) for Skylake which disables AVX512 but does nto disable AVX2 support. However, this is just the Intel side of things. When it comes to AMD I read that the AMD Zen 2 architecture, of which the current flagship: Threadripper 3990X, is based, is able to support AVX2 without the frequency scaling which some/all(?) of the Intel chips incur. I personally don?t have access to one of these chips so I cannot confirm how it is classified in the JVM. Also, I found when investigating this that there is actually a JVM flag which can be used to control what level of AVX is enabled: -XX:UseAVX=version. ------------- PR: https://git.openjdk.java.net/jdk/pull/71 From aph at redhat.com Mon Sep 21 09:30:18 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 21 Sep 2020 10:30:18 +0100 Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v2] In-Reply-To: References: <1ZhTsmFbjf-c4lddQG53Y-D1PieCcxEOGBKe-CkpGAo=.8be414f0-d0a0-48d9-8be7-82615f733233@github.com> Message-ID: On 21/09/2020 09:18, Bernhard Urban-Forster wrote: > Thank you Andrew. Is the goal to reduce the patch diff in `assembler_aarch64.cpp`? If so, we need to get rid of the > retry in your patch to avoid additional calls to `random`, e.g. something like this (the diff for the generated part > would look indeed nicer with that: https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ): > > --- a/src/hotspot/cpu/aarch64/aarch64-asmtest.py > +++ b/src/hotspot/cpu/aarch64/aarch64-asmtest.py > @@ -13,6 +13,8 @@ class Register(Operand): > > def generate(self): > self.number = random.randint(0, 30) > + if self.number == 18: > + self.number = 17 Yes, better. Thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From kbarrett at openjdk.java.net Mon Sep 21 09:44:12 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 21 Sep 2020 09:44:12 GMT Subject: RFR: 8253407: Move max_pow2 from test to src In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 08:59:01 GMT, Stefan Karlsson wrote: > Small refactoring to move test utility function over to src, so that it can be used in both places. > > Patch summary: > - Moved the code > - Replaced duplicate code in round_power_of_2 > - Adjusted to the surrounding powerOfTwo.hpp code and only accept integral types. > - Added small gtest. (On the fence whether it's worth it or not) Looks good. The gtest seems fine, and it's already written. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/279 From tschatzl at openjdk.java.net Mon Sep 21 09:50:11 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 21 Sep 2020 09:50:11 GMT Subject: RFR: 8253407: Move max_pow2 from test to src In-Reply-To: References: Message-ID: <-80z7SzdD-EuQlXw7r41Cf8thpFeNGiGivcK59Eq9BU=.ca39a569-e2f7-4360-8701-e55a09c82748@github.com> On Mon, 21 Sep 2020 08:59:01 GMT, Stefan Karlsson wrote: > Small refactoring to move test utility function over to src, so that it can be used in both places. > > Patch summary: > - Moved the code > - Replaced duplicate code in round_power_of_2 > - Adjusted to the surrounding powerOfTwo.hpp code and only accept integral types. > - Added small gtest. (On the fence whether it's worth it or not) Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/279 From rehn at openjdk.java.net Mon Sep 21 09:54:18 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 09:54:18 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 20:21:09 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed double check, fix comment, removed not needed function, updated logs > > src/hotspot/share/runtime/handshake.cpp line 349: > >> 347: target->handshake_state()->add_operation(op); >> 348: } else { >> 349: log_handshake_info(start_time_ns, op->name(), 0, 0, "(thread dead)"); > > It might be useful to also log the 'target' thread value here so: > > .... (thread= is dead)" > > Might be something like this: > > log_handshake_info(start_time_ns, op->name(), 0, 0, "(thread=" INTPTR_FORMAT " is dead)", p2i(target)); > > Although you'd probably have to form the string in a buffer and then pass it > to the log_handshake_info() call... sigh... Fixed (via buffert) > src/hotspot/share/runtime/handshake.cpp line 450: > >> 448: return false; >> 449: } >> 450: // Operations are added without lock and then the poll is armed. > > s/without lock/lock free/ Fixed > src/hotspot/share/runtime/handshake.cpp line 479: > >> 477: } >> 478: >> 479: // If we own the mutex at this point and while owning the mutex > > grammar - s/owning the mutex/owning the mutex we/ Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Mon Sep 21 09:54:19 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 09:54:19 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 05:32:54 GMT, David Holmes wrote: >> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 157: >> >>> 155: >>> 156: // Threads shouldn't block if they are in the middle of printing, but... >>> 157: ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); >> >> Can you explain why you had to add this? >> Did something show up in testing? > > Yes please explain as this looks really bad. The tty lock allow vm thread to block and it is a no safepoint check lock. Meaning that you are not allowed to safepoint/handshake poll while holding it. Also if someone is holding it, you can't print on the tty inside a safepoint/handshake. The tty lock is also lower rank than Threads_lock (we used to block on that in safepoint) and lower rank than the handshake state lock. Compiler have code which takes the ttyLocker and prints on tty. Some of the information that it prints passes code which can safepoint/handshake. The way safepoint have gotten around this is by unlocking tty lock before a safepoint. Now that handshake use a mutex instead of semaphore, we thus get an error also. (even if you now don't get an error we could potentially deadlock, or at least we are very deep water). Until compiler is fixed to UL we need this unlocking of the tty lock. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From simonis at openjdk.java.net Mon Sep 21 10:00:30 2020 From: simonis at openjdk.java.net (Volker Simonis) Date: Mon, 21 Sep 2020 10:00:30 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v2] In-Reply-To: <-DRWR4_f5u6DsSGHAuPnpHrhaG8Una8BXf4zDekQjLM=.469b08b6-a8b2-4a6b-8ab8-1a40810aede0@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <-DRWR4_f5u6DsSGHAuPnpHrhaG8Una8BXf4zDekQjLM=.469b08b6-a8b2-4a6b-8ab8-1a40810aede0@github.com> Message-ID: <7DJmBVYGzIaMRYO0Ad5UumqLK3_ehORlOFTAtX_aSP0=.e020152a-a2a0-4db5-ac82-dc17736975a9@github.com> On Fri, 18 Sep 2020 11:56:09 GMT, Jason Tatton wrote: >> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for >> x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it >> I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as >> code for C2. Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and >> java/lang/StringLatin1.java https://bugs.openjdk.java.net/browse/JDK-8173585 >> >> Details of testing: >> ============ >> I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note >> that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the >> input String. Hence the test has been designed to cover all these cases. In summary they are: >> - A ?short? string of < 16 characters. >> - A SIMD String of 16 ? 31 characters. >> - A AVX2 SIMD String of 32 characters+. >> >> Hardware used for testing: >> ----------------------------- >> >> - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support). >> - AWS Graviton 2 (ARM 64 processor). >> >> I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64. >> >> Possible future enhancements: >> ==================== >> For the x86 implementation there may be two further improvements we can make in order to improve performance of both >> the StringUTF16 and StringLatin1 indexOf(char) intrinsics: >> 1. Make use of AVX-512 instructions. >> 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD >> instructions instead of a loop. >> Benchmark results: >> ============ >> **Without** the new StringLatin1 indexOf(char) intrinsic: >> >> | Benchmark | Mode | Cnt | Score | Error | Units | >> | ------------- | ------------- |------------- |------------- |------------- |------------- | >> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op | >> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933 | ns/op | >> >> >> **With** the new StringLatin1 indexOf(char) intrinsic: >> >> | Benchmark | Mode | Cnt | Score | Error | Units | >> | ------------- | ------------- |------------- |------------- |------------- |------------- | >> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716 | ns/op | >> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306 | ns/op | >> >> >> The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 >> indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when >> running on ARM. > > Jason Tatton has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains four commits: > - Merge master > - 8173585: further whitespace changes required by jcheck > - JDK-8173585 - whitespace changes required by jcheck > - JDK-8173585 src/hotspot/share/classfile/vmSymbols.cpp line 295: > 293: if (symbol == NULL) return NO_SID; > 294: return find_sid(symbol); > 295: } I think it is common sense to have a newline at the end of a file. ------------- PR: https://git.openjdk.java.net/jdk/pull/71 From rkennke at openjdk.java.net Mon Sep 21 10:01:29 2020 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 21 Sep 2020 10:01:29 GMT Subject: RFR: 8247912: Make narrowOop a scoped enum In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 08:32:14 GMT, Roman Kennke wrote: >> Please review this change to the type narrowOop from a typedef for juint to a >> scoped enum with uint32_t as the representation type. This provides stronger >> type checking when using this type. >> >> For the most part this was fairly straightforward, and the patch size is >> relatively small. The implementation of some existing CompressedOops >> "primitives" required adjustment. An explicit conversion to narrowOop was >> added, with casts change to use it. There were a few places that were type >> punning and needed explicit conversions,, mostly in platform-specific assembly >> support. >> >> There are a couple of lingering problems. >> >> Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass >> as a narrowOop. I adjusted the code to accommodate the narrowOop change, but >> this probably ought to be done differently. >> >> There are a couple of `(narrowOop)` casts remaining in s390.ad. I'm not sure >> whether these can be safely converted to CompressedOops::narrow_oop_cast. >> >> There might still be some casts from narrowOop to an integral type. Those are >> hard to find in our cast-happy code base. >> >> Testing: >> tier1-6 for Oracle supported platforms. >> Build fastdebug linux-ppc64le and linux-s390x. > > I'm not convinced. This reduces readability of the code for little gain IMO. A typedef is the logical C++ construct for > something like a narrowOop. An enum class is not, or at least I don't see it. How's a narrowOop an enumeration? The > next time somebody uninitiated comes across this declaration, this is going to cause headscratching. I'd rather avoid > that. > _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on > [shenandoah-dev](mailto:shenandoah-dev at openjdk.java.net):_ > > On Sep 21, 2020, at 4:34 AM, Roman Kennke wrote: > > On Mon, 21 Sep 2020 04:01:34 GMT, Kim Barrett wrote: > > > [?] > > > > > > I'm not convinced. This reduces readability of the code for little gain IMO. A typedef is the logical C++ construct for > > something like a narrowOop. An enum class is not, or at least I don't see it. How's a narrowOop an enumeration? The > > next time somebody uninitiated comes across this declaration, this is going to cause headscratching. I'd rather avoid > > that. > > This is a normal and well-established use of scoped enums as type-safe > integral-like values. Examples from the C++17 Standard include std::byte and > std::align_val_t. I've also seen type-safe integer arithmetic done this way, > eliminating that nasty implicit promotion and conversion stuff that can get > one into so much trouble. I'm sure I can produce more examples if needed. Hmm ok. Thanks for clarification. Roman ------------- PR: https://git.openjdk.java.net/jdk/pull/273 From rehn at openjdk.java.net Mon Sep 21 10:05:32 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 10:05:32 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 20:37:10 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed double check, fix comment, removed not needed function, updated logs > > src/hotspot/share/runtime/thread.cpp line 487: > >> 485: assert(!thread->is_Java_thread() || >> 486: ((JavaThread *) thread)->is_handshake_safe_for(Thread::current()) || >> 487: !((JavaThread *) thread)->on_thread_list() || > > Should use "thread->as_Java_thread()" instead of the cast here (2 places). Fixed > src/hotspot/share/runtime/thread.hpp line 1360: > >> 1358: bool is_handshake_safe_for(Thread* th) const { >> 1359: return _handshake.active_handshaker() == th || >> 1360: this == th; > > I _think_ L1359-60 will fit on one line... Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Mon Sep 21 10:05:33 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 10:05:33 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 05:04:45 GMT, David Holmes wrote: >> src/hotspot/share/prims/whitebox.cpp line 2032: >> >>> 2030: void do_thread(Thread* th) { >>> 2031: assert(th->is_Java_thread(), "sanity"); >>> 2032: JavaThread* jt = (JavaThread*)th; >> >> Can whitebox.cpp code use the new as_Java_thread() call? > > Yes it can. :) Fixed :) ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From stefank at openjdk.java.net Mon Sep 21 10:09:39 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 21 Sep 2020 10:09:39 GMT Subject: RFR: 8253407: Move max_pow2 from test to src In-Reply-To: <-80z7SzdD-EuQlXw7r41Cf8thpFeNGiGivcK59Eq9BU=.ca39a569-e2f7-4360-8701-e55a09c82748@github.com> References: <-80z7SzdD-EuQlXw7r41Cf8thpFeNGiGivcK59Eq9BU=.ca39a569-e2f7-4360-8701-e55a09c82748@github.com> Message-ID: On Mon, 21 Sep 2020 09:46:59 GMT, Thomas Schatzl wrote: >> Small refactoring to move test utility function over to src, so that it can be used in both places. >> >> Patch summary: >> - Moved the code >> - Replaced duplicate code in round_power_of_2 >> - Adjusted to the surrounding powerOfTwo.hpp code and only accept integral types. >> - Added small gtest. (On the fence whether it's worth it or not) > > Marked as reviewed by tschatzl (Reviewer). Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/279 From rehn at openjdk.java.net Mon Sep 21 10:10:44 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 10:10:44 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 05:27:00 GMT, David Holmes wrote: >> src/hotspot/share/runtime/handshake.hpp line 45: >> >>> 43: // a single target/direct handshake or not, by the JavaThread that requested the >>> 44: // handshake or the VMThread respectively. >>> 45: class HandshakeClosure : public ThreadClosure, public CHeapObj { >> >> Just to be clear. You haven't added support for a handshake that >> must only be executed by the target thread yet, right? That's >> future work, if I remember correctly... > > AsyncHandshakeClosures have operations that must, by definition, be executed by the target thread (if they are executed > at all). Yes as David says. The code that make sure this is case is: static bool processor_filter(HandshakeOperation* op) { return !op->is_asynch(); } Which is used e.g: return _queue.contains(processor_filter); While process_self_inner() uses no filter. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Mon Sep 21 10:10:45 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 10:10:45 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 20:52:49 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed double check, fix comment, removed not needed function, updated logs > > src/hotspot/share/prims/whitebox.cpp line 2033: > >> 2031: assert(th->is_Java_thread(), "sanity"); >> 2032: JavaThread* jt = (JavaThread*)th; >> 2033: ResourceMark rm; > > It also might be interesting to print the "current thread" info here so > that someone looking at the test output knows which thread handled > the handshake (the target or a surrogate). It's always the thread it self, added asserts to make this clear. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Mon Sep 21 10:42:32 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 10:42:32 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 06:13:55 GMT, David Holmes wrote: > There is still a lack of motivation for this feature in the JBS issue. What kind of handshakes need to be asynchronous? > Any async operation implies that the requester doesn't care about when or even if, the operation gets executed - they > are by definition fire-and-forget actions. So what are the usecases being envisaged here? Added info in JBS issue: https://bugs.openjdk.java.net/browse/JDK-8238761 All uses-cases of _suspend_flag as initial targets. But some of them require more bits. > Many of the changes included here seem unrelated to, and not reliant on, async handshakes, and could be factored out to > simplify the review and allow focus on the actual async handshake part e.g. the JVM TI cleanups seem they could be > mostly standalone. Since I kept rebasing this doing somethings I did somethings to simplify the rebasing. I guess you are talking about the JvmtiHandshakeClosure? > Specific comments below. A general concern I have is where the current thread is no longer guaranteed to be a > JavaThread (which is a step in the wrong direction in relation to some of the cleanups I have planned!) and I can't see > why this would be changing. If the VM thread emits a "handshake all" it will continuously loop the JavaThreads until op is completed. We do not keep track which JavaThread have done which handshake. The VM thread will execute all handshakes it finds on every JavaThread's queue. If someone else adds a handshake to one of the JavaThreads the VM thread might execute it. I did not see any issues while looking at the code or in testing doing this. Many of the handshakes used to be safepoints, always executed by VM thread. We changed that to VM thread or JavaThread it self, and we now extend that to any JavaThread. Some of the JVM TI handshakes are a bit different, but since they must proper allocate resource in target JavaThread and not in current JavaThread, there is no issue executing the code with a non-JavaThread. At the moment we have no dependencies on that the 'driver' is a JavaThread for any of the handshakes. We can easily set a per Handshake typ filter (slight changes to Handshake Closure and filter function) and choose to only executed the handshake with target self and requester/any JavaThread/only VM thread. So if we think JVM TI handshakes should only be executed by requester or target it's an easy fix. If you think the default is wrong, it's also an easy change. (For others following there also a planned investigation on requester only executed handshake, which is not as easy) > Thanks. # > src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 320: > >> 318: op.do_thread(_thread); >> 319: } else { >> 320: Handshake::execute(&op, _thread); > > We should still have the guarantee check that the target was alive. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Mon Sep 21 10:55:17 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 10:55:17 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: <__uAJJKEl-cvCeHySd7cSrEEkGefi4Yfui_Lpv6z53E=.2be65db7-a561-4296-8a8c-d8ca0f5901f7@github.com> On Mon, 21 Sep 2020 05:01:29 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed double check, fix comment, removed not needed function, updated logs > > src/hotspot/share/prims/jvmtiEventController.cpp line 339: > >> 337: hs.do_thread(target); >> 338: } else { >> 339: Handshake::execute(&hs, target); > > We should still have the guarantee check that the target is still alive. Fixed > src/hotspot/share/prims/jvmtiEnvBase.cpp line 692: > >> 690: // calling_thread is the thread that requested the list of monitors for java_thread. >> 691: // java_thread is thread owning the monitors. >> 692: // current_thread is thread executint this code, can be a non-JavaThread (e.g. VM Thread). > > Where is the use of the VMThread introduced as I cannot see it? The code was changed to use direct handshakes so that > we know that either the caller or the target (both JavaThreads) must be executing it. I don't see any VMOperation added > to call this code. The assumption that it must be an JavaThread was due to code such as "JavaThread::current();", any Thread can execute this. The default the first thread grabbing the handshake state lock for the targeted thread will execute all handshake operation it is allowed to. This might be the VM thread. > src/hotspot/share/runtime/handshake.cpp line 230: > >> 228: log_trace(handshake)("Threads signaled, begin processing blocked threads by VMThread"); >> 229: HandshakeSpinYield hsy(start_time_ns); >> 230: int executed_by_driver = 0; > > driver?? Isn't this still the VMThread? The driver is VM thread or a JavaThread. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Mon Sep 21 11:00:42 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 11:00:42 GMT Subject: RFR: 8238761: Asynchronous handshakes [v2] In-Reply-To: References: Message-ID: <7K8EUtQv1UsANs3q0n1V5PJ5zGmygDn160Cn9SXCPWc=.115b8e4a-12ae-4912-a7c8-b109506f77b7@github.com> On Mon, 21 Sep 2020 05:17:03 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed double checks >> Added NSV >> ProcessResult to enum >> Fixed logging >> Moved _active_handshaker to private > > src/hotspot/share/runtime/handshake.cpp line 336: > >> 334: // and thus prevents reading stale data modified in the handshake closure >> 335: // by the Handshakee. >> 336: OrderAccess::acquire(); > > How/why is this deleted? Surely there are still single-thread VMops that use a handshake?? As I said in PR request: "Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did." They are not VM ops, and default we do not promise who will execute it. Just that it will be executed on thread X. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Mon Sep 21 11:06:04 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 11:06:04 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 05:18:06 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed double check, fix comment, removed not needed function, updated logs > > src/hotspot/share/runtime/handshake.cpp line 313: > >> 311: } >> 312: >> 313: int executed_by_driver = 0; > > Again why driver?? Isn't it either the current thread or the target that will execute the op? The thread executing this handshake operation, what the current thread is doesn't matter. You can't use current threads resources or be dependent otherwise on it. Exception being locking issues in JVM TI, where we are dependent that requester have locked JVM TI state lock for us, but we are not dependent that the current thread is the owner. So checking that the lock is held by requester doesn't matter for how is the 'driver'. > src/hotspot/share/runtime/handshake.cpp line 453: > >> 451: // If all handshake operations for the handshakee are finished and someone >> 452: // just adds an operation we may see it here. But if the handshakee is not >> 453: // armed yet it is not safe to procced. > > s/procced/proceed/ Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Mon Sep 21 11:11:05 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 11:11:05 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: <4l2vRUllquBWTsz1t0brYAsPoBzNIKo1A7M9GBAcKNw=.da0e1992-ebff-4c31-bdc9-e6c293189276@github.com> On Mon, 21 Sep 2020 05:26:08 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed double check, fix comment, removed not needed function, updated logs > > src/hotspot/share/runtime/handshake.hpp line 44: > >> 42: // by the target JavaThread itself or, depending on whether the operation is >> 43: // a single target/direct handshake or not, by the JavaThread that requested the >> 44: // handshake or the VMThread respectively. > > This comment now indicates that all single target handshakes are executed as direct-handshakes and never by the > VMThread - is that correct? The concept of direct handshake do not exist in that way. (but can easily be implemented using the filter) You have operation that you need to be executed on a JavaThread, you add that to that JavaThread. Any thread ("driver") that succeed to claim that JavaThreads handshake state (lock and that JavaThread is safe) procced to execute from that handshake queue until empty (empty according to applied filter on queue). > src/hotspot/share/runtime/handshake.hpp line 107: > >> 105: _claim_failed, >> 106: _processed, >> 107: _succeed, > > grammatically should be _succeeded Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Mon Sep 21 11:14:29 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 11:14:29 GMT Subject: RFR: 8238761: Asynchronous handshakes [v2] In-Reply-To: References: Message-ID: <-FquO1wFCKkgjCoNBYg7I3pAHIiujI6BrPKqHrOex6k=.54ca4124-ecdb-4fbb-92b7-d787d9ccae08@github.com> On Mon, 21 Sep 2020 05:31:59 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed double checks >> Added NSV >> ProcessResult to enum >> Fixed logging >> Moved _active_handshaker to private > > src/hotspot/share/runtime/interfaceSupport.inline.hpp line 136: > >> 134: assert(_thread->thread_state() == _thread_in_vm, "should only call when leaving VM after handshake"); >> 135: >> 136: _thread->set_thread_state(_original_state); > > Can you clarify why this is no longer needed? What states can we be returning to? You can never call SafepointMechanism::process_if_requested() while in any 'safe-state' (as determine by safepoint/handshake safe routines). We thus know we are transitioning from an unsafe state to an unsafe state, which unsafe state might be seen by e.g. VM thread we care little about. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Mon Sep 21 11:49:30 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 11:49:30 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 05:42:29 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed double check, fix comment, removed not needed function, updated logs > > src/hotspot/share/runtime/thread.cpp line 481: > >> 479: #ifdef ASSERT >> 480: // A JavaThread is considered "dangling" if it is not the current >> 481: // thread, his not handshaking with current thread, as been added the Threads > > s/his/is/ ? > s/as been added the/has been added to the/ > > But rather than describe all the conditions, few of which are actually visible in the assertion below, why not just > rephrase in terms of the conditions checked i.e. // A JavaThread is considered dangling if it not handshake-safe with > respect to the current thread, or // it is not on a ThreadsList. > The is_handshake_safe_for method should describe all the conditions that make a target handshake safe. Fixed > src/hotspot/share/runtime/thread.cpp line 851: > >> 849: bool >> 850: JavaThread::is_thread_fully_suspended(bool wait_for_suspend, uint32_t *bits) { >> 851: if (this != Thread::current()) { > > Why/how is a non-JavaThread calling this? is_thread_fully_suspended() is used in JVM TI handshake and this change-set allow VM thread to execute them. This method have no dependency that caller is a JavaThread. > src/hotspot/share/runtime/thread.cpp line 2441: > >> 2439: assert(Thread::current()->is_VM_thread() || >> 2440: is_handshake_safe_for(Thread::current()), >> 2441: "should be in the vm thread, self or handshakee"); > > This seems too general. This should either be a VMoperation or a direct handshake, but not both. send_thread_stop() is only called from a handshake operation. Fixed. > src/hotspot/share/utilities/filterQueue.hpp line 57: > >> 55: >> 56: // MT-safe >> 57: // Since pops and adds are allowed while we add, we do not know if _first is same even if it's the same address. > > This comment seems out of context on the declaration of add, as it is describing a detail of the implementation - to > what are we comparing _first to be the same ?? If you want to just document the MT properties abstractedly then > describing this a lock-free would suffice. Though if pop requires locking then it's implementation is also constrained > to work with the lock-free version of add. Overall it is unclear how documenting "external serialization needed" > actually helps the user of this API. ?? Removed comment. Ok. Since it's same notation as posix uses I thought was clear that any method marked MT-Unsafe is not safe call to from a multithreaded program. Suggestion on how to separate the MT-safe from MT-usafe methods ? > src/hotspot/share/utilities/filterQueue.inline.hpp line 42: > >> 40: break; >> 41: } >> 42: yield.wait(); > > Was the need for spinwaits identified through benchmarking? Do you really expect this to be hot? No and no. It was added to guard against any pathologically case, such as the gtest stress-tests. > src/hotspot/share/utilities/filterQueue.inline.hpp line 63: > >> 61: } >> 62: >> 63: // MT-Unsafe, external serialization needed. > > So IIUC this queue supports multiple concurrent add()s, but has to be restricted to a single pop() at a time (although > that is allowed to execute concurrently with the add()s) - correct? Yes > test/hotspot/jtreg/runtime/handshake/MixedHandshakeWalkStackTest.java line 38: > >> 36: >> 37: public class MixedHandshakeWalkStackTest { >> 38: public static Thread tthreads[]; > > why tthreads? It looks like a typo :) Test threads, changed to testThreads. > test/hotspot/jtreg/runtime/handshake/AsyncHandshakeWalkStackTest.java line 30: > >> 28: * @build AsyncHandshakeWalkStackTest >> 29: * @run driver ClassFileInstaller sun.hotspot.WhiteBox >> 30: * sun.hotspot.WhiteBox$WhiteBoxPermission > > This is not needed as ClassFileInstaller already handles WhiteBox's nested classes. Fixed > test/hotspot/jtreg/runtime/handshake/MixedHandshakeWalkStackTest.java line 30: > >> 28: * @build MixedHandshakeWalkStackTest >> 29: * @run driver ClassFileInstaller sun.hotspot.WhiteBox >> 30: * sun.hotspot.WhiteBox$WhiteBoxPermission > > Not needed - see earlier comment. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Mon Sep 21 12:19:09 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 21 Sep 2020 12:19:09 GMT Subject: RFR: 8238761: Asynchronous handshakes [v4] In-Reply-To: References: Message-ID: > This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes > are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) > Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an > arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a > singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first > pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first > pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake > operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything > except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed > filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake > operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there > is now only one method to call when handshaking one thread. Some comments about the changes: > - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake > all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much > worse then this. > > - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that > thread. > > - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a > handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. > > - Added WB testing method. > > - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. > > - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. > > - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a > safepoint and half of them after, in many handshake all operations. > > - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. > > - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the > moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. > > - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. > > - Added filtered queue and gtest for it. > > Passes multiple t1-8 runs. > Been through some pre-reviwing. Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Update after Dan and David - Merge branch 'master' into 8238761-asynchrounous-handshakes - Removed double check, fix comment, removed not needed function, updated logs - Fixed double checks Added NSV ProcessResult to enum Fixed logging Moved _active_handshaker to private - Rebase version 1.0 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/151/files - new: https://git.openjdk.java.net/jdk/pull/151/files/469f8fc8..badefa47 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=151&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=151&range=02-03 Stats: 9168 lines in 299 files changed: 4700 ins; 3543 del; 925 mod Patch: https://git.openjdk.java.net/jdk/pull/151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/151/head:pull/151 PR: https://git.openjdk.java.net/jdk/pull/151 From github.com+70893615+jasontatton-aws at openjdk.java.net Mon Sep 21 12:45:55 2020 From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton) Date: Mon, 21 Sep 2020 12:45:55 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v3] In-Reply-To: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> Message-ID: > This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for > x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it > I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as > code for C2. Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and > java/lang/StringLatin1.java https://bugs.openjdk.java.net/browse/JDK-8173585 > > Details of testing: > ============ > I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note > that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the > input String. Hence the test has been designed to cover all these cases. In summary they are: > - A ?short? string of < 16 characters. > - A SIMD String of 16 ? 31 characters. > - A AVX2 SIMD String of 32 characters+. > > Hardware used for testing: > ----------------------------- > > - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support). > - AWS Graviton 2 (ARM 64 processor). > > I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64. > > Possible future enhancements: > ==================== > For the x86 implementation there may be two further improvements we can make in order to improve performance of both > the StringUTF16 and StringLatin1 indexOf(char) intrinsics: > 1. Make use of AVX-512 instructions. > 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD > instructions instead of a loop. > Benchmark results: > ============ > **Without** the new StringLatin1 indexOf(char) intrinsic: > > | Benchmark | Mode | Cnt | Score | Error | Units | > | ------------- | ------------- |------------- |------------- |------------- |------------- | > | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op | > | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933 | ns/op | > > > **With** the new StringLatin1 indexOf(char) intrinsic: > > | Benchmark | Mode | Cnt | Score | Error | Units | > | ------------- | ------------- |------------- |------------- |------------- |------------- | > | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716 | ns/op | > | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306 | ns/op | > > > The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 > indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when > running on ARM. Jason Tatton has updated the pull request incrementally with one additional commit since the last revision: Add missing newline to end of vmSymbols.cpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/71/files - new: https://git.openjdk.java.net/jdk/pull/71/files/b85a7fb4..c8cc441e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=71&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=71&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/71.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/71/head:pull/71 PR: https://git.openjdk.java.net/jdk/pull/71 From stefank at openjdk.java.net Mon Sep 21 13:05:31 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 21 Sep 2020 13:05:31 GMT Subject: RFR: 8253407: Move max_pow2 from test to src In-Reply-To: References: <-80z7SzdD-EuQlXw7r41Cf8thpFeNGiGivcK59Eq9BU=.ca39a569-e2f7-4360-8701-e55a09c82748@github.com> Message-ID: <4hiYMQ23FD5G4zsOttLMO1kCgbRakMPQQfJjvMduuRc=.a00fa892-e4e7-4b75-b2e3-62c8c3654e00@github.com> On Mon, 21 Sep 2020 10:06:16 GMT, Stefan Karlsson wrote: >> Marked as reviewed by tschatzl (Reviewer). > > Thanks for reviewing! I consider this trivial enough to push it now. ------------- PR: https://git.openjdk.java.net/jdk/pull/279 From stefank at openjdk.java.net Mon Sep 21 13:05:32 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 21 Sep 2020 13:05:32 GMT Subject: Integrated: 8253407: Move max_pow2 from test to src In-Reply-To: References: Message-ID: <4ajVq5iyuUnh03k6KCCj2i_3eh_buri3aW2O0NJAAK8=.3bb6e95f-eff1-45be-b6bf-38f3b3fe1f86@github.com> On Mon, 21 Sep 2020 08:59:01 GMT, Stefan Karlsson wrote: > Small refactoring to move test utility function over to src, so that it can be used in both places. > > Patch summary: > - Moved the code > - Replaced duplicate code in round_power_of_2 > - Adjusted to the surrounding powerOfTwo.hpp code and only accept integral types. > - Added small gtest. (On the fence whether it's worth it or not) This pull request has now been integrated. Changeset: 7e49eaec Author: Stefan Karlsson URL: https://git.openjdk.java.net/jdk/commit/7e49eaec Stats: 31 lines in 2 files changed: 6 ins; 17 del; 8 mod 8253407: Move max_pow2 from test to src Reviewed-by: kbarrett, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/279 From mbeckwit at openjdk.java.net Mon Sep 21 14:55:26 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Mon, 21 Sep 2020 14:55:26 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v3] In-Reply-To: References: Message-ID: > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 11 new commits since the last revision: - 8248787: G1: Workaround MSVC bug Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248670: Windows: Exception handling support on AArch64 Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248660: AArch64: Make _clear_cache and _nop portable Summary: __builtin___clear_cache, etc. Contributed-by: mbeckwit, luhenry, burban - 8248659: AArch64: Extend CPU Feature detection Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248656: Add Windows AArch64 platform support code Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248498: Add build system support for Windows AArch64 Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__ Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248663: AArch64: Avoid existing macros/keywords of MSVC Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248676: AArch64: Add workaround for LITable constructor Reviewed-by: aph Contributed-by: mbeckwit, luhenry, burban - 8248500: AArch64: Remove the r18 dependency on Windows AArch64 (regenerate tests) Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - ... and 1 more: https://git.openjdk.java.net/jdk/compare/5f9b0d35...3881b12d ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/212/files - new: https://git.openjdk.java.net/jdk/pull/212/files/5f9b0d35..3881b12d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=01-02 Stats: 1366 lines in 2 files changed: 6 ins; 4 del; 1356 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From burban at openjdk.java.net Mon Sep 21 14:55:27 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Mon, 21 Sep 2020 14:55:27 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v3] In-Reply-To: References: <1ZhTsmFbjf-c4lddQG53Y-D1PieCcxEOGBKe-CkpGAo=.8be414f0-d0a0-48d9-8be7-82615f733233@github.com> Message-ID: On Mon, 21 Sep 2020 08:15:20 GMT, Bernhard Urban-Forster wrote: >> Hey @erikj79, thank you so much for giving it a try! >> >>> Our linux-aarch64 build fails with this: >>> cc: error: unrecognized command line option '-std=c++14' >>> when compiling build/linux-aarch64/buildjdk/hotspot/variant-server/libjvm/objs/precompiled/precompiled.hpp.gch >> >> Hmm, that's interesting. What environment is that exactly? What `configure` line are you using there? We have tested on >> such a system: $ cat /etc/issue >> Ubuntu 19.10 \n \l >> $ bash configure --with-boot-jdk=/home/beurba/work/jdk-16+13 --with-jtreg >> $ make clean CONF=linux-aarch64-server-release >> $ make images JOBS=255 LOG=info CONF=linux-aarch64-server-release >> $ ./build/linux-aarch64-server-release/images/jdk/bin/java -XshowSettings:properties -version 2>&1 | grep aarch64 >> java.home = /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk >> os.arch = aarch64 >> sun.boot.library.path = /home/beurba/work/jdk/build/linux-aarch64-server-release/images/jdk/lib >> -------------------------------------------------------- >>> I'm trying to configure a windows-aarch64 build, but it fails on fixpath. Is this something you are also experiencing, >>> and if so, how are you addressing it? >> >> Yes. As far as I understand, the problem is that `fixpath.exe` isn't built properly when doing cross-compiling on >> Windows targets (as it hasn't been a thing so far). We use a workaround internally >> https://gist.github.com/lewurm/c099a4b5fcd8a182510cbdeebcb41f77 , but a proper solution is under discussion on >> build-dev: https://mail.openjdk.java.net/pipermail/build-dev/2020-July/027872.html > >> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ >> >> On 18/09/2020 11:14, Monica Beckwith wrote: >> >> > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> The diffs in assembler_aarch64.cpp are mostly spurious. Please try this. > > > Thank you Andrew. Is the goal to reduce the patch diff in `assembler_aarch64.cpp`? If so, we need to get rid of the > retry in your patch to avoid additional calls to `random`, e.g. something like this (the diff for the generated part > would look indeed nicer with that: https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ): > --- a/src/hotspot/cpu/aarch64/aarch64-asmtest.py > +++ b/src/hotspot/cpu/aarch64/aarch64-asmtest.py > @@ -13,6 +13,8 @@ class Register(Operand): > > def generate(self): > self.number = random.randint(0, 30) > + if self.number == 18: > + self.number = 17 > return self > > def astr(self, prefix): > @@ -37,6 +39,8 @@ class GeneralRegisterOrZr(Register): > > def generate(self): > self.number = random.randint(0, 31) > + if self.number == 18: > + self.number = 16 > return self > > def astr(self, prefix = ""): > @@ -54,6 +58,8 @@ class GeneralRegisterOrZr(Register): > class GeneralRegisterOrSp(Register): > def generate(self): > self.number = random.randint(0, 31) > + if self.number == 18: > + self.number = 15 > return self > > def astr(self, prefix = ""): > @@ -1331,7 +1337,7 @@ generate(SpecialCases, [["ccmn", "__ ccmn(zr, zr, 3u, Assembler::LE);", > ["st1w", "__ sve_st1w(z0, __ S, p1, Address(r0, 7));", "st1w\t{z0.s}, p1, [x0, #7, MUL VL]"], > ["st1b", "__ sve_st1b(z0, __ B, p2, Address(sp, r1));", "st1b\t{z0.b}, p2, [sp, x1]"], > ["st1h", "__ sve_st1h(z0, __ H, p3, Address(sp, r8));", "st1h\t{z0.h}, p3, [sp, x8, LSL #1]"], > - ["st1d", "__ sve_st1d(z0, __ D, p4, Address(r0, r18));", "st1d\t{z0.d}, p4, [x0, x18, LSL #3]"], > + ["st1d", "__ sve_st1d(z0, __ D, p4, Address(r0, r17));", "st1d\t{z0.d}, p4, [x0, x17, > LSL #3]"], > ["ldr", "__ sve_ldr(z0, Address(sp));", "ldr\tz0, [sp]"], > ["ldr", "__ sve_ldr(z31, Address(sp, -256));", "ldr\tz31, [sp, #-256, MUL VL]"], > ["str", "__ sve_str(z8, Address(r8, 255));", "str\tz8, [x8, #255, MUL VL]"], > _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ > > On 21/09/2020 09:18, Bernhard Urban-Forster wrote: > > > Thank you Andrew. Is the goal to reduce the patch diff in `assembler_aarch64.cpp`? If so, we need to get rid of the > > retry in your patch to avoid additional calls to `random`, e.g. something like this (the diff for the generated part > > would look indeed nicer with that: https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ): > > [...] > > Yes, better. Thanks. Great, I've updated the PR. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From minqi at openjdk.java.net Mon Sep 21 16:25:06 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 21 Sep 2020 16:25:06 GMT Subject: RFR: 8253262: Allocate in DumpRegion is not thread safe In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 04:18:49 GMT, David Holmes wrote: > It seems to me that the need for locking should be an internal implementation detail of > MetaspaceShared::symbol_space_alloc, rather than Symbol operator new. I pushed before saw your above comment. The reason for current place is because the following code: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/symbol.cpp#L75 DEBUG_ONLY(static void* last = 0); void* p = (void*)MetaspaceShared::symbol_space_alloc(size(len)*wordSize); assert(p > last, "must increase monotonically"); DEBUG_ONLY(last = p); return p; this 'last' is not thread safe either. ------------- PR: https://git.openjdk.java.net/jdk/pull/216 From minqi at openjdk.java.net Mon Sep 21 18:17:55 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 21 Sep 2020 18:17:55 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v2] In-Reply-To: References: Message-ID: > With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is > specific to CDS. > Tests: tier1-4 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: 8253208: Move CDS related code to a separate class ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/261/files - new: https://git.openjdk.java.net/jdk/pull/261/files/b9789c8b..c01deec7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=261&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=261&range=00-01 Stats: 27 lines in 7 files changed: 0 ins; 0 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/261/head:pull/261 PR: https://git.openjdk.java.net/jdk/pull/261 From minqi at openjdk.java.net Mon Sep 21 18:25:55 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 21 Sep 2020 18:25:55 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v2] In-Reply-To: References: Message-ID: <7rL3zSJi28q_2LUdGaxlpMg8b2fFh1IHNF07U3uaaeU=.b4a7e852-9c61-43bf-aadf-30b5d5d6af32@github.com> On Sun, 20 Sep 2020 06:10:53 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> 8253208: Move CDS related code to a separate class > > src/java.base/share/native/libjava/CDS.c line 49: > >> 47: JNIEXPORT jboolean JNICALL >> 48: Java_jdk_internal_misc_CDS_isCDSDumpingEnabled(JNIEnv *env, jclass jcls) { >> 49: return JVM_IsCDSDumpingEnabled(env); > > Maybe: return JVM_IsCDSDynamicDumpingEnabled(env) updated with comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From kvn at openjdk.java.net Mon Sep 21 18:48:24 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 21 Sep 2020 18:48:24 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> Message-ID: On Thu, 17 Sep 2020 14:26:56 GMT, Doug Simon wrote: >> The idea is to add a more powerful API for cases where the current iterateFrames API cannot be used. >> >> For example, a debugger needs access to the content of stack frames such as local variables or monitors. In cases where >> threads execute in the runtime or in native code, it's not possible to obtain a thread suspension hook, for which >> iterateFrames can be used on the suspended thread. The getStackFrames method enables an immediate stack frames lookup >> regardless of the status of the underlying thread. Another use case would be for lookup of backtraces for non-current >> threads. The implementation is done by means of a VM operation that collects vframe data for each thread during a >> safepoint, whereafter required object reallocation/reassign fields is performed based on the collected snapshot. > > @vnkozlov @veresov @dean-long it would be great to get some reviews of this soon. To assist, let me try provide a > little more context on the area of JVMCI which is motivated by > [Truffle](https://www.graalvm.org/truffle/javadoc/com/oracle/truffle/api/package-summary.html). The > [`StackIntrospection.iterateFrames()`](https://github.com/openjdk/jdk/blob/6bab0f539fba8fb441697846347597b4a0ade428/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.code/src/jdk/vm/ci/code/stack/StackIntrospection.java#L45) > API exists for Truffle to support walking guest language frames. In Truffle, all values, including primitives, are > boxed which explains why there is no `InspectedFrame.setLocal(int index, Object value)` method. All Truffle guest > language frame locals are accessed/updated by reading/updating the boxed value returned by `InspectedFrame.getLocal()`. > With this existing API, a thread can only inspect its own stack frames. As the description of this PR states, it > extends `StackIntrospection.iterateFrames()` with `StackIntrospection.getStackFrames()` so that a thread can inspect > the frames of other threads. It is somewhat analogous to `java.lang.Thread.getAllStackTraces()` except it allows the > local variables of the frames to be accessed as well. I would like to hear answer to @dholmes-ora question in JBS: "Do we really need yet another stack dumping interface in the VM? Why isn't a debugger using JVM TI?" ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From mchung at openjdk.java.net Mon Sep 21 19:00:33 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 21 Sep 2020 19:00:33 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v2] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 18:17:55 GMT, Yumin Qi wrote: >> With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is >> specific to CDS. >> Tests: tier1-4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > 8253208: Move CDS related code to a separate class This patch looks okay. Please add the javadoc for `CDS::getRandomSeedForDumping` and `CDS::defineArchiveModules` for completeness. ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From erikj at openjdk.java.net Mon Sep 21 19:07:13 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 21 Sep 2020 19:07:13 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v2] In-Reply-To: References: Message-ID: <65z5iR9UPXmBfCEVJkOgnegcyctdCIOZJ_tMl0bEdAI=.0457ea07-f4ff-48e4-b793-2e8011ee1a45@github.com> On Mon, 21 Sep 2020 18:17:55 GMT, Yumin Qi wrote: >> With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is >> specific to CDS. >> Tests: tier1-4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > 8253208: Move CDS related code to a separate class Build changes look good. ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From dtitov at openjdk.java.net Mon Sep 21 19:35:48 2020 From: dtitov at openjdk.java.net (Daniil Titov) Date: Mon, 21 Sep 2020 19:35:48 GMT Subject: Integrated: 8241390: 'Deadlock' with VM_RedefineClasses::lock_classes() In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 16:43:01 GMT, Daniil Titov wrote: > The change fixes a 'deadlock' situation in VM_RedefineClasses::lock_classes() when the current thread is in the middle > of redefining the same class. The change is based on the fix [1] suggested in the Jira issue [2] comment. > [1] http://cr.openjdk.java.net/~jiangli/8241390/webrev.00/ > [2] https://bugs.openjdk.java.net/browse/JDK-8241390 > > Testing: :jdk_instrument, tier1-tier3, and tier5 tests pass. This pull request has now been integrated. Changeset: f800af97 Author: Daniil Titov URL: https://git.openjdk.java.net/jdk/commit/f800af97 Stats: 179 lines in 4 files changed: 0 ins; 170 del; 9 mod 8241390: 'Deadlock' with VM_RedefineClasses::lock_classes() Reviewed-by: coleenp, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/190 From iklam at openjdk.java.net Mon Sep 21 21:32:19 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 21 Sep 2020 21:32:19 GMT Subject: RFR: 8247912: Make narrowOop a scoped enum In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 04:01:34 GMT, Kim Barrett wrote: > Please review this change to the type narrowOop from a typedef for juint to a > scoped enum with uint32_t as the representation type. This provides stronger > type checking when using this type. > > For the most part this was fairly straightforward, and the patch size is > relatively small. The implementation of some existing CompressedOops > "primitives" required adjustment. An explicit conversion to narrowOop was > added, with casts change to use it. There were a few places that were type > punning and needed explicit conversions,, mostly in platform-specific assembly > support. > > There are a couple of lingering problems. > > Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass > as a narrowOop. I adjusted the code to accommodate the narrowOop change, but > this probably ought to be done differently. > > There are a couple of `(narrowOop)` casts remaining in s390.ad. I'm not sure > whether these can be safely converted to CompressedOops::narrow_oop_cast. > > There might still be some casts from narrowOop to an integral type. Those are > hard to find in our cast-happy code base. > > Testing: > tier1-6 for Oracle supported platforms. > Build fastdebug linux-ppc64le and linux-s390x. This looks good overall to me. src/hotspot/share/oops/compressedOops.hpp line 142: > 140: // Shift by 32 is UB if size in bits of i is 32, e.g. on 32bit platform. > 141: assert(((i >> 16) >> 16) == 0, "narrowOop overflow"); > 142: return static_cast(static_cast(i)); Should we have an assert that further restricts the range according to max heap size? Also, should we allow only unsigned types for T? I think using signed types here is prone to error and should be flagged. ------------- Changes requested by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/273 From iklam at openjdk.java.net Mon Sep 21 21:44:21 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 21 Sep 2020 21:44:21 GMT Subject: RFR: 8247912: Make narrowOop a scoped enum In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 04:01:34 GMT, Kim Barrett wrote: > Please review this change to the type narrowOop from a typedef for juint to a > scoped enum with uint32_t as the representation type. This provides stronger > type checking when using this type. > > For the most part this was fairly straightforward, and the patch size is > relatively small. The implementation of some existing CompressedOops > "primitives" required adjustment. An explicit conversion to narrowOop was > added, with casts change to use it. There were a few places that were type > punning and needed explicit conversions,, mostly in platform-specific assembly > support. > > There are a couple of lingering problems. > > Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass > as a narrowOop. I adjusted the code to accommodate the narrowOop change, but > this probably ought to be done differently. > > There are a couple of `(narrowOop)` casts remaining in s390.ad. I'm not sure > whether these can be safely converted to CompressedOops::narrow_oop_cast. > > There might still be some casts from narrowOop to an integral type. Those are > hard to find in our cast-happy code base. > > Testing: > tier1-6 for Oracle supported platforms. > Build fastdebug linux-ppc64le and linux-s390x. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 179: > 177: // Move narrow OOP > 178: narrowOop noop = CompressedOops::encode((oop)o); > 179: CompressedOops::NarrowType n = CompressedOops::narrow_oop_value(noop); I think a public NarrowType is confusing (vs narrowOop). Since NarrowType is rarely used, and it's unlikely to be changed from uint32_t, maybe we should make NarrowType private, and change the above to uint32_t n = CompressedOops::encode_as_uint32_t((oop)o); Code that does arithmetic operations on the integer value probably wants to know the exact type anyway. I.e., not knowing whether NarrowType is signed or not makes me worry about the correctness of `n >> 16` below. ------------- PR: https://git.openjdk.java.net/jdk/pull/273 From iklam at openjdk.java.net Mon Sep 21 21:57:01 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 21 Sep 2020 21:57:01 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v2] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 18:17:55 GMT, Yumin Qi wrote: >> With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is >> specific to CDS. >> Tests: tier1-4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > 8253208: Move CDS related code to a separate class Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From minqi at openjdk.java.net Mon Sep 21 22:24:15 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 21 Sep 2020 22:24:15 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v3] In-Reply-To: References: Message-ID: <7yHEh89XlpTGoXfHw85_SVEKEBM0t03tQlkZ7tKm4P0=.399d9d6c-c375-4892-a92c-3cd6806e51d6@github.com> > With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is > specific to CDS. > Tests: tier1-4 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: 8253208: Move CDS related code to a separate class ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/261/files - new: https://git.openjdk.java.net/jdk/pull/261/files/c01deec7..953b6bac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=261&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=261&range=01-02 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/261.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/261/head:pull/261 PR: https://git.openjdk.java.net/jdk/pull/261 From adityam at openjdk.java.net Mon Sep 21 22:33:05 2020 From: adityam at openjdk.java.net (Aditya Mandaleeka) Date: Mon, 21 Sep 2020 22:33:05 GMT Subject: RFR: 8253349: Remove unimplemented SharedRuntime::native_method_throw_unsupported_operation_exception_entry In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 10:53:48 GMT, Aleksey Shipilev wrote: > The definition was removed in JDK-7196277 (confidential): > https://github.com/openjdk/jdk/commit/149097fbb751155cba49de38f8da5b39635198af > Declaration was left behind. > > Testing: > - [x] Linux x86_64 fastdebug build > - [x] Text search for `native_method_throw_unsupported_operation_exception_entry` in `src/hotspot` Marked as reviewed by adityam (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/244 From coleenp at openjdk.java.net Mon Sep 21 23:00:28 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 21 Sep 2020 23:00:28 GMT Subject: RFR: 8238761: Asynchronous handshakes [v4] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 12:19:09 GMT, Robbin Ehn wrote: >> This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes >> are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) >> Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an >> arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a >> singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first >> pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first >> pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake >> operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything >> except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed >> filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake >> operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there >> is now only one method to call when handshaking one thread. Some comments about the changes: >> - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake >> all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much >> worse then this. >> >> - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that >> thread. >> >> - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a >> handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. >> >> - Added WB testing method. >> >> - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. >> >> - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. >> >> - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a >> safepoint and half of them after, in many handshake all operations. >> >> - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. >> >> - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the >> moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. >> >> - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. >> >> - Added filtered queue and gtest for it. >> >> Passes multiple t1-8 runs. >> Been through some pre-reviwing. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since > the last revision: > - Update after Dan and David > - Merge branch 'master' into 8238761-asynchrounous-handshakes > - Removed double check, fix comment, removed not needed function, updated logs > - Fixed double checks > Added NSV > ProcessResult to enum > Fixed logging > Moved _active_handshaker to private > - Rebase version 1.0 Looks mostly good to me! src/hotspot/share/runtime/handshake.hpp line 55: > 53: }; > 54: > 55: class AsynchHandshakeClosure : public HandshakeClosure { Can you make this minor change? Asynch to english speakers looks like a-cinch and if left as Async is a-sink. Can you remove the 'h's ? I see David above left off the extra h, which is what one expects this to be named. src/hotspot/share/runtime/handshake.hpp line 78: > 76: FilterQueue _queue; > 77: Mutex _lock; > 78: Thread* _active_handshaker; Nit: can you line up the data member names for lock and _active_handshaker ? src/hotspot/share/runtime/handshake.cpp line 394: > 392: { > 393: NoSafepointVerifier nsv; > 394: process_self_inner(); Can you remove process_self_inner and just inline it here since this is it's only caller and both are short functions? If you don't want to, that's fine. I found myself searching for any other callers of this, that's all. ------------- Changes requested by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/151 From coleenp at openjdk.java.net Mon Sep 21 23:00:31 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 21 Sep 2020 23:00:31 GMT Subject: RFR: 8238761: Asynchronous handshakes [v4] In-Reply-To: References: Message-ID: <0buWd7Y3md8DLJOL6eIBdMu6vs8SVG9DzQy56OJkwsc=.6ce33107-0039-4d2c-885c-ee0961063d2a@github.com> On Mon, 21 Sep 2020 21:19:32 GMT, Coleen Phillimore wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev >> excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since >> the last revision: >> - Update after Dan and David >> - Merge branch 'master' into 8238761-asynchrounous-handshakes >> - Removed double check, fix comment, removed not needed function, updated logs >> - Fixed double checks >> Added NSV >> ProcessResult to enum >> Fixed logging >> Moved _active_handshaker to private >> - Rebase version 1.0 > > src/hotspot/share/runtime/handshake.hpp line 78: > >> 76: FilterQueue _queue; >> 77: Mutex _lock; >> 78: Thread* _active_handshaker; > > Nit: can you line up the data member names for lock and _active_handshaker ? FilterQueue _queue; JavaThread* _handshakee; Mutex _lock; Thread* _active_handshaker; Isn't this nicer? (it didn't keep the formatting in the comment) ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From coleenp at openjdk.java.net Mon Sep 21 23:00:31 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 21 Sep 2020 23:00:31 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 11:02:10 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/handshake.cpp line 313: >> >>> 311: } >>> 312: >>> 313: int executed_by_driver = 0; >> >> Again why driver?? Isn't it either the current thread or the target that will execute the op? > > The thread executing this handshake operation, what the current thread is doesn't matter. > You can't use current threads resources or be dependent otherwise on it. > > Exception being locking issues in JVM TI, where we are dependent that requester have locked JVM TI state lock for us, > but we are not dependent that the current thread is the owner. So checking that the lock is held by requester doesn't > matter for how is the 'driver'. The "driver" concept is odd. Should it really be caller? Like the thread that called VMHandshake? ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From coleenp at openjdk.java.net Mon Sep 21 23:03:45 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 21 Sep 2020 23:03:45 GMT Subject: RFR: 8238761: Asynchronous handshakes [v4] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 12:19:09 GMT, Robbin Ehn wrote: >> This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes >> are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) >> Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an >> arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a >> singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first >> pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first >> pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake >> operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything >> except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed >> filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake >> operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there >> is now only one method to call when handshaking one thread. Some comments about the changes: >> - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake >> all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much >> worse then this. >> >> - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that >> thread. >> >> - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a >> handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. >> >> - Added WB testing method. >> >> - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. >> >> - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. >> >> - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a >> safepoint and half of them after, in many handshake all operations. >> >> - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. >> >> - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the >> moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. >> >> - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. >> >> - Added filtered queue and gtest for it. >> >> Passes multiple t1-8 runs. >> Been through some pre-reviwing. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since > the last revision: > - Update after Dan and David > - Merge branch 'master' into 8238761-asynchrounous-handshakes > - Removed double check, fix comment, removed not needed function, updated logs > - Fixed double checks > Added NSV > ProcessResult to enum > Fixed logging > Moved _active_handshaker to private > - Rebase version 1.0 test/hotspot/jtreg/runtime/handshake/HandshakeDirectTest.java line 42: > 40: public class HandshakeDirectTest implements Runnable { > 41: static final int WORKING_THREADS = 32; > 42: static final int DIRECT_HANDSHAKES_MARK = 500000; Could this timeout? ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From sspitsyn at openjdk.java.net Tue Sep 22 00:41:05 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 22 Sep 2020 00:41:05 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 07:45:52 GMT, Goetz Lindenmaier wrote: >> Marked as reviewed by goetz (Reviewer). > > Reviewed in the good old hg times :) > See also http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041453.html src/hotspot/share/opto/macro.cpp: @@ -1091,11 +1091,11 @@ bool PhaseMacroExpand::eliminate_allocate_node(AllocateNode *alloc) { // Don't do scalar replacement if the frame can be popped by JVMTI: // if reallocation fails during deoptimization we'll pop all // interpreter frames for this compiled frame and that won't play // nice with JVMTI popframe. - if (!EliminateAllocations || JvmtiExport::can_pop_frame() || !alloc->_is_non_escaping) { + if (!EliminateAllocations || !alloc->_is_non_escaping) { return false; } I wonder if the comment is still correct after you removed the check for JvmtiExport::can_pop_frame(). ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From sspitsyn at openjdk.java.net Tue Sep 22 01:37:23 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 22 Sep 2020 01:37:23 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 00:38:43 GMT, Serguei Spitsyn wrote: >> Reviewed in the good old hg times :) >> See also http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041453.html > > Hi Richard, > > Could you consider to place the classes EscapeBarrier and JvmtiDeferredUpdates into theyr own .hpp/.cpp files? The > class JvmtiDeferredUpdates would be better to put into the folder 'prims' then. > src/hotspot/share/opto/macro.cpp: > @@ -1091,11 +1091,11 @@ > bool PhaseMacroExpand::eliminate_allocate_node(AllocateNode *alloc) { > // Don't do scalar replacement if the frame can be popped by JVMTI: > // if reallocation fails during deoptimization we'll pop all > // interpreter frames for this compiled frame and that won't play > // nice with JVMTI popframe. > - if (!EliminateAllocations || JvmtiExport::can_pop_frame() || !alloc->_is_non_escaping) { > + if (!EliminateAllocations || !alloc->_is_non_escaping) { > return false; > } > > I wonder if the comment is still correct after you removed the check for JvmtiExport::can_pop_frame(). > > src/hotspot/share/runtime/deoptimization.hpp: > > + EscapeBarrier(JavaThread* calling_thread, JavaThread* deoptee_thread, bool barrier_active) > + : _calling_thread(calling_thread), _deoptee_thread(deoptee_thread), > + _barrier_active(barrier_active && (JVMCI_ONLY(UseJVMCICompiler) NOT_JVMCI(false) > + COMPILER2_PRESENT(|| DoEscapeAnalysis))) > . . . . . . . . . > + > + // Revert ea based optimizations for all java threads > + EscapeBarrier(JavaThread* calling_thread, bool barrier_active) > + : _calling_thread(calling_thread), _deoptee_thread(NULL), > > Nit: would better to make the parameter deoptee_thread to be the 3rd to better mach the seconf constructor. > > + bool all_threads() const { return _deoptee_thread == NULL; } // Should revert optimizations for all > threads. + bool self_deopt() const { return _calling_thread == _deoptee_thread; } // Current thread deoptimizes > its own objects. + bool barrier_active() const { return _barrier_active; } // Inactive barriers are > created if no local objects can escape. > I'd suggest to put comments in a line before function definitions as it is done for other declarations/definitions. src/hotspot/share/runtime/deoptimization.cpp: @@ -349,12 +408,12 @@ // Now that the vframeArray has been created if we have any deferred local writes // added by jvmti then we can free up that structure as the data is now in the // vframeArray - if (thread->deferred_locals() != NULL) { - GrowableArray* list = thread->deferred_locals(); + if (JvmtiDeferredUpdates::deferred_locals(thread) != NULL) { + GrowableArray* list = JvmtiDeferredUpdates::deferred_locals(thread); int i = 0; do { // Because of inlining we could have multiple vframes for a single frame // and several of the vframes could have deferred writes. Find them all. if (list->at(i)->id() == array->original().id()) { @@ -365,13 +424,14 @@ } else { i++; } } while ( i < list->length() ); if (list->length() == 0) { - thread->set_deferred_locals(NULL); - // free the list and elements back to C heap. - delete list; + JvmtiDeferredUpdates* updates = thread->deferred_updates(); + thread->set_deferred_updates(NULL); + // free deferred updates. + delete updates; } It is not clear why the 'list' is not deleted anymore. If it is intentional then could you, please, add a comment with an explanation? ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From jcm at openjdk.java.net Tue Sep 22 01:56:31 2020 From: jcm at openjdk.java.net (Jamsheed Mohammed C M) Date: Tue, 22 Sep 2020 01:56:31 GMT Subject: RFR: 8253447: Remove buggy code introduced by 8249451 Message-ID: if ((thread->has_pending_exception() || thread->frames_to_pop_failed_realloc() > 0) && exec_mode != Unpack_uncommon_trap) { assert(thread->has_pending_exception(), "should have thrown OOME/Async"); introduced a buggy code checking, clearing pending exception and taking Unpack_exception route. This can have consequences as the deopt entries may have additional logic depending on bci's. and the change introduced in 8249451 doesn't honor deopt exception checking and forward logic. Thank you @fisk for pointing the bug in the code. Request for review. ------------- Commit messages: - fixing buggy code introduced in 8249451 Changes: https://git.openjdk.java.net/jdk/pull/292/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=292&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253447 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/292/head:pull/292 PR: https://git.openjdk.java.net/jdk/pull/292 From jcm at openjdk.java.net Tue Sep 22 02:05:01 2020 From: jcm at openjdk.java.net (Jamsheed Mohammed C M) Date: Tue, 22 Sep 2020 02:05:01 GMT Subject: RFR: 8253447: Remove buggy code introduced by 8249451 In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 01:48:53 GMT, Jamsheed Mohammed C M wrote: > if ((thread->has_pending_exception() || thread->frames_to_pop_failed_realloc() > 0) && exec_mode != > Unpack_uncommon_trap) { > assert(thread->has_pending_exception(), "should have thrown OOME/Async"); > > introduced a buggy code checking, clearing pending exception and taking Unpack_exception route. > > This can have consequences as the deopt entries may have additional logic depending on bci's. and the change introduced > in 8249451 doesn't honor deopt exception checking and forward logic. Thank you @fisk for pointing the bug in the code. > Request for review. @dholmes-ora @veresov @fisk could you please have a look. ------------- PR: https://git.openjdk.java.net/jdk/pull/292 From jcm at openjdk.java.net Tue Sep 22 02:05:01 2020 From: jcm at openjdk.java.net (Jamsheed Mohammed C M) Date: Tue, 22 Sep 2020 02:05:01 GMT Subject: RFR: 8253447: Remove buggy code introduced by 8249451 [v2] In-Reply-To: References: Message-ID: <-1narCtDccARvrE8LbvdKMuaDtBU9f_08MJjysQ7xB0=.19e1536d-5d9d-4e4b-a1fc-9249e735fbd1@github.com> > if ((thread->has_pending_exception() || thread->frames_to_pop_failed_realloc() > 0) && exec_mode != > Unpack_uncommon_trap) { > assert(thread->has_pending_exception(), "should have thrown OOME/Async"); > > introduced a buggy code checking, clearing pending exception and taking Unpack_exception route. > > This can have consequences as the deopt entries may have additional logic depending on bci's. and the change introduced > in 8249451 doesn't honor deopt exception checking and forward logic. Thank you @fisk for pointing the bug in the code. > Request for review. Jamsheed Mohammed C M has updated the pull request incrementally with one additional commit since the last revision: fixing the assert message too ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/292/files - new: https://git.openjdk.java.net/jdk/pull/292/files/d81ce188..4eea9a95 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=292&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=292&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/292.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/292/head:pull/292 PR: https://git.openjdk.java.net/jdk/pull/292 From dholmes at openjdk.java.net Tue Sep 22 02:05:25 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 22 Sep 2020 02:05:25 GMT Subject: RFR: 8253262: Allocate in DumpRegion is not thread safe In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 16:22:40 GMT, Yumin Qi wrote: >> It seems to me that the need for locking should be an internal implementation detail of >> MetaspaceShared::symbol_space_alloc, rather than Symbol operator new. > >> It seems to me that the need for locking should be an internal implementation detail of >> MetaspaceShared::symbol_space_alloc, rather than Symbol operator new. > > I pushed before saw your above comment. The reason for current place is because the following code: > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/symbol.cpp#L75 > DEBUG_ONLY(static void* last = 0); > void* p = (void*)MetaspaceShared::symbol_space_alloc(size(len)*wordSize); > assert(p > last, "must increase monotonically"); > DEBUG_ONLY(last = p); > return p; > this 'last' is not thread safe either. My comment was made after the integration so no issue there. But I think the monotonicity check also belongs inside MetaspaceShared::symbol_space_alloc ------------- PR: https://git.openjdk.java.net/jdk/pull/216 From iveresov at openjdk.java.net Tue Sep 22 02:26:07 2020 From: iveresov at openjdk.java.net (Igor Veresov) Date: Tue, 22 Sep 2020 02:26:07 GMT Subject: RFR: 8253447: Remove buggy code introduced by 8249451 [v2] In-Reply-To: <-1narCtDccARvrE8LbvdKMuaDtBU9f_08MJjysQ7xB0=.19e1536d-5d9d-4e4b-a1fc-9249e735fbd1@github.com> References: <-1narCtDccARvrE8LbvdKMuaDtBU9f_08MJjysQ7xB0=.19e1536d-5d9d-4e4b-a1fc-9249e735fbd1@github.com> Message-ID: On Tue, 22 Sep 2020 02:05:01 GMT, Jamsheed Mohammed C M wrote: >> if ((thread->has_pending_exception() || thread->frames_to_pop_failed_realloc() > 0) && exec_mode != >> Unpack_uncommon_trap) { >> assert(thread->has_pending_exception(), "should have thrown OOME/Async"); >> >> introduced a buggy code checking, clearing pending exception and taking Unpack_exception route. >> >> This can have consequences as the deopt entries may have additional logic depending on bci's. and the change introduced >> in 8249451 doesn't honor deopt exception checking and forward logic. Thank you @fisk for pointing the bug in the code. >> Request for review. > > Jamsheed Mohammed C M has updated the pull request incrementally with one additional commit since the last revision: > > fixing the assert message too Marked as reviewed by iveresov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/292 From kvn at openjdk.java.net Tue Sep 22 02:34:04 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 22 Sep 2020 02:34:04 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> <2dlrgVtF5twY9WGHEKS2ZcLEm1jPmGgOfFF6o-ZyUHc=.c33e5814-724a-4569-9eed-97e8afaaa440@github.com> Message-ID: On Mon, 21 Sep 2020 09:20:56 GMT, Andrew Dinn wrote: >>> Can you explain where this restricted effect is documented? >> >> Certainly! I?ve found that determining the capability of the CPU and whether to enable AVX2 support if the chip >> supports it is mostly controlled in: [vm_version_x86.cpp]( >> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp) specifically: >> [get_processor_features](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L684-L755) >> and in [generate_get_cpu_info]( >> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L69-L611). In order to test the >> patch comprehensively I had to track down an Intel Core i7 (I7-9750H) processor which the aforementioned code permitted >> AVX2 instructions for (maybe this is an error and it should not be enabled for this processor though) as most of the >> infrastructure I personally use here at AWS runs on Intel Xeon processors - I also tested on a E5-2680 which the JVM >> does not enable AVX2 for. However, this is just the Intel side of things. When it comes to AMD I read that the AMD Zen >> 2 architecture, of which the current flagship: Threadripper 3990X, is based, is able to support AVX2 [without the >> frequency scaling]( >> https://www.anandtech.com/Show/Index/14525?cPage=7&all=False&sort=0&page=9&slug=amd-zen-2-microarchitecture-analysis-ryzen-3000-and-epyc-rome) >> which some/all(?) of the Intel chips incur. I personally don?t have access to one of these chips so I cannot confirm >> how it is classified in the JVM. Also, I found when investigating this that there is actually a JVM flag which can be >> used to control what level of AVX is enabled: `-XX:UseAVX=version.` > >> > Can you explain where this restricted effect is documented? > >> Certainly! I?ve found that determining the capability of the CPU and whether to enable AVX2 support if the chip >> supports it is mostly controlled in: vm_version_x86.cpp specifically: get_processor_features and in >> generate_get_cpu_info. > > Yes, I can see what the code does. I was asking where the cpu behaviour is documented independent of the code. > >> In order to test the patch comprehensively I had to track down an Intel Core i7 (I7-9750H) processor which the >> aforementioned code permitted AVX2 instructions for (maybe this is an error and it should not be enabled for this >> processor though) as most of the infrastructure I personally use here at AWS runs on Intel Xeon processors - I also >> tested on a E5-2680 which the JVM does not enable AVX2 for. > > 'maybe'? The documentation Andrew provided mentioned Xeon E5 v3 which I believe is a Skylake design. However, the code > I pointed you at in vm_version_x86 which claims to detect 'early Skylake' designs is only disabling AVX512 support. It > still enables AVX2. Similarly, the code that generates machine code to check the processor capabilities has a special > check if use_evex is set (i.e. AVX3 is requested) which disables AVX512 for Skylake but does not disable AVX2 support. >> However, this is just the Intel side of things. When it comes to AMD I read that the AMD Zen 2 architecture, of which >> the current flagship: Threadripper 3990X, is based, is able to support AVX2 without the frequency scaling which >> some/all(?) of the Intel chips incur. I personally don?t have access to one of these chips so I cannot confirm how it >> is classified in the JVM. > > Well, it would be good to know where you read that and to see if that confirms thar the code is avoiding the issue > Andrew raised. >> Also, I found when investigating this that there is actually a JVM flag which can be used to control what level of AVX >> is enabled: -XX:UseAVX=version. > > Yes, indeed. However, what I am trying to understand is whether the current code is bypassing the problem Andrew > brought up in the cases where that problem actually exists. It doesn't look like it so far given that the problem > applies to AVX2 and only AVX512 support is being disabled and, even then only for some (Skylake) processors. Without > some clear documentation of what processors suffer from this power surge problem it will not be possible to decide > whether this patch is doing the right thing or not. Based on comment by @jatin-bhateja (Intel) frequency level switchover pointed by @theRealAph is sensitive to vector size https://github.com/openjdk/jdk/pull/144#issuecomment-692044896 By keeping vector size less or equal to 32 bytes we should avoid it. And as I can see this intrinsic code is using 32 bytes (chars) and 16 bytes vectors: `pbroadcastb(vec1, vec1, Assembler::AVX_256bit);` Also we never had issues with AVX2. only with AVX512 regarding performance hit: https://bugs.openjdk.java.net/browse/JDK-8221092 I would like to see performance numbers for for all values of UseAVX flag : 0, 1, 2, 3 The usage is guarded UseSSE42Intrinsics in UseSSE42Intrinsics predicate in .ad file. Make sure to test with UseAVX=0 to make sure that some avx instructions are not mixed into non avx code. And also with UseSSE=2 (for example) to make sure shared code correctly recognize that intrinsics is not supported. ------------- PR: https://git.openjdk.java.net/jdk/pull/71 From dholmes at openjdk.java.net Tue Sep 22 02:37:56 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 22 Sep 2020 02:37:56 GMT Subject: RFR: 8253447: Remove buggy code introduced by 8249451 [v2] In-Reply-To: <-1narCtDccARvrE8LbvdKMuaDtBU9f_08MJjysQ7xB0=.19e1536d-5d9d-4e4b-a1fc-9249e735fbd1@github.com> References: <-1narCtDccARvrE8LbvdKMuaDtBU9f_08MJjysQ7xB0=.19e1536d-5d9d-4e4b-a1fc-9249e735fbd1@github.com> Message-ID: On Tue, 22 Sep 2020 02:05:01 GMT, Jamsheed Mohammed C M wrote: >> if ((thread->has_pending_exception() || thread->frames_to_pop_failed_realloc() > 0) && exec_mode != >> Unpack_uncommon_trap) { >> assert(thread->has_pending_exception(), "should have thrown OOME/Async"); >> >> introduced a buggy code checking, clearing pending exception and taking Unpack_exception route. >> >> This can have consequences as the deopt entries may have additional logic depending on bci's. and the change introduced >> in 8249451 doesn't honor deopt exception checking and forward logic. Thank you @fisk for pointing the bug in the code. >> Request for review. > > Jamsheed Mohammed C M has updated the pull request incrementally with one additional commit since the last revision: > > fixing the assert message too src/hotspot/share/runtime/deoptimization.cpp line 531: > 529: #endif > 530: > 531: if (thread->frames_to_pop_failed_realloc() > 0 && exec_mode != Unpack_uncommon_trap) { I'm not at all clear on whether an async-exception could be pending at this point. The original change indicated it could be, but now you are saying it can't. How is that known? ------------- PR: https://git.openjdk.java.net/jdk/pull/292 From dholmes at openjdk.java.net Tue Sep 22 03:14:32 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 22 Sep 2020 03:14:32 GMT Subject: RFR: 8238761: Asynchronous handshakes [v4] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 22:57:55 GMT, Coleen Phillimore wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev >> excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since >> the last revision: >> - Update after Dan and David >> - Merge branch 'master' into 8238761-asynchrounous-handshakes >> - Removed double check, fix comment, removed not needed function, updated logs >> - Fixed double checks >> Added NSV >> ProcessResult to enum >> Fixed logging >> Moved _active_handshaker to private >> - Rebase version 1.0 > > Looks mostly good to me! Hi Robbin, I've gone back to refresh myself on the previous discussions and (internal) design walk-throughs to get a better sense of these changes. Really the "asynchronous handshake" aspect is only a small part of this. The fundamental change here is that handshakes are now maintained via a per-thread queue, and those handshake operations can, in the general case, be executed by any of the target thread, the requestor (active_handshaker) thread or the VMThread. Hence the removal of the various "JavaThread::current()" assumptions. Unless constrained otherwise, any handshake operation may be executed by the VMThread so we have to take extra care to ensure the code is written to allow this. I'm a little concerned that our detour into direct-handshakes actually lulled us into a false sense of security knowing that an operation would always execute in a JavaThread, and we have now reverted that and allowed the VMThread back in. I understand why, but the change in direction here caught me by surprise (as I had forgotten the bigger picture). It may not always be obvious that the transitive closure of the code from an operation can be safely executed by a non-JavaThread. Then on top of this generalized queuing mechanism there is a filter which allows some control over which thread may perform a given operation - at the moment the only filter isolates "async" operations which only the target thread can execute. In addition another nuance is that when processing a given thread's handshake operation queue, different threads have different criteria for when to stop processing the queue: - the target thread will drain the queue completely - the VMThread will drain the queue of all "non-async" operations** - the initiator for a "direct" operation will drain the queue up to, and including, the synchronous operation they submitted - the initiator for an "async" operation will not process any operation themselves and will simply add to the queue and then continue on their way (hence the "asynchronous") ** I do have some concerns about latency impact on the VMThread if it is used to execute operations that didn't need to be executed by the VMThread! I remain concerned about the terminology conflation that happens around "async handshakes". There are two aspects that need to be separated: - the behaviour of the thread initiating the handshake operation; and - which thread can execute the handshake operation When a thread initiates a handshake operation and waits until that operation is complete (regardless of which thread performed it, or whether the initiator processed any other operations) that is a synchronous handshake operation. When a thread initiates a handshake operation and does not wait for the operation to complete (it does the target->queue()->add(op); and continues on its way) that is an asynchronous handshake operation. The question of whether the operation must be executed by the target thread is orthogonal to whether the operation was submitted as a synchronous or asynchronous operation. So I have problem when you say that an asynchronous handshake operation is one that must be executed by the target thread, as this is not the right characterisation at all. It is okay to constrain things such that an async operation is always executed by the target, but that is not what makes it an async operation. In the general case there is no reason why an async operation might not be executed by the VMThread, or some other JavaThread performing a synchronous operation on the same target. I will go back through the actual handshake code to see if there are specific things I would like to see changed, but that will have to wait until tomorrow. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From jcm at openjdk.java.net Tue Sep 22 03:15:59 2020 From: jcm at openjdk.java.net (Jamsheed Mohammed C M) Date: Tue, 22 Sep 2020 03:15:59 GMT Subject: RFR: 8253447: Remove buggy code introduced by 8249451 [v2] In-Reply-To: References: <-1narCtDccARvrE8LbvdKMuaDtBU9f_08MJjysQ7xB0=.19e1536d-5d9d-4e4b-a1fc-9249e735fbd1@github.com> Message-ID: <4UXzkGK0txAGnug89GEPNmT58axvNWBQ1aNwtb85uBI=.f08c488e-79e3-4c73-adc6-54788999eff7@github.com> On Tue, 22 Sep 2020 02:35:17 GMT, David Holmes wrote: >> Jamsheed Mohammed C M has updated the pull request incrementally with one additional commit since the last revision: >> >> fixing the assert message too > > src/hotspot/share/runtime/deoptimization.cpp line 531: > >> 529: #endif >> 530: >> 531: if (thread->frames_to_pop_failed_realloc() > 0 && exec_mode != Unpack_uncommon_trap) { > > I'm not at all clear on whether an async-exception could be pending at this point. The original change indicated it > could be, but now you are saying it can't. How is that known? Async-exception can be pending for Deoptimization::load_class_by_index(Java code executed case). This can happen for C2/ and probably for JVMCI too. https://github.com/openjdk/jdk/blob/d1f9b8a8b54843f06a93078c4a058af86fcc2aac/src/hotspot/share/runtime/deoptimization.cpp#L1964 In all cases deopt entries are equipped to handle pending exceptions. In my previous code I incorrectly tried to handle it using Unpack_exception route. this can have implication that I am at method entry and I don't handle locks properly. now i simply leave it to the deopt entries to handle pending exceptions. ------------- PR: https://git.openjdk.java.net/jdk/pull/292 From kvn at openjdk.java.net Tue Sep 22 03:37:25 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 22 Sep 2020 03:37:25 GMT Subject: RFR: 8252847: New AVX512 optimized stubs for both conjoint and disjoint arraycopy [v3] In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 11:19:42 GMT, Nils Eliasson wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8252847: Review comments resolution > > Thanks for the clarification och update! > > Reviewed. @jatin-bhateja Can you put summary of performance improvement into JBS? ------------- PR: https://git.openjdk.java.net/jdk/pull/61 From dholmes at openjdk.java.net Tue Sep 22 04:16:30 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 22 Sep 2020 04:16:30 GMT Subject: RFR: 8253447: Remove buggy code introduced by 8249451 [v2] In-Reply-To: <4UXzkGK0txAGnug89GEPNmT58axvNWBQ1aNwtb85uBI=.f08c488e-79e3-4c73-adc6-54788999eff7@github.com> References: <-1narCtDccARvrE8LbvdKMuaDtBU9f_08MJjysQ7xB0=.19e1536d-5d9d-4e4b-a1fc-9249e735fbd1@github.com> <4UXzkGK0txAGnug89GEPNmT58axvNWBQ1aNwtb85uBI=.f08c488e-79e3-4c73-adc6-54788999eff7@github.com> Message-ID: <4AAQXW3Vy9cWsNdT55xzsW51g2voP0hktq_dGTwR6y0=.cab032ef-a8e3-441c-ad9c-ebf2a2fb8075@github.com> On Tue, 22 Sep 2020 03:13:04 GMT, Jamsheed Mohammed C M wrote: >> src/hotspot/share/runtime/deoptimization.cpp line 531: >> >>> 529: #endif >>> 530: >>> 531: if (thread->frames_to_pop_failed_realloc() > 0 && exec_mode != Unpack_uncommon_trap) { >> >> I'm not at all clear on whether an async-exception could be pending at this point. The original change indicated it >> could be, but now you are saying it can't. How is that known? > > Async-exception can be pending for Deoptimization::load_class_by_index(Java code executed case). This can happen for > C2/ and probably for JVMCI too. > https://github.com/openjdk/jdk/blob/d1f9b8a8b54843f06a93078c4a058af86fcc2aac/src/hotspot/share/runtime/deoptimization.cpp#L1964 > In all cases deopt entries are equipped to handle pending exceptions. > In my previous code I incorrectly tried to handle it using Unpack_exception route. this can have implication that I am > at method entry and I don't handle locks properly. > now i simply leave it to the deopt entries to handle pending exceptions. Okay. I'm not familiar with that code at all so will leave this for compiler folk. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/292 From github.com+35809+mknjc at openjdk.java.net Tue Sep 22 04:56:09 2020 From: github.com+35809+mknjc at openjdk.java.net (mknjc) Date: Tue, 22 Sep 2020 04:56:09 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> <2dlrgVtF5twY9WGHEKS2ZcLEm1jPmGgOfFF6o-ZyUHc=.c33e5814-724a-4569-9eed-97e8afaaa440@github.com> Message-ID: On Fri, 18 Sep 2020 23:11:46 GMT, Jason Tatton wrote: >> "the JVM has knowledge of the AVX capability of the chip it?s running on and disables the AVX2 code path for chips >> which suffer from the performance degradation which has been outlined in this discussion" >> Does it? The white paper Andrew cited doesn't mention this as being specific to only some chips that implement AVX2. >> Can you explain where this restricted effect is documented? >> Also, I assume you are referring to the code in vm_version_x86.cpp with this comment >> >> // Don't use AVX-512 on older Skylakes unless explicitly requested >> >> is that correct? > >> Can you explain where this restricted effect is documented? > > Certainly! I?ve found that determining the capability of the CPU and whether to enable AVX2 support if the chip > supports it is mostly controlled in: [vm_version_x86.cpp]( > https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp) specifically: > [get_processor_features](https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L684-L755) > and in [generate_get_cpu_info]( > https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/vm_version_x86.cpp#L69-L611). In order to test the > patch comprehensively I had to track down an Intel Core i7 (I7-9750H) processor which the aforementioned code permitted > AVX2 instructions for (maybe this is an error and it should not be enabled for this processor though) as most of the > infrastructure I personally use here at AWS runs on Intel Xeon processors - I also tested on a E5-2680 which the JVM > does not enable AVX2 for. However, this is just the Intel side of things. When it comes to AMD I read that the AMD Zen > 2 architecture, of which the current flagship: Threadripper 3990X, is based, is able to support AVX2 [without the > frequency scaling]( > https://www.anandtech.com/Show/Index/14525?cPage=7&all=False&sort=0&page=9&slug=amd-zen-2-microarchitecture-analysis-ryzen-3000-and-epyc-rome) > which some/all(?) of the Intel chips incur. I personally don?t have access to one of these chips so I cannot confirm > how it is classified in the JVM. Also, I found when investigating this that there is actually a JVM flag which can be > used to control what level of AVX is enabled: `-XX:UseAVX=version.` I really don't see the problem with using AVX for this? As long as the used instructions all only activate license l0 the cpu don't scale the frequency at all. For AVX2 these are most of all instructions which don't use the FMA or floating point ports. Additionally the cpu doesn't instant scale down the frequency but runs the 256 bit instructions with reduced throughput but full cpu clock until enough instructions use the avx command set. For more information see https://stackoverflow.com/a/56861355/130541 So as long the 512bit width instructions aren't used there should no frequency scaling happening. ------------- PR: https://git.openjdk.java.net/jdk/pull/71 From github.com+471021+marschall at openjdk.java.net Tue Sep 22 05:26:31 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Tue, 22 Sep 2020 05:26:31 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v3] In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate ------------- Changes: https://git.openjdk.java.net/jdk/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=02 Stats: 748 lines in 64 files changed: 149 ins; 149 del; 450 mod Patch: https://git.openjdk.java.net/jdk/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk/pull/45 From kustos at gmx.net Tue Sep 22 05:57:45 2020 From: kustos at gmx.net (Philippe Marschall) Date: Tue, 22 Sep 2020 07:57:45 +0200 Subject: Looking for a sponsor for JDK-8138732 Message-ID: <17d66481-a8d2-8f37-857e-9e1e9707b700@gmx.net> Hello I am looking for a sponsor for JDK-8138732 [1]. The ready to integrate PR is here [2]. Changes between the current code and the reviewed code: - I removed the jdk.internal export to jdk.jfr, that was a review comment. - I had to rebase and resolve a merge conflict with JDK-8243066. [1] https://bugs.openjdk.java.net/browse/JDK-8138732 [2] https://github.com/openjdk/jdk/pull/45 Cheers Philippe From iklam at openjdk.java.net Tue Sep 22 06:08:05 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 22 Sep 2020 06:08:05 GMT Subject: RFR: 8081833: Clean up JVMFlag getter/setter code [v3] In-Reply-To: References: Message-ID: > This is a follow to [JDK-8243208 Clean up JVMFlag implementation](https://bugs.openjdk.java.net/browse/JDK-8243208). > > I try to use templates and inheritance (and a bit of macros) to get rid of the large amount of duplicated code in the > JVMFlag getters/setters. > Stefan Karlsson and I have tried this several times already, but I think the current attempt probably has the least > amount of hacks and most functionality: > - Type safety is enforced up to the point of loading/storing `JVMFlag::_addr`, without any unchecked typecasts. > - Runtime type checking is implemented by the `JVM_FLAG_TYPE(t)` macro (see jvmFlagAccess.hpp), by passing along an > integer (`JVMFlag::TYPE_int`, etc). This is more efficient than previous attempts that passed along a function pointer > (see http://cr.openjdk.java.net/~stefank/8081833/webrev.04/) > - The old `JVMFlag::xxxAtPut` functions were undocumented. There are actually two groups that have different usage. I > added documentation in jvmFlagAccess.hpp to explain this. > - I got rid of the `JVMFlagEx` class and moved the code into `JVMFlag`. This is possible with C++11 which allows forward > declaration of `enum JVMFlagsEnum : int;` > - I changed `JVMFlag::_type` from a string into an enum. I am surprised this had lasted for over 20 years. > - I also changed `JVMFlag` from a struct into a class and made some fields private. I probably will do more cleanup in a > separate RFE. > > Please start with jvmFlagAccess.hpp, jvmFlagAccess.hpp and then globals_extension.hpp. > > Probably not everyone is in love with the `JVM_FLAG_TYPE(t)` macro. I'll be happy to try out alternatives. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into 8081833-clean-up-jvmflag-get-set - Updated according to feedback from Gerard and Coleen - 8081833: Clean up JVMFlag getter/setter code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/163/files - new: https://git.openjdk.java.net/jdk/pull/163/files/696a9412..2d9d16a1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=163&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=163&range=01-02 Stats: 9075 lines in 349 files changed: 5276 ins; 2932 del; 867 mod Patch: https://git.openjdk.java.net/jdk/pull/163.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/163/head:pull/163 PR: https://git.openjdk.java.net/jdk/pull/163 From iklam at openjdk.java.net Tue Sep 22 06:08:07 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 22 Sep 2020 06:08:07 GMT Subject: Integrated: 8081833: Clean up JVMFlag getter/setter code In-Reply-To: References: Message-ID: On Tue, 15 Sep 2020 05:01:13 GMT, Ioi Lam wrote: > This is a follow to [JDK-8243208 Clean up JVMFlag implementation](https://bugs.openjdk.java.net/browse/JDK-8243208). > > I try to use templates and inheritance (and a bit of macros) to get rid of the large amount of duplicated code in the > JVMFlag getters/setters. > Stefan Karlsson and I have tried this several times already, but I think the current attempt probably has the least > amount of hacks and most functionality: > - Type safety is enforced up to the point of loading/storing `JVMFlag::_addr`, without any unchecked typecasts. > - Runtime type checking is implemented by the `JVM_FLAG_TYPE(t)` macro (see jvmFlagAccess.hpp), by passing along an > integer (`JVMFlag::TYPE_int`, etc). This is more efficient than previous attempts that passed along a function pointer > (see http://cr.openjdk.java.net/~stefank/8081833/webrev.04/) > - The old `JVMFlag::xxxAtPut` functions were undocumented. There are actually two groups that have different usage. I > added documentation in jvmFlagAccess.hpp to explain this. > - I got rid of the `JVMFlagEx` class and moved the code into `JVMFlag`. This is possible with C++11 which allows forward > declaration of `enum JVMFlagsEnum : int;` > - I changed `JVMFlag::_type` from a string into an enum. I am surprised this had lasted for over 20 years. > - I also changed `JVMFlag` from a struct into a class and made some fields private. I probably will do more cleanup in a > separate RFE. > > Please start with jvmFlagAccess.hpp, jvmFlagAccess.hpp and then globals_extension.hpp. > > Probably not everyone is in love with the `JVM_FLAG_TYPE(t)` macro. I'll be happy to try out alternatives. This pull request has now been integrated. Changeset: 282b9dcf Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/282b9dcf Stats: 2277 lines in 26 files changed: 1389 ins; 670 del; 218 mod 8081833: Clean up JVMFlag getter/setter code Reviewed-by: gziemski, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/163 From eosterlund at openjdk.java.net Tue Sep 22 06:23:34 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 22 Sep 2020 06:23:34 GMT Subject: RFR: 8253447: Remove buggy code introduced by 8249451 [v2] In-Reply-To: <4AAQXW3Vy9cWsNdT55xzsW51g2voP0hktq_dGTwR6y0=.cab032ef-a8e3-441c-ad9c-ebf2a2fb8075@github.com> References: <-1narCtDccARvrE8LbvdKMuaDtBU9f_08MJjysQ7xB0=.19e1536d-5d9d-4e4b-a1fc-9249e735fbd1@github.com> <4UXzkGK0txAGnug89GEPNmT58axvNWBQ1aNwtb85uBI=.f08c488e-79e3-4c73-adc6-54788999eff7@github.com> <4AAQXW3Vy9cWsNdT55xzsW51g2voP0hktq_dGTwR6y0=.cab032ef-a8e3-441c-ad9c-ebf2a2fb8075@github.com> Message-ID: On Tue, 22 Sep 2020 04:13:26 GMT, David Holmes wrote: >> Async-exception can be pending for Deoptimization::load_class_by_index(Java code executed case). This can happen for >> C2/ and probably for JVMCI too. >> https://github.com/openjdk/jdk/blob/d1f9b8a8b54843f06a93078c4a058af86fcc2aac/src/hotspot/share/runtime/deoptimization.cpp#L1964 >> In all cases deopt entries are equipped to handle pending exceptions. >> In my previous code I incorrectly tried to handle it using Unpack_exception route. this can have implication that I am >> at method entry and I don't handle locks properly. >> now i simply leave it to the deopt entries to handle pending exceptions. > > Okay. I'm not familiar with that code at all so will leave this for compiler folk. Thanks. So basically when you get here through the uncommon trap path, you have just called a JRT_ENTRY function and returned from it by now. That means you can have an async exception installed as a pending exception. If you just leave it there, the deopt entry of the interpreter will check for it and throw it. So we were already equipped to deal with this, and that is what should happen. The code that clears the pending exception and sets the exception oop instead is for when you are unwinding due to exception throwing into a deoptimized frame. The deopt handler is returned as exception handler PC for such frames, and hence needs to quack like an exception handler. But that is not at all the scenario we are in when we go through the uncommon trap; we are not in the middle of throwing an exception. Conversely, we are just about to throw it - that difference is the crucial thing. So clearing the pending exception is likely to just make it disappear (or crash later). ------------- PR: https://git.openjdk.java.net/jdk/pull/292 From eosterlund at openjdk.java.net Tue Sep 22 06:23:34 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 22 Sep 2020 06:23:34 GMT Subject: RFR: 8253447: Remove buggy code introduced by 8249451 [v2] In-Reply-To: <-1narCtDccARvrE8LbvdKMuaDtBU9f_08MJjysQ7xB0=.19e1536d-5d9d-4e4b-a1fc-9249e735fbd1@github.com> References: <-1narCtDccARvrE8LbvdKMuaDtBU9f_08MJjysQ7xB0=.19e1536d-5d9d-4e4b-a1fc-9249e735fbd1@github.com> Message-ID: On Tue, 22 Sep 2020 02:05:01 GMT, Jamsheed Mohammed C M wrote: >> if ((thread->has_pending_exception() || thread->frames_to_pop_failed_realloc() > 0) && exec_mode != >> Unpack_uncommon_trap) { >> assert(thread->has_pending_exception(), "should have thrown OOME/Async"); >> >> introduced a buggy code checking, clearing pending exception and taking Unpack_exception route. >> >> This can have consequences as the deopt entries may have additional logic depending on bci's. and the change introduced >> in 8249451 doesn't honor deopt exception checking and forward logic. Thank you @fisk for pointing the bug in the code. >> Request for review. > > Jamsheed Mohammed C M has updated the pull request incrementally with one additional commit since the last revision: > > fixing the assert message too Looks good, thanks for fixing this. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/292 From jcm at openjdk.java.net Tue Sep 22 06:29:39 2020 From: jcm at openjdk.java.net (Jamsheed Mohammed C M) Date: Tue, 22 Sep 2020 06:29:39 GMT Subject: Integrated: 8253447: Remove buggy code introduced by 8249451 In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 01:48:53 GMT, Jamsheed Mohammed C M wrote: > if ((thread->has_pending_exception() || thread->frames_to_pop_failed_realloc() > 0) && exec_mode != > Unpack_uncommon_trap) { > assert(thread->has_pending_exception(), "should have thrown OOME/Async"); > > introduced a buggy code checking, clearing pending exception and taking Unpack_exception route. > > This can have consequences as the deopt entries may have additional logic depending on bci's. and the change introduced > in 8249451 doesn't honor deopt exception checking and forward logic. Thank you @fisk for pointing the bug in the code. > Request for review. This pull request has now been integrated. Changeset: f7b1ce45 Author: Jamsheed Mohammed C M URL: https://git.openjdk.java.net/jdk/commit/f7b1ce45 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8253447: Remove buggy code introduced by 8249451 Reviewed-by: iveresov, eosterlund ------------- PR: https://git.openjdk.java.net/jdk/pull/292 From jcm at openjdk.java.net Tue Sep 22 06:29:38 2020 From: jcm at openjdk.java.net (Jamsheed Mohammed C M) Date: Tue, 22 Sep 2020 06:29:38 GMT Subject: RFR: 8253447: Remove buggy code introduced by 8249451 [v2] In-Reply-To: References: <-1narCtDccARvrE8LbvdKMuaDtBU9f_08MJjysQ7xB0=.19e1536d-5d9d-4e4b-a1fc-9249e735fbd1@github.com> Message-ID: On Tue, 22 Sep 2020 06:20:30 GMT, Erik ?sterlund wrote: >> Jamsheed Mohammed C M has updated the pull request incrementally with one additional commit since the last revision: >> >> fixing the assert message too > > Looks good, thanks for fixing this. Thank you @dholmes-ora @veresov @fisk ------------- PR: https://git.openjdk.java.net/jdk/pull/292 From david.holmes at oracle.com Tue Sep 22 06:31:05 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Sep 2020 16:31:05 +1000 Subject: Looking for a sponsor for JDK-8138732 In-Reply-To: <17d66481-a8d2-8f37-857e-9e1e9707b700@gmx.net> References: <17d66481-a8d2-8f37-857e-9e1e9707b700@gmx.net> Message-ID: <60472904-3987-b87d-1112-23ea77e0bc87@oracle.com> Hi Philippe, On 22/09/2020 3:57 pm, Philippe Marschall wrote: > Hello > > I am looking for a sponsor for JDK-8138732 [1]. The ready to integrate > PR is here [2]. Sorry I can't volunteer to sponsor this. > Changes between the current code and the reviewed code: > > - I removed the jdk.internal export to jdk.jfr, that was a review comment. > - I had to rebase and resolve a merge conflict with JDK-8243066. @marschall marschall force-pushed the marschall:JDK-8138732 branch from 1c9dd9d to 5c49560 1 hour ago Please do not force-push anything as it breaks the commit history in the PR and renders previous reviews/comments obsolete. There is no way for the reviewers to see what changed between the commit they reviewed and the commit now in the PR. To update to latest changes you should have just merged your branch with your (up-to-date) local master, committed that merge in your local branch and then pushed that commit to your Personal Fork. The skara tooling will flatten the series of commits in a PR into one single well-formed commit that is pushed to the master branch of the repo. Thanks, David ----- > ?[1] https://bugs.openjdk.java.net/browse/JDK-8138732 > ?[2] https://github.com/openjdk/jdk/pull/45 > > Cheers > Philippe From eosterlund at openjdk.java.net Tue Sep 22 06:44:41 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 22 Sep 2020 06:44:41 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> Message-ID: On Mon, 21 Sep 2020 18:45:24 GMT, Vladimir Kozlov wrote: > I would like to hear answer to @dholmes-ora question in JBS: > > "Do we really need yet another stack dumping interface in the VM? Why isn't a debugger using JVM TI?" I also want to know this. ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From rehn at openjdk.java.net Tue Sep 22 07:02:30 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 22 Sep 2020 07:02:30 GMT Subject: RFR: 8238761: Asynchronous handshakes [v4] In-Reply-To: References: Message-ID: <_DibVw4wgsoLZ-zT_Shdu0JJ877r-6SRDlP_vBsrHe8=.81d41756-e490-4451-a24d-8fc89938e27e@github.com> On Tue, 22 Sep 2020 03:12:01 GMT, David Holmes wrote: >> Looks mostly good to me! > > Hi Robbin, > > I've gone back to refresh myself on the previous discussions and (internal) design walk-throughs to get a better sense > of these changes. Really the "asynchronous handshake" aspect is only a small part of this. The fundamental change here > is that handshakes are now maintained via a per-thread queue, and those handshake operations can, in the general case, > be executed by any of the target thread, the requestor (active_handshaker) thread or the VMThread. Hence the removal of > the various "JavaThread::current()" assumptions. Unless constrained otherwise, any handshake operation may be executed > by the VMThread so we have to take extra care to ensure the code is written to allow this. I'm a little concerned that > our detour into direct-handshakes actually lulled us into a false sense of security knowing that an operation would > always execute in a JavaThread, and we have now reverted that and allowed the VMThread back in. I understand why, but > the change in direction here caught me by surprise (as I had forgotten the bigger picture). It may not always be > obvious that the transitive closure of the code from an operation can be safely executed by a non-JavaThread. Then on > top of this generalized queuing mechanism there is a filter which allows some control over which thread may perform a > given operation - at the moment the only filter isolates "async" operations which only the target thread can execute. > In addition another nuance is that when processing a given thread's handshake operation queue, different threads have > different criteria for when to stop processing the queue: > - the target thread will drain the queue completely > - the VMThread will drain the queue of all "non-async" operations** > - the initiator for a "direct" operation will drain the queue up to, and including, the synchronous operation they > submitted > - the initiator for an "async" operation will not process any operation themselves and will simply add to the queue and > then continue on their way (hence the "asynchronous") > > ** I do have some concerns about latency impact on the VMThread if it is used to execute operations that didn't need to be > executed by the VMThread! > > I remain concerned about the terminology conflation that happens around "async handshakes". There are two aspects that > need to be separated: > - the behaviour of the thread initiating the handshake operation; and > - which thread can execute the handshake operation > > When a thread initiates a handshake operation and waits until that operation is complete (regardless of which thread > performed it, or whether the initiator processed any other operations) that is a synchronous handshake operation. When > a thread initiates a handshake operation and does not wait for the operation to complete (it does the > target->queue()->add(op); and continues on its way) that is an asynchronous handshake operation. The question of > whether the operation must be executed by the target thread is orthogonal to whether the operation was submitted as a > synchronous or asynchronous operation. So I have problem when you say that an asynchronous handshake operation is one > that must be executed by the target thread, as this is not the right characterisation at all. It is okay to constrain > things such that an async operation is always executed by the target, but that is not what makes it an async operation. > In the general case there is no reason why an async operation might not be executed by the VMThread, or some other > JavaThread performing a synchronous operation on the same target. I will go back through the actual handshake code to > see if there are specific things I would like to see changed, but that will have to wait until tomorrow. Thanks, David Hi David, you are correct and you did a fine job summarizing this, thanks! > I will go back through the actual handshake code to see if there are specific things I would like to see changed, but > that will have to wait until tomorrow. Great thanks! > > Thanks, > David # ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From akozlov at openjdk.java.net Tue Sep 22 07:16:38 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 22 Sep 2020 07:16:38 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS Message-ID: Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL, PROT_NONE), the function was made aware of exec permissions. For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference compared with old code. For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and immediately reflects this in diagnostic tools like ps. For executable regions it would require MAP_FIXED|MAP_JIT, so instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not shrink (if I haven't missed anything, by the implementation and in principle). Tested: * local tier1 * jdk-submit * codesign[2] with hardened runtime and allow-jit but without allow-unsigned-executable-memory entitlements[3] produce a working bundle. (adding GC group as suggested by @dholmes-ora) [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227 [2] codesign \ --sign - \ --options runtime \ --entitlements ents.plist \ --timestamp \ $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib [3] com.apple.security.cs.allow-jit com.apple.security.cs.disable-library-validation com.apple.security.cs.allow-dyld-environment-variables ------------- Commit messages: - Use MAP_JIT for CodeCache pages Changes: https://git.openjdk.java.net/jdk/pull/294/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=294&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234930 Stats: 65 lines in 15 files changed: 27 ins; 0 del; 38 mod Patch: https://git.openjdk.java.net/jdk/pull/294.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/294/head:pull/294 PR: https://git.openjdk.java.net/jdk/pull/294 From rehn at openjdk.java.net Tue Sep 22 07:34:16 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 22 Sep 2020 07:34:16 GMT Subject: RFR: 8238761: Asynchronous handshakes [v4] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 21:18:20 GMT, Coleen Phillimore wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev >> excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since >> the last revision: >> - Update after Dan and David >> - Merge branch 'master' into 8238761-asynchrounous-handshakes >> - Removed double check, fix comment, removed not needed function, updated logs >> - Fixed double checks >> Added NSV >> ProcessResult to enum >> Fixed logging >> Moved _active_handshaker to private >> - Rebase version 1.0 > > src/hotspot/share/runtime/handshake.hpp line 55: > >> 53: }; >> 54: >> 55: class AsynchHandshakeClosure : public HandshakeClosure { > > Can you make this minor change? Asynch to english speakers looks like a-cinch and if left as Async is a-sink. Can you > remove the 'h's ? I see David above left off the extra h, which is what one expects this to be named. Fixed > src/hotspot/share/runtime/handshake.cpp line 394: > >> 392: { >> 393: NoSafepointVerifier nsv; >> 394: process_self_inner(); > > Can you remove process_self_inner and just inline it here since this is it's only caller and both are short functions? > If you don't want to, that's fine. I found myself searching for any other callers of this, that's all. We might remove ThreadInVMForHandshake and NoSafepointVerifier in the future. ThreadInVMForHandshake is needed while we have the _suspend_flag and we have two different request to safepoint inside handshake due java heap allocation inside handshakes. Having them outside like now it's clearer if we do such changes, so I'll keep it this way. > test/hotspot/jtreg/runtime/handshake/HandshakeDirectTest.java line 42: > >> 40: public class HandshakeDirectTest implements Runnable { >> 41: static final int WORKING_THREADS = 32; >> 42: static final int DIRECT_HANDSHAKES_MARK = 500000; > > Could this timeout? I have seen no signs of it and have been through several mach5 runs with no issues. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Tue Sep 22 07:34:16 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 22 Sep 2020 07:34:16 GMT Subject: RFR: 8238761: Asynchronous handshakes [v4] In-Reply-To: <0buWd7Y3md8DLJOL6eIBdMu6vs8SVG9DzQy56OJkwsc=.6ce33107-0039-4d2c-885c-ee0961063d2a@github.com> References: <0buWd7Y3md8DLJOL6eIBdMu6vs8SVG9DzQy56OJkwsc=.6ce33107-0039-4d2c-885c-ee0961063d2a@github.com> Message-ID: On Mon, 21 Sep 2020 21:26:08 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/handshake.hpp line 78: >> >>> 76: FilterQueue _queue; >>> 77: Mutex _lock; >>> 78: Thread* _active_handshaker; >> >> Nit: can you line up the data member names for lock and _active_handshaker ? > > FilterQueue _queue; > JavaThread* _handshakee; > Mutex _lock; > Thread* _active_handshaker; > > Isn't this nicer? (it didn't keep the formatting in the comment) The order of members matter since C++ initialize them in declared order. My opinion when changing this was that it was easier to read when passing the only argument to the first member being initialized, thus _handshakee must be first member. But I should init _active_handshaker in constructor, so added that and lined-up. So before I do any such change please reflect over how the constructor will look like. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Tue Sep 22 07:48:36 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 22 Sep 2020 07:48:36 GMT Subject: RFR: 8238761: Asynchronous handshakes [v4] In-Reply-To: <_DibVw4wgsoLZ-zT_Shdu0JJ877r-6SRDlP_vBsrHe8=.81d41756-e490-4451-a24d-8fc89938e27e@github.com> References: <_DibVw4wgsoLZ-zT_Shdu0JJ877r-6SRDlP_vBsrHe8=.81d41756-e490-4451-a24d-8fc89938e27e@github.com> Message-ID: On Tue, 22 Sep 2020 07:00:06 GMT, Robbin Ehn wrote: >> Hi Robbin, >> >> I've gone back to refresh myself on the previous discussions and (internal) design walk-throughs to get a better sense >> of these changes. Really the "asynchronous handshake" aspect is only a small part of this. The fundamental change here >> is that handshakes are now maintained via a per-thread queue, and those handshake operations can, in the general case, >> be executed by any of the target thread, the requestor (active_handshaker) thread or the VMThread. Hence the removal of >> the various "JavaThread::current()" assumptions. Unless constrained otherwise, any handshake operation may be executed >> by the VMThread so we have to take extra care to ensure the code is written to allow this. I'm a little concerned that >> our detour into direct-handshakes actually lulled us into a false sense of security knowing that an operation would >> always execute in a JavaThread, and we have now reverted that and allowed the VMThread back in. I understand why, but >> the change in direction here caught me by surprise (as I had forgotten the bigger picture). It may not always be >> obvious that the transitive closure of the code from an operation can be safely executed by a non-JavaThread. Then on >> top of this generalized queuing mechanism there is a filter which allows some control over which thread may perform a >> given operation - at the moment the only filter isolates "async" operations which only the target thread can execute. >> In addition another nuance is that when processing a given thread's handshake operation queue, different threads have >> different criteria for when to stop processing the queue: >> - the target thread will drain the queue completely >> - the VMThread will drain the queue of all "non-async" operations** >> - the initiator for a "direct" operation will drain the queue up to, and including, the synchronous operation they >> submitted >> - the initiator for an "async" operation will not process any operation themselves and will simply add to the queue and >> then continue on their way (hence the "asynchronous") >> >> ** I do have some concerns about latency impact on the VMThread if it is used to execute operations that didn't need to be >> executed by the VMThread! >> >> I remain concerned about the terminology conflation that happens around "async handshakes". There are two aspects that >> need to be separated: >> - the behaviour of the thread initiating the handshake operation; and >> - which thread can execute the handshake operation >> >> When a thread initiates a handshake operation and waits until that operation is complete (regardless of which thread >> performed it, or whether the initiator processed any other operations) that is a synchronous handshake operation. When >> a thread initiates a handshake operation and does not wait for the operation to complete (it does the >> target->queue()->add(op); and continues on its way) that is an asynchronous handshake operation. The question of >> whether the operation must be executed by the target thread is orthogonal to whether the operation was submitted as a >> synchronous or asynchronous operation. So I have problem when you say that an asynchronous handshake operation is one >> that must be executed by the target thread, as this is not the right characterisation at all. It is okay to constrain >> things such that an async operation is always executed by the target, but that is not what makes it an async operation. >> In the general case there is no reason why an async operation might not be executed by the VMThread, or some other >> JavaThread performing a synchronous operation on the same target. I will go back through the actual handshake code to >> see if there are specific things I would like to see changed, but that will have to wait until tomorrow. Thanks, David > > Hi David, you are correct and you did a fine job summarizing this, thanks! > >> I will go back through the actual handshake code to see if there are specific things I would like to see changed, but >> that will have to wait until tomorrow. > > Great thanks! > >> >> Thanks, >> David > > # @coleenp I think you placed your comment: "The "driver" concept is odd. Should it really be caller? Like the thread that called VMHandshake?" On the commit or somewhere else, not a review comment, I can't reply. Anyhow I can reply to it here: The answer is caller makes me think of requester, but we don't know if it's the requester executing this. Therefore I referred to the thread executing handshakes on the target/handshakee as driver. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Tue Sep 22 07:54:57 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 22 Sep 2020 07:54:57 GMT Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: > This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes > are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) > Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an > arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a > singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first > pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first > pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake > operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything > except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed > filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake > operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there > is now only one method to call when handshaking one thread. Some comments about the changes: > - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake > all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much > worse then this. > > - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that > thread. > > - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a > handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. > > - Added WB testing method. > > - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. > > - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. > > - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a > safepoint and half of them after, in many handshake all operations. > > - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. > > - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the > moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. > > - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. > > - Added filtered queue and gtest for it. > > Passes multiple t1-8 runs. > Been through some pre-reviwing. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Update after Coleen ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/151/files - new: https://git.openjdk.java.net/jdk/pull/151/files/badefa47..cd784a75 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=151&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=151&range=03-04 Stats: 11 lines in 3 files changed: 1 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/151/head:pull/151 PR: https://git.openjdk.java.net/jdk/pull/151 From egahlin at openjdk.java.net Tue Sep 22 08:45:52 2020 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 22 Sep 2020 08:45:52 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Sat, 12 Sep 2020 00:19:00 GMT, Vladimir Kozlov wrote: >> Philippe Marschall has refreshed the contents of this pull request, and previous commits have been removed. The >> incremental views will show differences compared to the previous content of the PR. The pull request contains one new >> commit since the last revision: >> 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate > > Marked as reviewed by kvn (Reviewer). Have you run the JFR tests in test/jdk/jdk/jfr? ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From adinn at openjdk.java.net Tue Sep 22 09:01:22 2020 From: adinn at openjdk.java.net (Andrew Dinn) Date: Tue, 22 Sep 2020 09:01:22 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) In-Reply-To: References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <3X2uVszEC9NytfF9QvL6dJQ1SHztYEpAkMKNsN3VuKc=.9aec19c0-0e5d-4512-ac41-2eed8a0cd078@github.com> <-jCc20O2YVYuUT1bu-9h-nHSx0zP35TMleyo1-fdlRI=.f8e3fe1f-3a7e-44a7-b24b-8c809cf727c8@github.com> <2dlrgVtF5twY9WGHEKS2ZcLEm1jPmGgOfFF6o-ZyUHc=.c33e5814-724a-4569-9eed-97e8afaaa440@github.com> Message-ID: On Tue, 22 Sep 2020 02:31:14 GMT, Vladimir Kozlov wrote: >>> > Can you explain where this restricted effect is documented? >> >>> Certainly! I?ve found that determining the capability of the CPU and whether to enable AVX2 support if the chip >>> supports it is mostly controlled in: vm_version_x86.cpp specifically: get_processor_features and in >>> generate_get_cpu_info. >> >> Yes, I can see what the code does. I was asking where the cpu behaviour is documented independent of the code. >> >>> In order to test the patch comprehensively I had to track down an Intel Core i7 (I7-9750H) processor which the >>> aforementioned code permitted AVX2 instructions for (maybe this is an error and it should not be enabled for this >>> processor though) as most of the infrastructure I personally use here at AWS runs on Intel Xeon processors - I also >>> tested on a E5-2680 which the JVM does not enable AVX2 for. >> >> 'maybe'? The documentation Andrew provided mentioned Xeon E5 v3 which I believe is a Skylake design. However, the code >> I pointed you at in vm_version_x86 which claims to detect 'early Skylake' designs is only disabling AVX512 support. It >> still enables AVX2. Similarly, the code that generates machine code to check the processor capabilities has a special >> check if use_evex is set (i.e. AVX3 is requested) which disables AVX512 for Skylake but does not disable AVX2 support. >>> However, this is just the Intel side of things. When it comes to AMD I read that the AMD Zen 2 architecture, of which >>> the current flagship: Threadripper 3990X, is based, is able to support AVX2 without the frequency scaling which >>> some/all(?) of the Intel chips incur. I personally don?t have access to one of these chips so I cannot confirm how it >>> is classified in the JVM. >> >> Well, it would be good to know where you read that and to see if that confirms thar the code is avoiding the issue >> Andrew raised. >>> Also, I found when investigating this that there is actually a JVM flag which can be used to control what level of AVX >>> is enabled: -XX:UseAVX=version. >> >> Yes, indeed. However, what I am trying to understand is whether the current code is bypassing the problem Andrew >> brought up in the cases where that problem actually exists. It doesn't look like it so far given that the problem >> applies to AVX2 and only AVX512 support is being disabled and, even then only for some (Skylake) processors. Without >> some clear documentation of what processors suffer from this power surge problem it will not be possible to decide >> whether this patch is doing the right thing or not. > > Based on comment by @jatin-bhateja (Intel) frequency level switchover pointed by @theRealAph is sensitive to vector > size https://github.com/openjdk/jdk/pull/144#issuecomment-692044896 > > By keeping vector size less or equal to 32 bytes we should avoid it. And as I can see this intrinsic code is using 32 > bytes (chars) and 16 bytes vectors: `pbroadcastb(vec1, vec1, Assembler::AVX_256bit);` > Also we never had issues with AVX2. only with AVX512 regarding performance hit: > https://bugs.openjdk.java.net/browse/JDK-8221092 > > I would like to see performance numbers for for all values of UseAVX flag : 0, 1, 2, 3 > > The usage is guarded UseSSE42Intrinsics in UseSSE42Intrinsics predicate in .ad file. Make sure to test with UseAVX=0 to > make sure that some avx instructions are not mixed into non avx code. And also with UseSSE=2 (for example) to make sure > shared code correctly recognize that intrinsics is not supported. @vnkozlov @mknjc @jatin-bhateja Thanks for providing the relevant details. I'm now quite content that this patch avoids any potential frequency scaling problem. I'm also glad that an explanation of why this is so is now available -- although it's not perfect that we are relying on a stackoverflow post for the full details. ------------- PR: https://git.openjdk.java.net/jdk/pull/71 From github.com+4676506+javeleon at openjdk.java.net Tue Sep 22 09:19:57 2020 From: github.com+4676506+javeleon at openjdk.java.net (Allan Gregersen) Date: Tue, 22 Sep 2020 09:19:57 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> Message-ID: On Tue, 22 Sep 2020 06:42:00 GMT, Erik ?sterlund wrote: > I would like to hear answer to @dholmes-ora question in JBS: > "Do we really need yet another stack dumping interface in the VM? Why isn't a debugger using JVM TI?" One reason for having both the new getStackFrames API (set of threads) as well as the existing iterateFrames (current thread only) API in JVMCI is that Truffle would want a deopt-free read-only view of the values in a frame, which to the best of our knowledge is not possible through JVMTI. Only in rare cases, materialization of frames is required, so it boils down to the performance hit caused by deopting frames, which is even more of a concern with a set of threads than for the single current thread case. Another potential issue with a JVMTI-based approach is that there might be other drawbacks to having an always-on (or even late attached) JVMTI agent in a GraalVM? ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From eosterlund at openjdk.java.net Tue Sep 22 10:53:53 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 22 Sep 2020 10:53:53 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> Message-ID: On Tue, 22 Sep 2020 09:17:08 GMT, Allan Gregersen wrote: > > I would like to hear answer to @dholmes-ora question in JBS: > > "Do we really need yet another stack dumping interface in the VM? Why isn't a debugger using JVM TI?" > > One reason for having both the new getStackFrames API (set of threads) as well as the existing iterateFrames (current > thread only) API in JVMCI is that Truffle would want a deopt-free read-only view of the values in a frame, which to the > best of our knowledge is not possible through JVMTI. Only in rare cases, materialization of frames is required, so it > boils down to the performance hit caused by deopting frames, which is even more of a concern with a set of threads than > for the single current thread case. Another potential issue with a JVMTI-based approach is that there might be other > drawbacks to having an always-on (or even late attached) JVMTI agent in a GraalVM? 1) You are describing that the main reason is performance. But you also say this is to be used by a debugger? So, not sure performance as a primary motive really makes sense then. Not sure why performance of debugging Truffle must be so much faster than debugging Java code (which I have not heard anyone complain about). And if this really was an actual performance problem, it seems like we would want a generic fix then, not a special Truffle stack walker for debugging Truffle code alone, to be maintained separately. 2) We are talking about JVMTI, not JVMCI. iterateFrames is defined in JVMCI, and that is something completely different, which I don't think any of us had in mind. It seems indeed to be limited to the current frame. I'm talking about e.g. JVMTI GetStackTrace and the JVMTI GetLocal* functions. It gives you a stack trace for any thread (not just the current one), and allows you to retrieve locals. 3) When you just read locals, (as you describe is your use case), there is no need to deoptimize anything. So yeah, that's just not something we do, unless you change the locals, which you said you are not. Please let me know if there is anything I missed. But so far it seems to me that the mentioned JVMTI functionality is all you really need for a debugger. What did I miss? I would like to better understand the problem domain before taking this further. ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From eosterlund at openjdk.java.net Tue Sep 22 12:00:26 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 22 Sep 2020 12:00:26 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing Message-ID: This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. https://openjdk.java.net/jeps/376). Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it brought (and is only possible on TSO machines). So left that one out. ------------- Commit messages: - 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing Changes: https://git.openjdk.java.net/jdk/pull/296/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253180 Stats: 2560 lines in 131 files changed: 2046 ins; 279 del; 235 mod Patch: https://git.openjdk.java.net/jdk/pull/296.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/296/head:pull/296 PR: https://git.openjdk.java.net/jdk/pull/296 From coleenp at openjdk.java.net Tue Sep 22 12:24:11 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 22 Sep 2020 12:24:11 GMT Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 07:54:57 GMT, Robbin Ehn wrote: >> This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes >> are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) >> Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an >> arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a >> singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first >> pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first >> pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake >> operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything >> except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed >> filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake >> operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there >> is now only one method to call when handshaking one thread. Some comments about the changes: >> - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake >> all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much >> worse then this. >> >> - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that >> thread. >> >> - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a >> handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. >> >> - Added WB testing method. >> >> - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. >> >> - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. >> >> - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a >> safepoint and half of them after, in many handshake all operations. >> >> - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. >> >> - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the >> moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. >> >> - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. >> >> - Added filtered queue and gtest for it. >> >> Passes multiple t1-8 runs. >> Been through some pre-reviwing. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Update after Coleen Just one comment that needs an answer if you can find it :) src/hotspot/share/prims/whitebox.cpp line 2050: > 2048: JavaThread* target = java_lang_Thread::thread(thread_oop); > 2049: TraceSelfClosure* tsc = new TraceSelfClosure(target); > 2050: Handshake::execute(tsc, target); I know it's a whitebox test, but should this delete TraceSelfClosure sometime? ------------- Changes requested by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/151 From coleenp at openjdk.java.net Tue Sep 22 12:24:11 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 22 Sep 2020 12:24:11 GMT Subject: RFR: 8238761: Asynchronous handshakes [v4] In-Reply-To: References: <0buWd7Y3md8DLJOL6eIBdMu6vs8SVG9DzQy56OJkwsc=.6ce33107-0039-4d2c-885c-ee0961063d2a@github.com> Message-ID: On Tue, 22 Sep 2020 07:20:30 GMT, Robbin Ehn wrote: >> FilterQueue _queue; >> JavaThread* _handshakee; >> Mutex _lock; >> Thread* _active_handshaker; >> >> Isn't this nicer? (it didn't keep the formatting in the comment) > > The order of members matter since C++ initialize them in declared order. > My opinion when changing this was that it was easier to read when passing the only argument to the first member being > initialized, thus _handshakee must be first member. > But I should init _active_handshaker in constructor, so added that and lined-up. > > So before I do any such change please reflect over how the constructor will look like. I don't understand, you'd have to rearrange the initializers in the constructor too, but I don't see any order dependance. Moving over _lock helps, so this is fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From stefank at openjdk.java.net Tue Sep 22 12:27:05 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 22 Sep 2020 12:27:05 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 11:43:41 GMT, Erik ?sterlund wrote: > This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. > https://openjdk.java.net/jeps/376). > Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, > and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into > more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to > expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in > the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized > automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization > processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is > actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception > handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC > threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming > of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the > watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll > word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it > brought (and is only possible on TSO machines). So left that one out. I've pre-reviewed most of the changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From github.com+8792647+robcasloz at openjdk.java.net Tue Sep 22 12:44:33 2020 From: github.com+8792647+robcasloz at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Tue, 22 Sep 2020 12:44:33 GMT Subject: RFR: 8252219: C2: Randomize IGVN worklist for stress testing [v2] In-Reply-To: References: Message-ID: > Add `StressIGVN` option to let C2 randomize IGVN worklist order. When enabled, the worklist is shuffled before each > main run of the IGVN loop. Also add `GenerateStressSeed' and 'StressSeed=N` options to randomly generate or specify the > seed. In either case, the seed is logged if `LogCompilation` is enabled. The generation or specification of seeds also > affects the randomization triggered by `StressLCM` and `StressGCM`. The new options are declared as > production+diagnostic for consistency with these existing options. Roberto Casta?eda Lozano has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Apply minor rearrangements to simplify the patch - Do not use the per-compilation seed for StressLCM and StressGCM Use global seed for StressLCM and StressGCM as before to preserve their behavior by now. In the future, these options can also benefit from using the local (per-compilation) seed by simply using Compile::random() instead of os::random() and extending the Compile constructor accordingly. - Merge branch 'master' of github.com:robcasloz/jdk into JDK-8252219 - Replace global seed with compilation-local seeds for repeatability Replace usage of global seed for stress testing with a seed per compilation, to make stress runs repeatable in the face of concurrent method compilations. This affects StressLCM, StressGCM, and StressIGVN. Reuse pseudonumber generation logic in os::random_helper. - 8252219: C2: Randomize IGVN worklist for stress testing Add 'StressIGVN' option to let C2 randomize IGVN worklist order. When enabled, the worklist is shuffled before each main run of the IGVN loop. Also add 'GenerateStressSeed' and 'StressSeed=N' options to randomly generate or specify the seed. In either case, the seed is logged if 'LogCompilation' is enabled. The generation or specification of seeds also affects the randomization triggered by 'StressLCM' and 'StressGCM'. The new options are declared as production+diagnostic for consistency with these existing options. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/242/files - new: https://git.openjdk.java.net/jdk/pull/242/files/2c674fa5..73abfb27 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=242&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=242&range=00-01 Stats: 8415 lines in 304 files changed: 4786 ins; 2817 del; 812 mod Patch: https://git.openjdk.java.net/jdk/pull/242.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/242/head:pull/242 PR: https://git.openjdk.java.net/jdk/pull/242 From kim.barrett at oracle.com Tue Sep 22 13:14:58 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 22 Sep 2020 09:14:58 -0400 Subject: RFR: 8247912: Make narrowOop a scoped enum In-Reply-To: References: Message-ID: > On Sep 21, 2020, at 5:32 PM, Ioi Lam wrote: > > On Mon, 21 Sep 2020 04:01:34 GMT, Kim Barrett wrote: > >> Please review this change to the type narrowOop from a typedef for juint to a >> scoped enum with uint32_t as the representation type. This provides stronger >> type checking when using this type. >> [?] > > This looks good overall to me. > > src/hotspot/share/oops/compressedOops.hpp line 142: > >> 140: // Shift by 32 is UB if size in bits of i is 32, e.g. on 32bit platform. >> 141: assert(((i >> 16) >> 16) == 0, "narrowOop overflow"); >> 142: return static_cast(static_cast(i)); > > Should we have an assert that further restricts the range according to max heap size? I?m updating this, in part in light of your question below. > Also, should we allow only unsigned types for T? I think using signed types here is prone to error and should be > flagged. It turns out we can?t restrict it to unsigned types, at least not very easily. For example, CDS calls this with an intptr_t value. I suppose CDS could do conversion itself before calling this, but that seems a little odd. And I don?t know how many more there are after changing that one. > Changes requested by iklam (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/273 From kim.barrett at oracle.com Tue Sep 22 13:16:36 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 22 Sep 2020 09:16:36 -0400 Subject: RFR: 8247912: Make narrowOop a scoped enum In-Reply-To: References: Message-ID: > On Sep 21, 2020, at 5:44 PM, Ioi Lam wrote: > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 179: > >> 177: // Move narrow OOP >> 178: narrowOop noop = CompressedOops::encode((oop)o); >> 179: CompressedOops::NarrowType n = CompressedOops::narrow_oop_value(noop); > > I think a public NarrowType is confusing (vs narrowOop). Since NarrowType is rarely used, and it's unlikely to be > changed from uint32_t, maybe we should make NarrowType private, and change the above to uint32_t n = > CompressedOops::encode_as_uint32_t((oop)o); Code that does arithmetic operations on the integer value probably wants to > know the exact type anyway. I.e., not knowing whether NarrowType is signed or not makes me worry about the correctness > of `n >> 16` below. Coleen didn?t like NarrowType either. I?m convinced by your argument that callers need to know it?s uint32_t anyway, and will remove it. From kbarrett at openjdk.java.net Tue Sep 22 13:43:54 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 22 Sep 2020 13:43:54 GMT Subject: RFR: 8247912: Make narrowOop a scoped enum [v2] In-Reply-To: References: Message-ID: > Please review this change to the type narrowOop from a typedef for juint to a > scoped enum with uint32_t as the representation type. This provides stronger > type checking when using this type. > > For the most part this was fairly straightforward, and the patch size is > relatively small. The implementation of some existing CompressedOops > "primitives" required adjustment. An explicit conversion to narrowOop was > added, with casts change to use it. There were a few places that were type > punning and needed explicit conversions,, mostly in platform-specific assembly > support. > > There are a couple of lingering problems. > > Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass > as a narrowOop. I adjusted the code to accommodate the narrowOop change, but > this probably ought to be done differently. > > There are a couple of `(narrowOop)` casts remaining in s390.ad. I'm not sure > whether these can be safely converted to CompressedOops::narrow_oop_cast. > > There might still be some casts from narrowOop to an integral type. Those are > hard to find in our cast-happy code base. > > Testing: > tier1-6 for Oracle supported platforms. > Build fastdebug linux-ppc64le and linux-s390x. Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: - improve assertion - remove NarrowType ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/273/files - new: https://git.openjdk.java.net/jdk/pull/273/files/10f9cf5f..e36f7895 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=273&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=273&range=00-01 Stats: 10 lines in 3 files changed: 2 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/273.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/273/head:pull/273 PR: https://git.openjdk.java.net/jdk/pull/273 From stefank at openjdk.java.net Tue Sep 22 13:49:51 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 22 Sep 2020 13:49:51 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing In-Reply-To: References: Message-ID: <1iLCRf17v1nwE70nQk7qq0bcad8gop9q5dYt-sr9fG8=.81025951-bc22-45d0-84ff-9557b67262e3@github.com> On Tue, 22 Sep 2020 11:43:41 GMT, Erik ?sterlund wrote: > This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. > https://openjdk.java.net/jeps/376). > Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, > and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into > more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to > expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in > the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized > automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization > processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is > actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception > handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC > threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming > of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the > watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll > word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it > brought (and is only possible on TSO machines). So left that one out. Partially re-reviewed the changes. src/hotspot/cpu/x86/templateInterpreterGenerator_x86_64.cpp line 194: > 192: > 193: Label slow_path; > 194: __ safepoint_poll(slow_path, r15_thread, true /* at_return */, false /* in_nmethod */); Why is this tagged with 'true /* at_return */? Same for line 240. The _x86_32 version uses false. src/hotspot/share/c1/c1_Runtime1.cpp line 515: > 513: if (thread->last_frame().is_runtime_frame()) { > 514: // The Runtime1::handle_exception_from_callee_id handler is invoked after the > 515: // frame has been unwinded. It instead builds its own stub frame, to call the Unwided -> unwound, maybe? Same below and probably other places as well. src/hotspot/share/compiler/oopMap.cpp line 243: > 241: } else { > 242: all_do(fr, reg_map, f, process_derived_oop, &do_nothing_cl); > 243: } I wonder if we shouldn't hide the StackWatermarkSet in the GC code, and not "activate" the DerivedPointerTable when a SWS is used? Isn't it the case that already don't enable the table for ZGC? Couldn't this simply be: ` if (DerivedPointerTable::is_active()) { all_do(fr, reg_map, f, add_derived_oop, &do_nothing_cl); } else { all_do(fr, reg_map, f, process_derived_oop, &do_nothing_cl); } ` src/hotspot/share/compiler/oopMap.cpp line 312: > 310: #ifdef ASSERT > 311: if ((((uintptr_t)loc & (sizeof(oop)-1)) != 0) || > 312: !Universe::heap()->is_in_or_null((oop)NativeAccess::oop_load(&val))) { Discussed offline. This is technical debt that we'd like to get rid of somehow. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From mbaesken at openjdk.java.net Tue Sep 22 14:07:26 2020 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 22 Sep 2020 14:07:26 GMT Subject: RFR: 8247912: Make narrowOop a scoped enum [v2] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 21:29:41 GMT, Ioi Lam wrote: >> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: >> >> - improve assertion >> - remove NarrowType > > This looks good overall to me. Our nightly builds+tests on linux ppc64(le) with your change included looked good, seems your change did not cause any harm. My local build on linux s390x with your patch included worked nicely too, some small smoke tests were okay as well . ------------- PR: https://git.openjdk.java.net/jdk/pull/273 From rehn at openjdk.java.net Tue Sep 22 14:09:50 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 22 Sep 2020 14:09:50 GMT Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 12:14:19 GMT, Coleen Phillimore wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after Coleen > > src/hotspot/share/prims/whitebox.cpp line 2050: > >> 2048: JavaThread* target = java_lang_Thread::thread(thread_oop); >> 2049: TraceSelfClosure* tsc = new TraceSelfClosure(target); >> 2050: Handshake::execute(tsc, target); > > I know it's a whitebox test, but should this delete TraceSelfClosure sometime? Please have a look here, we delete it if we fail to install it: https://github.com/openjdk/jdk/blob/cd784a751a3153939b9284898f370160124ca610/src/hotspot/share/runtime/handshake.cpp#L352 Here we delete it after we processed it: https://github.com/openjdk/jdk/blob/cd784a751a3153939b9284898f370160124ca610/src/hotspot/share/runtime/handshake.cpp#L419 Since this as async op, the requester can't safely delete it. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Tue Sep 22 14:25:26 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 22 Sep 2020 14:25:26 GMT Subject: RFR: 8238761: Asynchronous handshakes [v4] In-Reply-To: References: <0buWd7Y3md8DLJOL6eIBdMu6vs8SVG9DzQy56OJkwsc=.6ce33107-0039-4d2c-885c-ee0961063d2a@github.com> Message-ID: On Tue, 22 Sep 2020 12:20:36 GMT, Coleen Phillimore wrote: >> The order of members matter since C++ initialize them in declared order. >> My opinion when changing this was that it was easier to read when passing the only argument to the first member being >> initialized, thus _handshakee must be first member. >> But I should init _active_handshaker in constructor, so added that and lined-up. >> >> So before I do any such change please reflect over how the constructor will look like. > > I don't understand, you'd have to rearrange the initializers in the constructor too, but I don't see any order > dependance. Moving over _lock helps, so this is fine. You want a cosmetic change in the member declaration. I'm saying the constructor will look worse. Im asking if you want to trade a worse constructor for that? (all here is extremely subjective :) ) ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From dcubed at openjdk.java.net Tue Sep 22 14:40:58 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Sep 2020 14:40:58 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing In-Reply-To: <1iLCRf17v1nwE70nQk7qq0bcad8gop9q5dYt-sr9fG8=.81025951-bc22-45d0-84ff-9557b67262e3@github.com> References: <1iLCRf17v1nwE70nQk7qq0bcad8gop9q5dYt-sr9fG8=.81025951-bc22-45d0-84ff-9557b67262e3@github.com> Message-ID: <0iHoaOyRCFzhpuXNG78m6xgv5B_xBPlyUdNx_dnqBJQ=.e9270174-1980-454d-90a3-e27a5b7daac2@github.com> On Tue, 22 Sep 2020 13:47:21 GMT, Stefan Karlsson wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, >> and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into >> more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to >> expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in >> the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized >> automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization >> processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is >> actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception >> handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC >> threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming >> of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the >> watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll >> word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it >> brought (and is only possible on TSO machines). So left that one out. > > Partially re-reviewed the changes. @fisk - You are missing testing information for this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From coleenp at openjdk.java.net Tue Sep 22 14:46:06 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 22 Sep 2020 14:46:06 GMT Subject: RFR: 8238761: Asynchronous handshakes [v4] In-Reply-To: References: <0buWd7Y3md8DLJOL6eIBdMu6vs8SVG9DzQy56OJkwsc=.6ce33107-0039-4d2c-885c-ee0961063d2a@github.com> Message-ID: On Tue, 22 Sep 2020 14:22:58 GMT, Robbin Ehn wrote: >> I don't understand, you'd have to rearrange the initializers in the constructor too, but I don't see any order >> dependance. Moving over _lock helps, so this is fine. > > You want a cosmetic change in the member declaration. > I'm saying the constructor will look worse. > > Im asking if you want to trade a worse constructor for that? > (all here is extremely subjective :) ) It is subjective. What you have is fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From coleenp at openjdk.java.net Tue Sep 22 14:51:12 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 22 Sep 2020 14:51:12 GMT Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 07:54:57 GMT, Robbin Ehn wrote: >> This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes >> are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) >> Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an >> arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a >> singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first >> pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first >> pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake >> operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything >> except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed >> filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake >> operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there >> is now only one method to call when handshaking one thread. Some comments about the changes: >> - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake >> all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much >> worse then this. >> >> - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that >> thread. >> >> - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a >> handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. >> >> - Added WB testing method. >> >> - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. >> >> - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. >> >> - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a >> safepoint and half of them after, in many handshake all operations. >> >> - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. >> >> - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the >> moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. >> >> - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. >> >> - Added filtered queue and gtest for it. >> >> Passes multiple t1-8 runs. >> Been through some pre-reviwing. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Update after Coleen Ok, all questions addressed. Looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/151 From coleenp at openjdk.java.net Tue Sep 22 14:51:12 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 22 Sep 2020 14:51:12 GMT Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: <-BS_ADrq7PRAtT5SNtB32bPlmGf6RF3IIXZjEkybsQc=.75ab871d-9c34-48be-a421-b4606c851a2c@github.com> On Tue, 22 Sep 2020 14:07:11 GMT, Robbin Ehn wrote: >> src/hotspot/share/prims/whitebox.cpp line 2050: >> >>> 2048: JavaThread* target = java_lang_Thread::thread(thread_oop); >>> 2049: TraceSelfClosure* tsc = new TraceSelfClosure(target); >>> 2050: Handshake::execute(tsc, target); >> >> I know it's a whitebox test, but should this delete TraceSelfClosure sometime? > > Please have a look here, we delete it if we fail to install it: > https://github.com/openjdk/jdk/blob/cd784a751a3153939b9284898f370160124ca610/src/hotspot/share/runtime/handshake.cpp#L352 > Here we delete it after we processed it: > https://github.com/openjdk/jdk/blob/cd784a751a3153939b9284898f370160124ca610/src/hotspot/share/runtime/handshake.cpp#L419 > > Since this as async op, the requester can't safely delete it. Ok, thanks for pointing it out. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From eosterlund at openjdk.java.net Tue Sep 22 15:12:52 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 22 Sep 2020 15:12:52 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing In-Reply-To: <0iHoaOyRCFzhpuXNG78m6xgv5B_xBPlyUdNx_dnqBJQ=.e9270174-1980-454d-90a3-e27a5b7daac2@github.com> References: <1iLCRf17v1nwE70nQk7qq0bcad8gop9q5dYt-sr9fG8=.81025951-bc22-45d0-84ff-9557b67262e3@github.com> <0iHoaOyRCFzhpuXNG78m6xgv5B_xBPlyUdNx_dnqBJQ=.e9270174-1980-454d-90a3-e27a5b7daac2@github.com> Message-ID: On Tue, 22 Sep 2020 14:38:05 GMT, Daniel D. Daugherty wrote: > @fisk - You are missing testing information for this PR. Sorry about that. I have performed testing with ZGC enabled from tier1-7 (multiple times), and standard testing tier1-5. I have also stress tested the change with gc-test-suite, with full verification on (there is a bunch of it), and the GC interval reduced to very small (GC all the time). Recent versions of this patch I also tested from tier1-8 (2 times). I have also perf tested this in dev-submit to check for regressions (none found), as well as stress tested SPECjbb2015 on a 3 TB machine with ~2200 threads. I have also manually stress tested the changes on an AArch64 machine, using gc-test-suite. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From simonis at openjdk.java.net Tue Sep 22 15:21:58 2020 From: simonis at openjdk.java.net (Volker Simonis) Date: Tue, 22 Sep 2020 15:21:58 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v3] In-Reply-To: References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> Message-ID: On Mon, 21 Sep 2020 12:45:55 GMT, Jason Tatton wrote: >> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for >> x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it >> I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as >> code for C2. Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and >> java/lang/StringLatin1.java https://bugs.openjdk.java.net/browse/JDK-8173585 >> >> Details of testing: >> ============ >> I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note >> that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the >> input String. Hence the test has been designed to cover all these cases. In summary they are: >> - A ?short? string of < 16 characters. >> - A SIMD String of 16 ? 31 characters. >> - A AVX2 SIMD String of 32 characters+. >> >> Hardware used for testing: >> ----------------------------- >> >> - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support). >> - AWS Graviton 2 (ARM 64 processor). >> >> I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64. >> >> Possible future enhancements: >> ==================== >> For the x86 implementation there may be two further improvements we can make in order to improve performance of both >> the StringUTF16 and StringLatin1 indexOf(char) intrinsics: >> 1. Make use of AVX-512 instructions. >> 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD >> instructions instead of a loop. >> Benchmark results: >> ============ >> **Without** the new StringLatin1 indexOf(char) intrinsic: >> >> | Benchmark | Mode | Cnt | Score | Error | Units | >> | ------------- | ------------- |------------- |------------- |------------- |------------- | >> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op | >> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933 | ns/op | >> >> >> **With** the new StringLatin1 indexOf(char) intrinsic: >> >> | Benchmark | Mode | Cnt | Score | Error | Units | >> | ------------- | ------------- |------------- |------------- |------------- |------------- | >> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716 | ns/op | >> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306 | ns/op | >> >> >> The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 >> indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when >> running on ARM. > > Jason Tatton has updated the pull request incrementally with one additional commit since the last revision: > > Add missing newline to end of vmSymbols.cpp src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1889: > 1887: bind(SCAN_TO_32_CHAR_LOOP); > 1888: vmovdqu(vec3, Address(result, 0)); > 1889: vpcmpeqb(vec3, vec3, vec1, 1); Using `Assembler::AVX_256bit` instead of `1` will make this easier to understand. ------------- PR: https://git.openjdk.java.net/jdk/pull/71 From simonis at openjdk.java.net Tue Sep 22 15:21:56 2020 From: simonis at openjdk.java.net (Volker Simonis) Date: Tue, 22 Sep 2020 15:21:56 GMT Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v2] In-Reply-To: <-DRWR4_f5u6DsSGHAuPnpHrhaG8Una8BXf4zDekQjLM=.469b08b6-a8b2-4a6b-8ab8-1a40810aede0@github.com> References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com> <-DRWR4_f5u6DsSGHAuPnpHrhaG8Una8BXf4zDekQjLM=.469b08b6-a8b2-4a6b-8ab8-1a40810aede0@github.com> Message-ID: On Fri, 18 Sep 2020 11:56:09 GMT, Jason Tatton wrote: >> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for >> x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it >> I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as >> code for C2. Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and >> java/lang/StringLatin1.java https://bugs.openjdk.java.net/browse/JDK-8173585 >> >> Details of testing: >> ============ >> I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note >> that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the >> input String. Hence the test has been designed to cover all these cases. In summary they are: >> - A ?short? string of < 16 characters. >> - A SIMD String of 16 ? 31 characters. >> - A AVX2 SIMD String of 32 characters+. >> >> Hardware used for testing: >> ----------------------------- >> >> - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support). >> - AWS Graviton 2 (ARM 64 processor). >> >> I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64. >> >> Possible future enhancements: >> ==================== >> For the x86 implementation there may be two further improvements we can make in order to improve performance of both >> the StringUTF16 and StringLatin1 indexOf(char) intrinsics: >> 1. Make use of AVX-512 instructions. >> 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD >> instructions instead of a loop. >> Benchmark results: >> ============ >> **Without** the new StringLatin1 indexOf(char) intrinsic: >> >> | Benchmark | Mode | Cnt | Score | Error | Units | >> | ------------- | ------------- |------------- |------------- |------------- |------------- | >> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op | >> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933 | ns/op | >> >> >> **With** the new StringLatin1 indexOf(char) intrinsic: >> >> | Benchmark | Mode | Cnt | Score | Error | Units | >> | ------------- | ------------- |------------- |------------- |------------- |------------- | >> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716 | ns/op | >> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306 | ns/op | >> >> >> The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16 >> indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when >> running on ARM. > > Jason Tatton has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains four commits: > - Merge master > - 8173585: further whitespace changes required by jcheck > - JDK-8173585 - whitespace changes required by jcheck > - JDK-8173585 Hi Jason, thanks for bringing String.indexOf() for latin strings up to date with the Unicode version. Your changes look good except a few minor issues I've commented on right in the code. I'd only like to ask you if you could possibly improve your test a little bit. As far as I understand, your search text is a consecutive sequence of "abc" characters, so you'll always find the character your searching for within the next three characters of the source text. This won't exercise the loops of your intrinsic. Maybe you can also add some test versions where the search character will be found beyond the first 32/64 characters after "fromIndex"? test/hotspot/jtreg/compiler/intrinsics/string/TestStringLatin1IndexOfChar.java line 24: > 22: > 23: public static void main(String[] args) throws Exception { > 24: for (int i = 0; i < 100_0; ++i) {//repeat such that we enter into C2 code... The placement of the underscore looks strange to me. I'd expect it to separate thousands (like 1_000) if at all but not sure if id use it for one thousand at all as that's really not such a big number that it is hard to read.. Also, the Tier4InvocationThreshold is 5000 so I'm not sure youre reaching C2? src/hotspot/share/classfile/vmSymbols.cpp line 295: > 293: if (symbol == NULL) return NO_SID; > 294: return find_sid(symbol); > 295: } I think it is common sense to have a newline at the end of a file. test/hotspot/jtreg/compiler/intrinsics/string/TestStringLatin1IndexOfChar.java line 84: > 82: } > 83: > 84: } Please put an EOL at the end of the file. test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java line 199: > 197: return ret; > 198: } > 199: } Please put an EOL at the end of the file. ------------- Changes requested by simonis (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/71 From jbhateja at openjdk.java.net Tue Sep 22 15:32:18 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 22 Sep 2020 15:32:18 GMT Subject: RFR: 8252848: Optimize small primitive arrayCopy operations through partial inlining using AVX-512 masked instructions Message-ID: Summary: 1) Partial in-lining technique avoids call overhead penalty for small array copy operations with size less than 32 bytes. 2) At runtime, a conditional check based on copy length either calls an array-copy stub or executes an optimized instruction sequence using AVX-512 masked instructions emitted at the call site. 3) New runtime flag ArrayCopyPartialInlineSize=0/32(default)/64 bytes determines the maximum size for partial in-lining. 4) Based on the perf results seen in benchmarks currently partial in-lining is performed only for arraycopy involving sub-word types (bool/byte/char/short). Once PR-61 gets integrated we can extend this patch to cover all the primitive types. Performance Results: System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java ArrayCopyPartialInlineSize : 32 JMH | Block Size | Baseline (ns/op) | Partial Inling (ns/op) | Gain -- | -- | -- | -- | -- ArrayCopyAligned.testByte | 1 | 5.417 | 2.696 | 2.009272997 ArrayCopyAligned.testByte | 3 | 5.494 | 2.702 | 2.03330866 ArrayCopyAligned.testByte | 5 | 5.417 | 2.637 | 2.05422829 ArrayCopyAligned.testByte | 10 | 5.343 | 2.703 | 1.976692564 ArrayCopyAligned.testByte | 20 | 5.837 | 2.636 | 2.214339909 ArrayCopyAligned.testByte | 70 | 5.86 | 6 | 0.976666667 ArrayCopyAligned.testByte | 150 | 6.766 | 6.906 | 0.979727773 ArrayCopyAligned.testByte | 300 | 7.605 | 7.952 | 0.956363179 ArrayCopyAligned.testByte | 600 | 11.989 | 12.007 | 0.998500874 ArrayCopyAligned.testByte | 1200 | 16.447 | 16.585 | 0.991679228 ArrayCopyAligned.testChar | 1 | 5.02 | 2.828 | 1.775106082 ArrayCopyAligned.testChar | 3 | 5.129 | 2.762 | 1.85698769 ArrayCopyAligned.testChar | 5 | 5.041 | 2.762 | 1.82512672 ArrayCopyAligned.testChar | 10 | 5.716 | 2.762 | 2.069514844 ArrayCopyAligned.testChar | 20 | 5.111 | 5.399 | 0.946656788 ArrayCopyAligned.testChar | 70 | 6.271 | 6.242 | 1.004645947 ArrayCopyAligned.testChar | 150 | 7.45 | 7.599 | 0.980392157 ArrayCopyAligned.testChar | 300 | 9.904 | 10.112 | 0.97943038 ArrayCopyAligned.testChar | 600 | 17.131 | 17.167 | 0.997902953 ArrayCopyAligned.testChar | 1200 | 29.556 | 29.851 | 0.990117584 ArrayCopyUnalignedBoth.testByte | 1 | 5.419 | 2.702 | 2.005551443 ArrayCopyUnalignedBoth.testByte | 3 | 5.558 | 2.636 | 2.108497724 ArrayCopyUnalignedBoth.testByte | 5 | 5.43 | 2.636 | 2.059939302 ArrayCopyUnalignedBoth.testByte | 10 | 5.378 | 2.637 | 2.039438756 ArrayCopyUnalignedBoth.testByte | 20 | 5.914 | 2.636 | 2.243550836 ArrayCopyUnalignedBoth.testByte | 70 | 5.882 | 5.954 | 0.987907289 ArrayCopyUnalignedBoth.testByte | 150 | 6.784 | 6.88 | 0.986046512 ArrayCopyUnalignedBoth.testByte | 300 | 7.635 | 7.968 | 0.958207831 ArrayCopyUnalignedBoth.testByte | 600 | 12.226 | 12.129 | 1.007997362 ArrayCopyUnalignedBoth.testByte | 1200 | 16.992 | 20.717 | 0.820195974 ArrayCopyUnalignedBoth.testChar | 1 | 5.019 | 2.828 | 1.774752475 ArrayCopyUnalignedBoth.testChar | 3 | 5.163 | 2.763 | 1.868621064 ArrayCopyUnalignedBoth.testChar | 5 | 5.042 | 2.827 | 1.783516095 ArrayCopyUnalignedBoth.testChar | 10 | 5.718 | 2.828 | 2.021923621 ArrayCopyUnalignedBoth.testChar | 20 | 5.111 | 5.404 | 0.945780903 ArrayCopyUnalignedBoth.testChar | 70 | 6.367 | 6.235 | 1.02117081 ArrayCopyUnalignedBoth.testChar | 150 | 7.367 | 8.269 | 0.890917886 ArrayCopyUnalignedBoth.testChar | 300 | 10.358 | 10.642 | 0.973313287 ArrayCopyUnalignedBoth.testChar | 600 | 20.84 | 17.522 | 1.189361945 ArrayCopyUnalignedBoth.testChar | 1200 | 31.895 | 31.892 | 1.000094067 ArrayCopyUnalignedDst.testByte | 1 | 5.455 | 2.637 | 2.068638604 ArrayCopyUnalignedDst.testByte | 3 | 5.562 | 2.702 | 2.058475204 ArrayCopyUnalignedDst.testByte | 5 | 5.427 | 2.702 | 2.008512213 ArrayCopyUnalignedDst.testByte | 10 | 5.367 | 2.696 | 1.990727003 ArrayCopyUnalignedDst.testByte | 20 | 5.839 | 2.637 | 2.214258627 ArrayCopyUnalignedDst.testByte | 70 | 5.888 | 5.968 | 0.986595174 ArrayCopyUnalignedDst.testByte | 150 | 6.785 | 6.773 | 1.001771741 ArrayCopyUnalignedDst.testByte | 300 | 7.606 | 7.972 | 0.954089313 ArrayCopyUnalignedDst.testByte | 600 | 11.986 | 21.195 | 0.565510734 ArrayCopyUnalignedDst.testByte | 1200 | 16.54 | 16.784 | 0.985462345 ArrayCopyUnalignedDst.testChar | 1 | 5.02 | 2.827 | 1.775733994 ArrayCopyUnalignedDst.testChar | 3 | 5.131 | 2.762 | 1.857711803 ArrayCopyUnalignedDst.testChar | 5 | 5.038 | 2.762 | 1.82404055 ArrayCopyUnalignedDst.testChar | 10 | 5.718 | 2.762 | 2.070238957 ArrayCopyUnalignedDst.testChar | 20 | 5.113 | 5.401 | 0.946676541 ArrayCopyUnalignedDst.testChar | 70 | 6.222 | 6.214 | 1.001287416 ArrayCopyUnalignedDst.testChar | 150 | 7.367 | 8.125 | 0.906707692 ArrayCopyUnalignedDst.testChar | 300 | 10.204 | 10.082 | 1.012100774 ArrayCopyUnalignedDst.testChar | 600 | 16.978 | 17.135 | 0.990837467 ArrayCopyUnalignedDst.testChar | 1200 | 32.351 | 31.996 | 1.011095137 ArrayCopyUnalignedSrc.testByte | 1 | 5.414 | 2.696 | 2.008160237 ArrayCopyUnalignedSrc.testByte | 3 | 5.494 | 2.637 | 2.083428138 ArrayCopyUnalignedSrc.testByte | 5 | 5.431 | 2.637 | 2.059537353 ArrayCopyUnalignedSrc.testByte | 10 | 5.344 | 2.703 | 1.977062523 ArrayCopyUnalignedSrc.testByte | 20 | 5.834 | 2.696 | 2.163946588 ArrayCopyUnalignedSrc.testByte | 70 | 5.883 | 6.009 | 0.979031453 ArrayCopyUnalignedSrc.testByte | 150 | 6.729 | 6.87 | 0.979475983 ArrayCopyUnalignedSrc.testByte | 300 | 7.603 | 7.97 | 0.953952321 ArrayCopyUnalignedSrc.testByte | 600 | 12.004 | 12.16 | 0.987171053 ArrayCopyUnalignedSrc.testByte | 1200 | 16.534 | 16.643 | 0.9934507 ArrayCopyUnalignedSrc.testChar | 1 | 5.021 | 2.762 | 1.81788559 ArrayCopyUnalignedSrc.testChar | 3 | 5.13 | 2.762 | 1.857349747 ArrayCopyUnalignedSrc.testChar | 5 | 5.042 | 2.827 | 1.783516095 ArrayCopyUnalignedSrc.testChar | 10 | 5.726 | 2.761 | 2.073886273 ArrayCopyUnalignedSrc.testChar | 20 | 5.112 | 5.401 | 0.94649139 ArrayCopyUnalignedSrc.testChar | 70 | 6.113 | 6.227 | 0.981692629 ArrayCopyUnalignedSrc.testChar | 150 | 7.493 | 7.888 | 0.949923935 ArrayCopyUnalignedSrc.testChar | 300 | 10.234 | 10.501 | 0.97457385 ArrayCopyUnalignedSrc.testChar | 600 | 17.175 | 17.142 | 1.001925096 ArrayCopyUnalignedSrc.testChar | 1200 | 31.926 | 31.987 | 0.998092975 Detailed Reports: Baseline : [http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_Baseline.txt](http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_Baseline.txt) WithOpt : [http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_With_PI_Opts.txt](http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_With_PI_Opts.txt) ------------- Commit messages: - 8252848: Optimize small primitive arrayCopy operations through partial inlining using AVX-512 masked instructions. Changes: https://git.openjdk.java.net/jdk/pull/302/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=302&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252848 Stats: 515 lines in 23 files changed: 495 ins; 0 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/302.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/302/head:pull/302 PR: https://git.openjdk.java.net/jdk/pull/302 From jbhateja at openjdk.java.net Tue Sep 22 15:35:29 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 22 Sep 2020 15:35:29 GMT Subject: RFR: 8252848: Optimize small primitive arrayCopy operations through partial inlining using AVX-512 masked instructions In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 15:24:41 GMT, Jatin Bhateja wrote: > Summary: > > 1) Partial in-lining technique avoids call overhead penalty for small array copy operations with size less than 32 > bytes. 2) At runtime, a conditional check based on copy length either calls an array-copy stub or executes an optimized > instruction sequence using AVX-512 masked instructions emitted at the call site. 3) New runtime flag > ArrayCopyPartialInlineSize=0/32(default)/64 bytes determines the maximum size for partial in-lining. 4) Based on the > perf results seen in benchmarks currently partial in-lining is performed only for arraycopy involving sub-word types > (bool/byte/char/short). Once PR-61 gets integrated we can extend this patch to cover all the primitive types. > Performance Results: > System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz > Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java > ArrayCopyPartialInlineSize : 32 > > JMH | Block Size | Baseline (ns/op) | Partial Inling (ns/op) | Gain > -- | -- | -- | -- | -- > ArrayCopyAligned.testByte | 1 | 5.417 | 2.696 | 2.009272997 > ArrayCopyAligned.testByte | 3 | 5.494 | 2.702 | 2.03330866 > ArrayCopyAligned.testByte | 5 | 5.417 | 2.637 | 2.05422829 > ArrayCopyAligned.testByte | 10 | 5.343 | 2.703 | 1.976692564 > ArrayCopyAligned.testByte | 20 | 5.837 | 2.636 | 2.214339909 > ArrayCopyAligned.testByte | 70 | 5.86 | 6 | 0.976666667 > ArrayCopyAligned.testByte | 150 | 6.766 | 6.906 | 0.979727773 > ArrayCopyAligned.testByte | 300 | 7.605 | 7.952 | 0.956363179 > ArrayCopyAligned.testByte | 600 | 11.989 | 12.007 | 0.998500874 > ArrayCopyAligned.testByte | 1200 | 16.447 | 16.585 | 0.991679228 > ArrayCopyAligned.testChar | 1 | 5.02 | 2.828 | 1.775106082 > ArrayCopyAligned.testChar | 3 | 5.129 | 2.762 | 1.85698769 > ArrayCopyAligned.testChar | 5 | 5.041 | 2.762 | 1.82512672 > ArrayCopyAligned.testChar | 10 | 5.716 | 2.762 | 2.069514844 > ArrayCopyAligned.testChar | 20 | 5.111 | 5.399 | 0.946656788 > ArrayCopyAligned.testChar | 70 | 6.271 | 6.242 | 1.004645947 > ArrayCopyAligned.testChar | 150 | 7.45 | 7.599 | 0.980392157 > ArrayCopyAligned.testChar | 300 | 9.904 | 10.112 | 0.97943038 > ArrayCopyAligned.testChar | 600 | 17.131 | 17.167 | 0.997902953 > ArrayCopyAligned.testChar | 1200 | 29.556 | 29.851 | 0.990117584 > ArrayCopyUnalignedBoth.testByte | 1 | 5.419 | 2.702 | 2.005551443 > ArrayCopyUnalignedBoth.testByte | 3 | 5.558 | 2.636 | 2.108497724 > ArrayCopyUnalignedBoth.testByte | 5 | 5.43 | 2.636 | 2.059939302 > ArrayCopyUnalignedBoth.testByte | 10 | 5.378 | 2.637 | 2.039438756 > ArrayCopyUnalignedBoth.testByte | 20 | 5.914 | 2.636 | 2.243550836 > ArrayCopyUnalignedBoth.testByte | 70 | 5.882 | 5.954 | 0.987907289 > ArrayCopyUnalignedBoth.testByte | 150 | 6.784 | 6.88 | 0.986046512 > ArrayCopyUnalignedBoth.testByte | 300 | 7.635 | 7.968 | 0.958207831 > ArrayCopyUnalignedBoth.testByte | 600 | 12.226 | 12.129 | 1.007997362 > ArrayCopyUnalignedBoth.testByte | 1200 | 16.992 | 20.717 | 0.820195974 > ArrayCopyUnalignedBoth.testChar | 1 | 5.019 | 2.828 | 1.774752475 > ArrayCopyUnalignedBoth.testChar | 3 | 5.163 | 2.763 | 1.868621064 > ArrayCopyUnalignedBoth.testChar | 5 | 5.042 | 2.827 | 1.783516095 > ArrayCopyUnalignedBoth.testChar | 10 | 5.718 | 2.828 | 2.021923621 > ArrayCopyUnalignedBoth.testChar | 20 | 5.111 | 5.404 | 0.945780903 > ArrayCopyUnalignedBoth.testChar | 70 | 6.367 | 6.235 | 1.02117081 > ArrayCopyUnalignedBoth.testChar | 150 | 7.367 | 8.269 | 0.890917886 > ArrayCopyUnalignedBoth.testChar | 300 | 10.358 | 10.642 | 0.973313287 > ArrayCopyUnalignedBoth.testChar | 600 | 20.84 | 17.522 | 1.189361945 > ArrayCopyUnalignedBoth.testChar | 1200 | 31.895 | 31.892 | 1.000094067 > ArrayCopyUnalignedDst.testByte | 1 | 5.455 | 2.637 | 2.068638604 > ArrayCopyUnalignedDst.testByte | 3 | 5.562 | 2.702 | 2.058475204 > ArrayCopyUnalignedDst.testByte | 5 | 5.427 | 2.702 | 2.008512213 > ArrayCopyUnalignedDst.testByte | 10 | 5.367 | 2.696 | 1.990727003 > ArrayCopyUnalignedDst.testByte | 20 | 5.839 | 2.637 | 2.214258627 > ArrayCopyUnalignedDst.testByte | 70 | 5.888 | 5.968 | 0.986595174 > ArrayCopyUnalignedDst.testByte | 150 | 6.785 | 6.773 | 1.001771741 > ArrayCopyUnalignedDst.testByte | 300 | 7.606 | 7.972 | 0.954089313 > ArrayCopyUnalignedDst.testByte | 600 | 11.986 | 21.195 | 0.565510734 > ArrayCopyUnalignedDst.testByte | 1200 | 16.54 | 16.784 | 0.985462345 > ArrayCopyUnalignedDst.testChar | 1 | 5.02 | 2.827 | 1.775733994 > ArrayCopyUnalignedDst.testChar | 3 | 5.131 | 2.762 | 1.857711803 > ArrayCopyUnalignedDst.testChar | 5 | 5.038 | 2.762 | 1.82404055 > ArrayCopyUnalignedDst.testChar | 10 | 5.718 | 2.762 | 2.070238957 > ArrayCopyUnalignedDst.testChar | 20 | 5.113 | 5.401 | 0.946676541 > ArrayCopyUnalignedDst.testChar | 70 | 6.222 | 6.214 | 1.001287416 > ArrayCopyUnalignedDst.testChar | 150 | 7.367 | 8.125 | 0.906707692 > ArrayCopyUnalignedDst.testChar | 300 | 10.204 | 10.082 | 1.012100774 > ArrayCopyUnalignedDst.testChar | 600 | 16.978 | 17.135 | 0.990837467 > ArrayCopyUnalignedDst.testChar | 1200 | 32.351 | 31.996 | 1.011095137 > ArrayCopyUnalignedSrc.testByte | 1 | 5.414 | 2.696 | 2.008160237 > ArrayCopyUnalignedSrc.testByte | 3 | 5.494 | 2.637 | 2.083428138 > ArrayCopyUnalignedSrc.testByte | 5 | 5.431 | 2.637 | 2.059537353 > ArrayCopyUnalignedSrc.testByte | 10 | 5.344 | 2.703 | 1.977062523 > ArrayCopyUnalignedSrc.testByte | 20 | 5.834 | 2.696 | 2.163946588 > ArrayCopyUnalignedSrc.testByte | 70 | 5.883 | 6.009 | 0.979031453 > ArrayCopyUnalignedSrc.testByte | 150 | 6.729 | 6.87 | 0.979475983 > ArrayCopyUnalignedSrc.testByte | 300 | 7.603 | 7.97 | 0.953952321 > ArrayCopyUnalignedSrc.testByte | 600 | 12.004 | 12.16 | 0.987171053 > ArrayCopyUnalignedSrc.testByte | 1200 | 16.534 | 16.643 | 0.9934507 > ArrayCopyUnalignedSrc.testChar | 1 | 5.021 | 2.762 | 1.81788559 > ArrayCopyUnalignedSrc.testChar | 3 | 5.13 | 2.762 | 1.857349747 > ArrayCopyUnalignedSrc.testChar | 5 | 5.042 | 2.827 | 1.783516095 > ArrayCopyUnalignedSrc.testChar | 10 | 5.726 | 2.761 | 2.073886273 > ArrayCopyUnalignedSrc.testChar | 20 | 5.112 | 5.401 | 0.94649139 > ArrayCopyUnalignedSrc.testChar | 70 | 6.113 | 6.227 | 0.981692629 > ArrayCopyUnalignedSrc.testChar | 150 | 7.493 | 7.888 | 0.949923935 > ArrayCopyUnalignedSrc.testChar | 300 | 10.234 | 10.501 | 0.97457385 > ArrayCopyUnalignedSrc.testChar | 600 | 17.175 | 17.142 | 1.001925096 > ArrayCopyUnalignedSrc.testChar | 1200 | 31.926 | 31.987 | 0.998092975 > > Detailed Reports: > Baseline : > [http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_Baseline.txt](http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_Baseline.txt) > WithOpt : > [http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_With_PI_Opts.txt](http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_With_PI_Opts.txt) This pull request is an incremental work over [pull request-61](https://github.com/openjdk/jdk/pull/61). It shares leaf level assembler routines with it, to build the standalone patch following common code patch needs to be applied on top of this PR. http://cr.openjdk.java.net/~jbhateja/8252848/common_code_with_8252847.diff ------------- PR: https://git.openjdk.java.net/jdk/pull/302 From dcubed at openjdk.java.net Tue Sep 22 15:40:41 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Sep 2020 15:40:41 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing In-Reply-To: References: <1iLCRf17v1nwE70nQk7qq0bcad8gop9q5dYt-sr9fG8=.81025951-bc22-45d0-84ff-9557b67262e3@github.com> <0iHoaOyRCFzhpuXNG78m6xgv5B_xBPlyUdNx_dnqBJQ=.e9270174-1980-454d-90a3-e27a5b7daac2@github.com> Message-ID: <3bvLkcQ84vROOOcdEQcMR29DQHrfpoWt9hlwfz1m3YA=.2ea7a58d-cbd5-439c-8d98-2cf26eeed22d@github.com> On Tue, 22 Sep 2020 15:09:51 GMT, Erik ?sterlund wrote: >> @fisk - You are missing testing information for this PR. > >> @fisk - You are missing testing information for this PR. > > Sorry about that. I have performed testing with ZGC enabled from tier1-7 (multiple times), and standard testing > tier1-5. I have also stress tested the change with gc-test-suite, with full verification on (there is a bunch of it), > and the GC interval reduced to very small (GC all the time). Recent versions of this patch I also tested from tier1-8 > (2 times). I have also perf tested this in dev-submit to check for regressions (none found), as well as stress tested > SPECjbb2015 on a 3 TB machine with ~2200 threads. I have also manually stress tested the changes on an AArch64 machine, > using gc-test-suite. @fisk - Thanks for the info. An amazing amount of testing!! ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From iklam at openjdk.java.net Tue Sep 22 15:41:36 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 22 Sep 2020 15:41:36 GMT Subject: RFR: 8247912: Make narrowOop a scoped enum [v2] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 13:43:54 GMT, Kim Barrett wrote: >> Please review this change to the type narrowOop from a typedef for juint to a >> scoped enum with uint32_t as the representation type. This provides stronger >> type checking when using this type. >> >> For the most part this was fairly straightforward, and the patch size is >> relatively small. The implementation of some existing CompressedOops >> "primitives" required adjustment. An explicit conversion to narrowOop was >> added, with casts change to use it. There were a few places that were type >> punning and needed explicit conversions,, mostly in platform-specific assembly >> support. >> >> There are a couple of lingering problems. >> >> Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass >> as a narrowOop. I adjusted the code to accommodate the narrowOop change, but >> this probably ought to be done differently. >> >> There are a couple of `(narrowOop)` casts remaining in s390.ad. I'm not sure >> whether these can be safely converted to CompressedOops::narrow_oop_cast. >> >> There might still be some casts from narrowOop to an integral type. Those are >> hard to find in our cast-happy code base. >> >> Testing: >> tier1-6 for Oracle supported platforms. >> Build fastdebug linux-ppc64le and linux-s390x. > > Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: > > - improve assertion > - remove NarrowType Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/273 From jbhateja at openjdk.java.net Tue Sep 22 15:47:29 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 22 Sep 2020 15:47:29 GMT Subject: RFR: 8252847: New AVX512 optimized stubs for both conjoint and disjoint arraycopy [v4] In-Reply-To: References: Message-ID: > Summary: > > 1) New AVX3 optimized stubs for both conjoint and disjoint arraycopy. > 2) Special instruction sequence blocks for copy sizes b/w 32-192 bytes. > 3) Block copy operation above 192 bytes is performed using destination address aligned PRE-MAIN-POST loop. Main loop > copies 192 byte in one iteration and tail part fall over special instruction sequence blocks. 4) Both small copy block > and aligned loop use 32 byte vector register to prevent and frequency penalty for copy sizes less than AVX3Threshold. > 5) For block size above AVX3Theshold both special blocks and loop operate using 64 byte register. 6) In case user > sets the maximum vector size to 32 bytes, forward copy (disjoint) operations are done using efficient REP MOVS for copy > sizes above 4096 bytes. JMH Results: > System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz > Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java > Baseline : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_Baseline.txt]() > WithOpt : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_WithOpts.txt]() Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8252847: Review comments resolution; code reorganized to cover arraycopy for reference types. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/61/files - new: https://git.openjdk.java.net/jdk/pull/61/files/271b6457..fadd3687 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=61&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=61&range=02-03 Stats: 691 lines in 5 files changed: 340 ins; 198 del; 153 mod Patch: https://git.openjdk.java.net/jdk/pull/61.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/61/head:pull/61 PR: https://git.openjdk.java.net/jdk/pull/61 From iklam at openjdk.java.net Tue Sep 22 15:47:46 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 22 Sep 2020 15:47:46 GMT Subject: RFR: 8247912: Make narrowOop a scoped enum [v2] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 15:38:21 GMT, Ioi Lam wrote: >> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: >> >> - improve assertion >> - remove NarrowType > > Marked as reviewed by iklam (Reviewer). > > Also, should we allow only unsigned types for T? I think using signed types here is prone to error and should be > > flagged. > > It turns out we can't restrict it to unsigned types, at least not very easily. For example, > CDS calls this with an intptr_t value. I suppose CDS could do conversion itself before > calling this, but that seems a little odd. And I don't know how many more there are after > changing that one. But shouldn't intptr_t be unsigned? I tested with this: #include #include int main() { printf("%d %d\n", std::is_signed::value, std::is_signed::value); } and it prints out "1 0". ------------- PR: https://git.openjdk.java.net/jdk/pull/273 From jbhateja at openjdk.java.net Tue Sep 22 15:55:11 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 22 Sep 2020 15:55:11 GMT Subject: RFR: 8252847: New AVX512 optimized stubs for both conjoint and disjoint arraycopy [v5] In-Reply-To: References: Message-ID: > Summary: > > 1) New AVX3 optimized stubs for both conjoint and disjoint arraycopy. > 2) Special instruction sequence blocks for copy sizes b/w 32-192 bytes. > 3) Block copy operation above 192 bytes is performed using destination address aligned PRE-MAIN-POST loop. Main loop > copies 192 byte in one iteration and tail part fall over special instruction sequence blocks. 4) Both small copy block > and aligned loop use 32 byte vector register to prevent and frequency penalty for copy sizes less than AVX3Threshold. > 5) For block size above AVX3Theshold both special blocks and loop operate using 64 byte register. 6) In case user > sets the maximum vector size to 32 bytes, forward copy (disjoint) operations are done using efficient REP MOVS for copy > sizes above 4096 bytes. JMH Results: > System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz > Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java > Baseline : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_Baseline.txt]() > WithOpt : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_WithOpts.txt]() Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8252847 : Modifying file permission to resolve jcheck failure. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/61/files - new: https://git.openjdk.java.net/jdk/pull/61/files/fadd3687..78c4fe73 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=61&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=61&range=03-04 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/61.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/61/head:pull/61 PR: https://git.openjdk.java.net/jdk/pull/61 From mchung at openjdk.java.net Tue Sep 22 16:03:07 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 22 Sep 2020 16:03:07 GMT Subject: RFR: 8253208: Move CDS related code to a separate class [v3] In-Reply-To: <7yHEh89XlpTGoXfHw85_SVEKEBM0t03tQlkZ7tKm4P0=.399d9d6c-c375-4892-a92c-3cd6806e51d6@github.com> References: <7yHEh89XlpTGoXfHw85_SVEKEBM0t03tQlkZ7tKm4P0=.399d9d6c-c375-4892-a92c-3cd6806e51d6@github.com> Message-ID: <8hwfOa6oYGE3dZPVcdltbIO_lVzRHFeztiTrFAFaIr0=.f4082018-d17a-40ee-94f7-14fef9872579@github.com> On Mon, 21 Sep 2020 22:24:15 GMT, Yumin Qi wrote: >> With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is >> specific to CDS. >> Tests: tier1-4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > 8253208: Move CDS related code to a separate class Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From minqi at openjdk.java.net Tue Sep 22 16:14:40 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 22 Sep 2020 16:14:40 GMT Subject: Integrated: 8253208: Move CDS related code to a separate class In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 23:47:56 GMT, Yumin Qi wrote: > With more CDS related code added to VM, it is time to move CDS code to a separate class. CDS is the new class which is > specific to CDS. > Tests: tier1-4 This pull request has now been integrated. Changeset: c1df13b8 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/c1df13b8 Stats: 218 lines in 23 files changed: 53 ins; 119 del; 46 mod 8253208: Move CDS related code to a separate class Reviewed-by: mchung, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/261 From jbhateja at openjdk.java.net Tue Sep 22 16:38:56 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 22 Sep 2020 16:38:56 GMT Subject: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions [v3] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 03:34:37 GMT, Vladimir Kozlov wrote: > @jatin-bhateja Can you put summary of performance improvement into JBS? yes, I have added the summary in JBS. ------------- PR: https://git.openjdk.java.net/jdk/pull/61 From jbhateja at openjdk.java.net Tue Sep 22 16:41:48 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 22 Sep 2020 16:41:48 GMT Subject: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions [v3] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 03:34:37 GMT, Vladimir Kozlov wrote: > @jatin-bhateja Can you put summary of performance improvement into JBS? Yes, I have added the summary to JBS ------------- PR: https://git.openjdk.java.net/jdk/pull/61 From erikj at openjdk.java.net Tue Sep 22 17:02:59 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 22 Sep 2020 17:02:59 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v3] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 07:10:47 GMT, Bernhard Urban-Forster wrote: >> I assume you need the rest of the PATH on Windows. > >> I assume you need the rest of the PATH on Windows. > > Doesn't look like it actually. I've reverted it, thanks for catching it. Thanks, I tried the updated patch and it works now. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From pchilanomate at openjdk.java.net Tue Sep 22 17:50:27 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 22 Sep 2020 17:50:27 GMT Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 07:54:57 GMT, Robbin Ehn wrote: >> This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes >> are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) >> Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an >> arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a >> singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first >> pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first >> pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake >> operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything >> except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed >> filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake >> operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there >> is now only one method to call when handshaking one thread. Some comments about the changes: >> - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake >> all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much >> worse then this. >> >> - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that >> thread. >> >> - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a >> handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. >> >> - Added WB testing method. >> >> - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. >> >> - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. >> >> - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a >> safepoint and half of them after, in many handshake all operations. >> >> - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. >> >> - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the >> moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. >> >> - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. >> >> - Added filtered queue and gtest for it. >> >> Passes multiple t1-8 runs. >> Been through some pre-reviwing. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Update after Coleen Marked as reviewed by pchilanomate (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From mbeckwit at openjdk.java.net Tue Sep 22 18:38:11 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Tue, 22 Sep 2020 18:38:11 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v4] In-Reply-To: References: Message-ID: <9AWXqWBreFSnBvXc9kzj0R7RIIRjmdg3nDz859KKD5Q=.df3d538f-a8d7-4e22-8d8c-76371172f75d@github.com> > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - 8248787: G1: Workaround MSVC bug Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248670: Windows: Exception handling support on AArch64 Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248660: AArch64: Make _clear_cache and _nop portable Summary: __builtin___clear_cache, etc. Contributed-by: mbeckwit, luhenry, burban - 8248659: AArch64: Extend CPU Feature detection Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248656: Add Windows AArch64 platform support code Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248498: Add build system support for Windows AArch64 Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248681: AArch64: MSVC doesn't support __PRETTY_FUNCTION__ Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248663: AArch64: Avoid existing macros/keywords of MSVC Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248676: AArch64: Add workaround for LITable constructor Reviewed-by: aph Contributed-by: mbeckwit, luhenry, burban - 8248500: AArch64: Remove the r18 dependency on Windows AArch64 (regenerate tests) Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - ... and 3 more: https://git.openjdk.java.net/jdk/compare/7b860120...50ab8edf ------------- Changes: https://git.openjdk.java.net/jdk/pull/212/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=03 Stats: 2970 lines in 69 files changed: 2407 ins; 275 del; 288 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From iklam at openjdk.java.net Tue Sep 22 19:57:51 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 22 Sep 2020 19:57:51 GMT Subject: RFR: 8253496: [BACKOUT] JDK-8253208 Move CDS related code to a separate class Message-ID: Please review this BACKOUT for tier-1 failures. I have tested all CDS tests locally on Linux-x64, including the failed DeterministicDump.java. I would like to apply for the "trivial" rule since this is a simple backout for tier-1 failures. I executed the command: git revert c1df13b855984dc2197c0561f7a50c7a5a731dd9 and them manually fixed the conflict with 7b860120e130c13de8ba543a8706c9ecdeab468b. ------------- Commit messages: - [BACKOUT] JDK-8253208 Move CDS related code to a separate class Changes: https://git.openjdk.java.net/jdk/pull/308/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=308&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253496 Stats: 156 lines in 22 files changed: 53 ins; 57 del; 46 mod Patch: https://git.openjdk.java.net/jdk/pull/308.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/308/head:pull/308 PR: https://git.openjdk.java.net/jdk/pull/308 From dcubed at openjdk.java.net Tue Sep 22 20:09:17 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 22 Sep 2020 20:09:17 GMT Subject: RFR: 8253496: [BACKOUT] JDK-8253208 Move CDS related code to a separate class In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 19:48:33 GMT, Ioi Lam wrote: > Please review this BACKOUT for tier-1 failures. I have tested all CDS tests locally on Linux-x64, including the failed > DeterministicDump.java. > I would like to apply for the "trivial" rule since this is a simple backout for tier-1 failures. > > I executed the command: > > git revert c1df13b855984dc2197c0561f7a50c7a5a731dd9 > > and them manually fixed the conflict with 7b860120e130c13de8ba543a8706c9ecdeab468b. I compared the full webrev patch for this fix with the full webrev patch for JDK-8253208. This looks like a proper backout/revert. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/308 From eosterlund at openjdk.java.net Tue Sep 22 20:09:17 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 22 Sep 2020 20:09:17 GMT Subject: RFR: 8253496: [BACKOUT] JDK-8253208 Move CDS related code to a separate class In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 19:48:33 GMT, Ioi Lam wrote: > Please review this BACKOUT for tier-1 failures. I have tested all CDS tests locally on Linux-x64, including the failed > DeterministicDump.java. > I would like to apply for the "trivial" rule since this is a simple backout for tier-1 failures. > > I executed the command: > > git revert c1df13b855984dc2197c0561f7a50c7a5a731dd9 > > and them manually fixed the conflict with 7b860120e130c13de8ba543a8706c9ecdeab468b. Marked as reviewed by eosterlund (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/308 From iklam at openjdk.java.net Tue Sep 22 20:17:41 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 22 Sep 2020 20:17:41 GMT Subject: Integrated: 8253496: [BACKOUT] JDK-8253208 Move CDS related code to a separate class In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 19:48:33 GMT, Ioi Lam wrote: > Please review this BACKOUT for tier-1 failures. I have tested all CDS tests locally on Linux-x64, including the failed > DeterministicDump.java. > I would like to apply for the "trivial" rule since this is a simple backout for tier-1 failures. > > I executed the command: > > git revert c1df13b855984dc2197c0561f7a50c7a5a731dd9 > > and them manually fixed the conflict with 7b860120e130c13de8ba543a8706c9ecdeab468b. This pull request has now been integrated. Changeset: 65af8373 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/65af8373 Stats: 156 lines in 22 files changed: 57 ins; 53 del; 46 mod 8253496: [BACKOUT] JDK-8253208 Move CDS related code to a separate class Reviewed-by: eosterlund, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/308 From coleenp at openjdk.java.net Tue Sep 22 21:05:46 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 22 Sep 2020 21:05:46 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v2] In-Reply-To: <8KYOSvjbrmDhnP3_WLOu0dO0saiWTHp1SBgE3ikOJkE=.dd9b9e50-2bb5-47cb-a67f-e7c5293ef1d2@github.com> References: <8KYOSvjbrmDhnP3_WLOu0dO0saiWTHp1SBgE3ikOJkE=.dd9b9e50-2bb5-47cb-a67f-e7c5293ef1d2@github.com> Message-ID: On Mon, 21 Sep 2020 07:33:27 GMT, Robbin Ehn wrote: >> We simplify the vmThread by removing the queue and refactor the the main loop. >> This solves the issues listed: >> - It can create an extra safepoint directly after a safepoint. >> - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. >> - The exposure of the vm operation is dangerous if it's a handshake. >> - The code is a hornets nest with the repetition of checks and branches >> >> Passes t1-8, and a benchmark run. >> >> If you want a smaller diff the commits contains the incremental progress and each commit passed t1. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since > the last revision: > - Merge branch 'master' into 8212107-vmthread > - Fixed nits > - Merge branch 'master' into 8212107-vmthread > - Fixes after review from shipilev. > - Fixed some indent misses > - Fixed ws > - Added assert > - Restructured and simplified > - Removed used linking in VM_Operation > - Removed ticket and use only one Monitor > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6c757159...e49178a4 Looks like a nice cleanup. I had a couple of questions. src/hotspot/share/runtime/vmThread.cpp line 52: > 50: #include "utilities/events.hpp" > 51: #include "utilities/vmError.hpp" > 52: #include "utilities/xmlstream.hpp" Since you've changed a lot of the body of this, can you make sure that all these header files are needed? method.hpp, runtimeService.hpp and dtrace.hpp may no longer be needed. Check with precompiled headers off though. src/hotspot/share/runtime/vmThread.cpp line 351: > 349: if (VMThread::vm_thread()->set_next_operation(op)) { > 350: ml.notify_all(); > 351: break; I was wondering if you should put some counter while the thread is waiting to install its operation for logging and debugging purposes? Since the supposition is that there are few operations that cause safepoints so there's never a long wait. src/hotspot/share/runtime/vmThread.cpp line 352: > 350: ml.notify_all(); > 351: break; > 352: } // Wait to install this operation as the next operation in the VM Thread src/hotspot/share/runtime/vmThread.cpp line 357: > 355: // _next_vm_operation is cleared holding VMOperation_lock > 356: // after it have been executed. > 357: while (_next_vm_operation == op) { // Wait until the operation has been processed But can this operation still be being processed as the current process? Anyway can you add a couple of comments to help the reader. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/228 From amenkov at openjdk.java.net Tue Sep 22 22:57:49 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 22 Sep 2020 22:57:49 GMT Subject: RFR: 8253372: [TESTBUG] update tests which require jvmti - hotspot Message-ID: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com> This is subtask which covers test in hotspot/jtreg except test/hotspot/jtreg/vmTestbase/nsk/jvmti (there is a separate issue for it: JDK-8253371) In most tests just "@requires vm.jvmti" is added, in several test '@requires vm.flavor != "minimal"' is removed (when this requirement is only to ensure test VM has JVMTI included) ------------- Commit messages: - 8253372: [TESTBUG] update tests which require jvmti - hotspot Changes: https://git.openjdk.java.net/jdk/pull/314/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=314&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253372 Stats: 38 lines in 36 files changed: 25 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/314.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/314/head:pull/314 PR: https://git.openjdk.java.net/jdk/pull/314 From cjplummer at openjdk.java.net Tue Sep 22 23:10:37 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 22 Sep 2020 23:10:37 GMT Subject: RFR: 8253372: [TESTBUG] update tests which require jvmti - hotspot In-Reply-To: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com> References: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com> Message-ID: <_wP0b5uSUa6fQ23NaIK5RsUj_dZnoda3L_OOxxL6CbI=.ff626b36-a833-4ad0-966f-82994942b2bc@github.com> On Tue, 22 Sep 2020 22:51:13 GMT, Alex Menkov wrote: > This is subtask which covers test in hotspot/jtreg except test/hotspot/jtreg/vmTestbase/nsk/jvmti (there is a separate > issue for it: JDK-8253371) > In most tests just "@requires vm.jvmti" is added, > in several test '@requires vm.flavor != "minimal"' is removed (when this requirement is only to ensure test VM has > JVMTI included) How did you determine the list of tests that need jvmti? ------------- PR: https://git.openjdk.java.net/jdk/pull/314 From iklam at openjdk.java.net Tue Sep 22 23:38:46 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 22 Sep 2020 23:38:46 GMT Subject: RFR: 8253372: [TESTBUG] update tests which require jvmti - hotspot In-Reply-To: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com> References: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com> Message-ID: On Tue, 22 Sep 2020 22:51:13 GMT, Alex Menkov wrote: > This is subtask which covers test in hotspot/jtreg except test/hotspot/jtreg/vmTestbase/nsk/jvmti (there is a separate > issue for it: JDK-8253371) > In most tests just "@requires vm.jvmti" is added, > in several test '@requires vm.flavor != "minimal"' is removed (when this requirement is only to ensure test VM has > JVMTI included) The CDS test changes look good to me. Thanks for doing this. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/314 From sspitsyn at openjdk.java.net Tue Sep 22 23:38:46 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 22 Sep 2020 23:38:46 GMT Subject: RFR: 8253372: [TESTBUG] update tests which require jvmti - hotspot In-Reply-To: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com> References: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com> Message-ID: On Tue, 22 Sep 2020 22:51:13 GMT, Alex Menkov wrote: > This is subtask which covers test in hotspot/jtreg except test/hotspot/jtreg/vmTestbase/nsk/jvmti (there is a separate > issue for it: JDK-8253371) > In most tests just "@requires vm.jvmti" is added, > in several test '@requires vm.flavor != "minimal"' is removed (when this requirement is only to ensure test VM has > JVMTI included) Alex, It looks good. Did you test it in minimal config? ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/314 From github.com+471021+marschall at openjdk.java.net Wed Sep 23 04:03:05 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Wed, 23 Sep 2020 04:03:05 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v4] In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate ------------- Changes: https://git.openjdk.java.net/jdk/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=03 Stats: 753 lines in 65 files changed: 153 ins; 149 del; 451 mod Patch: https://git.openjdk.java.net/jdk/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk/pull/45 From dholmes at openjdk.java.net Wed Sep 23 04:13:05 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 23 Sep 2020 04:13:05 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: <4l2vRUllquBWTsz1t0brYAsPoBzNIKo1A7M9GBAcKNw=.da0e1992-ebff-4c31-bdc9-e6c293189276@github.com> References: <4l2vRUllquBWTsz1t0brYAsPoBzNIKo1A7M9GBAcKNw=.da0e1992-ebff-4c31-bdc9-e6c293189276@github.com> Message-ID: On Mon, 21 Sep 2020 11:07:14 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/handshake.hpp line 44: >> >>> 42: // by the target JavaThread itself or, depending on whether the operation is >>> 43: // a single target/direct handshake or not, by the JavaThread that requested the >>> 44: // handshake or the VMThread respectively. >> >> This comment now indicates that all single target handshakes are executed as direct-handshakes and never by the >> VMThread - is that correct? > > The concept of direct handshake do not exist in that way. (but can easily be implemented using the filter) > You have operation that you need to be executed on a JavaThread, you add that to that JavaThread. > Any thread ("driver") that succeed to claim that JavaThreads handshake state (lock and that JavaThread is safe) procced > to execute from that handshake queue until empty (empty according to applied filter on queue). I think the entire comment block above can now be simplified: // A handshake closure is a callback that is executed for a JavaThread // while it is in a safepoint/handshake-safe state. Depending on the // nature of the closure, the callback may be executed by the initiating // thread, the target thread, or the VMThread. If the callback is not executed // by the target thread it will remain in a blocked state until the callback completes. >> src/hotspot/share/runtime/handshake.cpp line 230: >> >>> 228: log_trace(handshake)("Threads signaled, begin processing blocked threads by VMThread"); >>> 229: HandshakeSpinYield hsy(start_time_ns); >>> 230: int executed_by_driver = 0; >> >> driver?? Isn't this still the VMThread? > > The driver is VM thread or a JavaThread. But this is VM_HandshakeAllThreads (a VM_Operation), it can't be executed by anything other than the VMThread! ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From dholmes at openjdk.java.net Wed Sep 23 04:13:04 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 23 Sep 2020 04:13:04 GMT Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 07:54:57 GMT, Robbin Ehn wrote: >> This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes >> are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) >> Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an >> arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a >> singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first >> pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first >> pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake >> operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything >> except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed >> filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake >> operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there >> is now only one method to call when handshaking one thread. Some comments about the changes: >> - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake >> all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much >> worse then this. >> >> - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that >> thread. >> >> - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a >> handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. >> >> - Added WB testing method. >> >> - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. >> >> - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. >> >> - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a >> safepoint and half of them after, in many handshake all operations. >> >> - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. >> >> - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the >> moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. >> >> - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. >> >> - Added filtered queue and gtest for it. >> >> Passes multiple t1-8 runs. >> Been through some pre-reviwing. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Update after Coleen No significant comments. All my concerns relate to naming and terminology, where I think there is scope for quite a bit of tidying up. Thanks. src/hotspot/share/runtime/handshake.hpp line 45: > 43: // a single target/direct handshake or not, by the JavaThread that requested the > 44: // handshake or the VMThread respectively. > 45: class HandshakeClosure : public ThreadClosure, public CHeapObj { Is use of multiple inheritance allowed within hotspot code? src/hotspot/share/runtime/handshake.hpp line 51: > 49: virtual ~HandshakeClosure() {} > 50: const char* name() const { return _name; } > 51: virtual bool is_asynch() { return false; }; I thought "asynch" has already been renamed to drop the 'h' everywhere? src/hotspot/share/runtime/handshake.hpp line 78: > 76: FilterQueue _queue; > 77: Mutex _lock; > 78: Thread* _active_handshaker; To be clear, the _handshakee is the always the target JavaThread, while the _active_handshaker, is the thread that is actually executing the handshake operation (ie do_thread). If so can you add comments on these declarations to clarify that. Thanks. src/hotspot/share/runtime/handshake.hpp line 90: > 88: void add_operation(HandshakeOperation* op); > 89: HandshakeOperation* pop_for_self(); > 90: HandshakeOperation* pop_for_processor(); What is "processor" in this context - the active handshaker? Can we not introduce yet another piece of terminology here. We should have consistency of naming when it comes to "self" and others. ie. we have pop_for_self() but has_operation() rather than has_operation_for_self() If we made the "self" case explicit then we could leave the not-self case implicit e.g. pop_for_self(); // Called by handshakee only pop(); // Called by handshaker or VMThread has_operation_for_self(); // Is there an operation that can be executed by the handshakee itself has_operation(); // Is there an operation that can be executed by the handshaker or VMThread We can then stop using "processor" in other places as well. src/hotspot/share/runtime/handshake.hpp line 96: > 94: return !_queue.is_empty(); > 95: } > 96: bool block_for_operation() { should_block_for_operation() ? Though looking at the loop that uses this the name doesn't seem right as we are not blocking but processing the operation. ?? src/hotspot/share/runtime/handshake.hpp line 97: > 95: } > 96: bool block_for_operation() { > 97: return !_queue.is_empty() || _lock.is_locked(); I really don't understand the is_locked() check in this condition. ?? And the check for !empty is racy, so how do we avoid missing an in-progress addition? src/hotspot/share/runtime/handshake.cpp line 44: > 42: protected: > 43: HandshakeClosure* _handshake_cl; > 44: int32_t _pending_threads; Not new but the meaning of _pending_threads is unclear - please add a descriptive comment. src/hotspot/share/runtime/handshake.cpp line 63: > 61: }; > 62: > 63: class AsyncHandshakeOperation : public HandshakeOperation { This doesn't quite make sense. If you have an AsyncHandshakeOperation as a distinct subclass then it should not be possible for is_async() on a HandshakeOperation to return true - but it can because it can be passed an AsyncHandshakeClosure when constructed. If you want async and non-async operations to be distinct types then you will need to restrict how the base class is constructed, and provide a protected constructor that just takes an AsyncHandShakeClosure. src/hotspot/share/runtime/handshake.cpp line 195: > 193: } > 194: > 195: static void log_handshake_info(jlong start_time_ns, const char* name, int targets, int requester_executed, const > char* extra = NULL) { It is not clear what "requester_executed" actually means here - why is this an int? what does it represent? Again we have new terminology "requester" - is that the handshakee or ??? src/hotspot/share/runtime/handshake.cpp line 244: > 242: // A new thread on the ThreadsList will not have an operation, > 243: // hence it is skipped in handshake_try_process. > 244: HandshakeState::ProcessResult pr = thr->handshake_state()->try_process(_op); To be clear on what can be happening here ... as the VMThread has to loop through all threads first to initiate the handshake, by the time it starts trying to process the op, the target threads may have already done it themselves. Additionally while looping through all threads, a thread that has not yet been handshaked could try to handshake with a thread the VMThread has already processed, and so it could also execute the operation before the VMThread gets to it. src/hotspot/share/runtime/handshake.cpp line 356: > 354: } > 355: > 356: HandshakeState::HandshakeState(JavaThread* thread) : s/thread/target/ for clarity src/hotspot/share/runtime/handshake.cpp line 412: > 410: if (op != NULL) { > 411: assert(op->_target == NULL || op->_target == Thread::current(), "Wrong thread"); > 412: assert(_handshakee == Thread::current(), "Wrong thread"); You already asserted this at line 400. src/hotspot/share/runtime/thread.hpp line 1358: > 1356: HandshakeState* handshake_state() { return &_handshake; } > 1357: > 1358: // A JavaThread can always safely operate on it self and other threads s/it self/itself/ src/hotspot/share/runtime/thread.hpp line 1359: > 1357: > 1358: // A JavaThread can always safely operate on it self and other threads > 1359: // can do it safely it if they are the active handshaker. s/it if/if/ src/hotspot/share/utilities/filterQueue.hpp line 32: > 30: > 31: template > 32: class FilterQueue { A brief description of the class would be good. It is basically a FIFO queue but with the ability to skip nodes that match a given "filter" criteria. src/hotspot/share/utilities/filterQueue.hpp line 34: > 32: class FilterQueue { > 33: private: > 34: class FilterQueueNode : public CHeapObj { The Filter in FilterQueueNode is redundant given this is a nested type. Node would suffice. src/hotspot/share/utilities/filterQueue.hpp line 56: > 54: } > 55: > 56: // MT-safe Not sure where our previous discussion is on this but these posix-style MT-safe labels don't really halp for this kind of abstract data type API. Please briefly explain the thread-safety properties of add and pop. src/hotspot/share/utilities/filterQueue.hpp line 57: > 55: > 56: // MT-safe > 57: void add(E data); It would be more regular naming to use add/remove or push/pop rather than add/pop. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/151 From dholmes at openjdk.java.net Wed Sep 23 04:13:05 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 23 Sep 2020 04:13:05 GMT Subject: RFR: 8238761: Asynchronous handshakes [v3] In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 21:59:40 GMT, Coleen Phillimore wrote: >> The thread executing this handshake operation, what the current thread is doesn't matter. >> You can't use current threads resources or be dependent otherwise on it. >> >> Exception being locking issues in JVM TI, where we are dependent that requester have locked JVM TI state lock for us, >> but we are not dependent that the current thread is the owner. So checking that the lock is held by requester doesn't >> matter for how is the 'driver'. > > The "driver" concept is odd. Should it really be caller? Like the thread that called VMHandshake? In this context "driver" is just the current thread, that called execute. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From dholmes at openjdk.java.net Wed Sep 23 05:13:17 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 23 Sep 2020 05:13:17 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Tue, 22 Sep 2020 08:43:04 GMT, Erik Gahlin wrote: >> Marked as reviewed by kvn (Reviewer). > > Have you run the JFR tests in test/jdk/jdk/jfr? @marschall Please do not force-push anything as it breaks the commit history in the PR and renders previous reviews/comments obsolete. There is no way for the reviewers to see what changed between the commit they reviewed and the commit now in the PR. To update to latest changes you should have just merged your branch with your (up-to-date) local master, committed that merge in your local branch and then pushed that commit to your Personal Fork. The skara tooling will flatten the series of commits in a PR into one single well-formed commit that is pushed to the master branch of the repo. ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From shade at openjdk.java.net Wed Sep 23 05:38:48 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 23 Sep 2020 05:38:48 GMT Subject: RFR: 8253349: Remove unimplemented SharedRuntime::native_method_throw_unsupported_operation_exception_entry In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 22:30:15 GMT, Aditya Mandaleeka wrote: >> The definition was removed in JDK-7196277 (confidential): >> https://github.com/openjdk/jdk/commit/149097fbb751155cba49de38f8da5b39635198af >> Declaration was left behind. >> >> Testing: >> - [x] Linux x86_64 fastdebug build >> - [x] Text search for `native_method_throw_unsupported_operation_exception_entry` in `src/hotspot` > > Marked as reviewed by adityam (Author). Friendly reminder (of this trivial issue). Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/244 From dholmes at openjdk.java.net Wed Sep 23 05:59:05 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 23 Sep 2020 05:59:05 GMT Subject: RFR: 8253349: Remove unimplemented SharedRuntime::native_method_throw_unsupported_operation_exception_entry In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 10:53:48 GMT, Aleksey Shipilev wrote: > The definition was removed in JDK-7196277 (confidential): > https://github.com/openjdk/jdk/commit/149097fbb751155cba49de38f8da5b39635198af > Declaration was left behind. > > Testing: > - [x] Linux x86_64 fastdebug build > - [x] Text search for `native_method_throw_unsupported_operation_exception_entry` in `src/hotspot` Good and trivial. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/244 From eric.c.liu at arm.com Wed Sep 23 06:10:07 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Wed, 23 Sep 2020 06:10:07 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> , <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com>, Message-ID: Hi Kim,? Sorry for the delay. This patch removes a redundant string copy in NetworkInterface.c to avoid string-truncation warning. Other warnings we talked before, which are unable to completely fix in different version of gcc, I have to use pragma to suppress them as a workaround. This patch now could compile with gcc-7, gcc-8, gcc-9, gcc-10 both with or without asan. [TESTS] Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. No new failure found. http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8252407 Thanks, Eric From thomas.stuefe at gmail.com Wed Sep 23 06:14:23 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 23 Sep 2020 08:14:23 +0200 Subject: RFR: 8247910: Improve alignment and power-of-2 utilities using C++14 In-Reply-To: References: Message-ID: Hi, unfortunately this breaks my builds on Ubuntu 16.4. I am using gcc 5.4.0 which according to https://openjdk.java.net/groups/build/doc/building.html should still be an accepted compiler? Creating hotspot/variant-server/libjvm/gtest/gtestLauncher from 1 file(s) In file included from /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/services/memTracker.hpp:85:0, from /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/precompiled/precompiled.hpp:60: /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/services/mallocTracker.hpp:190:78: error: size of array '_snapshot' is not an integral constant-expression static size_t _snapshot[CALC_OBJ_SIZE_IN_TYPE(MallocMemorySnapshot, size_t)]; ^ In file included from /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/services/memTracker.hpp:87:0, from /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/precompiled/precompiled.hpp:60: /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/services/virtualMemoryTracker.hpp:170:79: error: size of array '_snapshot' is not an integral constant-expression static size_t _snapshot[CALC_OBJ_SIZE_IN_TYPE(VirtualMemorySnapshot, size_t)]; ^ In file included from /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/services/memTracker.hpp:85:0, from /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/precompiled/precompiled.hpp:60: /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/services/mallocTracker.hpp:190:78: error: size of array '_snapshot' is not an integral constant-expression static size_t _snapshot[CALC_OBJ_SIZE_IN_TYPE(MallocMemorySnapshot, size_t)]; ^ In file included from /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/services/memTracker.hpp:87:0, from /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/precompiled/precompiled.hpp:60: /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/services/virtualMemoryTracker.hpp:170:79: error: size of array '_snapshot' is not an integral constant-expression static size_t _snapshot[CALC_OBJ_SIZE_IN_TYPE(VirtualMemorySnapshot, size_t)]; ^ cc1plus: error: unrecognized command line option '-Wno-shift-negative-value' [-Werror] cc1plus: error: unrecognized command line option '-Wno-cast-function-type' [-Werror] Cheers, Thomas On Tue, Sep 15, 2020 at 12:09 AM Kim Barrett wrote: > > On Sep 14, 2020, at 3:43 AM, Stefan Karlsson > wrote: > > > > On Fri, 11 Sep 2020 08:44:49 GMT, Kim Barrett > wrote: > > > >> Please review this change which updates the alignment and power-of-2 > >> utilities (utilities/align.hpp and utilities/powerOfTwo.hpp) to use > >> C++14 features. > >> > >> Where possible, the alignment functions are now constexpr. This > >> eliminates the need for alternate macros that needed to be used in > >> constexpr contexts. > >> > >> Use and rather than HotSpot workalikes. > >> We no longer need max_value(), as the problematic platform for > >> std::numeric_limits::max() was Solaris. > >> > >> Testing: tier1 > > > > Looks good! > > > > ------------- > > > > Marked as reviewed by stefank (Reviewer). > > > > PR: https://git.openjdk.java.net/jdk/pull/126 > > Thanks. > > From github.com+4676506+javeleon at openjdk.java.net Wed Sep 23 06:35:12 2020 From: github.com+4676506+javeleon at openjdk.java.net (Allan Gregersen) Date: Wed, 23 Sep 2020 06:35:12 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> Message-ID: On Tue, 22 Sep 2020 10:51:16 GMT, Erik ?sterlund wrote: > > > I would like to hear answer to @dholmes-ora question in JBS: > > > "Do we really need yet another stack dumping interface in the VM? Why isn't a debugger using JVM TI?" > > > > > > One reason for having both the new getStackFrames API (set of threads) as well as the existing iterateFrames (current > > thread only) API in JVMCI is that Truffle would want a deopt-free read-only view of the values in a frame, which to the > > best of our knowledge is not possible through JVMTI. Only in rare cases, materialization of frames is required, so it > > boils down to the performance hit caused by deopting frames, which is even more of a concern with a set of threads than > > for the single current thread case. Another potential issue with a JVMTI-based approach is that there might be other > > drawbacks to having an always-on (or even late attached) JVMTI agent in a GraalVM? > > 1. You are describing that the main reason is performance. But you also say this is to be used by a debugger? So, not > sure performance as a primary motive really makes sense then. Not sure why performance of debugging Truffle must be so > much faster than debugging Java code (which I have not heard anyone complain about). And if this really was an actual > performance problem, it seems like we would want a generic fix then, not a special Truffle stack walker for debugging > Truffle code alone, to be maintained separately. 2. We are talking about JVMTI, not JVMCI. iterateFrames is defined in > JVMCI, and that is something completely different, which I don't think any of us had in mind. It seems indeed to be > limited to the current frame. I'm talking about e.g. JVMTI GetStackTrace and the JVMTI GetLocal* functions. It gives > you a stack trace for any thread (not just the current one), and allows you to retrieve locals. 3. When you just read > locals, (as you describe is your use case), there is no need to deoptimize anything. So yeah, that's just not something > we do, unless you change the locals, which you said you are not. Please let me know if there is anything I missed. But > so far it seems to me that the mentioned JVMTI functionality is all you really need for a debugger. What did I miss? I > would like to better understand the problem domain before taking this further. Thanks for your quick follow-up. 1. It's not entirely made for the debugger use-case. For example in some guest languages we need this for implementing Thread#getStackTrace or similar. In Espresso (Java as a Truffle guest language) we would need this also for implementing part of the management API. 2. I know that you suggested JVMTI and no JVMCI. Since I wasn't around when the decision to implement and include iterateFrames into JVMCI was made, I'm unaware of the exact reasoning behind that decision. I was assuming that whatever reason not to go with JVMTI back then would still hold true today. So say we wanted to adopt the JVMTI approach now. Would the design be an in-process always on and in-process JVMTI agent? Would there be security implications from such an approach leaving any VM running anything Truffle more vulnerable? 3. No need for deoptimize anything when reading locals through JVMTI is good. Thanks for clarifying that. ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From shade at openjdk.java.net Wed Sep 23 06:39:37 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 23 Sep 2020 06:39:37 GMT Subject: Integrated: 8253349: Remove unimplemented SharedRuntime::native_method_throw_unsupported_operation_exception_entry In-Reply-To: References: Message-ID: On Fri, 18 Sep 2020 10:53:48 GMT, Aleksey Shipilev wrote: > The definition was removed in JDK-7196277 (confidential): > https://github.com/openjdk/jdk/commit/149097fbb751155cba49de38f8da5b39635198af > Declaration was left behind. > > Testing: > - [x] Linux x86_64 fastdebug build > - [x] Text search for `native_method_throw_unsupported_operation_exception_entry` in `src/hotspot` This pull request has now been integrated. Changeset: bd679754 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/bd679754 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8253349: Remove unimplemented SharedRuntime::native_method_throw_unsupported_operation_exception_entry Reviewed-by: adityam, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/244 From thomas.stuefe at gmail.com Wed Sep 23 07:00:49 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 23 Sep 2020 09:00:49 +0200 Subject: RFR: 8247910: Improve alignment and power-of-2 utilities using C++14 In-Reply-To: References: Message-ID: ... Okay I worked around the problem by upgrading to gcc 7. However, should we not make sure that we are buildable on the lowest required compiler level? Thanks, Thomas On Wed, Sep 23, 2020 at 8:14 AM Thomas St?fe wrote: > Hi, > > unfortunately this breaks my builds on Ubuntu 16.4. I am using gcc 5.4.0 > which according to https://openjdk.java.net/groups/build/doc/building.html > should still be an accepted compiler? > > Creating hotspot/variant-server/libjvm/gtest/gtestLauncher from 1 file(s) > In file included from > /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/services/memTracker.hpp:85:0, > from > /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/precompiled/precompiled.hpp:60: > /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/services/mallocTracker.hpp:190:78: > error: size of array '_snapshot' is not an integral constant-expression > static size_t _snapshot[CALC_OBJ_SIZE_IN_TYPE(MallocMemorySnapshot, > size_t)]; > > ^ > In file included from > /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/services/memTracker.hpp:87:0, > from > /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/precompiled/precompiled.hpp:60: > /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/services/virtualMemoryTracker.hpp:170:79: > error: size of array '_snapshot' is not an integral constant-expression > static size_t _snapshot[CALC_OBJ_SIZE_IN_TYPE(VirtualMemorySnapshot, > size_t)]; > > ^ > In file included from > /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/services/memTracker.hpp:85:0, > from > /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/precompiled/precompiled.hpp:60: > /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/services/mallocTracker.hpp:190:78: > error: size of array '_snapshot' is not an integral constant-expression > static size_t _snapshot[CALC_OBJ_SIZE_IN_TYPE(MallocMemorySnapshot, > size_t)]; > > ^ > In file included from > /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/services/memTracker.hpp:87:0, > from > /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/precompiled/precompiled.hpp:60: > /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/services/virtualMemoryTracker.hpp:170:79: > error: size of array '_snapshot' is not an integral constant-expression > static size_t _snapshot[CALC_OBJ_SIZE_IN_TYPE(VirtualMemorySnapshot, > size_t)]; > > ^ > cc1plus: error: unrecognized command line option > '-Wno-shift-negative-value' [-Werror] > cc1plus: error: unrecognized command line option '-Wno-cast-function-type' > [-Werror] > > Cheers, Thomas > > > On Tue, Sep 15, 2020 at 12:09 AM Kim Barrett > wrote: > >> > On Sep 14, 2020, at 3:43 AM, Stefan Karlsson >> wrote: >> > >> > On Fri, 11 Sep 2020 08:44:49 GMT, Kim Barrett >> wrote: >> > >> >> Please review this change which updates the alignment and power-of-2 >> >> utilities (utilities/align.hpp and utilities/powerOfTwo.hpp) to use >> >> C++14 features. >> >> >> >> Where possible, the alignment functions are now constexpr. This >> >> eliminates the need for alternate macros that needed to be used in >> >> constexpr contexts. >> >> >> >> Use and rather than HotSpot workalikes. >> >> We no longer need max_value(), as the problematic platform for >> >> std::numeric_limits::max() was Solaris. >> >> >> >> Testing: tier1 >> > >> > Looks good! >> > >> > ------------- >> > >> > Marked as reviewed by stefank (Reviewer). >> > >> > PR: https://git.openjdk.java.net/jdk/pull/126 >> >> Thanks. >> >> From dholmes at openjdk.java.net Wed Sep 23 07:35:40 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 23 Sep 2020 07:35:40 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v2] In-Reply-To: <8KYOSvjbrmDhnP3_WLOu0dO0saiWTHp1SBgE3ikOJkE=.dd9b9e50-2bb5-47cb-a67f-e7c5293ef1d2@github.com> References: <8KYOSvjbrmDhnP3_WLOu0dO0saiWTHp1SBgE3ikOJkE=.dd9b9e50-2bb5-47cb-a67f-e7c5293ef1d2@github.com> Message-ID: <0zyH4bq9n93UH7O4QuK4WtqIs7Zig2ADAfsCaNyWWfU=.9d8a09e8-5aa1-4c65-93a8-cf84eed75820@github.com> On Mon, 21 Sep 2020 07:33:27 GMT, Robbin Ehn wrote: >> We simplify the vmThread by removing the queue and refactor the the main loop. >> This solves the issues listed: >> - It can create an extra safepoint directly after a safepoint. >> - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. >> - The exposure of the vm operation is dangerous if it's a handshake. >> - The code is a hornets nest with the repetition of checks and branches >> >> Passes t1-8, and a benchmark run. >> >> If you want a smaller diff the commits contains the incremental progress and each commit passed t1. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since > the last revision: > - Merge branch 'master' into 8212107-vmthread > - Fixed nits > - Merge branch 'master' into 8212107-vmthread > - Fixes after review from shipilev. > - Fixed some indent misses > - Fixed ws > - Added assert > - Restructured and simplified > - Removed used linking in VM_Operation > - Removed ticket and use only one Monitor > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/7c142951...e49178a4 This generally looks good. Mapping between the old way and the new way is a little tricky but I think I made all the connections. One thing I did notice is that it seems that nested VM operations are now restricted to a nesting depth of one - is that correct? (And the code could be a lot simpler if nesting was not needed. :) ). A couple of minor comments/suggestions below. Thanks. David src/hotspot/share/runtime/vmThread.cpp line 392: > 390: EventMark em("Executing %s VM operation: %s", prev_vm_operation != NULL ? "nested" : "", op->name()); > 391: > 392: // If we are at a safepoint we will evaluate all the operations that "all"? There can only be one surely? src/hotspot/share/runtime/vmThread.hpp line 74: > 72: > 73: void evaluate_operation(VM_Operation* op); > 74: void inner_execute(VM_Operation* op); Perhaps nested_execute as it seems this is only for handling the case of a nested vm op? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/228 From rehn at openjdk.java.net Wed Sep 23 07:35:44 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 07:35:44 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v2] In-Reply-To: References: <8KYOSvjbrmDhnP3_WLOu0dO0saiWTHp1SBgE3ikOJkE=.dd9b9e50-2bb5-47cb-a67f-e7c5293ef1d2@github.com> Message-ID: On Tue, 22 Sep 2020 20:46:33 GMT, Coleen Phillimore wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev >> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since >> the last revision: >> - Merge branch 'master' into 8212107-vmthread >> - Fixed nits >> - Merge branch 'master' into 8212107-vmthread >> - Fixes after review from shipilev. >> - Fixed some indent misses >> - Fixed ws >> - Added assert >> - Restructured and simplified >> - Removed used linking in VM_Operation >> - Removed ticket and use only one Monitor >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/359def09...e49178a4 > > src/hotspot/share/runtime/vmThread.cpp line 52: > >> 50: #include "utilities/events.hpp" >> 51: #include "utilities/vmError.hpp" >> 52: #include "utilities/xmlstream.hpp" > > Since you've changed a lot of the body of this, can you make sure that all these header files are needed? method.hpp, > runtimeService.hpp and dtrace.hpp may no longer be needed. Check with precompiled headers off though. Fixed > src/hotspot/share/runtime/vmThread.cpp line 351: > >> 349: if (VMThread::vm_thread()->set_next_operation(op)) { >> 350: ml.notify_all(); >> 351: break; > > I was wondering if you should put some counter while the thread is waiting to install its operation for logging and > debugging purposes? Since the supposition is that there are few operations that cause safepoints so there's never a > long wait. Sounds like a good idea, fixing. ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From rehn at openjdk.java.net Wed Sep 23 07:51:51 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 07:51:51 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v2] In-Reply-To: References: <8KYOSvjbrmDhnP3_WLOu0dO0saiWTHp1SBgE3ikOJkE=.dd9b9e50-2bb5-47cb-a67f-e7c5293ef1d2@github.com> Message-ID: On Tue, 22 Sep 2020 21:00:09 GMT, Coleen Phillimore wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev >> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since >> the last revision: >> - Merge branch 'master' into 8212107-vmthread >> - Fixed nits >> - Merge branch 'master' into 8212107-vmthread >> - Fixes after review from shipilev. >> - Fixed some indent misses >> - Fixed ws >> - Added assert >> - Restructured and simplified >> - Removed used linking in VM_Operation >> - Removed ticket and use only one Monitor >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/9c929843...e49178a4 > > src/hotspot/share/runtime/vmThread.cpp line 352: > >> 350: ml.notify_all(); >> 351: break; >> 352: } > > // Wait to install this operation as the next operation in the VM Thread Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From rehn at openjdk.java.net Wed Sep 23 07:58:08 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 07:58:08 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v2] In-Reply-To: References: <8KYOSvjbrmDhnP3_WLOu0dO0saiWTHp1SBgE3ikOJkE=.dd9b9e50-2bb5-47cb-a67f-e7c5293ef1d2@github.com> Message-ID: On Tue, 22 Sep 2020 21:02:10 GMT, Coleen Phillimore wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev >> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since >> the last revision: >> - Merge branch 'master' into 8212107-vmthread >> - Fixed nits >> - Merge branch 'master' into 8212107-vmthread >> - Fixes after review from shipilev. >> - Fixed some indent misses >> - Fixed ws >> - Added assert >> - Restructured and simplified >> - Removed used linking in VM_Operation >> - Removed ticket and use only one Monitor >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/f6984edd...e49178a4 > > src/hotspot/share/runtime/vmThread.cpp line 357: > >> 355: // _next_vm_operation is cleared holding VMOperation_lock >> 356: // after it have been executed. >> 357: while (_next_vm_operation == op) { > > // Wait until the operation has been processed > > But can this operation still be being processed as the current process? > > Anyway can you add a couple of comments to help the reader. Not while you have the VMOperation_lock. It can only get processed once you release it with wait(). ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From stefank at openjdk.java.net Wed Sep 23 08:14:10 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 23 Sep 2020 08:14:10 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 11:43:41 GMT, Erik ?sterlund wrote: > This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. > https://openjdk.java.net/jeps/376). > Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, > and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into > more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to > expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in > the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized > automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization > processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is > actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception > handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC > threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming > of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the > watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll > word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it > brought (and is only possible on TSO machines). So left that one out. Next set of comments. src/hotspot/share/gc/z/zStackWatermark.cpp line 78: > 76: ZThreadLocalData::do_invisible_root(_jt, ZBarrier::load_barrier_on_invisible_root_oop_field); > 77: > 78: ZVerify::verify_thread_frames_bad(_jt); Every time I read the name verify_thread_no_frames_bad I read it as "verify that no frames are bad", but that's not at all what that function does. Is there still a reason why verify_thread_no_frames_bad and verify_thread_frames_bad are split up into two functions? Or could we fuse them into a ZVerify::verify_thread_bad? src/hotspot/share/gc/z/zBarrier.cpp line 130: > 128: uintptr_t ZBarrier::load_barrier_on_invisible_root_oop_slow_path(uintptr_t addr) { > 129: return during_relocate() ? relocate(addr) : mark(addr); > 130: } There's a style skew between load_barrier_on_oop_slow_path and load_barrier_on_invisible_root_oop_slow_path. The former calls wrapper function relocate_or_mark, which does the during_relocate() ... check. Maybe do the same for load_barrier_on_invisible_root_oop_slow_path, and introduce a relocate_or_mark_no_follow? src/hotspot/share/gc/z/zBarrierSet.cpp line 85: > 83: ZThreadLocalData::set_address_bad_mask(thread, ZAddressBadMask); > 84: if (thread->is_Java_thread()) { > 85: JavaThread* const jt = static_cast(thread); Use as_Java_thread() here? src/hotspot/share/gc/z/zCollectedHeap.cpp line 235: > 233: return true; > 234: } > 235: Weird placement between store barrier functions. But even weirder that we still have those functions. I'll remove them with JDK-8253516. src/hotspot/share/gc/z/zDriver.cpp line 108: > 106: return false; > 107: } > 108: Group needs_inactive_gc_locker, skip_thread_oop_barriers, and allow_coalesced_vm_operations together? Add a comment about why we chose to skip coalescing here. src/hotspot/share/gc/z/zHeapIterator.cpp line 90: > 88: virtual void do_thread(Thread* thread) { > 89: if (thread->is_Java_thread()) { > 90: StackWatermarkSet::finish_processing(static_cast(thread), NULL /* context */, > StackWatermarkKind::gc); as_Java_thread() ? src/hotspot/share/gc/z/zNMethod.cpp line 244: > 242: ZNMethodToOopsDoClosure(OopClosure* cl, bool should_disarm_nmethods) : > 243: _cl(cl), > 244: _should_disarm_nmethods(should_disarm_nmethods) {} Indentation is off. src/hotspot/share/gc/z/zObjectAllocator.cpp line 2: > 1: /* > 2: * Copyright (c) 2015, 2020, Oracle and/or its affiliates. All rights reserved. Revert. src/hotspot/share/gc/z/zRootsIterator.cpp line 200: > 198: ZRootsIteratorClosure* const _cl; > 199: // The resource mark is needed because interpreter oop maps are not reused in concurrent mode. > 200: // Instead, they are temporary, and resource allocated. temporary, and => temporary and ? src/hotspot/share/gc/z/zStackWatermark.cpp line 96: > 94: void ZStackWatermark::process(const frame& fr, RegisterMap& register_map, void* context) { > 95: ZVerify::verify_frame_bad(fr, register_map); > 96: frame(fr).oops_do(closure_from_context(context), &_cb_cl, ®ister_map); With recent frame::oops_do cleanups, frame(fr) can be changed to simply fr. src/hotspot/share/gc/z/zVerify.cpp line 377: > 375: void ZVerify::verify_frame_bad(const frame& fr, RegisterMap& register_map) { > 376: ZVerifyBadOopClosure verify_cl; > 377: frame(fr).oops_do(&verify_cl, NULL, ®ister_map); With recent frame::oops_do cleanups, frame(fr) can be changed to simply fr. src/hotspot/share/gc/z/zStackWatermark.hpp line 46: > 44: ZOnStackCodeBlobClosure(); > 45: > 46: virtual void do_code_blob(CodeBlob* cb); Could be private. src/hotspot/share/gc/z/zStackWatermark.hpp line 57: > 55: OopClosure* closure_from_context(void* context); > 56: > 57: protected: No need to be protected, so can be private. We don't have sub-classes that overrides ZStackWatermark. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From kim.barrett at oracle.com Wed Sep 23 08:24:41 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 23 Sep 2020 04:24:41 -0400 Subject: RFR: 8247910: Improve alignment and power-of-2 utilities using C++14 In-Reply-To: References: Message-ID: > On Sep 23, 2020, at 3:00 AM, Thomas St?fe wrote: > > ... Okay I worked around the problem by upgrading to gcc 7. > > However, should we not make sure that we are buildable on the lowest required compiler level? gcc5 is the first version of gcc that *claims* to completely support C++14. That?s the only reason for setting it as the lower limit; it wasn?t based on data. Rather than potentially contort code to support what is now a pretty old version, I?d prefer we moved forward the minimum required version. From eosterlund at openjdk.java.net Wed Sep 23 08:31:28 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 23 Sep 2020 08:31:28 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing In-Reply-To: <1iLCRf17v1nwE70nQk7qq0bcad8gop9q5dYt-sr9fG8=.81025951-bc22-45d0-84ff-9557b67262e3@github.com> References: <1iLCRf17v1nwE70nQk7qq0bcad8gop9q5dYt-sr9fG8=.81025951-bc22-45d0-84ff-9557b67262e3@github.com> Message-ID: On Tue, 22 Sep 2020 13:17:05 GMT, Stefan Karlsson wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, >> and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into >> more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to >> expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in >> the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized >> automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization >> processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is >> actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception >> handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC >> threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming >> of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the >> watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll >> word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it >> brought (and is only possible on TSO machines). So left that one out. > > src/hotspot/cpu/x86/templateInterpreterGenerator_x86_64.cpp line 194: > >> 192: >> 193: Label slow_path; >> 194: __ safepoint_poll(slow_path, r15_thread, true /* at_return */, false /* in_nmethod */); > > Why is this tagged with 'true /* at_return */? Same for line 240. The _x86_32 version uses false. Good point. > src/hotspot/share/c1/c1_Runtime1.cpp line 515: > >> 513: if (thread->last_frame().is_runtime_frame()) { >> 514: // The Runtime1::handle_exception_from_callee_id handler is invoked after the >> 515: // frame has been unwinded. It instead builds its own stub frame, to call the > > Unwided -> unwound, maybe? Same below and probably other places as well. Good point. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From rehn at openjdk.java.net Wed Sep 23 08:36:29 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 08:36:29 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v2] In-Reply-To: <0zyH4bq9n93UH7O4QuK4WtqIs7Zig2ADAfsCaNyWWfU=.9d8a09e8-5aa1-4c65-93a8-cf84eed75820@github.com> References: <8KYOSvjbrmDhnP3_WLOu0dO0saiWTHp1SBgE3ikOJkE=.dd9b9e50-2bb5-47cb-a67f-e7c5293ef1d2@github.com> <0zyH4bq9n93UH7O4QuK4WtqIs7Zig2ADAfsCaNyWWfU=.9d8a09e8-5aa1-4c65-93a8-cf84eed75820@github.com> Message-ID: On Wed, 23 Sep 2020 07:14:59 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev >> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since >> the last revision: >> - Merge branch 'master' into 8212107-vmthread >> - Fixed nits >> - Merge branch 'master' into 8212107-vmthread >> - Fixes after review from shipilev. >> - Fixed some indent misses >> - Fixed ws >> - Added assert >> - Restructured and simplified >> - Removed used linking in VM_Operation >> - Removed ticket and use only one Monitor >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/92287620...e49178a4 > > src/hotspot/share/runtime/vmThread.cpp line 392: > >> 390: EventMark em("Executing %s VM operation: %s", prev_vm_operation != NULL ? "nested" : "", op->name()); >> 391: >> 392: // If we are at a safepoint we will evaluate all the operations that > > "all"? There can only be one surely? Yes, fixed > src/hotspot/share/runtime/vmThread.hpp line 74: > >> 72: >> 73: void evaluate_operation(VM_Operation* op); >> 74: void inner_execute(VM_Operation* op); > > Perhaps nested_execute as it seems this is only for handling the case of a nested vm op? inner_execute(..) is called in the non nested-case here: https://github.com/openjdk/jdk/blob/e49178a4445378fa0b5505ad6e9f1661636f88b8/src/hotspot/share/runtime/vmThread.cpp#L474 Nest case: https://github.com/openjdk/jdk/blob/e49178a4445378fa0b5505ad6e9f1661636f88b8/src/hotspot/share/runtime/vmThread.cpp#L511 ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From eosterlund at openjdk.java.net Wed Sep 23 08:36:25 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 23 Sep 2020 08:36:25 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing In-Reply-To: <1iLCRf17v1nwE70nQk7qq0bcad8gop9q5dYt-sr9fG8=.81025951-bc22-45d0-84ff-9557b67262e3@github.com> References: <1iLCRf17v1nwE70nQk7qq0bcad8gop9q5dYt-sr9fG8=.81025951-bc22-45d0-84ff-9557b67262e3@github.com> Message-ID: <2ytvTzDWlalJ67i7_piPhQJU3ApK-M82JAXVYjCIgFQ=.e3d10e0b-fbab-4e45-941f-d54a8a35f1eb@github.com> On Tue, 22 Sep 2020 13:45:16 GMT, Stefan Karlsson wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, >> and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into >> more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to >> expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in >> the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized >> automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization >> processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is >> actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception >> handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC >> threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming >> of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the >> watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll >> word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it >> brought (and is only possible on TSO machines). So left that one out. > > src/hotspot/share/compiler/oopMap.cpp line 243: > >> 241: } else { >> 242: all_do(fr, reg_map, f, process_derived_oop, &do_nothing_cl); >> 243: } > > I wonder if we shouldn't hide the StackWatermarkSet in the GC code, and not "activate" the DerivedPointerTable when a > SWS is used? Isn't it the case that already don't enable the table for ZGC? Couldn't this simply be: ` > if (DerivedPointerTable::is_active()) { > all_do(fr, reg_map, f, add_derived_oop, &do_nothing_cl); > } else { > all_do(fr, reg_map, f, process_derived_oop, &do_nothing_cl); > } > ` The problem isn't the GC code deciding to use or not use the derived pointer "table". It's the shared code uses of it that is the problem here. The table is explicitly activated by shared code, when for example using the JFR leak profiler, JVMTI heap walks, etc. This code makes the selection a GC choice when invoked by GC code, and a shared runtime choice when invoked by the shared runtime. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From rehn at openjdk.java.net Wed Sep 23 08:39:53 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 08:39:53 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v2] In-Reply-To: <0zyH4bq9n93UH7O4QuK4WtqIs7Zig2ADAfsCaNyWWfU=.9d8a09e8-5aa1-4c65-93a8-cf84eed75820@github.com> References: <8KYOSvjbrmDhnP3_WLOu0dO0saiWTHp1SBgE3ikOJkE=.dd9b9e50-2bb5-47cb-a67f-e7c5293ef1d2@github.com> <0zyH4bq9n93UH7O4QuK4WtqIs7Zig2ADAfsCaNyWWfU=.9d8a09e8-5aa1-4c65-93a8-cf84eed75820@github.com> Message-ID: On Wed, 23 Sep 2020 07:29:32 GMT, David Holmes wrote: > This generally looks good. Mapping between the old way and the new way is a little tricky but I think I made all the > connections. One thing I did notice is that it seems that nested VM operations are now restricted to a nesting depth of > one - is that correct? (And the code could be a lot simpler if nesting was not needed. :) ). A couple of minor > comments/suggestions below. Thanks. > David Hi, David. The support should be the same as before the previous operation is stored on stack while we change to the nested operation. I don't see what would be different from before? Thanks, Robbin ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From rehn at openjdk.java.net Wed Sep 23 08:45:00 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 08:45:00 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v3] In-Reply-To: References: Message-ID: > We simplify the vmThread by removing the queue and refactor the the main loop. > This solves the issues listed: > - It can create an extra safepoint directly after a safepoint. > - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. > - The exposure of the vm operation is dangerous if it's a handshake. > - The code is a hornets nest with the repetition of checks and branches > > Passes t1-8, and a benchmark run. > > If you want a smaller diff the commits contains the incremental progress and each commit passed t1. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Update after Coleen and David ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/228/files - new: https://git.openjdk.java.net/jdk/pull/228/files/e49178a4..f590c6cb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=228&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=228&range=01-02 Stats: 27 lines in 1 file changed: 12 ins; 7 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/228.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/228/head:pull/228 PR: https://git.openjdk.java.net/jdk/pull/228 From rehn at openjdk.java.net Wed Sep 23 08:54:05 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 08:54:05 GMT Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 02:40:31 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after Coleen > > src/hotspot/share/runtime/handshake.hpp line 45: > >> 43: // a single target/direct handshake or not, by the JavaThread that requested the >> 44: // handshake or the VMThread respectively. >> 45: class HandshakeClosure : public ThreadClosure, public CHeapObj { > > Is use of multiple inheritance allowed within hotspot code? There is other 'sane' way to 'implement an interface' and being heap allocated. We have a few like: class DefaultICProtectionBehaviour: public CompiledICProtectionBehaviour, public CHeapObj class AOTCompiledMethod : public CompiledMethod, public CHeapObj template class TaskQueueSetSuperImpl: public CHeapObj, public TaskQueueSetSuper So the 'rule' about multiple inheritance is in conflict with not using new/delete operator without using CHeapObj. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Wed Sep 23 08:57:13 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 08:57:13 GMT Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 02:41:37 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after Coleen > > src/hotspot/share/runtime/handshake.hpp line 51: > >> 49: virtual ~HandshakeClosure() {} >> 50: const char* name() const { return _name; } >> 51: virtual bool is_asynch() { return false; }; > > I thought "asynch" has already been renamed to drop the 'h' everywhere? Missed this one, fixing! ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Wed Sep 23 09:13:43 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 09:13:43 GMT Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 02:45:27 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after Coleen > > src/hotspot/share/runtime/handshake.hpp line 78: > >> 76: FilterQueue _queue; >> 77: Mutex _lock; >> 78: Thread* _active_handshaker; > > To be clear, the _handshakee is the always the target JavaThread, while the _active_handshaker, is the thread that is > actually executing the handshake operation (ie do_thread). If so can you add comments on these declarations to clarify > that. Thanks. Fixed > src/hotspot/share/runtime/handshake.hpp line 90: > >> 88: void add_operation(HandshakeOperation* op); >> 89: HandshakeOperation* pop_for_self(); >> 90: HandshakeOperation* pop_for_processor(); > > What is "processor" in this context - the active handshaker? Can we not introduce yet another piece of terminology > here. We should have consistency of naming when it comes to "self" and others. ie. we have > pop_for_self() > > but > > has_operation() > > rather than > > has_operation_for_self() > > If we made the "self" case explicit then we could leave the not-self case implicit e.g. > > pop_for_self(); // Called by handshakee only > pop(); // Called by handshaker or VMThread > has_operation_for_self(); // Is there an operation that can be executed by the handshakee itself > has_operation(); // Is there an operation that can be executed by the handshaker or VMThread > We can then stop using "processor" in other places as well. Fixing ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Wed Sep 23 09:20:31 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 09:20:31 GMT Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 02:54:09 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after Coleen > > src/hotspot/share/runtime/handshake.hpp line 96: > >> 94: return !_queue.is_empty(); >> 95: } >> 96: bool block_for_operation() { > > should_block_for_operation() ? Though looking at the loop that uses this the name doesn't seem right as we are not > blocking but processing the operation. ?? Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Wed Sep 23 09:37:56 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 09:37:56 GMT Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 02:56:00 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after Coleen > > src/hotspot/share/runtime/handshake.hpp line 97: > >> 95: } >> 96: bool block_for_operation() { >> 97: return !_queue.is_empty() || _lock.is_locked(); > > I really don't understand the is_locked() check in this condition. ?? > And the check for !empty is racy, so how do we avoid missing an in-progress addition? A JavaThread is blocked. A second thread have just executed a handshake operation for this JavaThread and are on line: https://github.com/openjdk/jdk/blob/cd784a751a3153939b9284898f370160124ca610/src/hotspot/share/runtime/handshake.cpp#L510 And the queue is empty. The JavaThread wakes up and changes state from blocked to blocked_trans. It now checks if it's allowed to complete the transition to e.g. vm. If a third thread adds to queue before the second thread leaves the loop it's operation can be executed. But the JavaThread could see the queue as empty. (racey as you say) The executor takes lock and then checks if the JavaThread is safe for processing. The JavaThread becomes unsafe and then check if lock is locked. If the lock is locked we must take slow path to avoid this. We should also take slow path if there is something on queue to processes. We are unsafe when we check queue and lock is not held, if we 'miss' that anything is on queue, it's fine. Since any other thread cannot have seen us as safe and seen the item on queue. (since lock is not held) Thus not allowed to process the operation. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From aph at redhat.com Wed Sep 23 09:39:27 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 23 Sep 2020 10:39:27 +0100 Subject: RFR: 8247910: Improve alignment and power-of-2 utilities using C++14 In-Reply-To: References: Message-ID: <43db77d4-9d37-fadd-bcdb-09275d01aed8@redhat.com> On 23/09/2020 09:24, Kim Barrett wrote: > gcc5 is the first version of gcc that *claims* to completely support > C++14. That?s the only reason for setting it as the lower limit; it > wasn?t based on data. > > Rather than potentially contort code to support what is now a pretty > old version, I?d prefer we moved forward the minimum required > version. I'd prefer that too, but it's not just about us developers: there are many distros building newer OpenJDK on older systems, and they may not have the freedom to change the system-wide C compiler. Given that we want to encourage people to use modern OpenJDK releases we should at least try to accommodate older compilers. I'd say that if we can use GCC 5 with minor changes we should do so, but not if it makes a mess of the code. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rehn at openjdk.java.net Wed Sep 23 10:11:40 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 10:11:40 GMT Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 03:04:39 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after Coleen > > src/hotspot/share/runtime/handshake.cpp line 63: > >> 61: }; >> 62: >> 63: class AsyncHandshakeOperation : public HandshakeOperation { > > This doesn't quite make sense. If you have an AsyncHandshakeOperation as a distinct subclass then it should not be > possible for is_async() on a HandshakeOperation to return true - but it can because it can be passed an > AsyncHandshakeClosure when constructed. If you want async and non-async operations to be distinct types then you will > need to restrict how the base class is constructed, and provide a protected constructor that just takes an > AsyncHandShakeClosure. This implementation code not part of the interface. By casting the AsyncHandShakeClosure to a HandshakeClosure before instantiating the HandshakeOperation you can still get is_async() to return true. And there are a loads of other user error which can be done like stack allocating AsyncHandshakeOperation. Protecting against all those kinds of errors requires a lot of more code. > src/hotspot/share/runtime/handshake.cpp line 44: > >> 42: protected: >> 43: HandshakeClosure* _handshake_cl; >> 44: int32_t _pending_threads; > > Not new but the meaning of _pending_threads is unclear - please add a descriptive comment. Fixed > src/hotspot/share/runtime/handshake.cpp line 195: > >> 193: } >> 194: >> 195: static void log_handshake_info(jlong start_time_ns, const char* name, int targets, int requester_executed, const >> char* extra = NULL) { > > It is not clear what "requester_executed" actually means here - why is this an int? what does it represent? > Again we have new terminology "requester" - is that the handshakee or ??? Fixed > src/hotspot/share/runtime/handshake.cpp line 356: > >> 354: } >> 355: >> 356: HandshakeState::HandshakeState(JavaThread* thread) : > > s/thread/target/ for clarity Fixed > src/hotspot/share/runtime/handshake.cpp line 412: > >> 410: if (op != NULL) { >> 411: assert(op->_target == NULL || op->_target == Thread::current(), "Wrong thread"); >> 412: assert(_handshakee == Thread::current(), "Wrong thread"); > > You already asserted this at line 400. Fixed > src/hotspot/share/runtime/thread.hpp line 1358: > >> 1356: HandshakeState* handshake_state() { return &_handshake; } >> 1357: >> 1358: // A JavaThread can always safely operate on it self and other threads > > s/it self/itself/ Fixed > src/hotspot/share/runtime/thread.hpp line 1359: > >> 1357: >> 1358: // A JavaThread can always safely operate on it self and other threads >> 1359: // can do it safely it if they are the active handshaker. > > s/it if/if/ Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Wed Sep 23 10:25:56 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 10:25:56 GMT Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 04:03:30 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after Coleen > > src/hotspot/share/utilities/filterQueue.hpp line 32: > >> 30: >> 31: template >> 32: class FilterQueue { > > A brief description of the class would be good. It is basically a FIFO queue but with the ability to skip nodes that > match a given "filter" criteria. Added > src/hotspot/share/utilities/filterQueue.hpp line 34: > >> 32: class FilterQueue { >> 33: private: >> 34: class FilterQueueNode : public CHeapObj { > > The Filter in FilterQueueNode is redundant given this is a nested type. Node would suffice. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From stefank at openjdk.java.net Wed Sep 23 10:30:46 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 23 Sep 2020 10:30:46 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 11:43:41 GMT, Erik ?sterlund wrote: > This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. > https://openjdk.java.net/jeps/376). > Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, > and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into > more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to > expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in > the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized > automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization > processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is > actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception > handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC > threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming > of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the > watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll > word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it > brought (and is only possible on TSO machines). So left that one out. I've gone over the entire patch, but I'm leaving the compiler parts to others to review. src/hotspot/share/jfr/leakprofiler/checkpoint/rootResolver.cpp line 275: > 273: > 274: // Traverse the execution stack > 275: for (StackFrameStream fst(jt, true /* update */, true /* process_frames */); !fst.is_done(); fst.next()) { Noticed that lines 261-262 refers to the array that was removed with: JDK-8252656: Replace RegisterArrayForGC mechanism with plain Handles And the comment in block 299-304 might need some love. It's not directly related to this patch, but something that has been moved around in preparation for this patch. I wouldn't be opposed to cleaning that up with this patch. src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp line 39: > 37: #include "runtime/os.hpp" > 38: #include "runtime/semaphore.hpp" > 39: #include "runtime/stackWatermarkSet.hpp" Revert? src/hotspot/share/runtime/safepoint.cpp line 507: > 505: return; > 506: } > 507: StackWatermarkSet::start_processing(static_cast(thread), StackWatermarkKind::gc); Maybe simply: if (thread->is_Java_thread()) { StackWatermarkSet::start_processing(static_cast(thread), StackWatermarkKind::gc); } src/hotspot/share/runtime/stackWatermarkSet.cpp line 70: > 68: Thread* thread = Thread::current(); > 69: if (thread->is_Java_thread()) { > 70: JavaThread* jt = static_cast(thread); as_Java_thread() src/hotspot/share/runtime/stackWatermarkSet.cpp line 112: > 110: return; > 111: } > 112: verify_poll_context(); There's a verfy_poll_context here, but no update_poll_values call. I guess this is because we could be iterating over a thread that is not Thread::current()? But in that case, should we really be "verifying the poll context" of the current thread? src/hotspot/share/runtime/stackWatermarkSet.cpp line 125: > 123: watermark->start_processing(); > 124: } > 125: } No update poll values here? src/hotspot/share/utilities/vmError.cpp line 754: > 752: Thread* thread = ((NamedThread *)_thread)->processed_thread(); > 753: if (thread != NULL && thread->is_Java_thread()) { > 754: JavaThread* jt = static_cast(thread); as_Java_thread() - maybe just search for this in the patch ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From rehn at openjdk.java.net Wed Sep 23 10:52:27 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 10:52:27 GMT Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 04:06:46 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after Coleen > > src/hotspot/share/utilities/filterQueue.hpp line 56: > >> 54: } >> 55: >> 56: // MT-safe > > Not sure where our previous discussion is on this but these posix-style MT-safe labels don't really halp for this kind > of abstract data type API. Please briefly explain the thread-safety properties of add and pop. Added comment > src/hotspot/share/utilities/filterQueue.hpp line 57: > >> 55: >> 56: // MT-safe >> 57: void add(E data); > > It would be more regular naming to use add/remove or push/pop rather than add/pop. Change to push. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Wed Sep 23 10:55:20 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 10:55:20 GMT Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 03:20:02 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after Coleen > > src/hotspot/share/runtime/handshake.cpp line 244: > >> 242: // A new thread on the ThreadsList will not have an operation, >> 243: // hence it is skipped in handshake_try_process. >> 244: HandshakeState::ProcessResult pr = thr->handshake_state()->try_process(_op); > > To be clear on what can be happening here ... as the VMThread has to loop through all threads first to initiate the > handshake, by the time it starts trying to process the op, the target threads may have already done it themselves. > Additionally while looping through all threads, a thread that has not yet been handshaked could try to handshake with a > thread the VMThread has already processed, and so it could also execute the operation before the VMThread gets to it. Yes ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From dholmes at openjdk.java.net Wed Sep 23 10:56:10 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 23 Sep 2020 10:56:10 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v2] In-Reply-To: References: <8KYOSvjbrmDhnP3_WLOu0dO0saiWTHp1SBgE3ikOJkE=.dd9b9e50-2bb5-47cb-a67f-e7c5293ef1d2@github.com> <0zyH4bq9n93UH7O4QuK4WtqIs7Zig2ADAfsCaNyWWfU=.9d8a09e8-5aa1-4c65-93a8-cf84eed75820@github.com> Message-ID: On Wed, 23 Sep 2020 08:37:28 GMT, Robbin Ehn wrote: > Hi, David. > > The support should be the same as before the previous operation is stored on stack while we change to the nested > operation. I don't see what would be different from before? Sorry my mistake. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From dholmes at openjdk.java.net Wed Sep 23 11:06:07 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 23 Sep 2020 11:06:07 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v2] In-Reply-To: References: <8KYOSvjbrmDhnP3_WLOu0dO0saiWTHp1SBgE3ikOJkE=.dd9b9e50-2bb5-47cb-a67f-e7c5293ef1d2@github.com> <0zyH4bq9n93UH7O4QuK4WtqIs7Zig2ADAfsCaNyWWfU=.9d8a09e8-5aa1-4c65-93a8-cf84eed75820@github.com> Message-ID: On Wed, 23 Sep 2020 08:33:23 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/vmThread.hpp line 74: >> >>> 72: >>> 73: void evaluate_operation(VM_Operation* op); >>> 74: void inner_execute(VM_Operation* op); >> >> Perhaps nested_execute as it seems this is only for handling the case of a nested vm op? > > inner_execute(..) is called in the non nested-case here: > https://github.com/openjdk/jdk/blob/e49178a4445378fa0b5505ad6e9f1661636f88b8/src/hotspot/share/runtime/vmThread.cpp#L474 > > Nested case: > https://github.com/openjdk/jdk/blob/e49178a4445378fa0b5505ad6e9f1661636f88b8/src/hotspot/share/runtime/vmThread.cpp#L511 Sorry I missed that. Seems odd that inner_execute handles nesting when that is only possible via one of the paths by which it is called - that's why I thought it was only for the case where called from execute(). I'd rather see the nesting logic handled as before, exclusively on the code path in which it can occur. ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From neliasso at openjdk.java.net Wed Sep 23 11:12:57 2020 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Wed, 23 Sep 2020 11:12:57 GMT Subject: RFR: 8252848: Optimize small primitive arrayCopy operations through partial inlining using AVX-512 masked instructions In-Reply-To: References: Message-ID: <_0-zfIDPieC0Xnc17GaSSsS7Sz9EEUrfjRyqWDtphfU=.298bacde-f330-486a-8bea-03ff1523d00c@github.com> On Tue, 22 Sep 2020 15:33:11 GMT, Jatin Bhateja wrote: >> Summary: >> >> 1) Partial in-lining technique avoids call overhead penalty for small array copy operations with size less than 32 >> bytes. 2) At runtime, a conditional check based on copy length either calls an array-copy stub or executes an optimized >> instruction sequence using AVX-512 masked instructions emitted at the call site. 3) New runtime flag >> ArrayCopyPartialInlineSize=0/32(default)/64 bytes determines the maximum size for partial in-lining. 4) Based on the >> perf results seen in benchmarks currently partial in-lining is performed only for arraycopy involving sub-word types >> (bool/byte/char/short). Once PR-61 gets integrated we can extend this patch to cover all the primitive types. >> Performance Results: >> System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz >> Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java >> ArrayCopyPartialInlineSize : 32 >> >> JMH | Block Size | Baseline (ns/op) | Partial Inling (ns/op) | Gain >> -- | -- | -- | -- | -- >> ArrayCopyAligned.testByte | 1 | 5.417 | 2.696 | 2.009272997 >> ArrayCopyAligned.testByte | 3 | 5.494 | 2.702 | 2.03330866 >> ArrayCopyAligned.testByte | 5 | 5.417 | 2.637 | 2.05422829 >> ArrayCopyAligned.testByte | 10 | 5.343 | 2.703 | 1.976692564 >> ArrayCopyAligned.testByte | 20 | 5.837 | 2.636 | 2.214339909 >> ArrayCopyAligned.testByte | 70 | 5.86 | 6 | 0.976666667 >> ArrayCopyAligned.testByte | 150 | 6.766 | 6.906 | 0.979727773 >> ArrayCopyAligned.testByte | 300 | 7.605 | 7.952 | 0.956363179 >> ArrayCopyAligned.testByte | 600 | 11.989 | 12.007 | 0.998500874 >> ArrayCopyAligned.testByte | 1200 | 16.447 | 16.585 | 0.991679228 >> ArrayCopyAligned.testChar | 1 | 5.02 | 2.828 | 1.775106082 >> ArrayCopyAligned.testChar | 3 | 5.129 | 2.762 | 1.85698769 >> ArrayCopyAligned.testChar | 5 | 5.041 | 2.762 | 1.82512672 >> ArrayCopyAligned.testChar | 10 | 5.716 | 2.762 | 2.069514844 >> ArrayCopyAligned.testChar | 20 | 5.111 | 5.399 | 0.946656788 >> ArrayCopyAligned.testChar | 70 | 6.271 | 6.242 | 1.004645947 >> ArrayCopyAligned.testChar | 150 | 7.45 | 7.599 | 0.980392157 >> ArrayCopyAligned.testChar | 300 | 9.904 | 10.112 | 0.97943038 >> ArrayCopyAligned.testChar | 600 | 17.131 | 17.167 | 0.997902953 >> ArrayCopyAligned.testChar | 1200 | 29.556 | 29.851 | 0.990117584 >> ArrayCopyUnalignedBoth.testByte | 1 | 5.419 | 2.702 | 2.005551443 >> ArrayCopyUnalignedBoth.testByte | 3 | 5.558 | 2.636 | 2.108497724 >> ArrayCopyUnalignedBoth.testByte | 5 | 5.43 | 2.636 | 2.059939302 >> ArrayCopyUnalignedBoth.testByte | 10 | 5.378 | 2.637 | 2.039438756 >> ArrayCopyUnalignedBoth.testByte | 20 | 5.914 | 2.636 | 2.243550836 >> ArrayCopyUnalignedBoth.testByte | 70 | 5.882 | 5.954 | 0.987907289 >> ArrayCopyUnalignedBoth.testByte | 150 | 6.784 | 6.88 | 0.986046512 >> ArrayCopyUnalignedBoth.testByte | 300 | 7.635 | 7.968 | 0.958207831 >> ArrayCopyUnalignedBoth.testByte | 600 | 12.226 | 12.129 | 1.007997362 >> ArrayCopyUnalignedBoth.testByte | 1200 | 16.992 | 20.717 | 0.820195974 >> ArrayCopyUnalignedBoth.testChar | 1 | 5.019 | 2.828 | 1.774752475 >> ArrayCopyUnalignedBoth.testChar | 3 | 5.163 | 2.763 | 1.868621064 >> ArrayCopyUnalignedBoth.testChar | 5 | 5.042 | 2.827 | 1.783516095 >> ArrayCopyUnalignedBoth.testChar | 10 | 5.718 | 2.828 | 2.021923621 >> ArrayCopyUnalignedBoth.testChar | 20 | 5.111 | 5.404 | 0.945780903 >> ArrayCopyUnalignedBoth.testChar | 70 | 6.367 | 6.235 | 1.02117081 >> ArrayCopyUnalignedBoth.testChar | 150 | 7.367 | 8.269 | 0.890917886 >> ArrayCopyUnalignedBoth.testChar | 300 | 10.358 | 10.642 | 0.973313287 >> ArrayCopyUnalignedBoth.testChar | 600 | 20.84 | 17.522 | 1.189361945 >> ArrayCopyUnalignedBoth.testChar | 1200 | 31.895 | 31.892 | 1.000094067 >> ArrayCopyUnalignedDst.testByte | 1 | 5.455 | 2.637 | 2.068638604 >> ArrayCopyUnalignedDst.testByte | 3 | 5.562 | 2.702 | 2.058475204 >> ArrayCopyUnalignedDst.testByte | 5 | 5.427 | 2.702 | 2.008512213 >> ArrayCopyUnalignedDst.testByte | 10 | 5.367 | 2.696 | 1.990727003 >> ArrayCopyUnalignedDst.testByte | 20 | 5.839 | 2.637 | 2.214258627 >> ArrayCopyUnalignedDst.testByte | 70 | 5.888 | 5.968 | 0.986595174 >> ArrayCopyUnalignedDst.testByte | 150 | 6.785 | 6.773 | 1.001771741 >> ArrayCopyUnalignedDst.testByte | 300 | 7.606 | 7.972 | 0.954089313 >> ArrayCopyUnalignedDst.testByte | 600 | 11.986 | 21.195 | 0.565510734 >> ArrayCopyUnalignedDst.testByte | 1200 | 16.54 | 16.784 | 0.985462345 >> ArrayCopyUnalignedDst.testChar | 1 | 5.02 | 2.827 | 1.775733994 >> ArrayCopyUnalignedDst.testChar | 3 | 5.131 | 2.762 | 1.857711803 >> ArrayCopyUnalignedDst.testChar | 5 | 5.038 | 2.762 | 1.82404055 >> ArrayCopyUnalignedDst.testChar | 10 | 5.718 | 2.762 | 2.070238957 >> ArrayCopyUnalignedDst.testChar | 20 | 5.113 | 5.401 | 0.946676541 >> ArrayCopyUnalignedDst.testChar | 70 | 6.222 | 6.214 | 1.001287416 >> ArrayCopyUnalignedDst.testChar | 150 | 7.367 | 8.125 | 0.906707692 >> ArrayCopyUnalignedDst.testChar | 300 | 10.204 | 10.082 | 1.012100774 >> ArrayCopyUnalignedDst.testChar | 600 | 16.978 | 17.135 | 0.990837467 >> ArrayCopyUnalignedDst.testChar | 1200 | 32.351 | 31.996 | 1.011095137 >> ArrayCopyUnalignedSrc.testByte | 1 | 5.414 | 2.696 | 2.008160237 >> ArrayCopyUnalignedSrc.testByte | 3 | 5.494 | 2.637 | 2.083428138 >> ArrayCopyUnalignedSrc.testByte | 5 | 5.431 | 2.637 | 2.059537353 >> ArrayCopyUnalignedSrc.testByte | 10 | 5.344 | 2.703 | 1.977062523 >> ArrayCopyUnalignedSrc.testByte | 20 | 5.834 | 2.696 | 2.163946588 >> ArrayCopyUnalignedSrc.testByte | 70 | 5.883 | 6.009 | 0.979031453 >> ArrayCopyUnalignedSrc.testByte | 150 | 6.729 | 6.87 | 0.979475983 >> ArrayCopyUnalignedSrc.testByte | 300 | 7.603 | 7.97 | 0.953952321 >> ArrayCopyUnalignedSrc.testByte | 600 | 12.004 | 12.16 | 0.987171053 >> ArrayCopyUnalignedSrc.testByte | 1200 | 16.534 | 16.643 | 0.9934507 >> ArrayCopyUnalignedSrc.testChar | 1 | 5.021 | 2.762 | 1.81788559 >> ArrayCopyUnalignedSrc.testChar | 3 | 5.13 | 2.762 | 1.857349747 >> ArrayCopyUnalignedSrc.testChar | 5 | 5.042 | 2.827 | 1.783516095 >> ArrayCopyUnalignedSrc.testChar | 10 | 5.726 | 2.761 | 2.073886273 >> ArrayCopyUnalignedSrc.testChar | 20 | 5.112 | 5.401 | 0.94649139 >> ArrayCopyUnalignedSrc.testChar | 70 | 6.113 | 6.227 | 0.981692629 >> ArrayCopyUnalignedSrc.testChar | 150 | 7.493 | 7.888 | 0.949923935 >> ArrayCopyUnalignedSrc.testChar | 300 | 10.234 | 10.501 | 0.97457385 >> ArrayCopyUnalignedSrc.testChar | 600 | 17.175 | 17.142 | 1.001925096 >> ArrayCopyUnalignedSrc.testChar | 1200 | 31.926 | 31.987 | 0.998092975 >> >> Detailed Reports: >> Baseline : >> [http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_Baseline.txt](http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_Baseline.txt) >> WithOpt : >> [http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_With_PI_Opts.txt](http://cr.openjdk.java.net/~jbhateja/8252848/JMH_results/JMH_With_PI_Opts.txt) > > This pull request is an incremental work over [pull request-61](https://github.com/openjdk/jdk/pull/61). > It shares leaf level assembler routines with it, to build the standalone patch following common code patch needs to be > applied on top of this PR. http://cr.openjdk.java.net/~jbhateja/8252848/common_code_with_8252847.diff Can you explain why 32 bytes are such a distinct performance cliff? Is there any performance difference between doing a single 64 bytes masked copy or two 32 bytes? ------------- PR: https://git.openjdk.java.net/jdk/pull/302 From jzhu at openjdk.java.net Wed Sep 23 11:18:22 2020 From: jzhu at openjdk.java.net (Joshua Zhu) Date: Wed, 23 Sep 2020 11:18:22 GMT Subject: RFR: 8253048: AArch64: When CallLeaf, no need to preserve callee-saved registers in caller In-Reply-To: <9K43aYMMk0zdBfxGBwRA336lvjqGZyLFtZcQKVWLOec=.4a194ce2-db80-4dcc-9ef2-ed2a0d2cd088@github.com> References: <9K43aYMMk0zdBfxGBwRA336lvjqGZyLFtZcQKVWLOec=.4a194ce2-db80-4dcc-9ef2-ed2a0d2cd088@github.com> Message-ID: On Fri, 11 Sep 2020 12:23:30 GMT, Joshua Zhu wrote: > I noticed all Floating-Point and SIMD Registers are defined as SOC > registers in c calling convention on AArch64. > As AArch64 ABI tells, the bottom 64 bits of v8-v15 are callee-saved. > > When using CallRuntime, with the help of existing flag "exclude_soe" and > function add_call_kills(), SOE registers are killed by the call > because values that could show up in the RegisterMap aren't live in > callee saved registers. > But CallLeaf and CallLeafNoFP are ok because they don't have safepoint > and debug info. > > Therefore I submit this patch that aligns save-policy in c calling > convention with AArch64 ABI. It could help eliminate unnecessary SOE > registers spilling in caller across CallLeafNode. > > I wrote a simple test case: > http://cr.openjdk.java.net/~jzhu/8253048/Test.java > Original OptoAssembly is: > http://cr.openjdk.java.net/~jzhu/8253048/old_OptoAssembly > With the patch, unnecessary spillings are eliminated: > http://cr.openjdk.java.net/~jzhu/8253048/new_OptoAssembly > > And when a vector is alive across CallLeaf, with the help of existing > FatProjectionNode and RA, the whole vector register ( length > 64-bit ) > is still spilled to stack as usual. > > A test case using VectorAPI is written to verify: > http://cr.openjdk.java.net/~jzhu/8253048/TestVector.java > Test patch: > http://cr.openjdk.java.net/~jzhu/8253048/patch > OptoAssembly dump: > http://cr.openjdk.java.net/~jzhu/8253048/TestVector_OptoAssembly > > I also searched all occurrences of "V8-V15" in aarch64 codes. > The stubs for sin/cos don't save v10 before usage. > Therefore I replace it with caller-save register v24. > > Jtreg Testing: hotspot_all_no_apps, jdk_core and langtools:tier1 > > Could you please help review this change? > > Best Regards, > Joshua > > --------- Gentle ping. May I ask reviewers to approve this change? ------------- PR: https://git.openjdk.java.net/jdk/pull/129 From rehn at openjdk.java.net Wed Sep 23 11:20:32 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 11:20:32 GMT Subject: RFR: 8238761: Asynchronous handshakes [v6] In-Reply-To: References: Message-ID: > This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes > are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) > Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an > arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a > singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first > pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first > pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake > operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything > except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed > filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake > operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there > is now only one method to call when handshaking one thread. Some comments about the changes: > - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake > all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much > worse then this. > > - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that > thread. > > - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a > handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. > > - Added WB testing method. > > - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. > > - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. > > - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a > safepoint and half of them after, in many handshake all operations. > > - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. > > - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the > moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. > > - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. > > - Added filtered queue and gtest for it. > > Passes multiple t1-8 runs. > Been through some pre-reviwing. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Update after David ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/151/files - new: https://git.openjdk.java.net/jdk/pull/151/files/cd784a75..31421807 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=151&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=151&range=04-05 Stats: 105 lines in 7 files changed: 27 ins; 5 del; 73 mod Patch: https://git.openjdk.java.net/jdk/pull/151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/151/head:pull/151 PR: https://git.openjdk.java.net/jdk/pull/151 From adinn at openjdk.java.net Wed Sep 23 11:23:34 2020 From: adinn at openjdk.java.net (Andrew Dinn) Date: Wed, 23 Sep 2020 11:23:34 GMT Subject: RFR: 8253048: AArch64: When CallLeaf, no need to preserve callee-saved registers in caller In-Reply-To: <9K43aYMMk0zdBfxGBwRA336lvjqGZyLFtZcQKVWLOec=.4a194ce2-db80-4dcc-9ef2-ed2a0d2cd088@github.com> References: <9K43aYMMk0zdBfxGBwRA336lvjqGZyLFtZcQKVWLOec=.4a194ce2-db80-4dcc-9ef2-ed2a0d2cd088@github.com> Message-ID: On Fri, 11 Sep 2020 12:23:30 GMT, Joshua Zhu wrote: > I noticed all Floating-Point and SIMD Registers are defined as SOC > registers in c calling convention on AArch64. > As AArch64 ABI tells, the bottom 64 bits of v8-v15 are callee-saved. > > When using CallRuntime, with the help of existing flag "exclude_soe" and > function add_call_kills(), SOE registers are killed by the call > because values that could show up in the RegisterMap aren't live in > callee saved registers. > But CallLeaf and CallLeafNoFP are ok because they don't have safepoint > and debug info. > > Therefore I submit this patch that aligns save-policy in c calling > convention with AArch64 ABI. It could help eliminate unnecessary SOE > registers spilling in caller across CallLeafNode. > > I wrote a simple test case: > http://cr.openjdk.java.net/~jzhu/8253048/Test.java > Original OptoAssembly is: > http://cr.openjdk.java.net/~jzhu/8253048/old_OptoAssembly > With the patch, unnecessary spillings are eliminated: > http://cr.openjdk.java.net/~jzhu/8253048/new_OptoAssembly > > And when a vector is alive across CallLeaf, with the help of existing > FatProjectionNode and RA, the whole vector register ( length > 64-bit ) > is still spilled to stack as usual. > > A test case using VectorAPI is written to verify: > http://cr.openjdk.java.net/~jzhu/8253048/TestVector.java > Test patch: > http://cr.openjdk.java.net/~jzhu/8253048/patch > OptoAssembly dump: > http://cr.openjdk.java.net/~jzhu/8253048/TestVector_OptoAssembly > > I also searched all occurrences of "V8-V15" in aarch64 codes. > The stubs for sin/cos don't save v10 before usage. > Therefore I replace it with caller-save register v24. > > Jtreg Testing: hotspot_all_no_apps, jdk_core and langtools:tier1 > > Could you please help review this change? > > Best Regards, > Joshua > > --------- Marked as reviewed by adinn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/129 From rehn at openjdk.java.net Wed Sep 23 11:27:30 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 11:27:30 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v2] In-Reply-To: References: <8KYOSvjbrmDhnP3_WLOu0dO0saiWTHp1SBgE3ikOJkE=.dd9b9e50-2bb5-47cb-a67f-e7c5293ef1d2@github.com> <0zyH4bq9n93UH7O4QuK4WtqIs7Zig2ADAfsCaNyWWfU=.9d8a09e8-5aa1-4c65-93a8-cf84eed75820@github.com> Message-ID: On Wed, 23 Sep 2020 11:02:54 GMT, David Holmes wrote: >> inner_execute(..) is called in the non nested-case here: >> https://github.com/openjdk/jdk/blob/e49178a4445378fa0b5505ad6e9f1661636f88b8/src/hotspot/share/runtime/vmThread.cpp#L474 >> >> Nested case: >> https://github.com/openjdk/jdk/blob/e49178a4445378fa0b5505ad6e9f1661636f88b8/src/hotspot/share/runtime/vmThread.cpp#L511 > > Sorry I missed that. Seems odd that inner_execute handles nesting when that is only possible via one of the paths by > which it is called - that's why I thought it was only for the case where called from execute(). I'd rather see the > nesting logic handled as before, exclusively on the code path in which it can occur. That would create a lot of code duplication: void VMThread::none_nested_inner_execute(VM_Operation* op) { Thread* current = Thread::current(); assert(current->is_VM_thread(), "must be a VM thread"); _cur_vm_operation = op; HandleMark hm(VMThread::vm_thread()); EventMark em("Executing %s VM operation: %s", op->name()); // If we are at a safepoint we will evaluate all the operations that // follow that also require a safepoint log_debug(vmthread)("Evaluating %s %s VM operation: %s", _cur_vm_operation->evaluate_at_safepoint() ? "safepoint" : "non-safepoint", _cur_vm_operation->name()); bool end_safepoint = false; if (_cur_vm_operation->evaluate_at_safepoint()) { SafepointSynchronize::begin(); if (_timeout_task != NULL) { _timeout_task->arm(); } end_safepoint = true; } evaluate_operation(_cur_vm_operation); if (end_safepoint) { if (_timeout_task != NULL) { _timeout_task->disarm(); } SafepointSynchronize::end(); } _cur_vm_operation = NULL; } Which 80% the same. (Same minus a few lines) ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From rehn at openjdk.java.net Wed Sep 23 11:39:34 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 11:39:34 GMT Subject: RFR: 8238761: Asynchronous handshakes [v7] In-Reply-To: References: Message-ID: > This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes > are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) > Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an > arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a > singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first > pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first > pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake > operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything > except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed > filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake > operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there > is now only one method to call when handshaking one thread. Some comments about the changes: > - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake > all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much > worse then this. > > - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that > thread. > > - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a > handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. > > - Added WB testing method. > > - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. > > - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. > > - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a > safepoint and half of them after, in many handshake all operations. > > - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. > > - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the > moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. > > - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. > > - Added filtered queue and gtest for it. > > Passes multiple t1-8 runs. > Been through some pre-reviwing. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Fixed trailing whitespace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/151/files - new: https://git.openjdk.java.net/jdk/pull/151/files/31421807..94daf2c7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=151&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=151&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/151/head:pull/151 PR: https://git.openjdk.java.net/jdk/pull/151 From jzhu at openjdk.java.net Wed Sep 23 11:53:51 2020 From: jzhu at openjdk.java.net (Joshua Zhu) Date: Wed, 23 Sep 2020 11:53:51 GMT Subject: RFR: 8253048: AArch64: When CallLeaf, no need to preserve callee-saved registers in caller In-Reply-To: References: <9K43aYMMk0zdBfxGBwRA336lvjqGZyLFtZcQKVWLOec=.4a194ce2-db80-4dcc-9ef2-ed2a0d2cd088@github.com> Message-ID: On Wed, 23 Sep 2020 11:21:09 GMT, Andrew Dinn wrote: >> I noticed all Floating-Point and SIMD Registers are defined as SOC >> registers in c calling convention on AArch64. >> As AArch64 ABI tells, the bottom 64 bits of v8-v15 are callee-saved. >> >> When using CallRuntime, with the help of existing flag "exclude_soe" and >> function add_call_kills(), SOE registers are killed by the call >> because values that could show up in the RegisterMap aren't live in >> callee saved registers. >> But CallLeaf and CallLeafNoFP are ok because they don't have safepoint >> and debug info. >> >> Therefore I submit this patch that aligns save-policy in c calling >> convention with AArch64 ABI. It could help eliminate unnecessary SOE >> registers spilling in caller across CallLeafNode. >> >> I wrote a simple test case: >> http://cr.openjdk.java.net/~jzhu/8253048/Test.java >> Original OptoAssembly is: >> http://cr.openjdk.java.net/~jzhu/8253048/old_OptoAssembly >> With the patch, unnecessary spillings are eliminated: >> http://cr.openjdk.java.net/~jzhu/8253048/new_OptoAssembly >> >> And when a vector is alive across CallLeaf, with the help of existing >> FatProjectionNode and RA, the whole vector register ( length > 64-bit ) >> is still spilled to stack as usual. >> >> A test case using VectorAPI is written to verify: >> http://cr.openjdk.java.net/~jzhu/8253048/TestVector.java >> Test patch: >> http://cr.openjdk.java.net/~jzhu/8253048/patch >> OptoAssembly dump: >> http://cr.openjdk.java.net/~jzhu/8253048/TestVector_OptoAssembly >> >> I also searched all occurrences of "V8-V15" in aarch64 codes. >> The stubs for sin/cos don't save v10 before usage. >> Therefore I replace it with caller-save register v24. >> >> Jtreg Testing: hotspot_all_no_apps, jdk_core and langtools:tier1 >> >> Could you please help review this change? >> >> Best Regards, >> Joshua >> >> --------- > > Marked as reviewed by adinn (Reviewer). Aph and Adinn, Thanks a lot for your review! ------------- PR: https://git.openjdk.java.net/jdk/pull/129 From eosterlund at openjdk.java.net Wed Sep 23 12:22:48 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 23 Sep 2020 12:22:48 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> Message-ID: On Wed, 23 Sep 2020 06:32:14 GMT, Allan Gregersen wrote: > > > > I would like to hear answer to @dholmes-ora question in JBS: > > > > "Do we really need yet another stack dumping interface in the VM? Why isn't a debugger using JVM TI?" > > > > > > > > > One reason for having both the new getStackFrames API (set of threads) as well as the existing iterateFrames (current > > > thread only) API in JVMCI is that Truffle would want a deopt-free read-only view of the values in a frame, which to the > > > best of our knowledge is not possible through JVMTI. Only in rare cases, materialization of frames is required, so it > > > boils down to the performance hit caused by deopting frames, which is even more of a concern with a set of threads than > > > for the single current thread case. Another potential issue with a JVMTI-based approach is that there might be other > > > drawbacks to having an always-on (or even late attached) JVMTI agent in a GraalVM? > > > > > > > > 1. You are describing that the main reason is performance. But you also say this is to be used by a debugger? So, not > > sure performance as a primary motive really makes sense then. Not sure why performance of debugging Truffle must be so > > much faster than debugging Java code (which I have not heard anyone complain about). And if this really was an actual > > performance problem, it seems like we would want a generic fix then, not a special Truffle stack walker for debugging > > Truffle code alone, to be maintained separately. 2. We are talking about JVMTI, not JVMCI. iterateFrames is defined in > > JVMCI, and that is something completely different, which I don't think any of us had in mind. It seems indeed to be > > limited to the current frame. I'm talking about e.g. JVMTI GetStackTrace and the JVMTI GetLocal* functions. It gives > > you a stack trace for any thread (not just the current one), and allows you to retrieve locals. 3. When you just read > > locals, (as you describe is your use case), there is no need to deoptimize anything. So yeah, that's just not something > > we do, unless you change the locals, which you said you are not. Please let me know if there is anything I missed. But > > so far it seems to me that the mentioned JVMTI functionality is all you really need for a debugger. What did I miss? I > > would like to better understand the problem domain before taking this further. > > Thanks for your quick follow-up. > > 1. It's not entirely made for the debugger use-case. For example in some guest languages we need this for implementing > Thread#getStackTrace or similar. In Espresso (Java as a Truffle guest language) we would need this also for > implementing part of the management API. > > 2. I know that you suggested JVMTI and no JVMCI. Since I wasn't around when the decision to implement and include > iterateFrames into JVMCI was made, I'm unaware of the exact reasoning behind that decision. I was assuming that > whatever reason not to go with JVMTI back then would still hold true today. So say we wanted to adopt the JVMTI > approach now. Would the design be an in-process always on and in-process JVMTI agent? Would there be security > implications from such an approach leaving any VM running anything Truffle more vulnerable? > > 3. No need for deoptimize anything when reading locals through JVMTI is good. Thanks for clarifying that. So I understand it, you really have 2 cases: 1) Using the debugger 2) To support other APIs that need a stack trace So if you use JVMTI for the debugging (like everybody else), that seems to be a solved problem. As for the second use case, I hope you can use java.lang.StackWalker? It should give you all the info you could dream of. If you can't use all classes in java.lang.* then I fear that you are in a lot of trouble using HotSpot in general. ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From eosterlund at openjdk.java.net Wed Sep 23 12:45:43 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 23 Sep 2020 12:45:43 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 07:17:31 GMT, Stefan Karlsson wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, >> and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into >> more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to >> expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in >> the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized >> automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization >> processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is >> actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception >> handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC >> threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming >> of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the >> watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll >> word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it >> brought (and is only possible on TSO machines). So left that one out. > > src/hotspot/share/gc/z/zStackWatermark.cpp line 78: > >> 76: ZThreadLocalData::do_invisible_root(_jt, ZBarrier::load_barrier_on_invisible_root_oop_field); >> 77: >> 78: ZVerify::verify_thread_frames_bad(_jt); > > Every time I read the name verify_thread_no_frames_bad I read it as "verify that no frames are bad", but that's not at > all what that function does. > Is there still a reason why verify_thread_no_frames_bad and verify_thread_frames_bad are split up into two functions? > Or could we fuse them into a ZVerify::verify_thread_bad? I will try this. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From eosterlund at openjdk.java.net Wed Sep 23 12:53:37 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 23 Sep 2020 12:53:37 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 07:39:55 GMT, Stefan Karlsson wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, >> and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into >> more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to >> expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in >> the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized >> automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization >> processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is >> actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception >> handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC >> threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming >> of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the >> watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll >> word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it >> brought (and is only possible on TSO machines). So left that one out. > > src/hotspot/share/gc/z/zCollectedHeap.cpp line 235: > >> 233: return true; >> 234: } >> 235: > > Weird placement between store barrier functions. But even weirder that we still have those functions. I'll remove them > with JDK-8253516. Perfect, thanks. > src/hotspot/share/gc/z/zDriver.cpp line 108: > >> 106: return false; >> 107: } >> 108: > > Group needs_inactive_gc_locker, skip_thread_oop_barriers, and allow_coalesced_vm_operations together? > > Add a comment about why we chose to skip coalescing here. Per explicitly wanted skip_thread_oop_barriers grouped with needs_inactive_gc_locker. But I should remove allow_coalesced_vm_operations; it is no longer used since I have removed VM operation coalescing completely already. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From eosterlund at openjdk.java.net Wed Sep 23 13:04:50 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 23 Sep 2020 13:04:50 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing In-Reply-To: References: Message-ID: <5ybiOYTcLErkirwGD7rSWg0MoVsOPdvQ2Jogf7d_VfY=.92e95514-30e6-47c0-903a-a9e6967607e3@github.com> On Wed, 23 Sep 2020 08:51:08 GMT, Stefan Karlsson wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, >> and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into >> more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to >> expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in >> the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized >> automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization >> processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is >> actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception >> handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC >> threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming >> of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the >> watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll >> word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it >> brought (and is only possible on TSO machines). So left that one out. > > src/hotspot/share/jfr/leakprofiler/checkpoint/rootResolver.cpp line 275: > >> 273: >> 274: // Traverse the execution stack >> 275: for (StackFrameStream fst(jt, true /* update */, true /* process_frames */); !fst.is_done(); fst.next()) { > > Noticed that lines 261-262 refers to the array that was removed with: > JDK-8252656: Replace RegisterArrayForGC mechanism with plain Handles > > And the comment in block 299-304 might need some love. > > It's not directly related to this patch, but something that has been moved around in preparation for this patch. I > wouldn't be opposed to cleaning that up with this patch. Will do. > src/hotspot/share/runtime/stackWatermarkSet.cpp line 112: > >> 110: return; >> 111: } >> 112: verify_poll_context(); > > There's a verfy_poll_context here, but no update_poll_values call. I guess this is because we could be iterating over a > thread that is not Thread::current()? But in that case, should we really be "verifying the poll context" of the current > thread? Correct - I'm not updating the poll values, because it's not necessarily the current thread we are processing. But the verify_poll_context() code does correctly always refer to the current frame. It verifies we are in the right context to perform this kind of processing, yet the processing could be for a different thread. > src/hotspot/share/runtime/stackWatermarkSet.cpp line 125: > >> 123: watermark->start_processing(); >> 124: } >> 125: } > > No update poll values here? Like the previous scenario, start_processing may be called on a different thread than Thread::current. The thread the stack belongs to will always update the poll values when it wakes up from the safepoint. Other threads have no business updating it. > src/hotspot/share/utilities/vmError.cpp line 754: > >> 752: Thread* thread = ((NamedThread *)_thread)->processed_thread(); >> 753: if (thread != NULL && thread->is_Java_thread()) { >> 754: JavaThread* jt = static_cast(thread); > > as_Java_thread() - maybe just search for this in the patch Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From shade at openjdk.java.net Wed Sep 23 13:07:23 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 23 Sep 2020 13:07:23 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v3] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 08:45:00 GMT, Robbin Ehn wrote: >> We simplify the vmThread by removing the queue and refactor the the main loop. >> This solves the issues listed: >> - It can create an extra safepoint directly after a safepoint. >> - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. >> - The exposure of the vm operation is dangerous if it's a handshake. >> - The code is a hornets nest with the repetition of checks and branches >> >> Passes t1-8, and a benchmark run. >> >> If you want a smaller diff the commits contains the incremental progress and each commit passed t1. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Update after Coleen and David I have only minor comments, without diving into the logic machinery. I am relying on others to review this more substantially. src/hotspot/share/runtime/vmThread.cpp line 389: > 387: if (!prev_vm_operation->allow_nested_vm_operations()) { > 388: fatal("Nested VM operation %s requested by operation %s", > 389: op->name(), vm_operation()->name()); This is better as `prev_vm_operation`, not `vm_operation()`? Saves some brain cycles reading... src/hotspot/share/runtime/vmThread.cpp line 483: > 481: break; > 482: } > 483: } while(!should_terminate()); So now we have the duplicated `should_terminate()` here. Can we check it once (logically)? For example: do { wait_for_operation(); assert(_next_vm_operation != NULL, "Must have one"); inner_execute(_next_vm_operation); } while (!should_terminate()); If not, then it might be rewritten without change in logic this: while (true) { if (should_terminate()) break; wait_for_operation(); if (should_terminate()) break; assert(_next_vm_operation != NULL, "Must have one"); inner_execute(_next_vm_operation); } src/hotspot/share/runtime/vmThread.hpp line 108: > 106: static VM_Operation::VMOp_Type vm_op_type() { > 107: assert(Thread::current()->is_VM_thread(), "Must be"); > 108: return _cur_vm_operation->type(); These two might just delegate and check a bit more thoroughly. static VM_Operation* vm_operation() { static VM_Operation::VMOp_Type vm_op_type() { return _cur_vm_operation->type(); } assert(Thread::current()->is_VM_thread(), "Must be"); return _cur_vm_operation; } static VM_Operation::VMOp_Type vm_op_type() { VM_Operation* op = vm_operation(); assert (op != NULL, "sanity"); return op->type(); } Haven't checked if `vm_op_type` helps readability at actual usages, maybe it is unnecessary to begin with. src/hotspot/share/runtime/vmThread.cpp line 461: > 459: // We did find anything to execute, notify any waiter so they can install a new one. > 460: ml_op_lock.notify_all(); > 461: ml_op_lock.wait(GuaranteedSafepointInterval); I initially had the same concern as in my previous review: if there are multiple threads entering here, they could just ping-pong each other with notify-wait. But then I realized this method is only called from VMThread itself. Maybe methods like that need to be `assert(is_VM_thread())` on entry? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/228 From stefank at openjdk.java.net Wed Sep 23 13:10:36 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 23 Sep 2020 13:10:36 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 12:50:51 GMT, Erik ?sterlund wrote: >> src/hotspot/share/gc/z/zDriver.cpp line 108: >> >>> 106: return false; >>> 107: } >>> 108: >> >> Group needs_inactive_gc_locker, skip_thread_oop_barriers, and allow_coalesced_vm_operations together? >> >> Add a comment about why we chose to skip coalescing here. > > Per explicitly wanted skip_thread_oop_barriers grouped with needs_inactive_gc_locker. But I should remove > allow_coalesced_vm_operations; it is no longer used since I have removed VM operation coalescing completely already. I agree with Per, but I also wanted to move allow_coalesced_vm_operations. But now your removing it, so it becomes a moot point. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From mbeckwit at openjdk.java.net Wed Sep 23 13:23:43 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Wed, 23 Sep 2020 13:23:43 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5] In-Reply-To: References: Message-ID: > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: Update orderAccess_windows_aarch64.hpp changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/212/files - new: https://git.openjdk.java.net/jdk/pull/212/files/50ab8edf..4da7b89e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From mbeckwit at openjdk.java.net Wed Sep 23 13:23:43 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Wed, 23 Sep 2020 13:23:43 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5] In-Reply-To: References: <1ZhTsmFbjf-c4lddQG53Y-D1PieCcxEOGBKe-CkpGAo=.8be414f0-d0a0-48d9-8be7-82615f733233@github.com> Message-ID: On Mon, 21 Sep 2020 14:47:15 GMT, Bernhard Urban-Forster wrote: >>> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ >>> >>> On 18/09/2020 11:14, Monica Beckwith wrote: >>> >>> > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >>> >>> The diffs in assembler_aarch64.cpp are mostly spurious. Please try this. >> >> >> Thank you Andrew. Is the goal to reduce the patch diff in `assembler_aarch64.cpp`? If so, we need to get rid of the >> retry in your patch to avoid additional calls to `random`, e.g. something like this (the diff for the generated part >> would look indeed nicer with that: https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ): >> --- a/src/hotspot/cpu/aarch64/aarch64-asmtest.py >> +++ b/src/hotspot/cpu/aarch64/aarch64-asmtest.py >> @@ -13,6 +13,8 @@ class Register(Operand): >> >> def generate(self): >> self.number = random.randint(0, 30) >> + if self.number == 18: >> + self.number = 17 >> return self >> >> def astr(self, prefix): >> @@ -37,6 +39,8 @@ class GeneralRegisterOrZr(Register): >> >> def generate(self): >> self.number = random.randint(0, 31) >> + if self.number == 18: >> + self.number = 16 >> return self >> >> def astr(self, prefix = ""): >> @@ -54,6 +58,8 @@ class GeneralRegisterOrZr(Register): >> class GeneralRegisterOrSp(Register): >> def generate(self): >> self.number = random.randint(0, 31) >> + if self.number == 18: >> + self.number = 15 >> return self >> >> def astr(self, prefix = ""): >> @@ -1331,7 +1337,7 @@ generate(SpecialCases, [["ccmn", "__ ccmn(zr, zr, 3u, Assembler::LE);", >> ["st1w", "__ sve_st1w(z0, __ S, p1, Address(r0, 7));", "st1w\t{z0.s}, p1, [x0, #7, MUL VL]"], >> ["st1b", "__ sve_st1b(z0, __ B, p2, Address(sp, r1));", "st1b\t{z0.b}, p2, [sp, x1]"], >> ["st1h", "__ sve_st1h(z0, __ H, p3, Address(sp, r8));", "st1h\t{z0.h}, p3, [sp, x8, LSL #1]"], >> - ["st1d", "__ sve_st1d(z0, __ D, p4, Address(r0, r18));", "st1d\t{z0.d}, p4, [x0, x18, LSL #3]"], >> + ["st1d", "__ sve_st1d(z0, __ D, p4, Address(r0, r17));", "st1d\t{z0.d}, p4, [x0, x17, >> LSL #3]"], >> ["ldr", "__ sve_ldr(z0, Address(sp));", "ldr\tz0, [sp]"], >> ["ldr", "__ sve_ldr(z31, Address(sp, -256));", "ldr\tz31, [sp, #-256, MUL VL]"], >> ["str", "__ sve_str(z8, Address(r8, 255));", "str\tz8, [x8, #255, MUL VL]"], > >> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ >> >> On 21/09/2020 09:18, Bernhard Urban-Forster wrote: >> >> > Thank you Andrew. Is the goal to reduce the patch diff in `assembler_aarch64.cpp`? If so, we need to get rid of the >> > retry in your patch to avoid additional calls to `random`, e.g. something like this (the diff for the generated part >> > would look indeed nicer with that: https://gist.github.com/lewurm/2e7b0e00447696c75e00febb83034ba1 ): >> > [...] >> >> Yes, better. Thanks. > > Great, I've updated the PR. Thank you! Thanks, Andrew for catching that. I have made the needful changes. -Monica > _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ > > On 18/09/2020 11:14, Monica Beckwith wrote: > > > This is a continuation of > > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > > * We've improved the write barrier as suggested by Andrew [1] > > It's still wrong, I'm afraid. This is not a full barrier: > > +#define FULL_MEM_BARRIER atomic_thread_fence(std::memory_order_acq_rel); > > it is only StoreStore|LoadStore|LoadLoad, but you need StoreLoad as > well. It might well be that you get the same DMB ISH instruction, but > unless you use a StoreLoad barrier here it's theoretically possible > for a compiler to reorder accesses so that a processor sees its own > stores before other processors do. (And it's confusing for the reader > too.) > > Use: > > +#define FULL_MEM_BARRIER atomic_thread_fence(std::memory_order_seq_cst); > > See here: > > https://en.cppreference.com/w/cpp/atomic/memory_order > > memory_order_seq_cst "...plus a single total order exists in which all > threads observe all modifications in the same order (see > Sequentially-consistent ordering below)" > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From eosterlund at openjdk.java.net Wed Sep 23 13:50:30 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 23 Sep 2020 13:50:30 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v2] In-Reply-To: References: Message-ID: <-FppQ9a6WgYy4OzBKOqx11CZlJjtWddLDeSottkTjrg=.0ce0c6a7-7b9b-4bb4-af3d-46e02432aaad@github.com> > This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. > https://openjdk.java.net/jeps/376). > Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, > and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into > more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to > expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in > the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized > automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization > processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is > actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception > handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC > threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming > of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the > watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll > word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it > brought (and is only possible on TSO machines). So left that one out. Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into 8253180_conc_stack_scanning - Review: SteafanK CR 1 - 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing ------------- Changes: https://git.openjdk.java.net/jdk/pull/296/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=01 Stats: 2629 lines in 130 files changed: 2079 ins; 289 del; 261 mod Patch: https://git.openjdk.java.net/jdk/pull/296.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/296/head:pull/296 PR: https://git.openjdk.java.net/jdk/pull/296 From eosterlund at openjdk.java.net Wed Sep 23 13:50:30 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 23 Sep 2020 13:50:30 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v2] In-Reply-To: <2ytvTzDWlalJ67i7_piPhQJU3ApK-M82JAXVYjCIgFQ=.e3d10e0b-fbab-4e45-941f-d54a8a35f1eb@github.com> References: <1iLCRf17v1nwE70nQk7qq0bcad8gop9q5dYt-sr9fG8=.81025951-bc22-45d0-84ff-9557b67262e3@github.com> <2ytvTzDWlalJ67i7_piPhQJU3ApK-M82JAXVYjCIgFQ=.e3d10e0b-fbab-4e45-941f-d54a8a35f1eb@github.com> Message-ID: On Wed, 23 Sep 2020 08:33:20 GMT, Erik ?sterlund wrote: >> src/hotspot/share/compiler/oopMap.cpp line 243: >> >>> 241: } else { >>> 242: all_do(fr, reg_map, f, process_derived_oop, &do_nothing_cl); >>> 243: } >> >> I wonder if we shouldn't hide the StackWatermarkSet in the GC code, and not "activate" the DerivedPointerTable when a >> SWS is used? Isn't it the case that already don't enable the table for ZGC? Couldn't this simply be: ` >> if (DerivedPointerTable::is_active()) { >> all_do(fr, reg_map, f, add_derived_oop, &do_nothing_cl); >> } else { >> all_do(fr, reg_map, f, process_derived_oop, &do_nothing_cl); >> } >> ` > > The problem isn't the GC code deciding to use or not use the derived pointer "table". It's the shared code uses of it > that is the problem here. The table is explicitly activated by shared code, when for example using the JFR leak > profiler, JVMTI heap walks, etc. This code makes the selection a GC choice when invoked by GC code, and a shared > runtime choice when invoked by the shared runtime. After discussions off-line, I think passing in an explicit derived pointer iteration mode into oops_do, is much better than trying to figure out who the caller is from this context. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From eosterlund at openjdk.java.net Wed Sep 23 13:57:11 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 23 Sep 2020 13:57:11 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v3] In-Reply-To: References: Message-ID: > This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. > https://openjdk.java.net/jeps/376). > Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, > and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into > more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to > expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in > the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized > automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization > processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is > actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception > handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC > threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming > of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the > watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll > word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it > brought (and is only possible on TSO machines). So left that one out. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Review: SteafanK CR 2 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/296/files - new: https://git.openjdk.java.net/jdk/pull/296/files/e77e8e88..71db0303 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/296.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/296/head:pull/296 PR: https://git.openjdk.java.net/jdk/pull/296 From eosterlund at openjdk.java.net Wed Sep 23 13:57:11 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 23 Sep 2020 13:57:11 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v3] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 10:27:05 GMT, Stefan Karlsson wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Review: SteafanK CR 2 > > I've gone over the entire patch, but I'm leaving the compiler parts to others to review. Thanks for reviewing @stefank, and thanks for all the pre-reviewing as well. I have updated the PR to resolve all your comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From eosterlund at openjdk.java.net Wed Sep 23 13:57:11 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 23 Sep 2020 13:57:11 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v3] In-Reply-To: <5ybiOYTcLErkirwGD7rSWg0MoVsOPdvQ2Jogf7d_VfY=.92e95514-30e6-47c0-903a-a9e6967607e3@github.com> References: <5ybiOYTcLErkirwGD7rSWg0MoVsOPdvQ2Jogf7d_VfY=.92e95514-30e6-47c0-903a-a9e6967607e3@github.com> Message-ID: On Wed, 23 Sep 2020 12:59:40 GMT, Erik ?sterlund wrote: >> src/hotspot/share/runtime/stackWatermarkSet.cpp line 112: >> >>> 110: return; >>> 111: } >>> 112: verify_poll_context(); >> >> There's a verfy_poll_context here, but no update_poll_values call. I guess this is because we could be iterating over a >> thread that is not Thread::current()? But in that case, should we really be "verifying the poll context" of the current >> thread? > > Correct - I'm not updating the poll values, because it's not necessarily the current thread we are processing. But the > verify_poll_context() code does correctly always refer to the current frame. It verifies we are in the right context to > perform this kind of processing, yet the processing could be for a different thread. Updating the name to verify_processing_context to better reflect what this does. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From stefank at openjdk.java.net Wed Sep 23 14:30:41 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 23 Sep 2020 14:30:41 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v3] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 13:57:11 GMT, Erik ?sterlund wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, >> and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into >> more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to >> expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in >> the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized >> automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization >> processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is >> actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception >> handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC >> threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming >> of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the >> watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll >> word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it >> brought (and is only possible on TSO machines). So left that one out. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Review: SteafanK CR 2 Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From kim.barrett at oracle.com Wed Sep 23 14:40:21 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 23 Sep 2020 10:40:21 -0400 Subject: RFR: 8247910: Improve alignment and power-of-2 utilities using C++14 In-Reply-To: <43db77d4-9d37-fadd-bcdb-09275d01aed8@redhat.com> References: <43db77d4-9d37-fadd-bcdb-09275d01aed8@redhat.com> Message-ID: <294F5F30-7256-404C-B3EF-06E0701F82A3@oracle.com> > On Sep 23, 2020, at 5:39 AM, Andrew Haley wrote: > > On 23/09/2020 09:24, Kim Barrett wrote: > >> gcc5 is the first version of gcc that *claims* to completely support >> C++14. That?s the only reason for setting it as the lower limit; it >> wasn?t based on data. >> >> Rather than potentially contort code to support what is now a pretty >> old version, I?d prefer we moved forward the minimum required >> version. > > I'd prefer that too, but it's not just about us developers: there are > many distros building newer OpenJDK on older systems, and they may not > have the freedom to change the system-wide C compiler. Given that we > want to encourage people to use modern OpenJDK releases we should at > least try to accommodate older compilers. > > I'd say that if we can use GCC 5 with minor changes we should do so, > but not if it makes a mess of the code. Sure, but the code that?s failing is nothing out of the ordinary for C++14. I?m pretty surprised there?s a failure for anything like that. I?m also not in a good position to try to track down the problem; if Thomas or someone else wants to, I?m game for kibitzing, but I?m reluctant to try to drive the investigation. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://urldefense.com/v3/__https://keybase.io/andrewhaley__;!!GqivPVa7Brio!I1YAmf55J8AxadNeOeEq0g8zvKdUQ0d5zgrC66QQ4kdY23Ldo-WTx6Ww7TU1JXe-$ > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From kim.barrett at oracle.com Wed Sep 23 14:42:52 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 23 Sep 2020 10:42:52 -0400 Subject: RFR: 8247910: Improve alignment and power-of-2 utilities using C++14 In-Reply-To: References: Message-ID: > On Sep 23, 2020, at 2:14 AM, Thomas St?fe wrote: > > Hi, > > unfortunately this breaks my builds on Ubuntu 16.4. I am using gcc 5.4.0 which according to https://openjdk.java.net/groups/build/doc/building.html should still be an accepted compiler? > > Creating hotspot/variant-server/libjvm/gtest/gtestLauncher from 1 file(s) > In file included from /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/services/memTracker.hpp:85:0, > from /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/precompiled/precompiled.hpp:60: > /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/services/mallocTracker.hpp:190:78: error: size of array '_snapshot' is not an integral constant-expression > static size_t _snapshot[CALC_OBJ_SIZE_IN_TYPE(MallocMemorySnapshot, size_t)]; I don?t see anything here to indicate what platform this is for. It?s not, by any chance, arm32? From lucy at openjdk.java.net Wed Sep 23 14:48:55 2020 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 23 Sep 2020 14:48:55 GMT Subject: RFR: 8250635: MethodArityHistogram should use Compile_lock in favour of fancy checks Message-ID: This change was already fully reviewed before the Mercurial to Git transition. Reviewed-by: thartmann (TobiHartmann), mdoerr (TheRealMDoerr). ------------- Commit messages: - JDK-8250635 tranferred from Mercurial Changes: https://git.openjdk.java.net/jdk/pull/321/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=321&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8250635 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/321.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/321/head:pull/321 PR: https://git.openjdk.java.net/jdk/pull/321 From rehn at openjdk.java.net Wed Sep 23 14:49:43 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 14:49:43 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v3] In-Reply-To: References: Message-ID: <_XvcdRWiV6Db4MrTA0eykTUtQgbuZ7kC0LXztzMpsYc=.c6e49dd8-6325-48f1-8efd-e41d712dc649@github.com> On Wed, 23 Sep 2020 12:51:48 GMT, Aleksey Shipilev wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after Coleen and David > > src/hotspot/share/runtime/vmThread.cpp line 389: > >> 387: if (!prev_vm_operation->allow_nested_vm_operations()) { >> 388: fatal("Nested VM operation %s requested by operation %s", >> 389: op->name(), vm_operation()->name()); > > This is better as `prev_vm_operation`, not `vm_operation()`? Saves some brain cycles reading... I changed prev_vm_operation to _cur_vm_operation and removed uses of vm_operation() to be consistent with the rest of the method (storing and reading from _cur_vm_operation). VM_Operation* prev_vm_operation = NULL; if (_cur_vm_operation!= NULL) { // Check the VM operation allows nested VM operation. // This normally not the case, e.g., the compiler // does not allow nested scavenges or compiles. if (!_cur_vm_operation->allow_nested_vm_operations()) { fatal("Nested VM operation %s requested by operation %s", op->name(), _cur_vm_operation->name()); } op->set_calling_thread(_cur_vm_operation->calling_thread()); prev_vm_operation = _cur_vm_operation; } > src/hotspot/share/runtime/vmThread.cpp line 483: > >> 481: break; >> 482: } >> 483: } while(!should_terminate()); > > So now we have the duplicated `should_terminate()` here. Can we check it once (logically)? For example: > > do { > wait_for_operation(); > assert(_next_vm_operation != NULL, "Must have one"); > inner_execute(_next_vm_operation); > } while (!should_terminate()); > > If not, then it might be rewritten without change in logic this: > > while (true) { > if (should_terminate()) break; > wait_for_operation(); > if (should_terminate()) break; > assert(_next_vm_operation != NULL, "Must have one"); > inner_execute(_next_vm_operation); > } If we return from wait_for_operation() due to should_terminate() but someone just stored an op into _next_vm_operation. Calling inner_execute() would execute that op before exiting, so I'm going with an additional if on should_terminate(). ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From mdoerr at openjdk.java.net Wed Sep 23 15:12:39 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 23 Sep 2020 15:12:39 GMT Subject: RFR: 8250635: MethodArityHistogram should use Compile_lock in favour of fancy checks In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 14:41:57 GMT, Lutz Schmidt wrote: > This change was already fully reviewed before the Mercurial to Git transition. > Reviewed-by: thartmann (TobiHartmann), mdoerr (TheRealMDoerr). I had already reviewed it on the mailing list. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/321 From rehn at openjdk.java.net Wed Sep 23 15:14:52 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 15:14:52 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v3] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 13:00:43 GMT, Aleksey Shipilev wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after Coleen and David > > src/hotspot/share/runtime/vmThread.hpp line 108: > >> 106: static VM_Operation::VMOp_Type vm_op_type() { >> 107: assert(Thread::current()->is_VM_thread(), "Must be"); >> 108: return _cur_vm_operation->type(); > > These two might just delegate and check a bit more thoroughly. > > static VM_Operation* vm_operation() { > static VM_Operation::VMOp_Type vm_op_type() { return _cur_vm_operation->type(); } > assert(Thread::current()->is_VM_thread(), "Must be"); > return _cur_vm_operation; > } > > static VM_Operation::VMOp_Type vm_op_type() { > VM_Operation* op = vm_operation(); > assert (op != NULL, "sanity"); > return op->type(); > } > > Haven't checked if `vm_op_type` helps readability at actual usages, maybe it is unnecessary to begin with. vm_operation() may return NULL as callers handles this, as long it's the VM Thread calling a non NULL is also fine. But we should remove this method and do something else, but for another PR :) vm_op_type() is only used at one place, but I think your version is much better so I took that! > src/hotspot/share/runtime/vmThread.cpp line 461: > >> 459: // We did find anything to execute, notify any waiter so they can install a new one. >> 460: ml_op_lock.notify_all(); >> 461: ml_op_lock.wait(GuaranteedSafepointInterval); > > I initially had the same concern as in my previous review: if there are multiple threads entering here, they could just > ping-pong each other with notify-wait. But then I realized this method is only called from VMThread itself. Maybe > methods like that need to be `assert(is_VM_thread())` on entry? Adding assert(s)! ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From thartmann at openjdk.java.net Wed Sep 23 15:27:52 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 23 Sep 2020 15:27:52 GMT Subject: RFR: 8250635: MethodArityHistogram should use Compile_lock in favour of fancy checks In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 14:41:57 GMT, Lutz Schmidt wrote: > This change was already fully reviewed before the Mercurial to Git transition. > Reviewed-by: thartmann (TobiHartmann), mdoerr (TheRealMDoerr). Looks good. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/321 From shade at openjdk.java.net Wed Sep 23 15:29:49 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 23 Sep 2020 15:29:49 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v3] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 08:45:00 GMT, Robbin Ehn wrote: >> We simplify the vmThread by removing the queue and refactor the the main loop. >> This solves the issues listed: >> - It can create an extra safepoint directly after a safepoint. >> - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. >> - The exposure of the vm operation is dangerous if it's a handshake. >> - The code is a hornets nest with the repetition of checks and branches >> >> Passes t1-8, and a benchmark run. >> >> If you want a smaller diff the commits contains the incremental progress and each commit passed t1. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Update after Coleen and David Looks good! src/hotspot/share/runtime/vmThread.cpp line 382: > 380: > 381: VM_Operation* prev_vm_operation = NULL; > 382: if (_cur_vm_operation!= NULL) { Whitespace before `!=`? src/hotspot/share/runtime/vmThread.hpp line 109: > 107: static VM_Operation::VMOp_Type vm_op_type() { > 108: VM_Operation* op = vm_operation(); > 109: assert (op != NULL, "sanity"); Should be no whitespace after `assert`? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/228 From jbhateja at openjdk.java.net Wed Sep 23 15:33:50 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 23 Sep 2020 15:33:50 GMT Subject: RFR: 8252848: Optimize small primitive arrayCopy operations through partial inlining using AVX-512 masked instructions In-Reply-To: <_0-zfIDPieC0Xnc17GaSSsS7Sz9EEUrfjRyqWDtphfU=.298bacde-f330-486a-8bea-03ff1523d00c@github.com> References: <_0-zfIDPieC0Xnc17GaSSsS7Sz9EEUrfjRyqWDtphfU=.298bacde-f330-486a-8bea-03ff1523d00c@github.com> Message-ID: On Wed, 23 Sep 2020 11:09:25 GMT, Nils Eliasson wrote: > Can you explain why 32 bytes are such a distinct performance cliff? > > Is there any performance difference between doing a single 64 bytes masked copy or two 32 bytes? Hi Nils, Copy for sizes <= 32 bytes can be done using one YMM register, AVX-512 vector length extension allows masked instructions to operate on YMM and XMM registers. Using newly added flag -XX:ArrayCopyPartialInlineSize=64 one can perform in-lining up to 64 bytes but since it will use a ZMM register CPU will operate at a lower frequency but it could still give better performance depending on the application. A single 64 byte masked copy may have a performance hit if for majority of the application runtime, CPU operates at highest frequency. There is a switchover penalty from higher frequency level to lower frequency level along with some hysteresis which forces subsequent instructions to operate a lower frequency for some cycles. Current implementation has been kept simple to avoid emitting too many instruction at call site considering arraycopy is a very high frequency operation. ------------- PR: https://git.openjdk.java.net/jdk/pull/302 From rehn at openjdk.java.net Wed Sep 23 15:34:21 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 15:34:21 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v4] In-Reply-To: References: Message-ID: > We simplify the vmThread by removing the queue and refactor the the main loop. > This solves the issues listed: > - It can create an extra safepoint directly after a safepoint. > - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. > - The exposure of the vm operation is dangerous if it's a handshake. > - The code is a hornets nest with the repetition of checks and branches > > Passes t1-8, and a benchmark run. > > If you want a smaller diff the commits contains the incremental progress and each commit passed t1. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Update after Shipilev ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/228/files - new: https://git.openjdk.java.net/jdk/pull/228/files/f590c6cb..3c0395bb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=228&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=228&range=02-03 Stats: 25 lines in 2 files changed: 7 ins; 4 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/228.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/228/head:pull/228 PR: https://git.openjdk.java.net/jdk/pull/228 From lucy at openjdk.java.net Wed Sep 23 15:36:38 2020 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 23 Sep 2020 15:36:38 GMT Subject: RFR: 8250635: MethodArityHistogram should use Compile_lock in favour of fancy checks In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 15:23:20 GMT, Tobias Hartmann wrote: >> This change was already fully reviewed before the Mercurial to Git transition. >> Reviewed-by: thartmann (TobiHartmann), mdoerr (TheRealMDoerr). > > Looks good. Thank you, Tobias and Martin, for reacting so promptly. Regards, Lutz From: Tobias Hartmann Reply to: openjdk/jdk Date: Wednesday, 23. September 2020 at 17:23 To: openjdk/jdk Cc: Lutz Schmidt , Mention Subject: Re: [openjdk/jdk] 8250635: MethodArityHistogram should use Compile_lock in favour of fancy checks (#321) @TobiHartmann approved this pull request. Looks good. ? You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. ------------- PR: https://git.openjdk.java.net/jdk/pull/321 From rehn at openjdk.java.net Wed Sep 23 15:38:16 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 15:38:16 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v4] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 15:25:36 GMT, Aleksey Shipilev wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after Shipilev > > src/hotspot/share/runtime/vmThread.cpp line 382: > >> 380: >> 381: VM_Operation* prev_vm_operation = NULL; >> 382: if (_cur_vm_operation!= NULL) { > > Whitespace before `!=`? Fixing! > src/hotspot/share/runtime/vmThread.hpp line 109: > >> 107: static VM_Operation::VMOp_Type vm_op_type() { >> 108: VM_Operation* op = vm_operation(); >> 109: assert (op != NULL, "sanity"); > > Should be no whitespace after `assert`? Fixing! ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From thomas.stuefe at gmail.com Wed Sep 23 15:38:56 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 23 Sep 2020 17:38:56 +0200 Subject: RFR: 8247910: Improve alignment and power-of-2 utilities using C++14 In-Reply-To: References: Message-ID: On Wed, Sep 23, 2020, 16:43 Kim Barrett wrote: > > On Sep 23, 2020, at 2:14 AM, Thomas St?fe > wrote: > > > > Hi, > > > > unfortunately this breaks my builds on Ubuntu 16.4. I am using gcc 5.4.0 > which according to https://openjdk.java.net/groups/build/doc/building.html > should still be an accepted compiler? > > > > Creating hotspot/variant-server/libjvm/gtest/gtestLauncher from 1 file(s) > > In file included from > /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/services/memTracker.hpp:85:0, > > from > /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/precompiled/precompiled.hpp:60: > > > /shared/projects/openjdk/jdk-jep387/source/src/hotspot/share/services/mallocTracker.hpp:190:78: > error: size of array '_snapshot' is not an integral constant-expression > > static size_t _snapshot[CALC_OBJ_SIZE_IN_TYPE(MallocMemorySnapshot, > size_t)]; > > I don?t see anything here to indicate what platform this is for. It?s > not, by any chance, arm32? > Sorry. No, plain old x64. Upgrading to gcc 7 also fixed another problem I had where the gtests would not be buildable for non-pch builds. So I guess gcc 5 support slowly bitrots. Unfortunately I do not have time to follow up on this. Maybe later. That is, Thomas From lucy at openjdk.java.net Wed Sep 23 15:41:36 2020 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 23 Sep 2020 15:41:36 GMT Subject: Integrated: 8250635: MethodArityHistogram should use Compile_lock in favour of fancy checks In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 14:41:57 GMT, Lutz Schmidt wrote: > This change was already fully reviewed before the Mercurial to Git transition. > Reviewed-by: thartmann (TobiHartmann), mdoerr (TheRealMDoerr). This pull request has now been integrated. Changeset: 0bc01da7 Author: Lutz Schmidt URL: https://git.openjdk.java.net/jdk/commit/0bc01da7 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod 8250635: MethodArityHistogram should use Compile_lock in favour of fancy checks Reviewed-by: mdoerr, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/321 From coleenp at openjdk.java.net Wed Sep 23 15:43:08 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 23 Sep 2020 15:43:08 GMT Subject: RFR: 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc Message-ID: These functions are also unused and in the thread_platform.hpp files. _last_Java_sp and _last_Java_fp are set in the assembly code for platforms that use these (x86, arm32 and aarch64). The shared runtime code never sets these, or should it. last_Java_fp() is always called through JavaFrameAnchor, so that function is not needed. last_Java_fp_offset() is used and needs to be in these platform dependent files because not all platforms save last_Java_fp. Tested with build on arm32 and tier1 on Oracle platforms including aarch64. ------------- Commit messages: - 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc Changes: https://git.openjdk.java.net/jdk/pull/324/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=324&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253539 Stats: 35 lines in 9 files changed: 0 ins; 28 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/324.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/324/head:pull/324 PR: https://git.openjdk.java.net/jdk/pull/324 From rehn at openjdk.java.net Wed Sep 23 15:43:09 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 15:43:09 GMT Subject: RFR: 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 15:12:57 GMT, Coleen Phillimore wrote: > These functions are also unused and in the thread_platform.hpp files. _last_Java_sp and _last_Java_fp are set in the > assembly code for platforms that use these (x86, arm32 and aarch64). The shared runtime code never sets these, or > should it. last_Java_fp() is always called through JavaFrameAnchor, so that function is not needed. > last_Java_fp_offset() is used and needs to be in these platform dependent files because not all platforms save > last_Java_fp. Tested with build on arm32 and tier1 on Oracle platforms including aarch64. Marked as reviewed by rehn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/324 From rehn at openjdk.java.net Wed Sep 23 15:43:45 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 15:43:45 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v4] In-Reply-To: References: Message-ID: <2jTE6zz4aOqiKx9CRncxM9qWJnt0yLim_ilT3cdd_D8=.ef5816c5-22bd-4852-a6be-6e35d5798b70@github.com> On Wed, 23 Sep 2020 15:35:27 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/vmThread.hpp line 109: >> >>> 107: static VM_Operation::VMOp_Type vm_op_type() { >>> 108: VM_Operation* op = vm_operation(); >>> 109: assert (op != NULL, "sanity"); >> >> Should be no whitespace after `assert`? > > Fixing! Fixing ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From ayang at openjdk.java.net Wed Sep 23 15:48:05 2020 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 23 Sep 2020 15:48:05 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v3] In-Reply-To: References: Message-ID: <6IokOfdx_1Sx_F5DisPJJTycPJ8CjdJsXzUlxUyMR_U=.c02a3059-c973-40d3-85d7-4e3925e7984c@github.com> On Wed, 23 Sep 2020 14:27:55 GMT, Stefan Karlsson wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Review: SteafanK CR 2 > > Marked as reviewed by stefank (Reviewer). Given names like `StackWatermarkSet::lowest_watermark`, I wonder if some diagrams could be provided in the code comments for `class StackWatermarks` so that readers will have the correct mental pictures of the layout of stack frames and watermarks. Some docs on `volatile uint32_t _state;` in `StackWatermark` would be nice, such as what info is encoded in this state, typical state transitions, who can access this state (tying it to volatile) etc. I wonder if it's possible to remove `bool _is_done;` in `StackWatermarkFramesIterator`; just calling `is_done()` on the underlying frame stream seems cleaner. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From rehn at openjdk.java.net Wed Sep 23 15:48:21 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 23 Sep 2020 15:48:21 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v5] In-Reply-To: References: Message-ID: > We simplify the vmThread by removing the queue and refactor the the main loop. > This solves the issues listed: > - It can create an extra safepoint directly after a safepoint. > - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. > - The exposure of the vm operation is dangerous if it's a handshake. > - The code is a hornets nest with the repetition of checks and branches > > Passes t1-8, and a benchmark run. > > If you want a smaller diff the commits contains the incremental progress and each commit passed t1. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Whitespace fixes, thanks to Shipilev ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/228/files - new: https://git.openjdk.java.net/jdk/pull/228/files/3c0395bb..85cf9001 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=228&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=228&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/228.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/228/head:pull/228 PR: https://git.openjdk.java.net/jdk/pull/228 From lucy at openjdk.java.net Wed Sep 23 16:35:36 2020 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 23 Sep 2020 16:35:36 GMT Subject: RFR: 8219586: CodeHeap State Analytics processes dead nmethods Message-ID: This change was already fully reviewed before the transition Mercurial to Git happened. Reviewed-by: thartmann (TobiHartmann), eosterlund (Git name unknown) ------------- Commit messages: - Backout JDK-8250635 - Merge branch 'JDK-8250635' into JDK-8219586 - JDK-8250635 tranferred from Mercurial - 8219586: CodeHeap State Analytics processes dead nmethods Changes: https://git.openjdk.java.net/jdk/pull/325/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=325&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8219586 Stats: 266 lines in 8 files changed: 111 ins; 53 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/325.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/325/head:pull/325 PR: https://git.openjdk.java.net/jdk/pull/325 From kvn at openjdk.java.net Wed Sep 23 16:41:46 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 23 Sep 2020 16:41:46 GMT Subject: RFR: 8253402: Convert vmSymbols::SID to enum class In-Reply-To: References: Message-ID: <2RctRAOHDMDgW1Qu57RDcOF1Uns4pjAZfR6Yg9dTb_0=.d3f1bcdd-39b8-4504-8f1a-76541bb5c55e@github.com> On Mon, 21 Sep 2020 07:07:25 GMT, Ioi Lam wrote: > Convert `vmSymbols::SID` to an `enum class` to provide better type safety. > > - The original enum type `vmSymbols::SID` cannot be forward-declared. I moved it out of the `vmSymbols` class and > renamed, so now it can be forward-declared as `enum class vmSymbolID : int;`, without including the large vmSymbols.hpp > file. > - This also breaks the mutual dependency between the `vmSymbols` and `vmIntrinsics` classes. Now the declaration of > `vmIntrinsics` can be moved from vmSymbols.hpp to vmIntrinsics.hpp, where it naturally belongs. > - Type-safe enumeration (contributed by Kim Barrett) > for (vmSymbolID index : vmSymbolsIterator()) { > vm_symbol_index[as_int(index)] = index; > } > - I moved `vmSymbols::_symbols[]` to `Symbol::_vm_symbols[]`, and made it accessible via `Symbol::vm_symbol_at()`. This > way, header files (e.g. fieldInfo.hpp) that need to convert from `vmSymbolID` to `Symbol*` don't need to include the > large vmSymbols.hpp file. > - I changed the `VM_SYMBOL_ENUM_NAME` macro so that the users don't need to explicitly add the `vmSymbolID::` scope. > - I removed many unnecessary casts between `int` and `vmSymbolID`. > - The remaining casts are done via `vmSymbol::as_int()` and `vmSymbols::as_SID()` with range checks. > > ----- > If this is successful, I will do the same for `vmIntrinsics::ID`. src/hotspot/share/ci/ciObjectFactory.hpp line 32: > 30: #include "utilities/growableArray.hpp" > 31: > 32: enum class vmSymbolID : int; Do you need this declaration to avoid #include "classfile/vmSymbols.hpp" ? ------------- PR: https://git.openjdk.java.net/jdk/pull/276 From stefank at openjdk.java.net Wed Sep 23 16:43:28 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 23 Sep 2020 16:43:28 GMT Subject: RFR: 8219586: CodeHeap State Analytics processes dead nmethods In-Reply-To: References: Message-ID: <9yYtCS3kFkxW_SryxZN3zd8jj_IoW3c5E_hBHCYb5fM=.d38b487a-d364-4f0a-b8ad-d4f19c61ae1e@github.com> On Wed, 23 Sep 2020 16:25:32 GMT, Lutz Schmidt wrote: > This change was already fully reviewed before the transition Mercurial to Git happened. > Reviewed-by: thartmann (TobiHartmann), eosterlund (Git name unknown) CC @fisk ------------- PR: https://git.openjdk.java.net/jdk/pull/325 From kvn at openjdk.java.net Wed Sep 23 16:44:26 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 23 Sep 2020 16:44:26 GMT Subject: RFR: 8253402: Convert vmSymbols::SID to enum class In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 07:07:25 GMT, Ioi Lam wrote: > Convert `vmSymbols::SID` to an `enum class` to provide better type safety. > > - The original enum type `vmSymbols::SID` cannot be forward-declared. I moved it out of the `vmSymbols` class and > renamed, so now it can be forward-declared as `enum class vmSymbolID : int;`, without including the large vmSymbols.hpp > file. > - This also breaks the mutual dependency between the `vmSymbols` and `vmIntrinsics` classes. Now the declaration of > `vmIntrinsics` can be moved from vmSymbols.hpp to vmIntrinsics.hpp, where it naturally belongs. > - Type-safe enumeration (contributed by Kim Barrett) > for (vmSymbolID index : vmSymbolsIterator()) { > vm_symbol_index[as_int(index)] = index; > } > - I moved `vmSymbols::_symbols[]` to `Symbol::_vm_symbols[]`, and made it accessible via `Symbol::vm_symbol_at()`. This > way, header files (e.g. fieldInfo.hpp) that need to convert from `vmSymbolID` to `Symbol*` don't need to include the > large vmSymbols.hpp file. > - I changed the `VM_SYMBOL_ENUM_NAME` macro so that the users don't need to explicitly add the `vmSymbolID::` scope. > - I removed many unnecessary casts between `int` and `vmSymbolID`. > - The remaining casts are done via `vmSymbol::as_int()` and `vmSymbols::as_SID()` with range checks. > > ----- > If this is successful, I will do the same for `vmIntrinsics::ID`. CI and JVMCI changes seem fine. I did not look in details on the rest. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/276 From iklam at openjdk.java.net Wed Sep 23 17:08:53 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 23 Sep 2020 17:08:53 GMT Subject: RFR: 8253402: Convert vmSymbols::SID to enum class In-Reply-To: <2RctRAOHDMDgW1Qu57RDcOF1Uns4pjAZfR6Yg9dTb_0=.d3f1bcdd-39b8-4504-8f1a-76541bb5c55e@github.com> References: <2RctRAOHDMDgW1Qu57RDcOF1Uns4pjAZfR6Yg9dTb_0=.d3f1bcdd-39b8-4504-8f1a-76541bb5c55e@github.com> Message-ID: On Wed, 23 Sep 2020 16:38:39 GMT, Vladimir Kozlov wrote: >> Convert `vmSymbols::SID` to an `enum class` to provide better type safety. >> >> - The original enum type `vmSymbols::SID` cannot be forward-declared. I moved it out of the `vmSymbols` class and >> renamed, so now it can be forward-declared as `enum class vmSymbolID : int;`, without including the large vmSymbols.hpp >> file. >> - This also breaks the mutual dependency between the `vmSymbols` and `vmIntrinsics` classes. Now the declaration of >> `vmIntrinsics` can be moved from vmSymbols.hpp to vmIntrinsics.hpp, where it naturally belongs. >> - Type-safe enumeration (contributed by Kim Barrett) >> for (vmSymbolID index : vmSymbolsIterator()) { >> vm_symbol_index[as_int(index)] = index; >> } >> - I moved `vmSymbols::_symbols[]` to `Symbol::_vm_symbols[]`, and made it accessible via `Symbol::vm_symbol_at()`. This >> way, header files (e.g. fieldInfo.hpp) that need to convert from `vmSymbolID` to `Symbol*` don't need to include the >> large vmSymbols.hpp file. >> - I changed the `VM_SYMBOL_ENUM_NAME` macro so that the users don't need to explicitly add the `vmSymbolID::` scope. >> - I removed many unnecessary casts between `int` and `vmSymbolID`. >> - The remaining casts are done via `vmSymbol::as_int()` and `vmSymbols::as_SID()` with range checks. >> >> ----- >> If this is successful, I will do the same for `vmIntrinsics::ID`. > > src/hotspot/share/ci/ciObjectFactory.hpp line 32: > >> 30: #include "utilities/growableArray.hpp" >> 31: >> 32: enum class vmSymbolID : int; > > Do you need this declaration to avoid #include "classfile/vmSymbols.hpp" ? Yes, that's the intention, because vmSymbols.hpp is big. I am thinking whether I should move such forward declarations of enums into globalDefinitions.hpp, so header files that use `vmSymbolID` don't need to know that the base type is `int`. ------------- PR: https://git.openjdk.java.net/jdk/pull/276 From github.com+4346215+chumer at openjdk.java.net Wed Sep 23 18:22:25 2020 From: github.com+4346215+chumer at openjdk.java.net (Christian Humer) Date: Wed, 23 Sep 2020 18:22:25 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> Message-ID: On Wed, 23 Sep 2020 12:19:52 GMT, Erik ?sterlund wrote: >>> > > I would like to hear answer to @dholmes-ora question in JBS: >>> > > "Do we really need yet another stack dumping interface in the VM? Why isn't a debugger using JVM TI?" >>> > >>> > >>> > One reason for having both the new getStackFrames API (set of threads) as well as the existing iterateFrames (current >>> > thread only) API in JVMCI is that Truffle would want a deopt-free read-only view of the values in a frame, which to the >>> > best of our knowledge is not possible through JVMTI. Only in rare cases, materialization of frames is required, so it >>> > boils down to the performance hit caused by deopting frames, which is even more of a concern with a set of threads than >>> > for the single current thread case. Another potential issue with a JVMTI-based approach is that there might be other >>> > drawbacks to having an always-on (or even late attached) JVMTI agent in a GraalVM? >>> >>> 1. You are describing that the main reason is performance. But you also say this is to be used by a debugger? So, not >>> sure performance as a primary motive really makes sense then. Not sure why performance of debugging Truffle must be so >>> much faster than debugging Java code (which I have not heard anyone complain about). And if this really was an actual >>> performance problem, it seems like we would want a generic fix then, not a special Truffle stack walker for debugging >>> Truffle code alone, to be maintained separately. 2. We are talking about JVMTI, not JVMCI. iterateFrames is defined in >>> JVMCI, and that is something completely different, which I don't think any of us had in mind. It seems indeed to be >>> limited to the current frame. I'm talking about e.g. JVMTI GetStackTrace and the JVMTI GetLocal* functions. It gives >>> you a stack trace for any thread (not just the current one), and allows you to retrieve locals. 3. When you just read >>> locals, (as you describe is your use case), there is no need to deoptimize anything. So yeah, that's just not something >>> we do, unless you change the locals, which you said you are not. Please let me know if there is anything I missed. But >>> so far it seems to me that the mentioned JVMTI functionality is all you really need for a debugger. What did I miss? I >>> would like to better understand the problem domain before taking this further. >> >> Thanks for your quick follow-up. >> >> 1. It's not entirely made for the debugger use-case. For example in some guest languages we need this for implementing >> Thread#getStackTrace or similar. In Espresso (Java as a Truffle guest language) we would need this also for >> implementing part of the management API. 2. I know that you suggested JVMTI and no JVMCI. Since I wasn't around when >> the decision to implement and include iterateFrames into JVMCI was made, I'm unaware of the exact reasoning behind that >> decision. I was assuming that whatever reason not to go with JVMTI back then would still hold true today. So say we >> wanted to adopt the JVMTI approach now. Would the design be an in-process always on and in-process JVMTI agent? Would >> there be security implications from such an approach leaving any VM running anything Truffle more vulnerable? 3. No >> need for deoptimize anything when reading locals through JVMTI is good. Thanks for clarifying that. > >> > > > I would like to hear answer to @dholmes-ora question in JBS: >> > > > "Do we really need yet another stack dumping interface in the VM? Why isn't a debugger using JVM TI?" >> > > >> > > >> > > One reason for having both the new getStackFrames API (set of threads) as well as the existing iterateFrames (current >> > > thread only) API in JVMCI is that Truffle would want a deopt-free read-only view of the values in a frame, which to the >> > > best of our knowledge is not possible through JVMTI. Only in rare cases, materialization of frames is required, so it >> > > boils down to the performance hit caused by deopting frames, which is even more of a concern with a set of threads than >> > > for the single current thread case. Another potential issue with a JVMTI-based approach is that there might be other >> > > drawbacks to having an always-on (or even late attached) JVMTI agent in a GraalVM? >> > >> > >> > >> > 1. You are describing that the main reason is performance. But you also say this is to be used by a debugger? So, not >> > sure performance as a primary motive really makes sense then. Not sure why performance of debugging Truffle must be so >> > much faster than debugging Java code (which I have not heard anyone complain about). And if this really was an actual >> > performance problem, it seems like we would want a generic fix then, not a special Truffle stack walker for debugging >> > Truffle code alone, to be maintained separately. 2. We are talking about JVMTI, not JVMCI. iterateFrames is defined in >> > JVMCI, and that is something completely different, which I don't think any of us had in mind. It seems indeed to be >> > limited to the current frame. I'm talking about e.g. JVMTI GetStackTrace and the JVMTI GetLocal* functions. It gives >> > you a stack trace for any thread (not just the current one), and allows you to retrieve locals. 3. When you just read >> > locals, (as you describe is your use case), there is no need to deoptimize anything. So yeah, that's just not something >> > we do, unless you change the locals, which you said you are not. Please let me know if there is anything I missed. But >> > so far it seems to me that the mentioned JVMTI functionality is all you really need for a debugger. What did I miss? I >> > would like to better understand the problem domain before taking this further. >> >> Thanks for your quick follow-up. >> >> 1. It's not entirely made for the debugger use-case. For example in some guest languages we need this for implementing >> Thread#getStackTrace or similar. In Espresso (Java as a Truffle guest language) we would need this also for >> implementing part of the management API. >> >> 2. I know that you suggested JVMTI and no JVMCI. Since I wasn't around when the decision to implement and include >> iterateFrames into JVMCI was made, I'm unaware of the exact reasoning behind that decision. I was assuming that >> whatever reason not to go with JVMTI back then would still hold true today. So say we wanted to adopt the JVMTI >> approach now. Would the design be an in-process always on and in-process JVMTI agent? Would there be security >> implications from such an approach leaving any VM running anything Truffle more vulnerable? >> >> 3. No need for deoptimize anything when reading locals through JVMTI is good. Thanks for clarifying that. > > So I understand it, you really have 2 cases: > 1) Using the debugger > 2) To support other APIs that need a stack trace > > So if you use JVMTI for the debugging (like everybody else), that seems to be a solved problem. > As for the second use case, I hope you can use java.lang.StackWalker? It should give you all the info you could dream > of. If you can't use all classes in java.lang.* then I fear that you are in a lot of trouble using HotSpot in general. Tuning in to provide some background on why Truffle needs this and why we spent a lot of time to stabilize this PR. If we could have gone a different route we would have. Truffle introduces the separation of guest and host language. As host language, we understand the Java host VM. This is either HotSpot (relevant for this PR) or SubstrateVM (Native Image). Guest languages are interpreters implemented on top of Truffle, like JavaScript, Ruby, or Python, but also Espresso our Java implementation based on Truffle. Truffle uses Graal and JVMCI to optimize these guest languages to optimized machine code using a technique called the first Futamura projection. This Graal compilation is limited to JDKs that provide JVMCI APIs. In Truffle we use the notion of guest and host stack frames. Guest stack frames represent a method activation in the guest language and host stack frames represent host Java method activations. A guest stack frame entry consists of the call location (Node) and guest frame (VirtualFrame) that contains the guest local variables. Truffle languages need to access guest frames of the current thread to construct a stack trace or to lazily access variables in a parent guest frame. There are two techniques to do this: 1. Have a separate stack data structure on the heap that keeps track of the guest frames for each thread. 2. Walk the alive local variables in Java host frames to access the guest frame and node call location. We use the technique (1) to implement Truffle guest stack traces on a JVM without JVMCI support. This is pretty simple and allows us to walk the guest stack for any thread we need. But, there are downsides with this though: * For each method invocation we have additional overhead for writing the external data structure. * The frame always escapes the current compilation scope and can therefore not be escape analyzed by Graal. Both of these issues are deal-breakers, performance-wise. With Truffle we want to be competitive with other specialized VMs, so technique (1) is not good enough. JVMCI exposes stack walking APIs for Truffle that allows us to access the host frame local variables of the current thread. This allows us to lazily reconstruct the guest frames from the host frames from certain known and alive local variables. We also have special logic to reconstruct read-only guest frames from optimized Truffle+Graal compiled methods without the need to invalidate the optimized code. We are using the technique (2) successfully for many years, but now with the growing maturity of Truffle we have new requirements: 1. We need to be able to walk all the root pointers of a guest language. This includes all active guest frames. This is needed to allow languages to walk all alive objects (e.g. Ruby needs that) and to compute the retained size of a truffle guest language context. 2. We need to be able to read locals from other threads to produce the guest stack trace of other threads in the Truffle debugger. This was not a big issue before, because we were mostly dealing with single-threaded languages (JavaScript). The Truffle debugger should not be confused with the Java host debugger. The Truffle debugger works based on the Truffle instrumentation framework and cannot debug Java host code. It only shows guest stack frames and statements and is entirely agnostic to which Java methods were used to implement it and on which Java VM it runs on. It is entirely built with Java, without the use of JVMTI, this allows us to debug guest code without having the Java debugger attached. It allows us to on-demand enable debugging in a production scenario when it is needed and only for a guest context that needs it without slowing down others (e.g. in an app server). Truffle debugging works on SubstrateVM (native-image) which has currently no support for JVMTI. Enabling and not using the debugger also comes without any peak performance overhead (some memory and warmup overhead). To summarize: 1. We cannot use the StackWalker API as it does not allow us to access the local variables we need. 2. We cannot manually push/pop guest language frames, as this would be too bad for performance. 3. We cannot use JVMTI because: 3a. We need it to implement language features, not just debugger features. 3b. There is no way to enable it on demand for an individual guest application (we run multiple guest applications per host VM). 3c. Using JVMTI would slow down the host VM. Therefore our best idea was to introduce this new JVMCI API. We are of course open to other suggestions, if they solve our problem. This is also not an entirely new feature, this PR is an extension to the existing JVMCI functionality to walk the stack frames with local variable access. I hope these clarifications were helpful. ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From kustos at gmx.net Wed Sep 23 18:40:22 2020 From: kustos at gmx.net (Philippe Marschall) Date: Wed, 23 Sep 2020 20:40:22 +0200 Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On 22.09.20 10:45, Erik Gahlin wrote: > On Sat, 12 Sep 2020 00:19:00 GMT, Vladimir Kozlov wrote: > >>> Philippe Marschall has refreshed the contents of this pull request, and previous commits have been removed. The >>> incremental views will show differences compared to the previous content of the PR. The pull request contains one new >>> commit since the last revision: >>> 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate >> >> Marked as reviewed by kvn (Reviewer). > > Have you run the JFR tests in test/jdk/jdk/jfr? I initially did not but now I have. jdk.jfr.event.runtime.TestModuleEvents was failing, I have updated it to what makes sense to me. Cheers Philippe From github.com+471021+marschall at openjdk.java.net Wed Sep 23 18:41:06 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Wed, 23 Sep 2020 18:41:06 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5] In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate ------------- Changes: https://git.openjdk.java.net/jdk/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=04 Stats: 749 lines in 65 files changed: 149 ins; 149 del; 451 mod Patch: https://git.openjdk.java.net/jdk/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk/pull/45 From kustos at gmx.net Wed Sep 23 18:42:59 2020 From: kustos at gmx.net (Philippe Marschall) Date: Wed, 23 Sep 2020 20:42:59 +0200 Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On 23.09.20 07:13, David Holmes wrote: > On Tue, 22 Sep 2020 08:43:04 GMT, Erik Gahlin wrote: > >>> Marked as reviewed by kvn (Reviewer). >> >> Have you run the JFR tests in test/jdk/jdk/jfr? > > @marschall Please do not force-push anything as it breaks the commit history in the PR and renders previous > reviews/comments obsolete. There is no way for the reviewers to see what changed between the commit they reviewed and > the commit now in the PR. > > To update to latest changes you should have just merged your branch with your (up-to-date) local master, committed that > merge in your local branch and then pushed that commit to your Personal Fork. The skara tooling will flatten the series > of commits in a PR into one single well-formed commit that is pushed to the master branch of the repo. My apologies, I was not aware of this, I won't make this mistake in the future again. I don't assume there is a way to fix this now. Philippe From kvn at openjdk.java.net Wed Sep 23 18:55:29 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 23 Sep 2020 18:55:29 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Wed, 23 Sep 2020 18:41:06 GMT, Philippe Marschall wrote: >> Hello, newbie here >> >> I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. >> >> - I tried to update the copyright year to 2020 in every file. >> - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. >> - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of >> imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. >> - All tier1 tests pass. >> - One jpackage/jlink tier2 test fails but I don't believe it is related. >> - Some tier3 Swing tests fail but I don't think they are related. > > Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains one commit: > 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate Update seems fine. Thanks for JFR testing and fixing. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/45 From eosterlund at openjdk.java.net Wed Sep 23 18:57:02 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 23 Sep 2020 18:57:02 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> Message-ID: On Wed, 23 Sep 2020 18:16:11 GMT, Christian Humer wrote: >>> > > > I would like to hear answer to @dholmes-ora question in JBS: >>> > > > "Do we really need yet another stack dumping interface in the VM? Why isn't a debugger using JVM TI?" >>> > > >>> > > >>> > > One reason for having both the new getStackFrames API (set of threads) as well as the existing iterateFrames (current >>> > > thread only) API in JVMCI is that Truffle would want a deopt-free read-only view of the values in a frame, which to the >>> > > best of our knowledge is not possible through JVMTI. Only in rare cases, materialization of frames is required, so it >>> > > boils down to the performance hit caused by deopting frames, which is even more of a concern with a set of threads than >>> > > for the single current thread case. Another potential issue with a JVMTI-based approach is that there might be other >>> > > drawbacks to having an always-on (or even late attached) JVMTI agent in a GraalVM? >>> > >>> > >>> > >>> > 1. You are describing that the main reason is performance. But you also say this is to be used by a debugger? So, not >>> > sure performance as a primary motive really makes sense then. Not sure why performance of debugging Truffle must be so >>> > much faster than debugging Java code (which I have not heard anyone complain about). And if this really was an actual >>> > performance problem, it seems like we would want a generic fix then, not a special Truffle stack walker for debugging >>> > Truffle code alone, to be maintained separately. 2. We are talking about JVMTI, not JVMCI. iterateFrames is defined in >>> > JVMCI, and that is something completely different, which I don't think any of us had in mind. It seems indeed to be >>> > limited to the current frame. I'm talking about e.g. JVMTI GetStackTrace and the JVMTI GetLocal* functions. It gives >>> > you a stack trace for any thread (not just the current one), and allows you to retrieve locals. 3. When you just read >>> > locals, (as you describe is your use case), there is no need to deoptimize anything. So yeah, that's just not something >>> > we do, unless you change the locals, which you said you are not. Please let me know if there is anything I missed. But >>> > so far it seems to me that the mentioned JVMTI functionality is all you really need for a debugger. What did I miss? I >>> > would like to better understand the problem domain before taking this further. >>> >>> Thanks for your quick follow-up. >>> >>> 1. It's not entirely made for the debugger use-case. For example in some guest languages we need this for implementing >>> Thread#getStackTrace or similar. In Espresso (Java as a Truffle guest language) we would need this also for >>> implementing part of the management API. >>> >>> 2. I know that you suggested JVMTI and no JVMCI. Since I wasn't around when the decision to implement and include >>> iterateFrames into JVMCI was made, I'm unaware of the exact reasoning behind that decision. I was assuming that >>> whatever reason not to go with JVMTI back then would still hold true today. So say we wanted to adopt the JVMTI >>> approach now. Would the design be an in-process always on and in-process JVMTI agent? Would there be security >>> implications from such an approach leaving any VM running anything Truffle more vulnerable? >>> >>> 3. No need for deoptimize anything when reading locals through JVMTI is good. Thanks for clarifying that. >> >> So I understand it, you really have 2 cases: >> 1) Using the debugger >> 2) To support other APIs that need a stack trace >> >> So if you use JVMTI for the debugging (like everybody else), that seems to be a solved problem. >> As for the second use case, I hope you can use java.lang.StackWalker? It should give you all the info you could dream >> of. If you can't use all classes in java.lang.* then I fear that you are in a lot of trouble using HotSpot in general. > > Tuning in to provide some background on why Truffle needs this and why we spent a lot of time to stabilize this PR. If > we could have gone a different route we would have. > Truffle introduces the separation of guest and host language. As host language, we understand the Java host VM. This is > either HotSpot (relevant for this PR) or SubstrateVM (Native Image). Guest languages are interpreters implemented on > top of Truffle, like JavaScript, Ruby, or Python, but also Espresso our Java implementation based on Truffle. Truffle > uses Graal and JVMCI to optimize these guest languages to optimized machine code using a technique called the first > Futamura projection. This Graal compilation is limited to JDKs that provide JVMCI APIs. In Truffle we use the notion > of guest and host stack frames. Guest stack frames represent a method activation in the guest language and host stack > frames represent host Java method activations. A guest stack frame entry consists of the call location (Node) and guest > frame (VirtualFrame) that contains the guest local variables. Truffle languages need to access guest frames of the > current thread to construct a stack trace or to lazily access variables in a parent guest frame. There are two > techniques to do this: 1. Have a separate stack data structure on the heap that keeps track of the guest frames for > each thread. 2. Walk the alive local variables in Java host frames to access the guest frame and node call location. > We use the technique (1) to implement Truffle guest stack traces on a JVM without JVMCI support. This is pretty simple > and allows us to walk the guest stack for any thread we need. But, there are downsides with this though: > * For each method invocation we have additional overhead for writing the external data structure. > * The frame always escapes the current compilation scope and can therefore not be escape analyzed by Graal. > > Both of these issues are deal-breakers, performance-wise. With Truffle we want to be competitive with other specialized > VMs, so technique (1) is not good enough. JVMCI exposes stack walking APIs for Truffle that allows us to access the > host frame local variables of the current thread. This allows us to lazily reconstruct the guest frames from the host > frames from certain known and alive local variables. We also have special logic to reconstruct read-only guest frames > from optimized Truffle+Graal compiled methods without the need to invalidate the optimized code. We are using the > technique (2) successfully for many years, but now with the growing maturity of Truffle we have new requirements: 1. > We need to be able to walk all the root pointers of a guest language. This includes all active guest frames. This is > needed to allow languages to walk all alive objects (e.g. Ruby needs that) and to compute the retained size of a > truffle guest language context. 2. We need to be able to read locals from other threads to produce the guest stack > trace of other threads in the Truffle debugger. This was not a big issue before, because we were mostly dealing with > single-threaded languages (JavaScript). The Truffle debugger should not be confused with the Java host debugger. The > Truffle debugger works based on the Truffle instrumentation framework and cannot debug Java host code. It only shows > guest stack frames and statements and is entirely agnostic to which Java methods were used to implement it and on which > Java VM it runs on. It is entirely built with Java, without the use of JVMTI, this allows us to debug guest code > without having the Java debugger attached. It allows us to on-demand enable debugging in a production scenario when it > is needed and only for a guest context that needs it without slowing down others (e.g. in an app server). Truffle > debugging works on SubstrateVM (native-image) which has currently no support for JVMTI. Enabling and not using the > debugger also comes without any peak performance overhead (some memory and warmup overhead). To summarize: 1. We > cannot use the StackWalker API as it does not allow us to access the local variables we need. 2. We cannot manually > push/pop guest language frames, as this would be too bad for performance. 3. We cannot use JVMTI because: 3a. We need > it to implement language features, not just debugger features. 3b. There is no way to enable it on demand for an > individual guest application (we run multiple guest applications per host VM). 3c. Using JVMTI would slow down the > host VM. Therefore our best idea was to introduce this new JVMCI API. We are of course open to other suggestions, if > they solve our problem. This is also not an entirely new feature, this PR is an extension to the existing JVMCI > functionality to walk the stack frames with local variable access. I hope these clarifications were helpful. java.lang.StackWalker does expose locals as well. What am I missing? ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From minqi at openjdk.java.net Wed Sep 23 19:22:06 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 23 Sep 2020 19:22:06 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive In-Reply-To: References: Message-ID: On Wed, 16 Sep 2020 19:01:18 GMT, Ioi Lam wrote: >> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous >> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the >> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses >> function. Tests: tier1-4 > > src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 67: > >> 65: if (VM.isDumpLoadedClassListSetAndOpen) { >> 66: VM.cdsTraceResolve(traceLF); >> 67: } > > GenerateJLIClassesHelper shouldn't need to know why the trace is needed. Also, "cdsTraceResolve" is too generic. > > I think it's better to have > if (TRACE_RESOLVE || VM.CDS_TRACE_JLINV_RESOLVE) { > ... > VM.cdsTraceJLINVResolve(traceLF); > > The acronym JLINV is used in > [methodHandles.cpp](https://github.com/openjdk/jdk/blob/ce93cbce77e1f4baa52676826c8ae27d474360b6/src/hotspot/share/prims/methodHandles.cpp#L1524) With CDS related code moved to CDS.java, I think we should keep TRACE_RESOLVE here. A new name like suggested by Mandy, logTraceResolve in CDS.java > src/java.base/share/classes/jdk/internal/misc/VM.java line 490: > >> 488: */ >> 489: public static boolean isDumpLoadedClassListSetAndOpen; >> 490: private static native boolean isDumpLoadedClassListSetAndOpen0(); > > I would suggest to rename to `isDumpingLoadedClassList` Will change. ------------- PR: https://git.openjdk.java.net/jdk/pull/193 From dnsimon at openjdk.java.net Wed Sep 23 19:31:37 2020 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 23 Sep 2020 19:31:37 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> Message-ID: <-oU_AT5DuFwfL-rgxqGIrN7pAL0NPWzlrgPewnfTCyw=.6a50f1a0-a089-47b7-9687-68da101d5206@github.com> On Wed, 23 Sep 2020 18:54:33 GMT, Erik ?sterlund wrote: >> Tuning in to provide some background on why Truffle needs this and why we spent a lot of time to stabilize this PR. If >> we could have gone a different route we would have. >> Truffle introduces the separation of guest and host language. As host language, we understand the Java host VM. This is >> either HotSpot (relevant for this PR) or SubstrateVM (Native Image). Guest languages are interpreters implemented on >> top of Truffle, like JavaScript, Ruby, or Python, but also Espresso our Java implementation based on Truffle. Truffle >> uses Graal and JVMCI to optimize these guest languages to optimized machine code using a technique called the first >> Futamura projection. This Graal compilation is limited to JDKs that provide JVMCI APIs. In Truffle we use the notion >> of guest and host stack frames. Guest stack frames represent a method activation in the guest language and host stack >> frames represent host Java method activations. A guest stack frame consists of the caller location and guest local >> variables. Truffle languages need to access guest frames of the current thread to construct a stack trace or to lazily >> access variables in a parent guest frame. There are two techniques to do this: 1. Have a separate stack data structure >> on the heap that keeps track of the guest frames for each thread. 2. Walk the live local variables in Java host frames >> to access the guest frame and caller location. We use the technique (1) to implement Truffle guest stack traces on a >> JVM without JVMCI support. This is pretty simple and allows us to walk the guest stack for any thread we need. But, >> there are downsides with this: >> * For each method invocation we have additional overhead for maintaining the extra heap data structure. >> * The frame object always escapes the current compilation scope and can therefore not be escape analyzed by Graal. >> >> Both of these issues are deal-breakers, performance-wise. With Truffle we want to be competitive with other specialized >> VMs, so technique (1) is not good enough. JVMCI currently exposes stack walking APIs for Truffle that allows us to >> access the host frame local variables of the current thread. This allows us to lazily reconstruct the guest frames from >> the host frames from certain known and live local variables. We also have special logic to reconstruct read-only guest >> frames from optimized Truffle+Graal compiled methods without the need to invalidate the optimized code. We are using >> the technique (2) successfully for many years, but now with the growing maturity of Truffle we have new requirements: >> 1. We need to be able to walk all the root pointers of a guest language. This includes all active guest frames. This is >> needed to allow languages to walk all live objects (e.g. Ruby needs that) and to compute the size of the live objects >> of a truffle language. 2. We need to be able to read locals from other threads to produce the guest stack trace of >> other threads in the Truffle debugger. This was not a big issue before, because we were mostly dealing with >> single-threaded languages (JavaScript). The Truffle debugger should not be confused with the Java host debugger. The >> Truffle debugger works based on the Truffle instrumentation framework and cannot debug Java host code. It only shows >> guest stack frames and statements and is entirely agnostic to which Java methods were used to implement it and on which >> Java VM it runs on. It is entirely built with Java, without the use of JVMTI, this allows us to debug guest code >> without having the Java debugger attached. It allows us to on-demand enable debugging in a production scenario when it >> is needed and only for a guest language instance that needs it without slowing down other code in host VM (e.g. in an >> app server). Truffle debugging works on SubstrateVM (native-image) which has currently no support for JVMTI. Enabling >> and not using the debugger also comes without any peak performance overhead (some memory and warmup overhead). To >> summarize: 1. We cannot use the StackWalker API as it does not allow us to access local variables. 2. We cannot >> manually allocate extra objects for guest language frames, as this would hurt performance. 3. We cannot use JVMTI >> because: 3a. We need it to implement language features, not just debugger features. 3b. There is no way to enable it on >> demand for an individual guest application (we run multiple guest applications per host VM). 3c. There is no Java API >> that allows it be used in the same process. Therefore our best idea was to introduce this new JVMCI API. We are of >> course open to other suggestions, if they solve our problem. This is also not an entirely new feature, this PR is an >> extension to the existing JVMCI functionality to walk the stack frames with local variable access. I hope these >> clarifications were helpful. > > java.lang.StackWalker does expose locals as well. What am I missing? It seems as though the `java.lang.LiveStackFrame` and `java.lang.LiveStackFrameInfo` classes are not public. However, it may indeed provide what's needed for the Truffle use cases. Do you know how/where this internal interface is used currently? In any case, the Truffle team will investigate further before coming back to this pull request. Thanks for bringing up what may be a much simpler solution @fisk . ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From dnsimon at openjdk.java.net Wed Sep 23 19:56:49 2020 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 23 Sep 2020 19:56:49 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> Message-ID: <_luUft9Qs0GYU6GwUs1PLMDGel1salhJg8XGxsc3h0k=.c175a93b-0736-4549-8316-ac01692f6b9e@github.com> On Wed, 23 Sep 2020 18:54:33 GMT, Erik ?sterlund wrote: >> Tuning in to provide some background on why Truffle needs this and why we spent a lot of time to stabilize this PR. If >> we could have gone a different route we would have. >> Truffle introduces the separation of guest and host language. As host language, we understand the Java host VM. This is >> either HotSpot (relevant for this PR) or SubstrateVM (Native Image). Guest languages are interpreters implemented on >> top of Truffle, like JavaScript, Ruby, or Python, but also Espresso our Java implementation based on Truffle. Truffle >> uses Graal and JVMCI to optimize these guest languages to optimized machine code using a technique called the first >> Futamura projection. This Graal compilation is limited to JDKs that provide JVMCI APIs. In Truffle we use the notion >> of guest and host stack frames. Guest stack frames represent a method activation in the guest language and host stack >> frames represent host Java method activations. A guest stack frame consists of the caller location and guest local >> variables. Truffle languages need to access guest frames of the current thread to construct a stack trace or to lazily >> access variables in a parent guest frame. There are two techniques to do this: 1. Have a separate stack data structure >> on the heap that keeps track of the guest frames for each thread. 2. Walk the live local variables in Java host frames >> to access the guest frame and caller location. We use the technique (1) to implement Truffle guest stack traces on a >> JVM without JVMCI support. This is pretty simple and allows us to walk the guest stack for any thread we need. But, >> there are downsides with this: >> * For each method invocation we have additional overhead for maintaining the extra heap data structure. >> * The frame object always escapes the current compilation scope and can therefore not be escape analyzed by Graal. >> >> Both of these issues are deal-breakers, performance-wise. With Truffle we want to be competitive with other specialized >> VMs, so technique (1) is not good enough. JVMCI currently exposes stack walking APIs for Truffle that allows us to >> access the host frame local variables of the current thread. This allows us to lazily reconstruct the guest frames from >> the host frames from certain known and live local variables. We also have special logic to reconstruct read-only guest >> frames from optimized Truffle+Graal compiled methods without the need to invalidate the optimized code. We are using >> the technique (2) successfully for many years, but now with the growing maturity of Truffle we have new requirements: >> 1. We need to be able to walk all the root pointers of a guest language. This includes all active guest frames. This is >> needed to allow languages to walk all live objects (e.g. Ruby needs that) and to compute the size of the live objects >> of a truffle language. 2. We need to be able to read locals from other threads to produce the guest stack trace of >> other threads in the Truffle debugger. This was not a big issue before, because we were mostly dealing with >> single-threaded languages (JavaScript). The Truffle debugger should not be confused with the Java host debugger. The >> Truffle debugger works based on the Truffle instrumentation framework and cannot debug Java host code. It only shows >> guest stack frames and statements and is entirely agnostic to which Java methods were used to implement it and on which >> Java VM it runs on. It is entirely built with Java, without the use of JVMTI, this allows us to debug guest code >> without having the Java debugger attached. It allows us to on-demand enable debugging in a production scenario when it >> is needed and only for a guest language instance that needs it without slowing down other code in host VM (e.g. in an >> app server). Truffle debugging works on SubstrateVM (native-image) which has currently no support for JVMTI. Enabling >> and not using the debugger also comes without any peak performance overhead (some memory and warmup overhead). To >> summarize: 1. We cannot use the StackWalker API as it does not allow us to access local variables. 2. We cannot >> manually allocate extra objects for guest language frames, as this would hurt performance. 3. We cannot use JVMTI >> because: 3a. We need it to implement language features, not just debugger features. 3b. There is no way to enable it on >> demand for an individual guest application (we run multiple guest applications per host VM). 3c. There is no Java API >> that allows it be used in the same process. Therefore our best idea was to introduce this new JVMCI API. We are of >> course open to other suggestions, if they solve our problem. This is also not an entirely new feature, this PR is an >> extension to the existing JVMCI functionality to walk the stack frames with local variable access. I hope these >> clarifications were helpful. > > java.lang.StackWalker does expose locals as well. What am I missing? @fisk @coleenp , it appears as though StackWalker can only be used for the current thread. Am I missing some other, potentially internal, API that extends StackWalker to work on other threads? ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From egahlin at openjdk.java.net Wed Sep 23 20:05:14 2020 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 23 Sep 2020 20:05:14 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Wed, 23 Sep 2020 18:41:06 GMT, Philippe Marschall wrote: >> Hello, newbie here >> >> I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. >> >> - I tried to update the copyright year to 2020 in every file. >> - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. >> - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of >> imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. >> - All tier1 tests pass. >> - One jpackage/jlink tier2 test fails but I don't believe it is related. >> - Some tier3 Swing tests fail but I don't think they are related. > > Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains one commit: > 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From eosterlund at openjdk.java.net Wed Sep 23 20:13:21 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 23 Sep 2020 20:13:21 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: <_luUft9Qs0GYU6GwUs1PLMDGel1salhJg8XGxsc3h0k=.c175a93b-0736-4549-8316-ac01692f6b9e@github.com> References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> <_luUft9Qs0GYU6GwUs1PLMDGel1salhJg8X Gxsc3h0k=.c175a93b-0736-4549-8316-ac01692f6b9e@github.com> Message-ID: <9tn1QTeKWk7DB7fWgyw7O_PSuN5Y7nTUmvvZSuuWqHM=.e9a7dbbe-c8ec-40eb-aee4-74e08892db08@github.com> On Wed, 23 Sep 2020 19:54:11 GMT, Doug Simon wrote: >> java.lang.StackWalker does expose locals as well. What am I missing? > > @fisk @coleenp , it appears as though StackWalker can only be used for the current thread. Am I missing some other, > potentially internal, API that extends StackWalker to allow one thread to walk the stack of another thread? You are right; the java.lang.StackWalker does not have a thread parameter. If one is needed, I imagine we can add one (using a handshake). However, I was under the impression that only the debugger case needed this for other remote threads, in which case JVMTI seems like the natural solution. So yeah, is the non-debug case in need of remote stack traces with locals? ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From dnsimon at openjdk.java.net Wed Sep 23 20:26:11 2020 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 23 Sep 2020 20:26:11 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: <9tn1QTeKWk7DB7fWgyw7O_PSuN5Y7nTUmvvZSuuWqHM=.e9a7dbbe-c8ec-40eb-aee4-74e08892db08@github.com> References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> <_luUft9Qs0GYU6GwUs1PLMDGel1salhJg8X Gxsc3h0k=.c175a93b-0736-4549-8316-ac01692f6b9e@github.com> <9tn1QTeKWk7DB7fWgyw7O_PSuN5Y7nTUmvvZSuuWqHM=.e9a7dbbe-c8ec-40eb-aee4-74e08892db08@github.com> Message-ID: On Wed, 23 Sep 2020 20:10:37 GMT, Erik ?sterlund wrote: >> @fisk @coleenp , it appears as though StackWalker can only be used for the current thread. Am I missing some other, >> potentially internal, API that extends StackWalker to allow one thread to walk the stack of another thread? > > You are right; the java.lang.StackWalker does not have a thread parameter. If one is needed, I imagine we can add one > (using a handshake). However, I was under the impression that only the debugger case needed this for other remote > threads, in which case JVMTI seems like the natural solution. So yeah, is the non-debug case in need of remote stack > traces with locals? I'll let @chumer answer that question. However, I have another one of my own. As far as I can see, the only use of `java.lang.LiveStackFrame` and `java.lang.LiveStackFrameInfo` in the JDK code base are in the [LocalsAndOperands](https://github.com/openjdk/jdk/blob/6bab0f539fba8fb441697846347597b4a0ade428/test/jdk/java/lang/StackWalker/LocalsAndOperands.java) test where they are used via reflection. Do you know if there are/were plans to make these classes public? ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From amenkov at openjdk.java.net Wed Sep 23 21:11:56 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 23 Sep 2020 21:11:56 GMT Subject: RFR: 8253372: [TESTBUG] update tests which require jvmti - hotspot In-Reply-To: References: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com> Message-ID: On Tue, 22 Sep 2020 23:35:22 GMT, Serguei Spitsyn wrote: > > Did you test it in minimal config? Sure. The updated tests are skipped with minimal VM ------------- PR: https://git.openjdk.java.net/jdk/pull/314 From amenkov at openjdk.java.net Wed Sep 23 21:11:55 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 23 Sep 2020 21:11:55 GMT Subject: RFR: 8253372: [TESTBUG] update tests which require jvmti - hotspot In-Reply-To: References: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com> Message-ID: On Tue, 22 Sep 2020 23:36:04 GMT, Ioi Lam wrote: >> This is subtask which covers test in hotspot/jtreg except test/hotspot/jtreg/vmTestbase/nsk/jvmti (there is a separate >> issue for it: JDK-8253371) >> In most tests just "@requires vm.jvmti" is added, >> in several test '@requires vm.flavor != "minimal"' is removed (when this requirement is only to ensure test VM has >> JVMTI included) > > The CDS test changes look good to me. Thanks for doing this. > > > How did you determine the list of tests that need jvmti? I tried to run all hotspot tests, but it failed due timeout. Main reason is absence of management (management module presents in minimal, but contains only stubs). There is a separate issue for management requirement: JDK-8252474 So I got the list by combining 2 ways: - search for known functionalities which require jvmti (java.instrument, javaagent/agentlib) - run subsets of the tests and looked at the failure reasons So I can miss some tests which need to be updated, but it will be much simpler to identify them after JDK-8252474 is fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/314 From amenkov at openjdk.java.net Wed Sep 23 21:14:46 2020 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 23 Sep 2020 21:14:46 GMT Subject: Integrated: 8253372: [TESTBUG] update tests which require jvmti - hotspot In-Reply-To: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com> References: <7oSgHbXu_Mnhu3ntyE7Vp_hvJWcHyTksHNRPnf1nkkA=.d68565f3-7df4-4cab-8c4d-3c4108ac1f35@github.com> Message-ID: <11WW-JcbzA7F1bLTDhj2mHHORIMm8MKjW6YiPgfqf_Y=.4a02eb5c-a1e2-4a2b-a4f2-f54dd9227133@github.com> On Tue, 22 Sep 2020 22:51:13 GMT, Alex Menkov wrote: > This is subtask which covers test in hotspot/jtreg except test/hotspot/jtreg/vmTestbase/nsk/jvmti (there is a separate > issue for it: JDK-8253371) > In most tests just "@requires vm.jvmti" is added, > in several test '@requires vm.flavor != "minimal"' is removed (when this requirement is only to ensure test VM has > JVMTI included) This pull request has now been integrated. Changeset: 3320fc0f Author: Alex Menkov URL: https://git.openjdk.java.net/jdk/commit/3320fc0f Stats: 38 lines in 36 files changed: 25 ins; 0 del; 13 mod 8253372: [TESTBUG] update tests which require jvmti - hotspot Reviewed-by: sspitsyn, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/314 From jrose at openjdk.java.net Wed Sep 23 22:11:32 2020 From: jrose at openjdk.java.net (John R Rose) Date: Wed, 23 Sep 2020 22:11:32 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> <_luUft9Qs0GYU6GwUs1PLMDGel1salhJg8X Gxsc3h0k=.c175a93b-0736-4549-8316-ac01692f6b9e@github.com> <9tn1QTeKWk7DB7fWgyw7O_PSuN5Y7nTUmvvZSuuWqHM=.e9a7dbbe-c8ec-40eb-aee4-74e08892db08@github.com> Message-ID: On Wed, 23 Sep 2020 20:23:18 GMT, Doug Simon wrote: >> You are right; the java.lang.StackWalker does not have a thread parameter. If one is needed, I imagine we can add one >> (using a handshake). However, I was under the impression that only the debugger case needed this for other remote >> threads, in which case JVMTI seems like the natural solution. So yeah, is the non-debug case in need of remote stack >> traces with locals? > > I'll let @chumer answer that question. > > However, I have another one of my own. As far as I can see, the only use of `java.lang.LiveStackFrame` and > `java.lang.LiveStackFrameInfo` in the JDK code base are in the > [LocalsAndOperands](https://github.com/openjdk/jdk/blob/6bab0f539fba8fb441697846347597b4a0ade428/test/jdk/java/lang/StackWalker/LocalsAndOperands.java) > test where they are used via reflection. Do you know if there are/were plans to make these classes public? The special case we support in the `StackWalker` API is intentionally limited, because a thread examining its own stack is the least risky and most performant scenario. The `StackWalker::walk` API point, in particular, is carefully designed so that its internal implementation can internally use unsafe "dangling" pointers from the thread into its own stack. This reduces copying and buffering, which is obviously the least expensive way to "take a quick peek" at what's on the stack. It is reasonable to ask to extend such functionality to a second, uncooperative thread, but this brings in lots of extra baggage: - How does the requesting thread get permission to look inside the target thread? (New security analysis.) - At what point does the target thread get its state taken as a snapshot? Any random moment? - How is the target thread "held still" while it is being sampled? (And then, "Where is this term 'safepoint' defined in the JVM specifications?") - Can a target thread refuse or defer the request, to defend some particular encapsulation? - How is that state stored, and what are the time and space costs for such storage? - What happens if the requesting thread just wants to look at a few bits? Do we still buffer up a whole backtrace? - Or, is the target thread required to execute callbacks provided by the requesting thread, with a temporary view, and if so, that limits are there on such callbacks? - Can the observation process ever cause the target thread to fail, or will any and all failures (OOME, SOE, etc.) be attributed to the requesting thread? - What happens if the requesting thread makes two requests in a row: Are there any guarantees about relations between the two sets of results? (To be fair, this is also an issue with the self-walking case.) - What happens if the requesting thread asks to change a value in a frame or pop or re-invoke or replace a frame? (Not allowed in the self-walking case either, but a plausible extension.) If only "just adding a thread parameter" were a straightforward extension? Instead, we have serious user model issues (see above), and serious implementation issues (see the PR). I think we could perhaps add cross-thread access to the current `StackWalker` API, if we came up with answers to the above. I think, in order to engineer it correctly, we would want to factor it as the composition of a self-walking request, *plus* a cross-call mechanism which would allow one thread to ask another thread to run a function. Jumbling these complex operations together into a big pile of new code would be the wrong way to do it. The self-walking API is pretty well understood, and there is a good literature on cross-call mechanisms too. Let's break the problem up. BTW, the current `StackWalker` API could certainly accept minor extensions to inspect locals, and/or to perform frame replacement, as hinted above. The JVM currently benefits from performing on-stack replacement when it can tell that a slow loop is worth (re-)optimizing as a fast loop. There's no reason the JDK libraries (say, the streams runtime, in particular) shouldn't have a shot at doing something similar. That would require internal JDK hooks self-inspect and replace loops with improved "customizations", on the fly. All of the above comments apply only to what might be called the self-inspecting, self-reflective, or "introspective" modes of stack walking. Debuggers usually don't do this (except in one-world environments like Lisp and SmallTalk), but rather operate from the side, through a privileged channel "under the virtual metal" like JVMTI. I suppose for those use cases, JVMTI is plenty good. If there is some trick for self-attachment (either direct or through a conspirator process), then some introspection is also possible, via JVMTI. For best performance, a more "one world" implementation is desirable, but this implies that we create a whole category of "debugging/monitoring code". Such debugging/monitoring code would (like today's runtime internals like those that use `Unsafe`) have privileges beyond regular application code. It might also have eBPF-like limitations on resource usage, so that its executions could be hidden "under the metal" of regular executions. IMO these are promising ideas. They might help us define a better, more cooperative debugging/monitoring primitives. I raise the ideas here because I think there may be a root issue here: How can we use the JDK's on-line introspection APIs for more purposes? How can we inject privileged monitoring code into Java executions? Adding yet another stack walking mechanism to the JVM seems to me like an inefficient way to move, a little bit, in the direction of cooperative debugging/monitoring facilities in the JDK. Conversely, if we can create a way to do (privileged) cross-calls, then we won't need yet another stack walking mechanism. I guess this is where I end up: Please consider refactoring this into an extension (if any is needed) to the self-inspection API (`StackWalker`) and something a cross-call API. Then we should consider hooking it up to JVMCI. ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From kvn at openjdk.java.net Wed Sep 23 22:50:52 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 23 Sep 2020 22:50:52 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Wed, 23 Sep 2020 20:02:45 GMT, Erik Gahlin wrote: >> Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains one commit: >> 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate > > Marked as reviewed by egahlin (Reviewer). @marschall I will sponsor it after you integrate the latest update. ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From dholmes at openjdk.java.net Wed Sep 23 23:09:52 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 23 Sep 2020 23:09:52 GMT Subject: RFR: 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc In-Reply-To: References: Message-ID: <7DI8bSYLJe978QgasK2DBMAAl5yC0pkq8Rt_vMC0BaA=.d0f68e84-d778-4a36-a4b9-2d0f9a9e2200@github.com> On Wed, 23 Sep 2020 15:12:57 GMT, Coleen Phillimore wrote: > These functions are also unused and in the thread_platform.hpp files. _last_Java_sp and _last_Java_fp are set in the > assembly code for platforms that use these (x86, arm32 and aarch64). The shared runtime code never sets these, or > should it. last_Java_fp() is always called through JavaFrameAnchor, so that function is not needed. > last_Java_fp_offset() is used and needs to be in these platform dependent files because not all platforms save > last_Java_fp. Tested with build on arm32 and tier1 on Oracle platforms including aarch64. Seems okay. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/324 From sspitsyn at openjdk.java.net Wed Sep 23 23:48:46 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 23 Sep 2020 23:48:46 GMT Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 04:10:36 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after Coleen > > No significant comments. All my concerns relate to naming and terminology, where I think there is scope for quite a bit > of tidying up. Thanks. Hi Robbin, I've looked more at the Serviceability files. The fix looks good in general. Nice refactoring and simplification with the JvmtiHandshakeClosure. It is a little unexpected that the do_thread can be executed by non-JavaThread's. Not sure, what kinds of inconvenience it can cause. Also, adding the _completed field is somewhat inconsistent. I'd expect it to be present or not present for almost all JVMTI handshake closures. I hope, you can comment on why it was added in these particular cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From jzhu at openjdk.java.net Thu Sep 24 00:57:59 2020 From: jzhu at openjdk.java.net (Joshua Zhu) Date: Thu, 24 Sep 2020 00:57:59 GMT Subject: Integrated: 8253048: AArch64: When CallLeaf, no need to preserve callee-saved registers in caller In-Reply-To: <9K43aYMMk0zdBfxGBwRA336lvjqGZyLFtZcQKVWLOec=.4a194ce2-db80-4dcc-9ef2-ed2a0d2cd088@github.com> References: <9K43aYMMk0zdBfxGBwRA336lvjqGZyLFtZcQKVWLOec=.4a194ce2-db80-4dcc-9ef2-ed2a0d2cd088@github.com> Message-ID: On Fri, 11 Sep 2020 12:23:30 GMT, Joshua Zhu wrote: > I noticed all Floating-Point and SIMD Registers are defined as SOC > registers in c calling convention on AArch64. > As AArch64 ABI tells, the bottom 64 bits of v8-v15 are callee-saved. > > When using CallRuntime, with the help of existing flag "exclude_soe" and > function add_call_kills(), SOE registers are killed by the call > because values that could show up in the RegisterMap aren't live in > callee saved registers. > But CallLeaf and CallLeafNoFP are ok because they don't have safepoint > and debug info. > > Therefore I submit this patch that aligns save-policy in c calling > convention with AArch64 ABI. It could help eliminate unnecessary SOE > registers spilling in caller across CallLeafNode. > > I wrote a simple test case: > http://cr.openjdk.java.net/~jzhu/8253048/Test.java > Original OptoAssembly is: > http://cr.openjdk.java.net/~jzhu/8253048/old_OptoAssembly > With the patch, unnecessary spillings are eliminated: > http://cr.openjdk.java.net/~jzhu/8253048/new_OptoAssembly > > And when a vector is alive across CallLeaf, with the help of existing > FatProjectionNode and RA, the whole vector register ( length > 64-bit ) > is still spilled to stack as usual. > > A test case using VectorAPI is written to verify: > http://cr.openjdk.java.net/~jzhu/8253048/TestVector.java > Test patch: > http://cr.openjdk.java.net/~jzhu/8253048/patch > OptoAssembly dump: > http://cr.openjdk.java.net/~jzhu/8253048/TestVector_OptoAssembly > > I also searched all occurrences of "V8-V15" in aarch64 codes. > The stubs for sin/cos don't save v10 before usage. > Therefore I replace it with caller-save register v24. > > Jtreg Testing: hotspot_all_no_apps, jdk_core and langtools:tier1 > > Could you please help review this change? > > Best Regards, > Joshua > > --------- This pull request has now been integrated. Changeset: ba174af3 Author: Joshua Zhu URL: https://git.openjdk.java.net/jdk/commit/ba174af3 Stats: 22 lines in 2 files changed: 0 ins; 0 del; 22 mod 8253048: AArch64: When CallLeaf, no need to preserve callee-saved registers in caller Reviewed-by: adinn, aph ------------- PR: https://git.openjdk.java.net/jdk/pull/129 From david.holmes at oracle.com Thu Sep 24 04:04:22 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Sep 2020 14:04:22 +1000 Subject: RFR: 8212107: VMThread issues and cleanup [v2] In-Reply-To: References: <8KYOSvjbrmDhnP3_WLOu0dO0saiWTHp1SBgE3ikOJkE=.dd9b9e50-2bb5-47cb-a67f-e7c5293ef1d2@github.com> <0zyH4bq9n93UH7O4QuK4WtqIs7Zig2ADAfsCaNyWWfU=.9d8a09e8-5aa1-4c65-93a8-cf84eed75820@github.com> Message-ID: On 23/09/2020 9:27 pm, Robbin Ehn wrote: > On Wed, 23 Sep 2020 11:02:54 GMT, David Holmes wrote: > >>> inner_execute(..) is called in the non nested-case here: >>> https://github.com/openjdk/jdk/blob/e49178a4445378fa0b5505ad6e9f1661636f88b8/src/hotspot/share/runtime/vmThread.cpp#L474 >>> >>> Nested case: >>> https://github.com/openjdk/jdk/blob/e49178a4445378fa0b5505ad6e9f1661636f88b8/src/hotspot/share/runtime/vmThread.cpp#L511 >> >> Sorry I missed that. Seems odd that inner_execute handles nesting when that is only possible via one of the paths by >> which it is called - that's why I thought it was only for the case where called from execute(). I'd rather see the >> nesting logic handled as before, exclusively on the code path in which it can occur. > > That would create a lot of code duplication: > void VMThread::none_nested_inner_execute(VM_Operation* op) { > Thread* current = Thread::current(); > assert(current->is_VM_thread(), "must be a VM thread"); > > _cur_vm_operation = op; > > HandleMark hm(VMThread::vm_thread()); > EventMark em("Executing %s VM operation: %s", op->name()); > > // If we are at a safepoint we will evaluate all the operations that > // follow that also require a safepoint > log_debug(vmthread)("Evaluating %s %s VM operation: %s", > _cur_vm_operation->evaluate_at_safepoint() ? "safepoint" : "non-safepoint", > _cur_vm_operation->name()); > > bool end_safepoint = false; > if (_cur_vm_operation->evaluate_at_safepoint()) { > SafepointSynchronize::begin(); > if (_timeout_task != NULL) { > _timeout_task->arm(); > } > end_safepoint = true; > } > > evaluate_operation(_cur_vm_operation); > > if (end_safepoint) { > if (_timeout_task != NULL) { > _timeout_task->disarm(); > } > SafepointSynchronize::end(); > } > > _cur_vm_operation = NULL; > } > Which 80% the same. (Same minus a few lines) I envisaged simply moving the nesting check out of inner_execute and back into execute: // psuedo-code execute(VM_Operation* op) { if (on VMThread) { if (_cur_operation != NULL) { // nested case check_nesting_allowed(); VM_Operation* prev = _cur_operation; _cur_operation = NULL; inner_execute(op); _cur_operation = prev; } } Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/228 > From dholmes at openjdk.java.net Thu Sep 24 04:12:53 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 24 Sep 2020 04:12:53 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v5] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 15:48:21 GMT, Robbin Ehn wrote: >> We simplify the vmThread by removing the queue and refactor the the main loop. >> This solves the issues listed: >> - It can create an extra safepoint directly after a safepoint. >> - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. >> - The exposure of the vm operation is dangerous if it's a handshake. >> - The code is a hornets nest with the repetition of checks and branches >> >> Passes t1-8, and a benchmark run. >> >> If you want a smaller diff the commits contains the incremental progress and each commit passed t1. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Whitespace fixes, thanks to Shipilev src/hotspot/share/runtime/vmThread.cpp line 471: > 469: SafepointSynchronize::init(_vm_thread); > 470: > 471: assert(Thread::current()->is_VM_thread(), "Must be the VM thread"); This is unnecessary, we don't need to guard against accidental calls to VMThread::loop by other threads! src/hotspot/share/runtime/vmThread.hpp line 108: > 106: > 107: static VM_Operation::VMOp_Type vm_op_type() { > 108: VM_Operation* op = vm_operation(); Why use vm_operation() instead of direct access to _cur_vm_operation? Elsewhere you made the reverse change. ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From david.holmes at oracle.com Thu Sep 24 04:24:57 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Sep 2020 14:24:57 +1000 Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: <9c56a19a-0b3f-929b-d652-e9b77f03ed33@oracle.com> On 23/09/2020 7:37 pm, Robbin Ehn wrote: > On Wed, 23 Sep 2020 02:56:00 GMT, David Holmes wrote: > >>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Update after Coleen >> >> src/hotspot/share/runtime/handshake.hpp line 97: >> >>> 95: } >>> 96: bool block_for_operation() { >>> 97: return !_queue.is_empty() || _lock.is_locked(); >> >> I really don't understand the is_locked() check in this condition. ?? >> And the check for !empty is racy, so how do we avoid missing an in-progress addition? > > A JavaThread is blocked. > A second thread have just executed a handshake operation for this JavaThread and are on line: > https://github.com/openjdk/jdk/blob/cd784a751a3153939b9284898f370160124ca610/src/hotspot/share/runtime/handshake.cpp#L510 > And the queue is empty. > > The JavaThread wakes up and changes state from blocked to blocked_trans. > It now checks if it's allowed to complete the transition to e.g. vm. > > If a third thread adds to queue before the second thread leaves the loop it's operation can be executed. > But the JavaThread could see the queue as empty. (racey as you say) > > The executor takes lock and then checks if the JavaThread is safe for processing. > The JavaThread becomes unsafe and then check if lock is locked. > If the lock is locked we must take slow path to avoid this. > > We should also take slow path if there is something on queue to processes. > We are unsafe when we check queue and lock is not held, if we 'miss' that anything is on queue, it's fine. > Since any other thread cannot have seen us as safe and seen the item on queue. (since lock is not held) > Thus not allowed to process the operation. Wow! That all definitely needs some detailed commentary. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/151 > From david.holmes at oracle.com Thu Sep 24 04:28:20 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Sep 2020 14:28:20 +1000 Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: On 23/09/2020 8:11 pm, Robbin Ehn wrote: > On Wed, 23 Sep 2020 03:04:39 GMT, David Holmes wrote: > >>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Update after Coleen >> >> src/hotspot/share/runtime/handshake.cpp line 63: >> >>> 61: }; >>> 62: >>> 63: class AsyncHandshakeOperation : public HandshakeOperation { >> >> This doesn't quite make sense. If you have an AsyncHandshakeOperation as a distinct subclass then it should not be >> possible for is_async() on a HandshakeOperation to return true - but it can because it can be passed an >> AsyncHandshakeClosure when constructed. If you want async and non-async operations to be distinct types then you will >> need to restrict how the base class is constructed, and provide a protected constructor that just takes an >> AsyncHandShakeClosure. > > This implementation code not part of the interface. I find it hard to tell which classes form which. > By casting the AsyncHandShakeClosure to a HandshakeClosure before instantiating the HandshakeOperation you can still > get is_async() to return true. And there are a loads of other user error which can be done like stack allocating > AsyncHandshakeOperation. Protecting against all those kinds of errors requires a lot of more code. Can we at least declare a protected constructor for HandshakeOperation that takes the AsyncHandshakeClosure, so that an accidental creation of "new HandShakeperation(anAsyncClosure)" will be prevented? Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/151 > From dholmes at openjdk.java.net Thu Sep 24 05:00:16 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 24 Sep 2020 05:00:16 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 13:23:43 GMT, Monica Beckwith wrote: >> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: > > Update orderAccess_windows_aarch64.hpp > > changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided I've mainly looked at the non-Aarch64 specific changes. A couple of minor comments below. src/hotspot/os/windows/os_windows.cpp line 2546: > 2544: > 2545: #ifdef _M_ARM64 > 2546: // Unsafe memory access I'm not at all clear why this unsafe memory access handling is for Aarch64 only? src/hotspot/share/runtime/stubRoutines.cpp line 397: > 395: // test safefetch routines > 396: // Not on Windows 32bit until 8074860 is fixed > 397: #if ! (defined(_WIN32) && defined(_M_IX86)) && !defined(_M_ARM64) The comment needs updating to refer to Aarch64. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/212 From dholmes at openjdk.java.net Thu Sep 24 05:14:47 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 24 Sep 2020 05:14:47 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5] In-Reply-To: References: Message-ID: <4-nb0OwmjwH4FpKoNor3BGZmsAKouFjMJpJ8uN62Y_s=.7de01521-af13-4ce1-ace9-80f4ef2a6d4f@github.com> On Thu, 24 Sep 2020 04:57:39 GMT, David Holmes wrote: >> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: >> >> Update orderAccess_windows_aarch64.hpp >> >> changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided > > I've mainly looked at the non-Aarch64 specific changes. A couple of minor comments below. @mo-beck This PR should not be associated with any JBS issues which are targeted at repo-aarch64-port. All such issues should have been closed by now when the associated code was pushed to aarch64-port repo. That was the whole point of creating separate issues so that they could be tracked in the porting repo. Now that all of that work should be complete the only issue that should remain open in relation to the Windows-Aarch64 port is JDK-8248238. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From thartmann at openjdk.java.net Thu Sep 24 05:45:18 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 24 Sep 2020 05:45:18 GMT Subject: RFR: 8219586: CodeHeap State Analytics processes dead nmethods In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 16:25:32 GMT, Lutz Schmidt wrote: > This change was already fully reviewed before the transition Mercurial to Git happened. > Reviewed-by: thartmann (TobiHartmann), eosterlund (Git name unknown) Still looks good. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/325 From rehn at openjdk.java.net Thu Sep 24 06:14:05 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 24 Sep 2020 06:14:05 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v5] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 04:10:14 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Whitespace fixes, thanks to Shipilev > > src/hotspot/share/runtime/vmThread.hpp line 108: > >> 106: >> 107: static VM_Operation::VMOp_Type vm_op_type() { >> 108: VM_Operation* op = vm_operation(); > > Why use vm_operation() instead of direct access to _cur_vm_operation? Elsewhere you made the reverse change. It was suggested by @shipilev todo that, so we don't need the: `assert(Thread::current()->is_VM_thread(), "Must be");` In that method also. In the other cases we already had access to _cur_vm_operation and it was confusing to mix. > src/hotspot/share/runtime/vmThread.cpp line 471: > >> 469: SafepointSynchronize::init(_vm_thread); >> 470: >> 471: assert(Thread::current()->is_VM_thread(), "Must be the VM thread"); > > This is unnecessary, we don't need to guard against accidental calls to VMThread::loop by other threads! Removed ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From eosterlund at openjdk.java.net Thu Sep 24 06:18:53 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 24 Sep 2020 06:18:53 GMT Subject: RFR: 8219586: CodeHeap State Analytics processes dead nmethods In-Reply-To: References: Message-ID: <-X5eO9shg69d_9pcIvCfV8aK3ST_fW79kOJ2uJYTs4A=.2175d0e8-6549-4491-8614-7514fec7d85f@github.com> On Wed, 23 Sep 2020 16:25:32 GMT, Lutz Schmidt wrote: > This change was already fully reviewed before the transition Mercurial to Git happened. > Reviewed-by: thartmann (TobiHartmann), eosterlund (Git name unknown) Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/325 From rehn at openjdk.java.net Thu Sep 24 06:27:46 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 24 Sep 2020 06:27:46 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v6] In-Reply-To: References: Message-ID: > We simplify the vmThread by removing the queue and refactor the the main loop. > This solves the issues listed: > - It can create an extra safepoint directly after a safepoint. > - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. > - The exposure of the vm operation is dangerous if it's a handshake. > - The code is a hornets nest with the repetition of checks and branches > > Passes t1-8, and a benchmark run. > > If you want a smaller diff the commits contains the incremental progress and each commit passed t1. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Removed assert as suggested by David ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/228/files - new: https://git.openjdk.java.net/jdk/pull/228/files/85cf9001..5bd76150 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=228&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=228&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/228.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/228/head:pull/228 PR: https://git.openjdk.java.net/jdk/pull/228 From stefank at openjdk.java.net Thu Sep 24 06:29:30 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 24 Sep 2020 06:29:30 GMT Subject: RFR: 8253555: Make ByteSize and WordSize typed scoped enums Message-ID: It's a common bug in HotSpot that byte values are used when the code asks for words, and vice versa. One attempt to prevent that has been to use the classes ByteSize and WordSize, to make the compiler detect these problems. The current implementation is a bit problematic, because both types are int typedefs in release builds, and wrapper classes in debug builds. This means that we can't use these types in overload resolution. I propose that we fix that by changing the type to scoped enums with a fixed int type. The compiler will then be apple to completely separate ByteSize, WordSize, and ints. We also don't need different code in release vs debug builds. FWIW, I once created a size_t versions of these classes and annotated all the metaspace code with these types. This experiment flushed out a handful of bugs (some of them were known and the reason for trying that experiment) There are some controversy about having these classes around. See for example: JDK-8041956: remove ByteSize and WordSize classes I hope we can stay away from that discussion in this PR. ------------- Commit messages: - 8253555: Make ByteSize and WordSize typed scoped enums Changes: https://git.openjdk.java.net/jdk/pull/328/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=328&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253555 Stats: 188 lines in 8 files changed: 17 ins; 157 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/328.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/328/head:pull/328 PR: https://git.openjdk.java.net/jdk/pull/328 From eosterlund at openjdk.java.net Thu Sep 24 06:41:43 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 24 Sep 2020 06:41:43 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> <_luUft9Qs0GYU6GwUs1PLMDGel1salhJg8X Gxsc3h0k=.c175a93b-0736-4549-8316-ac01692f6b9e@github.com> <9tn1QTeKWk7DB7fWgyw7O_PSuN5Y7nTUmvvZSuuWqHM=.e9a7dbbe-c8ec-40eb-aee4-74e08892db08@github.com> Message-ID: On Wed, 23 Sep 2020 22:06:33 GMT, John R Rose wrote: >> I'll let @chumer answer that question. >> >> However, I have another one of my own. As far as I can see, the only use of `java.lang.LiveStackFrame` and >> `java.lang.LiveStackFrameInfo` in the JDK code base are in the >> [LocalsAndOperands](https://github.com/openjdk/jdk/blob/6bab0f539fba8fb441697846347597b4a0ade428/test/jdk/java/lang/StackWalker/LocalsAndOperands.java) >> test where they are used via reflection. Do you know if there are/were plans to make these classes public? > > The special case we support in the `StackWalker` API is intentionally limited, because a thread examining its own stack > is the least risky and most performant scenario. The `StackWalker::walk` API point, in particular, is carefully > designed so that its internal implementation can internally use unsafe "dangling" pointers from the thread into its own > stack. This reduces copying and buffering, which is obviously the least expensive way to "take a quick peek" at what's > on the stack. It is reasonable to ask to extend such functionality to a second, uncooperative thread, but this brings > in lots of extra baggage: > - How does the requesting thread get permission to look inside the target thread? (New security analysis.) > - At what point does the target thread get its state taken as a snapshot? Any random moment? > - How is the target thread "held still" while it is being sampled? (And then, "Where is this term 'safepoint' defined in > the JVM specifications?") > - Can a target thread refuse or defer the request, to defend some particular encapsulation? > - How is that state stored, and what are the time and space costs for such storage? > - What happens if the requesting thread just wants to look at a few bits? Do we still buffer up a whole backtrace? > - Or, is the target thread required to execute callbacks provided by the requesting thread, with a temporary view, and if > so, that limits are there on such callbacks? > - Can the observation process ever cause the target thread to fail, or will any and all failures (OOME, SOE, etc.) be > attributed to the requesting thread? > - What happens if the requesting thread makes two requests in a row: Are there any guarantees about relations between > the two sets of results? (To be fair, this is also an issue with the self-walking case.) > - What happens if the requesting thread asks to change a value in a frame or pop or re-invoke or replace a frame? (Not > allowed in the self-walking case either, but a plausible extension.) > > If only "just adding a thread parameter" were a straightforward extension? Instead, we have serious user model issues > (see above), and serious implementation issues (see the PR). > I think we could perhaps add cross-thread access to the current `StackWalker` API, if we came up with answers to the > above. I think, in order to engineer it correctly, we would want to factor it as the composition of a self-walking > request, *plus* a cross-call mechanism which would allow one thread to ask another thread to run a function. Jumbling > these complex operations together into a big pile of new code would be the wrong way to do it. The self-walking API is > pretty well understood, and there is a good literature on cross-call mechanisms too. Let's break the problem up. > BTW, the current `StackWalker` API could certainly accept minor extensions to inspect locals, and/or to perform frame > replacement, as hinted above. The JVM currently benefits from performing on-stack replacement when it can tell that a > slow loop is worth (re-)optimizing as a fast loop. There's no reason the JDK libraries (say, the streams runtime, in > particular) shouldn't have a shot at doing something similar. That would require internal JDK hooks self-inspect and > replace loops with improved "customizations", on the fly. > > All of the above comments apply only to what might be called the self-inspecting, self-reflective, or "introspective" > modes of stack walking. Debuggers usually don't do this (except in one-world environments like Lisp and SmallTalk), > but rather operate from the side, through a privileged channel "under the virtual metal" like JVMTI. I suppose for > those use cases, JVMTI is plenty good. If there is some trick for self-attachment (either direct or through a > conspirator process), then some introspection is also possible, via JVMTI. For best performance, a more "one world" > implementation is desirable, but this implies that we create a whole category of "debugging/monitoring code". Such > debugging/monitoring code would (like today's runtime internals like those that use `Unsafe`) have privileges beyond > regular application code. It might also have eBPF-like limitations on resource usage, so that its executions could be > hidden "under the metal" of regular executions. IMO these are promising ideas. They might help us define a better, > more cooperative debugging/monitoring primitives. I raise the ideas here because I think there may be a root issue > here: How can we use the JDK's on-line introspection APIs for more purposes? How can we inject privileged monitoring > code into Java executions? Adding yet another stack walking mechanism to the JVM seems to me like an inefficient way > to move, a little bit, in the direction of cooperative debugging/monitoring facilities in the JDK. Conversely, if we > can create a way to do (privileged) cross-calls, then we won't need yet another stack walking mechanism. I guess this > is where I end up: Please consider refactoring this into an extension (if any is needed) to the self-inspection API > (`StackWalker`) and something a cross-call API. Then we should consider hooking it up to JVMCI. John there is a lot to be said here in the solution domain. But before we get there, I want to get answers about the problem domain, so I know if we are solving a real or imaginary problem. The crucial question it boils down to is: "is remote thread stack sampling with locals needed in the non-debugger case"? If so, we can start discussing the solution domain of that. But I suspect we already have all the APIs in place that are needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From rehn at openjdk.java.net Thu Sep 24 06:57:04 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 24 Sep 2020 06:57:04 GMT Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 23:45:49 GMT, Serguei Spitsyn wrote: >> No significant comments. All my concerns relate to naming and terminology, where I think there is scope for quite a bit >> of tidying up. Thanks. > > Hi Robbin, > I've looked more at the Serviceability files. > The fix looks good in general. Nice refactoring and simplification with the JvmtiHandshakeClosure. > It is a little unexpected that the do_thread can be executed by non-JavaThread's. > Not sure, what kinds of inconvenience it can cause. > Also, adding the _completed field is somewhat inconsistent. > I'd expect it to be present or not present for almost all JVMTI handshake closures. > I hope, you can comment on why it was added in these particular cases. Hi Serguei, > Hi Robbin, > I've looked more at the Serviceability files. > The fix looks good in general. Nice refactoring and simplification with the JvmtiHandshakeClosure. Good. > It is a little unexpected that the do_thread can be executed by non-JavaThread's. > Not sure, what kinds of inconvenience it can cause. Reading the code I did not find any issues. Any return values must already be allocated correctly since the executor thread do not wait around. Thus targeted thread must be the owner of these. Also extensive testing find no issues. But as I said to David, we can easily change back to the previous behavior if needed by using the filter mechanism. > Also, adding the _completed field is somewhat inconsistent. > I'd expect it to be present or not present for almost all JVMTI handshake closures. > I hope, you can comment on why it was added in these particular cases. Two of the handshakes have guarantee checks: https://github.com/openjdk/jdk/blob/94daf2c7566d882c46cb87b8c28017812bf722ef/src/hotspot/share/prims/jvmtiEnvThreadState.cpp#L326 https://github.com/openjdk/jdk/blob/94daf2c7566d882c46cb87b8c28017812bf722ef/src/hotspot/share/prims/jvmtiEventController.cpp#L345 This is the only placed it is used/needed. In my previous version I just removed those guarantee because they needed extra code and was suspicious to me. But it was requested to add them back. I had quick look now, and from what I can tell it is not guaranteed that we do execute those handshake. We do not run handshakes on exiting threads (is_terminated()), we set is exiting here: https://github.com/openjdk/jdk/blob/94daf2c7566d882c46cb87b8c28017812bf722ef/src/hotspot/share/runtime/thread.cpp#L2123 But we remove the JVM TI Thread state way later, here: https://github.com/openjdk/jdk/blob/94daf2c7566d882c46cb87b8c28017812bf722ef/src/hotspot/share/runtime/thread.cpp#L2207 For example the method ensure_join() which is between set_terminated and removing the JVM TI state can safepoint/handshake. https://github.com/openjdk/jdk/blob/94daf2c7566d882c46cb87b8c28017812bf722ef/src/hotspot/share/runtime/thread.cpp#L2159 That would trigger the guarantee. So I believe we should not have those two guarantees and thus the _completed can be removed once again. I think that should be handled in a separate issue, leaving this as is for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From lucy at openjdk.java.net Thu Sep 24 07:51:13 2020 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Thu, 24 Sep 2020 07:51:13 GMT Subject: RFR: 8219586: CodeHeap State Analytics processes dead nmethods In-Reply-To: <-X5eO9shg69d_9pcIvCfV8aK3ST_fW79kOJ2uJYTs4A=.2175d0e8-6549-4491-8614-7514fec7d85f@github.com> References: <-X5eO9shg69d_9pcIvCfV8aK3ST_fW79kOJ2uJYTs4A=.2175d0e8-6549-4491-8614-7514fec7d85f@github.com> Message-ID: On Thu, 24 Sep 2020 06:15:51 GMT, Erik ?sterlund wrote: >> This change was already fully reviewed before the transition Mercurial to Git happened. >> Reviewed-by: thartmann (TobiHartmann), eosterlund (Git name unknown) > > Looks good. Thank you, Tobias and Erik, for re-checking this fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/325 From lucy at openjdk.java.net Thu Sep 24 07:51:14 2020 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Thu, 24 Sep 2020 07:51:14 GMT Subject: Integrated: 8219586: CodeHeap State Analytics processes dead nmethods In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 16:25:32 GMT, Lutz Schmidt wrote: > This change was already fully reviewed before the transition Mercurial to Git happened. > Reviewed-by: thartmann (TobiHartmann), eosterlund (Git name unknown) This pull request has now been integrated. Changeset: 4440bda3 Author: Lutz Schmidt URL: https://git.openjdk.java.net/jdk/commit/4440bda3 Stats: 266 lines in 8 files changed: 111 ins; 53 del; 102 mod 8219586: CodeHeap State Analytics processes dead nmethods Reviewed-by: thartmann, eosterlund ------------- PR: https://git.openjdk.java.net/jdk/pull/325 From github.com+4676506+javeleon at openjdk.java.net Thu Sep 24 08:04:52 2020 From: github.com+4676506+javeleon at openjdk.java.net (Allan Gregersen) Date: Thu, 24 Sep 2020 08:04:52 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> <_luUft9Qs0GYU6GwUs1PLMDGel1salhJg8X Gxsc3h0k=.c175a93b-0736-4549-8316-ac01692f6b9e@github.com> <9tn1QTeKWk7DB7fWgyw7O_PSuN5Y7nTUmvvZSuuWqHM=.e9a7dbbe-c8ec-40eb-aee4-74e08892db08@github.com> Message-ID: On Thu, 24 Sep 2020 06:38:10 GMT, Erik ?sterlund wrote: >> The special case we support in the `StackWalker` API is intentionally limited, because a thread examining its own stack >> is the least risky and most performant scenario. The `StackWalker::walk` API point, in particular, is carefully >> designed so that its internal implementation can internally use unsafe "dangling" pointers from the thread into its own >> stack. This reduces copying and buffering, which is obviously the least expensive way to "take a quick peek" at what's >> on the stack. It is reasonable to ask to extend such functionality to a second, uncooperative thread, but this brings >> in lots of extra baggage: >> - How does the requesting thread get permission to look inside the target thread? (New security analysis.) >> - At what point does the target thread get its state taken as a snapshot? Any random moment? >> - How is the target thread "held still" while it is being sampled? (And then, "Where is this term 'safepoint' defined in >> the JVM specifications?") >> - Can a target thread refuse or defer the request, to defend some particular encapsulation? >> - How is that state stored, and what are the time and space costs for such storage? >> - What happens if the requesting thread just wants to look at a few bits? Do we still buffer up a whole backtrace? >> - Or, is the target thread required to execute callbacks provided by the requesting thread, with a temporary view, and if >> so, that limits are there on such callbacks? >> - Can the observation process ever cause the target thread to fail, or will any and all failures (OOME, SOE, etc.) be >> attributed to the requesting thread? >> - What happens if the requesting thread makes two requests in a row: Are there any guarantees about relations between >> the two sets of results? (To be fair, this is also an issue with the self-walking case.) >> - What happens if the requesting thread asks to change a value in a frame or pop or re-invoke or replace a frame? (Not >> allowed in the self-walking case either, but a plausible extension.) >> >> If only "just adding a thread parameter" were a straightforward extension? Instead, we have serious user model issues >> (see above), and serious implementation issues (see the PR). >> I think we could perhaps add cross-thread access to the current `StackWalker` API, if we came up with answers to the >> above. I think, in order to engineer it correctly, we would want to factor it as the composition of a self-walking >> request, *plus* a cross-call mechanism which would allow one thread to ask another thread to run a function. Jumbling >> these complex operations together into a big pile of new code would be the wrong way to do it. The self-walking API is >> pretty well understood, and there is a good literature on cross-call mechanisms too. Let's break the problem up. >> BTW, the current `StackWalker` API could certainly accept minor extensions to inspect locals, and/or to perform frame >> replacement, as hinted above. The JVM currently benefits from performing on-stack replacement when it can tell that a >> slow loop is worth (re-)optimizing as a fast loop. There's no reason the JDK libraries (say, the streams runtime, in >> particular) shouldn't have a shot at doing something similar. That would require internal JDK hooks self-inspect and >> replace loops with improved "customizations", on the fly. >> >> All of the above comments apply only to what might be called the self-inspecting, self-reflective, or "introspective" >> modes of stack walking. Debuggers usually don't do this (except in one-world environments like Lisp and SmallTalk), >> but rather operate from the side, through a privileged channel "under the virtual metal" like JVMTI. I suppose for >> those use cases, JVMTI is plenty good. If there is some trick for self-attachment (either direct or through a >> conspirator process), then some introspection is also possible, via JVMTI. For best performance, a more "one world" >> implementation is desirable, but this implies that we create a whole category of "debugging/monitoring code". Such >> debugging/monitoring code would (like today's runtime internals like those that use `Unsafe`) have privileges beyond >> regular application code. It might also have eBPF-like limitations on resource usage, so that its executions could be >> hidden "under the metal" of regular executions. IMO these are promising ideas. They might help us define a better, >> more cooperative debugging/monitoring primitives. I raise the ideas here because I think there may be a root issue >> here: How can we use the JDK's on-line introspection APIs for more purposes? How can we inject privileged monitoring >> code into Java executions? Adding yet another stack walking mechanism to the JVM seems to me like an inefficient way >> to move, a little bit, in the direction of cooperative debugging/monitoring facilities in the JDK. Conversely, if we >> can create a way to do (privileged) cross-calls, then we won't need yet another stack walking mechanism. I guess this >> is where I end up: Please consider refactoring this into an extension (if any is needed) to the self-inspection API >> (`StackWalker`) and something a cross-call API. Then we should consider hooking it up to JVMCI. > > John there is a lot to be said here in the solution domain. But before we get there, I want to get answers about the > problem domain, so I know if we are solving a real or imaginary problem. The crucial question it boils down to is: "is > remote thread stack sampling with locals needed in the non-debugger case"? If so, we can start discussing the solution > domain of that. But I suspect we already have all the APIs in place that are needed. A lot of good comments here. Thanks! I agree that we should look at the problem domain first. Hence, let's look at the use-cases that was brought up once more. 1. The Truffle debugger (not to be confused with a Java host debugger) in general needs to access all live stack traces for all guest-language threads and read/write access to local variables. 2. Some Truffle guest languages need to access all live objects (e.g. Ruby). Espresso also needs this for implementing e.g. getReferringObjects (through the debugger though) etc. Onto discussing potential solutions: After discussing the capabilities of JVMTI internally, it seems that the current implementation of getting locals might not be able to return anything for escape-analyzed objects. This obviously poses a serious limitation for Truffle given the fact that this is a corner-stone in GraalVM. I take it this played a big role in introducing iterateFrames (current thread only) in JVMCI a while back. Even for the debugger case we would need JVMTI to guarantee the following: 1. A safe suspension mechanism for all target threads (what if two debuggers are connected at the same time?) that would span the entirety of getAllStackTraces + fetching all locals for all frames. I don't see how something like suspendThreadList would provide the safe guards that we would need here. 2. A bulk getAllLocals to avoid fetching all stack traces + retrieving all locals in bulk for all frames. Given that Truffle/GraalVM will continue to support Java 8 for quite some time, this new API should probably be exposed through JVMCI and backported like it was done for iterateFrames regardless of the underlying implementation. Note: In the current PR we need to refactor materializeVirtualObjects into using VM operations to guarantee that we run stack walking and sanity checks for locating the frame in question at a safe point. I'll hold my horses a bit on that until there is a consensus on where this is going. ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From rehn at openjdk.java.net Thu Sep 24 08:18:12 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 24 Sep 2020 08:18:12 GMT Subject: RFR: 8238761: Asynchronous handshakes [v8] In-Reply-To: References: Message-ID: > This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes > are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) > Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an > arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a > singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first > pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first > pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake > operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything > except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed > filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake > operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there > is now only one method to call when handshaking one thread. Some comments about the changes: > - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake > all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much > worse then this. > > - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that > thread. > > - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a > handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. > > - Added WB testing method. > > - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. > > - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. > > - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a > safepoint and half of them after, in many handshake all operations. > > - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. > > - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the > moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. > > - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. > > - Added filtered queue and gtest for it. > > Passes multiple t1-8 runs. > Been through some pre-reviwing. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Add constructor and comment. Previous renames caused confusing, improved names once more and moved non-public to private ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/151/files - new: https://git.openjdk.java.net/jdk/pull/151/files/94daf2c7..9125d6ad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=151&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=151&range=06-07 Stats: 29 lines in 3 files changed: 18 ins; 3 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/151/head:pull/151 PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Thu Sep 24 08:18:13 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 24 Sep 2020 08:18:13 GMT Subject: RFR: 8238761: Asynchronous handshakes [v5] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 06:54:32 GMT, Robbin Ehn wrote: >> Hi Robbin, >> I've looked more at the Serviceability files. >> The fix looks good in general. Nice refactoring and simplification with the JvmtiHandshakeClosure. >> It is a little unexpected that the do_thread can be executed by non-JavaThread's. >> Not sure, what kinds of inconvenience it can cause. >> Also, adding the _completed field is somewhat inconsistent. >> I'd expect it to be present or not present for almost all JVMTI handshake closures. >> I hope, you can comment on why it was added in these particular cases. > > Hi Serguei, > >> Hi Robbin, >> I've looked more at the Serviceability files. >> The fix looks good in general. Nice refactoring and simplification with the JvmtiHandshakeClosure. > > Good. > >> It is a little unexpected that the do_thread can be executed by non-JavaThread's. >> Not sure, what kinds of inconvenience it can cause. > > Reading the code I did not find any issues. > Any return values must already be allocated correctly since the executor thread do not wait around. > Thus targeted thread must be the owner of these. > Also extensive testing find no issues. > But as I said to David, we can easily change back to the previous behavior if needed by using the filter mechanism. > >> Also, adding the _completed field is somewhat inconsistent. >> I'd expect it to be present or not present for almost all JVMTI handshake closures. >> I hope, you can comment on why it was added in these particular cases. > > Two of the handshakes have guarantee checks: > https://github.com/openjdk/jdk/blob/94daf2c7566d882c46cb87b8c28017812bf722ef/src/hotspot/share/prims/jvmtiEnvThreadState.cpp#L326 > https://github.com/openjdk/jdk/blob/94daf2c7566d882c46cb87b8c28017812bf722ef/src/hotspot/share/prims/jvmtiEventController.cpp#L345 > > This is the only placed it is used/needed. > In my previous version I just removed those guarantee because they needed extra code and was suspicious to me. > But it was requested to add them back. > > I had quick look now, and from what I can tell it is not guaranteed that we do execute those handshake. > We do not run handshakes on exiting threads (is_terminated()), we set is exiting here: > https://github.com/openjdk/jdk/blob/94daf2c7566d882c46cb87b8c28017812bf722ef/src/hotspot/share/runtime/thread.cpp#L2123 > But we remove the JVM TI Thread state way later, here: > https://github.com/openjdk/jdk/blob/94daf2c7566d882c46cb87b8c28017812bf722ef/src/hotspot/share/runtime/thread.cpp#L2207 > > For example the method ensure_join() which is between set_terminated and removing the JVM TI state can > safepoint/handshake. > https://github.com/openjdk/jdk/blob/94daf2c7566d882c46cb87b8c28017812bf722ef/src/hotspot/share/runtime/thread.cpp#L2159 > That would trigger the guarantee. > > So I believe we should not have those two guarantees and thus the _completed can be removed once again. > I think that should be handled in a separate issue, leaving this as is for now. Added comment @dholmes-ora Added constructor @dholmes-ora Previous renames caused confusing, renamed some methods and moved those not public to private Running tests Good to go? ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From kim.barrett at oracle.com Thu Sep 24 08:31:52 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 24 Sep 2020 04:31:52 -0400 Subject: RFR: 8253555: Make ByteSize and WordSize typed scoped enums In-Reply-To: References: Message-ID: <15B4A544-93B7-4E70-B6F3-A79C5FCF2C42@oracle.com> > On Sep 24, 2020, at 2:29 AM, Stefan Karlsson wrote: > > It's a common bug in HotSpot that byte values are used when the code asks for words, and vice versa. One attempt to > prevent that has been to use the classes ByteSize and WordSize, to make the compiler detect these problems. The current > implementation is a bit problematic, because both types are int typedefs in release builds, and wrapper classes in > debug builds. This means that we can't use these types in overload resolution. I propose that we fix that by changing > the type to scoped enums with a fixed int type. The compiler will then be apple to completely separate ByteSize, > WordSize, and ints. We also don't need different code in release vs debug builds. > > FWIW, I once created a size_t versions of these classes and annotated all the metaspace code with these types. This > experiment flushed out a handful of bugs (some of them were known and the reason for trying that experiment) > > There are some controversy about having these classes around. See for example: > JDK-8041956: remove ByteSize and WordSize classes > > I hope we can stay away from that discussion in this PR. > > ------------- > > Commit messages: > - 8253555: Make ByteSize and WordSize typed scoped enums > > Changes: https://git.openjdk.java.net/jdk/pull/328/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=328&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8253555 > Stats: 188 lines in 8 files changed: 17 ins; 157 del; 14 mod > Patch: https://git.openjdk.java.net/jdk/pull/328.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/328/head:pull/328 > > PR: https://git.openjdk.java.net/jdk/pull/328 I've also experimented with various changes to these classes, eventually concluding I should wait for scoped enums. This looks exactly like what I had in mind. The alternative of a thin wrapper class may have unpleasant costs on some platforms due to ABI issues. ------------------------------------------------------------------------------ src/hotspot/share/utilities/sizes.hpp I think all the operations here should be constexpr rather than just inline. ------------------------------------------------------------------------------ src/hotspot/share/utilities/sizes.hpp Consider adding constexpr ByteSize in_ByteSize(WordSize size) { ... } constexpr int in_bytes(WordSize size) { ... } Also consider adding the identity conversion constexpr ByteSize in_ByteSize(ByteSize size) { return size; } which might be useful in generic code? But if we're really planning to move away from using WordSize at all, then probably don't bother. ------------------------------------------------------------------------------ src/hotspot/share/utilities/sizes.hpp It would be nice to have a more complete set of operations for ByteSize. That way, when writing new code, one doesn't need to remember or look up whether the operation you want to use is supported. ByteSize operator*(int, ByteSize) -- so multiplicative scaling is commutative ByteSize operator/(ByteSize, int) -- division scaling ? -- op= variants ByteSize& operator+=(ByteSize& x, ByteSize y) ByteSize& operator-=(ByteSize& x, ByteSize y) ByteSize& operator*=(ByteSize& x, int y) ByteSize& operator/=(ByteSize& x, int y) ------------------------------------------------------------------------------ src/hotspot/share/utilities/sizes.hpp 45 inline WordSize in_WordSize(int size) { return WordSize(size); } 46 inline int in_words(WordSize x) { return static_cast(x); } ... 50 inline ByteSize in_ByteSize(int size) { return ByteSize(size); } 51 inline int in_bytes(ByteSize x) { return static_cast(x); } The explicit conversions using function notation are semantically equivalent to static casts. I think these should be consistent about which form they use. My preference would be for static_cast for all of these. ------------------------------------------------------------------------------ src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp 591 __ add(Rbcp, Rtemp, in_bytes(ConstMethod::codes_offset())); // get codebase Newly added in_bytes seems like it should not be needed here. codes_offset returns a ByteSize, and AsmOperand has an implicit ByteSize conversion constructor. ------------------------------------------------------------------------------ From eosterlund at openjdk.java.net Thu Sep 24 08:55:03 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 24 Sep 2020 08:55:03 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v4] In-Reply-To: References: Message-ID: <4bjUBhVYYs27w4gQ3YV-O4jIece8dzeNobbyuvz0AZY=.75e05368-efbc-4b9c-8a72-4d947a5f3717@github.com> > This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. > https://openjdk.java.net/jeps/376). > Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, > and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into > more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to > expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in > the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized > automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization > processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is > actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception > handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC > threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming > of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the > watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll > word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it > brought (and is only possible on TSO machines). So left that one out. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Review: Albert CR 1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/296/files - new: https://git.openjdk.java.net/jdk/pull/296/files/71db0303..4e2aabbb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=02-03 Stats: 36 lines in 2 files changed: 35 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/296.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/296/head:pull/296 PR: https://git.openjdk.java.net/jdk/pull/296 From kim.barrett at oracle.com Thu Sep 24 08:59:15 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 24 Sep 2020 04:59:15 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> Message-ID: <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> > On Sep 23, 2020, at 2:10 AM, Eric Liu wrote: > > Hi Kim, > > Sorry for the delay. > > This patch removes a redundant string copy in NetworkInterface.c to avoid string-truncation > warning. Other warnings we talked before, which are unable to completely fix in different version > of gcc, I have to use pragma to suppress them as a workaround. > > This patch now could compile with gcc-7, gcc-8, gcc-9, gcc-10 both with or without asan. > > [TESTS] > Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. > No new failure found. > > http://cr.openjdk.java.net/~qfeng/ericliu/jdk/stringop_trunc/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8252407 If possible, my preference would be to avoid the pragma cruft and write the code in such a way that gcc8/9 without asan doesn't warn, and gcc10 doesn't warn with or without asan. I've kind of lost track in the discussion of all the variants whether that's actually feasible. From eosterlund at openjdk.java.net Thu Sep 24 09:00:35 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 24 Sep 2020 09:00:35 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v3] In-Reply-To: <6IokOfdx_1Sx_F5DisPJJTycPJ8CjdJsXzUlxUyMR_U=.c02a3059-c973-40d3-85d7-4e3925e7984c@github.com> References: <6IokOfdx_1Sx_F5DisPJJTycPJ8CjdJsXzUlxUyMR_U=.c02a3059-c973-40d3-85d7-4e3925e7984c@github.com> Message-ID: <6K3BEwbUiMfs96Yb3lG8kINGvrwokpvMZ9wvznsRjSU=.102dc9b0-3b0c-4606-bfff-becd03b5ad2f@github.com> On Wed, 23 Sep 2020 15:45:12 GMT, Albert Mingkun Yang wrote: >> Marked as reviewed by stefank (Reviewer). > > Given names like `StackWatermarkSet::lowest_watermark`, I wonder if some diagrams could be provided in the code > comments for `class StackWatermarks` so that readers will have the correct mental pictures of the layout of stack > frames and watermarks. Some docs on `volatile uint32_t _state;` in `StackWatermark` would be nice, such as what info > is encoded in this state, typical state transitions, who can access this state (tying it to volatile) etc. > I wonder if it's possible to remove `bool _is_done;` in `StackWatermarkFramesIterator`; just calling `is_done()` on the > underlying frame stream seems cleaner. Thanks for reviewing Albert. > Given names like `StackWatermarkSet::lowest_watermark`, I wonder if some diagrams could be provided in the code > comments for `class StackWatermarks` so that readers will have the correct mental pictures of the layout of stack > frames and watermarks. Added some further comments and diagrams. > Some docs on `volatile uint32_t _state;` in `StackWatermark` would be nice, such as what info is encoded in this state, > typical state transitions, who can access this state (tying it to volatile) etc. Added some comments about the state. > I wonder if it's possible to remove `bool _is_done;` in `StackWatermarkFramesIterator`; just calling `is_done()` on the > underlying frame stream seems cleaner. Unfortunately this is not possible. The underlying frame stream is_done() function is not idempotent. It alters the state of the iteration as a side effect of asking the question whether it is done or not. The first time it reaches past the last frame it will report true, and the second time it will report false. So for that use to be valid, it is assumed that you only ask if you are is_done() once. But the way I use it, I ask this question potentially more than once after we are done, and expect it to return false consistently. That's why I read it once from the stream and cache the result that I use. One might argue that the underlying stream class has undesirable behaviour, but fixing that seemed outside the scope of this RFE. I have had too many rabbit holes already. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From Alan.Bateman at oracle.com Thu Sep 24 09:32:05 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Sep 2020 10:32:05 +0100 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> Message-ID: On 24/09/2020 09:59, Kim Barrett wrote: > If possible, my preference would be to avoid the pragma cruft and write the > code in such a way that gcc8/9 without asan doesn't warn, and gcc10 doesn't > warn with or without asan. I've kind of lost track in the discussion of all > the variants whether that's actually feasible. > > I agree, the program cruft in NetworkInterface.c is unmaintainable and not the right place for it. -Alan. From stefank at openjdk.java.net Thu Sep 24 10:17:44 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 24 Sep 2020 10:17:44 GMT Subject: RFR: 8253555: Make ByteSize and WordSize typed scoped enums In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 06:23:34 GMT, Stefan Karlsson wrote: > It's a common bug in HotSpot that byte values are used when the code asks for words, and vice versa. One attempt to > prevent that has been to use the classes ByteSize and WordSize, to make the compiler detect these problems. The current > implementation is a bit problematic, because both types are int typedefs in release builds, and wrapper classes in > debug builds. This means that we can't use these types in overload resolution. I propose that we fix that by changing > the type to scoped enums with a fixed int type. The compiler will then be apple to completely separate ByteSize, > WordSize, and ints. We also don't need different code in release vs debug builds. FWIW, I once created a size_t > versions of these classes and annotated all the metaspace code with these types. This experiment flushed out a handful > of bugs (some of them were known and the reason for trying that experiment) There are some controversy about having > these classes around. See for example: JDK-8041956: remove ByteSize and WordSize classes I hope we can stay away from > that discussion in this PR. Hmm. All these comments came through the mailing list bot, and I can't address them individually. :( I implemented the minimally necessary for this. The templateInterpreterGenerator_arm.cpp change was needed to get this to compile. The surrounding code also performs an in_bytes call for the add. ------------- PR: https://git.openjdk.java.net/jdk/pull/328 From stefank at openjdk.java.net Thu Sep 24 10:32:45 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 24 Sep 2020 10:32:45 GMT Subject: RFR: 8253555: Make ByteSize and WordSize typed scoped enums In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 10:14:41 GMT, Stefan Karlsson wrote: >> It's a common bug in HotSpot that byte values are used when the code asks for words, and vice versa. One attempt to >> prevent that has been to use the classes ByteSize and WordSize, to make the compiler detect these problems. The current >> implementation is a bit problematic, because both types are int typedefs in release builds, and wrapper classes in >> debug builds. This means that we can't use these types in overload resolution. I propose that we fix that by changing >> the type to scoped enums with a fixed int type. The compiler will then be apple to completely separate ByteSize, >> WordSize, and ints. We also don't need different code in release vs debug builds. FWIW, I once created a size_t >> versions of these classes and annotated all the metaspace code with these types. This experiment flushed out a handful >> of bugs (some of them were known and the reason for trying that experiment) There are some controversy about having >> these classes around. See for example: JDK-8041956: remove ByteSize and WordSize classes I hope we can stay away from >> that discussion in this PR. > > Hmm. All these comments came through the mailing list bot, and I can't address them individually. :( I implemented the > minimally necessary for this. The templateInterpreterGenerator_arm.cpp change was needed to get this to compile. The > surrounding code also performs an in_bytes call for the add. I'll revert the templateInterpreterGenerator_arm.cpp change, and fix it by removing the #ifdef ASSERT around the AsmOperand constructor. ------------- PR: https://git.openjdk.java.net/jdk/pull/328 From github.com+4676506+javeleon at openjdk.java.net Thu Sep 24 10:42:17 2020 From: github.com+4676506+javeleon at openjdk.java.net (Allan Gregersen) Date: Thu, 24 Sep 2020 10:42:17 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> <_luUft9Qs0GYU6GwUs1PLMDGel1salhJg8X Gxsc3h0k=.c175a93b-0736-4549-8316-ac01692f6b9e@github.com> <9tn1QTeKWk7DB7fWgyw7O_PSuN5Y7nTUmvvZSuuWqHM=.e9a7dbbe-c8ec-40eb-aee4-74e08892db08@github.com> Message-ID: On Thu, 24 Sep 2020 08:02:13 GMT, Allan Gregersen wrote: >> John there is a lot to be said here in the solution domain. But before we get there, I want to get answers about the >> problem domain, so I know if we are solving a real or imaginary problem. The crucial question it boils down to is: "is >> remote thread stack sampling with locals needed in the non-debugger case"? If so, we can start discussing the solution >> domain of that. But I suspect we already have all the APIs in place that are needed. > > A lot of good comments here. Thanks! > > I agree that we should look at the problem domain first. Hence, let's look at the use-cases that was brought up once > more. > 1. The Truffle debugger (not to be confused with a Java host debugger) in general needs to access all live stack traces > for all guest-language threads and read/write access to local variables. > 2. Some Truffle guest languages need to access all live objects (e.g. Ruby). Espresso also needs this for implementing > e.g. getReferringObjects (through the debugger though) etc. > Onto discussing potential solutions: > > After discussing the capabilities of JVMTI internally, it seems that the current implementation of getting locals might > not be able to return anything for escape-analyzed objects. This obviously poses a serious limitation for Truffle given > the fact that this is a corner-stone in GraalVM. I take it this played a big role in introducing iterateFrames (current > thread only) in JVMCI a while back. Even for the debugger case we would need JVMTI to guarantee the following: 1. A > safe suspension mechanism for all target threads (what if two debuggers are connected at the same time?) that would > span the entirety of getAllStackTraces + fetching all locals for all frames. I don't see how something like > suspendThreadList would provide the safe guards that we would need here. 2. A bulk getAllLocals to avoid fetching all > stack traces + retrieving all locals in bulk for all frames. Given that Truffle/GraalVM will continue to support Java > 8 for quite some time, this new API should probably be exposed through JVMCI and backported like it was done for > iterateFrames regardless of the underlying implementation. Note: In the current PR we need to refactor > materializeVirtualObjects into using VM operations to guarantee that we run stack walking and sanity checks for > locating the frame in question at a safe point. I'll hold my horses a bit on that until there is a consensus on where > this is going. It?s important to note that this PR is about making changes to JVMCI which is internal API and not part of the JavaSE API. With that framing let's address the questions that came up: - is remote thread stack sampling with locals needed in the non-debugger case? Yes (see previous comment). What existing APIs are in place for this? - How does the requesting thread get permission to look inside the target thread? (New security analysis.) No permission needed - JVMCI is a privileged API that has ?boot loader? access. - At what point does the target thread get its state taken as a snapshot? Any random moment? The snapshot of threads is taken at a safepoint (much like Thread.getAllStackTraces() which does not mention safepoints either) - How is the target thread ?held still? while it is being sampled? (And then, ?Where is this term ?safepoint? defined in the JVM specifications??) See above. - Can a target thread refuse or defer the request, to defend some particular encapsulation? No - see above. - How is that state stored, and what are the time and space costs for such storage? The state is stored within [HotSpotStackFrameReference](https://github.com/openjdk/jdk/blob/master/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotStackFrameReference.java) instances. its about the same time and cost as java.lang.LiveStackFrameInfo. - What happens if the requesting thread just wants to look at a few bits? Do we still buffer up a whole backtrace? In the suggested API you can 1) limit the number of frames to capture, 2) skip the first N top frames 3) add an array of methods as argument that any frames seen on stack before those are not included and 4) add an array of methods as arguments controlling the exact methods to include in the result. - Or, is the target thread required to execute callbacks provided by the requesting thread, with a temporary view, and if so, that limits are there on such callbacks? No callbacks. - Can the observation process ever cause the target thread to fail, or will any and all failures (OOME, SOE, etc.) be attributed to the requesting thread? No. All failures will be attributed to the requesting thread. - What happens if the requesting thread makes two requests in a row: Are there any guarantees about relations between the two sets of results? (To be fair, this is also an issue with the self-walking case.) No guarantees. - What happens if the requesting thread asks to change a value in a frame or pop or re-invoke or replace a frame? (Not allowed in the self-walking case either, but a plausible extension.) No support for this. The snapshot is read-only. ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From coleenp at openjdk.java.net Thu Sep 24 10:49:11 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 24 Sep 2020 10:49:11 GMT Subject: Integrated: 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 15:12:57 GMT, Coleen Phillimore wrote: > These functions are also unused and in the thread_platform.hpp files. _last_Java_sp and _last_Java_fp are set in the > assembly code for platforms that use these (x86, arm32 and aarch64). The shared runtime code never sets these, or > should it. last_Java_fp() is always called through JavaFrameAnchor, so that function is not needed. > last_Java_fp_offset() is used and needs to be in these platform dependent files because not all platforms save > last_Java_fp. Tested with build on arm32 and tier1 on Oracle platforms including aarch64. This pull request has now been integrated. Changeset: bf442c5b Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/bf442c5b Stats: 35 lines in 9 files changed: 0 ins; 28 del; 7 mod 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc Reviewed-by: rehn, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/324 From stefank at openjdk.java.net Thu Sep 24 10:59:48 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 24 Sep 2020 10:59:48 GMT Subject: RFR: 8253555: Make ByteSize and WordSize typed scoped enums [v2] In-Reply-To: References: Message-ID: > It's a common bug in HotSpot that byte values are used when the code asks for words, and vice versa. One attempt to > prevent that has been to use the classes ByteSize and WordSize, to make the compiler detect these problems. The current > implementation is a bit problematic, because both types are int typedefs in release builds, and wrapper classes in > debug builds. This means that we can't use these types in overload resolution. I propose that we fix that by changing > the type to scoped enums with a fixed int type. The compiler will then be apple to completely separate ByteSize, > WordSize, and ints. We also don't need different code in release vs debug builds. FWIW, I once created a size_t > versions of these classes and annotated all the metaspace code with these types. This experiment flushed out a handful > of bugs (some of them were known and the reason for trying that experiment) There are some controversy about having > these classes around. See for example: JDK-8041956: remove ByteSize and WordSize classes I hope we can stay away from > that discussion in this PR. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Review 1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/328/files - new: https://git.openjdk.java.net/jdk/pull/328/files/0b32240f..26f2695f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=328&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=328&range=00-01 Stats: 55 lines in 4 files changed: 41 ins; 4 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/328.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/328/head:pull/328 PR: https://git.openjdk.java.net/jdk/pull/328 From stefank at openjdk.java.net Thu Sep 24 10:59:48 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 24 Sep 2020 10:59:48 GMT Subject: RFR: 8253555: Make ByteSize and WordSize typed scoped enums In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 10:30:20 GMT, Stefan Karlsson wrote: >> Hmm. All these comments came through the mailing list bot, and I can't address them individually. :( I implemented the >> minimally necessary for this. The templateInterpreterGenerator_arm.cpp change was needed to get this to compile. The >> surrounding code also performs an in_bytes call for the add. > > I'll revert the templateInterpreterGenerator_arm.cpp change, and fix it by removing the #ifdef ASSERT around the > AsmOperand constructor. I pushed the suggestion that I found relevant for my review, and put the rest in a new RFE [JDK-8253593]. ------------- PR: https://git.openjdk.java.net/jdk/pull/328 From eosterlund at openjdk.java.net Thu Sep 24 11:18:55 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 24 Sep 2020 11:18:55 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> <_luUft9Qs0GYU6GwUs1PLMDGel1salhJg8X Gxsc3h0k=.c175a93b-0736-4549-8316-ac01692f6b9e@github.com> <9tn1QTeKWk7DB7fWgyw7O_PSuN5Y7nTUmvvZSuuWqHM=.e9a7dbbe-c8ec-40eb-aee4-74e08892db08@github.com> Message-ID: On Thu, 24 Sep 2020 08:02:13 GMT, Allan Gregersen wrote: > A lot of good comments here. Thanks! > > I agree that we should look at the problem domain first. Hence, let's look at the use-cases that was brought up once > more. > 1. The Truffle debugger (not to be confused with a Java host debugger) in general needs to access all live stack traces > for all guest-language threads and read/write access to local variables. Right, and these needs should be satisfied by the JVMTI APIs that were designed to do exactly this. Right? > 2. Some Truffle guest languages need to access all live objects (e.g. Ruby). Espresso also needs this for implementing > e.g. getReferringObjects (through the debugger though) etc. This sounds like a completely different use case. You want to get the stack locals to traverse all objects. But stacks are only one root set out of many. Keeping the HotSpot root sets in sync outside the VM, across multiple JDK versions, does not sound like something you want to do unless you really have to. Fortunately, this is yet another wheel that has already been invented. For example, you can use JVMTI FollowReferences to perform a traversal through the heap from roots (that we maintain in the VM), and get callbacks for each visited object. You can also use JVMTI IterateThroughHeap to iterate over the heap and report the objects found with callbacks. Over the years, there have been many fun interactions with especially (concurrent) reference processing (weak/phantom references, finalizers, class unloading, which root sets should and should not be included, that constantly changes) that I really don't think you want to re-discover, by performing yet another heap walk, outside of the VM. I think just plugging in to this wheel sounds more desirable for this use case. I also don't get how you can even get a snapshot of live objects, if you allow threads to run concurrently. You mention it is so important to get a snapshot of all thread locals for this to work the way you want it to. But it's seemingly not just the roots you need a snapshot of, if you allow the object graph to concurrently mutate. The JVMTI APIs solve all of this. You should be able to just plug in to that. Right? > > Onto discussing potential solutions: > > After discussing the capabilities of JVMTI internally, it seems that the current implementation of getting locals might > not be able to return anything for escape-analyzed objects. This obviously poses a serious limitation for Truffle given > the fact that this is a corner-stone in GraalVM. I take it this played a big role in introducing iterateFrames (current > thread only) in JVMCI a while back. The problem you describe is what _jvmti_can_access_local_variables capability is for. A debugger will have this set, and hence while debugging, we just don't scalarize stuff, so all objects are simply materialized. JVMCI already exposes this variable and presumably plays by the same rules. > Even for the debugger case we would need JVMTI to guarantee the following: > > 1. A safe suspension mechanism for all target threads (what if two debuggers are connected at the same time?) that > would span the entirety of getAllStackTraces + fetching all locals for all frames. I don't see how something like > suspendThreadList would provide the safe guards that we would need here. > > 2. A bulk getAllLocals to avoid fetching all stack traces + retrieving all locals in bulk for all frames. Let me guess... these requirements you just stated are for getting a stable set of roots for the heap walk you want to perform outside of the VM? Or is there any other client that needs the snapshotness of the thread dumps? If I'm right, then there are many more roots that can mutate other than stacks... and the edges in the object graph can also mutate. How are you going to ensure proper traversal of all objects without injecting GC barriers into mutating accesses? I think what you really want is an API that can give you a snapshot heap iteration from roots (including stacks but also a whole bunch of other roots that you really don't want to know about). And JVMTI provides that API, as discussed above. Let's see if my guessing was right... > Given that Truffle/GraalVM will continue to support Java 8 for quite some time, this new API should probably be exposed > through JVMCI and backported like it was done for iterateFrames regardless of the underlying implementation. Let's continue discussing the problem domain first. Obviously, JVMTI has been around for ages. So let's see what problems we really have to solve, once our understanding of the problems you try to solve converge. > Note: In the current PR we need to refactor materializeVirtualObjects into using VM operations to guarantee that we run > stack walking and sanity checks for locating the frame in question at a safe point. I'll hold my horses a bit on that > until there is a consensus on where this is going. I also can't find the definition of some functions and wonder if all files are really in the PR. Seems like they are not, unless the GUI is bugged out. But let's leave the whole discussion of the code in this PR to a point where we know what code if any is actually going to change. Hope this helps. I hope we can start to converge a bit in the problem domain. ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From coleenp at openjdk.java.net Thu Sep 24 11:19:43 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 24 Sep 2020 11:19:43 GMT Subject: RFR: 8253402: Convert vmSymbols::SID to enum class In-Reply-To: References: Message-ID: On Mon, 21 Sep 2020 07:07:25 GMT, Ioi Lam wrote: > Convert `vmSymbols::SID` to an `enum class` to provide better type safety. > > - The original enum type `vmSymbols::SID` cannot be forward-declared. I moved it out of the `vmSymbols` class and > renamed, so now it can be forward-declared as `enum class vmSymbolID : int;`, without including the large vmSymbols.hpp > file. > - This also breaks the mutual dependency between the `vmSymbols` and `vmIntrinsics` classes. Now the declaration of > `vmIntrinsics` can be moved from vmSymbols.hpp to vmIntrinsics.hpp, where it naturally belongs. > - Type-safe enumeration (contributed by Kim Barrett) > for (vmSymbolID index : vmSymbolsIterator()) { > vm_symbol_index[as_int(index)] = index; > } > - I moved `vmSymbols::_symbols[]` to `Symbol::_vm_symbols[]`, and made it accessible via `Symbol::vm_symbol_at()`. This > way, header files (e.g. fieldInfo.hpp) that need to convert from `vmSymbolID` to `Symbol*` don't need to include the > large vmSymbols.hpp file. > - I changed the `VM_SYMBOL_ENUM_NAME` macro so that the users don't need to explicitly add the `vmSymbolID::` scope. > - I removed many unnecessary casts between `int` and `vmSymbolID`. > - The remaining casts are done via `vmSymbol::as_int()` and `vmSymbols::as_SID()` with range checks. > > ----- > If this is successful, I will do the same for `vmIntrinsics::ID`. Looks like a nice improvement to me. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/276 From coleenp at openjdk.java.net Thu Sep 24 11:19:43 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 24 Sep 2020 11:19:43 GMT Subject: RFR: 8253402: Convert vmSymbols::SID to enum class In-Reply-To: References: <2RctRAOHDMDgW1Qu57RDcOF1Uns4pjAZfR6Yg9dTb_0=.d3f1bcdd-39b8-4504-8f1a-76541bb5c55e@github.com> Message-ID: On Wed, 23 Sep 2020 17:05:49 GMT, Ioi Lam wrote: >> src/hotspot/share/ci/ciObjectFactory.hpp line 32: >> >>> 30: #include "utilities/growableArray.hpp" >>> 31: >>> 32: enum class vmSymbolID : int; >> >> Do you need this declaration to avoid #include "classfile/vmSymbols.hpp" ? > > Yes, that's the intention, because vmSymbols.hpp is big. > > I am thinking whether I should move such forward declarations of enums into globalDefinitions.hpp, so header files that > use `vmSymbolID` don't need to know that the base type is `int`. No, don't move them to globalDefinitions.hpp, only have the forward declarations where they're used. So this is like a class forward declaration? neat. ------------- PR: https://git.openjdk.java.net/jdk/pull/276 From pliden at openjdk.java.net Thu Sep 24 11:32:46 2020 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 24 Sep 2020 11:32:46 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v4] In-Reply-To: <4bjUBhVYYs27w4gQ3YV-O4jIece8dzeNobbyuvz0AZY=.75e05368-efbc-4b9c-8a72-4d947a5f3717@github.com> References: <4bjUBhVYYs27w4gQ3YV-O4jIece8dzeNobbyuvz0AZY=.75e05368-efbc-4b9c-8a72-4d947a5f3717@github.com> Message-ID: On Thu, 24 Sep 2020 08:55:03 GMT, Erik ?sterlund wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, >> and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into >> more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to >> expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in >> the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized >> automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization >> processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is >> actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception >> handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC >> threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming >> of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the >> watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll >> word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it >> brought (and is only possible on TSO machines). So left that one out. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Review: Albert CR 1 I had also pre-reviewed, but did a final semi-quick review. Looks good overall. Just found a couple of minor nitpicks. src/hotspot/share/gc/z/zBarrierSet.cpp line 86: > 84: if (thread->is_Java_thread()) { > 85: JavaThread* const jt = thread->as_Java_thread(); > 86: StackWatermark* watermark = new ZStackWatermark(jt); Please add a const here. src/hotspot/share/gc/z/zStackWatermark.cpp line 43: > 41: nmethod* const nm = cb->as_nmethod_or_null(); > 42: if (nm != NULL) { > 43: bool result = _bs_nm->nmethod_entry_barrier(nm); Please add a const here. src/hotspot/share/gc/z/zVerify.cpp line 88: > 86: virtual void do_thread(Thread* thread); > 87: > 88: bool verify_fixed() const { return _verify_fixed; } Please turn this into three lines. src/hotspot/share/gc/z/zVerify.cpp line 114: > 112: _last_good(0), > 113: _verifying_bad_frames(false) { > 114: ZStackWatermark* stack_watermark = StackWatermarkSet::get(jt, StackWatermarkKind::gc); Please add const here. src/hotspot/share/gc/z/zVerify.cpp line 151: > 149: // last processed frame or not. Before it is reached, we expect everything to > 150: // be good. After reaching it, we expect everything to be bad. > 151: uintptr_t sp = reinterpret_cast(frame.sp()); Please add const here. ------------- Marked as reviewed by pliden (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/296 From kbarrett at openjdk.java.net Thu Sep 24 11:51:04 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 24 Sep 2020 11:51:04 GMT Subject: RFR: 8253555: Make ByteSize and WordSize typed scoped enums [v2] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 10:59:48 GMT, Stefan Karlsson wrote: >> It's a common bug in HotSpot that byte values are used when the code asks for words, and vice versa. One attempt to >> prevent that has been to use the classes ByteSize and WordSize, to make the compiler detect these problems. The current >> implementation is a bit problematic, because both types are int typedefs in release builds, and wrapper classes in >> debug builds. This means that we can't use these types in overload resolution. I propose that we fix that by changing >> the type to scoped enums with a fixed int type. The compiler will then be apple to completely separate ByteSize, >> WordSize, and ints. We also don't need different code in release vs debug builds. FWIW, I once created a size_t >> versions of these classes and annotated all the metaspace code with these types. This experiment flushed out a handful >> of bugs (some of them were known and the reason for trying that experiment) There are some controversy about having >> these classes around. See for example: JDK-8041956: remove ByteSize and WordSize classes I hope we can stay away from >> that discussion in this PR. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Review 1 I'd intended suggesting the AsmOperand didn't need to be #ifdef ASSERT anymore, but forgot about that when suggesting removing the in_bytes conversion for const_offset. You figured out what I wanted despite that. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/328 From github.com+4676506+javeleon at openjdk.java.net Thu Sep 24 12:03:09 2020 From: github.com+4676506+javeleon at openjdk.java.net (Allan Gregersen) Date: Thu, 24 Sep 2020 12:03:09 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> <_luUft9Qs0GYU6GwUs1PLMDGel1salhJg8X Gxsc3h0k=.c175a93b-0736-4549-8316-ac01692f6b9e@github.com> <9tn1QTeKWk7DB7fWgyw7O_PSuN5Y7nTUmvvZSuuWqHM=.e9a7dbbe-c8ec-40eb-aee4-74e08892db08@github.com> Message-ID: On Thu, 24 Sep 2020 11:16:17 GMT, Erik ?sterlund wrote: >The problem you describe is what _jvmti_can_access_local_variables capability is for. A debugger will have this set, >and hence while debugging, we just don't scalarize stuff, so all objects are simply materialized. JVMCI already exposes >this variable and presumably plays by the same rules. A few questions pops into my mind: 1. What is the performance implications on setting _jvmti_can_access_local_variables capability? More specifically, does this capability kill off escape analysis for a GraalVM? 2. When we have multiple Truffle contexts running, including but not limited to different guest languages, can we make sure that escape analysis is only switched off on very specific parts of the host system with this set and can we enable/disable this capability on the fly? ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From coleenp at openjdk.java.net Thu Sep 24 12:16:24 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 24 Sep 2020 12:16:24 GMT Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v2] In-Reply-To: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> Message-ID: > That the monitor has already been unlocked, or is a null stacklock monitor has been already checked in the caller, so > the code that makes it a JRT_ENTRY_NO_ASYNC is unnecessary. > Making it a JRT_LEAF like the compiled method entries makes it safer. We know it can never safepoint and > unintentionally install a async exception. > Tested with tier1-6. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/320/files - new: https://git.openjdk.java.net/jdk/pull/320/files/847442da..a54ae7cd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=320&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=320&range=00-01 Stats: 17 lines in 2 files changed: 15 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/320.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/320/head:pull/320 PR: https://git.openjdk.java.net/jdk/pull/320 From rehn at openjdk.java.net Thu Sep 24 12:17:05 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 24 Sep 2020 12:17:05 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v4] In-Reply-To: <4bjUBhVYYs27w4gQ3YV-O4jIece8dzeNobbyuvz0AZY=.75e05368-efbc-4b9c-8a72-4d947a5f3717@github.com> References: <4bjUBhVYYs27w4gQ3YV-O4jIece8dzeNobbyuvz0AZY=.75e05368-efbc-4b9c-8a72-4d947a5f3717@github.com> Message-ID: On Thu, 24 Sep 2020 08:55:03 GMT, Erik ?sterlund wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, >> and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into >> more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to >> expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in >> the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized >> automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization >> processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is >> actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception >> handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC >> threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming >> of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the >> watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll >> word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it >> brought (and is only possible on TSO machines). So left that one out. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Review: Albert CR 1 Looks good. ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/296 From coleenp at openjdk.java.net Thu Sep 24 12:19:27 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 24 Sep 2020 12:19:27 GMT Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v2] In-Reply-To: References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> <86XUy7L61xxgpXo7p95CX02jc0gBIP5V_dZrcFQtD8g=.661acf40-a115-46d2-b02a-1b8363faa988@github.com> Message-ID: On Wed, 23 Sep 2020 20:13:37 GMT, Coleen Phillimore wrote: >> Right, looks like the UseHeavyMonitors case in unlock_object misses the "Free entry" part. >> >> I believe this is how it's supposed to work: >> - TemplateTable::monitorexit only uses unlock_object if the obj is not null and it is found in the monitor section on >> stack. >> - unlock_object should clear the obj field on stack ("Free entry" on x86) >> - when calling monitorexit for the same unlocked obj, TemplateTable::monitorexit shouldn't find it on stack any more and >> throw the exception >> >> Ah, we have "elem->set_obj(NULL);" in InterpreterRuntime::monitorexit. So this should also cover the UseHeavyMonitors >> case. > >> Ah, we have "elem->set_obj(NULL);" in InterpreterRuntime::monitorexit. So this should also cover the UseHeavyMonitors >> case. > > I found out the hard way that this line is needed :) I pushed a revision that is what I think it should do. If the monitor has been unlocked by JNI code, just like other handing for JNI failures, like void ObjectSynchronizer::release_monitors_owned_by_thread, we should allow the code to continue, and give an error if CheckJNICalls is true. ------------- PR: https://git.openjdk.java.net/jdk/pull/320 From eosterlund at openjdk.java.net Thu Sep 24 12:22:22 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 24 Sep 2020 12:22:22 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> <_luUft9Qs0GYU6GwUs1PLMDGel1salhJg8X Gxsc3h0k=.c175a93b-0736-4549-8316-ac01692f6b9e@github.com> <9tn1QTeKWk7DB7fWgyw7O_PSuN5Y7nTUmvvZSuuWqHM=.e9a7dbbe-c8ec-40eb-aee4-74e08892db08@github.com> Message-ID: On Thu, 24 Sep 2020 12:00:22 GMT, Allan Gregersen wrote: > >The problem you describe is what _jvmti_can_access_local_variables capability is for. A debugger will have this set, > >and hence while debugging, we just don't scalarize stuff, so all objects are simply materialized. JVMCI already exposes > >this variable and presumably plays by the same rules. > > > > A few questions pops into my mind: > > > > 1. What is the performance implications on setting _jvmti_can_access_local_variables capability? More specifically, > does this capability kill off escape analysis for a GraalVM? Yes, it will disable escape analysis... when you are running in the debugger. > 2. When we have multiple Truffle contexts running, including but not limited to different guest languages, can we make > sure that escape analysis is only switched off on very specific parts of the host system with this set and can we > enable/disable this capability on the fly? Why do you care to isolate the performance cost of debugging so tightly? Are you trying to enable some kind of use case where you are mixing development and production execution in the same JVM, so some code can run at optimal performance in production, driving a heavy production workload, while someone is single stepping other buggy development code in the debugger? ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From eosterlund at openjdk.java.net Thu Sep 24 12:27:42 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 24 Sep 2020 12:27:42 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v4] In-Reply-To: References: <4bjUBhVYYs27w4gQ3YV-O4jIece8dzeNobbyuvz0AZY=.75e05368-efbc-4b9c-8a72-4d947a5f3717@github.com> Message-ID: On Thu, 24 Sep 2020 11:29:36 GMT, Per Liden wrote: > I had also pre-reviewed, but did a final semi-quick review. Looks good overall. Just found a couple of minor nitpicks. Thansk for the review Per. I uploaded fixes to your nitpicks. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From eosterlund at openjdk.java.net Thu Sep 24 12:27:42 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 24 Sep 2020 12:27:42 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v5] In-Reply-To: References: Message-ID: > This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. > https://openjdk.java.net/jeps/376). > Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, > and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into > more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to > expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in > the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized > automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization > processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is > actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception > handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC > threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming > of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the > watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll > word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it > brought (and is only possible on TSO machines). So left that one out. Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Review: Per CR 1 - Merge branch 'master' into 8253180_conc_stack_scanning - Review: Albert CR 1 - Review: SteafanK CR 2 - Merge branch 'master' into 8253180_conc_stack_scanning - Review: SteafanK CR 1 - 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing ------------- Changes: https://git.openjdk.java.net/jdk/pull/296/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=04 Stats: 2665 lines in 129 files changed: 2116 ins; 289 del; 260 mod Patch: https://git.openjdk.java.net/jdk/pull/296.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/296/head:pull/296 PR: https://git.openjdk.java.net/jdk/pull/296 From eosterlund at openjdk.java.net Thu Sep 24 12:27:43 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 24 Sep 2020 12:27:43 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v4] In-Reply-To: References: <4bjUBhVYYs27w4gQ3YV-O4jIece8dzeNobbyuvz0AZY=.75e05368-efbc-4b9c-8a72-4d947a5f3717@github.com> Message-ID: On Thu, 24 Sep 2020 12:23:50 GMT, Erik ?sterlund wrote: > Looks good. Thanks for the review Robbin. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From neliasso at openjdk.java.net Thu Sep 24 12:37:45 2020 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Thu, 24 Sep 2020 12:37:45 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v5] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 12:27:42 GMT, Erik ?sterlund wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, >> and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into >> more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to >> expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in >> the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized >> automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization >> processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is >> actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception >> handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC >> threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming >> of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the >> watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll >> word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it >> brought (and is only possible on TSO machines). So left that one out. > > Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains seven commits: > - Review: Per CR 1 > - Merge branch 'master' into 8253180_conc_stack_scanning > - Review: Albert CR 1 > - Review: SteafanK CR 2 > - Merge branch 'master' into 8253180_conc_stack_scanning > - Review: SteafanK CR 1 > - 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing Marked as reviewed by neliasso (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From neliasso at openjdk.java.net Thu Sep 24 12:37:46 2020 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Thu, 24 Sep 2020 12:37:46 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v4] In-Reply-To: References: <4bjUBhVYYs27w4gQ3YV-O4jIece8dzeNobbyuvz0AZY=.75e05368-efbc-4b9c-8a72-4d947a5f3717@github.com> Message-ID: <6FaxSkAK5MeWpCUSBoiAM8md6ynKUNG7bC1bPcFUoh0=.c9e57775-0adb-4b14-a3e1-e0ec2d5413ef@github.com> On Thu, 24 Sep 2020 12:24:40 GMT, Erik ?sterlund wrote: >>> I had also pre-reviewed, but did a final semi-quick review. Looks good overall. Just found a couple of minor nitpicks. >> >> Thansk for the review Per. I uploaded fixes to your nitpicks. > >> Looks good. > > Thanks for the review Robbin. I did a pre-reviewed of the compiler parts, and have now done a second reading. The compiler parts looks good! ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From coleenp at openjdk.java.net Thu Sep 24 12:37:47 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 24 Sep 2020 12:37:47 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v5] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 12:27:42 GMT, Erik ?sterlund wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, >> and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into >> more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to >> expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in >> the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized >> automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization >> processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is >> actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception >> handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC >> threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming >> of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the >> watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll >> word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it >> brought (and is only possible on TSO machines). So left that one out. > > Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains seven commits: > - Review: Per CR 1 > - Merge branch 'master' into 8253180_conc_stack_scanning > - Review: Albert CR 1 > - Review: SteafanK CR 2 > - Merge branch 'master' into 8253180_conc_stack_scanning > - Review: SteafanK CR 1 > - 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing src/hotspot/share/runtime/mutexLocker.cpp line 249: > 247: def(Patching_lock , PaddedMutex , special, true, _safepoint_check_never); // used for > safepointing and code patching. 248: def(CompiledMethod_lock , PaddedMutex , special-1, true, > _safepoint_check_never); 249: def(Service_lock , PaddedMonitor, tty-2, true, > _safepoint_check_never); // used for service thread operations @pchilano Look. tty-2 ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From eosterlund at openjdk.java.net Thu Sep 24 12:37:46 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 24 Sep 2020 12:37:46 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v4] In-Reply-To: <6FaxSkAK5MeWpCUSBoiAM8md6ynKUNG7bC1bPcFUoh0=.c9e57775-0adb-4b14-a3e1-e0ec2d5413ef@github.com> References: <4bjUBhVYYs27w4gQ3YV-O4jIece8dzeNobbyuvz0AZY=.75e05368-efbc-4b9c-8a72-4d947a5f3717@github.com> <6FaxSkAK5MeWpCUSBoiAM8md6ynKUNG7bC1bPcFUoh0=.c9e57775-0adb-4b14-a3e1-e0ec2d5413ef@github.com> Message-ID: On Thu, 24 Sep 2020 12:32:36 GMT, Nils Eliasson wrote: > I did a pre-reviewed of the compiler parts, and have now done a second reading. > > The compiler parts looks good! Thanks for the review, Nils. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From tschatzl at openjdk.java.net Thu Sep 24 12:41:45 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 24 Sep 2020 12:41:45 GMT Subject: RFR: 8253555: Make ByteSize and WordSize typed scoped enums [v2] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 10:59:48 GMT, Stefan Karlsson wrote: >> It's a common bug in HotSpot that byte values are used when the code asks for words, and vice versa. One attempt to >> prevent that has been to use the classes ByteSize and WordSize, to make the compiler detect these problems. The current >> implementation is a bit problematic, because both types are int typedefs in release builds, and wrapper classes in >> debug builds. This means that we can't use these types in overload resolution. I propose that we fix that by changing >> the type to scoped enums with a fixed int type. The compiler will then be apple to completely separate ByteSize, >> WordSize, and ints. We also don't need different code in release vs debug builds. FWIW, I once created a size_t >> versions of these classes and annotated all the metaspace code with these types. This experiment flushed out a handful >> of bugs (some of them were known and the reason for trying that experiment) There are some controversy about having >> these classes around. See for example: JDK-8041956: remove ByteSize and WordSize classes I hope we can stay away from >> that discussion in this PR. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Review 1 No need to re-review to fix the typo. src/hotspot/cpu/x86/assembler_x86.hpp line 259: > 257: } > 258: > 259: // The following two overloads are used in connection with the s/two/three ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/328 From coleenp at openjdk.java.net Thu Sep 24 12:52:05 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 24 Sep 2020 12:52:05 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v5] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 12:27:42 GMT, Erik ?sterlund wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, >> and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into >> more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to >> expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in >> the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized >> automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization >> processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is >> actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception >> handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC >> threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming >> of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the >> watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll >> word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it >> brought (and is only possible on TSO machines). So left that one out. > > Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains seven commits: > - Review: Per CR 1 > - Merge branch 'master' into 8253180_conc_stack_scanning > - Review: Albert CR 1 > - Review: SteafanK CR 2 > - Merge branch 'master' into 8253180_conc_stack_scanning > - Review: SteafanK CR 1 > - 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing I looked at the runtime code and it is nicely non-invasive, and makes sense where there are changes. src/hotspot/share/runtime/vframe.hpp line 340: > 338: public: > 339: // Constructors > 340: vframeStream(JavaThread* thread, bool stop_at_java_call_stub = false, bool process_frames = true); I was wondering if you supply arguments to all callers of vframeStream now? It seems like having default parameters is an invitation to errors. Same with RegMap. src/hotspot/share/classfile/javaClasses.cpp line 2440: > 2438: // trace as utilizing vframe. > 2439: #ifdef ASSERT > 2440: vframeStream st(thread, false /* stop_at_java_call_stub */, false /* process_frames */); This is a nit, but could you put the /* stop_at_java_call_stub*/ and /* process_frames */ before the values? Having a bunch of bool parameters seems like it could also become buggy. In linkResolver.hpp we have enums so that the values can be checked and are more explicit at the call sites. Not this change, but can we fix this later to do the same thing? ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From stefank at openjdk.java.net Thu Sep 24 12:57:22 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 24 Sep 2020 12:57:22 GMT Subject: RFR: 8253555: Make ByteSize and WordSize typed scoped enums [v3] In-Reply-To: References: Message-ID: > It's a common bug in HotSpot that byte values are used when the code asks for words, and vice versa. One attempt to > prevent that has been to use the classes ByteSize and WordSize, to make the compiler detect these problems. The current > implementation is a bit problematic, because both types are int typedefs in release builds, and wrapper classes in > debug builds. This means that we can't use these types in overload resolution. I propose that we fix that by changing > the type to scoped enums with a fixed int type. The compiler will then be apple to completely separate ByteSize, > WordSize, and ints. We also don't need different code in release vs debug builds. FWIW, I once created a size_t > versions of these classes and annotated all the metaspace code with these types. This experiment flushed out a handful > of bugs (some of them were known and the reason for trying that experiment) There are some controversy about having > these classes around. See for example: JDK-8041956: remove ByteSize and WordSize classes I hope we can stay away from > that discussion in this PR. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Review 2 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/328/files - new: https://git.openjdk.java.net/jdk/pull/328/files/26f2695f..e798ff83 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=328&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=328&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/328.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/328/head:pull/328 PR: https://git.openjdk.java.net/jdk/pull/328 From stefank at openjdk.java.net Thu Sep 24 12:57:25 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 24 Sep 2020 12:57:25 GMT Subject: RFR: 8253555: Make ByteSize and WordSize typed scoped enums [v2] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 12:37:59 GMT, Thomas Schatzl wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Review 1 > > No need to re-review to fix the typo. Thanks @kimbarrett and @tschatzl for reviewing. > src/hotspot/cpu/x86/assembler_x86.hpp line 259: > >> 257: } >> 258: >> 259: // The following two overloads are used in connection with the > > s/two/three Removed the word instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/328 From mdoerr at openjdk.java.net Thu Sep 24 13:18:49 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 24 Sep 2020 13:18:49 GMT Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v2] In-Reply-To: References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> Message-ID: On Thu, 24 Sep 2020 12:16:24 GMT, Coleen Phillimore wrote: >> That the monitor has already been unlocked, or is a null stacklock monitor has been already checked in the caller, so >> the code that makes it a JRT_ENTRY_NO_ASYNC is unnecessary. >> Making it a JRT_LEAF like the compiled method entries makes it safer. We know it can never safepoint and >> unintentionally install a async exception. >> Tested with tier1-6. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function Please note that complete_monitor_unlocking_C is only called by C2. Other JIT compilers have other functions. SharedRuntime::monitor_exit_helper is used by all ones. I had another question: Shouldn't the call sites in the interpreter use call_VM_leaf instead of call_VM? ------------- PR: https://git.openjdk.java.net/jdk/pull/320 From iklam at openjdk.java.net Thu Sep 24 13:19:43 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 24 Sep 2020 13:19:43 GMT Subject: RFR: 8247912: Make narrowOop a scoped enum [v2] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 15:45:01 GMT, Ioi Lam wrote: > > > Also, should we allow only unsigned types for T? I think using signed types here is prone to error and should be > > > flagged. > > > > > > It turns out we can't restrict it to unsigned types, at least not very easily. For example, > > CDS calls this with an intptr_t value. I suppose CDS could do conversion itself before > > calling this, but that seems a little odd. And I don't know how many more there are after > > changing that one. > > But shouldn't intptr_t be unsigned? I tested with this: Oops, my mistake. I thought `intptr_t` was `int*`, but it's in fact "Integer type capable of holding a value converted from a void pointer and then be converted back to that type with a value that compares equal to the original pointer." ------------- PR: https://git.openjdk.java.net/jdk/pull/273 From eosterlund at openjdk.java.net Thu Sep 24 13:19:47 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 24 Sep 2020 13:19:47 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v5] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 12:45:00 GMT, Coleen Phillimore wrote: >> Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains seven commits: >> - Review: Per CR 1 >> - Merge branch 'master' into 8253180_conc_stack_scanning >> - Review: Albert CR 1 >> - Review: SteafanK CR 2 >> - Merge branch 'master' into 8253180_conc_stack_scanning >> - Review: SteafanK CR 1 >> - 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing > > src/hotspot/share/runtime/vframe.hpp line 340: > >> 338: public: >> 339: // Constructors >> 340: vframeStream(JavaThread* thread, bool stop_at_java_call_stub = false, bool process_frames = true); > > I was wondering if you supply arguments to all callers of vframeStream now? It seems like having default parameters is > an invitation to errors. Same with RegMap. I have tried to have explicit arguments as much as possible. But RegMap and vframeStream seemed to clutter my whole patch if I made them explicit (they are already implicit today). I agree though that having them explicit would be better. But what do you think about doing that in a follow-up cleanup RFE instead? It might reduce the amount of scrolling needed to review this patch. The defaults are on the safe conservative side, so not supplying the extra parameter should not harm you. > src/hotspot/share/classfile/javaClasses.cpp line 2440: > >> 2438: // trace as utilizing vframe. >> 2439: #ifdef ASSERT >> 2440: vframeStream st(thread, false /* stop_at_java_call_stub */, false /* process_frames */); > > This is a nit, but could you put the /* stop_at_java_call_stub*/ and /* process_frames */ before the values? Having a > bunch of bool parameters seems like it could also become buggy. In linkResolver.hpp we have enums so that the values > can be checked and are more explicit at the call sites. Not this change, but can we fix this later to do the same > thing? Per and Stefan would kill me if I put the comments before the value (they explicitly prefer it on the right side of the value). Personally I have no strong preference. And yes, this also sounds like a good follow-up cleanup RFE. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From mbeckwit at openjdk.java.net Thu Sep 24 14:04:22 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Thu, 24 Sep 2020 14:04:22 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6] In-Reply-To: References: Message-ID: <21bX6lTqVC7rs1Cor4HZwmD4cm3_V1rNzSX9shlp03Y=.5aeaaf6c-e42a-4a84-b3ab-b7e6e1c6c706@github.com> > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc - cleanup for 8253457: Remove unimplemented register stack functions - Merge remote-tracking branch 'upstream/master' into jdk-windows - Update orderAccess_windows_aarch64.hpp changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided - 8248787: G1: Workaround MSVC bug Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248670: Windows: Exception handling support on AArch64 Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248660: AArch64: Make _clear_cache and _nop portable Summary: __builtin___clear_cache, etc. Contributed-by: mbeckwit, luhenry, burban - 8248659: AArch64: Extend CPU Feature detection Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248656: Add Windows AArch64 platform support code Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - 8248498: Add build system support for Windows AArch64 Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - ... and 7 more: https://git.openjdk.java.net/jdk/compare/6cee388c...2b662010 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/212/files - new: https://git.openjdk.java.net/jdk/pull/212/files/4da7b89e..2b662010 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=04-05 Stats: 1938 lines in 234 files changed: 652 ins; 841 del; 445 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From rrich at openjdk.java.net Thu Sep 24 14:17:10 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 24 Sep 2020 14:17:10 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v2] In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 05:02:42 GMT, David Holmes wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes based on dholmes' feedback. >> >> EscapeBarrier::sync_and_suspend_all(): >> >> - Set suspend flags before handshake because then the setting will be visible >> after leaving the _thread_blocked state in JavaThread::wait_for_object_deoptimization() >> >> JavaThread::wait_for_object_deoptimization() >> >> - Reuse SpinYield instead of new custom spinning code. >> >> - Do safepoint check after the loop. This is possible because the >> set_obj_deopt_flag is done before the handshake. >> >> - Don't set_suspend_equivalent() anymore for more simplicity. It's just an >> optimization (that won't pay off here). >> >> Added/updated source code comments. >> >> Additional smaller enhancements. > > src/hotspot/share/opto/macro.cpp line 1096: > >> 1094: // interpreter frames for this compiled frame and that won't play >> 1095: // nice with JVMTI popframe. >> 1096: if (!EliminateAllocations || !alloc->_is_non_escaping) { > > The comment needs to be updated to match the new code. Done. > src/hotspot/share/runtime/thread.cpp line 1926: > >> 1924: delete dlv; >> 1925: } while (deferred->length() != 0); >> 1926: delete deferred_updates(); > > This looks suspect - we delete what is pointed to but we don't NULL the field. Fixed. > src/hotspot/share/runtime/thread.cpp line 2640: > >> 2638: } >> 2639: >> 2640: void JavaThread::wait_for_object_deoptimization() { > > I find this method very complex, and the fact it needs to recheck many of the conditions already checked in the calling > code, suggests to me that the structure here is not quite right. Perhaps > JavaThread::handle_special_runtime_exit_condition should be the place where we loop over each of the potential > conditions, instead of calling per-condition code that then loops and potentially rechecks other conditions. For now I reshaped and hopefully also simplified the method. It should resemble its model java_suspend_self_with_safepoint_check() very much now. With this similarity I'd see the added complexity to be small. In fact wait_for_object_deoptimization() could be a drop-in replacement for java_suspend_self_with_safepoint_check(). Well, the condition in the callers would have to be adapted. > src/hotspot/share/runtime/thread.cpp line 2647: > >> 2645: bool should_spin_wait = true; >> 2646: do { >> 2647: set_thread_state(_thread_blocked); > > It isn't obvious that this raw thread state change is safe. I added a comment explaining it before the method definition. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From rrich at openjdk.java.net Thu Sep 24 14:17:00 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 24 Sep 2020 14:17:00 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v2] In-Reply-To: References: Message-ID: <9JlQSgv11V9HkT3GQn61Lux-NcHNfAXCT2JhhrxmWFE=.820921fe-6440-41a7-acab-377de2bfb423@github.com> > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Changes based on dholmes' feedback. EscapeBarrier::sync_and_suspend_all(): - Set suspend flags before handshake because then the setting will be visible after leaving the _thread_blocked state in JavaThread::wait_for_object_deoptimization() JavaThread::wait_for_object_deoptimization() - Reuse SpinYield instead of new custom spinning code. - Do safepoint check after the loop. This is possible because the set_obj_deopt_flag is done before the handshake. - Don't set_suspend_equivalent() anymore for more simplicity. It's just an optimization (that won't pay off here). Added/updated source code comments. Additional smaller enhancements. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/119/files - new: https://git.openjdk.java.net/jdk/pull/119/files/79f5b823..18dd54b4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=00-01 Stats: 109 lines in 6 files changed: 54 ins; 36 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119 PR: https://git.openjdk.java.net/jdk/pull/119 From rrich at openjdk.java.net Thu Sep 24 14:20:54 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 24 Sep 2020 14:20:54 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v2] In-Reply-To: References: Message-ID: <52tEGYwfin4D77BRSb_uhGxutsKKz0Fyeus9ODCnrO4=.31222347-5829-442c-9ad0-93a2901dc86c@github.com> On Mon, 14 Sep 2020 05:08:39 GMT, David Holmes wrote: >> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: >> >> Changes based on dholmes' feedback. >> >> EscapeBarrier::sync_and_suspend_all(): >> >> - Set suspend flags before handshake because then the setting will be visible >> after leaving the _thread_blocked state in JavaThread::wait_for_object_deoptimization() >> >> JavaThread::wait_for_object_deoptimization() >> >> - Reuse SpinYield instead of new custom spinning code. >> >> - Do safepoint check after the loop. This is possible because the >> set_obj_deopt_flag is done before the handshake. >> >> - Don't set_suspend_equivalent() anymore for more simplicity. It's just an >> optimization (that won't pay off here). >> >> Added/updated source code comments. >> >> Additional smaller enhancements. > > src/hotspot/share/prims/whitebox.cpp line 884: > >> 882: >> 883: WB_ENTRY(jboolean, WB_IsFrameDeoptimized(JNIEnv* env, jobject o, jint depth)) >> 884: JavaThread* t = JavaThread::current(); > > A WB_ENTRY is a JNI_ENTRY which means the current JavaThread is already available via the `thread` variable. Done. > src/hotspot/share/runtime/thread.cpp line 2660: > >> 2658: // showed 5% better performance when spinning. >> 2659: if (should_spin_wait) { >> 2660: // Inspired by HandshakeSpinYield > > Can we not reuse any existing spinning code in the VM? Good point. I wasn't aware of SpinYield. I use it now for the spinning. I use 10 * SpinYield::default_spin_limit as spin limit based on microbenchmarking: http://cr.openjdk.java.net/~rrich/webrevs/8227745/pr116v2.microbenchmark/ ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From eosterlund at openjdk.java.net Thu Sep 24 14:25:15 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 24 Sep 2020 14:25:15 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6] In-Reply-To: References: Message-ID: > This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. > https://openjdk.java.net/jeps/376). > Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, > and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into > more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to > expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in > the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized > automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization > processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is > actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception > handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC > threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming > of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the > watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll > word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it > brought (and is only possible on TSO machines). So left that one out. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Review: StefanK CR 3 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/296/files - new: https://git.openjdk.java.net/jdk/pull/296/files/3db0dbcb..078a207e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=04-05 Stats: 12 lines in 3 files changed: 9 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/296.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/296/head:pull/296 PR: https://git.openjdk.java.net/jdk/pull/296 From eosterlund at openjdk.java.net Thu Sep 24 14:25:22 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 24 Sep 2020 14:25:22 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v5] In-Reply-To: References: Message-ID: <3oH6qlEjgAHw8HK_9LvUCf6yvWeidEiEQXJHuoepgok=.157a7736-afc4-4604-9c13-9f56d385e292@github.com> On Thu, 24 Sep 2020 12:49:06 GMT, Coleen Phillimore wrote: >> Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains seven commits: >> - Review: Per CR 1 >> - Merge branch 'master' into 8253180_conc_stack_scanning >> - Review: Albert CR 1 >> - Review: SteafanK CR 2 >> - Merge branch 'master' into 8253180_conc_stack_scanning >> - Review: SteafanK CR 1 >> - 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing > > I looked at the runtime code and it is nicely non-invasive, and makes sense where there are changes. I uploaded an incremental change to re-instate the separate verification of the thread head vs frames that I had before. Stefan wanted it merged into one function unless I could remember why I had split it. I did not remember why, but now I do. Updated with comments this time to describe why this is split (the exception oop must be fixed before fiddling with the frames). ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From coleenp at openjdk.java.net Thu Sep 24 14:27:26 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 24 Sep 2020 14:27:26 GMT Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v2] In-Reply-To: References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> Message-ID: On Thu, 24 Sep 2020 13:15:53 GMT, Martin Doerr wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function > > Please note that complete_monitor_unlocking_C is only called by C2. Other JIT compilers have other functions. > SharedRuntime::monitor_exit_helper is used by all ones. I had another question: Shouldn't the call sites in the > interpreter use call_VM_leaf instead of call_VM? @TheRealMDoerr you're right, it should be call_VM_leaf so that popframe and force early return are not executed. Setting up last_Java_sp is benign but unnecessary. I should have changed the code in SharedRuntime::monitor_exit_helper instead. Thanks for looking at this and your help! ------------- PR: https://git.openjdk.java.net/jdk/pull/320 From coleenp at openjdk.java.net Thu Sep 24 14:31:45 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 24 Sep 2020 14:31:45 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 14:25:15 GMT, Erik ?sterlund wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, >> and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into >> more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to >> expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in >> the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized >> automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization >> processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is >> actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception >> handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC >> threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming >> of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the >> watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll >> word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it >> brought (and is only possible on TSO machines). So left that one out. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Review: StefanK CR 3 To be clear, my comments about boolean parameters to vframeStream/RegMap can be addressed in a follow up RFE. That would be better. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/296 From mbeckwit at openjdk.java.net Thu Sep 24 15:15:45 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Thu, 24 Sep 2020 15:15:45 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v7] In-Reply-To: References: Message-ID: <2yIqVzoFHyYvmsksyTt-u8UOJongLYpvejzHBy4SRWU=.1917991e-684a-4d45-95fa-6d13b365370d@github.com> > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith has updated the pull request incrementally with two additional commits since the last revision: - os_windows: remove duplicated UMA handling - test_safefetch{32,N} works fine on win+aarch64 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/212/files - new: https://git.openjdk.java.net/jdk/pull/212/files/2b662010..68f61d60 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=05-06 Stats: 22 lines in 2 files changed: 0 ins; 21 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From burban at openjdk.java.net Thu Sep 24 15:15:47 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Thu, 24 Sep 2020 15:15:47 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 04:45:16 GMT, David Holmes wrote: >> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: >> >> Update orderAccess_windows_aarch64.hpp >> >> changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided > > src/hotspot/os/windows/os_windows.cpp line 2546: > >> 2544: >> 2545: #ifdef _M_ARM64 >> 2546: // Unsafe memory access > > I'm not at all clear why this unsafe memory access handling is for Aarch64 only? Hum, this was already part of [JDK-8250810](https://github.com/openjdk/jdk/commit/a4eaf9536c272862b5ec856bf263679be09bddc9) / [JDK-8248817](https://github.com/openjdk/jdk/commit/257809d7440e87ac595d03b6c9a98d8f457f314c) (see a couple lines below in this PR) without the `ifdef` for Aarch64, but I messed up rebasing on top of it. I removed it now, thanks for catching! ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From burban at openjdk.java.net Thu Sep 24 15:19:13 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Thu, 24 Sep 2020 15:19:13 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v5] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 04:52:22 GMT, David Holmes wrote: >> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: >> >> Update orderAccess_windows_aarch64.hpp >> >> changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided > > src/hotspot/share/runtime/stubRoutines.cpp line 397: > >> 395: // test safefetch routines >> 396: // Not on Windows 32bit until 8074860 is fixed >> 397: #if ! (defined(_WIN32) && defined(_M_IX86)) && !defined(_M_ARM64) > > The comment needs updating to refer to Aarch64. This is actually not needed anymore, as it does work just fine on Windows+Aarch64. Presumably we have added it in the early days of the port when we haven't figured out exception handling quite yet. Thanks for catching David. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From cjplummer at openjdk.java.net Thu Sep 24 15:47:05 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 24 Sep 2020 15:47:05 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6] In-Reply-To: <21bX6lTqVC7rs1Cor4HZwmD4cm3_V1rNzSX9shlp03Y=.5aeaaf6c-e42a-4a84-b3ab-b7e6e1c6c706@github.com> References: <21bX6lTqVC7rs1Cor4HZwmD4cm3_V1rNzSX9shlp03Y=.5aeaaf6c-e42a-4a84-b3ab-b7e6e1c6c706@github.com> Message-ID: <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com> On Thu, 24 Sep 2020 14:04:22 GMT, Monica Beckwith wrote: >> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since > the last revision: > - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc > - cleanup for 8253457: Remove unimplemented register stack functions > - Merge remote-tracking branch 'upstream/master' into jdk-windows > - Update orderAccess_windows_aarch64.hpp > > changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided > - 8248787: G1: Workaround MSVC bug > Reviewed-by: > Contributed-by: mbeckwit, luhenry, burban > - 8248670: Windows: Exception handling support on AArch64 > Reviewed-by: > Contributed-by: mbeckwit, luhenry, burban > - 8248660: AArch64: Make _clear_cache and _nop portable > Summary: __builtin___clear_cache, etc. > Contributed-by: mbeckwit, luhenry, burban > - 8248659: AArch64: Extend CPU Feature detection > Reviewed-by: > Contributed-by: mbeckwit, luhenry, burban > - 8248656: Add Windows AArch64 platform support code > Reviewed-by: > Contributed-by: mbeckwit, luhenry, burban > - 8248498: Add build system support for Windows AArch64 > Reviewed-by: > Contributed-by: mbeckwit, luhenry, burban > - ... and 7 more: https://git.openjdk.java.net/jdk/compare/ddd43bee...2b662010 I looked at changes to existing SA files. These changes look fine. I did not look at the new aarch64 SA files other than the copyright section. I assume they are clones of the x64 versions with some symbolic renaming. If there is any more than that and you'd like me to have a look, let me know. As for the copyright in the new SA files, I believe it is incorrect and needs to include Oracle. There are a number of other non-SA files that are new and also have the same copyright issue. I also looked at src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java. It looks fine except it needs a copyright date update. ------------- Changes requested by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/212 From eosterlund at openjdk.java.net Thu Sep 24 15:52:41 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 24 Sep 2020 15:52:41 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 14:28:44 GMT, Coleen Phillimore wrote: > To be clear, my comments about boolean parameters to vframeStream/RegMap can be addressed in a follow up RFE. That > would be better. Thanks for reviewing Coleen! ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From dcubed at openjdk.java.net Thu Sep 24 15:58:25 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 24 Sep 2020 15:58:25 GMT Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v2] In-Reply-To: References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> Message-ID: On Thu, 24 Sep 2020 12:16:24 GMT, Coleen Phillimore wrote: >> That the monitor has already been unlocked, or is a null stacklock monitor has been already checked in the caller, so >> the code that makes it a JRT_ENTRY_NO_ASYNC is unnecessary. >> Making it a JRT_LEAF like the compiled method entries makes it safer. We know it can never safepoint and >> unintentionally install a async exception. >> Tested with tier1-6. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function src/hotspot/share/interpreter/interpreterRuntime.cpp line 741: > 739: #endif > 740: oop obj = elem->obj(); > 741: assert(Universe::heap()->is_in(obj), "must an object"); typo: s/must an/must be an/ src/hotspot/share/interpreter/interpreterRuntime.cpp line 743: > 741: assert(Universe::heap()->is_in(obj), "must an object"); > 742: // The object could become unlocked through a JNI call, which we have no other checks for. > 743: // Give a message if CheckJNICalls but ignore. That comment is a bit misleading. Perhaps: // Give a fatal message if CheckJNICalls. Otherwise we ignore it. src/hotspot/share/runtime/sharedRuntime.cpp line 2106: > 2104: JRT_LEAF(void, SharedRuntime::complete_monitor_unlocking_C(oopDesc* obj, BasicLock* lock, JavaThread* thread)) > 2105: // The object could become unlocked through a JNI call, which we have no other checks for. > 2106: // Give a message if CheckJNICalls but ignore. That comment is a bit misleading. Perhaps: // Give a fatal message if CheckJNICalls. Otherwise we ignore it. ------------- PR: https://git.openjdk.java.net/jdk/pull/320 From dcubed at openjdk.java.net Thu Sep 24 15:58:25 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 24 Sep 2020 15:58:25 GMT Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v2] In-Reply-To: <83qkysm3yGgirk6gOgaO-XbWqW_DFddXtpggcUVZTJE=.9c1a6a13-d224-4448-b213-484cc0a1cdf7@github.com> References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> <3aWZDJX4OXhpPvOXaWP3wA0SPxJGSslQZXl6T_N2riY=.3d6025a6-cf37-4b88-abd8-2b22426bd210@github.com> <8_8hkSO3rgGn5Mx3cxVrN_D90UsFH1tokl5g4Dn-H_E=.5df6f931-d73d-468c-82aa-9f3662e78e53@github.com> <83qkysm3yGgirk6gOgaO-XbWqW_DFddXtpg gcUVZTJE=.9c1a6a13-d224-4448-b213-484cc0a1cdf7@github.com> Message-ID: On Wed, 23 Sep 2020 21:38:37 GMT, Daniel D. Daugherty wrote: >> Actually, I think it has to be: assert(!obj->is_unlocked(), "this object must be locked") > > Update: looks like oop has both is_locked() and is_unlocked()... What happened here? These comments are now completely out of context relative to the code above them? Was this PR rebased? ------------- PR: https://git.openjdk.java.net/jdk/pull/320 From stefank at openjdk.java.net Thu Sep 24 16:30:29 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 24 Sep 2020 16:30:29 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 07:08:35 GMT, Anton Kozlov wrote: > Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html > > On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL, > PROT_NONE), the function was made aware of exec permissions. > For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference > compared with old code. > For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and > immediately reflects this in diagnostic tools like ps. For executable regions it would require MAP_FIXED|MAP_JIT, so > instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently > this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not > shrink (if I haven't missed anything, by the implementation and in principle). Tested: > * local tier1 > * jdk-submit > * codesign[2] with hardened runtime and allow-jit but without > allow-unsigned-executable-memory entitlements[3] produce a working bundle. > > (adding GC group as suggested by @dholmes-ora) > > > [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227 > [2] > > codesign \ > --sign - \ > --options runtime \ > --entitlements ents.plist \ > --timestamp \ > $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib > [3] > > > > > com.apple.security.cs.allow-jit > > com.apple.security.cs.disable-library-validation > > com.apple.security.cs.allow-dyld-environment-variables > > > I started to look at some of these changes and I have a hunch that we don't ever use MAP_FIXED when reserving memory. I have a prototype that cleans that out, but I need more time to complete it and pull it through our testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From github.com+4676506+javeleon at openjdk.java.net Thu Sep 24 16:41:28 2020 From: github.com+4676506+javeleon at openjdk.java.net (Allan Gregersen) Date: Thu, 24 Sep 2020 16:41:28 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> <_luUft9Qs0GYU6GwUs1PLMDGel1salhJg8X Gxsc3h0k=.c175a93b-0736-4549-8316-ac01692f6b9e@github.com> <9tn1QTeKWk7DB7fWgyw7O_PSuN5Y7nTUmvvZSuuWqHM=.e9a7dbbe-c8ec-40eb-aee4-74e08892db08@github.com> Message-ID: On Thu, 24 Sep 2020 12:19:54 GMT, Erik ?sterlund wrote: >>>The problem you describe is what _jvmti_can_access_local_variables capability is for. A debugger will have this set, >>>and hence while debugging, we just don't scalarize stuff, so all objects are simply materialized. JVMCI already exposes >>>this variable and presumably plays by the same rules. >> >> A few questions pops into my mind: >> >> 1. What is the performance implications on setting _jvmti_can_access_local_variables capability? More specifically, >> does this capability kill off escape analysis for a GraalVM? >> 2. When we have multiple Truffle contexts running, including but not limited to different guest languages, can we make >> sure that escape analysis is only switched off on very specific parts of the host system with this set and can we >> enable/disable this capability on the fly? > >> >The problem you describe is what _jvmti_can_access_local_variables capability is for. A debugger will have this set, >> >and hence while debugging, we just don't scalarize stuff, so all objects are simply materialized. JVMCI already exposes >> >this variable and presumably plays by the same rules. >> >> >> >> A few questions pops into my mind: >> >> >> >> 1. What is the performance implications on setting _jvmti_can_access_local_variables capability? More specifically, >> does this capability kill off escape analysis for a GraalVM? > > Yes, it will disable escape analysis... when you are running in the debugger. > >> 2. When we have multiple Truffle contexts running, including but not limited to different guest languages, can we make >> sure that escape analysis is only switched off on very specific parts of the host system with this set and can we >> enable/disable this capability on the fly? > > Why do you care to isolate the performance cost of debugging so tightly? Are you trying to enable some kind of use case > where you are mixing development and production execution in the same JVM, so some code can run at optimal performance > in production, driving a heavy production workload, while someone is single stepping other buggy development code in > the debugger? As a result of a useful offline discussion with @fisk, we?ve decided to pause effort on this PR and investigate what it would take to enhance the StackWalker API to serve all the Truffle use cases. Stay tuned for updates? ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From rrich at openjdk.java.net Thu Sep 24 16:59:03 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 24 Sep 2020 16:59:03 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v3] In-Reply-To: References: Message-ID: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8227745 - Changes based on dholmes' feedback. EscapeBarrier::sync_and_suspend_all(): - Set suspend flags before handshake because then the setting will be visible after leaving the _thread_blocked state in JavaThread::wait_for_object_deoptimization() JavaThread::wait_for_object_deoptimization() - Reuse SpinYield instead of new custom spinning code. - Do safepoint check after the loop. This is possible because the set_obj_deopt_flag is done before the handshake. - Don't set_suspend_equivalent() anymore for more simplicity. It's just an optimization (that won't pay off here). Added/updated source code comments. Additional smaller enhancements. - 8227745, 8233915: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/119/files - new: https://git.openjdk.java.net/jdk/pull/119/files/18dd54b4..5bf631ba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=01-02 Stats: 26592 lines in 830 files changed: 13744 ins; 9718 del; 3130 mod Patch: https://git.openjdk.java.net/jdk/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119 PR: https://git.openjdk.java.net/jdk/pull/119 From luhenry at openjdk.java.net Thu Sep 24 17:10:54 2020 From: luhenry at openjdk.java.net (Ludovic Henry) Date: Thu, 24 Sep 2020 17:10:54 GMT Subject: RFR: 8253015: Aarch64: Move linux code out from generic CPU feature detection In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 20:07:03 GMT, Ludovic Henry wrote: >> Please review a change to remove Linux-specific code from hotspot/cpu/aarch64. >> >> The change is made to prepare for non-linux aarch64 platforms. >> >> vm_version no longer contains any "raw" values that were obtained directly from the platform registers. Some of them >> may be unavailable on certain architectures, like `ctr_el0` is not available on windows [1]. >> Few opportunities to improve linux code were taken: >> 1. `HWCAP_` flags now explicitly mapped to `CPU_` >> 2. `_dcpop` boolean was replaced with `CPU_DCPOP` >> 3. Code generation to get the platform register values was replaced with inline assembly. There is no a code buffer >> allocation anymore. >> Graal-related changes: https://github.com/oracle/graal/pull/2861 >> >> Testing: >> * local hotspot tier1 >> * looking at detected features >> * looking at debug output for `isDcZvaProhibited` and `zvaLength` values in Graal (not committed) -- have not changed >> * looking at the results of `./graal-compiler-micro-benchmarks.jar -p >> size=128,256,512,1024,2048,4096,8192,16384,32768,65536,131072 ArrayAllocationBenchmark.arrayAllocate` >> (https://github.com/oracle/graal/commit/dcb4506e4da05db74e8b4007e2845458e8c555e2) -- the benchmark is noisy in my >> environment, probably too many threads are used. Manually compared iterations, there is no regression spotted. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-September/009690.html > > I've verified that this code works for the Windows-AArch64 port with minimal changes to the new > `vm_version_windows_aarch64.cpp` file. A quick follow-up on getting a review for this patch. We're starting to take dependency on this patch for the Windows-AArch64 and macOS-AArch64 (https://github.com/openjdk/jdk/pull/212/commits/7bf0aab32fb7ef1659efa09651d59aaed53c31d2). /cc @theRealAph ------------- PR: https://git.openjdk.java.net/jdk/pull/154 From dcubed at openjdk.java.net Thu Sep 24 19:44:03 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 24 Sep 2020 19:44:03 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v4] In-Reply-To: References: Message-ID: <5TEAm4iib52xASZirt4XD_cLxz9Ke0UNotULbybLPOc=.d1767695-01b3-4292-9946-bf8fe01cf2ef@github.com> On Wed, 23 Sep 2020 15:26:51 GMT, Aleksey Shipilev wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after Shipilev > > Looks good! I'm looking at vmThread.cpp via the webrev and the "next" button on the frames view has stopped working after change number 8: https://openjdk.github.io/cr/?repo=jdk&pr=228&range=05#frames-6 The "Scroll Down" button is working so I'll push thru it... ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From iklam at openjdk.java.net Thu Sep 24 20:33:41 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 24 Sep 2020 20:33:41 GMT Subject: RFR: 8253402: Convert vmSymbols::SID to enum class In-Reply-To: References: <2RctRAOHDMDgW1Qu57RDcOF1Uns4pjAZfR6Yg9dTb_0=.d3f1bcdd-39b8-4504-8f1a-76541bb5c55e@github.com> Message-ID: <7Ot4ggK2CL3qnw1M3VSdDY3ZzPnUCEz5FZdWwfIN6fc=.d1c175cc-bb50-41a3-8c11-bb252fe6de46@github.com> On Thu, 24 Sep 2020 10:51:08 GMT, Coleen Phillimore wrote: >> Yes, that's the intention, because vmSymbols.hpp is big. >> >> I am thinking whether I should move such forward declarations of enums into globalDefinitions.hpp, so header files that >> use `vmSymbolID` don't need to know that the base type is `int`. > > No, don't move them to globalDefinitions.hpp, only have the forward declarations where they're used. So this is like a > class forward declaration? neat. How about having a new header file utilities/vmEnums.hpp that looks like this: // Include this header file if you just need the following enum types and // you don't use their members directly. This way you don't need to include the // complex header files that have the full definitions of these enums. enum JVMFlagsEnum : int; enum class vmSymbolID : int; My plan is to have at least 2 more such enums (one for `vmIntrinsics::ID`, and one for `SystemDictionary::WKID`). `: int` is the base type of the enum. I think that's part of the type's implementation so it shouldn't be exposed to the user of these types. If we litter `enum class vmSymbolID : int;` all over, when we decide to change the base type to something else, we would need to edit all such places. Worse, if your forward declaration is wrong, like enum class vmSymbolID : char; the compiler won't detect this if your source file doesn't *also* include vmSymbols.hpp, so it could be dangerous. ------------- PR: https://git.openjdk.java.net/jdk/pull/276 From dcubed at openjdk.java.net Thu Sep 24 20:39:09 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 24 Sep 2020 20:39:09 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v6] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 06:27:46 GMT, Robbin Ehn wrote: >> We simplify the vmThread by removing the queue and refactor the the main loop. >> This solves the issues listed: >> - It can create an extra safepoint directly after a safepoint. >> - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. >> - The exposure of the vm operation is dangerous if it's a handshake. >> - The code is a hornets nest with the repetition of checks and branches >> >> Passes t1-8, and a benchmark run. >> >> If you want a smaller diff the commits contains the incremental progress and each commit passed t1. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Removed assert as suggested by David Changes requested by dcubed (Reviewer). src/hotspot/share/runtime/vmThread.cpp line 316: > 314: bool max_time_exceeded = GuaranteedSafepointInterval != 0 && > 315: (interval_ms >= GuaranteedSafepointInterval); > 316: if (!max_time_exceeded) { You've changed the meaning of SafepointALot here. If max_time_exceeded is false, then you never check the SafepointALot flag and miss causing a safepointALot_op to happen next. Here's the old code: 394 if (max_time_exceeded && SafepointSynchronize::is_cleanup_needed()) { 395 return &cleanup_op; 396 } 397 if (SafepointALot) { 398 return &safepointALot_op; 399 } In the old code if max_time_exceeded and we need a cleanup, then cleanup_op is the priority, but if that wasn't the case, then we always checked the SafepointALot flag. src/hotspot/share/runtime/vmThread.cpp line 292: > 290: bool VMThread::handshake_alot() { > 291: assert(_cur_vm_operation == NULL, "Already have an op"); > 292: assert(_next_vm_operation == NULL, "Already have an op"); These mesgs should be "should not have an op yet". src/hotspot/share/runtime/vmThread.cpp line 299: > 297: jlong now_ms = nanos_to_millis(os::javaTimeNanos()); > 298: // If only HandshakeALot is set, but GuaranteedSafepointInterval is 0, > 299: // we emit a handshake if it's been more than a second since last. typo: s/since last/since the last one/ src/hotspot/share/runtime/vmThread.cpp line 354: > 352: // Wait to install this operation as the next operation in the VM Thread > 353: log_trace(vmthread)("A VM operation already set, waiting"); > 354: ml.wait(); So instead of a thread enqueuing an operation on the VMop queue and then waiting for the operation to be executed, we have the thread waiting to enqueue the operation as the "next operation". It seems to me that the new algorithm means that the waiting thread will be woken up more often and then go back to wait()ing without progress. Perhaps this is mitigated by there being way fewer VM operations in the system, but I'm not sure. src/hotspot/share/runtime/vmThread.cpp line 361: > 359: TraceTime timer("Waiting for VM operation to be completed", TRACETIME_LOG(Trace, vmthread)); > 360: // _next_vm_operation is cleared holding VMOperation_lock after it have been > 361: // executed. We wait until _next_vm_operation not our op. typo - s/it have been/it has been/ typo - s/not our op/is not our op/ src/hotspot/share/runtime/vmThread.cpp line 363: > 361: // executed. We wait until _next_vm_operation not our op. > 362: while (_next_vm_operation == op) { > 363: // VM Thread can process it once we unlocks the mutex on wait. typo - s/we unlocks/we unlock/ src/hotspot/share/runtime/vmThread.cpp line 384: > 382: if (_cur_vm_operation != NULL) { > 383: // Check the VM operation allows nested VM operation. > 384: // This normally not the case, e.g., the compiler typo - s/Check the VM/Check that the VM/ typo - s/This normally not/This is normally not/ src/hotspot/share/runtime/vmThread.cpp line 387: > 385: // does not allow nested scavenges or compiles. > 386: if (!_cur_vm_operation->allow_nested_vm_operations()) { > 387: fatal("Nested VM operation %s requested by operation %s", clarity - s/Nested VM/Unexpected nested VM/ src/hotspot/share/runtime/vmThread.cpp line 433: > 431: // On first call this clears a dummy place-holder. > 432: _next_vm_operation = NULL; > 433: // Notify operation done and notify a next operation can be installed. typo - s/operation done/operation is done/ ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From dcubed at openjdk.java.net Thu Sep 24 20:43:28 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 24 Sep 2020 20:43:28 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v6] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 20:36:08 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed assert as suggested by David > > Changes requested by dcubed (Reviewer). Most of my comments this round are not critical. The only real issue that I found was the change in behavior for the SafepointALot flag. The refactoring will make future code maintenance much, much easier, but it made reviewing vmThread.cpp an adventure. ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From ayang at openjdk.java.net Thu Sep 24 21:23:13 2020 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 24 Sep 2020 21:23:13 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 15:49:36 GMT, Erik ?sterlund wrote: >> To be clear, my comments about boolean parameters to vframeStream/RegMap can be addressed in a follow up RFE. That >> would be better. > >> To be clear, my comments about boolean parameters to vframeStream/RegMap can be addressed in a follow up RFE. That >> would be better. > > Thanks for reviewing Coleen! Thank you for the comments and diagrams; they make the code much more digestible. From that diagram, I get the impression that the watermark is associated with stack pointer, so it should be 1:1 relation, but `class Thread` contains multiple watermarks, `StackWatermarks _stack_watermarks;`. I think some high level description on the relation between the thread and a list of watermarks belong to that thread could be beneficial. > The first time it reaches past the last frame it will report true, and the second time it will report false. Why so? As I see it, once a stream becomes "done", it stays in that state forever. Am I missing sth? inline bool StackFrameStream::is_done() { return (_is_done) ? true : (_is_done = _fr.is_first_frame(), false); } ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From phh at openjdk.java.net Thu Sep 24 21:36:59 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Thu, 24 Sep 2020 21:36:59 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) Message-ID: Please review this small patch to enable the OSX build using Xcode 12.0. Thanks, Paul ------------- Commit messages: - JDK-8253375 Changes: https://git.openjdk.java.net/jdk/pull/348/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=348&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253375 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/348.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/348/head:pull/348 PR: https://git.openjdk.java.net/jdk/pull/348 From prr at openjdk.java.net Thu Sep 24 21:51:19 2020 From: prr at openjdk.java.net (Phil Race) Date: Thu, 24 Sep 2020 21:51:19 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul The awt change looks fine although it would be nice if you could paste the compiler error message into the bug report, since I'd like to see the compiler's reason why this is ambiguous today and not before - assuming that is the issue. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/348 From mbeckwit at openjdk.java.net Thu Sep 24 22:04:56 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Thu, 24 Sep 2020 22:04:56 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6] In-Reply-To: <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com> References: <21bX6lTqVC7rs1Cor4HZwmD4cm3_V1rNzSX9shlp03Y=.5aeaaf6c-e42a-4a84-b3ab-b7e6e1c6c706@github.com> <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com> Message-ID: <5ZsmSA9duJz5k77S_uvs3cJWDiQAv9ZkB6Nj1mede14=.27ded45d-7093-4151-ac83-7baf1b5ae3d4@github.com> On Thu, 24 Sep 2020 15:43:10 GMT, Chris Plummer wrote: >> Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev >> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since >> the last revision: >> - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc >> - cleanup for 8253457: Remove unimplemented register stack functions >> - Merge remote-tracking branch 'upstream/master' into jdk-windows >> - Update orderAccess_windows_aarch64.hpp >> >> changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided >> - 8248787: G1: Workaround MSVC bug >> Reviewed-by: >> Contributed-by: mbeckwit, luhenry, burban >> - 8248670: Windows: Exception handling support on AArch64 >> Reviewed-by: >> Contributed-by: mbeckwit, luhenry, burban >> - 8248660: AArch64: Make _clear_cache and _nop portable >> Summary: __builtin___clear_cache, etc. >> Contributed-by: mbeckwit, luhenry, burban >> - 8248659: AArch64: Extend CPU Feature detection >> Reviewed-by: >> Contributed-by: mbeckwit, luhenry, burban >> - 8248656: Add Windows AArch64 platform support code >> Reviewed-by: >> Contributed-by: mbeckwit, luhenry, burban >> - 8248498: Add build system support for Windows AArch64 >> Reviewed-by: >> Contributed-by: mbeckwit, luhenry, burban >> - ... and 7 more: https://git.openjdk.java.net/jdk/compare/6fea1339...2b662010 > > I looked at changes to existing SA files. These changes look fine. > > I did not look at the new aarch64 SA files other than the copyright section. I assume they are clones of the x64 > versions with some symbolic renaming. If there is any more than that and you'd like me to have a look, let me know. > As for the copyright in the new SA files, I believe it is incorrect and needs to include Oracle. There are a number of > other non-SA files that are new and also have the same copyright issue. > I also looked at src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java. It looks fine except it needs > a copyright date update. @dholmes-ora, makes sense. I will do the needful. Thanks. > @mo-beck This PR should not be associated with any JBS issues which are targeted at repo-aarch64-port. All such issues > should have been closed by now when the associated code was pushed to aarch64-port repo. That was the whole point of > creating separate issues so that they could be tracked in the porting repo. Now that all of that work should be > complete the only issue that should remain open in relation to the Windows-Aarch64 port is JDK-8248238. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From github.com+51754783+CoreyAshford at openjdk.java.net Thu Sep 24 22:52:34 2020 From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford) Date: Thu, 24 Sep 2020 22:52:34 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding Message-ID: This patch set encompasses the following commits: - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for the intrinsic. The API is similar to the existing encodeBlock intrinsic. - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic implementation - Adds a Power64LE-specific implementation of the decodeBlock intrinsic. - Adds a JMH microbenchmark for both Base64 encoding and encoding. - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding. ------------- Commit messages: - Expand the Base64 intrinsic regression test to cover decodeBlock - Add JMH benchmark for Base64 variable length buffer decoding - Add Power9+ intrinsic implementation for Base64 decoding - Add HotSpot code to implement Base64 decodeBlock API - Add HotSpotIntrinsicCandidate and API for Base64 decoding Changes: https://git.openjdk.java.net/jdk/pull/293/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=293&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248188 Stats: 1925 lines in 24 files changed: 1899 ins; 4 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/293.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/293/head:pull/293 PR: https://git.openjdk.java.net/jdk/pull/293 From github.com+51754783+CoreyAshford at openjdk.java.net Thu Sep 24 22:52:34 2020 From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford) Date: Thu, 24 Sep 2020 22:52:34 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: References: Message-ID: <3EH-0UK3nZW6J1A59XZ6im798XUPkN6OyJgC_Ptyp-Q=.9321be76-0004-40f2-ac74-366123d1fceb@github.com> On Tue, 22 Sep 2020 02:45:36 GMT, CoreyAshford wrote: > This patch set encompasses the following commits: > > - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for > the intrinsic. The API is similar to the existing encodeBlock intrinsic. > - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic > implementation > - Adds a Power64LE-specific implementation of the decodeBlock intrinsic. > - Adds a JMH microbenchmark for both Base64 encoding and encoding. > - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding. This work is covered by an existing IBM <-> Oracle agreement ------------- PR: https://git.openjdk.java.net/jdk/pull/293 From mchung at openjdk.java.net Thu Sep 24 23:45:05 2020 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 24 Sep 2020 23:45:05 GMT Subject: RFR: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: References: <0lND5NvCLWbPFWv_9eP-V_q_I4uXGanWg5ubT5ZMiZg=.86357e65-c1e8-41cb-9645-624870a46436@github.com> <_luUft9Qs0GYU6GwUs1PLMDGel1salhJg8X Gxsc3h0k=.c175a93b-0736-4549-8316-ac01692f6b9e@github.com> <9tn1QTeKWk7DB7fWgyw7O_PSuN5Y7nTUmvvZSuuWqHM=.e9a7dbbe-c8ec-40eb-aee4-74e08892db08@github.com> Message-ID: <5VH0MfSnKMvVfYzBAxb-OrdHeU6HAt1-wM7uEXYPn-o=.227e3d57-d63f-47bd-8007-dbf1ad376ba6@github.com> On Thu, 24 Sep 2020 16:39:10 GMT, Allan Gregersen wrote: >>> >The problem you describe is what _jvmti_can_access_local_variables capability is for. A debugger will have this set, >>> >and hence while debugging, we just don't scalarize stuff, so all objects are simply materialized. JVMCI already exposes >>> >this variable and presumably plays by the same rules. >>> >>> >>> >>> A few questions pops into my mind: >>> >>> >>> >>> 1. What is the performance implications on setting _jvmti_can_access_local_variables capability? More specifically, >>> does this capability kill off escape analysis for a GraalVM? >> >> Yes, it will disable escape analysis... when you are running in the debugger. >> >>> 2. When we have multiple Truffle contexts running, including but not limited to different guest languages, can we make >>> sure that escape analysis is only switched off on very specific parts of the host system with this set and can we >>> enable/disable this capability on the fly? >> >> Why do you care to isolate the performance cost of debugging so tightly? Are you trying to enable some kind of use case >> where you are mixing development and production execution in the same JVM, so some code can run at optimal performance >> in production, driving a heavy production workload, while someone is single stepping other buggy development code in >> the debugger? > > As a result of a useful offline discussion with @fisk, we?ve decided to pause effort on this PR and investigate what it > would take to enhance the StackWalker API to serve all the Truffle use cases. Stay tuned for updates? I suggest to send out the proposed extension to `StackWalker` API after the initial investigation for discussion. A discussion on the proposed API change would be useful before sending out a PR for code review. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From david.holmes at oracle.com Fri Sep 25 01:01:06 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Sep 2020 11:01:06 +1000 Subject: RFR: 8212107: VMThread issues and cleanup [v6] In-Reply-To: References: Message-ID: Hi Dan, On 25/09/2020 6:39 am, Daniel D.Daugherty wrote: > On Thu, 24 Sep 2020 06:27:46 GMT, Robbin Ehn wrote: >> 352: // Wait to install this operation as the next operation in the VM Thread >> 353: log_trace(vmthread)("A VM operation already set, waiting"); >> 354: ml.wait(); > > So instead of a thread enqueuing an operation on the VMop queue > and then waiting for the operation to be executed, we have the thread > waiting to enqueue the operation as the "next operation". It seems to > me that the new algorithm means that the waiting thread will be > woken up more often and then go back to wait()ing without progress. > Perhaps this is mitigated by there being way fewer VM operations in > the system, but I'm not sure. This is the whole premise of making this change: we no longer need a queue because we rarely have >1 VM-operations in-flight. So the expectation with the new "distributed queue" is that at most one or two threads may be waiting. Cheers, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/228 > From david.holmes at oracle.com Fri Sep 25 01:34:10 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Sep 2020 11:34:10 +1000 Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6] In-Reply-To: <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com> References: <21bX6lTqVC7rs1Cor4HZwmD4cm3_V1rNzSX9shlp03Y=.5aeaaf6c-e42a-4a84-b3ab-b7e6e1c6c706@github.com> <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com> Message-ID: <14d09119-7802-bc97-7547-626edee9c959@oracle.com> Hi Chris, Monica, On 25/09/2020 1:47 am, Chris Plummer wrote: > As for the copyright in the new SA files, I believe it is incorrect and needs to include Oracle. There are a number of > other non-SA files that are new and also have the same copyright issue. If a file was created completely from scratch then it should just have the Microsoft copyright notice. However, if it was copied from an existing file and modified, then the existing file's copyright should be included and a Microsoft one added if the changes are significant. But IANAL. :) Cheers, David > I also looked at src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java. It looks fine except it needs > a copyright date update. > > ------------- > > Changes requested by cjplummer (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/212 > From dholmes at openjdk.java.net Fri Sep 25 02:26:32 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 25 Sep 2020 02:26:32 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <5q0sckv5JjyV1HNZMX1f1eG2dwCjfLTejO8pfH7tS5s=.f1a8c3d5-a436-41bd-9d9f-68f0103539a1@github.com> On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul Changes requested by dholmes (Reviewer). src/hotspot/share/runtime/sharedRuntime.cpp line 2851: > 2849: if (buf != NULL) { > 2850: CodeBuffer buffer(buf); > 2851: short locs_buf[80]; This code is just weird. Why is the buf array not declared to be the desired type? If the compiler rejects double because it isn't relocInfo* then why does it accept short? And if it accepts short will it accept int or long long or int64_t? Using int64_t would be a clearer change. Though semantically this code is awful. :( Should it be intptr_t ? ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From kbarrett at openjdk.java.net Fri Sep 25 05:49:08 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 25 Sep 2020 05:49:08 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul No, don't do this. In the original, double is used to obtain the desired alignmnent. Changing the element type to short reduces the alignment requirement for the variable. initialize_shared_locs will then adjust the alignment, potentially shrinking the effective array size. So this is a real change that I think shouldn't be made. I think changing the declaration for locs_buf to any of the following gives equivalent behavior to the current code. I don't know whether any of them will trigger the new clang warning though. I don't have access to that version right now, and the documentation for the warning is useless (like so much of clang's warning options documentation). (1) alignas(double) char locs_buf[20 * sizeof(double)]; (but alignas is not yet in the "permitted features" list in the Style Guide: https://bugs.openjdk.java.net/browse/JDK-8252584) (2) union { char locs_buf[20 * sizeof(double)]; double align; }; (3) std::aligned_storage_t<20 * sizeof(double)> locs_buf; and change (relocInfo*)locs_buf => (relocInfo*)&locs_buf and #include This has the benefit of being explicit that we're just stack allocating a block of storage. I'll make a wild guess that (1) and (2) will still warn, though char arrays are somewhat special in the language so maybe they won't. I'm pretty sure (3) should do the trick. ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/348 From kbarrett at openjdk.java.net Fri Sep 25 06:09:10 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 25 Sep 2020 06:09:10 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129: > 127: NSColor* result = nil; > 128: > 129: if (colorIndex < ((useAppleColor) ? sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS : > java_awt_SystemColor_NUM_COLORS)) { This looks like a plain old bug fix, nothing really to do with the compiler upgrade. The new compiler presumably just has a new warning that brought attention to the problem. As such, I don't think it belongs in a PR that's about issues related to the compiler upgrade. Someone might want to backport just this fix, for example. ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From kim.barrett at oracle.com Fri Sep 25 06:12:27 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 25 Sep 2020 02:12:27 -0400 Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <26D262B7-A73B-450D-8789-16F33B950379@oracle.com> > On Sep 25, 2020, at 1:49 AM, Kim Barrett wrote: > > On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul [I tried submitting this comment through the github UI and somehow managed to lose all the context in the process. In case it?s not (eventually) obvious, this is about the change to src/hotspot/share/runtime/sharedRuntime.cpp. Still figuring out github?] > No, don't do this. In the original, double is used to obtain the desired > alignmnent. Changing the element type to short reduces the alignment > requirement for the variable. initialize_shared_locs will then adjust the > alignment, potentially shrinking the effective array size. So this is a > real change that I think shouldn't be made. > > I think changing the declaration for locs_buf to any of the following gives > equivalent behavior to the current code. I don't know whether any of them > will trigger the new clang warning though. I don't have access to that > version right now, and the documentation for the warning is useless (like so > much of clang's warning options documentation). > > (1) alignas(double) char locs_buf[20 * sizeof(double)]; > (but alignas is not yet in the "permitted features" list in the Style Guide: > https://bugs.openjdk.java.net/browse/JDK-8252584) > > (2) union { char locs_buf[20 * sizeof(double)]; double align; }; > > (3) std::aligned_storage_t<20 * sizeof(double)> locs_buf; > and change (relocInfo*)locs_buf => (relocInfo*)&locs_buf > and #include > This has the benefit of being explicit that we're just stack allocating a > block of storage. > > I'll make a wild guess that (1) and (2) will still warn, though char arrays > are somewhat special in the language so maybe they won't. I'm pretty sure > (3) should do the trick. > > ------------- > > Changes requested by kbarrett (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/348 From shade at openjdk.java.net Fri Sep 25 07:07:41 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 25 Sep 2020 07:07:41 GMT Subject: RFR: 8253611: AArch64: Concurrency problems in JavaFrameAnchor Message-ID: It looks that `_last_Java_sp` is additionally used as acquire/release flag that guards the rest of the state. Yet, the coding in `javaFrameAnchor_aarch64.hpp` is incorrect at least in one place: _last_Java_fp = src->_last_Java_fp; _last_Java_pc = src->_last_Java_pc; // Must be last so profiler will always see valid frame if has_last_frame() is true _last_Java_sp = src->_last_Java_sp; There should be `OrderAccess::release()` where the comment suggesting the ordering constraint actually is -- I believe that is a copy-paste error from x86. Other platforms have `release` thre. Additionally, it has to be matched with `OrderAccess::acquire()` before `_last_Java_sp` reads, which requires the shared code to use the platform-specific getter. Testing: - [ ] Linux x86_64 tier1 - [x] Linux AArch64 tier1 - [x] Linux AArch64 tier2 ------------- Commit messages: - Minor improvements in comment text - Use declarative Atomics instead of OrderAccess - Cleanups - 8253611: AArch64: Concurrency problems in JavaFrameAnchor Changes: https://git.openjdk.java.net/jdk/pull/352/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=352&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253611 Stats: 43 lines in 2 files changed: 15 ins; 10 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/352.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/352/head:pull/352 PR: https://git.openjdk.java.net/jdk/pull/352 From aph at redhat.com Fri Sep 25 07:57:19 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 25 Sep 2020 08:57:19 +0100 Subject: RFR: 8253611: AArch64: Concurrency problems in JavaFrameAnchor In-Reply-To: References: Message-ID: On 25/09/2020 08:07, Aleksey Shipilev wrote: > It looks that `_last_Java_sp` is additionally used as > acquire/release flag that guards the rest of the state. Yet, the > coding in `javaFrameAnchor_aarch64.hpp` is incorrect at least in one > place: > > _last_Java_fp = src->_last_Java_fp; > _last_Java_pc = src->_last_Java_pc; > // Must be last so profiler will always see valid frame if has_last_frame() is true > _last_Java_sp = src->_last_Java_sp; > > There should be `OrderAccess::release()` where the comment > suggesting the ordering constraint actually is -- I believe that is > a copy-paste error from x86. Other platforms have `release` thre. OK, thanks. After all these years! It wasn't an oversight. I have asked before about where this actually matters, and no-one seemed to know and it didn't seem to matter, so I never changed it. Is it really true that there are threads racily accessing the JavaFrameAnchor? If so, I'd expect more problems than just this. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From kim.barrett at oracle.com Fri Sep 25 08:00:48 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 25 Sep 2020 04:00:48 -0400 Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <0CC7FB67-55D9-4E7F-9B45-BA7FD6E3BE43@oracle.com> > On Sep 25, 2020, at 1:49 AM, Kim Barrett wrote: > > On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > [?] > > I think changing the declaration for locs_buf to any of the following gives > equivalent behavior to the current code. [?] > > [?] Another variant that probably avoids both the warning and avoids any C++14 features: (4) union { char data[20 * sizeof(double)]; double align; } locs_buf; and change (relocInfo*)locs_buf => (relocInfo*)&locs_buf. > ------------- > > Changes requested by kbarrett (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/348 From adinn at openjdk.java.net Fri Sep 25 08:35:17 2020 From: adinn at openjdk.java.net (Andrew Dinn) Date: Fri, 25 Sep 2020 08:35:17 GMT Subject: RFR: 8253611: AArch64: Concurrency problems in JavaFrameAnchor In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 07:00:16 GMT, Aleksey Shipilev wrote: > It looks that `_last_Java_sp` is additionally used as acquire/release flag that guards the rest of the state. Yet, the > coding in `javaFrameAnchor_aarch64.hpp` is incorrect at least in one place: > _last_Java_fp = src->_last_Java_fp; > _last_Java_pc = src->_last_Java_pc; > // Must be last so profiler will always see valid frame if has_last_frame() is true > _last_Java_sp = src->_last_Java_sp; > > There should be `OrderAccess::release()` where the comment suggesting the ordering constraint actually is -- I believe > that is a copy-paste error from x86. Other platforms have `release` thre. Additionally, it has to be matched with > `OrderAccess::acquire()` before `_last_Java_sp` reads, which requires the shared code to use the platform-specific > getter. Testing: > - [x] Linux x86_64 tier1 > - [x] Linux AArch64 tier1 > - [x] Linux AArch64 tier2 I also remember the discussion about this being inconclusive. I can certainly see it mattering for profiling threads trying to initiate a stack walk but I suspect they may have relied on sanity checks to filter out erroneous reads. ------------- Marked as reviewed by adinn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/352 From mdoerr at openjdk.java.net Fri Sep 25 09:19:29 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 25 Sep 2020 09:19:29 GMT Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v2] In-Reply-To: References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> Message-ID: On Thu, 24 Sep 2020 14:24:43 GMT, Coleen Phillimore wrote: >> Please note that complete_monitor_unlocking_C is only called by C2. Other JIT compilers have other functions. >> SharedRuntime::monitor_exit_helper is used by all ones. I had another question: Shouldn't the call sites in the >> interpreter use call_VM_leaf instead of call_VM? > > @TheRealMDoerr you're right, it should be call_VM_leaf so that popframe and force early return are not executed. > Setting up last_Java_sp is benign but unnecessary. I should have changed the code in > SharedRuntime::monitor_exit_helper instead. Thanks for looking at this and your help! Hi David, the IllegalMonitorStateException should get thrown by the code generated by TemplateTable::monitorexit() without reaching InterpreterRuntime::monitorexit in this scenario. But we should review this carefully and run all such JCK tests and whatever we have before pushing this change. Coleen?s check for already unlocked objects is only for JNI and is not mandatory AFAICS: ?Native code must not use MonitorExit to exit a monitor entered through a synchronized method or a monitorenter Java virtual machine instruction.? https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#MonitorExit So Coleen has chosen to implement the undefined behavior such that we gracefully ignore it or report fatal with CheckJNICalls. Best regards, Martin From: David Holmes Sent: Freitag, 25. September 2020 07:40 To: openjdk/jdk Cc: Doerr, Martin ; Mention Subject: Re: [openjdk/jdk] 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function (#320) Hi Coleen, I believe that failing to throw IllegalMonitorStateException now violates the JVMS. Even if the VM enforces balanced locking it should still throw IMSE here. Consider a JCK-style test that just performs a monitorexit with no monitorenter, expecting to get IMSE - such a test exists. Cheers, David ? You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. ------------- PR: https://git.openjdk.java.net/jdk/pull/320 From nick.gasson at arm.com Fri Sep 25 09:34:05 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Fri, 25 Sep 2020 17:34:05 +0800 Subject: RFR: 8253611: AArch64: Concurrency problems in JavaFrameAnchor In-Reply-To: References: Message-ID: <85o8lu19pu.fsf@nicgas01-pc.shanghai.arm.com> On 09/25/20 15:57 pm, Andrew Haley wrote: > On 25/09/2020 08:07, Aleksey Shipilev wrote: >> >> There should be `OrderAccess::release()` where the comment >> suggesting the ordering constraint actually is -- I believe that is >> a copy-paste error from x86. Other platforms have `release` thre. > > OK, thanks. > > After all these years! It wasn't an oversight. I have asked before > about where this actually matters, and no-one seemed to know and it > didn't seem to matter, so I never changed it. Is it really true that > there are threads racily accessing the JavaFrameAnchor? If so, I'd > expect more problems than just this. I see only the PPC port has an OrderAccess::release() here at the moment. If it matters for these two platforms then ARM32 and Zero also need the same fix? -- Nick From lucy at openjdk.java.net Fri Sep 25 10:22:08 2020 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Fri, 25 Sep 2020 10:22:08 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 05:46:08 GMT, Kim Barrett wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > No, don't do this. In the original, double is used to obtain the desired > alignmnent. Changing the element type to short reduces the alignment > requirement for the variable. initialize_shared_locs will then adjust the > alignment, potentially shrinking the effective array size. So this is a > real change that I think shouldn't be made. > > I think changing the declaration for locs_buf to any of the following gives > equivalent behavior to the current code. I don't know whether any of them > will trigger the new clang warning though. I don't have access to that > version right now, and the documentation for the warning is useless (like so > much of clang's warning options documentation). > > (1) alignas(double) char locs_buf[20 * sizeof(double)]; > (but alignas is not yet in the "permitted features" list in the Style Guide: > https://bugs.openjdk.java.net/browse/JDK-8252584) > > (2) union { char locs_buf[20 * sizeof(double)]; double align; }; > > (3) std::aligned_storage_t<20 * sizeof(double)> locs_buf; > and change (relocInfo*)locs_buf => (relocInfo*)&locs_buf > and #include > This has the benefit of being explicit that we're just stack allocating a > block of storage. > > I'll make a wild guess that (1) and (2) will still warn, though char arrays > are somewhat special in the language so maybe they won't. I'm pretty sure > (3) should do the trick. I checked Kim Barrett's proposals (1) and (2) on my machine (MacOS 10.15, Xcode 12.0). Both proposals make the warning go away. Another note, actually, it's more like a question: Has anyone had an eye on what happens in initialize_shared_locs(relocInfo* buf, int length)? To my understanding, "buf", which is passed in as "locs_buf", is stored into CodeBuffer fields. Is that a good idea? "locs_buf" points into the stack. This pointer becomes invalid at the end of the "locs_buf" scope. Did I get something wrong here? ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From phedlin at openjdk.java.net Fri Sep 25 10:27:52 2020 From: phedlin at openjdk.java.net (Patric Hedlin) Date: Fri, 25 Sep 2020 10:27:52 GMT Subject: RFR: 8247691: [aarch64] Incorrect handling of VM exceptions in C1 deopt stub/traps Message-ID: The immediate issue that causes the error symptom is due to the procedure link register (LR) not being preserved across the actual call to the "patching" function (in code generated from '_generate_patching()_'), invoked as part of the C1 deoptimization traps. However, this update addresses a larger issue with the current implementation. Since the Aarch64 implementation does not adopt patching but deoptimization to support load-mirror et.al., the "patching" stub-code does not need to support the exception protocol otherwise necessary when a VM transition might be needed in the actual patching function. The deoptimization is compulsory and the transition to the interpreter will cater for proper interaction with the VM. The proposed solution is thus: 1. The version of '_patch_code()_' used with **DEOPTIMIZE_WHEN_PATCHING** should no be modelled as a **JRT_ENTRY**. The "patching" functions will not transfer control to VM (for up-call or otherwise). 2. The patch-stub code does not need to handle the VM exception protocol (code can be removed). 3. The patch-stub code need only to support deoptimization and re-execute (it's a fatal error otherwise). 4. The patch-stub code does not need to utilise any instruction stream synchronisation barrier as no patching/modifying of the instruction stream is done (including indirectly through a VM transition). ------------- Commit messages: - No need to synchronize the instruction stream when not patching. - Terminating in the no-deopt case. - 8247691: Crash in test/hotspot/jtreg/runtime/Thread/StopAtExit.java Changes: https://git.openjdk.java.net/jdk/pull/344/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=344&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247691 Stats: 94 lines in 3 files changed: 15 ins; 60 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/344.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/344/head:pull/344 PR: https://git.openjdk.java.net/jdk/pull/344 From mdoerr at openjdk.java.net Fri Sep 25 10:28:29 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 25 Sep 2020 10:28:29 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: <3EH-0UK3nZW6J1A59XZ6im798XUPkN6OyJgC_Ptyp-Q=.9321be76-0004-40f2-ac74-366123d1fceb@github.com> References: <3EH-0UK3nZW6J1A59XZ6im798XUPkN6OyJgC_Ptyp-Q=.9321be76-0004-40f2-ac74-366123d1fceb@github.com> Message-ID: On Wed, 23 Sep 2020 22:28:38 GMT, CoreyAshford wrote: >> This patch set encompasses the following commits: >> >> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for >> the intrinsic. The API is similar to the existing encodeBlock intrinsic. >> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic >> implementation >> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic. >> - Adds a JMH microbenchmark for both Base64 encoding and encoding. >> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding. > > This work is covered by an existing IBM <-> Oracle agreement Hi Corey, thanks for refactoring the Java code such that it matches the intrinsic implementation. That's a better design. I'm now looking at the PPC64 platform code. The algorithm looks fine. I can see you're using clrldi to clear the upper bits of the parameters. But seems like it clears one bit too few. You can also use cmpwi for the boolean one. I wonder about the loop unrolling. It doesn't look beneficial because the loop body is large. Did you measure performance gain by this unrolling? I think for agressive tuning we'd have to apply techniques like modulo scheduling, but that's much more work. So please only use unrolling as far as a benefit is measurable. But you may want to align the loop start to help instruction fetch. We'll test it, but we don't have Power 10. You guys need to cover that. Best regards, Martin ------------- PR: https://git.openjdk.java.net/jdk/pull/293 From stefank at openjdk.java.net Fri Sep 25 10:33:30 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 25 Sep 2020 10:33:30 GMT Subject: Integrated: 8253555: Make ByteSize and WordSize typed scoped enums In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 06:23:34 GMT, Stefan Karlsson wrote: > It's a common bug in HotSpot that byte values are used when the code asks for words, and vice versa. One attempt to > prevent that has been to use the classes ByteSize and WordSize, to make the compiler detect these problems. The current > implementation is a bit problematic, because both types are int typedefs in release builds, and wrapper classes in > debug builds. This means that we can't use these types in overload resolution. I propose that we fix that by changing > the type to scoped enums with a fixed int type. The compiler will then be apple to completely separate ByteSize, > WordSize, and ints. We also don't need different code in release vs debug builds. FWIW, I once created a size_t > versions of these classes and annotated all the metaspace code with these types. This experiment flushed out a handful > of bugs (some of them were known and the reason for trying that experiment) There are some controversy about having > these classes around. See for example: JDK-8041956: remove ByteSize and WordSize classes I hope we can stay away from > that discussion in this PR. This pull request has now been integrated. Changeset: 1f5a0334 Author: Stefan Karlsson URL: https://git.openjdk.java.net/jdk/commit/1f5a0334 Stats: 236 lines in 9 files changed: 59 ins; 162 del; 15 mod 8253555: Make ByteSize and WordSize typed scoped enums Reviewed-by: kbarrett, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/328 From kim.barrett at oracle.com Fri Sep 25 10:37:08 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 25 Sep 2020 06:37:08 -0400 Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <7298FBE4-01E9-4857-B213-B2A7F0A41621@oracle.com> > On Sep 25, 2020, at 6:22 AM, Lutz Schmidt wrote: > > On Fri, 25 Sep 2020 05:46:08 GMT, Kim Barrett wrote: > > Another note, actually, it's more like a question: > Has anyone had an eye on what happens in initialize_shared_locs(relocInfo* buf, int length)? To my understanding, > "buf", which is passed in as "locs_buf", is stored into CodeBuffer fields. Is that a good idea? "locs_buf" points into > the stack. This pointer becomes invalid at the end of the "locs_buf" scope. Did I get something wrong here? It?s ?odd? but I think it?s more or less okay. Here and in other uses we seem to be allocating dynamically scoped storage for temporary use by the CodeBuffer. I think a more normal formulation might be to allocate the buffer, then pass it to the CodeBuffer constructor as a non-transfer of ownership. But I haven?t looked at all the places where this is used, and that?s perhaps out of scope for the problem at hand. > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/348 From dholmes at openjdk.java.net Fri Sep 25 10:47:17 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 25 Sep 2020 10:47:17 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v3] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 16:59:03 GMT, Richard Reingruber wrote: >> Hi, >> >> this is the continuation of the review of the implementation for: >> >> https://bugs.openjdk.java.net/browse/JDK-8227745 >> https://bugs.openjdk.java.net/browse/JDK-8233915 >> >> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references >> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such >> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka >> "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: >> >> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ >> >> Thanks, Richard. > > Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The incremental > webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional > commits since the last revision: > - Merge branch 'master' into JDK-8227745 > - Changes based on dholmes' feedback. > > EscapeBarrier::sync_and_suspend_all(): > > - Set suspend flags before handshake because then the setting will be visible > after leaving the _thread_blocked state in JavaThread::wait_for_object_deoptimization() > > JavaThread::wait_for_object_deoptimization() > > - Reuse SpinYield instead of new custom spinning code. > > - Do safepoint check after the loop. This is possible because the > set_obj_deopt_flag is done before the handshake. > > - Don't set_suspend_equivalent() anymore for more simplicity. It's just an > optimization (that won't pay off here). > > Added/updated source code comments. > > Additional smaller enhancements. > - 8227745, 8233915: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents The minor updates in response to my comments are fine. The more major updates ... I can't really comment on. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From david.holmes at oracle.com Fri Sep 25 11:21:52 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Sep 2020 21:21:52 +1000 Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v2] In-Reply-To: References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> Message-ID: Hi Martin, Coleen, Well this is a little embarrasing so I need to clarify this :) The "email" Martin received was presumably a direct notification from github. I added a comment and then immediately realized my mistake and deleted it before the skara bots sent out the email to the mailing list. But the github notification was sent immediately. :( Please ignore the comment as I realised this was handled at the previous level as Martin describes. Aside: I'm not at all sure it is even possible to hit the bit with the CheckJNICalls given we must have found a valid BasicObjectLock to get that far. But trying to figure out all the possible paths was too complex - the check is a good safety net. Cheers, David On 25/09/2020 7:19 pm, Martin Doerr wrote: > On Thu, 24 Sep 2020 14:24:43 GMT, Coleen Phillimore wrote: > >>> Please note that complete_monitor_unlocking_C is only called by C2. Other JIT compilers have other functions. >>> SharedRuntime::monitor_exit_helper is used by all ones. I had another question: Shouldn't the call sites in the >>> interpreter use call_VM_leaf instead of call_VM? >> >> @TheRealMDoerr you're right, it should be call_VM_leaf so that popframe and force early return are not executed. >> Setting up last_Java_sp is benign but unnecessary. I should have changed the code in >> SharedRuntime::monitor_exit_helper instead. Thanks for looking at this and your help! > > Hi David, > > the IllegalMonitorStateException should get thrown by the code generated by TemplateTable::monitorexit() without > reaching InterpreterRuntime::monitorexit in this scenario. But we should review this carefully and run all such JCK > tests and whatever we have before pushing this change. > > Coleen?s check for already unlocked objects is only for JNI and is not mandatory AFAICS: > ?Native code must not use MonitorExit to exit a monitor entered through a synchronized method or a monitorenter Java > virtual machine instruction.? https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#MonitorExit > So Coleen has chosen to implement the undefined behavior such that we gracefully ignore it or report fatal with > CheckJNICalls. > > Best regards, > Martin > > > From: David Holmes > Sent: Freitag, 25. September 2020 07:40 > To: openjdk/jdk > Cc: Doerr, Martin ; Mention > Subject: Re: [openjdk/jdk] 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function (#320) > > > Hi Coleen, > I believe that failing to throw IllegalMonitorStateException now violates the JVMS. Even if the VM enforces balanced > locking it should still throw IMSE here. Consider a JCK-style test that just performs a monitorexit with no > monitorenter, expecting to get IMSE - such a test exists. > > Cheers, > David > > ? > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or > unsubscribe. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/320 > From rehn at openjdk.java.net Fri Sep 25 11:25:14 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 25 Sep 2020 11:25:14 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v6] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 20:19:08 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed assert as suggested by David > > src/hotspot/share/runtime/vmThread.cpp line 292: > >> 290: bool VMThread::handshake_alot() { >> 291: assert(_cur_vm_operation == NULL, "Already have an op"); >> 292: assert(_next_vm_operation == NULL, "Already have an op"); > > These mesgs should be "should not have an op yet". Fixed > src/hotspot/share/runtime/vmThread.cpp line 299: > >> 297: jlong now_ms = nanos_to_millis(os::javaTimeNanos()); >> 298: // If only HandshakeALot is set, but GuaranteedSafepointInterval is 0, >> 299: // we emit a handshake if it's been more than a second since last. > > typo: s/since last/since the last one/ Fixed > src/hotspot/share/runtime/vmThread.cpp line 316: > >> 314: bool max_time_exceeded = GuaranteedSafepointInterval != 0 && >> 315: (interval_ms >= GuaranteedSafepointInterval); >> 316: if (!max_time_exceeded) { > > You've changed the meaning of SafepointALot here. If max_time_exceeded > is false, then you never check the SafepointALot flag and miss causing a > safepointALot_op to happen next. > > Here's the old code: > > 394 if (max_time_exceeded && SafepointSynchronize::is_cleanup_needed()) { > 395 return &cleanup_op; > 396 } > 397 if (SafepointALot) { > 398 return &safepointALot_op; > 399 } > > In the old code if max_time_exceeded and we need a cleanup, > then cleanup_op is the priority, but if that wasn't the case, then > we always checked the SafepointALot flag. The old behavior could create a SafepointALot when we had no 'safepoint priority' ops in queue when woken. To get this behavior we need more logic to avoid back to back SafepointALot and we need to peek at _next_vm_operation to determine if it's a safepoint op or not (handshake). During a normal test run the old behavior only creates around 1% more safepoints. And if you want more safepoints you can decrease GuaranteedSafepointInterval (not exactly the same). So I didn't think adding that complexity to exactly mimic the old behavior was worth it. What you want me to do? > src/hotspot/share/runtime/vmThread.cpp line 361: > >> 359: TraceTime timer("Waiting for VM operation to be completed", TRACETIME_LOG(Trace, vmthread)); >> 360: // _next_vm_operation is cleared holding VMOperation_lock after it have been >> 361: // executed. We wait until _next_vm_operation not our op. > > typo - s/it have been/it has been/ > typo - s/not our op/is not our op/ Fixed > src/hotspot/share/runtime/vmThread.cpp line 363: > >> 361: // executed. We wait until _next_vm_operation not our op. >> 362: while (_next_vm_operation == op) { >> 363: // VM Thread can process it once we unlocks the mutex on wait. > > typo - s/we unlocks/we unlock/ Fixed > src/hotspot/share/runtime/vmThread.cpp line 384: > >> 382: if (_cur_vm_operation != NULL) { >> 383: // Check the VM operation allows nested VM operation. >> 384: // This normally not the case, e.g., the compiler > > typo - s/Check the VM/Check that the VM/ > typo - s/This normally not/This is normally not/ Fixed > src/hotspot/share/runtime/vmThread.cpp line 387: > >> 385: // does not allow nested scavenges or compiles. >> 386: if (!_cur_vm_operation->allow_nested_vm_operations()) { >> 387: fatal("Nested VM operation %s requested by operation %s", > > clarity - s/Nested VM/Unexpected nested VM/ Fixed > src/hotspot/share/runtime/vmThread.cpp line 433: > >> 431: // On first call this clears a dummy place-holder. >> 432: _next_vm_operation = NULL; >> 433: // Notify operation done and notify a next operation can be installed. > > typo - s/operation done/operation is done/ Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From stefank at openjdk.java.net Fri Sep 25 11:31:07 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 25 Sep 2020 11:31:07 GMT Subject: RFR: 8253638: Cleanup os::reserve_memory and remove MAP_FIXED Message-ID: There's a code path through os::reserve_memory that uses MAP_FIXED. This path is used if a requested address is given. It's very dangerous to use MAP_FIXED, since it causes pre-existing mappings to be replaced. Alternative, move safe, functions exists; named os_attempt_reserve_memory_at. It's not only dangerous to use that API, the Mac AARCH64 port also can't use it in conjunction with its MAP_JIT. I started to split os::reserve_memory into two functions; one that doesn't care about were the memory is mapped (os::reserve_memory), and another that uses the dangerous MAP_FIXED flag (os::reserve_memory_at). However, I noticed that it's only windows code that actually use os::reserve_memory with a requested address. All other usages have been cleaned out and replaced with os::attempt_reserve_memory. And on windows os::attempt_reserve_memory uses os::reserve_memory with comments that it's safe because it only "attempts" to place the mapping. So, this patch: 1) Removes the forcefully reserving of memory and its MAP_FIXED usages! 2) Changes the windows code to call the attempt_reserve_memory_at version, that it actually did anyway. 3) Flips the call order between pd_reserve_memory and pd_attempt_reserve_memory_at, on windows. 4) There's also some unification and split done to handle MEMFLAGS and fds. This part needs followup cleanups (IMHO). 5) The AIX implementation already refused to use MAP_FIXED, and now it doesn't need special code to handle that. 6) Small cleanups around anon_mmap and anon_mmap_aligned ------------- Commit messages: - 8253638: Cleanup os::reserve_memory and remove MAP_FIXED Changes: https://git.openjdk.java.net/jdk/pull/357/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=357&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253638 Stats: 143 lines in 17 files changed: 29 ins; 59 del; 55 mod Patch: https://git.openjdk.java.net/jdk/pull/357.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/357/head:pull/357 PR: https://git.openjdk.java.net/jdk/pull/357 From phedlin at openjdk.java.net Fri Sep 25 11:51:26 2020 From: phedlin at openjdk.java.net (Patric Hedlin) Date: Fri, 25 Sep 2020 11:51:26 GMT Subject: RFR: 8247691: [aarch64] Incorrect handling of VM exceptions in C1 deopt stub/traps In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 19:14:54 GMT, Patric Hedlin wrote: > The immediate issue that causes the error symptom is due to the procedure link register (LR) not being preserved across > the actual call to the "patching" function (in code generated from '_generate_patching()_'), invoked as part of the C1 > deoptimization traps. However, this update addresses a larger issue with the current implementation. > > Since the Aarch64 implementation does not adopt patching but deoptimization to support load-mirror et.al., the > "patching" stub-code does not need to support the exception protocol otherwise necessary when a VM transition might be > needed in the actual patching function. The deoptimization is compulsory and the transition to the interpreter will > cater for proper interaction with the VM. The proposed solution is thus: 1. The version of '_patch_code()_' used > with **DEOPTIMIZE_WHEN_PATCHING** should no be modelled as a **JRT_ENTRY**. The "patching" functions will not transfer > control to VM (for up-call or otherwise). 2. The patch-stub code does not need to handle the VM exception protocol > (code can be removed). 3. The patch-stub code need only to support deoptimization and re-execute (it's a fatal error > otherwise). 4. The patch-stub code does not need to utilise any instruction stream synchronisation barrier as no > patching/modifying of the instruction stream is done (including indirectly through a VM transition). Testing: tier1..6, tier8 (almost ready). ------------- PR: https://git.openjdk.java.net/jdk/pull/344 From coleenp at openjdk.java.net Fri Sep 25 12:11:06 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 25 Sep 2020 12:11:06 GMT Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v2] In-Reply-To: References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> Message-ID: On Fri, 25 Sep 2020 09:16:32 GMT, Martin Doerr wrote: >> @TheRealMDoerr you're right, it should be call_VM_leaf so that popframe and force early return are not executed. >> Setting up last_Java_sp is benign but unnecessary. I should have changed the code in >> SharedRuntime::monitor_exit_helper instead. Thanks for looking at this and your help! > > Hi David, > > the IllegalMonitorStateException should get thrown by the code generated by TemplateTable::monitorexit() without > reaching InterpreterRuntime::monitorexit in this scenario. But we should review this carefully and run all such JCK > tests and whatever we have before pushing this change. Coleen?s check for already unlocked objects is only for JNI and > is not mandatory AFAICS: ?Native code must not use MonitorExit to exit a monitor entered through a synchronized method > or a monitorenter Java virtual machine instruction.? > https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#MonitorExit So Coleen has chosen to > implement the undefined behavior such that we gracefully ignore it or report fatal with CheckJNICalls. > Best regards, > Martin > > > From: David Holmes > Sent: Freitag, 25. September 2020 07:40 > To: openjdk/jdk > Cc: Doerr, Martin ; Mention > Subject: Re: [openjdk/jdk] 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function (#320) > > > Hi Coleen, > I believe that failing to throw IllegalMonitorStateException now violates the JVMS. Even if the VM enforces balanced > locking it should still throw IMSE here. Consider a JCK-style test that just performs a monitorexit with no > monitorenter, expecting to get IMSE - such a test exists. Cheers, > David > > ? > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or > unsubscribe. What Martin said. There are too many emails ... Further note, I implemented calling monitorexit with call_VM_leaf. By doing so, I lose the code that sets up the _last_Java_fp so that this check can't be made before and after ObjectSynchronizer::exit anymore: #ifdef ASSERT thread->last_frame().interpreter_frame_verify_monitor(elem); #endif I don't know if there's an objection to removing it. Maybe back in the day the vm was so buggy that ObjectSynchronizer broke the monitorstack so someone added this? The advantage to making the calls use call_VM_leaf is that call_VM_base also checks for popframe and earlyreturn from the debugger. I visually checked that these call paths don't inadvertently call_VM and install an asynchronous exception (the bug I was chasing last year), but not having this code path saves visual or mechanical inspection and would make the code more robust. What are people's preferences? ------------- PR: https://git.openjdk.java.net/jdk/pull/320 From rehn at openjdk.java.net Fri Sep 25 12:20:37 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 25 Sep 2020 12:20:37 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v7] In-Reply-To: References: Message-ID: <18RDE8UFMJaTC_oNFDF7ZZvaCpdLF5lnGlxDxIxTqzs=.6940805b-d4fa-4baa-a151-a00239d55be5@github.com> > We simplify the vmThread by removing the queue and refactor the the main loop. > This solves the issues listed: > - It can create an extra safepoint directly after a safepoint. > - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. > - The exposure of the vm operation is dangerous if it's a handshake. > - The code is a hornets nest with the repetition of checks and branches > > Passes t1-8, and a benchmark run. > > If you want a smaller diff the commits contains the incremental progress and each commit passed t1. Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision: - Merge branch 'master' into 8212107-vmthread - Spelling fixes from Dan - Removed assert as suggested by David - Whitespace fixes, thanks to Shipilev - Update after Shipilev - Update after Coleen and David - Merge branch 'master' into 8212107-vmthread - Fixed nits - Merge branch 'master' into 8212107-vmthread - Fixes after review from shipilev. - ... and 8 more: https://git.openjdk.java.net/jdk/compare/56fc9713...371ac282 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/228/files - new: https://git.openjdk.java.net/jdk/pull/228/files/5bd76150..371ac282 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=228&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=228&range=05-06 Stats: 29958 lines in 646 files changed: 4811 ins; 23493 del; 1654 mod Patch: https://git.openjdk.java.net/jdk/pull/228.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/228/head:pull/228 PR: https://git.openjdk.java.net/jdk/pull/228 From rehn at openjdk.java.net Fri Sep 25 12:20:37 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 25 Sep 2020 12:20:37 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v6] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 20:27:18 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed assert as suggested by David > > src/hotspot/share/runtime/vmThread.cpp line 354: > >> 352: // Wait to install this operation as the next operation in the VM Thread >> 353: log_trace(vmthread)("A VM operation already set, waiting"); >> 354: ml.wait(); > > So instead of a thread enqueuing an operation on the VMop queue > and then waiting for the operation to be executed, we have the thread > waiting to enqueue the operation as the "next operation". It seems to > me that the new algorithm means that the waiting thread will be > woken up more often and then go back to wait()ing without progress. > Perhaps this is mitigated by there being way fewer VM operations in > the system, but I'm not sure. What David said. When I do stress test I have not been able to produce a thread printing "A VM operation already set, waiting" twice in a row. ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From rrich at openjdk.java.net Fri Sep 25 12:31:30 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 25 Sep 2020 12:31:30 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v3] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 10:44:53 GMT, David Holmes wrote: > > > The minor updates in response to my comments are fine. > > The more major updates ... I can't really comment on. Thanks for looking at the changes and for giving feedback. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From aph at redhat.com Fri Sep 25 12:45:41 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 25 Sep 2020 13:45:41 +0100 Subject: RFR: 8253015: Aarch64: Move linux code out from generic CPU feature detection In-Reply-To: References: Message-ID: <6d7632bf-1662-c7c3-c549-c5e23cfa4c45@redhat.com> On 24/09/2020 18:10, Ludovic Henry wrote: > A quick follow-up on getting a review for this patch. We're starting to take dependency on this patch for the > Windows-AArch64 and macOS-AArch64 > (https://github.com/openjdk/jdk/pull/212/commits/7bf0aab32fb7ef1659efa09651d59aaed53c31d2). /cc @theRealAph It's a large and complex patch. It looks OK, so I have read through and reviewed it, but I haven't tested it on Linux-AArch64. I assume you've done that. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at openjdk.java.net Fri Sep 25 12:47:47 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 25 Sep 2020 12:47:47 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v7] In-Reply-To: <2yIqVzoFHyYvmsksyTt-u8UOJongLYpvejzHBy4SRWU=.1917991e-684a-4d45-95fa-6d13b365370d@github.com> References: <2yIqVzoFHyYvmsksyTt-u8UOJongLYpvejzHBy4SRWU=.1917991e-684a-4d45-95fa-6d13b365370d@github.com> Message-ID: On Thu, 24 Sep 2020 15:15:45 GMT, Monica Beckwith wrote: >> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > Monica Beckwith has updated the pull request incrementally with two additional commits since the last revision: > > - os_windows: remove duplicated UMA handling > - test_safefetch{32,N} works fine on win+aarch64 Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From jbhateja at openjdk.java.net Fri Sep 25 13:10:32 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 25 Sep 2020 13:10:32 GMT Subject: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions [v3] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 16:39:15 GMT, Jatin Bhateja wrote: > @jatin-bhateja Can you put summary of performance improvement into JBS? Hi @vnkozlov , @neliasso Kindly let me know your feedback, If there are no more comments is it ok to integrate this patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/61 From stuefe at openjdk.java.net Fri Sep 25 13:24:52 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 25 Sep 2020 13:24:52 GMT Subject: RFR: 8253638: Cleanup os::reserve_memory and remove MAP_FIXED In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 11:24:17 GMT, Stefan Karlsson wrote: > There's a code path through os::reserve_memory that uses MAP_FIXED. This path is used if a requested address is given. > It's very dangerous to use MAP_FIXED, since it causes pre-existing mappings to be replaced. Alternative, move safe, > functions exists; named os_attempt_reserve_memory_at. It's not only dangerous to use that API, the Mac AARCH64 port > also can't use it in conjunction with its MAP_JIT. > I started to split os::reserve_memory into two functions; one that doesn't care about were the memory is mapped > (os::reserve_memory), and another that uses the dangerous MAP_FIXED flag (os::reserve_memory_at). However, I noticed > that it's only windows code that actually use os::reserve_memory with a requested address. All other usages have been > cleaned out and replaced with os::attempt_reserve_memory. And on windows os::attempt_reserve_memory uses > os::reserve_memory with comments that it's safe because it only "attempts" to place the mapping. So, this patch: 1) > Removes the forcefully reserving of memory and its MAP_FIXED usages! 2) Changes the windows code to call the > attempt_reserve_memory_at version, that it actually did anyway. 3) Flips the call order between pd_reserve_memory and > pd_attempt_reserve_memory_at, on windows. 4) There's also some unification and split done to handle MEMFLAGS and fds. > This part needs followup cleanups (IMHO). 5) The AIX implementation already refused to use MAP_FIXED, and now it > doesn't need special code to handle that. 6) Small cleanups around anon_mmap and anon_mmap_aligned Hi Stefan, very nice cleanup! I had a similar change in work for some time now, but your work made that obsolete. See also https://bugs.openjdk.java.net/browse/JDK-8079351, which now can be closed as duplicate of your bug. Most of my remarks are idle nits; I leave it up to you what you take from them. src/hotspot/os/aix/os_aix.cpp line 2362: > 2360: // just ignore the request address (release) or assert(debug). > 2361: assert0(requested_addr == NULL); > 2362: Funnily, the comment is by me, from 15ish years ago. Back then I did not feel confident enough to change the other platforms, and we could nothing contribute upstream anyway since there was no OpenJDK yet. AIX changes look all fine (and trivial). See remark below about alignment_hint. src/hotspot/os/bsd/os_bsd.cpp line 2026: > 2024: static char* anon_mmap(char* requested_addr, size_t bytes) { > 2025: int flags = MAP_PRIVATE | MAP_NORESERVE | MAP_ANONYMOUS; > 2026: Could you add a short oneliner comment here (and in front of the other mmap calls) that MAP_FIXED is explicitly left out? src/hotspot/os/linux/os_linux.cpp line 3670: > 3668: // Returns address of memory or NULL. If req_addr was not NULL, will only return > 3669: // req_addr or NULL. > 3670: static char* anon_mmap_aligned(char* req_addr, size_t bytes, size_t alignment) { I like the corrected order of parameters. src/hotspot/os/linux/os_linux.cpp line 3653: > 3651: static char* anon_mmap(char* requested_addr, size_t bytes) { > 3652: int flags = MAP_PRIVATE | MAP_NORESERVE | MAP_ANONYMOUS; > 3653: On Linux, we have MAP_FIXED_NOREPLACE now. Just a thought. It would give us the behavior closest to what we want: use exactly the provided address but if there is a pre-existing mapping already do not clobber it. That avoids an extra turnaround where the caller has to unmap the mapping because its in the wrong place. The question is whether that flag is available on all kernels we want to run on. Maybe something for a future patch. src/hotspot/os/linux/os_linux.cpp line 3667: > 3665: // - req_addr can be NULL. If not NULL, it must be a multiple of alignment. > 3666: // - alignment sets the alignment at which memory shall be allocated. > 3667: // It must be a multiple of allocation granularity. (Nothing to do with your patch) but this comment is technically wrong; it should be a multiple of page size. And we probably should assert this in anon_mmap_aligned(). src/hotspot/os/windows/os_windows.cpp line 3067: > 3065: release_memory(base, size); > 3066: attempt_reserve_memory_at(split, base); > 3067: attempt_reserve_memory_at(size - split, split_address); (nothing to do with your patch) but an assert would be good here to make sure the re-reserving worked. AFAICS its only used by CDS and they already assert. But still, would be cleaner. src/hotspot/share/runtime/os.hpp line 317: > 315: // Reserves virtual memory. > 316: // alignment_hint - currently only used by AIX > 317: static char* reserve_memory(size_t bytes, size_t alignment_hint = 0, MEMFLAGS flags = mtOther); I believe we can actually do away with the alignment hint for os::reserve_memory altogether. Which would be good because it is strange and not well documented. I believe the original intent was to let the OS "do its best" but no OS does; all AIX does (and only in mmap mode) is the same as upper layers do, chopping excess memory at front and back away manually. Moreover, that chopping does only work well when using mmap. When using win32 VirtualAlloc or sysv shmat, we cannot unmap part of a mapping. On AIX, I basically just implemented it to "do my best", because I wanted to fill in the os::xx API as best as possible; but it is actually not needed, we don't care (there is some alignment magic going on in 64k paged mode with mmap, but that is a different issue). If I see it right, there are only two cases where caller request alignment from os::reserve_memory: - at several places (eg ZMarkStackSpace) I see an alignment used of os::vm_allocation_granularity, which is unnecessary since that is the granularity the OS will reserve at anyway. Also, it only has any meaning on windows. - I see os::reserve_memory_aligned(), used when creating a ReservedSpace with an alignment wish - which is a real thing, e.g. in metaspace - using the alignment parameter as a wish to os::reserve_memory, but then proceeds to do the alignment-chopping-dance anyway so I guess it is not needed and was just a hopeful optimization. src/hotspot/share/runtime/os.hpp line 322: > 320: // if file_desc != -1, also attaches the memory to the file. > 321: static char* reserve_memory_with_fd(size_t bytes, size_t alignment_hint, int file_desc); > 322: I like that you split those two apart. The fd parameter in reserve_memory really bugged me. Should we do this also for attempt_reserve_memory_at? ------------- PR: https://git.openjdk.java.net/jdk/pull/357 From stuefe at openjdk.java.net Fri Sep 25 13:24:53 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 25 Sep 2020 13:24:53 GMT Subject: RFR: 8253638: Cleanup os::reserve_memory and remove MAP_FIXED In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 12:16:01 GMT, Thomas Stuefe wrote: >> There's a code path through os::reserve_memory that uses MAP_FIXED. This path is used if a requested address is given. >> It's very dangerous to use MAP_FIXED, since it causes pre-existing mappings to be replaced. Alternative, move safe, >> functions exists; named os_attempt_reserve_memory_at. It's not only dangerous to use that API, the Mac AARCH64 port >> also can't use it in conjunction with its MAP_JIT. >> I started to split os::reserve_memory into two functions; one that doesn't care about were the memory is mapped >> (os::reserve_memory), and another that uses the dangerous MAP_FIXED flag (os::reserve_memory_at). However, I noticed >> that it's only windows code that actually use os::reserve_memory with a requested address. All other usages have been >> cleaned out and replaced with os::attempt_reserve_memory. And on windows os::attempt_reserve_memory uses >> os::reserve_memory with comments that it's safe because it only "attempts" to place the mapping. So, this patch: 1) >> Removes the forcefully reserving of memory and its MAP_FIXED usages! 2) Changes the windows code to call the >> attempt_reserve_memory_at version, that it actually did anyway. 3) Flips the call order between pd_reserve_memory and >> pd_attempt_reserve_memory_at, on windows. 4) There's also some unification and split done to handle MEMFLAGS and fds. >> This part needs followup cleanups (IMHO). 5) The AIX implementation already refused to use MAP_FIXED, and now it >> doesn't need special code to handle that. 6) Small cleanups around anon_mmap and anon_mmap_aligned > > src/hotspot/os/bsd/os_bsd.cpp line 2026: > >> 2024: static char* anon_mmap(char* requested_addr, size_t bytes) { >> 2025: int flags = MAP_PRIVATE | MAP_NORESERVE | MAP_ANONYMOUS; >> 2026: > > Could you add a short oneliner comment here (and in front of the other mmap calls) that MAP_FIXED is explicitly left > out? Also, flags could possibly be const now (linux too). Leave that up to you. ------------- PR: https://git.openjdk.java.net/jdk/pull/357 From stefank at openjdk.java.net Fri Sep 25 13:24:55 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 25 Sep 2020 13:24:55 GMT Subject: RFR: 8253638: Cleanup os::reserve_memory and remove MAP_FIXED In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 12:13:27 GMT, Thomas Stuefe wrote: >> There's a code path through os::reserve_memory that uses MAP_FIXED. This path is used if a requested address is given. >> It's very dangerous to use MAP_FIXED, since it causes pre-existing mappings to be replaced. Alternative, move safe, >> functions exists; named os_attempt_reserve_memory_at. It's not only dangerous to use that API, the Mac AARCH64 port >> also can't use it in conjunction with its MAP_JIT. >> I started to split os::reserve_memory into two functions; one that doesn't care about were the memory is mapped >> (os::reserve_memory), and another that uses the dangerous MAP_FIXED flag (os::reserve_memory_at). However, I noticed >> that it's only windows code that actually use os::reserve_memory with a requested address. All other usages have been >> cleaned out and replaced with os::attempt_reserve_memory. And on windows os::attempt_reserve_memory uses >> os::reserve_memory with comments that it's safe because it only "attempts" to place the mapping. So, this patch: 1) >> Removes the forcefully reserving of memory and its MAP_FIXED usages! 2) Changes the windows code to call the >> attempt_reserve_memory_at version, that it actually did anyway. 3) Flips the call order between pd_reserve_memory and >> pd_attempt_reserve_memory_at, on windows. 4) There's also some unification and split done to handle MEMFLAGS and fds. >> This part needs followup cleanups (IMHO). 5) The AIX implementation already refused to use MAP_FIXED, and now it >> doesn't need special code to handle that. 6) Small cleanups around anon_mmap and anon_mmap_aligned > > src/hotspot/os/aix/os_aix.cpp line 2362: > >> 2360: // just ignore the request address (release) or assert(debug). >> 2361: assert0(requested_addr == NULL); >> 2362: > > Funnily, the comment is by me, from 15ish years ago. Back then I did not feel confident enough to change the other > platforms, and we could nothing contribute upstream anyway since there was no OpenJDK yet. > AIX changes look all fine (and trivial). See remark below about alignment_hint. Thanks. > src/hotspot/os/linux/os_linux.cpp line 3670: > >> 3668: // Returns address of memory or NULL. If req_addr was not NULL, will only return >> 3669: // req_addr or NULL. >> 3670: static char* anon_mmap_aligned(char* req_addr, size_t bytes, size_t alignment) { > > I like the corrected order of parameters. Thanks. I'm going to change the top-level functions as a separate patch. > src/hotspot/os/linux/os_linux.cpp line 3653: > >> 3651: static char* anon_mmap(char* requested_addr, size_t bytes) { >> 3652: int flags = MAP_PRIVATE | MAP_NORESERVE | MAP_ANONYMOUS; >> 3653: > > On Linux, we have MAP_FIXED_NOREPLACE now. Just a thought. It would give us the behavior closest to what we want: use > exactly the provided address but if there is a pre-existing mapping already do not clobber it. That avoids an extra > turnaround where the caller has to unmap the mapping because its in the wrong place. The question is whether that flag > is available on all kernels we want to run on. > Maybe something for a future patch. Yes. I tested this on ZGC. We have to provide the MAP_FIXED_NOREPLACE define, but otherwise it should work. > src/hotspot/os/linux/os_linux.cpp line 3667: > >> 3665: // - req_addr can be NULL. If not NULL, it must be a multiple of alignment. >> 3666: // - alignment sets the alignment at which memory shall be allocated. >> 3667: // It must be a multiple of allocation granularity. > > (Nothing to do with your patch) but this comment is technically wrong; it should be a multiple of page size. And we > probably should assert this in anon_mmap_aligned(). I saw that as well, and I know there are more comments like that in other parts. Maybe we could take a clean-up round and fix these. > src/hotspot/os/windows/os_windows.cpp line 3067: > >> 3065: release_memory(base, size); >> 3066: attempt_reserve_memory_at(split, base); >> 3067: attempt_reserve_memory_at(size - split, split_address); > > (nothing to do with your patch) but an assert would be good here to make sure the re-reserving worked. AFAICS its only > used by CDS and they already assert. But still, would be cleaner. IMHO, the above code is a bug. The JVM could have been launched through JNI and we might have other threads reserving/committing memory. I'm inclined to file a bug about that. > src/hotspot/share/runtime/os.hpp line 317: > >> 315: // Reserves virtual memory. >> 316: // alignment_hint - currently only used by AIX >> 317: static char* reserve_memory(size_t bytes, size_t alignment_hint = 0, MEMFLAGS flags = mtOther); > > I believe we can actually do away with the alignment hint for os::reserve_memory altogether. Which would be good > because it is strange and not well documented. > I believe the original intent was to let the OS "do its best" but no OS does; all AIX does (and only in mmap mode) is > the same as upper layers do, chopping excess memory at front and back away manually. > Moreover, that chopping does only work well when using mmap. When using win32 VirtualAlloc or sysv shmat, we cannot > unmap part of a mapping. > On AIX, I basically just implemented it to "do my best", because I wanted to fill in the os::xx API as best as > possible; but it is actually not needed, we don't care (there is some alignment magic going on in 64k paged mode with > mmap, but that is a different issue). If I see it right, there are only two cases where caller request alignment from > os::reserve_memory: > - at several places (eg ZMarkStackSpace) I see an alignment used of os::vm_allocation_granularity, which is unnecessary > since that is the granularity the OS will reserve at anyway. Also, it only has any meaning on windows. > - I see os::reserve_memory_aligned(), used when creating a ReservedSpace with an alignment wish - which is a real thing, > e.g. in metaspace - using the alignment parameter as a wish to os::reserve_memory, but then proceeds to do the > alignment-chopping-dance anyway so I guess it is not needed and was just a hopeful optimization. I had the same thought, but found some paths were it wasn't obvious to me. That's why I left the comment above, hoping to get some reaction out from it. Could we look into this as a separate patch? > src/hotspot/share/runtime/os.hpp line 322: > >> 320: // if file_desc != -1, also attaches the memory to the file. >> 321: static char* reserve_memory_with_fd(size_t bytes, size_t alignment_hint, int file_desc); >> 322: > > I like that you split those two apart. The fd parameter in reserve_memory really bugged me. Should we do this also for > attempt_reserve_memory_at? Yes, I was thinking about that, but wanted to slice this into easily reviewed parts. ------------- PR: https://git.openjdk.java.net/jdk/pull/357 From stefank at openjdk.java.net Fri Sep 25 13:24:55 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 25 Sep 2020 13:24:55 GMT Subject: RFR: 8253638: Cleanup os::reserve_memory and remove MAP_FIXED In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 12:19:46 GMT, Thomas Stuefe wrote: >> src/hotspot/os/bsd/os_bsd.cpp line 2026: >> >>> 2024: static char* anon_mmap(char* requested_addr, size_t bytes) { >>> 2025: int flags = MAP_PRIVATE | MAP_NORESERVE | MAP_ANONYMOUS; >>> 2026: >> >> Could you add a short oneliner comment here (and in front of the other mmap calls) that MAP_FIXED is explicitly left >> out? > > Also, flags could possibly be const now (linux too). Leave that up to you. Sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/357 From aph at redhat.com Fri Sep 25 13:30:05 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 25 Sep 2020 14:30:05 +0100 Subject: RFR: 8253611: AArch64: Concurrency problems in JavaFrameAnchor In-Reply-To: <85o8lu19pu.fsf@nicgas01-pc.shanghai.arm.com> References: <85o8lu19pu.fsf@nicgas01-pc.shanghai.arm.com> Message-ID: <23aab94d-d550-6660-8224-f997a2d26715@redhat.com> On 25/09/2020 10:34, Nick Gasson wrote: > I see only the PPC port has an OrderAccess::release() here at the > moment. If it matters for these two platforms then ARM32 and Zero also > need the same fix? Sure, if it matters. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stefank at openjdk.java.net Fri Sep 25 13:33:05 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 25 Sep 2020 13:33:05 GMT Subject: RFR: 8253639: Change os::attempt_reserve_memory_at parameter order Message-ID: <0MJI9DrcQ8bKFZfFGLPLecI-U3Fu5D7ttmy4WHTRLko=.809857c7-c445-4df6-ae33-ad84e6789627@github.com> I propose that we change the parameter order from: os::attempt_reserve_memory_at(size, addr, ) to: os::attempt_reserve_memory_at(addr, size, ) This patch builds upon the changes in pull/357. There's currently no way to create an incremental review, but I want to get this out for review now. So, unfortunately you have to ignore the first commit and look at the second commit. ------------- Commit messages: - 8253639: Change os::attempt_reserve_memory_at parameter order - 8253638: Cleanup os::reserve_memory and remove MAP_FIXED Changes: https://git.openjdk.java.net/jdk/pull/359/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=359&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253639 Stats: 164 lines in 18 files changed: 29 ins; 59 del; 76 mod Patch: https://git.openjdk.java.net/jdk/pull/359.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/359/head:pull/359 PR: https://git.openjdk.java.net/jdk/pull/359 From stuefe at openjdk.java.net Fri Sep 25 13:39:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 25 Sep 2020 13:39:55 GMT Subject: RFR: 8253638: Cleanup os::reserve_memory and remove MAP_FIXED In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 13:19:20 GMT, Stefan Karlsson wrote: >> src/hotspot/os/windows/os_windows.cpp line 3067: >> >>> 3065: release_memory(base, size); >>> 3066: attempt_reserve_memory_at(split, base); >>> 3067: attempt_reserve_memory_at(size - split, split_address); >> >> (nothing to do with your patch) but an assert would be good here to make sure the re-reserving worked. AFAICS its only >> used by CDS and they already assert. But still, would be cleaner. > > IMHO, the above code is a bug. The JVM could have been launched through JNI and we might have other threads > reserving/committing memory. I'm inclined to file a bug about that. Yes. But there is no other way to do this at this level (if the intent is to split reserved memory and then be able to delete each mapping separately). This is used in ReservedSpace::first/last_part, and most users of that API do not care about independent unmapping, for most of them this is just a way to split an address range. Only exception is CDS which uses it to reserve a large range and then place both CDS and metaspace into them; that coding would have to be rewritten if we do away with split_reserved_memory(). >> src/hotspot/share/runtime/os.hpp line 317: >> >>> 315: // Reserves virtual memory. >>> 316: // alignment_hint - currently only used by AIX >>> 317: static char* reserve_memory(size_t bytes, size_t alignment_hint = 0, MEMFLAGS flags = mtOther); >> >> I believe we can actually do away with the alignment hint for os::reserve_memory altogether. Which would be good >> because it is strange and not well documented. >> I believe the original intent was to let the OS "do its best" but no OS does; all AIX does (and only in mmap mode) is >> the same as upper layers do, chopping excess memory at front and back away manually. >> Moreover, that chopping does only work well when using mmap. When using win32 VirtualAlloc or sysv shmat, we cannot >> unmap part of a mapping. >> On AIX, I basically just implemented it to "do my best", because I wanted to fill in the os::xx API as best as >> possible; but it is actually not needed, we don't care (there is some alignment magic going on in 64k paged mode with >> mmap, but that is a different issue). If I see it right, there are only two cases where caller request alignment from >> os::reserve_memory: >> - at several places (eg ZMarkStackSpace) I see an alignment used of os::vm_allocation_granularity, which is unnecessary >> since that is the granularity the OS will reserve at anyway. Also, it only has any meaning on windows. >> - I see os::reserve_memory_aligned(), used when creating a ReservedSpace with an alignment wish - which is a real thing, >> e.g. in metaspace - using the alignment parameter as a wish to os::reserve_memory, but then proceeds to do the >> alignment-chopping-dance anyway so I guess it is not needed and was just a hopeful optimization. > > I had the same thought, but found some paths were it wasn't obvious to me. That's why I left the comment above, hoping > to get some reaction out from it. Could we look into this as a separate patch? Of course. >> src/hotspot/os/linux/os_linux.cpp line 3653: >> >>> 3651: static char* anon_mmap(char* requested_addr, size_t bytes) { >>> 3652: int flags = MAP_PRIVATE | MAP_NORESERVE | MAP_ANONYMOUS; >>> 3653: >> >> On Linux, we have MAP_FIXED_NOREPLACE now. Just a thought. It would give us the behavior closest to what we want: use >> exactly the provided address but if there is a pre-existing mapping already do not clobber it. That avoids an extra >> turnaround where the caller has to unmap the mapping because its in the wrong place. The question is whether that flag >> is available on all kernels we want to run on. >> Maybe something for a future patch. > > Yes. I tested this on ZGC. We have to provide the MAP_FIXED_NOREPLACE define, but otherwise it should work. Great! ------------- PR: https://git.openjdk.java.net/jdk/pull/357 From stefank at openjdk.java.net Fri Sep 25 13:43:27 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 25 Sep 2020 13:43:27 GMT Subject: RFR: 8253638: Cleanup os::reserve_memory and remove MAP_FIXED In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 13:18:04 GMT, Stefan Karlsson wrote: >> src/hotspot/os/linux/os_linux.cpp line 3667: >> >>> 3665: // - req_addr can be NULL. If not NULL, it must be a multiple of alignment. >>> 3666: // - alignment sets the alignment at which memory shall be allocated. >>> 3667: // It must be a multiple of allocation granularity. >> >> (Nothing to do with your patch) but this comment is technically wrong; it should be a multiple of page size. And we >> probably should assert this in anon_mmap_aligned(). > > I saw that as well, and I know there are more comments like that in other parts. Maybe we could take a clean-up round > and fix these. Created JDK-8253648. ------------- PR: https://git.openjdk.java.net/jdk/pull/357 From stuefe at openjdk.java.net Fri Sep 25 13:43:27 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 25 Sep 2020 13:43:27 GMT Subject: RFR: 8253638: Cleanup os::reserve_memory and remove MAP_FIXED In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 13:40:53 GMT, Stefan Karlsson wrote: >> I saw that as well, and I know there are more comments like that in other parts. Maybe we could take a clean-up round >> and fix these. > > Created JDK-8253648. Yes, I feel os::vm_allocation_granularity is often misunderstood. A cleanup would be good. ------------- PR: https://git.openjdk.java.net/jdk/pull/357 From stuefe at openjdk.java.net Fri Sep 25 13:48:00 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 25 Sep 2020 13:48:00 GMT Subject: RFR: 8253639: Change os::attempt_reserve_memory_at parameter order In-Reply-To: <0MJI9DrcQ8bKFZfFGLPLecI-U3Fu5D7ttmy4WHTRLko=.809857c7-c445-4df6-ae33-ad84e6789627@github.com> References: <0MJI9DrcQ8bKFZfFGLPLecI-U3Fu5D7ttmy4WHTRLko=.809857c7-c445-4df6-ae33-ad84e6789627@github.com> Message-ID: On Fri, 25 Sep 2020 13:26:30 GMT, Stefan Karlsson wrote: > I propose that we change the parameter order from: > os::attempt_reserve_memory_at(size, addr, ) > > to: > os::attempt_reserve_memory_at(addr, size, ) > > This patch builds upon the changes in pull/357. There's currently no way to create an incremental review, but I want to > get this out for review now. So, unfortunately you have to ignore the first commit and look at the second commit. Looks good to me. I still learn to skara and just noticed that as a reviewer I cannot use /reviewer. Since this PR contains commits from some other PR, I don't know how to mark this as reviewed. ------------- PR: https://git.openjdk.java.net/jdk/pull/359 From stefank at openjdk.java.net Fri Sep 25 13:49:49 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 25 Sep 2020 13:49:49 GMT Subject: RFR: 8253638: Cleanup os::reserve_memory and remove MAP_FIXED In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 13:37:01 GMT, Thomas Stuefe wrote: >> IMHO, the above code is a bug. The JVM could have been launched through JNI and we might have other threads >> reserving/committing memory. I'm inclined to file a bug about that. > > Yes. But there is no other way to do this at this level (if the intent is to split reserved memory and then be able to > delete each mapping separately). > This is used in ReservedSpace::first/last_part, and most users of that API do not care about independent unmapping, for > most of them this is just a way to split an address range. Only exception is CDS which uses it to reserve a large range > and then place both CDS and metaspace into them; that coding would have to be rewritten if we do away with > split_reserved_memory(). I created JDK-8253649. >> I had the same thought, but found some paths were it wasn't obvious to me. That's why I left the comment above, hoping >> to get some reaction out from it. Could we look into this as a separate patch? > > Of course. Created JDK-8253650. ------------- PR: https://git.openjdk.java.net/jdk/pull/357 From stefank at openjdk.java.net Fri Sep 25 13:55:05 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 25 Sep 2020 13:55:05 GMT Subject: RFR: 8253638: Cleanup os::reserve_memory and remove MAP_FIXED In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 13:13:27 GMT, Thomas Stuefe wrote: >> There's a code path through os::reserve_memory that uses MAP_FIXED. This path is used if a requested address is given. >> It's very dangerous to use MAP_FIXED, since it causes pre-existing mappings to be replaced. Alternative, move safe, >> functions exists; named os_attempt_reserve_memory_at. It's not only dangerous to use that API, the Mac AARCH64 port >> also can't use it in conjunction with its MAP_JIT. >> I started to split os::reserve_memory into two functions; one that doesn't care about were the memory is mapped >> (os::reserve_memory), and another that uses the dangerous MAP_FIXED flag (os::reserve_memory_at). However, I noticed >> that it's only windows code that actually use os::reserve_memory with a requested address. All other usages have been >> cleaned out and replaced with os::attempt_reserve_memory. And on windows os::attempt_reserve_memory uses >> os::reserve_memory with comments that it's safe because it only "attempts" to place the mapping. So, this patch: 1) >> Removes the forcefully reserving of memory and its MAP_FIXED usages! 2) Changes the windows code to call the >> attempt_reserve_memory_at version, that it actually did anyway. 3) Flips the call order between pd_reserve_memory and >> pd_attempt_reserve_memory_at, on windows. 4) There's also some unification and split done to handle MEMFLAGS and fds. >> This part needs followup cleanups (IMHO). 5) The AIX implementation already refused to use MAP_FIXED, and now it >> doesn't need special code to handle that. 6) Small cleanups around anon_mmap and anon_mmap_aligned > > Hi Stefan, > > very nice cleanup! I had a similar change in work for some time now, but your work made that obsolete. See also > https://bugs.openjdk.java.net/browse/JDK-8079351, which now can be closed as duplicate of your bug. > Most of my remarks are idle nits; I leave it up to you what you take from them. Thanks @tstuefe for reviewing this. You need to click the "Files changed" and then "Review changes" to formally review this. However, since you seem to indicate that you have review I'll see if I can add you. ------------- PR: https://git.openjdk.java.net/jdk/pull/357 From stefank at openjdk.java.net Fri Sep 25 13:55:09 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 25 Sep 2020 13:55:09 GMT Subject: RFR: 8253638: Cleanup os::reserve_memory and remove MAP_FIXED In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 13:22:35 GMT, Stefan Karlsson wrote: >> src/hotspot/share/runtime/os.hpp line 322: >> >>> 320: // if file_desc != -1, also attaches the memory to the file. >>> 321: static char* reserve_memory_with_fd(size_t bytes, size_t alignment_hint, int file_desc); >>> 322: >> >> I like that you split those two apart. The fd parameter in reserve_memory really bugged me. Should we do this also for >> attempt_reserve_memory_at? > > Yes, I was thinking about that, but wanted to slice this into easily reviewed parts. Created JDK-8253652. ------------- PR: https://git.openjdk.java.net/jdk/pull/357 From eosterlund at openjdk.java.net Fri Sep 25 13:57:36 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 25 Sep 2020 13:57:36 GMT Subject: RFR: 8247691: [aarch64] Incorrect handling of VM exceptions in C1 deopt stub/traps In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 19:14:54 GMT, Patric Hedlin wrote: > The immediate issue that causes the error symptom is due to the procedure link register (LR) not being preserved across > the actual call to the "patching" function (in code generated from '_generate_patching()_'), invoked as part of the C1 > deoptimization traps. However, this update addresses a larger issue with the current implementation. > > Since the Aarch64 implementation does not adopt patching but deoptimization to support load-mirror et.al., the > "patching" stub-code does not need to support the exception protocol otherwise necessary when a VM transition might be > needed in the actual patching function. The deoptimization is compulsory and the transition to the interpreter will > cater for proper interaction with the VM. The proposed solution is thus: 1. The version of '_patch_code()_' used > with **DEOPTIMIZE_WHEN_PATCHING** should no be modelled as a **JRT_ENTRY**. The "patching" functions will not transfer > control to VM (for up-call or otherwise). 2. The patch-stub code does not need to handle the VM exception protocol > (code can be removed). 3. The patch-stub code need only to support deoptimization and re-execute (it's a fatal error > otherwise). 4. The patch-stub code does not need to utilise any instruction stream synchronisation barrier as no > patching/modifying of the instruction stream is done (including indirectly through a VM transition). Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/344 From stefank at openjdk.java.net Fri Sep 25 14:00:32 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 25 Sep 2020 14:00:32 GMT Subject: RFR: 8253639: Change os::attempt_reserve_memory_at parameter order In-Reply-To: References: <0MJI9DrcQ8bKFZfFGLPLecI-U3Fu5D7ttmy4WHTRLko=.809857c7-c445-4df6-ae33-ad84e6789627@github.com> Message-ID: On Fri, 25 Sep 2020 13:45:36 GMT, Thomas Stuefe wrote: >> I propose that we change the parameter order from: >> os::attempt_reserve_memory_at(size, addr, ) >> >> to: >> os::attempt_reserve_memory_at(addr, size, ) >> >> This patch builds upon the changes in pull/357. There's currently no way to create an incremental review, but I want to >> get this out for review now. So, unfortunately you have to ignore the first commit and look at the second commit. > > Looks good to me. > > I still learn to skara and just noticed that as a reviewer I cannot use /reviewer. Since this PR contains commits from > some other PR, I don't know how to mark this as reviewed. Thanks Thomas. You need to click "Files changed" then "Review Changes" to review this. I don't think there's a /reviewer command you can use. I'll ask. ------------- PR: https://git.openjdk.java.net/jdk/pull/359 From stefank at openjdk.java.net Fri Sep 25 14:14:45 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 25 Sep 2020 14:14:45 GMT Subject: RFR: 8253639: Change os::attempt_reserve_memory_at parameter order In-Reply-To: References: <0MJI9DrcQ8bKFZfFGLPLecI-U3Fu5D7ttmy4WHTRLko=.809857c7-c445-4df6-ae33-ad84e6789627@github.com> Message-ID: On Fri, 25 Sep 2020 13:57:38 GMT, Stefan Karlsson wrote: >> Looks good to me. >> >> I still learn to skara and just noticed that as a reviewer I cannot use /reviewer. Since this PR contains commits from >> some other PR, I don't know how to mark this as reviewed. > > Thanks Thomas. You need to click "Files changed" then "Review Changes" to review this. I don't think there's a > /reviewer command you can use. I'll ask. Currently, the `/reviewer` command is only there to the PR owner to credit additional reviewers. I've created a Skara ticket asking if this could be enhanced: https://bugs.openjdk.java.net/browse/SKARA-736 ------------- PR: https://git.openjdk.java.net/jdk/pull/359 From rriggs at openjdk.java.net Fri Sep 25 14:20:13 2020 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 25 Sep 2020 14:20:13 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: References: Message-ID: <_tvo1hj209XU5Y4JzhXfjSY2wh7-j1cahY7BskdaXNI=.c4acaa07-0a31-4460-b1d3-57a64fed1fdc@github.com> On Tue, 22 Sep 2020 02:45:36 GMT, CoreyAshford wrote: > This patch set encompasses the following commits: > > - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for > the intrinsic. The API is similar to the existing encodeBlock intrinsic. > - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic > implementation > - Adds a Power64LE-specific implementation of the decodeBlock intrinsic. > - Adds a JMH microbenchmark for both Base64 encoding and encoding. > - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding. Changes requested by rriggs (Reviewer). src/java.base/share/classes/java/util/Base64.java line 747: > 745: * Decodes base64 characters, and returns the number of data bytes > 746: * produced by the base64 decode intrinsic. > 747: * "intrinsic" can be omitted. Both the java and the intrinsic produce the same output. src/java.base/share/classes/java/util/Base64.java line 759: > 757: * src, it must process a multiple of four of them, making the > 758: * returned destination length a multiple of three. > 759: * If the dst array is too short does the intrinsic stop short or throw? The java code would throw an ArrayIndexOutOfBoundsException. It should not occur since the java code allocates the proper buffer but... It might be worth mentioning. src/java.base/share/classes/java/util/Base64.java line 820: > 818: dp += dl; > 819: } > 820: if (sp == sl) { I'd rather see (sp >= s1) instead of the equality, its would be consistent with the condition of the while loop. (And is already lines 767-768). test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 260: > 258: } > 259: > 260: private static final byte[] nonBase64 = { Please add a comment describing this test data. (It looks like it could be generated more compactly than an explicit array). Ditto nonBase64URL below. test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 240: > 238: } > 239: > 240: private static byte[] hexStringToByteArray(String s) { A method to convert a Hex String to a byte array already exists in test/lib/jdk/test/lib/Utils.java in toByteArray(s). Add "jdk.test.lib.Utils" to the "@build" line at the top of the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/293 From dcubed at openjdk.java.net Fri Sep 25 14:38:53 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 25 Sep 2020 14:38:53 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v6] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 06:58:29 GMT, Robbin Ehn wrote: >> src/hotspot/share/runtime/vmThread.cpp line 316: >> >>> 314: bool max_time_exceeded = GuaranteedSafepointInterval != 0 && >>> 315: (interval_ms >= GuaranteedSafepointInterval); >>> 316: if (!max_time_exceeded) { >> >> You've changed the meaning of SafepointALot here. If max_time_exceeded >> is false, then you never check the SafepointALot flag and miss causing a >> safepointALot_op to happen next. >> >> Here's the old code: >> >> 394 if (max_time_exceeded && SafepointSynchronize::is_cleanup_needed()) { >> 395 return &cleanup_op; >> 396 } >> 397 if (SafepointALot) { >> 398 return &safepointALot_op; >> 399 } >> >> In the old code if max_time_exceeded and we need a cleanup, >> then cleanup_op is the priority, but if that wasn't the case, then >> we always checked the SafepointALot flag. > > The old behavior could create a SafepointALot when we had no 'safepoint priority' ops in queue when woken. > To get this behavior we need more logic to avoid back to back SafepointALot and we need to peek at _next_vm_operation > to determine if it's a safepoint op or not (handshake). > During a normal test run the old behavior only creates around 1% more safepoints. > And if you want more safepoints you can decrease GuaranteedSafepointInterval (not exactly the same). > > So I didn't think adding that complexity to exactly mimic the old behavior was worth it. > > What you want me to do? Hmmm.... The old SafepointALot was intended to safepoint as frequently as possible to stress the system. Now we do very little at safepoints so maybe it is time for SafepointALot to evolve. Can you make it so that a SafepointALot happens some fraction of GuaranteedSafepointInterval, e.g., (GuaranteedSafepointInterval / 4) so four times as often? ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From dcubed at openjdk.java.net Fri Sep 25 14:41:23 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 25 Sep 2020 14:41:23 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v6] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 20:41:07 GMT, Daniel D. Daugherty wrote: >> Changes requested by dcubed (Reviewer). > > Most of my comments this round are not critical. The only real issue > that I found was the change in behavior for the SafepointALot flag. > The refactoring will make future code maintenance much, much easier, > but it made reviewing vmThread.cpp an adventure. @dholmes-ora and @robehn - I'm good with the rationale about why we have gotten rid of the VM op queue. My comment above it mostly just mumbling about it to myself while I think it through... ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From tschatzl at openjdk.java.net Fri Sep 25 15:10:22 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 25 Sep 2020 15:10:22 GMT Subject: RFR: 8253639: Change os::attempt_reserve_memory_at parameter order In-Reply-To: <0MJI9DrcQ8bKFZfFGLPLecI-U3Fu5D7ttmy4WHTRLko=.809857c7-c445-4df6-ae33-ad84e6789627@github.com> References: <0MJI9DrcQ8bKFZfFGLPLecI-U3Fu5D7ttmy4WHTRLko=.809857c7-c445-4df6-ae33-ad84e6789627@github.com> Message-ID: On Fri, 25 Sep 2020 13:26:30 GMT, Stefan Karlsson wrote: > I propose that we change the parameter order from: > os::attempt_reserve_memory_at(size, addr, ) > > to: > os::attempt_reserve_memory_at(addr, size, ) > > This patch builds upon the changes in pull/357. There's currently no way to create an incremental review, but I want to > get this out for review now. So, unfortunately you have to ignore the first commit and look at the second commit. Parameter reordering looks good. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/359 From daniel.daugherty at oracle.com Fri Sep 25 15:18:15 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Sep 2020 11:18:15 -0400 Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v2] In-Reply-To: References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> Message-ID: Looks like this reply from David didn't end up getting added to the PR by the SkaraBot... It will be interesting to see if my reply to David's reply gets picked up by the SkaraBot... Both Coleen and I crawled through the current set of code paths that get us into InterpreterRuntime::monitorexit() and we have (mostly) convinced ourselves that all code paths are covered by ownership checks and the throwing of IllegalMonitorStateException. However, to guard against future code breakage (or errors in our analysis) we decided to add _something_ to catch errors here. We talked about assert()s, guarantee()s and fatal() calls. Coleen settled on the fatal() call guarded by CheckJNICalls. Since we believe that only JNI code can screw this up (modulo new bugs in the interpreter or compiler code generation), this seemed like the right way to go.. Dan On 9/25/20 7:21 AM, David Holmes wrote: > Hi Martin, Coleen, > > Well this is a little embarrasing so I need to clarify this :) The > "email" Martin received was presumably a direct notification from > github. I added a comment and then immediately realized my mistake and > deleted it before the skara bots sent out the email to the mailing > list. But the github notification was sent immediately. :( > > Please ignore the comment as I realised this was handled at the > previous level as Martin describes. > > Aside: I'm not at all sure it is even possible to hit the bit with the > CheckJNICalls given we must have found a valid BasicObjectLock to get > that far. But trying to figure out all the possible paths was too > complex - the check is a good safety net. > > Cheers, > David > > On 25/09/2020 7:19 pm, Martin Doerr wrote: >> On Thu, 24 Sep 2020 14:24:43 GMT, Coleen Phillimore >> wrote: >> >>>> Please note that complete_monitor_unlocking_C is only called by C2. >>>> Other JIT compilers have other functions. >>>> SharedRuntime::monitor_exit_helper is used by all ones. I had >>>> another question: Shouldn't the call sites in the >>>> interpreter use call_VM_leaf instead of call_VM? >>> >>> @TheRealMDoerr you're right, it should be call_VM_leaf so that >>> popframe and force early return are not executed. >>> Setting up last_Java_sp is benign but unnecessary.? I should have >>> changed the code in >>> SharedRuntime::monitor_exit_helper instead.? Thanks for looking at >>> this and your help! >> >> Hi David, >> >> the IllegalMonitorStateException should get thrown by the code >> generated by TemplateTable::monitorexit() without >> reaching InterpreterRuntime::monitorexit in this scenario. But we >> should review this carefully and run all such JCK >> tests and whatever we have before pushing this change. >> >> Coleen?s check for already unlocked objects is only for JNI and is >> not mandatory AFAICS: >> ?Native code must not use MonitorExit to exit a monitor entered >> through a synchronized method or a monitorenter Java >> virtual machine instruction.? >> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#MonitorExit >> So Coleen has chosen to implement the undefined behavior such that we >> gracefully ignore it or report fatal with >> CheckJNICalls. >> >> Best regards, >> Martin >> >> >> From: David Holmes >> Sent: Freitag, 25. September 2020 07:40 >> To: openjdk/jdk >> Cc: Doerr, Martin ; Mention >> >> Subject: Re: [openjdk/jdk] 8253540: InterpreterRuntime::monitorexit >> should be a JRT_LEAF function (#320) >> >> >> Hi Coleen, >> I believe that failing to throw IllegalMonitorStateException now >> violates the JVMS. Even if the VM enforces balanced >> locking it should still throw IMSE here. Consider a JCK-style test >> that just performs a monitorexit with no >> monitorenter, expecting to get IMSE - such a test exists. >> >> Cheers, >> David >> >> ? >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on >> GitHub, >> or >> unsubscribe. >> >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/320 >> From redestad at openjdk.java.net Fri Sep 25 15:18:34 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 25 Sep 2020 15:18:34 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v7] In-Reply-To: <18RDE8UFMJaTC_oNFDF7ZZvaCpdLF5lnGlxDxIxTqzs=.6940805b-d4fa-4baa-a151-a00239d55be5@github.com> References: <18RDE8UFMJaTC_oNFDF7ZZvaCpdLF5lnGlxDxIxTqzs=.6940805b-d4fa-4baa-a151-a00239d55be5@github.com> Message-ID: On Fri, 25 Sep 2020 12:20:37 GMT, Robbin Ehn wrote: >> We simplify the vmThread by removing the queue and refactor the the main loop. >> This solves the issues listed: >> - It can create an extra safepoint directly after a safepoint. >> - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. >> - The exposure of the vm operation is dangerous if it's a handshake. >> - The code is a hornets nest with the repetition of checks and branches >> >> Passes t1-8, and a benchmark run. >> >> If you want a smaller diff the commits contains the incremental progress and each commit passed t1. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since > the last revision: > - Merge branch 'master' into 8212107-vmthread > - Spelling fixes from Dan > - Removed assert as suggested by David > - Whitespace fixes, thanks to Shipilev > - Update after Shipilev > - Update after Coleen and David > - Merge branch 'master' into 8212107-vmthread > - Fixed nits > - Merge branch 'master' into 8212107-vmthread > - Fixes after review from shipilev. > - ... and 8 more: https://git.openjdk.java.net/jdk/compare/5d592be8...371ac282 src/hotspot/share/runtime/mutexLocker.hpp line 62: > 60: extern Mutex* RetData_lock; // a lock on installation of RetData inside method data > 61: extern Monitor* VMOperation_lock; // a lock on queue of vm_operations waiting to execute > 62: extern Monitor* VMOperationRequest_lock; // a lock on Threads waiting for a vm_operation to terminate Can the declaration of VMOperationRequest_lock be removed now too? Since it's no longer being defined in mutexLocker.cpp ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From neliasso at openjdk.java.net Fri Sep 25 15:42:13 2020 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Fri, 25 Sep 2020 15:42:13 GMT Subject: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions [v5] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 15:55:11 GMT, Jatin Bhateja wrote: >> Summary: >> >> 1) New AVX3 optimized stubs for both conjoint and disjoint arraycopy. >> 2) Special instruction sequence blocks for copy sizes b/w 32-192 bytes. >> 3) Block copy operation above 192 bytes is performed using destination address aligned PRE-MAIN-POST loop. Main loop >> copies 192 byte in one iteration and tail part fall over special instruction sequence blocks. 4) Both small copy block >> and aligned loop use 32 byte vector register to prevent and frequency penalty for copy sizes less than AVX3Threshold. >> 5) For block size above AVX3Theshold both special blocks and loop operate using 64 byte register. 6) In case user >> sets the maximum vector size to 32 bytes, forward copy (disjoint) operations are done using efficient REP MOVS for copy >> sizes above 4096 bytes. JMH Results: >> System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz >> Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java >> Baseline : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_Baseline.txt]() >> WithOpt : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_WithOpts.txt]() > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8252847 : Modifying file permission to resolve jcheck failure. Looks good to me! ------------- Marked as reviewed by neliasso (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/61 From mdoerr at openjdk.java.net Fri Sep 25 15:54:08 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 25 Sep 2020 15:54:08 GMT Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v2] In-Reply-To: References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> Message-ID: <49fi_0KM_AwfH1gQ4rz_wTYD6RQdmmPTnI9oehctSsU=.7632b222-ca53-4cd1-b149-c5bf6cfc03ff@github.com> On Fri, 25 Sep 2020 12:07:40 GMT, Coleen Phillimore wrote: >> Hi David, >> >> the IllegalMonitorStateException should get thrown by the code generated by TemplateTable::monitorexit() without >> reaching InterpreterRuntime::monitorexit in this scenario. But we should review this carefully and run all such JCK >> tests and whatever we have before pushing this change. Coleen?s check for already unlocked objects is only for JNI and >> is not mandatory AFAICS: ?Native code must not use MonitorExit to exit a monitor entered through a synchronized method >> or a monitorenter Java virtual machine instruction.? >> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#MonitorExit So Coleen has chosen to >> implement the undefined behavior such that we gracefully ignore it or report fatal with CheckJNICalls. >> Best regards, >> Martin >> >> >> From: David Holmes >> Sent: Freitag, 25. September 2020 07:40 >> To: openjdk/jdk >> Cc: Doerr, Martin ; Mention >> Subject: Re: [openjdk/jdk] 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function (#320) >> >> >> Hi Coleen, >> I believe that failing to throw IllegalMonitorStateException now violates the JVMS. Even if the VM enforces balanced >> locking it should still throw IMSE here. Consider a JCK-style test that just performs a monitorexit with no >> monitorenter, expecting to get IMSE - such a test exists. Cheers, >> David >> >> ? >> You are receiving this because you were mentioned. >> Reply to this email directly, view it on GitHub, or >> unsubscribe. > > What Martin said. There are too many emails ... > > Further note, I implemented calling monitorexit with call_VM_leaf. By doing so, I lose the code that sets up the > _last_Java_fp so that this check can't be made before and after ObjectSynchronizer::exit anymore: > #ifdef ASSERT > thread->last_frame().interpreter_frame_verify_monitor(elem); > #endif > > I don't know if there's an objection to removing it. Maybe back in the day the vm was so buggy that ObjectSynchronizer > broke the monitorstack so someone added this? > The advantage to making the calls use call_VM_leaf is that call_VM_base also checks for popframe and earlyreturn from > the debugger. I visually checked that these call paths don't inadvertently call_VM and install an asynchronous > exception (the bug I was chasing last year), but not having this code path saves visual or mechanical inspection and > would make the code more robust. What are people's preferences? Good point. We could use set_last_Java_frame + call_VM_leaf + reset_last_Java_frame, but that's a bit complicated. I'd be ok with removing interpreter_frame_verify_monitor. If hs_err file dumping is good enough, we should get the desired information, too. ------------- PR: https://git.openjdk.java.net/jdk/pull/320 From aph at redhat.com Fri Sep 25 16:45:59 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 25 Sep 2020 17:45:59 +0100 Subject: RFR: 8247691: [aarch64] Incorrect handling of VM exceptions in C1 deopt stub/traps In-Reply-To: References: Message-ID: On 25/09/2020 11:27, Patric Hedlin wrote: > Since the Aarch64 implementation does not adopt patching but > deoptimization to support load-mirror et.al., the "patching" > stub-code does not need to support the exception protocol otherwise > necessary when a VM transition might be needed in the actual > patching function. The deoptimization is compulsory and the > transition to the interpreter will cater for proper interaction with > the VM. > > The proposed solution is thus: > 1. The version of '_patch_code()_' used with > **DEOPTIMIZE_WHEN_PATCHING** should no be modelled as a > **JRT_ENTRY**. The "patching" functions will not transfer control to > VM (for up-call or otherwise). > 2. The patch-stub code does not need to handle the VM exception > protocol (code can be removed). > 3. The patch-stub code need only to support deoptimization and > re-execute (it's a fatal error otherwise). > 4. The patch-stub code does not need to utilise any instruction > stream synchronisation barrier as no patching/modifying of the > instruction stream is done (including indirectly through a VM > transition). Hmm. I left this code in because there always is a possibility that we could enable C1 patching in the future. C1 patching does nothing useful when we have tiered compilation because recompiles due to tiered are ten times as common as recompiles due to patching needed, so being able to patch makes almost no difference to run time. However, there always was a possibility that some form of "patching" might be possible, given appropriate code generation strategies. This could be useful in small C1-only systems, in theory, but I haven't seen any interest in such things. On the other hand, I don't like dead code in the port and it's probably time for it to die. Anyone else have an opinion? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Fri Sep 25 17:23:04 2020 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 25 Sep 2020 18:23:04 +0100 Subject: RFR: 8247691: [aarch64] Incorrect handling of VM exceptions in C1 deopt stub/traps In-Reply-To: References: Message-ID: On 25/09/2020 17:45, Andrew Haley wrote: > Hmm. I left this code in because there always is a possibility that we > could enable C1 patching in the future. C1 patching does nothing > useful when we have tiered compilation because recompiles due to > tiered are ten times as common as recompiles due to patching needed, > so being able to patch makes almost no difference to run > time. However, there always was a possibility that some form of > "patching" might be possible, given appropriate code generation > strategies. This could be useful in small C1-only systems, in theory, > but I haven't seen any interest in such things. > > On the other hand, I don't like dead code in the port and it's > probably time for it to die. > > Anyone else have an opinion? It's dead, Jim. I think it's time to take it away and bury it somewhere. We can always disinter it should resuscitation ever seem like a good idea (which doesn't seem too likely). regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From rehn at openjdk.java.net Fri Sep 25 18:32:22 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 25 Sep 2020 18:32:22 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v6] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 14:36:13 GMT, Daniel D. Daugherty wrote: >> The old behavior could create a SafepointALot when we had no 'safepoint priority' ops in queue when woken. >> To get this behavior we need more logic to avoid back to back SafepointALot and we need to peek at _next_vm_operation >> to determine if it's a safepoint op or not (handshake). >> During a normal test run the old behavior only creates around 1% more safepoints. >> And if you want more safepoints you can decrease GuaranteedSafepointInterval (not exactly the same). >> >> So I didn't think adding that complexity to exactly mimic the old behavior was worth it. >> >> What you want me to do? > > Hmmm.... The old SafepointALot was intended to safepoint as frequently > as possible to stress the system. Now we do very little at safepoints so > maybe it is time for SafepointALot to evolve. Can you make it so that a > SafepointALot happens some fraction of GuaranteedSafepointInterval, e.g., > (GuaranteedSafepointInterval / 4) so four times as often? All test using SafepointALot the already set the GuaranteedSafepointInterval to a low value in range of ~1-300ms. (except for vm boolean flag test which uses SafepointALot to test a boolean flag) For example jni/FastGetField sets GuaranteedSafepointInterval to 1. The only case it would really differ is when adhoc adding SafepointALot without GuaranteedSafepointInterval. ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From rehn at openjdk.java.net Fri Sep 25 18:32:51 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Fri, 25 Sep 2020 18:32:51 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v7] In-Reply-To: References: <18RDE8UFMJaTC_oNFDF7ZZvaCpdLF5lnGlxDxIxTqzs=.6940805b-d4fa-4baa-a151-a00239d55be5@github.com> Message-ID: On Fri, 25 Sep 2020 15:15:21 GMT, Claes Redestad wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev >> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since >> the last revision: >> - Merge branch 'master' into 8212107-vmthread >> - Spelling fixes from Dan >> - Removed assert as suggested by David >> - Whitespace fixes, thanks to Shipilev >> - Update after Shipilev >> - Update after Coleen and David >> - Merge branch 'master' into 8212107-vmthread >> - Fixed nits >> - Merge branch 'master' into 8212107-vmthread >> - Fixes after review from shipilev. >> - ... and 8 more: https://git.openjdk.java.net/jdk/compare/adff7b86...371ac282 > > src/hotspot/share/runtime/mutexLocker.hpp line 62: > >> 60: extern Mutex* RetData_lock; // a lock on installation of RetData inside method data >> 61: extern Monitor* VMOperation_lock; // a lock on queue of vm_operations waiting to execute >> 62: extern Monitor* VMOperationRequest_lock; // a lock on Threads waiting for a vm_operation to terminate > > Can the declaration of VMOperationRequest_lock be removed now too? Since it's no longer being defined in mutexLocker.cpp Fixing, pushing later. ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From coleen.phillimore at oracle.com Fri Sep 25 18:45:03 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 25 Sep 2020 14:45:03 -0400 Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v2] In-Reply-To: References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> Message-ID: On 9/25/20 11:18 AM, Daniel D. Daugherty wrote: > Looks like this reply from David didn't end up getting added to the > PR by the SkaraBot... It will be interesting to see if my reply to > David's reply gets picked up by the SkaraBot... > This thread isn't going through the SkaraBot.? I can't tell you exactly why. > > Both Coleen and I crawled through the current set of code paths that > get us into InterpreterRuntime::monitorexit() and we have (mostly) > convinced ourselves that all code paths are covered by ownership > checks and the throwing of IllegalMonitorStateException. However, to > guard against future code breakage (or errors in our analysis) we > decided to add _something_ to catch errors here. We talked about > assert()s, guarantee()s and fatal() calls. Coleen settled on the > fatal() call guarded by CheckJNICalls. Since we believe that only > JNI code can screw this up (modulo new bugs in the interpreter or > compiler code generation), this seemed like the right way to go.. > Yes, thank you very much for looking through this and our discussions offline.? It would have been another 100 email messages.? Thank you for the summary. Coleen > Dan > > > On 9/25/20 7:21 AM, David Holmes wrote: >> Hi Martin, Coleen, >> >> Well this is a little embarrasing so I need to clarify this :) The >> "email" Martin received was presumably a direct notification from >> github. I added a comment and then immediately realized my mistake >> and deleted it before the skara bots sent out the email to the >> mailing list. But the github notification was sent immediately. :( >> >> Please ignore the comment as I realised this was handled at the >> previous level as Martin describes. >> >> Aside: I'm not at all sure it is even possible to hit the bit with >> the CheckJNICalls given we must have found a valid BasicObjectLock to >> get that far. But trying to figure out all the possible paths was too >> complex - the check is a good safety net. >> >> Cheers, >> David >> >> On 25/09/2020 7:19 pm, Martin Doerr wrote: >>> On Thu, 24 Sep 2020 14:24:43 GMT, Coleen Phillimore >>> wrote: >>> >>>>> Please note that complete_monitor_unlocking_C is only called by >>>>> C2. Other JIT compilers have other functions. >>>>> SharedRuntime::monitor_exit_helper is used by all ones. I had >>>>> another question: Shouldn't the call sites in the >>>>> interpreter use call_VM_leaf instead of call_VM? >>>> >>>> @TheRealMDoerr you're right, it should be call_VM_leaf so that >>>> popframe and force early return are not executed. >>>> Setting up last_Java_sp is benign but unnecessary.? I should have >>>> changed the code in >>>> SharedRuntime::monitor_exit_helper instead.? Thanks for looking at >>>> this and your help! >>> >>> Hi David, >>> >>> the IllegalMonitorStateException should get thrown by the code >>> generated by TemplateTable::monitorexit() without >>> reaching InterpreterRuntime::monitorexit in this scenario. But we >>> should review this carefully and run all such JCK >>> tests and whatever we have before pushing this change. >>> >>> Coleen?s check for already unlocked objects is only for JNI and is >>> not mandatory AFAICS: >>> ?Native code must not use MonitorExit to exit a monitor entered >>> through a synchronized method or a monitorenter Java >>> virtual machine instruction.? >>> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#MonitorExit >>> So Coleen has chosen to implement the undefined behavior such that >>> we gracefully ignore it or report fatal with >>> CheckJNICalls. >>> >>> Best regards, >>> Martin >>> >>> >>> From: David Holmes >>> Sent: Freitag, 25. September 2020 07:40 >>> To: openjdk/jdk >>> Cc: Doerr, Martin ; Mention >>> >>> Subject: Re: [openjdk/jdk] 8253540: InterpreterRuntime::monitorexit >>> should be a JRT_LEAF function (#320) >>> >>> >>> Hi Coleen, >>> I believe that failing to throw IllegalMonitorStateException now >>> violates the JVMS. Even if the VM enforces balanced >>> locking it should still throw IMSE here. Consider a JCK-style test >>> that just performs a monitorexit with no >>> monitorenter, expecting to get IMSE - such a test exists. >>> >>> Cheers, >>> David >>> >>> ? >>> You are receiving this because you were mentioned. >>> Reply to this email directly, view it on >>> GitHub, >>> or >>> unsubscribe. >>> >>> >>> ------------- >>> >>> PR: https://git.openjdk.java.net/jdk/pull/320 >>> > From iklam at openjdk.java.net Fri Sep 25 19:04:11 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 25 Sep 2020 19:04:11 GMT Subject: RFR: 8253638: Cleanup os::reserve_memory and remove MAP_FIXED In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 11:24:17 GMT, Stefan Karlsson wrote: > There's a code path through os::reserve_memory that uses MAP_FIXED. This path is used if a requested address is given. > It's very dangerous to use MAP_FIXED, since it causes pre-existing mappings to be replaced. Alternative, move safe, > functions exists; named os_attempt_reserve_memory_at. It's not only dangerous to use that API, the Mac AARCH64 port > also can't use it in conjunction with its MAP_JIT. > I started to split os::reserve_memory into two functions; one that doesn't care about were the memory is mapped > (os::reserve_memory), and another that uses the dangerous MAP_FIXED flag (os::reserve_memory_at). However, I noticed > that it's only windows code that actually use os::reserve_memory with a requested address. All other usages have been > cleaned out and replaced with os::attempt_reserve_memory. And on windows os::attempt_reserve_memory uses > os::reserve_memory with comments that it's safe because it only "attempts" to place the mapping. So, this patch: 1) > Removes the forcefully reserving of memory and its MAP_FIXED usages! 2) Changes the windows code to call the > attempt_reserve_memory_at version, that it actually did anyway. 3) Flips the call order between pd_reserve_memory and > pd_attempt_reserve_memory_at, on windows. 4) There's also some unification and split done to handle MEMFLAGS and fds. > This part needs followup cleanups (IMHO). 5) The AIX implementation already refused to use MAP_FIXED, and now it > doesn't need special code to handle that. 6) Small cleanups around anon_mmap and anon_mmap_aligned Looks good to me. I checked the existing calls and no one is calling os::reserve_memory with fixed==true, so this change doesn't impact any existing functionality. It's good to remove a dangerous API. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/357 From iklam at openjdk.java.net Fri Sep 25 19:06:16 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 25 Sep 2020 19:06:16 GMT Subject: RFR: 8253639: Change os::attempt_reserve_memory_at parameter order In-Reply-To: References: <0MJI9DrcQ8bKFZfFGLPLecI-U3Fu5D7ttmy4WHTRLko=.809857c7-c445-4df6-ae33-ad84e6789627@github.com> Message-ID: On Fri, 25 Sep 2020 15:07:54 GMT, Thomas Schatzl wrote: >> I propose that we change the parameter order from: >> os::attempt_reserve_memory_at(size, addr, ) >> >> to: >> os::attempt_reserve_memory_at(addr, size, ) >> >> This patch builds upon the changes in pull/357. There's currently no way to create an incremental review, but I want to >> get this out for review now. So, unfortunately you have to ignore the first commit and look at the second commit. > > Parameter reordering looks good. Could you add an explanation in the bug report for the reason of this change? ------------- PR: https://git.openjdk.java.net/jdk/pull/359 From kvn at openjdk.java.net Fri Sep 25 19:18:44 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 25 Sep 2020 19:18:44 GMT Subject: RFR: 8253402: Convert vmSymbols::SID to enum class In-Reply-To: <7Ot4ggK2CL3qnw1M3VSdDY3ZzPnUCEz5FZdWwfIN6fc=.d1c175cc-bb50-41a3-8c11-bb252fe6de46@github.com> References: <2RctRAOHDMDgW1Qu57RDcOF1Uns4pjAZfR6Yg9dTb_0=.d3f1bcdd-39b8-4504-8f1a-76541bb5c55e@github.com> <7Ot4ggK2CL3qnw1M3VSdDY3ZzPnUCEz5FZdWwfIN6fc=.d1c175cc-bb50-41a3-8c11-bb252fe6de46@github.com> Message-ID: On Thu, 24 Sep 2020 20:31:20 GMT, Ioi Lam wrote: >> No, don't move them to globalDefinitions.hpp, only have the forward declarations where they're used. So this is like a >> class forward declaration? neat. > > How about having a new header file utilities/vmEnums.hpp that looks like this: > > // Include this header file if you just need the following enum types and > // you don't use their members directly. This way you don't need to include the > // complex header files that have the full definitions of these enums. > enum JVMFlagsEnum : int; > enum class vmSymbolID : int; > > My plan is to have at least 2 more such enums (one for `vmIntrinsics::ID`, and one for `SystemDictionary::WKID`). > > `: int` is the base type of the enum. I think that's part of the type's implementation so it shouldn't be exposed to > the user of these types. If we litter `enum class vmSymbolID : int;` all over, when we decide to change the base type > to something else, we would need to edit all such places. Worse, if your forward declaration is wrong, like > > enum class vmSymbolID : char; > > the compiler won't detect this if your source file doesn't *also* include vmSymbols.hpp, so it could be dangerous. I am okay with this suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/276 From stefank at openjdk.java.net Fri Sep 25 19:27:57 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 25 Sep 2020 19:27:57 GMT Subject: RFR: 8253639: Change os::attempt_reserve_memory_at parameter order In-Reply-To: References: <0MJI9DrcQ8bKFZfFGLPLecI-U3Fu5D7ttmy4WHTRLko=.809857c7-c445-4df6-ae33-ad84e6789627@github.com> Message-ID: On Fri, 25 Sep 2020 19:03:16 GMT, Ioi Lam wrote: > Could you add an explanation in the bug report for the reason of this change? Sure. I thought it was obvious, but I agree a comment would be good. I added: The motivation is that it's simply awkward to have attempt_reserve_memory_at use the opposite order of most other memory range APIs. Examples of APIs using the order addr, size: 1) void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset); 2) PVOID VirtualAlloc2(..., BaseAddress, Size, ...) 3) ReservedMemoryRegion(address base, size_t size) 4) MemRegion(HeapWord* start, size_t word_size) 5) ReservedSpace(char* base, size_t size 6) commit_memory(char* addr, size_t bytes, bool executable) ------------- PR: https://git.openjdk.java.net/jdk/pull/359 From iklam at openjdk.java.net Fri Sep 25 19:38:42 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 25 Sep 2020 19:38:42 GMT Subject: RFR: 8253639: Change os::attempt_reserve_memory_at parameter order In-Reply-To: <0MJI9DrcQ8bKFZfFGLPLecI-U3Fu5D7ttmy4WHTRLko=.809857c7-c445-4df6-ae33-ad84e6789627@github.com> References: <0MJI9DrcQ8bKFZfFGLPLecI-U3Fu5D7ttmy4WHTRLko=.809857c7-c445-4df6-ae33-ad84e6789627@github.com> Message-ID: <8dDr07kjE73JgwiOCvYPk2Cwocoi_Y0ea5HbB4qy5W4=.f2057e57-b02c-4385-9a88-1f74246fc1e0@github.com> On Fri, 25 Sep 2020 13:26:30 GMT, Stefan Karlsson wrote: > I propose that we change the parameter order from: > os::attempt_reserve_memory_at(size, addr, ) > > to: > os::attempt_reserve_memory_at(addr, size, ) > > This patch builds upon the changes in pull/357. There's currently no way to create an incremental review, but I want to > get this out for review now. So, unfortunately you have to ignore the first commit and look at the second commit. Looks good to me. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/359 From stefank at openjdk.java.net Fri Sep 25 19:56:22 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 25 Sep 2020 19:56:22 GMT Subject: RFR: 8253639: Change os::attempt_reserve_memory_at parameter order In-Reply-To: <8dDr07kjE73JgwiOCvYPk2Cwocoi_Y0ea5HbB4qy5W4=.f2057e57-b02c-4385-9a88-1f74246fc1e0@github.com> References: <0MJI9DrcQ8bKFZfFGLPLecI-U3Fu5D7ttmy4WHTRLko=.809857c7-c445-4df6-ae33-ad84e6789627@github.com> <8dDr07kjE73JgwiOCvYPk2Cwocoi_Y0ea5HbB4qy5W4=.f2057e57-b02c-4385-9a88-1f74246fc1e0@github.com> Message-ID: On Fri, 25 Sep 2020 19:35:57 GMT, Ioi Lam wrote: >> I propose that we change the parameter order from: >> os::attempt_reserve_memory_at(size, addr, ) >> >> to: >> os::attempt_reserve_memory_at(addr, size, ) >> >> This patch builds upon the changes in pull/357. There's currently no way to create an incremental review, but I want to >> get this out for review now. So, unfortunately you have to ignore the first commit and look at the second commit. > > Looks good to me. Thanks all for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/359 From stefank at openjdk.java.net Fri Sep 25 19:57:28 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 25 Sep 2020 19:57:28 GMT Subject: RFR: 8253638: Cleanup os::reserve_memory and remove MAP_FIXED In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 19:00:56 GMT, Ioi Lam wrote: >> There's a code path through os::reserve_memory that uses MAP_FIXED. This path is used if a requested address is given. >> It's very dangerous to use MAP_FIXED, since it causes pre-existing mappings to be replaced. Alternative, move safe, >> functions exists; named os_attempt_reserve_memory_at. It's not only dangerous to use that API, the Mac AARCH64 port >> also can't use it in conjunction with its MAP_JIT. >> I started to split os::reserve_memory into two functions; one that doesn't care about were the memory is mapped >> (os::reserve_memory), and another that uses the dangerous MAP_FIXED flag (os::reserve_memory_at). However, I noticed >> that it's only windows code that actually use os::reserve_memory with a requested address. All other usages have been >> cleaned out and replaced with os::attempt_reserve_memory. And on windows os::attempt_reserve_memory uses >> os::reserve_memory with comments that it's safe because it only "attempts" to place the mapping. So, this patch: 1) >> Removes the forcefully reserving of memory and its MAP_FIXED usages! 2) Changes the windows code to call the >> attempt_reserve_memory_at version, that it actually did anyway. 3) Flips the call order between pd_reserve_memory and >> pd_attempt_reserve_memory_at, on windows. 4) There's also some unification and split done to handle MEMFLAGS and fds. >> This part needs followup cleanups (IMHO). 5) The AIX implementation already refused to use MAP_FIXED, and now it >> doesn't need special code to handle that. 6) Small cleanups around anon_mmap and anon_mmap_aligned > > Looks good to me. I checked the existing calls and no one is calling os::reserve_memory with fixed==true, so this > change doesn't impact any existing functionality. It's good to remove a dangerous API. Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/357 From eosterlund at openjdk.java.net Fri Sep 25 20:20:40 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 25 Sep 2020 20:20:40 GMT Subject: RFR: 8247691: [aarch64] Incorrect handling of VM exceptions in C1 deopt stub/traps In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 13:54:51 GMT, Erik ?sterlund wrote: >> The immediate issue that causes the error symptom is due to the procedure link register (LR) not being preserved across >> the actual call to the "patching" function (in code generated from '_generate_patching()_'), invoked as part of the C1 >> deoptimization traps. However, this update addresses a larger issue with the current implementation. >> >> Since the Aarch64 implementation does not adopt patching but deoptimization to support load-mirror et.al., the >> "patching" stub-code does not need to support the exception protocol otherwise necessary when a VM transition might be >> needed in the actual patching function. The deoptimization is compulsory and the transition to the interpreter will >> cater for proper interaction with the VM. The proposed solution is thus: 1. The version of '_patch_code()_' used >> with **DEOPTIMIZE_WHEN_PATCHING** should not be modelled as a **JRT_ENTRY**. The "patching" functions will not transfer >> control to VM (for up-call or otherwise). 2. The patch-stub code does not need to handle the VM exception protocol >> (code can be removed). 3. The patch-stub code need only to support deoptimization and re-execute (it's a fatal error >> otherwise). 4. The patch-stub code does not need to utilise any instruction stream synchronisation barrier as no >> patching/modifying of the instruction stream is done (including indirectly through a VM transition). > > Looks good. > > *Mailing list message from [Andrew Dinn](mailto:adinn at redhat.com) on [hotspot-dev](mailto:hotspot-dev at openjdk.java.net):* > > On 25/09/2020 17:45, Andrew Haley wrote: > > Hmm. I left this code in because there always is a possibility that we > > could enable C1 patching in the future. C1 patching does nothing > > useful when we have tiered compilation because recompiles due to > > tiered are ten times as common as recompiles due to patching needed, > > so being able to patch makes almost no difference to run > > time. However, there always was a possibility that some form of > > "patching" might be possible, given appropriate code generation > > strategies. This could be useful in small C1-only systems, in theory, > > but I haven't seen any interest in such things. > > > > On the other hand, I don't like dead code in the port and it's > > probably time for it to die. > > > > Anyone else have an opinion? > > It's dead, Jim. I think it's time to take it away and bury it somewhere. > We can always disinter it should resuscitation ever seem like a good > idea (which doesn't seem too likely). > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill +1. Should we need this stuff in the distant future, we can just revive it then, should that happen. ------------- PR: https://git.openjdk.java.net/jdk/pull/344 From minqi at openjdk.java.net Fri Sep 25 21:08:07 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 25 Sep 2020 21:08:07 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v2] In-Reply-To: References: Message-ID: > This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous > webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the > regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. Tests: tier1-4 Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - Merge branch 'master' into jdk-8247536 - Merge branch 'master' of https://github.com/openjdk/jdk - Merge branch 'master' of https://github.com/openjdk/jdk - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - Merge remote-tracking branch 'upstream/master' into jdk-8247536 - Merge remote-tracking branch 'upstream/master' into jdk-8247536 - Merge remote-tracking branch 'origin/jdk-8252689' - 8252689: Classes are loaded from jrt:/java.base even when CDS is used - 8252689: Classes are loaded from jrt:/java.base even when CDS is used - ... and 1 more: https://git.openjdk.java.net/jdk/compare/8b85c3a6...f45f364d ------------- Changes: https://git.openjdk.java.net/jdk/pull/193/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=01 Stats: 425 lines in 19 files changed: 399 ins; 13 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/193.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193 PR: https://git.openjdk.java.net/jdk/pull/193 From kvn at openjdk.java.net Fri Sep 25 21:08:50 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 25 Sep 2020 21:08:50 GMT Subject: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions [v5] In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 05:17:38 GMT, Jatin Bhateja wrote: >> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 7971: >> >>> 7969: BasicType type, int offset, bool use64byteVector) { >>> 7970: assert(MaxVectorSize >= 32, "vector length < 32"); >>> 7971: use64byteVector |= MaxVectorSize > 32 && AVX3Threshold == 0; >> >> When do you expect AVX3Threshold to be 0? > > As of now when user explicitly pass -XX:AVX3Threshold=0 , default value of AVX3Threshold is 4096. I don't like that you put special meaning on AVX3Threshold=0 and then have to add additional checks for it in places where you check its power of 2. And you don't check such setting in new tests. Actually checking for 0 and power of 2 should be done by flag's constraint. See CodeEntryAlignmentConstraintFunc as example. There is also this strange relation with MaxVectorSize. Also we should consider power level switch for 64 bytes AVX3 vectors. Does it make sense to use it if array length is small (< 4096 default)? ------------- PR: https://git.openjdk.java.net/jdk/pull/61 From kvn at openjdk.java.net Fri Sep 25 21:08:49 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 25 Sep 2020 21:08:49 GMT Subject: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions [v5] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 15:55:11 GMT, Jatin Bhateja wrote: >> Summary: >> >> 1) New AVX3 optimized stubs for both conjoint and disjoint arraycopy. >> 2) Special instruction sequence blocks for copy sizes b/w 32-192 bytes. >> 3) Block copy operation above 192 bytes is performed using destination address aligned PRE-MAIN-POST loop. Main loop >> copies 192 byte in one iteration and tail part fall over special instruction sequence blocks. 4) Both small copy block >> and aligned loop use 32 byte vector register to prevent and frequency penalty for copy sizes less than AVX3Threshold. >> 5) For block size above AVX3Theshold both special blocks and loop operate using 64 byte register. 6) In case user >> sets the maximum vector size to 32 bytes, forward copy (disjoint) operations are done using efficient REP MOVS for copy >> sizes above 4096 bytes. JMH Results: >> System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz >> Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java >> Baseline : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_Baseline.txt]() >> WithOpt : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_WithOpts.txt]() > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8252847 : Modifying file permission to resolve jcheck failure. The main concern which is not clear in these changes is ZMM usage which will lower frequency and case performance regression for small arrays. That is why AVX3Threshold is set to 4096 bytes by default. Allowing and checking for 0 AVX3Threshold value contradicts that. Would be nice to have clear comment/explanation about that. I also propose to use Flag constraint() functionality for checking AVX3Threshold value instead of runtime checks everywhere. Separate RFE, please. src/hotspot/cpu/x86/assembler_x86.cpp line 2593: > 2591: > 2592: void Assembler::evmovdqu(XMMRegister dst, KRegister mask, Address src, int vector_len, int type) { > 2593: assert(VM_Version::supports_avx512vlbw(), ""); I suggest to add assert to these 2 new instruction to check 'type' value to make sure only expected types are passed. src/hotspot/cpu/x86/assembler_x86.cpp line 2596: > 2594: InstructionMark im(this); > 2595: bool wide = type == T_SHORT || type == T_LONG || type == T_CHAR; > 2596: bool bwinstr = type == T_BYTE || type == T_SHORT || type == T_CHAR; 'bwinstr' is used only once. You may as well directly set 'prefix' here. (Same in second instruction). src/hotspot/cpu/x86/assembler_x86.cpp line 2595: > 2593: assert(VM_Version::supports_avx512vlbw(), ""); > 2594: InstructionMark im(this); > 2595: bool wide = type == T_SHORT || type == T_LONG || type == T_CHAR; It looks strange but it is correct (I looked on existing evmovdqu* instructions). May be reorder - T_LONG last. Do you consider replacing existing evmovdqu* instructions with these two? src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 1264: > 1262: } > 1263: > 1264: #ifndef PRODUCT macroAssembler_x86.hpp become big. May be we should start thing about splitting arraycopy stubs into separate file. src/hotspot/cpu/x86/stubRoutines_x86.hpp line 36: > 34: enum platform_dependent_constants { > 35: code_size1 = 20000 LP64_ONLY(+10000), // simply increase if too small (assembler will crash if too small) > 36: code_size2 = 35300 LP64_ONLY(+21400) // simply increase if too small (assembler will crash if too small) This is big increase in size! src/hotspot/cpu/x86/vm_version_x86.cpp line 1167: > 1165: > 1166: if (!FLAG_IS_DEFAULT(AVX3Threshold)) { > 1167: if (AVX3Threshold != 0 && !is_power_of_2(AVX3Threshold)) { Consider flag's constraint() instead of runtime these checks. Separate RFE, please. src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64ArrayCompareToOp.java line 87: > 85: super(TYPE); > 86: > 87: assert useAVX3Threshold == 0 || CodeUtil.isPowerOf2(useAVX3Threshold) : "AVX3Threshold must be power of 2"; You would need to upstream Graal changes. test/hotspot/jtreg/compiler/arraycopy/TestArrayCopyConjoint.java line 33: > 31: * > 32: * @run main/othervm/timeout=600 -XX:-TieredCompilation -Xbatch -XX:+IgnoreUnrecognizedVMOptions > 33: * -XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:ArrayCopyPartialInlineSize=0 -XX:MaxVectorSize=32 -XX:+UnlockDiagnosticVMOptions ArrayCopyPartialInlineSize flag is not defiled in these changes. It seems they need to be included in 8252848 changes. ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/61 From minqi at openjdk.java.net Fri Sep 25 21:19:39 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 25 Sep 2020 21:19:39 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v3] In-Reply-To: References: Message-ID: > This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous > webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the > regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. Tests: tier1-4 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/193/files - new: https://git.openjdk.java.net/jdk/pull/193/files/f45f364d..b1955272 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=01-02 Stats: 88 lines in 15 files changed: 57 ins; 15 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/193.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193 PR: https://git.openjdk.java.net/jdk/pull/193 From minqi at openjdk.java.net Fri Sep 25 21:41:22 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 25 Sep 2020 21:41:22 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v4] In-Reply-To: References: Message-ID: > This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous > webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the > regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. Tests: tier1-4 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/193/files - new: https://git.openjdk.java.net/jdk/pull/193/files/b1955272..4148e7d4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/193.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193 PR: https://git.openjdk.java.net/jdk/pull/193 From minqi at openjdk.java.net Fri Sep 25 21:58:36 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 25 Sep 2020 21:58:36 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v5] In-Reply-To: References: Message-ID: <58G1o_bRoZOc9vFivWYgPj1xaCL1G3UaR5a0BtEuGx8=.afcd2c71-72d1-47ad-8b4f-4faff40a231d@github.com> > This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous > webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the > regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. Tests: tier1-4 Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge branch 'master' of https://git.openjdk.java.net/jdk into jdk-8247536 - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - Merge branch 'master' into jdk-8247536 - Merge branch 'master' of https://github.com/openjdk/jdk - Merge branch 'master' of https://github.com/openjdk/jdk - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - Merge remote-tracking branch 'upstream/master' into jdk-8247536 - Merge remote-tracking branch 'upstream/master' into jdk-8247536 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/b159e4ed...01b229cc ------------- Changes: https://git.openjdk.java.net/jdk/pull/193/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=04 Stats: 464 lines in 21 files changed: 440 ins; 13 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/193.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193 PR: https://git.openjdk.java.net/jdk/pull/193 From iklam at openjdk.java.net Fri Sep 25 21:58:38 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 25 Sep 2020 21:58:38 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v3] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 21:19:39 GMT, Yumin Qi wrote: >> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous >> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the >> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses >> function. Tests: tier1-4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive Changes requested by iklam (Reviewer). test/hotspot/jtreg/runtime/cds/appcds/DumpClassListWithLF.java line 32: > 30: * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds > 31: * @compile ClassListFormatBase.java test-classes/Hello.java > 32: * @run driver DumpClassListWithLF The `@compile` line can be removed to speed up the test execution. You can add this: @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds/test-classes and also change the code below appJar, classlist( - "Hello", + Hello.class.getName(), (There's no need for `/test/hotspot/jtreg/runtime/cds/appcds` in `@library` because that's the current directory of this test). test/hotspot/jtreg/runtime/cds/appcds/DumpClassListWithLF.java line 53: > 51: "Hello", > 52: "@lambda-form-invoker [LF_RESOLVE] java.lang.invoke.DirectMethodHandle$Holder invokeStatic L7_L > (success)", 53: "@lambda-form-invoker [LF_RESOLVE] java.lang.invoke.DirectMethodHandle$Holder > invokeStatic LL_I (success)"), I think the `(success)` part should not be included in the classlist. The classlist is the public interface. It should be concise and include only the necessary information. @lambda-form-invoker [LF_RESOLVE] java.lang.invoke.DirectMethodHandle$Holder invokeStatic L7_L @lambda-form-invoker [LF_RESOLVE] java.lang.invoke.DirectMethodHandle$Holder invokeStatic LL_I test/hotspot/jtreg/runtime/cds/appcds/customLoader/ProhibitedPackageNamesTest.java line 31: > 29: * @requires vm.cds.custom.loaders > 30: * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds > 31: * @compile ../ClassListFormatBase.java ../test-classes/Hello.java test-classes/InProhibitedPkg.java Similar comment for avoiding `@compile`. `@compile` has been mis-used by older CDS tests. We should avoid using it, and should remove it when we are touching the old tests. src/hotspot/share/classfile/systemDictionary.cpp line 1864: > 1862: > 1863: // Used for assertions and verification, also used from LambdaFormInvokers::reload_class > 1864: // to get original class which has already been loaded. Is the above comment change still needed? ------------- PR: https://git.openjdk.java.net/jdk/pull/193 From coleenp at openjdk.java.net Fri Sep 25 22:15:10 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 25 Sep 2020 22:15:10 GMT Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v3] In-Reply-To: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> Message-ID: > That the monitor has already been unlocked, or is a null stacklock monitor has been already checked in the caller, so > the code that makes it a JRT_ENTRY_NO_ASYNC is unnecessary. > Making it a JRT_LEAF like the compiled method entries makes it safer. We know it can never safepoint and > unintentionally install a async exception. > Tested with tier1-6. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: make calls through call_VM_leaf ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/320/files - new: https://git.openjdk.java.net/jdk/pull/320/files/a54ae7cd..083f345d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=320&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=320&range=01-02 Stats: 70 lines in 10 files changed: 6 ins; 36 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/320.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/320/head:pull/320 PR: https://git.openjdk.java.net/jdk/pull/320 From iklam at openjdk.java.net Fri Sep 25 22:23:34 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 25 Sep 2020 22:23:34 GMT Subject: RFR: 8253402: Convert vmSymbols::SID to enum class [v2] In-Reply-To: References: Message-ID: <2OwQBbIcnjHfvfRcyRo0evb8tFPgNSP_n91VPhJwASc=.84300d55-aa7b-4dec-acbb-94a828adce58@github.com> > Convert `vmSymbols::SID` to an `enum class` to provide better type safety. > > - The original enum type `vmSymbols::SID` cannot be forward-declared. I moved it out of the `vmSymbols` class and > renamed, so now it can be forward-declared as `enum class vmSymbolID : int;`, without including the large vmSymbols.hpp > file. > - This also breaks the mutual dependency between the `vmSymbols` and `vmIntrinsics` classes. Now the declaration of > `vmIntrinsics` can be moved from vmSymbols.hpp to vmIntrinsics.hpp, where it naturally belongs. > - Type-safe enumeration (contributed by Kim Barrett) > for (vmSymbolID index : vmSymbolsIterator()) { > vm_symbol_index[as_int(index)] = index; > } > - I moved `vmSymbols::_symbols[]` to `Symbol::_vm_symbols[]`, and made it accessible via `Symbol::vm_symbol_at()`. This > way, header files (e.g. fieldInfo.hpp) that need to convert from `vmSymbolID` to `Symbol*` don't need to include the > large vmSymbols.hpp file. > - I changed the `VM_SYMBOL_ENUM_NAME` macro so that the users don't need to explicitly add the `vmSymbolID::` scope. > - I removed many unnecessary casts between `int` and `vmSymbolID`. > - The remaining casts are done via `vmSymbol::as_int()` and `vmSymbols::as_SID()` with range checks. > > ----- > If this is successful, I will do the same for `vmIntrinsics::ID`. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - more vmEnums.hpp fixes; fixed minimal VM build - Merge branch 'master' into 8253402-convert-vmsymbols-sid-to-enum-class - Moved forward declaration of vmSymbolID to vmEnums.hpp - clean up whitespaces and removed useless comment - removed unnecessary include - 8253402: Convert vmSymbols::SID to enum class ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/276/files - new: https://git.openjdk.java.net/jdk/pull/276/files/443cf52a..1ad27fdb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=276&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=276&range=00-01 Stats: 30598 lines in 679 files changed: 5310 ins; 23542 del; 1746 mod Patch: https://git.openjdk.java.net/jdk/pull/276.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/276/head:pull/276 PR: https://git.openjdk.java.net/jdk/pull/276 From iklam at openjdk.java.net Fri Sep 25 22:23:34 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 25 Sep 2020 22:23:34 GMT Subject: RFR: 8253402: Convert vmSymbols::SID to enum class [v2] In-Reply-To: References: <2RctRAOHDMDgW1Qu57RDcOF1Uns4pjAZfR6Yg9dTb_0=.d3f1bcdd-39b8-4504-8f1a-76541bb5c55e@github.com> <7Ot4ggK2CL3qnw1M3VSdDY3ZzPnUCEz5FZdWwfIN6fc=.d1c175cc-bb50-41a3-8c11-bb252fe6de46@github.com> Message-ID: On Fri, 25 Sep 2020 19:15:48 GMT, Vladimir Kozlov wrote: >> How about having a new header file utilities/vmEnums.hpp that looks like this: >> >> // Include this header file if you just need the following enum types and >> // you don't use their members directly. This way you don't need to include the >> // complex header files that have the full definitions of these enums. >> enum JVMFlagsEnum : int; >> enum class vmSymbolID : int; >> >> My plan is to have at least 2 more such enums (one for `vmIntrinsics::ID`, and one for `SystemDictionary::WKID`). >> >> `: int` is the base type of the enum. I think that's part of the type's implementation so it shouldn't be exposed to >> the user of these types. If we litter `enum class vmSymbolID : int;` all over, when we decide to change the base type >> to something else, we would need to edit all such places. Worse, if your forward declaration is wrong, like >> >> enum class vmSymbolID : char; >> >> the compiler won't detect this if your source file doesn't *also* include vmSymbols.hpp, so it could be dangerous. > > I am okay with this suggestion. I've moved the forward declarations into vmEnum.hpp in the latest version. ------------- PR: https://git.openjdk.java.net/jdk/pull/276 From coleenp at openjdk.java.net Fri Sep 25 22:43:50 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 25 Sep 2020 22:43:50 GMT Subject: RFR: 8253402: Convert vmSymbols::SID to enum class [v2] In-Reply-To: References: <2RctRAOHDMDgW1Qu57RDcOF1Uns4pjAZfR6Yg9dTb_0=.d3f1bcdd-39b8-4504-8f1a-76541bb5c55e@github.com> <7Ot4ggK2CL3qnw1M3VSdDY3ZzPnUCEz5FZdWwfIN6fc=.d1c175cc-bb50-41a3-8c11-bb252fe6de46@github.com> Message-ID: On Fri, 25 Sep 2020 22:19:37 GMT, Ioi Lam wrote: >> I am okay with this suggestion. > > I've moved the forward declarations into vmEnum.hpp in the latest version. Ok, I can't find it. Why did you have to add this little file to replace two forward declarations? What was wrong with the forward declarations? ------------- PR: https://git.openjdk.java.net/jdk/pull/276 From dcubed at openjdk.java.net Fri Sep 25 22:55:09 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 25 Sep 2020 22:55:09 GMT Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v3] In-Reply-To: References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> Message-ID: On Fri, 25 Sep 2020 22:15:10 GMT, Coleen Phillimore wrote: >> That the monitor has already been unlocked, or is a null stacklock monitor has been already checked in the caller, so >> the code that makes it a JRT_ENTRY_NO_ASYNC is unnecessary. >> Making it a JRT_LEAF like the compiled method entries makes it safer. We know it can never safepoint and >> unintentionally install a async exception. >> Tested with tier1-6. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > make calls through call_VM_leaf Thumbs up on this latest version. What testing have you run with it? ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/320 From coleenp at openjdk.java.net Fri Sep 25 22:55:10 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 25 Sep 2020 22:55:10 GMT Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v3] In-Reply-To: References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> Message-ID: On Fri, 25 Sep 2020 22:50:31 GMT, Daniel D. Daugherty wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> make calls through call_VM_leaf > > Thumbs up on this latest version. > > What testing have you run with it? Thanks Dan! I only ran tier1 on this latest version and builds on other platforms, because breaking this would be a catastrophic failure, but I'll run tiers 2-6 over the weekend. ------------- PR: https://git.openjdk.java.net/jdk/pull/320 From coleenp at openjdk.java.net Fri Sep 25 22:55:11 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 25 Sep 2020 22:55:11 GMT Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v2] In-Reply-To: References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> Message-ID: On Thu, 24 Sep 2020 15:54:33 GMT, Daniel D. Daugherty wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function > > src/hotspot/share/runtime/sharedRuntime.cpp line 2106: > >> 2104: JRT_LEAF(void, SharedRuntime::complete_monitor_unlocking_C(oopDesc* obj, BasicLock* lock, JavaThread* thread)) >> 2105: // The object could become unlocked through a JNI call, which we have no other checks for. >> 2106: // Give a message if CheckJNICalls but ignore. > > That comment is a bit misleading. Perhaps: > // Give a fatal message if CheckJNICalls. Otherwise we ignore it. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/320 From david.holmes at oracle.com Fri Sep 25 23:03:01 2020 From: david.holmes at oracle.com (David Holmes) Date: Sat, 26 Sep 2020 09:03:01 +1000 Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v2] In-Reply-To: References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> Message-ID: <9ce3b31a-8d07-cfd9-d8b8-6588479cd689@oracle.com> On 26/09/2020 4:45 am, Coleen Phillimore wrote: > On 9/25/20 11:18 AM, Daniel D. Daugherty wrote: >> Looks like this reply from David didn't end up getting added to the >> PR by the SkaraBot... It will be interesting to see if my reply to >> David's reply gets picked up by the SkaraBot... >> > > This thread isn't going through the SkaraBot.? I can't tell you exactly > why. "It looks at the In-Reply-To header (from the mbox-formatted archive) to determine which mails are part of a PR-initiated conversation." This one started from a git notification email. >> >> Both Coleen and I crawled through the current set of code paths that >> get us into InterpreterRuntime::monitorexit() and we have (mostly) >> convinced ourselves that all code paths are covered by ownership >> checks and the throwing of IllegalMonitorStateException. However, to >> guard against future code breakage (or errors in our analysis) we >> decided to add _something_ to catch errors here. We talked about >> assert()s, guarantee()s and fatal() calls. Coleen settled on the >> fatal() call guarded by CheckJNICalls. Since we believe that only >> JNI code can screw this up (modulo new bugs in the interpreter or >> compiler code generation), this seemed like the right way to go.. >> > > Yes, thank you very much for looking through this and our discussions > offline.? It would have been another 100 email messages.? Thank you for > the summary. Yes thanks for the additional info. As I said "the check is a good safety net". Cheers, David ----- > Coleen > >> Dan >> >> >> On 9/25/20 7:21 AM, David Holmes wrote: >>> Hi Martin, Coleen, >>> >>> Well this is a little embarrasing so I need to clarify this :) The >>> "email" Martin received was presumably a direct notification from >>> github. I added a comment and then immediately realized my mistake >>> and deleted it before the skara bots sent out the email to the >>> mailing list. But the github notification was sent immediately. :( >>> >>> Please ignore the comment as I realised this was handled at the >>> previous level as Martin describes. >>> >>> Aside: I'm not at all sure it is even possible to hit the bit with >>> the CheckJNICalls given we must have found a valid BasicObjectLock to >>> get that far. But trying to figure out all the possible paths was too >>> complex - the check is a good safety net. >>> >>> Cheers, >>> David >>> >>> On 25/09/2020 7:19 pm, Martin Doerr wrote: >>>> On Thu, 24 Sep 2020 14:24:43 GMT, Coleen Phillimore >>>> wrote: >>>> >>>>>> Please note that complete_monitor_unlocking_C is only called by >>>>>> C2. Other JIT compilers have other functions. >>>>>> SharedRuntime::monitor_exit_helper is used by all ones. I had >>>>>> another question: Shouldn't the call sites in the >>>>>> interpreter use call_VM_leaf instead of call_VM? >>>>> >>>>> @TheRealMDoerr you're right, it should be call_VM_leaf so that >>>>> popframe and force early return are not executed. >>>>> Setting up last_Java_sp is benign but unnecessary.? I should have >>>>> changed the code in >>>>> SharedRuntime::monitor_exit_helper instead.? Thanks for looking at >>>>> this and your help! >>>> >>>> Hi David, >>>> >>>> the IllegalMonitorStateException should get thrown by the code >>>> generated by TemplateTable::monitorexit() without >>>> reaching InterpreterRuntime::monitorexit in this scenario. But we >>>> should review this carefully and run all such JCK >>>> tests and whatever we have before pushing this change. >>>> >>>> Coleen?s check for already unlocked objects is only for JNI and is >>>> not mandatory AFAICS: >>>> ?Native code must not use MonitorExit to exit a monitor entered >>>> through a synchronized method or a monitorenter Java >>>> virtual machine instruction.? >>>> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#MonitorExit >>>> >>>> So Coleen has chosen to implement the undefined behavior such that >>>> we gracefully ignore it or report fatal with >>>> CheckJNICalls. >>>> >>>> Best regards, >>>> Martin >>>> >>>> >>>> From: David Holmes >>>> Sent: Freitag, 25. September 2020 07:40 >>>> To: openjdk/jdk >>>> Cc: Doerr, Martin ; Mention >>>> >>>> Subject: Re: [openjdk/jdk] 8253540: InterpreterRuntime::monitorexit >>>> should be a JRT_LEAF function (#320) >>>> >>>> >>>> Hi Coleen, >>>> I believe that failing to throw IllegalMonitorStateException now >>>> violates the JVMS. Even if the VM enforces balanced >>>> locking it should still throw IMSE here. Consider a JCK-style test >>>> that just performs a monitorexit with no >>>> monitorenter, expecting to get IMSE - such a test exists. >>>> >>>> Cheers, >>>> David >>>> >>>> ? >>>> You are receiving this because you were mentioned. >>>> Reply to this email directly, view it on >>>> GitHub, >>>> or >>>> unsubscribe. >>>> >>>> >>>> ------------- >>>> >>>> PR: https://git.openjdk.java.net/jdk/pull/320 >>>> >> > From coleenp at openjdk.java.net Fri Sep 25 23:03:43 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 25 Sep 2020 23:03:43 GMT Subject: RFR: 8253402: Convert vmSymbols::SID to enum class [v2] In-Reply-To: <2OwQBbIcnjHfvfRcyRo0evb8tFPgNSP_n91VPhJwASc=.84300d55-aa7b-4dec-acbb-94a828adce58@github.com> References: <2OwQBbIcnjHfvfRcyRo0evb8tFPgNSP_n91VPhJwASc=.84300d55-aa7b-4dec-acbb-94a828adce58@github.com> Message-ID: On Fri, 25 Sep 2020 22:23:34 GMT, Ioi Lam wrote: >> Convert `vmSymbols::SID` to an `enum class` to provide better type safety. >> >> - The original enum type `vmSymbols::SID` cannot be forward-declared. I moved it out of the `vmSymbols` class and >> renamed, so now it can be forward-declared as `enum class vmSymbolID : int;`, without including the large vmSymbols.hpp >> file. >> - This also breaks the mutual dependency between the `vmSymbols` and `vmIntrinsics` classes. Now the declaration of >> `vmIntrinsics` can be moved from vmSymbols.hpp to vmIntrinsics.hpp, where it naturally belongs. >> - Type-safe enumeration (contributed by Kim Barrett) >> for (vmSymbolID index : vmSymbolsIterator()) { >> vm_symbol_index[as_int(index)] = index; >> } >> - I moved `vmSymbols::_symbols[]` to `Symbol::_vm_symbols[]`, and made it accessible via `Symbol::vm_symbol_at()`. This >> way, header files (e.g. fieldInfo.hpp) that need to convert from `vmSymbolID` to `Symbol*` don't need to include the >> large vmSymbols.hpp file. >> - I changed the `VM_SYMBOL_ENUM_NAME` macro so that the users don't need to explicitly add the `vmSymbolID::` scope. >> - I removed many unnecessary casts between `int` and `vmSymbolID`. >> - The remaining casts are done via `vmSymbol::as_int()` and `vmSymbols::as_SID()` with range checks. >> >> ----- >> If this is successful, I will do the same for `vmIntrinsics::ID`. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes > the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last > revision: > - more vmEnums.hpp fixes; fixed minimal VM build > - Merge branch 'master' into 8253402-convert-vmsymbols-sid-to-enum-class > - Moved forward declaration of vmSymbolID to vmEnums.hpp > - clean up whitespaces and removed useless comment > - removed unnecessary include > - 8253402: Convert vmSymbols::SID to enum class src/hotspot/share/utilities/vmEnums.hpp line 33: > 31: > 32: enum JVMFlagsEnum : int; > 33: enum class vmSymbolID : int; I don't like that you mixed two different enums that are used in different places here. Can you go back? ------------- PR: https://git.openjdk.java.net/jdk/pull/276 From iklam at openjdk.java.net Fri Sep 25 23:28:09 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 25 Sep 2020 23:28:09 GMT Subject: RFR: 8253402: Convert vmSymbols::SID to enum class [v2] In-Reply-To: References: <2OwQBbIcnjHfvfRcyRo0evb8tFPgNSP_n91VPhJwASc=.84300d55-aa7b-4dec-acbb-94a828adce58@github.com> Message-ID: On Fri, 25 Sep 2020 22:46:20 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes >> the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last >> revision: >> - more vmEnums.hpp fixes; fixed minimal VM build >> - Merge branch 'master' into 8253402-convert-vmsymbols-sid-to-enum-class >> - Moved forward declaration of vmSymbolID to vmEnums.hpp >> - clean up whitespaces and removed useless comment >> - removed unnecessary include >> - 8253402: Convert vmSymbols::SID to enum class > > src/hotspot/share/utilities/vmEnums.hpp line 33: > >> 31: >> 32: enum JVMFlagsEnum : int; >> 33: enum class vmSymbolID : int; > > I don't like that you mixed two different enums that are used in different places here. Can you go back? The intention is to put other enums like vmIntrinsics::ID and SystemDictionary::WKID here. It's going to be a small collection of "enums used by the VM that have complex definitions but you probably don't care". ------------- PR: https://git.openjdk.java.net/jdk/pull/276 From kvn at openjdk.java.net Sat Sep 26 02:23:01 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Sat, 26 Sep 2020 02:23:01 GMT Subject: RFR: 8253402: Convert vmSymbols::SID to enum class [v2] In-Reply-To: <2OwQBbIcnjHfvfRcyRo0evb8tFPgNSP_n91VPhJwASc=.84300d55-aa7b-4dec-acbb-94a828adce58@github.com> References: <2OwQBbIcnjHfvfRcyRo0evb8tFPgNSP_n91VPhJwASc=.84300d55-aa7b-4dec-acbb-94a828adce58@github.com> Message-ID: On Fri, 25 Sep 2020 22:23:34 GMT, Ioi Lam wrote: >> Convert `vmSymbols::SID` to an `enum class` to provide better type safety. >> >> - The original enum type `vmSymbols::SID` cannot be forward-declared. I moved it out of the `vmSymbols` class and >> renamed, so now it can be forward-declared as `enum class vmSymbolID : int;`, without including the large vmSymbols.hpp >> file. >> - This also breaks the mutual dependency between the `vmSymbols` and `vmIntrinsics` classes. Now the declaration of >> `vmIntrinsics` can be moved from vmSymbols.hpp to vmIntrinsics.hpp, where it naturally belongs. >> - Type-safe enumeration (contributed by Kim Barrett) >> for (vmSymbolID index : vmSymbolsIterator()) { >> vm_symbol_index[as_int(index)] = index; >> } >> - I moved `vmSymbols::_symbols[]` to `Symbol::_vm_symbols[]`, and made it accessible via `Symbol::vm_symbol_at()`. This >> way, header files (e.g. fieldInfo.hpp) that need to convert from `vmSymbolID` to `Symbol*` don't need to include the >> large vmSymbols.hpp file. >> - I changed the `VM_SYMBOL_ENUM_NAME` macro so that the users don't need to explicitly add the `vmSymbolID::` scope. >> - I removed many unnecessary casts between `int` and `vmSymbolID`. >> - The remaining casts are done via `vmSymbol::as_int()` and `vmSymbols::as_SID()` with range checks. >> >> ----- >> If this is successful, I will do the same for `vmIntrinsics::ID`. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes > the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last > revision: > - more vmEnums.hpp fixes; fixed minimal VM build > - Merge branch 'master' into 8253402-convert-vmsymbols-sid-to-enum-class > - Moved forward declaration of vmSymbolID to vmEnums.hpp > - clean up whitespaces and removed useless comment > - removed unnecessary include > - 8253402: Convert vmSymbols::SID to enum class Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/276 From stuefe at openjdk.java.net Sat Sep 26 06:34:00 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 26 Sep 2020 06:34:00 GMT Subject: RFR: 8253638: Cleanup os::reserve_memory and remove MAP_FIXED In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 13:41:02 GMT, Thomas Stuefe wrote: >> Created JDK-8253648. > > Yes, I feel os::vm_allocation_granularity is often misunderstood. A cleanup would be good. -> https://bugs.openjdk.java.net/browse/JDK-8253683 ------------- PR: https://git.openjdk.java.net/jdk/pull/357 From aph at redhat.com Sat Sep 26 09:34:55 2020 From: aph at redhat.com (Andrew Haley) Date: Sat, 26 Sep 2020 10:34:55 +0100 Subject: RFR: 8247691: [aarch64] Incorrect handling of VM exceptions in C1 deopt stub/traps In-Reply-To: References: Message-ID: <8bfdaf38-0bc2-889b-8532-936435d90990@redhat.com> On 25/09/2020 18:23, Andrew Dinn wrote: > On 25/09/2020 17:45, Andrew Haley wrote: >> Hmm. I left this code in because there always is a possibility that we >> could enable C1 patching in the future. C1 patching does nothing >> useful when we have tiered compilation because recompiles due to >> tiered are ten times as common as recompiles due to patching needed, >> so being able to patch makes almost no difference to run >> time. However, there always was a possibility that some form of >> "patching" might be possible, given appropriate code generation >> strategies. This could be useful in small C1-only systems, in theory, >> but I haven't seen any interest in such things. >> >> On the other hand, I don't like dead code in the port and it's >> probably time for it to die. >> >> Anyone else have an opinion? > It's dead, Jim. I think it's time to take it away and bury it somewhere. > We can always disinter it should resuscitation ever seem like a good > idea (which doesn't seem too likely). OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at openjdk.java.net Sat Sep 26 09:36:31 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Sat, 26 Sep 2020 09:36:31 GMT Subject: RFR: 8247691: [aarch64] Incorrect handling of VM exceptions in C1 deopt stub/traps In-Reply-To: References: Message-ID: <0GnmBNF6sLSZq0C3ynW28j4RZMwdn8loxjcedQmF7IE=.49c2e792-44b9-4608-99fe-80b2c82dac49@github.com> On Thu, 24 Sep 2020 19:14:54 GMT, Patric Hedlin wrote: > The immediate issue that causes the error symptom is due to the procedure link register (LR) not being preserved across > the actual call to the "patching" function (in code generated from '_generate_patching()_'), invoked as part of the C1 > deoptimization traps. However, this update addresses a larger issue with the current implementation. > > Since the Aarch64 implementation does not adopt patching but deoptimization to support load-mirror et.al., the > "patching" stub-code does not need to support the exception protocol otherwise necessary when a VM transition might be > needed in the actual patching function. The deoptimization is compulsory and the transition to the interpreter will > cater for proper interaction with the VM. The proposed solution is thus: 1. The version of '_patch_code()_' used > with **DEOPTIMIZE_WHEN_PATCHING** should not be modelled as a **JRT_ENTRY**. The "patching" functions will not transfer > control to VM (for up-call or otherwise). 2. The patch-stub code does not need to handle the VM exception protocol > (code can be removed). 3. The patch-stub code need only to support deoptimization and re-execute (it's a fatal error > otherwise). 4. The patch-stub code does not need to utilise any instruction stream synchronisation barrier as no > patching/modifying of the instruction stream is done (including indirectly through a VM transition). Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/344 From stuefe at openjdk.java.net Sat Sep 26 10:00:06 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 26 Sep 2020 10:00:06 GMT Subject: RFR: 8253638: Cleanup os::reserve_memory and remove MAP_FIXED In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 11:24:17 GMT, Stefan Karlsson wrote: > There's a code path through os::reserve_memory that uses MAP_FIXED. This path is used if a requested address is given. > It's very dangerous to use MAP_FIXED, since it causes pre-existing mappings to be replaced. Alternative, move safe, > functions exists; named os_attempt_reserve_memory_at. It's not only dangerous to use that API, the Mac AARCH64 port > also can't use it in conjunction with its MAP_JIT. > I started to split os::reserve_memory into two functions; one that doesn't care about were the memory is mapped > (os::reserve_memory), and another that uses the dangerous MAP_FIXED flag (os::reserve_memory_at). However, I noticed > that it's only windows code that actually use os::reserve_memory with a requested address. All other usages have been > cleaned out and replaced with os::attempt_reserve_memory. And on windows os::attempt_reserve_memory uses > os::reserve_memory with comments that it's safe because it only "attempts" to place the mapping. So, this patch: 1) > Removes the forcefully reserving of memory and its MAP_FIXED usages! 2) Changes the windows code to call the > attempt_reserve_memory_at version, that it actually did anyway. 3) Flips the call order between pd_reserve_memory and > pd_attempt_reserve_memory_at, on windows. 4) There's also some unification and split done to handle MEMFLAGS and fds. > This part needs followup cleanups (IMHO). 5) The AIX implementation already refused to use MAP_FIXED, and now it > doesn't need special code to handle that. 6) Small cleanups around anon_mmap and anon_mmap_aligned Marked as reviewed by stuefe (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/357 From mdoerr at openjdk.java.net Sat Sep 26 15:36:28 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Sat, 26 Sep 2020 15:36:28 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 02:45:36 GMT, CoreyAshford wrote: > This patch set encompasses the following commits: > > - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for > the intrinsic. The API is similar to the existing encodeBlock intrinsic. > - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic > implementation > - Adds a Power64LE-specific implementation of the decodeBlock intrinsic. > - Adds a JMH microbenchmark for both Base64 encoding and encoding. > - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding. AOT support needs an update: # Internal Error (jdk/src/hotspot/share/aot/aotCodeHeap.cpp:557), pid=345656, tid=364316 # guarantee(adr != NULL) failed: AOT Symbol not found _aot_stub_routines_base64_decodeBlock V [jvm.dll+0x1dbc6e] AOTCodeHeap::link_stub_routines_symbols+0xf7e (aotcodeheap.cpp:557) V [jvm.dll+0x1d95e8] AOTCodeHeap::link_global_lib_symbols+0x2f8 (aotcodeheap.cpp:603) V [jvm.dll+0x1dc616] AOTCodeHeap::load_klass_data+0x476 (aotcodeheap.cpp:840) V [jvm.dll+0x1e1021] AOTLoader::load_for_klass+0x161 (aotloader.cpp:55) V [jvm.dll+0x5fec96] InstanceKlass::initialize_impl+0x4e6 (instanceklass.cpp:1159) V [jvm.dll+0x5fead6] InstanceKlass::initialize_impl+0x326 (instanceklass.cpp:1133) V [jvm.dll+0xc5a633] Threads::initialize_java_lang_classes+0x93 (thread.cpp:3766) V [jvm.dll+0xc57c32] Threads::create_vm+0xa12 (thread.cpp:4037) Can be reproduced by running JTREG tests: compiler/aot/calls/fromAot ------------- Changes requested by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/293 From mdoerr at openjdk.java.net Sat Sep 26 15:59:49 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Sat, 26 Sep 2020 15:59:49 GMT Subject: RFR: 8225329: -XX:+PrintBiasedLockingStatistics causes crash during =?UTF-8?B?aW5pdGlh4oCm?= Message-ID: ?lization on Windows platforms This bug was fixed in 11.0.3-oracle, but also exists in 16: https://bugs.openjdk.java.net/browse/JDK-8225329 VM crashes when built with VS2017, but passes with this trivial fix. jdk16\bin\java -XX:+UnlockDiagnosticVMOptions -XX:+UseBiasedLocking -XX:+PrintBiasedLockingStatistics -version OpenJDK 64-Bit Server VM warning: Temporarily processing option UseBiasedLocking; support is scheduled for removal in 16.0 Seems like we won't need this fix for a long time, but fixes should be done upstream for other backports. ------------- Commit messages: - 8225329: -XX:+PrintBiasedLockingStatistics causes crash during initialization on Windows platforms Changes: https://git.openjdk.java.net/jdk/pull/372/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=372&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8225329 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/372/head:pull/372 PR: https://git.openjdk.java.net/jdk/pull/372 From stuefe at openjdk.java.net Sat Sep 26 16:26:41 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 26 Sep 2020 16:26:41 GMT Subject: RFR: 8225329: -XX:+PrintBiasedLockingStatistics causes crash during =?UTF-8?B?aW5pdGlh4oCm?= In-Reply-To: References: Message-ID: On Sat, 26 Sep 2020 15:53:54 GMT, Martin Doerr wrote: > ?lization on Windows platforms > > This bug was fixed in 11.0.3-oracle, but also exists in 16: > https://bugs.openjdk.java.net/browse/JDK-8225329 > > VM crashes when built with VS2017, but passes with this trivial fix. > > jdk16\bin\java -XX:+UnlockDiagnosticVMOptions -XX:+UseBiasedLocking -XX:+PrintBiasedLockingStatistics -version > OpenJDK 64-Bit Server VM warning: Temporarily processing option UseBiasedLocking; support is scheduled for removal in > 16.0 > Seems like we won't need this fix for a long time, but fixes should be done upstream for other backports. Hi Martin, looks reasonable. But I am curious what "fixed in Oracle11" means, Oracle only fixed this in their 11 release? I cannot find a fix in 11u, nor an associated commit in the bug report, yet it is marked as fixed. ..Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/372 From mdoerr at openjdk.java.net Sat Sep 26 16:42:15 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Sat, 26 Sep 2020 16:42:15 GMT Subject: RFR: 8225329: -XX:+PrintBiasedLockingStatistics causes crash during =?UTF-8?B?aW5pdGlh4oCm?= In-Reply-To: References: Message-ID: On Sat, 26 Sep 2020 16:23:51 GMT, Thomas Stuefe wrote: >> ?lization on Windows platforms >> >> This bug was fixed in 11.0.3-oracle, but also exists in 16: >> https://bugs.openjdk.java.net/browse/JDK-8225329 >> >> VM crashes when built with VS2017, but passes with this trivial fix. >> >> jdk16\bin\java -XX:+UnlockDiagnosticVMOptions -XX:+UseBiasedLocking -XX:+PrintBiasedLockingStatistics -version >> OpenJDK 64-Bit Server VM warning: Temporarily processing option UseBiasedLocking; support is scheduled for removal in >> 16.0 >> Seems like we won't need this fix for a long time, but fixes should be done upstream for other backports. > > Hi Martin, > > looks reasonable. But I am curious what "fixed in Oracle11" means, Oracle only fixed this in their 11 release? I cannot > find a fix in 11u, nor an associated commit in the bug report, yet it is marked as fixed. > ..Thomas Hi Thomas, it is only fixed in Oracle's closed source version of JDK11u. I want to backport it to the open source version yet. ------------- PR: https://git.openjdk.java.net/jdk/pull/372 From phedlin at openjdk.java.net Sat Sep 26 18:27:23 2020 From: phedlin at openjdk.java.net (Patric Hedlin) Date: Sat, 26 Sep 2020 18:27:23 GMT Subject: RFR: 8247691: [aarch64] Incorrect handling of VM exceptions in C1 deopt stub/traps In-Reply-To: <0GnmBNF6sLSZq0C3ynW28j4RZMwdn8loxjcedQmF7IE=.49c2e792-44b9-4608-99fe-80b2c82dac49@github.com> References: <0GnmBNF6sLSZq0C3ynW28j4RZMwdn8loxjcedQmF7IE=.49c2e792-44b9-4608-99fe-80b2c82dac49@github.com> Message-ID: On Sat, 26 Sep 2020 09:34:03 GMT, Andrew Haley wrote: >> The immediate issue that causes the error symptom is due to the procedure link register (LR) not being preserved across >> the actual call to the "patching" function (in code generated from '_generate_patching()_'), invoked as part of the C1 >> deoptimization traps. However, this update addresses a larger issue with the current implementation. >> >> Since the Aarch64 implementation does not adopt patching but deoptimization to support load-mirror et.al., the >> "patching" stub-code does not need to support the exception protocol otherwise necessary when a VM transition might be >> needed in the actual patching function. The deoptimization is compulsory and the transition to the interpreter will >> cater for proper interaction with the VM. The proposed solution is thus: 1. The version of '_patch_code()_' used >> with **DEOPTIMIZE_WHEN_PATCHING** should not be modelled as a **JRT_ENTRY**. The "patching" functions will not transfer >> control to VM (for up-call or otherwise). 2. The patch-stub code does not need to handle the VM exception protocol >> (code can be removed). 3. The patch-stub code need only to support deoptimization and re-execute (it's a fatal error >> otherwise). 4. The patch-stub code does not need to utilise any instruction stream synchronisation barrier as no >> patching/modifying of the instruction stream is done (including indirectly through a VM transition). > > Marked as reviewed by aph (Reviewer). Thanks for reviewing Erik and Andrew. Additional thanks to Erik for discussing the issue and the proposed solution. ------------- PR: https://git.openjdk.java.net/jdk/pull/344 From phedlin at openjdk.java.net Sat Sep 26 18:27:23 2020 From: phedlin at openjdk.java.net (Patric Hedlin) Date: Sat, 26 Sep 2020 18:27:23 GMT Subject: Integrated: 8247691: [aarch64] Incorrect handling of VM exceptions in C1 deopt stub/traps In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 19:14:54 GMT, Patric Hedlin wrote: > The immediate issue that causes the error symptom is due to the procedure link register (LR) not being preserved across > the actual call to the "patching" function (in code generated from '_generate_patching()_'), invoked as part of the C1 > deoptimization traps. However, this update addresses a larger issue with the current implementation. > > Since the Aarch64 implementation does not adopt patching but deoptimization to support load-mirror et.al., the > "patching" stub-code does not need to support the exception protocol otherwise necessary when a VM transition might be > needed in the actual patching function. The deoptimization is compulsory and the transition to the interpreter will > cater for proper interaction with the VM. The proposed solution is thus: 1. The version of '_patch_code()_' used > with **DEOPTIMIZE_WHEN_PATCHING** should not be modelled as a **JRT_ENTRY**. The "patching" functions will not transfer > control to VM (for up-call or otherwise). 2. The patch-stub code does not need to handle the VM exception protocol > (code can be removed). 3. The patch-stub code need only to support deoptimization and re-execute (it's a fatal error > otherwise). 4. The patch-stub code does not need to utilise any instruction stream synchronisation barrier as no > patching/modifying of the instruction stream is done (including indirectly through a VM transition). This pull request has now been integrated. Changeset: 7817963c Author: Patric Hedlin URL: https://git.openjdk.java.net/jdk/commit/7817963c Stats: 94 lines in 3 files changed: 15 ins; 60 del; 19 mod 8247691: [aarch64] Incorrect handling of VM exceptions in C1 deopt stub/traps Reviewed-by: eosterlund, aph ------------- PR: https://git.openjdk.java.net/jdk/pull/344 From thomas.stuefe at gmail.com Sat Sep 26 18:36:37 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 26 Sep 2020 20:36:37 +0200 Subject: =?UTF-8?Q?Re=3A_RFR=3A_8225329=3A_=2DXX=3A=2BPrintBiasedLockingStatistics_?= =?UTF-8?Q?causes_crash_during_initia=E2=80=A6?= In-Reply-To: References: Message-ID: On Sat, Sep 26, 2020, 18:42 Martin Doerr wrote: > On Sat, 26 Sep 2020 16:23:51 GMT, Thomas Stuefe > wrote: > > >> ?lization on Windows platforms > >> > >> This bug was fixed in 11.0.3-oracle, but also exists in 16: > >> https://bugs.openjdk.java.net/browse/JDK-8225329 > >> > >> VM crashes when built with VS2017, but passes with this trivial fix. > >> > >> jdk16\bin\java -XX:+UnlockDiagnosticVMOptions -XX:+UseBiasedLocking > -XX:+PrintBiasedLockingStatistics -version > >> OpenJDK 64-Bit Server VM warning: Temporarily processing option > UseBiasedLocking; support is scheduled for removal in > >> 16.0 > >> Seems like we won't need this fix for a long time, but fixes should be > done upstream for other backports. > > > > Hi Martin, > > > > looks reasonable. But I am curious what "fixed in Oracle11" means, > Oracle only fixed this in their 11 release? I cannot > > find a fix in 11u, nor an associated commit in the bug report, yet it is > marked as fixed. > > ..Thomas > > Hi Thomas, > it is only fixed in Oracle's closed source version of JDK11u. I want to > backport it to the open source version yet. > That's odd. But thanks for the clarification! ------------- > > PR: https://git.openjdk.java.net/jdk/pull/372 > From kbarrett at openjdk.java.net Sun Sep 27 11:17:28 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 27 Sep 2020 11:17:28 GMT Subject: RFR: 8253402: Convert vmSymbols::SID to enum class [v2] In-Reply-To: <2OwQBbIcnjHfvfRcyRo0evb8tFPgNSP_n91VPhJwASc=.84300d55-aa7b-4dec-acbb-94a828adce58@github.com> References: <2OwQBbIcnjHfvfRcyRo0evb8tFPgNSP_n91VPhJwASc=.84300d55-aa7b-4dec-acbb-94a828adce58@github.com> Message-ID: On Fri, 25 Sep 2020 22:23:34 GMT, Ioi Lam wrote: >> Convert `vmSymbols::SID` to an `enum class` to provide better type safety. >> >> - The original enum type `vmSymbols::SID` cannot be forward-declared. I moved it out of the `vmSymbols` class and >> renamed, so now it can be forward-declared as `enum class vmSymbolID : int;`, without including the large vmSymbols.hpp >> file. >> - This also breaks the mutual dependency between the `vmSymbols` and `vmIntrinsics` classes. Now the declaration of >> `vmIntrinsics` can be moved from vmSymbols.hpp to vmIntrinsics.hpp, where it naturally belongs. >> - Type-safe enumeration (contributed by Kim Barrett) >> for (vmSymbolID index : vmSymbolsIterator()) { >> vm_symbol_index[as_int(index)] = index; >> } >> - I moved `vmSymbols::_symbols[]` to `Symbol::_vm_symbols[]`, and made it accessible via `Symbol::vm_symbol_at()`. This >> way, header files (e.g. fieldInfo.hpp) that need to convert from `vmSymbolID` to `Symbol*` don't need to include the >> large vmSymbols.hpp file. >> - I changed the `VM_SYMBOL_ENUM_NAME` macro so that the users don't need to explicitly add the `vmSymbolID::` scope. >> - I removed many unnecessary casts between `int` and `vmSymbolID`. >> - The remaining casts are done via `vmSymbol::as_int()` and `vmSymbols::as_SID()` with range checks. >> >> ----- >> If this is successful, I will do the same for `vmIntrinsics::ID`. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes > the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last > revision: > - more vmEnums.hpp fixes; fixed minimal VM build > - Merge branch 'master' into 8253402-convert-vmsymbols-sid-to-enum-class > - Moved forward declaration of vmSymbolID to vmEnums.hpp > - clean up whitespaces and removed useless comment > - removed unnecessary include > - 8253402: Convert vmSymbols::SID to enum class Changes requested by kbarrett (Reviewer). src/hotspot/share/utilities/enumIterator.hpp line 1: > 1: /* I think there are problems with this EnumIterator class. It was based in part on a prototype of mine, which I've been revisiting and revising, because I think it has problems. That prototype, in turn, was based on the existing WeakProcessorPhases::Iterator, which I think has some of the same failings. And I think this version expands on some of those problems. I don't yet have a full review, but below are some observations and issues. I'm working on an alternative. A fundamental question is what style of "iterator" do we want. (1) One style is self-contained; you create a single iterator which knows both the current position and the iteration limit, and step until a predicate (is_end() in the current code) is true. (2) Another style is to have a pair of iterators, one designating the current position and the other designating the iteration limit. This is the style used by the C++ Standard Library. Both my earlier prototype and the EnumIterator in this PR are 1-style but attempt (not necessarily very well, in my opinion) to also provide 2-style behavior. The point of that currently seems to be to support the new "range-based for" feature. (Said feature is currently not in the permitted list according to the Style Guide. I intentionally left it out because I think its utility is pretty strongly dependent on adopting 2-style iterators, which is not very well motivated without using the Standard Library.) One requirement for an enum iterator (for me) is that it doesn't require a "fake" enumerator that designates the exclusive end of the range. The current proposal fails that test. A problem with all of the variants is that they are trying to be both 1-style (providing is_end) and 2-style (providing being/end), with the result that they do neither well. This is especially true for the variant in the PR. I think part of the problem is that the begin/end functions don't belong to the iterator class; they should be part of a separate range class. Aside: I think it is possible to provide iteration that doesn't assume sequential enumerators if one is willing to have some code duplication or has an enum that is x-macro based. While possibly an interesting exercise, I doubt that's worth pursuing. Just mentioning it in case anyone thinks this would actually useful. I'm not certain how to proceed. Maybe this should be moved elsewhere as not yet ready to be a widely used "utility"? Or maybe go ahead with it with the intention of improving it? ------------- PR: https://git.openjdk.java.net/jdk/pull/276 From clanger at openjdk.java.net Sun Sep 27 18:31:02 2020 From: clanger at openjdk.java.net (Christoph Langer) Date: Sun, 27 Sep 2020 18:31:02 GMT Subject: RFR: 8225329: -XX:+PrintBiasedLockingStatistics causes crash during =?UTF-8?B?aW5pdGlh4oCm?= In-Reply-To: References: Message-ID: On Sat, 26 Sep 2020 16:39:36 GMT, Martin Doerr wrote: >> Hi Martin, >> >> looks reasonable. But I am curious what "fixed in Oracle11" means, Oracle only fixed this in their 11 release? I cannot >> find a fix in 11u, nor an associated commit in the bug report, yet it is marked as fixed. >> ..Thomas > > Hi Thomas, > it is only fixed in Oracle's closed source version of JDK11u. I want to backport it to the open source version yet. Hi, really odd, yes. Just for the record: It was fixed in Oracle 11.0.9 ;-) Cheers Christoph ------------- PR: https://git.openjdk.java.net/jdk/pull/372 From github.com+471021+marschall at openjdk.java.net Sun Sep 27 19:03:44 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Sun, 27 Sep 2020 19:03:44 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v6] In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into JDK-8138732 - 8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate ------------- Changes: https://git.openjdk.java.net/jdk/pull/45/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=45&range=05 Stats: 749 lines in 65 files changed: 149 ins; 149 del; 451 mod Patch: https://git.openjdk.java.net/jdk/pull/45.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/45/head:pull/45 PR: https://git.openjdk.java.net/jdk/pull/45 From rehn at openjdk.java.net Sun Sep 27 19:11:42 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Sun, 27 Sep 2020 19:11:42 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v8] In-Reply-To: References: Message-ID: <_kbecDop0xzsAlIGGtV6ZihNQ3YgDDLrwOureP0A7Yw=.020d61a2-c24d-4d4c-be73-c675f70d44d9@github.com> > We simplify the vmThread by removing the queue and refactor the the main loop. > This solves the issues listed: > - It can create an extra safepoint directly after a safepoint. > - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. > - The exposure of the vm operation is dangerous if it's a handshake. > - The code is a hornets nest with the repetition of checks and branches > > Passes t1-8, and a benchmark run. > > If you want a smaller diff the commits contains the incremental progress and each commit passed t1. Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Removed unused declartion - Claes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/228/files - new: https://git.openjdk.java.net/jdk/pull/228/files/371ac282..d64f6482 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=228&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=228&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/228.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/228/head:pull/228 PR: https://git.openjdk.java.net/jdk/pull/228 From dholmes at openjdk.java.net Mon Sep 28 01:16:29 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 28 Sep 2020 01:16:29 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v8] In-Reply-To: <_kbecDop0xzsAlIGGtV6ZihNQ3YgDDLrwOureP0A7Yw=.020d61a2-c24d-4d4c-be73-c675f70d44d9@github.com> References: <_kbecDop0xzsAlIGGtV6ZihNQ3YgDDLrwOureP0A7Yw=.020d61a2-c24d-4d4c-be73-c675f70d44d9@github.com> Message-ID: On Sun, 27 Sep 2020 19:11:42 GMT, Robbin Ehn wrote: >> We simplify the vmThread by removing the queue and refactor the the main loop. >> This solves the issues listed: >> - It can create an extra safepoint directly after a safepoint. >> - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. >> - The exposure of the vm operation is dangerous if it's a handshake. >> - The code is a hornets nest with the repetition of checks and branches >> >> Passes t1-8, and a benchmark run. >> >> If you want a smaller diff the commits contains the incremental progress and each commit passed t1. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Removed unused declartion - Claes Still LGTM. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/228 From dholmes at openjdk.java.net Mon Sep 28 01:39:15 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 28 Sep 2020 01:39:15 GMT Subject: RFR: 8225329: -XX:+PrintBiasedLockingStatistics causes crash during =?UTF-8?B?aW5pdGlh4oCm?= In-Reply-To: References: Message-ID: On Sat, 26 Sep 2020 15:53:54 GMT, Martin Doerr wrote: > ?lization on Windows platforms > > This bug was fixed in 11.0.3-oracle, but also exists in 16: > https://bugs.openjdk.java.net/browse/JDK-8225329 > > VM crashes when built with VS2017, but passes with this trivial fix. > > jdk16\bin\java -XX:+UnlockDiagnosticVMOptions -XX:+UseBiasedLocking -XX:+PrintBiasedLockingStatistics -version > OpenJDK 64-Bit Server VM warning: Temporarily processing option UseBiasedLocking; support is scheduled for removal in > 16.0 > Seems like we won't need this fix for a long time, but fixes should be done upstream for other backports. I'm not clear now why this wasn't fixed in mainline originally. VS2017 is still an allowed compiler. Fix is good. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/372 From stefank at openjdk.java.net Mon Sep 28 06:32:57 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 28 Sep 2020 06:32:57 GMT Subject: RFR: 8253638: Cleanup os::reserve_memory and remove MAP_FIXED [v2] In-Reply-To: References: Message-ID: > There's a code path through os::reserve_memory that uses MAP_FIXED. This path is used if a requested address is given. > It's very dangerous to use MAP_FIXED, since it causes pre-existing mappings to be replaced. Alternative, move safe, > functions exists; named os_attempt_reserve_memory_at. It's not only dangerous to use that API, the Mac AARCH64 port > also can't use it in conjunction with its MAP_JIT. > I started to split os::reserve_memory into two functions; one that doesn't care about were the memory is mapped > (os::reserve_memory), and another that uses the dangerous MAP_FIXED flag (os::reserve_memory_at). However, I noticed > that it's only windows code that actually use os::reserve_memory with a requested address. All other usages have been > cleaned out and replaced with os::attempt_reserve_memory. And on windows os::attempt_reserve_memory uses > os::reserve_memory with comments that it's safe because it only "attempts" to place the mapping. So, this patch: 1) > Removes the forcefully reserving of memory and its MAP_FIXED usages! 2) Changes the windows code to call the > attempt_reserve_memory_at version, that it actually did anyway. 3) Flips the call order between pd_reserve_memory and > pd_attempt_reserve_memory_at, on windows. 4) There's also some unification and split done to handle MEMFLAGS and fds. > This part needs followup cleanups (IMHO). 5) The AIX implementation already refused to use MAP_FIXED, and now it > doesn't need special code to handle that. 6) Small cleanups around anon_mmap and anon_mmap_aligned Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Review 1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/357/files - new: https://git.openjdk.java.net/jdk/pull/357/files/fba49d17..0b0ba20a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=357&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=357&range=00-01 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/357.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/357/head:pull/357 PR: https://git.openjdk.java.net/jdk/pull/357 From stefank at openjdk.java.net Mon Sep 28 06:32:58 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 28 Sep 2020 06:32:58 GMT Subject: Integrated: 8253638: Cleanup os::reserve_memory and remove MAP_FIXED In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 11:24:17 GMT, Stefan Karlsson wrote: > There's a code path through os::reserve_memory that uses MAP_FIXED. This path is used if a requested address is given. > It's very dangerous to use MAP_FIXED, since it causes pre-existing mappings to be replaced. Alternative, move safe, > functions exists; named os_attempt_reserve_memory_at. It's not only dangerous to use that API, the Mac AARCH64 port > also can't use it in conjunction with its MAP_JIT. > I started to split os::reserve_memory into two functions; one that doesn't care about were the memory is mapped > (os::reserve_memory), and another that uses the dangerous MAP_FIXED flag (os::reserve_memory_at). However, I noticed > that it's only windows code that actually use os::reserve_memory with a requested address. All other usages have been > cleaned out and replaced with os::attempt_reserve_memory. And on windows os::attempt_reserve_memory uses > os::reserve_memory with comments that it's safe because it only "attempts" to place the mapping. So, this patch: 1) > Removes the forcefully reserving of memory and its MAP_FIXED usages! 2) Changes the windows code to call the > attempt_reserve_memory_at version, that it actually did anyway. 3) Flips the call order between pd_reserve_memory and > pd_attempt_reserve_memory_at, on windows. 4) There's also some unification and split done to handle MEMFLAGS and fds. > This part needs followup cleanups (IMHO). 5) The AIX implementation already refused to use MAP_FIXED, and now it > doesn't need special code to handle that. 6) Small cleanups around anon_mmap and anon_mmap_aligned This pull request has now been integrated. Changeset: 625a9352 Author: Stefan Karlsson URL: https://git.openjdk.java.net/jdk/commit/625a9352 Stats: 143 lines in 17 files changed: 29 ins; 57 del; 57 mod 8253638: Cleanup os::reserve_memory and remove MAP_FIXED Reviewed-by: stuefe, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/357 From dholmes at openjdk.java.net Mon Sep 28 06:32:48 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 28 Sep 2020 06:32:48 GMT Subject: RFR: 8238761: Asynchronous handshakes [v8] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 08:18:12 GMT, Robbin Ehn wrote: >> This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes >> are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) >> Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an >> arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a >> singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first >> pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first >> pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake >> operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything >> except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed >> filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake >> operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there >> is now only one method to call when handshaking one thread. Some comments about the changes: >> - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake >> all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much >> worse then this. >> >> - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that >> thread. >> >> - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a >> handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. >> >> - Added WB testing method. >> >> - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. >> >> - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. >> >> - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a >> safepoint and half of them after, in many handshake all operations. >> >> - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. >> >> - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the >> moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. >> >> - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. >> >> - Added filtered queue and gtest for it. >> >> Passes multiple t1-8 runs. >> Been through some pre-reviwing. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Add constructor and comment. Previous renames caused confusing, improved names once more and moved non-public to private Still some naming issues to resolve and an editing pass on various new comments. Thanks, David src/hotspot/share/runtime/handshake.cpp line 51: > 49: private: > 50: // Must use AsyncHandshakeOperation when using AsyncHandshakeClosure. > 51: HandshakeOperation(AsyncHandshakeClosure* cl, JavaThread* target, jlong start_ns) {}; I'm really not understanding the way you have implemented the guard I requested. How does declaring the private constructor prevent a call to HandShakeOperation(someAsync, target) ? src/hotspot/share/runtime/handshake.cpp line 202: > 200: } > 201: > 202: static void log_handshake_info(jlong start_time_ns, const char* name, int targets, int non_self_executed, const > char* extra = NULL) { The name "non_self_executed" is much clearer - thanks. But this now highlights that the log message itself doesn't make complete sense as it refers to "requesting thread" when it could be a range of possible threads not just a single requesting thread. src/hotspot/share/runtime/handshake.cpp line 239: > 237: // Keeps count on how many of own emitted handshakes > 238: // this thread execute. > 239: int emitted_handshakes_executed = 0; I suggest: // Keeps count of how many handshakes were actually executed // by this thread. int handshakes_executed = 0; src/hotspot/share/runtime/handshake.cpp line 326: > 324: // Keeps count on how many of own emitted handshakes > 325: // this thread execute. > 326: int emitted_handshakes_executed = 0; See previous comment. src/hotspot/share/runtime/handshake.hpp line 79: > 77: // Provides mutual exclusion to this state and queue. > 78: Mutex _lock; > 79: // Set to the thread executing the handshake operation during the execution. s/the execution/its execution/ Or just delete "during the execution" src/hotspot/share/runtime/handshake.hpp line 87: > 85: void process_self_inner(); > 86: > 87: bool have_non_self_executable_operation(); API naming consistency is still a problem here. We have: - pop_for_self() - pop() but - has_operation() // for use by self/handshakee - have_non_self_executable_operation() why not: - has_operation_for_self() - has_operation() ? src/hotspot/share/runtime/handshake.hpp line 100: > 98: } > 99: > 100: // Both _queue and _lock must be check. If a thread have seen this _handshakee s/check/checked/ s/have/has/ src/hotspot/share/runtime/handshake.hpp line 103: > 101: // as safe it will execute all possible handshake operations in a loop while > 102: // holding _lock. We use lock free addition to the queue, which means it is > 103: // possible to the queue to be seen as empty by _handshakee but as non-empty s/to/for/ src/hotspot/share/runtime/handshake.hpp line 105: > 103: // possible to the queue to be seen as empty by _handshakee but as non-empty > 104: // by the thread executing in the loop. To avoid the _handshakee eliding > 105: // stopping while handshake operations are being executed, the _handshakee s/eliding stopping/continuing/ ? src/hotspot/share/runtime/handshake.hpp line 106: > 104: // by the thread executing in the loop. To avoid the _handshakee eliding > 105: // stopping while handshake operations are being executed, the _handshakee > 106: // must take slow if _lock is held and make sure the queue is empty otherwise Unclear what "slow" refers to - "take the slow path"? But what path is that? src/hotspot/share/runtime/handshake.hpp line 107: > 105: // stopping while handshake operations are being executed, the _handshakee > 106: // must take slow if _lock is held and make sure the queue is empty otherwise > 107: // try process it. s/try/try to/ but I'm not sure how this follows the "otherwise" in this sentence. src/hotspot/share/utilities/filterQueue.hpp line 32: > 30: > 31: // The FilterQueue is FIFO with the ability to skip over queued items. > 32: // The skipping is controlled by using a filter when poping. s/poping/popping/ src/hotspot/share/utilities/filterQueue.hpp line 33: > 31: // The FilterQueue is FIFO with the ability to skip over queued items. > 32: // The skipping is controlled by using a filter when poping. > 33: // It also supports lock free pushes, while poping (including contain()) s/poping/popping/ s/contain()/contains()/ src/hotspot/share/utilities/filterQueue.hpp line 63: > 61: > 62: // Applies the match_func to the items in the queue until match_func returns > 63: // true and then return false, or there is no more items and then returns Surely "true and then returns true"? s/there is/there are/ src/hotspot/share/utilities/filterQueue.hpp line 64: > 62: // Applies the match_func to the items in the queue until match_func returns > 63: // true and then return false, or there is no more items and then returns > 64: // false. Any pushed item while executing may or may not have match_func s/pushed item/item pushed/ I know what you are trying to say about concurrent pushes but it sounds too non-deterministic - any concurrent push that happens before contains() reaches the end of the queue will have the match_func applied. So in that sense "while executing" only applies to pushes that will be seen; any push not seen had to have happened after execution was complete. src/hotspot/share/utilities/filterQueue.hpp line 66: > 64: // false. Any pushed item while executing may or may not have match_func > 65: // applied. The method is not re-entrant and must be executed mutually > 66: // exclusive other contains and pops calls. // exclusive to other contains() and pop() calls. src/hotspot/share/utilities/filterQueue.hpp line 77: > 75: > 76: // Applies the match_func to all items in the queue returns the item which > 77: // match_func return true for and was inserted first. Any pushed item while // Applies the match_func to each item in the queue, in order of insertion, and // returns the first item for which match_func returns true. Returns false if there are // no matches or the queue is empty. src/hotspot/share/utilities/filterQueue.hpp line 80: > 78: // executing may or may not have be popped, if popped it was the first > 79: // inserted match. The method is not re-entrant and must be executed mutual > 80: // exclusive with other contains and pops calls. See comments on contains() to ensure pop() and contains() use consistent terminology. Thanks. src/hotspot/share/runtime/handshake.cpp line 389: > 387: }; > 388: > 389: static bool non_self_queue_filter(HandshakeOperation* op) { The name "non_self_queue_filter" is really awkward - sorry. But I think we're going to have to revisit the way filtering is named and done once we try to generalise it anyway, so I'll let this pass. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/151 From stefank at openjdk.java.net Mon Sep 28 07:15:46 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 28 Sep 2020 07:15:46 GMT Subject: RFR: 8253639: Change os::attempt_reserve_memory_at parameter order [v2] In-Reply-To: <0MJI9DrcQ8bKFZfFGLPLecI-U3Fu5D7ttmy4WHTRLko=.809857c7-c445-4df6-ae33-ad84e6789627@github.com> References: <0MJI9DrcQ8bKFZfFGLPLecI-U3Fu5D7ttmy4WHTRLko=.809857c7-c445-4df6-ae33-ad84e6789627@github.com> Message-ID: > I propose that we change the parameter order from: > os::attempt_reserve_memory_at(size, addr, ) > > to: > os::attempt_reserve_memory_at(addr, size, ) > > This patch builds upon the changes in pull/357. There's currently no way to create an incremental review, but I want to > get this out for review now. So, unfortunately you have to ignore the first commit and look at the second commit. Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into 8253639_attempt_reserve_memory_param_order - 8253639: Change os::attempt_reserve_memory_at parameter order - 8253638: Cleanup os::reserve_memory and remove MAP_FIXED ------------- Changes: https://git.openjdk.java.net/jdk/pull/359/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=359&range=01 Stats: 27 lines in 10 files changed: 0 ins; 0 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/359.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/359/head:pull/359 PR: https://git.openjdk.java.net/jdk/pull/359 From stefank at openjdk.java.net Mon Sep 28 07:15:46 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 28 Sep 2020 07:15:46 GMT Subject: RFR: 8253639: Change os::attempt_reserve_memory_at parameter order [v2] In-Reply-To: References: <0MJI9DrcQ8bKFZfFGLPLecI-U3Fu5D7ttmy4WHTRLko=.809857c7-c445-4df6-ae33-ad84e6789627@github.com> <8dDr07kjE73JgwiOCvYPk2Cwocoi_Y0ea5HbB4qy5W4=.f2057e57-b02c-4385-9a88-1f74246fc1e0@github.com> Message-ID: <4eQqUFOhDvOiasg5Zv0IF6nWkqiwujyEdCdPpm-qia8=.6b3e9895-eadb-477c-af73-4396d7bcc9e4@github.com> On Fri, 25 Sep 2020 19:53:48 GMT, Stefan Karlsson wrote: >> Looks good to me. > > Thanks all for reviewing! Continuing this experiment to build a PR on top of another PR. I added a commit to parent PR pull/357, merged in master, and pushed pull/359's branch. "Files changed" now looks as expected, and only contains the changes relevant for this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/359 From stefank at openjdk.java.net Mon Sep 28 07:15:47 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 28 Sep 2020 07:15:47 GMT Subject: Integrated: 8253639: Change os::attempt_reserve_memory_at parameter order In-Reply-To: <0MJI9DrcQ8bKFZfFGLPLecI-U3Fu5D7ttmy4WHTRLko=.809857c7-c445-4df6-ae33-ad84e6789627@github.com> References: <0MJI9DrcQ8bKFZfFGLPLecI-U3Fu5D7ttmy4WHTRLko=.809857c7-c445-4df6-ae33-ad84e6789627@github.com> Message-ID: On Fri, 25 Sep 2020 13:26:30 GMT, Stefan Karlsson wrote: > I propose that we change the parameter order from: > os::attempt_reserve_memory_at(size, addr, ) > > to: > os::attempt_reserve_memory_at(addr, size, ) > > This patch builds upon the changes in pull/357. There's currently no way to create an incremental review, but I want to > get this out for review now. So, unfortunately you have to ignore the first commit and look at the second commit. This pull request has now been integrated. Changeset: ca1ed162 Author: Stefan Karlsson URL: https://git.openjdk.java.net/jdk/commit/ca1ed162 Stats: 27 lines in 10 files changed: 0 ins; 0 del; 27 mod 8253639: Change os::attempt_reserve_memory_at parameter order Reviewed-by: tschatzl, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/359 From akozlov at openjdk.java.net Mon Sep 28 07:53:01 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 28 Sep 2020 07:53:01 GMT Subject: RFR: 8253015: Aarch64: Move linux code out from generic CPU feature detection [v2] In-Reply-To: References: Message-ID: > Please review a change to remove Linux-specific code from hotspot/cpu/aarch64. > > The change is made to prepare for non-linux aarch64 platforms. > > vm_version no longer contains any "raw" values that were obtained directly from the platform registers. Some of them > may be unavailable on certain architectures, like `ctr_el0` is not available on windows [1]. > Few opportunities to improve linux code were taken: > 1. `HWCAP_` flags now explicitly mapped to `CPU_` > 2. `_dcpop` boolean was replaced with `CPU_DCPOP` > 3. Code generation to get the platform register values was replaced with inline assembly. There is no a code buffer > allocation anymore. > Graal-related changes: https://github.com/oracle/graal/pull/2861 > > Testing: > * local hotspot tier1 > * looking at detected features > * looking at debug output for `isDcZvaProhibited` and `zvaLength` values in Graal (not committed) -- have not changed > * looking at the results of `./graal-compiler-micro-benchmarks.jar -p > size=128,256,512,1024,2048,4096,8192,16384,32768,65536,131072 ArrayAllocationBenchmark.arrayAllocate` > (https://github.com/oracle/graal/commit/dcb4506e4da05db74e8b4007e2845458e8c555e2) -- the benchmark is noisy in my > environment, probably too many threads are used. Manually compared iterations, there is no regression spotted. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-September/009690.html Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Fix graal codestyle ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/154/files - new: https://git.openjdk.java.net/jdk/pull/154/files/20bd7ad5..b3737676 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=154&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=154&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/154.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/154/head:pull/154 PR: https://git.openjdk.java.net/jdk/pull/154 From rehn at openjdk.java.net Mon Sep 28 09:01:34 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 28 Sep 2020 09:01:34 GMT Subject: RFR: 8238761: Asynchronous handshakes [v8] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 08:18:12 GMT, Robbin Ehn wrote: >> This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes >> are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) >> Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an >> arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a >> singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first >> pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first >> pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake >> operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything >> except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed >> filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake >> operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there >> is now only one method to call when handshaking one thread. Some comments about the changes: >> - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake >> all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much >> worse then this. >> >> - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that >> thread. >> >> - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a >> handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. >> >> - Added WB testing method. >> >> - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. >> >> - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. >> >> - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a >> safepoint and half of them after, in many handshake all operations. >> >> - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. >> >> - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the >> moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. >> >> - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. >> >> - Added filtered queue and gtest for it. >> >> Passes multiple t1-8 runs. >> Been through some pre-reviwing. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Add constructor and comment. Previous renames caused confusing, improved names once more and moved non-public to private Thanks David. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Mon Sep 28 09:01:22 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 28 Sep 2020 09:01:22 GMT Subject: RFR: 8238761: Asynchronous handshakes [v9] In-Reply-To: References: Message-ID: > This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes > are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) > Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an > arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a > singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first > pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first > pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake > operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything > except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed > filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake > operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there > is now only one method to call when handshaking one thread. Some comments about the changes: > - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake > all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much > worse then this. > > - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that > thread. > > - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a > handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. > > - Added WB testing method. > > - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. > > - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. > > - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a > safepoint and half of them after, in many handshake all operations. > > - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. > > - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the > moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. > > - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. > > - Added filtered queue and gtest for it. > > Passes multiple t1-8 runs. > Been through some pre-reviwing. Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - More fixes from David - Merge branch 'master' into 8238761-asynchrounous-handshakes - Add constructor and comment. Previous renames caused confusing, improved names once more and moved non-public to private - Fixed trailing whitespace - Update after David - Update after Coleen - Update after Dan and David - Merge branch 'master' into 8238761-asynchrounous-handshakes - Removed double check, fix comment, removed not needed function, updated logs - Fixed double checks Added NSV ProcessResult to enum Fixed logging Moved _active_handshaker to private - ... and 1 more: https://git.openjdk.java.net/jdk/compare/14a37812...3a95750e ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/151/files - new: https://git.openjdk.java.net/jdk/pull/151/files/9125d6ad..3a95750e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=151&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=151&range=07-08 Stats: 29973 lines in 648 files changed: 4815 ins; 23495 del; 1663 mod Patch: https://git.openjdk.java.net/jdk/pull/151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/151/head:pull/151 PR: https://git.openjdk.java.net/jdk/pull/151 From rehn at openjdk.java.net Mon Sep 28 09:02:39 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 28 Sep 2020 09:02:39 GMT Subject: RFR: 8238761: Asynchronous handshakes [v8] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 05:28:43 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Add constructor and comment. Previous renames caused confusing, improved names once more and moved non-public to private > > src/hotspot/share/runtime/handshake.cpp line 51: > >> 49: private: >> 50: // Must use AsyncHandshakeOperation when using AsyncHandshakeClosure. >> 51: HandshakeOperation(AsyncHandshakeClosure* cl, JavaThread* target, jlong start_ns) {}; > > I'm really not understanding the way you have implemented the guard I requested. How does declaring the private > constructor prevent a call to HandShakeOperation(someAsync, target) ? Sorry my bad, fixed. > src/hotspot/share/runtime/handshake.cpp line 202: > >> 200: } >> 201: >> 202: static void log_handshake_info(jlong start_time_ns, const char* name, int targets, int non_self_executed, const >> char* extra = NULL) { > > The name "non_self_executed" is much clearer - thanks. But this now highlights that the log message itself doesn't make > complete sense as it refers to "requesting thread" when it could be a range of possible threads not just a single > requesting thread. This log line is done by the requesting thread of the specific "Handshake "%s". The log line only prints executed handshake operations emitted by the requesting thread. With changes on how logs from @pchilano and name changes this is getting confusing for me also. I renamed non_self_executed to emitted_handshakes_executed as the local variable passed into this function. To summarize the log line prints how many of the handshake operation emitted by 'this' handshake request was done by the requesting thread (or by VM Thread on behalf of the requesting thread when doing handshake all). This value can thus only be 0 or 1 if not executed by VM thread in a handshake all. Operations not done by requesting thread was either done cooperatively or by targets self. > src/hotspot/share/runtime/handshake.cpp line 239: > >> 237: // Keeps count on how many of own emitted handshakes >> 238: // this thread execute. >> 239: int emitted_handshakes_executed = 0; > > I suggest: > // Keeps count of how many handshakes were actually executed > // by this thread. > int handshakes_executed = 0; We only count those we emitted. I use to count all, but @pchilano thought it was confusing that we could log more executed than emitted. So now it only counts executed and emitted. > src/hotspot/share/runtime/handshake.cpp line 326: > >> 324: // Keeps count on how many of own emitted handshakes >> 325: // this thread execute. >> 326: int emitted_handshakes_executed = 0; > > See previous comment. Dito :) > src/hotspot/share/runtime/handshake.cpp line 389: > >> 387: }; >> 388: >> 389: static bool non_self_queue_filter(HandshakeOperation* op) { > > The name "non_self_queue_filter" is really awkward - sorry. But I think we're going to have to revisit the way > filtering is named and done once we try to generalise it anyway, so I'll let this pass. Sure > src/hotspot/share/runtime/handshake.hpp line 79: > >> 77: // Provides mutual exclusion to this state and queue. >> 78: Mutex _lock; >> 79: // Set to the thread executing the handshake operation during the execution. > > s/the execution/its execution/ > > Or just delete "during the execution" Fixed > src/hotspot/share/runtime/handshake.hpp line 87: > >> 85: void process_self_inner(); >> 86: >> 87: bool have_non_self_executable_operation(); > > API naming consistency is still a problem here. We have: > - pop_for_self() > - pop() > > but > - has_operation() // for use by self/handshakee > - have_non_self_executable_operation() > > why not: > - has_operation_for_self() > - has_operation() > > ? has_operation() is used by other threads than self, since has_operation() is lock free. Since 99% of the time the queue is empty, we get the correct answers without needing to lock the handshake state lock. This is signification for handshake all, since we keep revisiting threads even when they have completed their opretaion. It is thus very confusing having another thread calling has_operation_for_self(). > src/hotspot/share/runtime/handshake.hpp line 100: > >> 98: } >> 99: >> 100: // Both _queue and _lock must be check. If a thread have seen this _handshakee > > s/check/checked/ > s/have/has/ Fixed > src/hotspot/share/runtime/handshake.hpp line 103: > >> 101: // as safe it will execute all possible handshake operations in a loop while >> 102: // holding _lock. We use lock free addition to the queue, which means it is >> 103: // possible to the queue to be seen as empty by _handshakee but as non-empty > > s/to/for/ Fixed > src/hotspot/share/runtime/handshake.hpp line 105: > >> 103: // possible to the queue to be seen as empty by _handshakee but as non-empty >> 104: // by the thread executing in the loop. To avoid the _handshakee eliding >> 105: // stopping while handshake operations are being executed, the _handshakee > > s/eliding stopping/continuing/ ? Sure > src/hotspot/share/runtime/handshake.hpp line 106: > >> 104: // by the thread executing in the loop. To avoid the _handshakee eliding >> 105: // stopping while handshake operations are being executed, the _handshakee >> 106: // must take slow if _lock is held and make sure the queue is empty otherwise > > Unclear what "slow" refers to - "take the slow path"? But what path is that? Fixed > src/hotspot/share/runtime/handshake.hpp line 107: > >> 105: // stopping while handshake operations are being executed, the _handshakee >> 106: // must take slow if _lock is held and make sure the queue is empty otherwise >> 107: // try process it. > > s/try/try to/ > > but I'm not sure how this follows the "otherwise" in this sentence. Fixed/removed > src/hotspot/share/utilities/filterQueue.hpp line 32: > >> 30: >> 31: // The FilterQueue is FIFO with the ability to skip over queued items. >> 32: // The skipping is controlled by using a filter when poping. > > s/poping/popping/ Fixed > src/hotspot/share/utilities/filterQueue.hpp line 33: > >> 31: // The FilterQueue is FIFO with the ability to skip over queued items. >> 32: // The skipping is controlled by using a filter when poping. >> 33: // It also supports lock free pushes, while poping (including contain()) > > s/poping/popping/ > s/contain()/contains()/ Fixed > src/hotspot/share/utilities/filterQueue.hpp line 64: > >> 62: // Applies the match_func to the items in the queue until match_func returns >> 63: // true and then return false, or there is no more items and then returns >> 64: // false. Any pushed item while executing may or may not have match_func > > s/pushed item/item pushed/ > > I know what you are trying to say about concurrent pushes but it sounds too non-deterministic - any concurrent push > that happens before contains() reaches the end of the queue will have the match_func applied. So in that sense "while > executing" only applies to pushes that will be seen; any push not seen had to have happened after execution was > complete. We insert on first ptr and we also walk from first ptr. (This is tail of the queue) Since contains() never restart and we load first on directly on entry, no new pushes will be seen by contains(). pop() on the other hand may re-start due to failed CAS, thus all pushes up till this failed CAS will be seen. This happens if first ptr (tail) is the items selected for popping. A new push will change the first ptr (tail), the re-start to be able to unlinked the match. With a deterministic match_func this newly pushed item will never be pop, since we have an older matching item. (otherwise we would never tried to CAS) > src/hotspot/share/utilities/filterQueue.hpp line 63: > >> 61: >> 62: // Applies the match_func to the items in the queue until match_func returns >> 63: // true and then return false, or there is no more items and then returns > > Surely "true and then returns true"? > s/there is/there are/ Fixed > src/hotspot/share/utilities/filterQueue.hpp line 66: > >> 64: // false. Any pushed item while executing may or may not have match_func >> 65: // applied. The method is not re-entrant and must be executed mutually >> 66: // exclusive other contains and pops calls. > > // exclusive to other contains() and pop() calls. Fixed > src/hotspot/share/utilities/filterQueue.hpp line 77: > >> 75: >> 76: // Applies the match_func to all items in the queue returns the item which >> 77: // match_func return true for and was inserted first. Any pushed item while > > // Applies the match_func to each item in the queue, in order of insertion, and > // returns the first item for which match_func returns true. Returns false if there are > // no matches or the queue is empty. Some offline discussion, fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From stefank at openjdk.java.net Mon Sep 28 09:13:39 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 28 Sep 2020 09:13:39 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS In-Reply-To: References: Message-ID: <9A1_S9rJTFeQMGFbx748OrLxfkxQ6gpbX1fZNhNPFbM=.c4913344-b812-41f3-91b5-61c41c609fe0@github.com> On Thu, 24 Sep 2020 16:27:29 GMT, Stefan Karlsson wrote: >> Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html >> >> On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL, >> PROT_NONE), the function was made aware of exec permissions. >> For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference >> compared with old code. >> For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and >> immediately reflects this in diagnostic tools like ps. For executable regions it would require MAP_FIXED|MAP_JIT, so >> instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently >> this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not >> shrink (if I haven't missed anything, by the implementation and in principle). Tested: >> * local tier1 >> * jdk-submit >> * codesign[2] with hardened runtime and allow-jit but without >> allow-unsigned-executable-memory entitlements[3] produce a working bundle. >> >> (adding GC group as suggested by @dholmes-ora) >> >> >> [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227 >> [2] >> >> codesign \ >> --sign - \ >> --options runtime \ >> --entitlements ents.plist \ >> --timestamp \ >> $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib >> [3] >> >> >> >> >> com.apple.security.cs.allow-jit >> >> com.apple.security.cs.disable-library-validation >> >> com.apple.security.cs.allow-dyld-environment-variables >> >> >> > > I started to look at some of these changes and I have a hunch that we don't ever use MAP_FIXED when reserving memory. I > have a prototype that cleans that out, but I need more time to complete it and pull it through our testing. I've now pushed the change to get rid of MAP_FIXED from the reserve memory code: https://github.com/openjdk/jdk/commit/625a9352bfdc017f426c3bd2a5c24b0f7598ccce ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From mdoerr at openjdk.java.net Mon Sep 28 09:23:06 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 28 Sep 2020 09:23:06 GMT Subject: Integrated: 8225329: -XX:+PrintBiasedLockingStatistics causes crash during =?UTF-8?B?aW5pdGlh4oCm?= In-Reply-To: References: Message-ID: On Sat, 26 Sep 2020 15:53:54 GMT, Martin Doerr wrote: > ?lization on Windows platforms > > This bug was fixed in 11.0.3-oracle, but also exists in 16: > https://bugs.openjdk.java.net/browse/JDK-8225329 > > VM crashes when built with VS2017, but passes with this trivial fix. > > jdk16\bin\java -XX:+UnlockDiagnosticVMOptions -XX:+UseBiasedLocking -XX:+PrintBiasedLockingStatistics -version > OpenJDK 64-Bit Server VM warning: Temporarily processing option UseBiasedLocking; support is scheduled for removal in > 16.0 > Seems like we won't need this fix for a long time, but fixes should be done upstream for other backports. This pull request has now been integrated. Changeset: c2692f88 Author: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/c2692f88 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8225329: -XX:+PrintBiasedLockingStatistics causes crash during initia? Reviewed-by: stuefe, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/372 From mdoerr at openjdk.java.net Mon Sep 28 09:33:50 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 28 Sep 2020 09:33:50 GMT Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v3] In-Reply-To: References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> Message-ID: On Fri, 25 Sep 2020 22:15:10 GMT, Coleen Phillimore wrote: >> That the monitor has already been unlocked, or is a null stacklock monitor has been already checked in the caller, so >> the code that makes it a JRT_ENTRY_NO_ASYNC is unnecessary. >> Making it a JRT_LEAF like the compiled method entries makes it safer. We know it can never safepoint and >> unintentionally install a async exception. >> Tested with tier1-6. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > make calls through call_VM_leaf Thanks for taking care of all platforms. Looks good. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/320 From stuefe at openjdk.java.net Mon Sep 28 10:10:27 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 28 Sep 2020 10:10:27 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 07:08:35 GMT, Anton Kozlov wrote: > Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html > > On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL, > PROT_NONE), the function was made aware of exec permissions. > For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference > compared with old code. > For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and > immediately reflects this in diagnostic tools like ps. For executable regions it would require MAP_FIXED|MAP_JIT, so > instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently > this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not > shrink (if I haven't missed anything, by the implementation and in principle). Tested: > * local tier1 > * jdk-submit > * codesign[2] with hardened runtime and allow-jit but without > allow-unsigned-executable-memory entitlements[3] produce a working bundle. > > (adding GC group as suggested by @dholmes-ora) > > > [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227 > [2] > > codesign \ > --sign - \ > --options runtime \ > --entitlements ents.plist \ > --timestamp \ > $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib > [3] > > > > > com.apple.security.cs.allow-jit > > com.apple.security.cs.disable-library-validation > > com.apple.security.cs.allow-dyld-environment-variables > > > Hi Anton, I am sorry, but I dislike the API changes to os::xxx(). As it is now, this API is quite convoluted, undocumented and inconsistent. There are ongoing efforts to clean this up (see eg JDK-8253650, JDK-8253638 and JDK-8253683). This mess carries over into the upper layers too, e.g. ReservedSpace. About the API changes: - Why does os::uncommit_memory() now require "exec" as parameter? I know why you do it, but semantically it has no meaning. I should be able to uncommit memory without knowing the exact flags the mapping had been established with. So now the user has to carry this information and provide it back to the API when uncommitting? Right now probably all uncommits happen in areas where the exec information is implicit by its usage, but who says this is always the case? - We now have to specify "exec" as parameter to os::reverve_memory(). This is another new restriction - before, I could theoretically reserve one mapping and commit various parts of it with and without exec flag. With this change, the whole mapping has to be either exec or !exec. Can we on MacOS not use mmap at os::commit_memory, like we do on other platforms? In os::commit_memory, the exec parameter exists but on MacOS it is ignored. It would be more consistent with other platforms if the exec parameter were honored in commit, not requiring a new one at reserve. And I see mmap is used in uncommit, so changing mappings via overlapped mmap seems to work? Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From stefank at openjdk.java.net Mon Sep 28 11:20:21 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 28 Sep 2020 11:20:21 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS In-Reply-To: <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com> References: <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com> Message-ID: On Mon, 28 Sep 2020 11:16:46 GMT, Thomas Stuefe wrote: >> Hi Anton, >> >> I am sorry, but I dislike the API changes to os::xxx(). As it is now, this API is quite convoluted, undocumented and >> inconsistent. There are ongoing efforts to clean this up (see eg JDK-8253650, JDK-8253638 and JDK-8253683). This mess >> carries over into the upper layers too, e.g. ReservedSpace. About the API changes: >> >> - Why does os::uncommit_memory() now require "exec" as parameter? I know why you do it, but semantically it has no >> meaning. I should be able to uncommit memory without knowing the exact flags the mapping had been established with. So >> now the user has to carry this information and provide it back to the API when uncommitting? Right now probably all >> uncommits happen in areas where the exec information is implicit by its usage, but who says this is always the case? >> >> - We now have to specify "exec" as parameter to os::reverve_memory(). This is another new restriction - before, I could >> theoretically reserve one mapping and commit various parts of it with and without exec flag. With this change, the >> whole mapping has to be either exec or !exec. >> Can we on MacOS not use mmap at os::commit_memory, like we do on other platforms? In os::commit_memory, the exec >> parameter exists but on MacOS it is ignored. It would be more consistent with other platforms if the exec parameter >> were honored in commit, not requiring a new one at reserve. And I see mmap is used in uncommit, so changing mappings >> via overlapped mmap seems to work? Thanks, Thomas > >> I am sorry, but I dislike the API changes to os::xxx(). As it is now, this API is quite convoluted, undocumented and >> inconsistent. > > Just to clarify that I did not mean your change makes the API convoluted and inconsistent but that it has been that way > already, for a long time. It is a constant headache to get right, especially in ports whose memory management is a bit > non-standard, e.g. on AIX. @tstuefe My patch to remove MAP_FIXED from the memory reservation path should make it possible to revert all the os::reserve_memory changes in this patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From stuefe at openjdk.java.net Mon Sep 28 11:20:21 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 28 Sep 2020 11:20:21 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS In-Reply-To: References: Message-ID: <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com> On Mon, 28 Sep 2020 10:07:21 GMT, Thomas Stuefe wrote: > I am sorry, but I dislike the API changes to os::xxx(). As it is now, this API is quite convoluted, undocumented and > inconsistent. Just to clarify that I did not mean your change makes the API convoluted and inconsistent but that it has been that way already, for a long time. It is a constant headache to get right, especially in ports whose memory management is a bit non-standard, e.g. on AIX. ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From akozlov at azul.com Mon Sep 28 11:31:06 2020 From: akozlov at azul.com (Anton Kozlov) Date: Mon, 28 Sep 2020 14:31:06 +0300 Subject: RFR: 8253015: Aarch64: Move linux code out from generic CPU feature detection In-Reply-To: <6d7632bf-1662-c7c3-c549-c5e23cfa4c45@redhat.com> References: <6d7632bf-1662-c7c3-c549-c5e23cfa4c45@redhat.com> Message-ID: <24f818fc-f7dd-0746-ed60-5e4e9bb2d75a@azul.com> Hello Andrew, On 25.09.2020 15:45, Andrew Haley wrote: > On 24/09/2020 18:10, Ludovic Henry wrote: >> A quick follow-up on getting a review for this patch. We're starting to take dependency on this patch for the >> Windows-AArch64 and macOS-AArch64 >> (https://github.com/openjdk/jdk/pull/212/commits/7bf0aab32fb7ef1659efa09651d59aaed53c31d2). /cc @theRealAph > > It's a large and complex patch. > > It looks OK, so I have read through and reviewed it, but I haven't tested > it on Linux-AArch64. I assume you've done that. > Sorry, do you refer to JDK-8248238 (Implementation of JEP: Windows AArch64) or to JDK-8253015 (Aarch64: Move linux code out from generic CPU feature detection)? Because first one was reviewed, but the second one (that is included in the former) was not. The intention of this CPU feature detection patch is to do a preparation and make Windows/AArch64 patch more simple for review. Could you and community review this (cpu feature detection) patch as well? Thanks, Anton From eosterlund at openjdk.java.net Mon Sep 28 11:58:06 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 28 Sep 2020 11:58:06 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 21:20:19 GMT, Albert Mingkun Yang wrote: > Thank you for the comments and diagrams; they make the code much more digestible. From that diagram, I get the > impression that the watermark is associated with stack pointer, so it should be 1:1 relation, but `class Thread` > contains multiple watermarks, `StackWatermarks _stack_watermarks;`. I think some high level description on the relation > between the thread and a list of watermarks belong to that thread could be beneficial. I added some further comments explaining this. > > The first time it reaches past the last frame it will report true, and the second time it will report false. > > Why so? As I see it, once a stream becomes "done", it stays in that state forever. Am I missing sth? > > ``` > inline bool StackFrameStream::is_done() { > return (_is_done) ? true : (_is_done = _fr.is_first_frame(), false); > } > ``` When you step into the last frame of the iteration (first frame in the stack), the first time you ask is_done() it will report false, the next time it will report true, despite still being in the same frame. Therefore, the is_done() function is not idempotent, as I need it to be. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From akozlov at openjdk.java.net Mon Sep 28 11:58:13 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 28 Sep 2020 11:58:13 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS In-Reply-To: References: <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com> Message-ID: On Mon, 28 Sep 2020 11:17:49 GMT, Stefan Karlsson wrote: >>> I am sorry, but I dislike the API changes to os::xxx(). As it is now, this API is quite convoluted, undocumented and >>> inconsistent. >> >> Just to clarify that I did not mean your change makes the API convoluted and inconsistent but that it has been that way >> already, for a long time. It is a constant headache to get right, especially in ports whose memory management is a bit >> non-standard, e.g. on AIX. > > @tstuefe My patch to remove MAP_FIXED from the memory reservation path should make it possible to revert all the > os::reserve_memory changes in this patch. Interesting, thanks! I haven't evaluated the interface, just because it seemed to be out of scope for the task. I'll take a look and update the patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From coleenp at openjdk.java.net Mon Sep 28 12:14:26 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 28 Sep 2020 12:14:26 GMT Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v3] In-Reply-To: References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> Message-ID: On Mon, 28 Sep 2020 09:22:48 GMT, Martin Doerr wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> make calls through call_VM_leaf > > Thanks for taking care of all platforms. Looks good. Thanks @TheRealMDoerr! Were you able to check the other platforms? @dcubed-ojdk for the record. All of the tier1-6 tests passed. The tests were squeaky clean. ------------- PR: https://git.openjdk.java.net/jdk/pull/320 From ayang at openjdk.java.net Mon Sep 28 12:14:15 2020 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 28 Sep 2020 12:14:15 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 11:54:17 GMT, Erik ?sterlund wrote: >> Thank you for the comments and diagrams; they make the code much more digestible. From that diagram, I get the >> impression that the watermark is associated with stack pointer, so it should be 1:1 relation, but `class Thread` >> contains multiple watermarks, `StackWatermarks _stack_watermarks;`. I think some high level description on the relation >> between the thread and a list of watermarks belong to that thread could be beneficial. >>> The first time it reaches past the last frame it will report true, and the second time it will report false. >> >> Why so? As I see it, once a stream becomes "done", it stays in that state forever. Am I missing sth? >> inline bool StackFrameStream::is_done() { >> return (_is_done) ? true : (_is_done = _fr.is_first_frame(), false); >> } > >> Thank you for the comments and diagrams; they make the code much more digestible. From that diagram, I get the >> impression that the watermark is associated with stack pointer, so it should be 1:1 relation, but `class Thread` >> contains multiple watermarks, `StackWatermarks _stack_watermarks;`. I think some high level description on the relation >> between the thread and a list of watermarks belong to that thread could be beneficial. > > I added some further comments explaining this. > >> > The first time it reaches past the last frame it will report true, and the second time it will report false. >> >> Why so? As I see it, once a stream becomes "done", it stays in that state forever. Am I missing sth? >> >> ``` >> inline bool StackFrameStream::is_done() { >> return (_is_done) ? true : (_is_done = _fr.is_first_frame(), false); >> } >> ``` > > When you step into the last frame of the iteration (first frame in the stack), the first time you ask is_done() it will > report false, the next time it will report true, despite still being in the same frame. Therefore, the is_done() > function is not idempotent, as I need it to be. I see; thank you for the explanation. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From eosterlund at openjdk.java.net Mon Sep 28 12:14:11 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 28 Sep 2020 12:14:11 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v7] In-Reply-To: References: Message-ID: > This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. > https://openjdk.java.net/jeps/376). > Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, > and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into > more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to > expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in > the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized > automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization > processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is > actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception > handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC > threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming > of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the > watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll > word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it > brought (and is only possible on TSO machines). So left that one out. Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Review: Albert CR2 and defensive programming ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/296/files - new: https://git.openjdk.java.net/jdk/pull/296/files/078a207e..27ecb2eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=05-06 Stats: 15 lines in 5 files changed: 9 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/296.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/296/head:pull/296 PR: https://git.openjdk.java.net/jdk/pull/296 From jbhateja at openjdk.java.net Mon Sep 28 12:21:01 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 28 Sep 2020 12:21:01 GMT Subject: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions [v6] In-Reply-To: References: Message-ID: > Summary: > > 1) New AVX3 optimized stubs for both conjoint and disjoint arraycopy. > 2) Special instruction sequence blocks for copy sizes b/w 32-192 bytes. > 3) Block copy operation above 192 bytes is performed using destination address aligned PRE-MAIN-POST loop. Main loop > copies 192 byte in one iteration and tail part fall over special instruction sequence blocks. 4) Both small copy block > and aligned loop use 32 byte vector register to prevent and frequency penalty for copy sizes less than AVX3Threshold. > 5) For block size above AVX3Theshold both special blocks and loop operate using 64 byte register. 6) In case user > sets the maximum vector size to 32 bytes, forward copy (disjoint) operations are done using efficient REP MOVS for copy > sizes above 4096 bytes. JMH Results: > System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz > Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java > Baseline : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_Baseline.txt]() > WithOpt : [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_WithOpts.txt]() Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8252847 : Review comments resolution ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/61/files - new: https://git.openjdk.java.net/jdk/pull/61/files/78c4fe73..2a606276 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=61&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=61&range=04-05 Stats: 493 lines in 9 files changed: 264 ins; 200 del; 29 mod Patch: https://git.openjdk.java.net/jdk/pull/61.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/61/head:pull/61 PR: https://git.openjdk.java.net/jdk/pull/61 From stefank at openjdk.java.net Mon Sep 28 12:24:55 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 28 Sep 2020 12:24:55 GMT Subject: RFR: 8253640: Make MEMFLAGS an enum class Message-ID: I'd like to propose that we make MEMFLAGS an enum class, to prevent them from being implicitly converted to integers. I've been refactoring code that uses MEMFLAGS and have found that the functions often take integers and/or use default values. Because of this the compiler won't always tell you if you mess up the order. If we make the MEMFLAGS more type safe, the compiler will complain immediately if you send in the arguments in the wrong order. Changes in the patch: 1) G1 is the only code that uses MemoryType instead of the MEMFLAGS typedef. I changed those to make the code base uniform w.r.t. this. 2) Added some code generation so that we still can use mtGC, and don't have to write MEMFLAGS::mtGC. 3) Some stricter checks around the values stored in MEMFLAGS variables. There was a masking of 0xFF that I removed in favor of an assert. Need to run some more extensive testing see if there was a need for this masking. 4) Removed unused by_index Notes: 1) I didn't specify the underlying type of the enum, but it's clear for its usage that code will start to break if the value range is larger than 8 bits. Maybe something to clean up in a separate patch? 2) The code sometimes talks about "flags" and sometimes about "memory type", it's quite clear that the name changed, but the comments and names didn't get cleaned up accordingly. ------------- Commit messages: - 8253640: Make MEMFLAGS an enum class Changes: https://git.openjdk.java.net/jdk/pull/378/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=378&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253640 Stats: 51 lines in 8 files changed: 17 ins; 13 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/378.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/378/head:pull/378 PR: https://git.openjdk.java.net/jdk/pull/378 From stuefe at openjdk.java.net Mon Sep 28 12:52:30 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 28 Sep 2020 12:52:30 GMT Subject: RFR: 8253640: Make MEMFLAGS an enum class In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 11:49:37 GMT, Stefan Karlsson wrote: > I'd like to propose that we make MEMFLAGS an enum class, to prevent them from being implicitly converted to integers. > > I've been refactoring code that uses MEMFLAGS and have found that the functions often take integers and/or use default > values. Because of this the compiler won't always tell you if you mess up the order. If we make the MEMFLAGS more type > safe, the compiler will complain immediately if you send in the arguments in the wrong order. Changes in the patch: > > 1) G1 is the only code that uses MemoryType instead of the MEMFLAGS typedef. I changed those to make the code base > uniform w.r.t. this. 2) Added some code generation so that we still can use mtGC, and don't have to write > MEMFLAGS::mtGC. 3) Some stricter checks around the values stored in MEMFLAGS variables. There was a masking of 0xFF > that I removed in favor of an assert. Need to run some more extensive testing see if there was a need for this masking. > 4) Removed unused by_index > Notes: > 1) I didn't specify the underlying type of the enum, but it's clear for its usage that code will start to break if the > value range is larger than 8 bits. Maybe something to clean up in a separate patch? 2) The code sometimes talks about > "flags" and sometimes about "memory type", it's quite clear that the name changed, but the comments and names didn't > get cleaned up accordingly. Hi Stefan, I was just looking this morning at this enum and wished it were a class. This will make reworking the reservation APIs less error prone. Found some small nits, but leave it up to you if you change anything. (For some reason I always believed that using enum class would prevent us from using sentinel values but for the life of me I cannot remember why I thought this...) Thanks, Thomas src/hotspot/share/services/nmtCommon.hpp line 55: > 53: } > 54: > 55: // Check if flag value is a valid MEMFLAGS enum value Small nit, can you please clarify that this includes "mtNone"? src/hotspot/share/memory/allocation.hpp line 154: > 152: * Memory types > 153: */ > 154: enum class MEMFLAGS { Remark (possible for a later change): As you wrote, I think using uint8 would be okay and safer here. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/378 From mdoerr at openjdk.java.net Mon Sep 28 12:55:29 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 28 Sep 2020 12:55:29 GMT Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v3] In-Reply-To: References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> Message-ID: On Mon, 28 Sep 2020 11:54:48 GMT, Coleen Phillimore wrote: >> Thanks for taking care of all platforms. Looks good. > > Thanks @TheRealMDoerr! Were you able to check the other platforms? @dcubed-ojdk for the record. All of the tier1-6 > tests passed. The tests were squeaky clean. PPC64 and s390 tests have passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/320 From stefank at openjdk.java.net Mon Sep 28 13:00:10 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 28 Sep 2020 13:00:10 GMT Subject: RFR: 8253640: Make MEMFLAGS an enum class [v2] In-Reply-To: References: Message-ID: > I'd like to propose that we make MEMFLAGS an enum class, to prevent them from being implicitly converted to integers. > > I've been refactoring code that uses MEMFLAGS and have found that the functions often take integers and/or use default > values. Because of this the compiler won't always tell you if you mess up the order. If we make the MEMFLAGS more type > safe, the compiler will complain immediately if you send in the arguments in the wrong order. Changes in the patch: > > 1) G1 is the only code that uses MemoryType instead of the MEMFLAGS typedef. I changed those to make the code base > uniform w.r.t. this. 2) Added some code generation so that we still can use mtGC, and don't have to write > MEMFLAGS::mtGC. 3) Some stricter checks around the values stored in MEMFLAGS variables. There was a masking of 0xFF > that I removed in favor of an assert. Need to run some more extensive testing see if there was a need for this masking. > 4) Removed unused by_index > Notes: > 1) I didn't specify the underlying type of the enum, but it's clear for its usage that code will start to break if the > value range is larger than 8 bits. Maybe something to clean up in a separate patch? 2) The code sometimes talks about > "flags" and sometimes about "memory type", it's quite clear that the name changed, but the comments and names didn't > get cleaned up accordingly. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Review 1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/378/files - new: https://git.openjdk.java.net/jdk/pull/378/files/24cb2fb8..3f225acd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=378&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=378&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/378.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/378/head:pull/378 PR: https://git.openjdk.java.net/jdk/pull/378 From stefank at openjdk.java.net Mon Sep 28 13:00:11 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 28 Sep 2020 13:00:11 GMT Subject: RFR: 8253640: Make MEMFLAGS an enum class [v2] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 12:40:43 GMT, Thomas Stuefe wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Review 1 > > src/hotspot/share/services/nmtCommon.hpp line 55: > >> 53: } >> 54: >> 55: // Check if flag value is a valid MEMFLAGS enum value > > Small nit, can you please clarify that this includes "mtNone"? Good point! ------------- PR: https://git.openjdk.java.net/jdk/pull/378 From mbeckwit at openjdk.java.net Mon Sep 28 13:13:43 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Mon, 28 Sep 2020 13:13:43 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v8] In-Reply-To: References: Message-ID: > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: - Fix graal codestyle - Reduce includes - Merge remote-tracking branch 'upstream/master' into jdk-windows - os_windows: remove duplicated UMA handling - test_safefetch{32,N} works fine on win+aarch64 - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc - cleanup for 8253457: Remove unimplemented register stack functions - Merge remote-tracking branch 'upstream/master' into jdk-windows - Update orderAccess_windows_aarch64.hpp changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided - 8248787: G1: Workaround MSVC bug Reviewed-by: Contributed-by: mbeckwit, luhenry, burban - ... and 12 more: https://git.openjdk.java.net/jdk/compare/4dd32e55...275a0b7f ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/212/files - new: https://git.openjdk.java.net/jdk/pull/212/files/68f61d60..275a0b7f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=06-07 Stats: 25771 lines in 386 files changed: 3908 ins; 20954 del; 909 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From stuefe at openjdk.java.net Mon Sep 28 13:15:18 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 28 Sep 2020 13:15:18 GMT Subject: RFR: 8253640: Make MEMFLAGS an enum class [v2] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 13:00:10 GMT, Stefan Karlsson wrote: >> I'd like to propose that we make MEMFLAGS an enum class, to prevent them from being implicitly converted to integers. >> >> I've been refactoring code that uses MEMFLAGS and have found that the functions often take integers and/or use default >> values. Because of this the compiler won't always tell you if you mess up the order. If we make the MEMFLAGS more type >> safe, the compiler will complain immediately if you send in the arguments in the wrong order. Changes in the patch: >> >> 1) G1 is the only code that uses MemoryType instead of the MEMFLAGS typedef. I changed those to make the code base >> uniform w.r.t. this. 2) Added some code generation so that we still can use mtGC, and don't have to write >> MEMFLAGS::mtGC. 3) Some stricter checks around the values stored in MEMFLAGS variables. There was a masking of 0xFF >> that I removed in favor of an assert. Need to run some more extensive testing see if there was a need for this masking. >> 4) Removed unused by_index >> Notes: >> 1) I didn't specify the underlying type of the enum, but it's clear for its usage that code will start to break if the >> value range is larger than 8 bits. Maybe something to clean up in a separate patch? 2) The code sometimes talks about >> "flags" and sometimes about "memory type", it's quite clear that the name changed, but the comments and names didn't >> get cleaned up accordingly. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Review 1 lgtm ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/378 From stefank at openjdk.java.net Mon Sep 28 13:15:20 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 28 Sep 2020 13:15:20 GMT Subject: RFR: 8253640: Make MEMFLAGS an enum class [v2] In-Reply-To: References: Message-ID: <1B7JwI8pXFTKOQEmbsCX6EegljPRxSa998kPwD0VXMk=.c51a4871-e1a2-4dc6-9062-299f317d7dad@github.com> On Mon, 28 Sep 2020 13:10:08 GMT, Thomas Stuefe wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Review 1 > > lgtm Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/378 From aph at openjdk.java.net Mon Sep 28 13:20:49 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 28 Sep 2020 13:20:49 GMT Subject: RFR: 8253015: Aarch64: Move linux code out from generic CPU feature detection [v2] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 07:53:01 GMT, Anton Kozlov wrote: >> Please review a change to remove Linux-specific code from hotspot/cpu/aarch64. >> >> The change is made to prepare for non-linux aarch64 platforms. >> >> vm_version no longer contains any "raw" values that were obtained directly from the platform registers. Some of them >> may be unavailable on certain architectures, like `ctr_el0` is not available on windows [1]. >> Few opportunities to improve linux code were taken: >> 1. `HWCAP_` flags now explicitly mapped to `CPU_` >> 2. `_dcpop` boolean was replaced with `CPU_DCPOP` >> 3. Code generation to get the platform register values was replaced with inline assembly. There is no a code buffer >> allocation anymore. >> Graal-related changes: https://github.com/oracle/graal/pull/2861 >> >> Testing: >> * local hotspot tier1 >> * looking at detected features >> * looking at debug output for `isDcZvaProhibited` and `zvaLength` values in Graal (not committed) -- have not changed >> * looking at the results of `./graal-compiler-micro-benchmarks.jar -p >> size=128,256,512,1024,2048,4096,8192,16384,32768,65536,131072 ArrayAllocationBenchmark.arrayAllocate` >> (https://github.com/oracle/graal/commit/dcb4506e4da05db74e8b4007e2845458e8c555e2) -- the benchmark is noisy in my >> environment, probably too many threads are used. Manually compared iterations, there is no regression spotted. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-September/009690.html > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Fix graal codestyle Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/154 From aph at redhat.com Mon Sep 28 13:21:38 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 28 Sep 2020 14:21:38 +0100 Subject: RFR: 8253015: Aarch64: Move linux code out from generic CPU feature detection In-Reply-To: <24f818fc-f7dd-0746-ed60-5e4e9bb2d75a@azul.com> References: <6d7632bf-1662-c7c3-c549-c5e23cfa4c45@redhat.com> <24f818fc-f7dd-0746-ed60-5e4e9bb2d75a@azul.com> Message-ID: <4417de0c-9a89-d15f-490b-00433b37737b@redhat.com> On 28/09/2020 12:31, Anton Kozlov wrote: > Sorry, do you refer to JDK-8248238 (Implementation of JEP: Windows AArch64) or > to JDK-8253015 (Aarch64: Move linux code out from generic CPU feature > detection)? Because first one was reviewed, but the second one (that is > included in the former) was not. That's very weird. One of the nice things about the Github web interface is that when you review a change, the "Approve" button is right next to the changeset on the page. I'm pretty sure I remember approving it. > The intention of this CPU feature detection patch is to do a > preparation and make Windows/AArch64 patch more simple for review. > Could you and community review this (cpu feature detection) patch as > well? Sure, done. I hope it sticks this time. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From tschatzl at openjdk.java.net Mon Sep 28 13:48:33 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 28 Sep 2020 13:48:33 GMT Subject: RFR: 8253640: Make MEMFLAGS an enum class [v2] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 13:00:10 GMT, Stefan Karlsson wrote: >> I'd like to propose that we make MEMFLAGS an enum class, to prevent them from being implicitly converted to integers. >> >> I've been refactoring code that uses MEMFLAGS and have found that the functions often take integers and/or use default >> values. Because of this the compiler won't always tell you if you mess up the order. If we make the MEMFLAGS more type >> safe, the compiler will complain immediately if you send in the arguments in the wrong order. Changes in the patch: >> >> 1) G1 is the only code that uses MemoryType instead of the MEMFLAGS typedef. I changed those to make the code base >> uniform w.r.t. this. 2) Added some code generation so that we still can use mtGC, and don't have to write >> MEMFLAGS::mtGC. 3) Some stricter checks around the values stored in MEMFLAGS variables. There was a masking of 0xFF >> that I removed in favor of an assert. Need to run some more extensive testing see if there was a need for this masking. >> 4) Removed unused by_index >> Notes: >> 1) I didn't specify the underlying type of the enum, but it's clear for its usage that code will start to break if the >> value range is larger than 8 bits. Maybe something to clean up in a separate patch? 2) The code sometimes talks about >> "flags" and sometimes about "memory type", it's quite clear that the name changed, but the comments and names didn't >> get cleaned up accordingly. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Review 1 Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/378 From burban at openjdk.java.net Mon Sep 28 13:49:07 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Mon, 28 Sep 2020 13:49:07 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v6] In-Reply-To: <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com> References: <21bX6lTqVC7rs1Cor4HZwmD4cm3_V1rNzSX9shlp03Y=.5aeaaf6c-e42a-4a84-b3ab-b7e6e1c6c706@github.com> <-Q6elsa1i0UX1b8UVhLbOWJ0-cyYuH-mh0-YtfUqEik=.25a5c2b4-05a0-4c8f-a2aa-050a1ad8d7eb@github.com> Message-ID: On Thu, 24 Sep 2020 15:43:10 GMT, Chris Plummer wrote: >> Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev >> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since >> the last revision: >> - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc >> - cleanup for 8253457: Remove unimplemented register stack functions >> - Merge remote-tracking branch 'upstream/master' into jdk-windows >> - Update orderAccess_windows_aarch64.hpp >> >> changing from Acq-reL to Sequential Consistency to avoid compiler reordering when no ordering hints are provided >> - 8248787: G1: Workaround MSVC bug >> Reviewed-by: >> Contributed-by: mbeckwit, luhenry, burban >> - 8248670: Windows: Exception handling support on AArch64 >> Reviewed-by: >> Contributed-by: mbeckwit, luhenry, burban >> - 8248660: AArch64: Make _clear_cache and _nop portable >> Summary: __builtin___clear_cache, etc. >> Contributed-by: mbeckwit, luhenry, burban >> - 8248659: AArch64: Extend CPU Feature detection >> Reviewed-by: >> Contributed-by: mbeckwit, luhenry, burban >> - 8248656: Add Windows AArch64 platform support code >> Reviewed-by: >> Contributed-by: mbeckwit, luhenry, burban >> - 8248498: Add build system support for Windows AArch64 >> Reviewed-by: >> Contributed-by: mbeckwit, luhenry, burban >> - ... and 7 more: https://git.openjdk.java.net/jdk/compare/451890eb...2b662010 > > I looked at changes to existing SA files. These changes look fine. > > I did not look at the new aarch64 SA files other than the copyright section. I assume they are clones of the x64 > versions with some symbolic renaming. If there is any more than that and you'd like me to have a look, let me know. > As for the copyright in the new SA files, I believe it is incorrect and needs to include Oracle. There are a number of > other non-SA files that are new and also have the same copyright issue. > I also looked at src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java. It looks fine except it needs > a copyright date update. @plummercj thank you for your feedback. I've updated the copyright in mentioned files. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From mbeckwit at openjdk.java.net Mon Sep 28 13:48:59 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Mon, 28 Sep 2020 13:48:59 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v9] In-Reply-To: References: Message-ID: > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: SA: update copyright ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/212/files - new: https://git.openjdk.java.net/jdk/pull/212/files/275a0b7f..23b209db Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=07-08 Stats: 5 lines in 5 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From mbeckwit at openjdk.java.net Mon Sep 28 14:07:16 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Mon, 28 Sep 2020 14:07:16 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10] In-Reply-To: References: Message-ID: <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com> > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - Merge remote-tracking branch 'upstream/master' into jdk-windows - SA: update copyright - Fix graal codestyle - Reduce includes - Merge remote-tracking branch 'upstream/master' into jdk-windows - os_windows: remove duplicated UMA handling - test_safefetch{32,N} works fine on win+aarch64 - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc - cleanup for 8253457: Remove unimplemented register stack functions - Merge remote-tracking branch 'upstream/master' into jdk-windows - ... and 14 more: https://git.openjdk.java.net/jdk/compare/ec9bee68...a7cdaad6 ------------- Changes: https://git.openjdk.java.net/jdk/pull/212/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=09 Stats: 2566 lines in 62 files changed: 2208 ins; 126 del; 232 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From akozlov at openjdk.java.net Mon Sep 28 14:14:26 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 28 Sep 2020 14:14:26 GMT Subject: Integrated: 8253015: Aarch64: Move linux code out from generic CPU feature detection In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 19:42:21 GMT, Anton Kozlov wrote: > Please review a change to remove Linux-specific code from hotspot/cpu/aarch64. > > The change is made to prepare for non-linux aarch64 platforms. > > vm_version no longer contains any "raw" values that were obtained directly from the platform registers. Some of them > may be unavailable on certain architectures, like `ctr_el0` is not available on windows [1]. > Few opportunities to improve linux code were taken: > 1. `HWCAP_` flags now explicitly mapped to `CPU_` > 2. `_dcpop` boolean was replaced with `CPU_DCPOP` > 3. Code generation to get the platform register values was replaced with inline assembly. There is no a code buffer > allocation anymore. > Graal-related changes: https://github.com/oracle/graal/pull/2861 > > Testing: > * local hotspot tier1 > * looking at detected features > * looking at debug output for `isDcZvaProhibited` and `zvaLength` values in Graal (not committed) -- have not changed > * looking at the results of `./graal-compiler-micro-benchmarks.jar -p > size=128,256,512,1024,2048,4096,8192,16384,32768,65536,131072 ArrayAllocationBenchmark.arrayAllocate` > (https://github.com/oracle/graal/commit/dcb4506e4da05db74e8b4007e2845458e8c555e2) -- the benchmark is noisy in my > environment, probably too many threads are used. Manually compared iterations, there is no regression spotted. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-September/009690.html This pull request has now been integrated. Changeset: ec9bee68 Author: Anton Kozlov Committer: Andrew Haley URL: https://git.openjdk.java.net/jdk/commit/ec9bee68 Stats: 373 lines in 7 files changed: 164 ins; 153 del; 56 mod 8253015: Aarch64: Move linux code out from generic CPU feature detection Reviewed-by: aph ------------- PR: https://git.openjdk.java.net/jdk/pull/154 From pchilanomate at openjdk.java.net Mon Sep 28 15:00:23 2020 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 28 Sep 2020 15:00:23 GMT Subject: RFR: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function [v3] In-Reply-To: References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> Message-ID: On Fri, 25 Sep 2020 22:15:10 GMT, Coleen Phillimore wrote: >> That the monitor has already been unlocked, or is a null stacklock monitor has been already checked in the caller, so >> the code that makes it a JRT_ENTRY_NO_ASYNC is unnecessary. >> Making it a JRT_LEAF like the compiled method entries makes it safer. We know it can never safepoint and >> unintentionally install a async exception. >> Tested with tier1-6. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > make calls through call_VM_leaf Marked as reviewed by pchilanomate (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/320 From eric.c.liu at arm.com Mon Sep 28 15:13:58 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Mon, 28 Sep 2020 15:13:58 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com>, Message-ID: Hi, Thanks for looking at this. For gcc-10, it's hard to make 'strncpy' all right with asan enabled (approaches we talked previous don't work). I'm trying to find a better way to avoid using compile pragma. I suppose it would be better to use 'memcpy' to replace 'strncpy'. Thanks, Eric From rkennke at openjdk.java.net Mon Sep 28 15:25:23 2020 From: rkennke at openjdk.java.net (Roman Kennke) Date: Mon, 28 Sep 2020 15:25:23 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v7] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 12:14:11 GMT, Erik ?sterlund wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, >> and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into >> more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to >> expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in >> the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized >> automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization >> processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is >> actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception >> handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC >> threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming >> of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the >> watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll >> word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it >> brought (and is only possible on TSO machines). So left that one out. > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Review: Albert CR2 and defensive programming src/hotspot/share/compiler/oopMap.cpp line 319: > 317: #ifdef ASSERT > 318: if ((((uintptr_t)loc & (sizeof(oop)-1)) != 0) || > 319: !Universe::heap()->is_in_or_null((oop)NativeAccess::oop_load(&val))) { This NativeAccess call causes the troubles with Shenandoah GC. It triggers evacuation of the object referenced by the stack location during a safepoint, which we'd rather avoid. Why is it needed? ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From aph at redhat.com Mon Sep 28 15:42:16 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 28 Sep 2020 16:42:16 +0100 Subject: RFR: 8253611: AArch64: Concurrency problems in JavaFrameAnchor In-Reply-To: <23aab94d-d550-6660-8224-f997a2d26715@redhat.com> References: <85o8lu19pu.fsf@nicgas01-pc.shanghai.arm.com> <23aab94d-d550-6660-8224-f997a2d26715@redhat.com> Message-ID: On 25/09/2020 14:30, Andrew Haley wrote: > On 25/09/2020 10:34, Nick Gasson wrote: >> I see only the PPC port has an OrderAccess::release() here at the >> moment. If it matters for these two platforms then ARM32 and Zero also >> need the same fix? > > Sure, if it matters. I've looked through this and there are some comments about JFR. I understand that it might also be to do with JVMTI. I believe that the patch won't do any harm, so I'll approve it. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From coleenp at openjdk.java.net Mon Sep 28 15:51:44 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 28 Sep 2020 15:51:44 GMT Subject: Integrated: 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function In-Reply-To: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> References: <5nU1CYJdKOywpJVw3s_c5vTIOAm0ojFcUc_WxRbvFfM=.ddc234fd-01be-439b-a2dd-2cf33c4ec7e8@github.com> Message-ID: On Wed, 23 Sep 2020 14:32:21 GMT, Coleen Phillimore wrote: > That the monitor has already been unlocked, or is a null stacklock monitor has been already checked in the caller, so > the code that makes it a JRT_ENTRY_NO_ASYNC is unnecessary. > Making it a JRT_LEAF like the compiled method entries makes it safer. We know it can never safepoint and > unintentionally install a async exception. > Tested with tier1-6. This pull request has now been integrated. Changeset: 77a0f399 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/77a0f399 Stats: 73 lines in 10 files changed: 9 ins; 28 del; 36 mod 8253540: InterpreterRuntime::monitorexit should be a JRT_LEAF function Reviewed-by: rehn, mdoerr, dcubed, pchilanomate ------------- PR: https://git.openjdk.java.net/jdk/pull/320 From eosterlund at openjdk.java.net Mon Sep 28 16:44:16 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 28 Sep 2020 16:44:16 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v7] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 15:22:55 GMT, Roman Kennke wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Review: Albert CR2 and defensive programming > > src/hotspot/share/compiler/oopMap.cpp line 319: > >> 317: #ifdef ASSERT >> 318: if ((((uintptr_t)loc & (sizeof(oop)-1)) != 0) || >> 319: !Universe::heap()->is_in_or_null((oop)NativeAccess::oop_load(&val))) { > > This NativeAccess call causes the troubles with Shenandoah GC. It triggers evacuation of the object referenced by the > stack location during a safepoint, which we'd rather avoid. Why is it needed? We call frame::oops_do from the GC to make bad oops good. But the oops_do logic assers the oop is good *before* the closure is applied. Every time I do something, I run i to issues with this assert. It seems like an invalid assumption to me, that oops are meant to always be good, even before they are fixed. I vote for removing this assert. It has caused a lot of pain. Any takers? ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From github.com+51754783+CoreyAshford at openjdk.java.net Mon Sep 28 16:46:14 2020 From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford) Date: Mon, 28 Sep 2020 16:46:14 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: <_tvo1hj209XU5Y4JzhXfjSY2wh7-j1cahY7BskdaXNI=.c4acaa07-0a31-4460-b1d3-57a64fed1fdc@github.com> References: <_tvo1hj209XU5Y4JzhXfjSY2wh7-j1cahY7BskdaXNI=.c4acaa07-0a31-4460-b1d3-57a64fed1fdc@github.com> Message-ID: On Fri, 25 Sep 2020 13:45:15 GMT, Roger Riggs wrote: >> This patch set encompasses the following commits: >> >> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for >> the intrinsic. The API is similar to the existing encodeBlock intrinsic. >> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic >> implementation >> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic. >> - Adds a JMH microbenchmark for both Base64 encoding and encoding. >> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding. > > src/java.base/share/classes/java/util/Base64.java line 747: > >> 745: * Decodes base64 characters, and returns the number of data bytes >> 746: * produced by the base64 decode intrinsic. >> 747: * > > "intrinsic" can be omitted. Both the java and the intrinsic produce the same output. Good point. Will fix. > src/java.base/share/classes/java/util/Base64.java line 759: > >> 757: * src, it must process a multiple of four of them, making the >> 758: * returned destination length a multiple of three. >> 759: * > > If the dst array is too short does the intrinsic stop short or throw? > The java code would throw an ArrayIndexOutOfBoundsException. > It should not occur since the java code allocates the proper buffer but... > It might be worth mentioning. The intrinsic doesn't have enough information to know how long the dst buffer is. It only knows the starting address and the offset from that starting address; it has to trust the caller. encodeBlock() has the same limitation. I will add a comment to that effect. > src/java.base/share/classes/java/util/Base64.java line 820: > >> 818: dp += dl; >> 819: } >> 820: if (sp == sl) { > > I'd rather see (sp >= s1) instead of the equality, its would be consistent with the condition of the while loop. > (And is already lines 767-768). Agreed. Will change that comparison. > test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 260: > >> 258: } >> 259: >> 260: private static final byte[] nonBase64 = { > > Please add a comment describing this test data. > (It looks like it could be generated more compactly than an explicit array). > Ditto nonBase64URL below. Will do. > test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 240: > >> 238: } >> 239: >> 240: private static byte[] hexStringToByteArray(String s) { > > A method to convert a Hex String to a byte array already exists in test/lib/jdk/test/lib/Utils.java in toByteArray(s). > Add "jdk.test.lib.Utils" to the "@build" line at the top of the test. Cool! Thanks. I was unaware of that function. Will fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/293 From github.com+51754783+CoreyAshford at openjdk.java.net Mon Sep 28 16:46:12 2020 From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford) Date: Mon, 28 Sep 2020 16:46:12 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: References: Message-ID: On Sat, 26 Sep 2020 15:33:29 GMT, Martin Doerr wrote: > AOT support needs an update: > # Internal Error (jdk/src/hotspot/share/aot/aotCodeHeap.cpp:557), pid=345656, tid=364316 > # guarantee(adr != NULL) failed: AOT Symbol not found _aot_stub_routines_base64_decodeBlock > > V [jvm.dll+0x1dbc6e] AOTCodeHeap::link_stub_routines_symbols+0xf7e (aotcodeheap.cpp:557) > V [jvm.dll+0x1d95e8] AOTCodeHeap::link_global_lib_symbols+0x2f8 (aotcodeheap.cpp:603) > V [jvm.dll+0x1dc616] AOTCodeHeap::load_klass_data+0x476 (aotcodeheap.cpp:840) > V [jvm.dll+0x1e1021] AOTLoader::load_for_klass+0x161 (aotloader.cpp:55) > V [jvm.dll+0x5fec96] InstanceKlass::initialize_impl+0x4e6 (instanceklass.cpp:1159) > V [jvm.dll+0x5fead6] InstanceKlass::initialize_impl+0x326 (instanceklass.cpp:1133) > V [jvm.dll+0xc5a633] Threads::initialize_java_lang_classes+0x93 (thread.cpp:3766) > V [jvm.dll+0xc57c32] Threads::create_vm+0xa12 (thread.cpp:4037) > > Can be reproduced by running JTREG tests: > compiler/aot/calls/fromAot Thanks for catching that! Will fix on next round. ------------- PR: https://git.openjdk.java.net/jdk/pull/293 From github.com+51754783+CoreyAshford at openjdk.java.net Mon Sep 28 17:20:45 2020 From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford) Date: Mon, 28 Sep 2020 17:20:45 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: References: Message-ID: <8n1icvS8ly4JNxXsEJe6qT67B53OwHtMFZrc0XrhWzk=.4271b6c1-cf7e-43f9-af86-392f352a2e8c@github.com> On Mon, 28 Sep 2020 16:35:59 GMT, CoreyAshford wrote: >> AOT support needs an update: >> # Internal Error (jdk/src/hotspot/share/aot/aotCodeHeap.cpp:557), pid=345656, tid=364316 >> # guarantee(adr != NULL) failed: AOT Symbol not found _aot_stub_routines_base64_decodeBlock >> >> V [jvm.dll+0x1dbc6e] AOTCodeHeap::link_stub_routines_symbols+0xf7e (aotcodeheap.cpp:557) >> V [jvm.dll+0x1d95e8] AOTCodeHeap::link_global_lib_symbols+0x2f8 (aotcodeheap.cpp:603) >> V [jvm.dll+0x1dc616] AOTCodeHeap::load_klass_data+0x476 (aotcodeheap.cpp:840) >> V [jvm.dll+0x1e1021] AOTLoader::load_for_klass+0x161 (aotloader.cpp:55) >> V [jvm.dll+0x5fec96] InstanceKlass::initialize_impl+0x4e6 (instanceklass.cpp:1159) >> V [jvm.dll+0x5fead6] InstanceKlass::initialize_impl+0x326 (instanceklass.cpp:1133) >> V [jvm.dll+0xc5a633] Threads::initialize_java_lang_classes+0x93 (thread.cpp:3766) >> V [jvm.dll+0xc57c32] Threads::create_vm+0xa12 (thread.cpp:4037) >> >> Can be reproduced by running JTREG tests: >> compiler/aot/calls/fromAot > >> AOT support needs an update: >> # Internal Error (jdk/src/hotspot/share/aot/aotCodeHeap.cpp:557), pid=345656, tid=364316 >> # guarantee(adr != NULL) failed: AOT Symbol not found _aot_stub_routines_base64_decodeBlock >> >> V [jvm.dll+0x1dbc6e] AOTCodeHeap::link_stub_routines_symbols+0xf7e (aotcodeheap.cpp:557) >> V [jvm.dll+0x1d95e8] AOTCodeHeap::link_global_lib_symbols+0x2f8 (aotcodeheap.cpp:603) >> V [jvm.dll+0x1dc616] AOTCodeHeap::load_klass_data+0x476 (aotcodeheap.cpp:840) >> V [jvm.dll+0x1e1021] AOTLoader::load_for_klass+0x161 (aotloader.cpp:55) >> V [jvm.dll+0x5fec96] InstanceKlass::initialize_impl+0x4e6 (instanceklass.cpp:1159) >> V [jvm.dll+0x5fead6] InstanceKlass::initialize_impl+0x326 (instanceklass.cpp:1133) >> V [jvm.dll+0xc5a633] Threads::initialize_java_lang_classes+0x93 (thread.cpp:3766) >> V [jvm.dll+0xc57c32] Threads::create_vm+0xa12 (thread.cpp:4037) >> >> Can be reproduced by running JTREG tests: >> compiler/aot/calls/fromAot > > Thanks for catching that! Will fix on next round. Martin Doerr wrote: ... > I can see you're using clrldi to clear the upper bits of the parameters. But seems like it clears one bit too few. You're right. I misread the instruction as clear from bit 0 to bit N, but it's actually create a mask with bits N to 63 with one's, zeroes elsewhere, then AND it with the src register. Will fix. > You can also use cmpwi for the boolean one. Ah, good! Thanks. Will change. > > I wonder about the loop unrolling. It doesn't look beneficial because the loop body is large. > Did you measure performance gain by this unrolling? > I think for agressive tuning we'd have to apply techniques like modulo scheduling, but that's much more work. > So please only use unrolling as far as a benefit is measurable. I did test on a prototype written in C using vector intrinsics, and 8 was the sweet spot, however the structure of that code was a bit different and I should have verified that the same amount of loop unrolling makes sense for the Java intrinsic. I will perform those experiments. > > But you may want to align the loop start to help instruction fetch. Interesting. I did add an align, but in my patch clean up I must have lost it again somehow. I will add it back again. Sorry for that mistake. > We'll test it, but we don't have Power 10. You guys need to cover that. I did test on Power10, but I wasn't able to do performance testing because I ran on an instruction-level simulator. Real hardware will be available in the coming months. Thanks for your careful look at the code, and the regression testing you've done. ------------- PR: https://git.openjdk.java.net/jdk/pull/293 From shade at openjdk.java.net Mon Sep 28 17:23:44 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 28 Sep 2020 17:23:44 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v7] In-Reply-To: References: Message-ID: <0YZltgQGjDI8GW69qzCH_Kg3twWzN6dOyO5yBJ7B784=.b9fd2418-4218-4ff3-ba56-17e0a453796b@github.com> On Mon, 28 Sep 2020 16:41:28 GMT, Erik ?sterlund wrote: >> src/hotspot/share/compiler/oopMap.cpp line 319: >> >>> 317: #ifdef ASSERT >>> 318: if ((((uintptr_t)loc & (sizeof(oop)-1)) != 0) || >>> 319: !Universe::heap()->is_in_or_null((oop)NativeAccess::oop_load(&val))) { >> >> This NativeAccess call causes the troubles with Shenandoah GC. It triggers evacuation of the object referenced by the >> stack location during a safepoint, which we'd rather avoid. Why is it needed? > > We call frame::oops_do from the GC to make bad oops good. But the oops_do logic assers the oop is good *before* the > closure is applied. Every time I do something, I run i to issues with this assert. It seems like an invalid assumption > to me, that oops are meant to always be good, even before they are fixed. I vote for removing this assert. It has > caused a lot of pain. Any takers? I think the previous assert was intentionally weaker: `is_in` checks that argument points to a committed area in the heap, which can include the oops not yet fixed. It does not check if oop is valid as far as GC is concerned. So maybe reverting `NativeAccess::oop_load` is enough? ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From minqi at openjdk.java.net Mon Sep 28 17:36:52 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 28 Sep 2020 17:36:52 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v6] In-Reply-To: References: Message-ID: <-yguNGytFoC5nivpKCYn3IKzCPlRSb-vRyw12Rn0r5c=.29825818-7b48-4eff-9cfb-2bea3abe8f16@github.com> > This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous > webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the > regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. Tests: tier1-4 Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - In case of exception happens during reloading class, CHECK will return without free the allocated buffer for class bytes so moved the buffer allocation and freeing to caller. Also removed test 6 since there is not guarantee that we can give a signature which will always fail. Additional changes to GenerateJLIClassesHelper according to review suggestion. - Merge branch 'master' of https://github.com/openjdk/jdk into jdk-8247536 - Merge branch 'master' of https://git.openjdk.java.net/jdk into jdk-8247536 - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - Merge branch 'master' into jdk-8247536 - Merge branch 'master' of https://github.com/openjdk/jdk - Merge branch 'master' of https://github.com/openjdk/jdk - 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive - ... and 6 more: https://git.openjdk.java.net/jdk/compare/1ae6b533...9ab52116 ------------- Changes: https://git.openjdk.java.net/jdk/pull/193/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=05 Stats: 457 lines in 21 files changed: 433 ins; 13 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/193.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193 PR: https://git.openjdk.java.net/jdk/pull/193 From vkempik at openjdk.java.net Mon Sep 28 17:41:43 2020 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 28 Sep 2020 17:41:43 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10] In-Reply-To: <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com> References: <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com> Message-ID: On Mon, 28 Sep 2020 14:07:16 GMT, Monica Beckwith wrote: >> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains 24 commits: > - Merge remote-tracking branch 'upstream/master' into jdk-windows > - SA: update copyright > - Fix graal codestyle > - Reduce includes > - Merge remote-tracking branch 'upstream/master' into jdk-windows > - os_windows: remove duplicated UMA handling > - test_safefetch{32,N} works fine on win+aarch64 > - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc > - cleanup for 8253457: Remove unimplemented register stack functions > - Merge remote-tracking branch 'upstream/master' into jdk-windows > - ... and 14 more: https://git.openjdk.java.net/jdk/compare/ec9bee68...a7cdaad6 src/hotspot/cpu/aarch64/register_aarch64.cpp line 44: > 42: "rscratch1", "rscratch2", > 43: "r10", "r11", "r12", "r13", "r14", "r15", "r16", > 44: "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls"), "r19", For me this line doesn't look good in case of expanding this functionality to macos-aarch64 as it's just the name of register and it's r18 on every platform except WIN64 and has nothing to do with reserving r18. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From minqi at openjdk.java.net Mon Sep 28 17:42:42 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 28 Sep 2020 17:42:42 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v3] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 21:45:13 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive > > test/hotspot/jtreg/runtime/cds/appcds/DumpClassListWithLF.java line 32: > >> 30: * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds >> 31: * @compile ClassListFormatBase.java test-classes/Hello.java >> 32: * @run driver DumpClassListWithLF > > The `@compile` line can be removed to speed up the test execution. You can add this: > > @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds/test-classes > > and also change the code below > > appJar, classlist( > - "Hello", > + Hello.class.getName(), > > (There's no need for `/test/hotspot/jtreg/runtime/cds/appcds` in `@library` because that's the current directory of > this test). I tried using @library and passed local tests, but it failed mach5 for complaining no file Hello.class found from path. ------------- PR: https://git.openjdk.java.net/jdk/pull/193 From sspitsyn at openjdk.java.net Mon Sep 28 18:23:20 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Mon, 28 Sep 2020 18:23:20 GMT Subject: RFR: 8238761: Asynchronous handshakes [v8] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 08:40:15 GMT, Robbin Ehn wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Add constructor and comment. Previous renames caused confusing, improved names once more and moved non-public to private > > Thanks David. Robbin, thank you for your answers! There are JVMTI functions that are specified to return error code JVMTI_ERROR_THREAD_NOT_ALIVE. As an example, see: https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#GetStackTrace The following functions are impacted by your fix: GetOwnedMonitorInfo, GetOwnedMonitorStackDepthInfo, GetCurrentContendedMonitor, GetStackTrace, GetFrameCount, GetFrameLocation, PopFrame I wonder, how this error code can be ever returned for these functions now. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From dcubed at openjdk.java.net Mon Sep 28 18:36:02 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 28 Sep 2020 18:36:02 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v6] In-Reply-To: References: Message-ID: <1DbVvan-K6HarNVZcdNHC_8l9AmiVq8moglmKtSie6U=.61c90e70-a45c-4e00-9dc2-4b5dc29111e5@github.com> On Fri, 25 Sep 2020 18:27:57 GMT, Robbin Ehn wrote: >> Hmmm.... The old SafepointALot was intended to safepoint as frequently >> as possible to stress the system. Now we do very little at safepoints so >> maybe it is time for SafepointALot to evolve. Can you make it so that a >> SafepointALot happens some fraction of GuaranteedSafepointInterval, e.g., >> (GuaranteedSafepointInterval / 4) so four times as often? > > All test using SafepointALot the already set the GuaranteedSafepointInterval to a low value in range of ~1-300ms. > (except for vm boolean flag test which uses SafepointALot to test a boolean flag) > For example jni/FastGetField sets GuaranteedSafepointInterval to 1. > > The only case it would really differ is when adhoc adding SafepointALot without GuaranteedSafepointInterval. If GuaranteedSafepointInterval is set to a lower value than the default on the command line, then I'm okay if SafepointALot does not do anything extra. However, if GuaranteedSafepointInterval is either the default value or is set to a higher value, then I would like SafepointALot to cause a safepoint more frequently than the GuaranteedSafepointInterval. Every GuaranteedSafepointInterval/4 would be a fine definition of "a lot". ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From dcubed at openjdk.java.net Mon Sep 28 18:36:02 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 28 Sep 2020 18:36:02 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v6] In-Reply-To: <1DbVvan-K6HarNVZcdNHC_8l9AmiVq8moglmKtSie6U=.61c90e70-a45c-4e00-9dc2-4b5dc29111e5@github.com> References: <1DbVvan-K6HarNVZcdNHC_8l9AmiVq8moglmKtSie6U=.61c90e70-a45c-4e00-9dc2-4b5dc29111e5@github.com> Message-ID: <6N9BJAvEjjipB90BTLeVUYFc2iCShOFCsfpuPk5r17k=.5cbf7ae0-c132-475e-8272-d719de7c0617@github.com> On Mon, 28 Sep 2020 18:30:01 GMT, Daniel D. Daugherty wrote: >> All test using SafepointALot the already set the GuaranteedSafepointInterval to a low value in range of ~1-300ms. >> (except for vm boolean flag test which uses SafepointALot to test a boolean flag) >> For example jni/FastGetField sets GuaranteedSafepointInterval to 1. >> >> The only case it would really differ is when adhoc adding SafepointALot without GuaranteedSafepointInterval. > > If GuaranteedSafepointInterval is set to a lower value than the default on the command line, then I'm okay if > SafepointALot does not do anything extra. However, if GuaranteedSafepointInterval is either the default value or is set > to a higher value, then I would like SafepointALot to cause a safepoint more frequently than the > GuaranteedSafepointInterval. Every GuaranteedSafepointInterval/4 would be a fine definition of "a lot". Mulling on this more... is it too radical to consider that we no longer need SafepointALot? ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From github.com+471021+marschall at openjdk.java.net Mon Sep 28 19:10:41 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Mon, 28 Sep 2020 19:10:41 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Wed, 23 Sep 2020 22:47:47 GMT, Vladimir Kozlov wrote: >> Marked as reviewed by egahlin (Reviewer). > > @marschall I will sponsor it after you integrate the latest update. @vnkozlov done, I hope I now made it correctly with a merge commit for the latest merge conflict ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From burban at openjdk.java.net Mon Sep 28 19:12:24 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Mon, 28 Sep 2020 19:12:24 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10] In-Reply-To: References: <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com> Message-ID: On Mon, 28 Sep 2020 17:37:32 GMT, Vladimir Kempik wrote: >> Monica Beckwith has updated the pull request with a new target base due to a merge or a rebase. The pull request now >> contains 24 commits: >> - Merge remote-tracking branch 'upstream/master' into jdk-windows >> - SA: update copyright >> - Fix graal codestyle >> - Reduce includes >> - Merge remote-tracking branch 'upstream/master' into jdk-windows >> - os_windows: remove duplicated UMA handling >> - test_safefetch{32,N} works fine on win+aarch64 >> - cleanup for 8253539: Remove unused JavaThread functions for set_last_Java_fp/pc >> - cleanup for 8253457: Remove unimplemented register stack functions >> - Merge remote-tracking branch 'upstream/master' into jdk-windows >> - ... and 14 more: https://git.openjdk.java.net/jdk/compare/ec9bee68...a7cdaad6 > > src/hotspot/cpu/aarch64/register_aarch64.cpp line 44: > >> 42: "rscratch1", "rscratch2", >> 43: "r10", "r11", "r12", "r13", "r14", "r15", "r16", >> 44: "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls"), "r19", > > For me this line doesn't look good in case of expanding this functionality to macos-aarch64 > as it's just the name of register and it's r18 on every platform except WIN64 and has nothing to do with reserving r18. The idea is that the naming should suggest that `r18` shouldn't be used on that particular platform. Same is true for macOS, but the ABI docs suggest a different usage, hence we have something like that in our internal branch for macOS: Suggestion: "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19", Are you suggesting it should rather be something like this eventually? Suggestion: "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19", ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From rehn at openjdk.java.net Mon Sep 28 19:18:12 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 28 Sep 2020 19:18:12 GMT Subject: RFR: 8238761: Asynchronous handshakes [v8] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 18:20:58 GMT, Serguei Spitsyn wrote: > Robbin, thank you for your answers! > There are JVMTI functions that are specified to return error code JVMTI_ERROR_THREAD_NOT_ALIVE. > As an example, see: > https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#GetStackTrace > The following functions are impacted by your fix: > GetOwnedMonitorInfo, GetOwnedMonitorStackDepthInfo, GetCurrentContendedMonitor, GetStackTrace, GetFrameCount, > GetFrameLocation, PopFrame > I wonder, how this error code can be ever returned for these functions now. They should have exactly the same behavior as previously. All I did was set JVMTI_ERROR_THREAD_NOT_ALIVE as the default value for those handshakes: https://github.com/openjdk/jdk/blob/3a95750e6474214c62b04fccbfe172d077d3915f/src/hotspot/share/prims/jvmtiEnvBase.hpp#L345 Which simplifies the code. So only in the two cases where the guarantee's are we can never return that (reset_current_location/enter_interp_only_mode) If the guarantee's are wrong, the current code have that bug already, so I'm not adding or fixing that. It should be exactly the same and we have test for at least some of the operations which verifies that the agent gets: JVMTI_ERROR_THREAD_NOT_ALIVE And this passes t1-8 multiple times, so I'm pretty confident that this does not change any return value. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From vkempik at openjdk.java.net Mon Sep 28 19:33:11 2020 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 28 Sep 2020 19:33:11 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10] In-Reply-To: References: <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com> Message-ID: On Mon, 28 Sep 2020 19:09:17 GMT, Bernhard Urban-Forster wrote: >> src/hotspot/cpu/aarch64/register_aarch64.cpp line 44: >> >>> 42: "rscratch1", "rscratch2", >>> 43: "r10", "r11", "r12", "r13", "r14", "r15", "r16", >>> 44: "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls"), "r19", >> >> For me this line doesn't look good in case of expanding this functionality to macos-aarch64 >> as it's just the name of register and it's r18 on every platform except WIN64 and has nothing to do with reserving r18. > > The idea is that the naming should suggest that `r18` shouldn't be used on that particular platform. Same is true for > macOS, but the ABI docs suggest a different usage, hence we have something like that in our internal branch for macOS: > Suggestion: > "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19", > Are you suggesting it should rather be something like this eventually? > Suggestion: > > "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19", this looks better I think, if it's done right from beginning, we won't have to modify it later. The Question is, can we do it ahead of JEP-391 ? If we can't then maybe better to leave it this way for now: WIN64_ONLY("rtls") NOT_WIN64("r18") as r18 is supposed to be reserved register on aarch64, linux is just an exception where it's allowed. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From burban at openjdk.java.net Mon Sep 28 19:40:49 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Mon, 28 Sep 2020 19:40:49 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10] In-Reply-To: References: <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com> Message-ID: <9cbO1bZWUEMui6WWZKjYKrvGhvNXgCLdm3C3NInY07k=.5a5ff95b-5c3b-467e-b2d4-04ef075f3f58@github.com> On Mon, 28 Sep 2020 19:28:10 GMT, Vladimir Kempik wrote: >> The idea is that the naming should suggest that `r18` shouldn't be used on that particular platform. Same is true for >> macOS, but the ABI docs suggest a different usage, hence we have something like that in our internal branch for macOS: >> Suggestion: >> "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19", >> Are you suggesting it should rather be something like this eventually? >> Suggestion: >> >> "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19", > > this looks better I think, if it's done right from beginning, we won't have to modify it later. > The Question is, can we do it ahead of JEP-391 ? > If we can't then maybe better to leave it this way for now: > WIN64_ONLY("rtls") NOT_WIN64("r18") > > as r18 is supposed to be reserved register on aarch64, linux is just an exception where it's allowed. Let us go with the following in this PR as that's the extend of this PR: Suggestion: "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls"), "r19", We can update it accordingly in a PR for JEP-391. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From vkempik at openjdk.java.net Mon Sep 28 19:44:33 2020 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Mon, 28 Sep 2020 19:44:33 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10] In-Reply-To: <9cbO1bZWUEMui6WWZKjYKrvGhvNXgCLdm3C3NInY07k=.5a5ff95b-5c3b-467e-b2d4-04ef075f3f58@github.com> References: <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com> <9cbO1bZWUEMui6WWZKjYKrvGhvNXgCLdm3C3NInY07k=.5a5ff95b-5c3b-467e-b2d4-04ef075f3f58@github.com> Message-ID: On Mon, 28 Sep 2020 19:38:15 GMT, Bernhard Urban-Forster wrote: >> this looks better I think, if it's done right from beginning, we won't have to modify it later. >> The Question is, can we do it ahead of JEP-391 ? >> If we can't then maybe better to leave it this way for now: >> WIN64_ONLY("rtls") NOT_WIN64("r18") >> >> as r18 is supposed to be reserved register on aarch64, linux is just an exception where it's allowed. > > Let us go with the following in this PR as that's the extend of this PR: > Suggestion: > > "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls"), "r19", > We can update it accordingly in a PR for JEP-391. Ok, Great. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From mbeckwit at openjdk.java.net Mon Sep 28 19:53:37 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Mon, 28 Sep 2020 19:53:37 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v11] In-Reply-To: References: Message-ID: > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: r18 only on Linux ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/212/files - new: https://git.openjdk.java.net/jdk/pull/212/files/a7cdaad6..398d7645 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From redestad at openjdk.java.net Mon Sep 28 20:06:02 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 28 Sep 2020 20:06:02 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v8] In-Reply-To: <_kbecDop0xzsAlIGGtV6ZihNQ3YgDDLrwOureP0A7Yw=.020d61a2-c24d-4d4c-be73-c675f70d44d9@github.com> References: <_kbecDop0xzsAlIGGtV6ZihNQ3YgDDLrwOureP0A7Yw=.020d61a2-c24d-4d4c-be73-c675f70d44d9@github.com> Message-ID: On Sun, 27 Sep 2020 19:11:42 GMT, Robbin Ehn wrote: >> We simplify the vmThread by removing the queue and refactor the the main loop. >> This solves the issues listed: >> - It can create an extra safepoint directly after a safepoint. >> - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. >> - The exposure of the vm operation is dangerous if it's a handshake. >> - The code is a hornets nest with the repetition of checks and branches >> >> Passes t1-8, and a benchmark run. >> >> If you want a smaller diff the commits contains the incremental progress and each commit passed t1. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Removed unused declartion - Claes Marked as reviewed by redestad (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From rehn at openjdk.java.net Mon Sep 28 20:06:02 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 28 Sep 2020 20:06:02 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v6] In-Reply-To: <6N9BJAvEjjipB90BTLeVUYFc2iCShOFCsfpuPk5r17k=.5cbf7ae0-c132-475e-8272-d719de7c0617@github.com> References: <1DbVvan-K6HarNVZcdNHC_8l9AmiVq8moglmKtSie6U=.61c90e70-a45c-4e00-9dc2-4b5dc29111e5@github.com> <6N9BJAvEjjipB90BTLeVUYFc2iCShOFCsfpuPk5r17k=.5cbf7ae0-c132-475e-8272-d719de7c0617@github.com> Message-ID: On Mon, 28 Sep 2020 18:32:17 GMT, Daniel D. Daugherty wrote: >> If GuaranteedSafepointInterval is set to a lower value than the default on the command line, then I'm okay if >> SafepointALot does not do anything extra. However, if GuaranteedSafepointInterval is either the default value or is set >> to a higher value, then I would like SafepointALot to cause a safepoint more frequently than the >> GuaranteedSafepointInterval. Every GuaranteedSafepointInterval/4 would be a fine definition of "a lot". > > Mulling on this more... is it too radical to consider that we no longer need SafepointALot? I would like SafepointALot(and HandshakeALot) to be executed in a separate thread and that randomly request a safepoint (preferably with some validation inside the operation). Since VM thread now handles this it can not do this request while busy. Also having the VM thread 'more' sporadic waking up will be confusing for the VM thread loop. So I agree with you that we need a better SafepointALot, but I think it wrong to use the VM thread to drive it. I suggest we create an enhancement for it. ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From dcubed at openjdk.java.net Mon Sep 28 20:14:35 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Mon, 28 Sep 2020 20:14:35 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v8] In-Reply-To: <_kbecDop0xzsAlIGGtV6ZihNQ3YgDDLrwOureP0A7Yw=.020d61a2-c24d-4d4c-be73-c675f70d44d9@github.com> References: <_kbecDop0xzsAlIGGtV6ZihNQ3YgDDLrwOureP0A7Yw=.020d61a2-c24d-4d4c-be73-c675f70d44d9@github.com> Message-ID: On Sun, 27 Sep 2020 19:11:42 GMT, Robbin Ehn wrote: >> We simplify the vmThread by removing the queue and refactor the the main loop. >> This solves the issues listed: >> - It can create an extra safepoint directly after a safepoint. >> - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. >> - The exposure of the vm operation is dangerous if it's a handshake. >> - The code is a hornets nest with the repetition of checks and branches >> >> Passes t1-8, and a benchmark run. >> >> If you want a smaller diff the commits contains the incremental progress and each commit passed t1. > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Removed unused declartion - Claes I'm okay with leaving SafepointALot as you have it now and leaving any future cleanup/refinement to a new RFE. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/228 From mdoerr at openjdk.java.net Mon Sep 28 20:18:23 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 28 Sep 2020 20:18:23 GMT Subject: RFR: 8253740: [PPC64] Minor interpreter cleanup Message-ID: <9ENQcPBWCaewPezO3ObXyRtvAW2464wWrYmn6eBExYs=.714ecad9-fca8-40a3-9f41-72875f70e54f@github.com> Template interpreter on PPC64 can be cleaned up after JDK-8253540: unlock_object has a parameter check_for_exceptions which is now unused. In addition to that, restore_interpreter_state is redundant after call_VM(R4_ARG2, CAST_FROM_FN_PTR(address, InterpreterRuntime::member_name_arg_or_null) because it's already included in call_VM. https://bugs.openjdk.java.net/browse/JDK-8253740 ------------- Commit messages: - 8253740: [PPC64] Minor interpreter cleanup Changes: https://git.openjdk.java.net/jdk/pull/385/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=385&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253740 Stats: 9 lines in 3 files changed: 0 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/385.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/385/head:pull/385 PR: https://git.openjdk.java.net/jdk/pull/385 From akozlov at openjdk.java.net Mon Sep 28 20:21:24 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Mon, 28 Sep 2020 20:21:24 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS In-Reply-To: References: <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com> Message-ID: On Mon, 28 Sep 2020 11:51:24 GMT, Anton Kozlov wrote: >> @tstuefe My patch to remove MAP_FIXED from the memory reservation path should make it possible to revert all the >> os::reserve_memory changes in this patch. > > Interesting, thanks! I haven't evaluated the interface, just because it seemed to be out of scope for the task. I'll > take a look and update the patch. Hi, > Can we on MacOS not use mmap at os::commit_memory, like we do on other platforms? In os::commit_memory, the exec > parameter exists but on MacOS it is ignored. Unfortunately, no. It's commit_memory uses MAP_FIXED that is incompatible with MAP_JIT. So it is impossible to commit executable mapping, as commit is always MAP_FIXED. This change proposes a kind of 2-step mapping: MAP_JIT in reserve and mprotect-without-mmap in commit. > We now have to specify "exec" as parameter to os::reverve_memory(). This is another new restriction - before, I could > theoretically reserve one mapping and commit various parts of it with and without exec flag. With this change, the > whole mapping has to be either exec or !exec. I think this is a major point in how the interface can be perceived. I assumed reserve to be semantically equivalent to mmap. And commit/uncommit only to control how much memory is actually allocated in the mmaping. E.g. commit could only follow reserve and commit could only refer to a (part of) memory reserved. So it would be natural for reserve to dictate exec or !exec mode for commit in its memory region. Do you think it will be a bad thing? I.e. to allow exec commit only in exec reserved mapping? Apparently, there was no demand to do the opposite before. For that, it is still possible to reserve another !exec mapping beside. > Why does os::uncommit_memory() now require "exec" as parameter? I know why you do it, but semantically it has no > meaning. I should be able to uncommit memory without knowing the exact flags the mapping had been established with. So > now the user has to carry this information and provide it back to the API when uncommitting? Right now probably all > uncommits happen in areas where the exec information is implicit by its usage, but who says this is always the case? I would propose for reserve, commit, uncommit to take a uniform set of parameters to model an object of a (missing) "mapping" class, which would contain a meta-information about e.g. permissions. Now the meta-information is available in the context, as you correctly have noted, so we don't really need to introduce the real object and class. It is hard for me to imagine a case for "uncommit region regardless exec/!exec permission" that would really justify the need for such uncommit request. So I would propose to consider executable and nonexecutable mappings rather different, as 1) it is required by some platforms like macOS, and 2) it is supported by the fact that now we know the exec/!exec type of a mapping when we work with it (e.g. heap vs codecache). To continue the trend of the cleanup and to highlight the difference, it is possible to create specialized code_reserve/commit/uncommit that will be implemented with usual reserve/... on all platforms except macOS, and latter to use MAP_JIT in the implementation. Or I could stick with exec parameter. What do you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From mdoerr at openjdk.java.net Mon Sep 28 21:18:06 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 28 Sep 2020 21:18:06 GMT Subject: RFR: 8253183: Fragile memory barrier selection for some weak memory model platforms Message-ID: Hi, I'd like to propose a fix after the discussion in https://bugs.openjdk.java.net/browse/JDK-8253183 Please especially review my new comments in the code. The authors of the surrounding code in objectMonitor.cpp and synchronizer.cpp may know better. ------------- Commit messages: - 8253183: Fragile memory barrier selection for some weak memory model platforms Changes: https://git.openjdk.java.net/jdk/pull/387/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=387&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253183 Stats: 32 lines in 4 files changed: 11 ins; 9 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/387.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/387/head:pull/387 PR: https://git.openjdk.java.net/jdk/pull/387 From phedlin at openjdk.java.net Mon Sep 28 21:29:19 2020 From: phedlin at openjdk.java.net (Patric Hedlin) Date: Mon, 28 Sep 2020 21:29:19 GMT Subject: RFR: 8253728: tests fail with "assert(fr.is_compiled_frame()) failed: Wrong frame type" Message-ID: Spurious assert (valid for Aarch64 only). The frame may already be deoptimized. ------------- Commit messages: - 8253728: tests fail with "assert(fr.is_compiled_frame()) failed: Wrong frame type" Changes: https://git.openjdk.java.net/jdk/pull/388/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=388&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253728 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/388.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/388/head:pull/388 PR: https://git.openjdk.java.net/jdk/pull/388 From kvn at openjdk.java.net Mon Sep 28 21:47:33 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 28 Sep 2020 21:47:33 GMT Subject: RFR: 8253728: tests fail with "assert(fr.is_compiled_frame()) failed: Wrong frame type" In-Reply-To: References: Message-ID: <0RQbvSuQKqxK5yspyB_GLPIIe4VpTOsWh-lC7_3LHkk=.4196a993-b923-44f3-a683-256a9b909dd8@github.com> On Mon, 28 Sep 2020 21:23:35 GMT, Patric Hedlin wrote: > Spurious assert (valid for Aarch64 only). > > The frame may already be deoptimized. Marked as reviewed by kvn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/388 From phedlin at openjdk.java.net Mon Sep 28 21:51:32 2020 From: phedlin at openjdk.java.net (Patric Hedlin) Date: Mon, 28 Sep 2020 21:51:32 GMT Subject: RFR: 8253728: tests fail with "assert(fr.is_compiled_frame()) failed: Wrong frame type" In-Reply-To: <0RQbvSuQKqxK5yspyB_GLPIIe4VpTOsWh-lC7_3LHkk=.4196a993-b923-44f3-a683-256a9b909dd8@github.com> References: <0RQbvSuQKqxK5yspyB_GLPIIe4VpTOsWh-lC7_3LHkk=.4196a993-b923-44f3-a683-256a9b909dd8@github.com> Message-ID: <3giCKtZ4clGziG7Rlh-7jCVnlG0oYjbou4ZruY-Pjww=.b93dbc86-81a6-4639-8885-2f903fcd9efe@github.com> On Mon, 28 Sep 2020 21:44:57 GMT, Vladimir Kozlov wrote: >> Spurious assert (valid for Aarch64 only). >> >> The frame may already be deoptimized. > > Marked as reviewed by kvn (Reviewer). Thank you Vladimir. ------------- PR: https://git.openjdk.java.net/jdk/pull/388 From phedlin at openjdk.java.net Mon Sep 28 21:51:33 2020 From: phedlin at openjdk.java.net (Patric Hedlin) Date: Mon, 28 Sep 2020 21:51:33 GMT Subject: Integrated: 8253728: tests fail with "assert(fr.is_compiled_frame()) failed: Wrong frame type" In-Reply-To: References: Message-ID: <5FjiiZcReZm1wExWEiBUQvHuIeUWjityfx4tE78ljcE=.3c03fbdc-2ef3-4b44-967e-271fe0e50e36@github.com> On Mon, 28 Sep 2020 21:23:35 GMT, Patric Hedlin wrote: > Spurious assert (valid for Aarch64 only). > > The frame may already be deoptimized. This pull request has now been integrated. Changeset: 70b0fccf Author: Patric Hedlin URL: https://git.openjdk.java.net/jdk/commit/70b0fccf Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8253728: tests fail with "assert(fr.is_compiled_frame()) failed: Wrong frame type" Reviewed-by: kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/388 From coleenp at openjdk.java.net Tue Sep 29 00:05:28 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 29 Sep 2020 00:05:28 GMT Subject: RFR: 8253740: [PPC64] Minor interpreter cleanup In-Reply-To: <9ENQcPBWCaewPezO3ObXyRtvAW2464wWrYmn6eBExYs=.714ecad9-fca8-40a3-9f41-72875f70e54f@github.com> References: <9ENQcPBWCaewPezO3ObXyRtvAW2464wWrYmn6eBExYs=.714ecad9-fca8-40a3-9f41-72875f70e54f@github.com> Message-ID: On Mon, 28 Sep 2020 20:11:05 GMT, Martin Doerr wrote: > Template interpreter on PPC64 can be cleaned up after JDK-8253540: > unlock_object has a parameter check_for_exceptions which is now unused. > > In addition to that, restore_interpreter_state is redundant after > call_VM(R4_ARG2, CAST_FROM_FN_PTR(address, InterpreterRuntime::member_name_arg_or_null) because it's already included > in call_VM. > https://bugs.openjdk.java.net/browse/JDK-8253740 This looks good but I also noticed that ppc and s390 pass an extra parameter to InterpreterRuntime::monitorenter() also. ------------- PR: https://git.openjdk.java.net/jdk/pull/385 From github.com+51754783+CoreyAshford at openjdk.java.net Tue Sep 29 00:53:59 2020 From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford) Date: Tue, 29 Sep 2020 00:53:59 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 16:35:59 GMT, CoreyAshford wrote: > Can be reproduced by running JTREG tests: > compiler/aot/calls/fromAot I have tried reproducing this, but haven't yet succeeded. Here's how I'm running it from the jdk/test directory: `jtreg -jdk: ./hotspot/jtreg/compiler/aot/calls/fromAot` The response is this: Test results: no tests selected Report written to /home/cjashfor/git-trees/jdk/test/JTreport/html/report.html Results written to /home/cjashfor/git-trees/jdk/test/JTwork The report's Results sections shows "Total 0" Any ideas? I'm new to running JTReg tests, so don't assume I know anything :) ------------- PR: https://git.openjdk.java.net/jdk/pull/293 From iignatyev at openjdk.java.net Tue Sep 29 01:27:43 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 29 Sep 2020 01:27:43 GMT Subject: RFR: 8253750: use build-stable default seed for Utils.RANDOM_GENERATOR Message-ID: Hi all, could you please review the patch which updates `jdk.test.lib.Utils` to use md5 hash-sum of `java.vm.version` property as default seed for `Utils.RANDOM_GENERATOR`? from JBS: > using the same seed for all runs of a build will make it possible (easier) to compare results from different test runs > (e.g. on different platforms, w/ different flags) and consequently will make test results analysis easier. the patch also updates `RandomGeneratorTest` test, so it expects now that the same values are generated if no seed is provided. testing: ? tier1 ------------- Commit messages: - 8253750: use build-stable default seed for Utils.RANDOM_GENERATOR Changes: https://git.openjdk.java.net/jdk/pull/391/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=391&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253750 Stats: 34 lines in 2 files changed: 26 ins; 6 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/391.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/391/head:pull/391 PR: https://git.openjdk.java.net/jdk/pull/391 From sspitsyn at openjdk.java.net Tue Sep 29 04:13:28 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 29 Sep 2020 04:13:28 GMT Subject: RFR: 8238761: Asynchronous handshakes [v8] In-Reply-To: References: Message-ID: <8LRFmqwRLm58fvuNkrwHvy0ahQEtP91-XA89qoVgq0E=.612c1dd1-0892-43ff-96ad-8903194807c5@github.com> On Mon, 28 Sep 2020 19:15:35 GMT, Robbin Ehn wrote: >> Robbin, thank you for your answers! >> There are JVMTI functions that are specified to return error code JVMTI_ERROR_THREAD_NOT_ALIVE. >> As an example, see: >> https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#GetStackTrace >> The following functions are impacted by your fix: >> GetOwnedMonitorInfo, GetOwnedMonitorStackDepthInfo, GetCurrentContendedMonitor, GetStackTrace, GetFrameCount, >> GetFrameLocation, PopFrame >> >> I wonder, how this error code can be ever returned for these functions now. > >> Robbin, thank you for your answers! >> There are JVMTI functions that are specified to return error code JVMTI_ERROR_THREAD_NOT_ALIVE. >> As an example, see: >> https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#GetStackTrace >> The following functions are impacted by your fix: >> GetOwnedMonitorInfo, GetOwnedMonitorStackDepthInfo, GetCurrentContendedMonitor, GetStackTrace, GetFrameCount, >> GetFrameLocation, PopFrame >> I wonder, how this error code can be ever returned for these functions now. > > They should have exactly the same behavior as previously. > All I did was set JVMTI_ERROR_THREAD_NOT_ALIVE as the default value for those handshakes: > https://github.com/openjdk/jdk/blob/3a95750e6474214c62b04fccbfe172d077d3915f/src/hotspot/share/prims/jvmtiEnvBase.hpp#L345 > Which simplifies the code. > So only in the two cases where the guarantee's are we can never return that > (reset_current_location/enter_interp_only_mode) > If the guarantee's are wrong, the current code have that bug already, so I'm not adding or fixing that. > > It should be exactly the same and we have test for at least some of the operations which verifies that the agent gets: > JVMTI_ERROR_THREAD_NOT_ALIVE > And this passes t1-8 multiple times, so I'm pretty confident that this does not change any return value. Robbin, you are right - thanks. The JVMTI_ERROR_THREAD_NOT_ALIVE is the default value. ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From sspitsyn at openjdk.java.net Tue Sep 29 04:13:28 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 29 Sep 2020 04:13:28 GMT Subject: RFR: 8238761: Asynchronous handshakes [v9] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 09:01:22 GMT, Robbin Ehn wrote: >> This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes >> are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) >> Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an >> arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a >> singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first >> pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first >> pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake >> operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything >> except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed >> filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake >> operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there >> is now only one method to call when handshaking one thread. Some comments about the changes: >> - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake >> all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much >> worse then this. >> >> - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that >> thread. >> >> - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a >> handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. >> >> - Added WB testing method. >> >> - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. >> >> - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. >> >> - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a >> safepoint and half of them after, in many handshake all operations. >> >> - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. >> >> - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the >> moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. >> >> - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. >> >> - Added filtered queue and gtest for it. >> >> Passes multiple t1-8 runs. >> Been through some pre-reviwing. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since > the last revision: > - More fixes from David > - Merge branch 'master' into 8238761-asynchrounous-handshakes > - Add constructor and comment. Previous renames caused confusing, improved names once more and moved non-public to private > - Fixed trailing whitespace > - Update after David > - Update after Coleen > - Update after Dan and David > - Merge branch 'master' into 8238761-asynchrounous-handshakes > - Removed double check, fix comment, removed not needed function, updated logs > - Fixed double checks > Added NSV > ProcessResult to enum > Fixed logging > Moved _active_handshaker to private > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3aea0ca4...3a95750e Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From jbhateja at openjdk.java.net Tue Sep 29 06:04:17 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 29 Sep 2020 06:04:17 GMT Subject: RFR: 8253721: Flag -XX:AVX3Threshold does not accept Zero value Message-ID: AVX3Threshold has been used in various places to enable emitting AVX3 specific instructions in case data size being worked over is greater than 4096 bytes. However, user is free to set the threshold value to Zero based on his workload. In such a case a compile time check is enough to trigger generation of AVX3 instructions. In other cases comparison is done at the runtime though JITed comparison instruction. Patch allows setting AVX3Threshold to a zero value. ------------- Commit messages: - 8253721: Flag -XX:AVX3Threshold does not accept Zero value. Changes: https://git.openjdk.java.net/jdk/pull/394/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=394&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253721 Stats: 23 lines in 7 files changed: 13 ins; 10 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/394.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/394/head:pull/394 PR: https://git.openjdk.java.net/jdk/pull/394 From jbhateja at openjdk.java.net Tue Sep 29 06:05:53 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 29 Sep 2020 06:05:53 GMT Subject: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions [v5] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 20:52:28 GMT, Vladimir Kozlov wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8252847 : Modifying file permission to resolve jcheck failure. > > test/hotspot/jtreg/compiler/arraycopy/TestArrayCopyConjoint.java line 33: > >> 31: * >> 32: * @run main/othervm/timeout=600 -XX:-TieredCompilation -Xbatch -XX:+IgnoreUnrecognizedVMOptions >> 33: * -XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:ArrayCopyPartialInlineSize=0 -XX:MaxVectorSize=32 -XX:+UnlockDiagnosticVMOptions > > ArrayCopyPartialInlineSize flag is not defiled in these changes. > It seems they need to be included in 8252848 changes. Hi @vnkozlov, I have updated the pull request to cover your comments. Kindly review. New RFE JDK-8253721 has been created for AVX3Threshold flag related changes (PR-394). ------------- PR: https://git.openjdk.java.net/jdk/pull/61 From kbarrett at openjdk.java.net Tue Sep 29 06:17:38 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 29 Sep 2020 06:17:38 GMT Subject: RFR: 8247912: Make narrowOop a scoped enum [v2] In-Reply-To: References: Message-ID: On Thu, 24 Sep 2020 13:17:08 GMT, Ioi Lam wrote: >>> > Also, should we allow only unsigned types for T? I think using signed types here is prone to error and should be >>> > flagged. >>> >>> It turns out we can't restrict it to unsigned types, at least not very easily. For example, >>> CDS calls this with an intptr_t value. I suppose CDS could do conversion itself before >>> calling this, but that seems a little odd. And I don't know how many more there are after >>> changing that one. >> >> But shouldn't intptr_t be unsigned? I tested with this: >> >> #include >> #include >> >> int main() { >> printf("%d %d\n", std::is_signed::value, std::is_signed::value); >> } >> >> and it prints out "1 0". > >> > > Also, should we allow only unsigned types for T? I think using signed types here is prone to error and should be >> > > flagged. >> > >> > >> > It turns out we can't restrict it to unsigned types, at least not very easily. For example, >> > CDS calls this with an intptr_t value. I suppose CDS could do conversion itself before >> > calling this, but that seems a little odd. And I don't know how many more there are after >> > changing that one. >> >> But shouldn't intptr_t be unsigned? I tested with this: > > Oops, my mistake. I thought `intptr_t` was `int*`, but it's in fact "Integer type capable of holding a value converted > from a void pointer and then be converted back to that type with a value that compares equal to the original pointer." Ping. Needs more reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/273 From dholmes at openjdk.java.net Tue Sep 29 06:28:43 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 29 Sep 2020 06:28:43 GMT Subject: RFR: 8238761: Asynchronous handshakes [v9] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 09:01:22 GMT, Robbin Ehn wrote: >> This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes >> are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) >> Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an >> arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a >> singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first >> pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first >> pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake >> operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything >> except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed >> filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake >> operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there >> is now only one method to call when handshaking one thread. Some comments about the changes: >> - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake >> all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much >> worse then this. >> >> - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that >> thread. >> >> - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a >> handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. >> >> - Added WB testing method. >> >> - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. >> >> - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. >> >> - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a >> safepoint and half of them after, in many handshake all operations. >> >> - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. >> >> - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the >> moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. >> >> - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. >> >> - Added filtered queue and gtest for it. >> >> Passes multiple t1-8 runs. >> Been through some pre-reviwing. > > Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since > the last revision: > - More fixes from David > - Merge branch 'master' into 8238761-asynchrounous-handshakes > - Add constructor and comment. Previous renames caused confusing, improved names once more and moved non-public to private > - Fixed trailing whitespace > - Update after David > - Update after Coleen > - Update after Dan and David > - Merge branch 'master' into 8238761-asynchrounous-handshakes > - Removed double check, fix comment, removed not needed function, updated logs > - Fixed double checks > Added NSV > ProcessResult to enum > Fixed logging > Moved _active_handshaker to private > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/153ca635...3a95750e Hi Robbin, Thanks for the updates and the slack chat to clarify my misunderstanding of the queuing mechanism. I agree that the logging statements are somewhat confusing as they were written when the processing logic was much simpler, but I understand now the count of emitted executed operations. This all looks good to me now. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/151 From eosterlund at openjdk.java.net Tue Sep 29 06:46:10 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 29 Sep 2020 06:46:10 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v7] In-Reply-To: <0YZltgQGjDI8GW69qzCH_Kg3twWzN6dOyO5yBJ7B784=.b9fd2418-4218-4ff3-ba56-17e0a453796b@github.com> References: <0YZltgQGjDI8GW69qzCH_Kg3twWzN6dOyO5yBJ7B784=.b9fd2418-4218-4ff3-ba56-17e0a453796b@github.com> Message-ID: On Mon, 28 Sep 2020 17:20:49 GMT, Aleksey Shipilev wrote: >> We call frame::oops_do from the GC to make bad oops good. But the oops_do logic assers the oop is good *before* the >> closure is applied. Every time I do something, I run i to issues with this assert. It seems like an invalid assumption >> to me, that oops are meant to always be good, even before they are fixed. I vote for removing this assert. It has >> caused a lot of pain. Any takers? > > I think the previous assert was intentionally weaker: `is_in` checks that argument points to a committed area in the > heap, which can include the oops not yet fixed. It does not check if oop is valid as far as GC is concerned. So maybe > reverting `NativeAccess::oop_load` is enough? It was checking is_in_or_null before and after. Our is_in checks that it is in committed memory, and that the pointer is not stale w.r.t. color, as that is very likely to be a bug. We reluctantly made it relaxed for our safepoints that flip colors. I think it was once again for this very same usual suspect assert. But now that this is concurrent, its memory can get concurrently freed. I think this is the 7th time I try to make this assert happy. I run into it all the time. IMO, the underlying assumption of the assert, is wrong. This is an iterator used by GC to fix totally invalid stale pointers into valid pointers. You really can't expect that they are valid before fixing them. That just happened to be true for other GCs. It makes little sense to me. That is why my preferred solution is to remove the assert. I would not miss it. We have had similar issues with the oop_iterate framework asserting oops are valid before the closure is applied. At least there, it is possible to opt out... Would anyone miss the assert? ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From thomas.stuefe at gmail.com Tue Sep 29 06:53:12 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 29 Sep 2020 08:53:12 +0200 Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS In-Reply-To: References: <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com> Message-ID: Hi Anton, On Mon, Sep 28, 2020 at 10:21 PM Anton Kozlov wrote: > On Mon, 28 Sep 2020 11:51:24 GMT, Anton Kozlov > wrote: > > >> @tstuefe My patch to remove MAP_FIXED from the memory reservation path > should make it possible to revert all the > >> os::reserve_memory changes in this patch. > > > > Interesting, thanks! I haven't evaluated the interface, just because it > seemed to be out of scope for the task. I'll > > take a look and update the patch. > > Hi, > > > Can we on MacOS not use mmap at os::commit_memory, like we do on other > platforms? In os::commit_memory, the exec > > parameter exists but on MacOS it is ignored. > > Unfortunately, no. It's commit_memory uses MAP_FIXED that is incompatible > with MAP_JIT. So it is impossible to commit > executable mapping, as commit is always MAP_FIXED. This change proposes a > kind of 2-step mapping: MAP_JIT in reserve > and mprotect-without-mmap in commit. > Okay > > > We now have to specify "exec" as parameter to os::reverve_memory(). This > is another new restriction - before, I could > > theoretically reserve one mapping and commit various parts of it with > and without exec flag. With this change, the > > whole mapping has to be either exec or !exec. > > I think this is a major point in how the interface can be perceived. I > assumed reserve to be semantically equivalent to > mmap. And commit/uncommit only to control how much memory is actually > allocated in the mmaping. E.g. commit could only > follow reserve and commit could only refer to a (part of) memory reserved. > So it would be natural for reserve to > dictate exec or !exec mode for commit in its memory region. > In principle I agree with you. But os::reserve and friends are vaguely defined wrappers around a number of quite different OS side APIs. Since they have zero documentation and very little testing, it is everyones guess what they actually should do. All we have are their names and the various different implementations, which differ in a lot of details from one another. I know this since a long time ago I implemented the AIX side of this API and that was painful. We have: 1 mmap on most Posix systems. An API with not a lot of restrictions, on the surface; allows partly unmapping and uncommitting parts; allows to set exec permissions on a per-page base. But seems not on all OSes. 2 VirtualAlloc on Windows. A stricter API. Only allows unmapping the whole mapping as a whole. 3 SystemV shared mem. Also strict; also only allows total unmapping. On Linux used for os::reserve_memory_special (no clue what special means) to allocate large pages. On AIX, we use it to get 64K pages. On AIX, we transparently switch between one or the other. To me, 2 and 3 feel very similar, as opposed to 1. On Linux and AIX, we dynamically switch between 1 and 3; on AIX we hide that fact. You are right, there is a missing building block (a mapping class) which would keep information about a mapping. Arguably, ReservedSpace feels like it wants to be that building block, but it is bloated and occupies itself with a lot of heap specific stuff. On AIX, to get information at commit/release time about the mapping, we keep such a mapping-related management record internally (struct vmembk_t, see https://github.com/openjdk/jdk/blob/70b0fccf79ac7193b36c49aff0286fdc09bb370c/src/hotspot/os/aix/os_aix.cpp#L1834) - and retrieve it whenever someone hands in a pointer allocated with os::reserve_memory, see: https://github.com/openjdk/jdk/blob/70b0fccf79ac7193b36c49aff0286fdc09bb370c/src/hotspot/os/aix/os_aix.cpp#L2372 . This code stems from before SAPs involvement in OpenJDK, when we had no way to change code upstream, and allowed us to hide AIX complications from upper layers. This is certainly not the best solution, but it is something you could do too for MacOS. That would mean you do not have to change the uncommit API. Of course, a better solution would be a cleanly defined interface, with a Mapping class which defines properties of a mapping, well documented and tested :/ but thats a large effort. The small cleanups that are done (most recently Stefans removal of MAP_FIXED) are a step in that direction. > > Do you think it will be a bad thing? I.e. to allow exec commit only in > exec reserved mapping? Apparently, there was no > demand to do the opposite before. For that, it is still possible to > reserve another !exec mapping beside. > > Well, I played with the thought of placing code fragments in Metaspace. Just an idea now, but being able to set exec permission on a range of memory would make matters a lot easier. As would not having to care about exec state of the underlying memory when uncommitting the memory. > > Why does os::uncommit_memory() now require "exec" as parameter? I know > why you do it, but semantically it has no > > meaning. I should be able to uncommit memory without knowing the exact > flags the mapping had been established with. So > > now the user has to carry this information and provide it back to the > API when uncommitting? Right now probably all > > uncommits happen in areas where the exec information is implicit by its > usage, but who says this is always the case? > > I would propose for reserve, commit, uncommit to take a uniform set of > parameters to model an object of a (missing) > "mapping" class, which would contain a meta-information about e.g. > permissions. Now the meta-information is available > in the context, as you correctly have noted, so we don't really need to > introduce the real object and class. > But what is the contract here for uncommit (and commit actually)? It looks like I can change exec permission per page in a mapping (regardless of its commit state) and it may be able to do this on commit() - but not on MacOS - but on uncommit, it is just a "remind me again what flag I used for this mapping" kind of thing. What happens when I accidentally get it wrong, or there is a mismatch? Something the OS or the hotspot OS layer should know already. > > It is hard for me to imagine a case for "uncommit region regardless > exec/!exec permission" that would really justify > the need for such uncommit request. > Uncommit has nothing to do with the exec state of the memory. I should not have to know at uncommit time. Like malloc and free: at free(), I should not have to know the size of the allocation established with malloc. The information should be already there in the lower layer. I should not have to provide it. > So I would propose to consider executable and nonexecutable mappings > rather different, as 1) it is required by some > platforms like macOS, I could live with that. The platforms which have this restriction are MacOS and AIX. The latter does not have explicit commit at all, so exec permission is established at reserve time and cannot be changed later. > and 2) it is supported by the fact that now we know the exec/!exec type of > a mapping when we work > with it (e.g. heap vs codecache). ok > To continue the trend of the cleanup and to highlight the difference, it > is possible > to create specialized code_reserve/commit/uncommit that will be > implemented with usual reserve/... on all platforms > except macOS, and latter to use MAP_JIT in the implementation. Not totally opposed to this, but how is this different from passing a parameter? Which brings me to another thing, if we add exec to os::reserve_memory, why not to os::reserve_aligned, os::attempt_reserve_at and os::reserve_memory_special? We had a similar thing some time ago when (Intel?) introduced the "reserve heap on device" notion and pushed the "fd" parameter into os::reserve - into some APIs, but not all, and Stefan Karlson just recently untangled that mess a bit. > Or I could stick with exec parameter. What do you think? > > I think we agree that an overhaul would be good, but I do not want to block you either. I'd ask you to investigate first if the "exec" information can somehow be obtained within os_bsd.cpp. Either by asking the platform (maybe there is an api to get the flags a mapping had been established with?). Or, failing that, by considering a similar solution as I have outlined above, like what we did on AIX (could be done better than I did, with less code). Storing mapping related information in a record and somehow keep it at OS level, retrieving it as needed. That would reduce the outside API changes by removing the need to pass in exec to uncommit. Which really feels wrong to me. (For the future, a better solution would be an os:: level class for mappings. Maybe we should just develop a new clean interface beside the old one and start migrating code to the new one.) Cheers & thanks for your patience, Thomas > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/294 > From dholmes at openjdk.java.net Tue Sep 29 06:57:02 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 29 Sep 2020 06:57:02 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v11] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 19:53:37 GMT, Monica Beckwith wrote: >> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: > > r18 only on Linux Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From mbaesken at openjdk.java.net Tue Sep 29 07:14:29 2020 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 29 Sep 2020 07:14:29 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 06:06:31 GMT, Kim Barrett wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129: > >> 127: NSColor* result = nil; >> 128: >> 129: if (colorIndex < ((useAppleColor) ? sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS : >> java_awt_SystemColor_NUM_COLORS)) { > > This looks like a plain old bug fix, nothing really to do with the compiler upgrade. The new compiler presumably just > has a new warning that brought attention to the problem. As such, I don't think it belongs in a PR that's about issues > related to the compiler upgrade. Someone might want to backport just this fix, for example. Hello Kim, Paul - so should we open a separate bug for the src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m issue because it might be a general problem just uncovered by the new compiler ? Paul , do you want to do this ? Or should I open a bug and post a separate change for the useAppleColor check in CSystemColors.m ? ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From stefank at openjdk.java.net Tue Sep 29 07:15:38 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 29 Sep 2020 07:15:38 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS In-Reply-To: References: <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com> Message-ID: On Mon, 28 Sep 2020 11:17:49 GMT, Stefan Karlsson wrote: > @tstuefe My patch to remove MAP_FIXED from the memory reservation path should make it possible to revert all the > os::reserve_memory changes in this patch. FWIW, I now understand that the motivation for the changes in os::reserve_memory is *not* that *it* uses MAP_FIXED. Instead the change there is done so that os::commit_memory doesn't have to mix mmap + MAP_FIXED + MAP_JIT. This is also the reason why os::uncommit_memory needs to be changed as well. So, ignore my comment above. ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From stefank at openjdk.java.net Tue Sep 29 07:27:06 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 29 Sep 2020 07:27:06 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v7] In-Reply-To: References: <0YZltgQGjDI8GW69qzCH_Kg3twWzN6dOyO5yBJ7B784=.b9fd2418-4218-4ff3-ba56-17e0a453796b@github.com> Message-ID: On Tue, 29 Sep 2020 06:42:54 GMT, Erik ?sterlund wrote: >> I think the previous assert was intentionally weaker: `is_in` checks that argument points to a committed area in the >> heap, which can include the oops not yet fixed. It does not check if oop is valid as far as GC is concerned. So maybe >> reverting `NativeAccess::oop_load` is enough? > > It was checking is_in_or_null before and after. Our is_in checks that it is in committed memory, and that the pointer > is not stale w.r.t. color, as that is very likely to be a bug. We reluctantly made it relaxed for our safepoints that > flip colors. I think it was once again for this very same usual suspect assert. But now that this is concurrent, its > memory can get concurrently freed. I think this is the 7th time I try to make this assert happy. I run into it all the > time. IMO, the underlying assumption of the assert, is wrong. This is an iterator used by GC to fix totally invalid > stale pointers into valid pointers. You really can't expect that they are valid before fixing them. That just happened > to be true for other GCs. It makes little sense to me. That is why my preferred solution is to remove the assert. I > would not miss it. We have had similar issues with the oop_iterate framework asserting oops are valid before the > closure is applied. At least there, it is possible to opt out... Would anyone miss the assert? FTR, this is the RFE to remove the oop verification from the oop_iterate framework: https://bugs.openjdk.java.net/browse/JDK-8237363 I really would like to get rid of it, but got push back because it made GCs have to duplicate the effort to provide verification. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From pliden at openjdk.java.net Tue Sep 29 07:31:55 2020 From: pliden at openjdk.java.net (Per Liden) Date: Tue, 29 Sep 2020 07:31:55 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v7] In-Reply-To: References: <0YZltgQGjDI8GW69qzCH_Kg3twWzN6dOyO5yBJ7B784=.b9fd2418-4218-4ff3-ba56-17e0a453796b@github.com> Message-ID: On Tue, 29 Sep 2020 07:24:16 GMT, Stefan Karlsson wrote: >> It was checking is_in_or_null before and after. Our is_in checks that it is in committed memory, and that the pointer >> is not stale w.r.t. color, as that is very likely to be a bug. We reluctantly made it relaxed for our safepoints that >> flip colors. I think it was once again for this very same usual suspect assert. But now that this is concurrent, its >> memory can get concurrently freed. I think this is the 7th time I try to make this assert happy. I run into it all the >> time. IMO, the underlying assumption of the assert, is wrong. This is an iterator used by GC to fix totally invalid >> stale pointers into valid pointers. You really can't expect that they are valid before fixing them. That just happened >> to be true for other GCs. It makes little sense to me. That is why my preferred solution is to remove the assert. I >> would not miss it. We have had similar issues with the oop_iterate framework asserting oops are valid before the >> closure is applied. At least there, it is possible to opt out... Would anyone miss the assert? > > FTR, this is the RFE to remove the oop verification from the oop_iterate framework: > https://bugs.openjdk.java.net/browse/JDK-8237363 > > I really would like to get rid of it, but got push back because it made GCs have to duplicate the effort to provide > verification. I've also has problems with this assert in the past, and I think that the underlying assumption of the assert is wrong. I would not miss it. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From stefank at openjdk.java.net Tue Sep 29 07:32:58 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 29 Sep 2020 07:32:58 GMT Subject: RFR: 8253640: Make MEMFLAGS an enum class [v2] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 13:39:31 GMT, Thomas Schatzl wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Review 1 > > Lgtm. Thanks, Thomas! ------------- PR: https://git.openjdk.java.net/jdk/pull/378 From eosterlund at openjdk.java.net Tue Sep 29 07:39:06 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 29 Sep 2020 07:39:06 GMT Subject: RFR: 8253611: AArch64: Concurrency problems in JavaFrameAnchor In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 07:00:16 GMT, Aleksey Shipilev wrote: > It looks that `_last_Java_sp` is additionally used as acquire/release flag that guards the rest of the state. Yet, the > coding in `javaFrameAnchor_aarch64.hpp` is incorrect at least in one place: > _last_Java_fp = src->_last_Java_fp; > _last_Java_pc = src->_last_Java_pc; > // Must be last so profiler will always see valid frame if has_last_frame() is true > _last_Java_sp = src->_last_Java_sp; > > There should be `OrderAccess::release()` where the comment suggesting the ordering constraint actually is -- I believe > that is a copy-paste error from x86. Other platforms have `release` thre. Additionally, it has to be matched with > `OrderAccess::acquire()` before `_last_Java_sp` reads, which requires the shared code to use the platform-specific > getter. Testing: > - [x] Linux x86_64 tier1 > - [x] Linux AArch64 tier1 > - [x] Linux AArch64 tier2 Note that the x86 code is probably wrong too. The volatile store/load pair only guarantees release/acquire semantics with the MSVC compiler (explicitly so). With for example GCC, it is explicitly stated that the compiler can and will reorder volatile and non-volatile accesses. So the release/acquire will only work if all preceding/subsequent accesses that were to be guarded by the release/acquire pair, are also volatile. And I doubt that is the case. So that seems flawed nevertheless. So x86 should probably also be explicit about using release/acquire (for the compiler barriers). ------------- PR: https://git.openjdk.java.net/jdk/pull/352 From dholmes at openjdk.java.net Tue Sep 29 07:53:53 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 29 Sep 2020 07:53:53 GMT Subject: RFR: 8253183: Fragile memory barrier selection for some weak memory model platforms In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 21:11:04 GMT, Martin Doerr wrote: > Hi, I'd like to propose a fix after the discussion in https://bugs.openjdk.java.net/browse/JDK-8253183 > > Please especially review my new comments in the code. The authors of the surrounding code in objectMonitor.cpp and > synchronizer.cpp may know better. Hi Martin, This looks good as was previously discussed. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/387 From mbaesken at openjdk.java.net Tue Sep 29 07:59:05 2020 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 29 Sep 2020 07:59:05 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: <5q0sckv5JjyV1HNZMX1f1eG2dwCjfLTejO8pfH7tS5s=.f1a8c3d5-a436-41bd-9d9f-68f0103539a1@github.com> References: <5q0sckv5JjyV1HNZMX1f1eG2dwCjfLTejO8pfH7tS5s=.f1a8c3d5-a436-41bd-9d9f-68f0103539a1@github.com> Message-ID: On Fri, 25 Sep 2020 02:23:07 GMT, David Holmes wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > src/hotspot/share/runtime/sharedRuntime.cpp line 2851: > >> 2849: if (buf != NULL) { >> 2850: CodeBuffer buffer(buf); >> 2851: short locs_buf[80]; > > This code is just weird. Why is the locs_buf array not declared to be the desired type? If the compiler rejects double > because it isn't relocInfo* then why does it accept short? And if it accepts short will it accept int or long long or > int64_t? Using int64_t would be a clearer change. Though semantically this code is awful. :( Should it be intptr_t ? Currently we have in the existing code various kind of buffers passed into initialize_shared_locs that compile nicely on all supported compilers and on Xcode 12 as well ,see c1_Compilation.cpp 326 char* locs_buffer = NEW_RESOURCE_ARRAY(char, locs_buffer_size); 327 code->insts()->initialize_shared_locs((relocInfo*)locs_buffer, sharedRuntime.cpp 2681 CodeBuffer buffer(buf); 2682 short buffer_locs[20]; 2683 buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, 2684 sizeof(buffer_locs)/sizeof(relocInfo)); So probably using short would be consistent to what we do already in the coding at another place (looking into relocInfo it would be probably better to use unsigned short or to typedef unsigned short in the relocInfo class and use the typedef). ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From eosterlund at openjdk.java.net Tue Sep 29 08:02:43 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 29 Sep 2020 08:02:43 GMT Subject: RFR: 8253183: Fragile memory barrier selection for some weak memory model platforms In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 21:11:04 GMT, Martin Doerr wrote: > Hi, I'd like to propose a fix after the discussion in https://bugs.openjdk.java.net/browse/JDK-8253183 > > Please especially review my new comments in the code. The authors of the surrounding code in objectMonitor.cpp and > synchronizer.cpp may know better. Looks good. Thanks for taking care of this Martin. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/387 From rehn at openjdk.java.net Tue Sep 29 08:57:41 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 29 Sep 2020 08:57:41 GMT Subject: RFR: 8238761: Asynchronous handshakes [v9] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 06:25:40 GMT, David Holmes wrote: >> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev >> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since >> the last revision: >> - More fixes from David >> - Merge branch 'master' into 8238761-asynchrounous-handshakes >> - Add constructor and comment. Previous renames caused confusing, improved names once more and moved non-public to private >> - Fixed trailing whitespace >> - Update after David >> - Update after Coleen >> - Update after Dan and David >> - Merge branch 'master' into 8238761-asynchrounous-handshakes >> - Removed double check, fix comment, removed not needed function, updated logs >> - Fixed double checks >> Added NSV >> ProcessResult to enum >> Fixed logging >> Moved _active_handshaker to private >> - ... and 1 more: https://git.openjdk.java.net/jdk/compare/5335e46d...3a95750e > > Hi Robbin, > Thanks for the updates and the slack chat to clarify my misunderstanding of the queuing mechanism. > > I agree that the logging statements are somewhat confusing as they were written when the processing logic was much > simpler, but I understand now the count of emitted executed operations. > This all looks good to me now. > Thanks, > David Thanks all! ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From mdoerr at openjdk.java.net Tue Sep 29 08:59:45 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 29 Sep 2020 08:59:45 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 00:51:37 GMT, CoreyAshford wrote: >>> AOT support needs an update: >>> # Internal Error (jdk/src/hotspot/share/aot/aotCodeHeap.cpp:557), pid=345656, tid=364316 >>> # guarantee(adr != NULL) failed: AOT Symbol not found _aot_stub_routines_base64_decodeBlock >>> >>> V [jvm.dll+0x1dbc6e] AOTCodeHeap::link_stub_routines_symbols+0xf7e (aotcodeheap.cpp:557) >>> V [jvm.dll+0x1d95e8] AOTCodeHeap::link_global_lib_symbols+0x2f8 (aotcodeheap.cpp:603) >>> V [jvm.dll+0x1dc616] AOTCodeHeap::load_klass_data+0x476 (aotcodeheap.cpp:840) >>> V [jvm.dll+0x1e1021] AOTLoader::load_for_klass+0x161 (aotloader.cpp:55) >>> V [jvm.dll+0x5fec96] InstanceKlass::initialize_impl+0x4e6 (instanceklass.cpp:1159) >>> V [jvm.dll+0x5fead6] InstanceKlass::initialize_impl+0x326 (instanceklass.cpp:1133) >>> V [jvm.dll+0xc5a633] Threads::initialize_java_lang_classes+0x93 (thread.cpp:3766) >>> V [jvm.dll+0xc57c32] Threads::create_vm+0xa12 (thread.cpp:4037) >>> >>> Can be reproduced by running JTREG tests: >>> compiler/aot/calls/fromAot >> >> Thanks for catching that! Will fix on next round. > >> Can be reproduced by running JTREG tests: >> compiler/aot/calls/fromAot > > I have tried reproducing this, but haven't yet succeeded. Here's how I'm running it from the jdk/test directory: > > `jtreg -jdk: ./hotspot/jtreg/compiler/aot/calls/fromAot` > > The response is this: > > Test results: no tests selected > Report written to /home/cjashfor/git-trees/jdk/test/JTreport/html/report.html > Results written to /home/cjashfor/git-trees/jdk/test/JTwork > The report's Results sections shows "Total 0" > > Any ideas? I'm new to running JTReg tests, so don't assume I know anything :) Did you try on x86? AOT is not supported on PPC64. ------------- PR: https://git.openjdk.java.net/jdk/pull/293 From rehn at openjdk.java.net Tue Sep 29 08:59:50 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 29 Sep 2020 08:59:50 GMT Subject: Integrated: 8238761: Asynchronous handshakes In-Reply-To: References: Message-ID: On Mon, 14 Sep 2020 13:00:59 GMT, Robbin Ehn wrote: > This patch implements asynchronous handshake, which changes how handshakes works by default. Asynchronous handshakes > are target only executed, which they may never be executed. (target may block on socket for the rest of VM lifetime) > Since we have several use-cases for them we can have many handshake pending. (should be very rare) To be able handle an > arbitrary amount of handshakes this patch adds a per JavaThread queue and heap allocated HandshakeOperations. It's a > singly linked list where you push/insert to the end and pop/get from the front. Inserts are done via CAS on first > pointer, no lock needed. Pops are done while holding the per handshake state lock, and when working on the first > pointer also CAS. The thread grabbing the handshake state lock for a JavaThread will pop and execute all handshake > operations matching the filter. The JavaThread itself uses no filter and any other thread uses the filter of everything > except asynchronous handshakes. In this initial change-set there is no need to do any other filtering. If needed > filtering can easily be exposed as a virtual method on the HandshakeClosure, but note that filtering causes handshake > operation to be done out-order. Since the filter determins who execute the operation and not the invoked method, there > is now only one method to call when handshaking one thread. Some comments about the changes: > - HandshakeClosure uses ThreadClosure, since it neat to use the same closure for both alla JavThreads do and Handshake > all threads. With heap allocating it cannot extends StackObj. I tested several ways to fix this, but those very much > worse then this. > > - I added a is_handshake_safe_for for checking if it's current thread is operating on itself or the handshaker of that > thread. > > - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not needing a JavaThread when executing as a > handshaker on a JavaThread, e.g. VM Thread can execute the handshake operation. > > - Added WB testing method. > > - Removed VM_HandshakeOneThread, the VM thread uses the same call path as direct handshakes did. > > - Changed the handshake semaphores to mutex to be able to handle deadlocks with lock ranking. > > - VM_HandshakeAllThreadsis still a VM operation, since we do support half of the threads being handshaked before a > safepoint and half of them after, in many handshake all operations. > > - ThreadInVMForHandshake do not need to do a fenced transistion since this is always a transistion from unsafe to unsafe. > > - Added NoSafepointVerifyer, we are thinking about supporting safepoints inside handshake, but it's not needed at the > moment. To make sure that gets well tested if added the NoSafepointVerifyer will raise eyebrows. > > - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due to lock rank. > > - Added filtered queue and gtest for it. > > Passes multiple t1-8 runs. > Been through some pre-reviwing. This pull request has now been integrated. Changeset: 6bddeb70 Author: Robbin Ehn URL: https://git.openjdk.java.net/jdk/commit/6bddeb70 Stats: 1126 lines in 24 files changed: 751 ins; 151 del; 224 mod 8238761: Asynchronous handshakes Reviewed-by: pchilanomate, dcubed, dholmes, coleenp, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/151 From mdoerr at openjdk.java.net Tue Sep 29 09:14:56 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 29 Sep 2020 09:14:56 GMT Subject: RFR: 8253740: [PPC64] Minor interpreter cleanup In-Reply-To: References: <9ENQcPBWCaewPezO3ObXyRtvAW2464wWrYmn6eBExYs=.714ecad9-fca8-40a3-9f41-72875f70e54f@github.com> Message-ID: On Tue, 29 Sep 2020 00:02:44 GMT, Coleen Phillimore wrote: >> Template interpreter on PPC64 can be cleaned up after JDK-8253540: >> unlock_object has a parameter check_for_exceptions which is now unused. >> >> In addition to that, restore_interpreter_state is redundant after >> call_VM(R4_ARG2, CAST_FROM_FN_PTR(address, InterpreterRuntime::member_name_arg_or_null) because it's already included >> in call_VM. >> https://bugs.openjdk.java.net/browse/JDK-8253740 > > This looks good but I also noticed that ppc and s390 pass an extra parameter to InterpreterRuntime::monitorenter() also. That's an interesting point: call_VM(monitorenter) uses check_for_exceptions=true on PPC64 and check_for_exceptions=false on s390. check_for_exceptions=true is default, so it's equivalent to omitting the explicit parameter. So PPC64 is implemented like x86 in this matter. Seems like we have optimized the exception check out for s390. This should be valid because monitorenter uses JRT_ENTRY_NO_ASYNC and doesn't throw any exception. Note that the JIT compiler's version uses assert(!HAS_PENDING_EXCEPTION, "Should have no exception here") in SharedRuntime::monitor_enter_helper. I think we could assert that in the interpreter's version and use check_for_exceptions=false on all platforms. It's probably not worth optimizing this, but maybe it'd be a good simplification wrt. complexity and readability of the gererated assembly code. But that's a bit out of scope for this issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/385 From aph at redhat.com Tue Sep 29 09:24:35 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 29 Sep 2020 10:24:35 +0100 Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10] In-Reply-To: References: <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com> Message-ID: <2f5093a5-2e1b-6ce9-3fc9-2c036261218f@redhat.com> On 28/09/2020 20:12, Bernhard Urban-Forster wrote: > The idea is that the naming should suggest that `r18` shouldn't be used on that particular platform. Same is true for > macOS, but the ABI docs suggest a different usage, hence we have something like that in our internal branch for macOS: > Suggestion: > > "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19", > Are you suggesting it should rather be something like this eventually? > Suggestion: > > "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19", This wrong. We can't use the register in Linux only, except in Linux-specific code of which there is almost none. It should be called r18_tls everywhere, as discussed. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at openjdk.java.net Tue Sep 29 09:24:46 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 29 Sep 2020 09:24:46 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 06:03:57 GMT, Ard Biesheuvel wrote: >> @ardbiesheuvel : Ard, could you please ack this patch? Thanks. > > Acked-by: Ard Biesheuvel > If this feature is not auto-enabled when the SHA3 hardware feature is there, we will have one failure for the following > test: test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java > 15 #-----testresult----- > 16 > description=file:/home/yangfei/github/jdk/test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java > 17 elapsed=31546 0:00:31.546 18 end=Mon Sep 21 10:27:58 CST 2020 > 19 environment=regtest > 20 execStatus=Failed. Execution failed: `main' threw exception: java.lang.AssertionError: Option 'UseSHA3Intrinsics' is > expected to have 'true' value Option 'UseSHA3Intrinsics' should be enabled by default > Any suggestions for this? I don't understand your question. There should be two acceptable results, either "Pass" or "Not supported". What else is possible? ------------- PR: https://git.openjdk.java.net/jdk/pull/207 From rkennke at openjdk.java.net Tue Sep 29 09:25:14 2020 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 29 Sep 2020 09:25:14 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v7] In-Reply-To: References: <0YZltgQGjDI8GW69qzCH_Kg3twWzN6dOyO5yBJ7B784=.b9fd2418-4218-4ff3-ba56-17e0a453796b@github.com> Message-ID: <0_s3c1jK1Q8ScyMZ2qDRnCwPxrXd5n84WK0FSG3LwsY=.e6684f06-86a5-430d-8f3d-7fb4eeb75809@github.com> On Tue, 29 Sep 2020 07:28:20 GMT, Per Liden wrote: >> FTR, this is the RFE to remove the oop verification from the oop_iterate framework: >> https://bugs.openjdk.java.net/browse/JDK-8237363 >> >> I really would like to get rid of it, but got push back because it made GCs have to duplicate the effort to provide >> verification. > > I've also has problems with this assert in the past, and I think that the underlying assumption of the assert is wrong. > I would not miss it. IMO it's ok to remove it. However, it can be argued that is_in() should not check for 'in committed memory' but 'in reserved space for heap', IOW 'is this a pointer into our heap memory region?'. Or maybe this would be CH::is_in_reserved() and we should change the assert to that? Also, IMO we should not do anything that may trip barriers on oop-iterators or similar GC-only paths. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From aph at redhat.com Tue Sep 29 09:26:31 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 29 Sep 2020 10:26:31 +0100 Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v10] In-Reply-To: References: <_pXOcN5hS77_QPTQPIix-QkJTiSsGCISZRG3sKJc6OU=.f0b1cd8a-8146-4b4f-b112-506521e07318@github.com> Message-ID: On 28/09/2020 20:12, Bernhard Urban-Forster wrote: > The idea is that the naming should suggest that `r18` shouldn't be used on that particular platform. Same is true for > macOS, but the ABI docs suggest a different usage, hence we have something like that in our internal branch for macOS: > Suggestion: > > "r17", NOT_R18_RESERVED("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19", > Are you suggesting it should rather be something like this eventually? > Suggestion: > > "r17", LINUX_ONLY("r18") WIN64_ONLY("rtls") MACOS_ONLY("rplatform"), "r19", This is wrong. We can't use the register in Linux either, except in Linux-specific code of which there is almost none. It's also a pointless complication. r18 should be called r18_tls everywhere, as discussed. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rehn at openjdk.java.net Tue Sep 29 09:40:37 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 29 Sep 2020 09:40:37 GMT Subject: RFR: 8212107: VMThread issues and cleanup [v8] In-Reply-To: References: <_kbecDop0xzsAlIGGtV6ZihNQ3YgDDLrwOureP0A7Yw=.020d61a2-c24d-4d4c-be73-c675f70d44d9@github.com> Message-ID: On Mon, 28 Sep 2020 20:11:56 GMT, Daniel D. Daugherty wrote: >> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed unused declartion - Claes > > I'm okay with leaving SafepointALot as you have it now > and leaving any future cleanup/refinement to a new RFE. Thanks all! ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From rehn at openjdk.java.net Tue Sep 29 09:40:38 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 29 Sep 2020 09:40:38 GMT Subject: Integrated: 8212107: VMThread issues and cleanup In-Reply-To: References: Message-ID: On Thu, 17 Sep 2020 19:58:02 GMT, Robbin Ehn wrote: > We simplify the vmThread by removing the queue and refactor the the main loop. > This solves the issues listed: > - It can create an extra safepoint directly after a safepoint. > - It's not safe for a non-JavaThread to add safepoint to queue while GC do oops do. > - The exposure of the vm operation is dangerous if it's a handshake. > - The code is a hornets nest with the repetition of checks and branches > > Passes t1-8, and a benchmark run. > > If you want a smaller diff the commits contains the incremental progress and each commit passed t1. This pull request has now been integrated. Changeset: 431338bc Author: Robbin Ehn URL: https://git.openjdk.java.net/jdk/commit/431338bc Stats: 480 lines in 8 files changed: 146 ins; 259 del; 75 mod 8212107: VMThread issues and cleanup Reviewed-by: shade, dcubed, coleenp, dholmes, redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/228 From eosterlund at openjdk.java.net Tue Sep 29 10:05:22 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 29 Sep 2020 10:05:22 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v7] In-Reply-To: <0_s3c1jK1Q8ScyMZ2qDRnCwPxrXd5n84WK0FSG3LwsY=.e6684f06-86a5-430d-8f3d-7fb4eeb75809@github.com> References: <0YZltgQGjDI8GW69qzCH_Kg3twWzN6dOyO5yBJ7B784=.b9fd2418-4218-4ff3-ba56-17e0a453796b@github.com> <0_s3c1jK1Q8ScyMZ2qDRnCwPxrXd5n84WK0FSG3LwsY=.e6684f06-86a5-430d-8f3d-7fb4eeb75809@github.com> Message-ID: On Tue, 29 Sep 2020 09:22:18 GMT, Roman Kennke wrote: >> I've also has problems with this assert in the past, and I think that the underlying assumption of the assert is wrong. >> I would not miss it. > > IMO it's ok to remove it. > However, it can be argued that is_in() should not check for 'in committed memory' but 'in reserved space for heap', IOW > 'is this a pointer into our heap memory region?'. Or maybe this would be CH::is_in_reserved() and we should change the > assert to that? Also, IMO we should not do anything that may trip barriers on oop-iterators or similar GC-only paths. Almost always, what you want to do, is to assert the validity of heap pointers, where they are expected to be valid (dereferenceable pointer to a not freed object). And then you actually do want to check that they are within the committed boundaries of the heap. Otherwise you have a bug. We don't want to make such reasonable assertions weaker, because we cater for asserts that want oops to look valid pretty much all the time, even when they are stale pointers from a previous cycle, pointing into freed memory (until it is fixed). And I would much rather cater for asserts with good underlying reasoning (the oop should actually be okay here or something is wrong), than to cater for asserts that seem to just have the wrong underlying reasoning, making everyone else suffer for it, and letting bugs slip past all the other asserts. The is_in_reserved check no longer exists. And I don't think I want to bring it back from the dead for this assert. Because I don't think the assert is right. The GCs already have their own verification code for roots (and the heap), that does this job, but much better. So I don't think it makes sense for the actual shared code oop iterator to go in and put constraints on what an invalid (not yet fixed up) stale pointer should and should not look like, for all GC implementations. Let the GC's own verification code take care of that. It has a much better idea about what a stale pointer should and should not look like. And I do agree that we should not use barriers in this kind of code path. I just didn't know what else to do here to make the assert happy. Sorry about that. Well now I know. I am going to delete it, unless anyone opposes that solution. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From akozlov at azul.com Tue Sep 29 10:50:11 2020 From: akozlov at azul.com (Anton Kozlov) Date: Tue, 29 Sep 2020 13:50:11 +0300 Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS In-Reply-To: References: <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com> Message-ID: <7128d909-fdd3-6ab4-5347-c262fa6216fe@azul.com> On 29.09.2020 09:53, Thomas St?fe wrote: > On AIX, to get information at commit/release time about the mapping, we > keep such a mapping-related management record internally (struct vmembk_t, > see > https://github.com/openjdk/jdk/blob/70b0fccf79ac7193b36c49aff0286fdc09bb370c/src/hotspot/os/aix/os_aix.cpp#L1834) > - and retrieve it whenever someone hands in a pointer allocated with > os::reserve_memory, see: > https://github.com/openjdk/jdk/blob/70b0fccf79ac7193b36c49aff0286fdc09bb370c/src/hotspot/os/aix/os_aix.cpp#L2372 > . This code stems from before SAPs involvement in OpenJDK, when we had no > way to change code upstream, and allowed us to hide AIX complications from > upper layers. > > This is certainly not the best solution, but it is something you could do > too for MacOS. That would mean you do not have to change the uncommit API. > > Uncommit has nothing to do with the exec state of the memory. I should not > have to know at uncommit time. Like malloc and free: at free(), I should > not have to know the size of the allocation established with malloc. The > information should be already there in the lower layer. I should not have > to provide it. Thanks for pointing, I'll take a deeper look. In general, I'm trying to avoid such kind of bookkeeping, because it is overhead (in CPU and memory). An API change could render this overhead to nothing, and I think this is a good thing even at cost of more complicated API (not saying bad API :). I'm not sure we can always avoid complicated API. It abstracts different operating systems and also needs to do that efficiently. I find malloc/free analogy is useful. Free don't need the size parameter because it is possible to rather efficiently store (small overhead) the size beside the allocated block. But I'm not sure our interface needs to provide the same level of generality. All our users are nearby and wecan always fix them or interface. > Of course, a better solution would be a cleanly defined interface, with a > Mapping class which defines properties of a mapping, well documented and > tested :/ but thats a large effort. The small cleanups that are done (most > recently Stefans removal of MAP_FIXED) are a step in that direction. Agree, I think it possible to do Mapping so it would have minimal runtime overhead, so probably it will emerge sometime. >> Do you think it will be a bad thing? I.e. to allow exec commit only in >> exec reserved mapping? >> > Well, I played with the thought of placing code fragments in Metaspace. > Just an idea now, but being able to set exec permission on a range of > memory would make matters a lot easier. As would not having to care about > exec state of the underlying memory when uncommitting the memory. I would suggest a metaspace-code section beside here :) >> To continue the trend of the cleanup and to highlight the difference, it >> is possible >> to create specialized code_reserve/commit/uncommit that will be >> implemented with usual reserve/... on all platforms >> except macOS, and latter to use MAP_JIT in the implementation. > > > Not totally opposed to this, but how is this different from passing a > parameter? > > Which brings me to another thing, if we add exec to os::reserve_memory, why > not to os::reserve_aligned, os::attempt_reserve_at and > os::reserve_memory_special? The questions are related, I think. Semantically the new set of functions (code_reserve,...) will not be a big difference. But the specialized function would allow defining a clean API that is tied to use-case. So there will be no code_reserve_at, code_attemp_reserve,.. > But what is the contract here for uncommit (and commit actually)? > > It looks like I can change exec permission per page in a mapping > (regardless of its commit state) and it may be able to do this on commit() > - but not on MacOS - but on uncommit, it is just a "remind me again what > flag I used for this mapping" kind of thing. What happens when I > accidentally get it wrong, or there is a mismatch? Something the OS or the > hotspot OS layer should know already. Yes, this is a good point. I don't have an immediate answer. Mapping class could solve this. To some extend, code_reserve and friends could also do that, because it is harder to confuse code_{reserve,commit,uncommit} functions and general ones. >> Or I could stick with exec parameter. What do you think? >> >> > I think we agree that an overhaul would be good, but I do not want to block > you either. > > I'd ask you to investigate first if the "exec" information can somehow be > obtained within os_bsd.cpp. Either by asking the platform (maybe there is > an api to get the flags a mapping had been established with?). Or, failing > that, by considering a similar solution as I have outlined above, like what > we did on AIX (could be done better than I did, with less code). Storing > mapping related information in a record and somehow keep it at OS level, > retrieving it as needed. > > That would reduce the outside API changes by removing the need to pass in > exec to uncommit. Which really feels wrong to me. > > (For the future, a better solution would be an os:: level class for > mappings. Maybe we should just develop a new clean interface beside the old > one and start migrating code to the new one.) > > Cheers & thanks for your patience, Excuse me for the long message. I'll take a look is it possible to retrieve the information in runtime and look for the options. I think it should be there something, but it depends on the possible overhead. Thanks, Anton From kim.barrett at oracle.com Tue Sep 29 10:51:15 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 29 Sep 2020 06:51:15 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> Message-ID: > On Sep 28, 2020, at 11:13 AM, Eric Liu wrote: > > Hi, > > Thanks for looking at this. > > For gcc-10, it's hard to make 'strncpy' all right with asan enabled (approaches we talked previous don't work). > I'm trying to find a better way to avoid using compile pragma. I suppose it would be better to use 'memcpy' > to replace 'strncpy'. > > > Thanks, > Eric I don't think using memory functions in place of string functions for string manipulation is really an improvement. I did a bit of experimenting. With gcc10.2, and using the --enable-asan configure option, we get a -Wstringop-truncation warning in CompilerCounters::set_current_method, even after careful adjustment of the code to use the documented idiom for avoiding that warning. I initially wondered whether this might be only in fastdebug builds, where we also define _FORTIFY_SOURCE=2. The asan faq https://github.com/google/sanitizers/wiki/AddressSanitizer#faq says asan doesn't work well with _FORTIFY_SOURCE. But the same warning occurs in a release build, where we aren't defining _FORTIFY_SOURCE. At this point all I can conclude is that --enable-asan (i.e. -fsanitize=address) is simply incompatible with -Wstringop-truncation, at least through gcc10. That seems like a bug that someone should report. (Might be same as or related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650) We don't normally build with -fsanitize=address; that's something that someone might want to turn on sometimes for testing or debugging, but I don't think we're planning to have it always on, even in debug builds. Since it seems to be incompatible with various other options that we *do* normally use, I think the way to allow --enable-asan to be (possibly) usable is in the build system at configure time. That is, the --enable-asan configure option should, in addition to adding -fsanitize=address, also (1) disable -Wstringop-truncation and (2) disable the defining of _FORTIFY_SOURCE in fastdebug builds. It looks like making those changes involves conditionalizing their addition/removal using ${ASAN_ENABLED}. Scattering pragmas for disabling -Wstringop-truncation doesn't cut it. From ihse at openjdk.java.net Tue Sep 29 11:16:06 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 29 Sep 2020 11:16:06 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v11] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 19:53:37 GMT, Monica Beckwith wrote: >> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: > > r18 only on Linux Build changes look good. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/212 From kim.barrett at oracle.com Tue Sep 29 11:17:50 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 29 Sep 2020 07:17:50 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> Message-ID: <2E08727F-E790-4B7F-82EC-FAE9031C7E16@oracle.com> > On Sep 29, 2020, at 6:51 AM, Kim Barrett wrote: > >> On Sep 28, 2020, at 11:13 AM, Eric Liu wrote: >> >> Hi, >> >> Thanks for looking at this. >> >> For gcc-10, it's hard to make 'strncpy' all right with asan enabled (approaches we talked previous don't work). >> I'm trying to find a better way to avoid using compile pragma. I suppose it would be better to use 'memcpy' >> to replace 'strncpy'. >> >> >> Thanks, >> Eric > > [?] > At this point all I can conclude is that --enable-asan (i.e. > -fsanitize=address) is simply incompatible with -Wstringop-truncation, at > least through gcc10. That seems like a bug that someone should report. > (Might be same as or related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650) > > [?] > > Since it seems to be incompatible with various other options that we *do* > normally use, I think the way to allow --enable-asan to be (possibly) usable > is in the build system at configure time. That is, the --enable-asan > configure option should, in addition to adding -fsanitize=address, also (1) > disable -Wstringop-truncation and (2) disable the defining of > _FORTIFY_SOURCE in fastdebug builds. It looks like making those changes > involves conditionalizing their addition/removal using ${ASAN_ENABLED}. > > Scattering pragmas for disabling -Wstringop-truncation doesn't cut it. Another option might be to solve https://bugs.openjdk.java.net/browse/JDK-8232187 From thomas.stuefe at gmail.com Tue Sep 29 11:20:47 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 29 Sep 2020 13:20:47 +0200 Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS In-Reply-To: <7128d909-fdd3-6ab4-5347-c262fa6216fe@azul.com> References: <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com> <7128d909-fdd3-6ab4-5347-c262fa6216fe@azul.com> Message-ID: Hi Anton, Excuse me for the long message. I'll take a look is it possible to retrieve > the information in runtime and look for the options. just another thought, in uncommit, if there is no way to poll the creation flag from the OS, you could just first try mmap(MAP_FIXED, MAP_NORESERVE); if that fails due to EINVAL, try the madvise route. Cheers, Thomas > From github.com+670087+jrziviani at openjdk.java.net Tue Sep 29 11:21:20 2020 From: github.com+670087+jrziviani at openjdk.java.net (Ziviani) Date: Tue, 29 Sep 2020 11:21:20 GMT Subject: RFR: 8253565: PPC: Remove duplicated if condition in vm_version_ppc.cpp Message-ID: This is a very small change. There're two `if (UseRTMLocking) {` conditions, one just after the other. This code simply merge them. https://bugs.openjdk.java.net/browse/JDK-8253565 ------------- Commit messages: - 8253565: Remove duplicated if condition in vm_version_ppc.cpp Changes: https://git.openjdk.java.net/jdk/pull/338/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=338&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253565 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/338.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/338/head:pull/338 PR: https://git.openjdk.java.net/jdk/pull/338 From mdoerr at openjdk.java.net Tue Sep 29 11:21:20 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 29 Sep 2020 11:21:20 GMT Subject: RFR: 8253565: PPC: Remove duplicated if condition in vm_version_ppc.cpp In-Reply-To: References: Message-ID: <1s37Dkf4xKhnWYXTm4zBtgIOlU8ZNYgmev9WKU1WseU=.548e7e01-93ab-435c-b95a-f9790218ab5e@github.com> On Thu, 24 Sep 2020 16:38:31 GMT, Ziviani wrote: > This is a very small change. There're two `if (UseRTMLocking) {` conditions, one just after the other. This code simply > merge them. > https://bugs.openjdk.java.net/browse/JDK-8253565 Looks good and trivial. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/338 From kim.barrett at oracle.com Tue Sep 29 11:22:48 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 29 Sep 2020 07:22:48 -0400 Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <751EE42A-4A0F-45EB-88EA-FD7A2B068CD2@oracle.com> > On Sep 29, 2020, at 3:14 AM, Matthias Baesken wrote: > > On Fri, 25 Sep 2020 06:06:31 GMT, Kim Barrett wrote: > >>> Please review this small patch to enable the OSX build using Xcode 12.0. >>> >>> Thanks, >>> Paul >> >> src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129: >> >>> 127: NSColor* result = nil; >>> 128: >>> 129: if (colorIndex < ((useAppleColor) ? sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS : >>> java_awt_SystemColor_NUM_COLORS)) { >> >> This looks like a plain old bug fix, nothing really to do with the compiler upgrade. The new compiler presumably just >> has a new warning that brought attention to the problem. As such, I don't think it belongs in a PR that's about issues >> related to the compiler upgrade. Someone might want to backport just this fix, for example. > > Hello Kim, Paul - so should we open a separate bug for the > src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m issue because it might be a general problem just > uncovered by the new compiler ? Paul , do you want to do this ? Or should I open a bug and post a separate change for > the useAppleColor check in CSystemColors.m ? I think so. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/348 From kim.barrett at oracle.com Tue Sep 29 12:02:11 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 29 Sep 2020 08:02:11 -0400 Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: <5q0sckv5JjyV1HNZMX1f1eG2dwCjfLTejO8pfH7tS5s=.f1a8c3d5-a436-41bd-9d9f-68f0103539a1@github.com> Message-ID: <20D716A9-C5BC-47A3-ADB4-CBA732A94DF6@oracle.com> > On Sep 29, 2020, at 3:59 AM, Matthias Baesken wrote: > > On Fri, 25 Sep 2020 02:23:07 GMT, David Holmes wrote: > >>> Please review this small patch to enable the OSX build using Xcode 12.0. >>> >>> Thanks, >>> Paul >> >> src/hotspot/share/runtime/sharedRuntime.cpp line 2851: >> >>> 2849: if (buf != NULL) { >>> 2850: CodeBuffer buffer(buf); >>> 2851: short locs_buf[80]; >> >> This code is just weird. Why is the locs_buf array not declared to be the desired type? If the compiler rejects double >> because it isn't relocInfo* then why does it accept short? And if it accepts short will it accept int or long long or >> int64_t? Using int64_t would be a clearer change. Though semantically this code is awful. :( Should it be intptr_t ? > > Currently we have in the existing code various kind of buffers passed into initialize_shared_locs that compile nicely > on all supported compilers and on Xcode 12 as well ,see > > c1_Compilation.cpp > > 326 char* locs_buffer = NEW_RESOURCE_ARRAY(char, locs_buffer_size); > 327 code->insts()->initialize_shared_locs((relocInfo*)locs_buffer, > > sharedRuntime.cpp > > 2681 CodeBuffer buffer(buf); > 2682 short buffer_locs[20]; > 2683 buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, > 2684 sizeof(buffer_locs)/sizeof(relocInfo)); > > So probably using short would be consistent to what we do already in the coding at another place (looking into > relocInfo it would be probably better to use unsigned short or to typedef unsigned short in the relocInfo class > and use the typedef). That?s *not* consistent, because of buffer alignment. The call to NEW_RESOURCE_ARRAY is going to return a pointer to memory that is 2*word aligned. (Interesting, possibly a 32/64 bit ?bug? here.) The existing code in sharedRuntime.cpp is allocating double-aligned. iniitalize_shared_locs wants a HeapWordSize-aligned buffer, and adjusts the pointer it uses accordingly. (I think with existing code it could just make the alignment of the buffer a precondition, but I haven?t looked at all callers.) Changing the declaration in sharedRuntime.cpp to short[] reduces the alignment requirement for the array, possibly requiring alignment adjustment (and hence size reduction) by initialize_shared_locs. Since initialize_shared_locs specifically adjusts the alignment, some downstream use of the buffer probably actually cares. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/348 From stefank at openjdk.java.net Tue Sep 29 12:05:57 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 29 Sep 2020 12:05:57 GMT Subject: Integrated: 8253640: Make MEMFLAGS an enum class In-Reply-To: References: Message-ID: <_74ttbM9xIDrlv_VGxtyEdCNcchQETs2byyRXyActg0=.fdd9e60b-4cff-4206-8148-997056e49490@github.com> On Mon, 28 Sep 2020 11:49:37 GMT, Stefan Karlsson wrote: > I'd like to propose that we make MEMFLAGS an enum class, to prevent them from being implicitly converted to integers. > > I've been refactoring code that uses MEMFLAGS and have found that the functions often take integers and/or use default > values. Because of this the compiler won't always tell you if you mess up the order. If we make the MEMFLAGS more type > safe, the compiler will complain immediately if you send in the arguments in the wrong order. Changes in the patch: > > 1) G1 is the only code that uses MemoryType instead of the MEMFLAGS typedef. I changed those to make the code base > uniform w.r.t. this. 2) Added some code generation so that we still can use mtGC, and don't have to write > MEMFLAGS::mtGC. 3) Some stricter checks around the values stored in MEMFLAGS variables. There was a masking of 0xFF > that I removed in favor of an assert. Need to run some more extensive testing see if there was a need for this masking. > 4) Removed unused by_index > Notes: > 1) I didn't specify the underlying type of the enum, but it's clear for its usage that code will start to break if the > value range is larger than 8 bits. Maybe something to clean up in a separate patch? 2) The code sometimes talks about > "flags" and sometimes about "memory type", it's quite clear that the name changed, but the comments and names didn't > get cleaned up accordingly. This pull request has now been integrated. Changeset: 3ed960ec Author: Stefan Karlsson URL: https://git.openjdk.java.net/jdk/commit/3ed960ec Stats: 51 lines in 8 files changed: 17 ins; 13 del; 21 mod 8253640: Make MEMFLAGS an enum class Reviewed-by: stuefe, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/378 From david.holmes at oracle.com Tue Sep 29 12:22:38 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Sep 2020 22:22:38 +1000 Subject: RFR: 8253740: [PPC64] Minor interpreter cleanup In-Reply-To: References: <9ENQcPBWCaewPezO3ObXyRtvAW2464wWrYmn6eBExYs=.714ecad9-fca8-40a3-9f41-72875f70e54f@github.com> Message-ID: Hi Martin, On 29/09/2020 7:14 pm, Martin Doerr wrote: > On Tue, 29 Sep 2020 00:02:44 GMT, Coleen Phillimore wrote: > >>> Template interpreter on PPC64 can be cleaned up after JDK-8253540: >>> unlock_object has a parameter check_for_exceptions which is now unused. >>> >>> In addition to that, restore_interpreter_state is redundant after >>> call_VM(R4_ARG2, CAST_FROM_FN_PTR(address, InterpreterRuntime::member_name_arg_or_null) because it's already included >>> in call_VM. >>> https://bugs.openjdk.java.net/browse/JDK-8253740 >> >> This looks good but I also noticed that ppc and s390 pass an extra parameter to InterpreterRuntime::monitorenter() also. > > That's an interesting point: call_VM(monitorenter) uses check_for_exceptions=true on PPC64 and > check_for_exceptions=false on s390. check_for_exceptions=true is default, so it's equivalent to omitting the explicit > parameter. So PPC64 is implemented like x86 in this matter. Seems like we have optimized the exception check out for > s390. This should be valid because monitorenter uses JRT_ENTRY_NO_ASYNC and doesn't throw any exception. Note that the > JIT compiler's version uses assert(!HAS_PENDING_EXCEPTION, "Should have no exception here") in > SharedRuntime::monitor_enter_helper. I think we could assert that in the interpreter's version and use > check_for_exceptions=false on all platforms. It's probably not worth optimizing this, but maybe it'd be a good > simplification wrt. complexity and readability of the gererated assembly code. But that's a bit out of scope for this > issue. It is not true that monitorenter can't throw exceptions. Contended monitorenter posts a JVMTI event and the event callback can execute Java code that triggers an exception. The "no async" just means the callVM won't actively looking for a pending-async to install, but there could already be an exception in flight (async or otherwise). Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/385 > From stefank at openjdk.java.net Tue Sep 29 12:42:49 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 29 Sep 2020 12:42:49 GMT Subject: RFR: 8247912: Make narrowOop a scoped enum [v2] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 13:43:54 GMT, Kim Barrett wrote: >> Please review this change to the type narrowOop from a typedef for juint to a >> scoped enum with uint32_t as the representation type. This provides stronger >> type checking when using this type. >> >> For the most part this was fairly straightforward, and the patch size is >> relatively small. The implementation of some existing CompressedOops >> "primitives" required adjustment. An explicit conversion to narrowOop was >> added, with casts change to use it. There were a few places that were type >> punning and needed explicit conversions,, mostly in platform-specific assembly >> support. >> >> There are a couple of lingering problems. >> >> Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass >> as a narrowOop. I adjusted the code to accommodate the narrowOop change, but >> this probably ought to be done differently. >> >> There are a couple of `(narrowOop)` casts remaining in s390.ad. I'm not sure >> whether these can be safely converted to CompressedOops::narrow_oop_cast. >> >> There might still be some casts from narrowOop to an integral type. Those are >> hard to find in our cast-happy code base. >> >> Testing: >> tier1-6 for Oracle supported platforms. >> Build fastdebug linux-ppc64le and linux-s390x. > > Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: > > - improve assertion > - remove NarrowType src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 179: > 177: // Move narrow OOP > 178: narrowOop noop = CompressedOops::encode((oop)o); > 179: uint32_t n = CompressedOops::narrow_oop_value(noop); I wonder if we should simply create an overload for oop so that this (and the other places) could be changed to: n = CompressedOops::narrow_oop_value((oop)o);``` src/hotspot/cpu/ppc/relocInfo_ppc.cpp line 62: > 60: narrowOop no = (type() == relocInfo::oop_type) ? > 61: CompressedOops::encode((oop)x) : > 62: // FIXME: Cheating! Treating narrowKlass as a narrowOop. I think we try to avoid adding new FIXMES and TODOS to the code. Maybe create a JBS entry instead? ------------- PR: https://git.openjdk.java.net/jdk/pull/273 From rkennke at openjdk.java.net Tue Sep 29 12:52:05 2020 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 29 Sep 2020 12:52:05 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v7] In-Reply-To: References: <0YZltgQGjDI8GW69qzCH_Kg3twWzN6dOyO5yBJ7B784=.b9fd2418-4218-4ff3-ba56-17e0a453796b@github.com> <0_s3c1jK1Q8ScyMZ2qDRnCwPxrXd5n84WK0FSG3LwsY=.e6684f06-86a5-430d-8f3d-7fb4eeb75809@github.com> Message-ID: On Tue, 29 Sep 2020 10:02:16 GMT, Erik ?sterlund wrote: >> IMO it's ok to remove it. >> However, it can be argued that is_in() should not check for 'in committed memory' but 'in reserved space for heap', IOW >> 'is this a pointer into our heap memory region?'. Or maybe this would be CH::is_in_reserved() and we should change the >> assert to that? Also, IMO we should not do anything that may trip barriers on oop-iterators or similar GC-only paths. > > Almost always, what you want to do, is to assert the validity of heap pointers, where they are expected to be valid > (dereferenceable pointer to a not freed object). And then you actually do want to check that they are within the > committed boundaries of the heap. Otherwise you have a bug. We don't want to make such reasonable assertions weaker, > because we cater for asserts that want oops to look valid pretty much all the time, even when they are stale pointers > from a previous cycle, pointing into freed memory (until it is fixed). And I would much rather cater for asserts with > good underlying reasoning (the oop should actually be okay here or something is wrong), than to cater for asserts that > seem to just have the wrong underlying reasoning, making everyone else suffer for it, and letting bugs slip past all > the other asserts. The is_in_reserved check no longer exists. And I don't think I want to bring it back from the dead > for this assert. Because I don't think the assert is right. The GCs already have their own verification code for roots > (and the heap), that does this job, but much better. So I don't think it makes sense for the actual shared code oop > iterator to go in and put constraints on what an invalid (not yet fixed up) stale pointer should and should not look > like, for all GC implementations. Let the GC's own verification code take care of that. It has a much better idea about > what a stale pointer should and should not look like. And I do agree that we should not use barriers in this kind of > code path. I just didn't know what else to do here to make the assert happy. Sorry about that. Well now I know. I am > going to delete it, unless anyone opposes that solution. It's ok for me. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From mdoerr at openjdk.java.net Tue Sep 29 12:52:48 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 29 Sep 2020 12:52:48 GMT Subject: RFR: 8253740: [PPC64] Minor interpreter cleanup In-Reply-To: References: <9ENQcPBWCaewPezO3ObXyRtvAW2464wWrYmn6eBExYs=.714ecad9-fca8-40a3-9f41-72875f70e54f@github.com> Message-ID: On Tue, 29 Sep 2020 09:12:37 GMT, Martin Doerr wrote: >> This looks good but I also noticed that ppc and s390 pass an extra parameter to InterpreterRuntime::monitorenter() also. > > That's an interesting point: call_VM(monitorenter) uses check_for_exceptions=true on PPC64 and > check_for_exceptions=false on s390. check_for_exceptions=true is default, so it's equivalent to omitting the explicit > parameter. So PPC64 is implemented like x86 in this matter. Seems like we have optimized the exception check out for > s390. This should be valid because monitorenter uses JRT_ENTRY_NO_ASYNC and doesn't throw any exception. Note that the > JIT compiler's version uses assert(!HAS_PENDING_EXCEPTION, "Should have no exception here") in > SharedRuntime::monitor_enter_helper. (monitor_enter_helper uses the CHECK macro which does the check for an exception, > but this looks like a bug.) I think we could assert that in the interpreter's version and use > check_for_exceptions=false on all platforms. It's probably not worth optimizing this, but maybe it'd be a good > simplification wrt. complexity and readability of the gererated assembly code. At least, it'd be nice to bring the > interpreter and the compiler version closer together. But that's a bit out of scope for this issue. Hi David, thanks for reminding me of JVMTI event callbacks. So we need to check s390 code. And in SharedRuntime::monitor_enter_helper it doesn't make sense to use CHECK macro and then assert(!HAS_PENDING_EXCEPTION, "Should have no exception here"). But this is unrelated to this PPC64 cleanup change. ------------- PR: https://git.openjdk.java.net/jdk/pull/385 From zgu at openjdk.java.net Tue Sep 29 13:16:34 2020 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 29 Sep 2020 13:16:34 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6] In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 12:00:40 GMT, Albert Mingkun Yang wrote: >>> Thank you for the comments and diagrams; they make the code much more digestible. From that diagram, I get the >>> impression that the watermark is associated with stack pointer, so it should be 1:1 relation, but `class Thread` >>> contains multiple watermarks, `StackWatermarks _stack_watermarks;`. I think some high level description on the relation >>> between the thread and a list of watermarks belong to that thread could be beneficial. >> >> I added some further comments explaining this. >> >>> > The first time it reaches past the last frame it will report true, and the second time it will report false. >>> >>> Why so? As I see it, once a stream becomes "done", it stays in that state forever. Am I missing sth? >>> >>> ``` >>> inline bool StackFrameStream::is_done() { >>> return (_is_done) ? true : (_is_done = _fr.is_first_frame(), false); >>> } >>> ``` >> >> When you step into the last frame of the iteration (first frame in the stack), the first time you ask is_done() it will >> report false, the next time it will report true, despite still being in the same frame. Therefore, the is_done() >> function is not idempotent, as I need it to be. > > I see; thank you for the explanation. Hi Erik, I have been playing with this patch for past a few days. Great work! I found that this patch seems to break an early assumption. We have a comment in JavaThread::exit() says: 
  // We need to cache the thread name for logging purposes below as once
  // we have called on_thread_detach this thread must not access any oops.
Then in method : 

void Threads::remove(JavaThread* p, bool is_daemon)  {
 ...
  BarrierSet::barrier_set()->on_thread_detach(p);

  // Extra scope needed for Thread_lock, so we can check
  // that we do not remove thread without safepoint code notice
  { MonitorLocker ml(Threads_lock);
..
}
It calls barrier's on_thread_detach(), acquires Threads_lock. The lock acquisition triggers stack processing, that potential accesses oops. 

V  [libjvm.so+0x10c6f5e]  StackWatermark::start_processing()+0x6a
V  [libjvm.so+0x10c77e8]  StackWatermarkSet::start_processing(JavaThread*, StackWatermarkKind)+0x82
V  [libjvm.so+0xfd7757]  SafepointMechanism::process(JavaThread*)+0x37
V  [libjvm.so+0xfd796b]  SafepointMechanism::process_if_requested_slow(JavaThread*)+0x1d
V  [libjvm.so+0x4b3683]  SafepointMechanism::process_if_requested(JavaThread*)+0x2b
V  [libjvm.so+0xe87f0d]  ThreadBlockInVMWithDeadlockCheck::~ThreadBlockInVMWithDeadlockCheck()+0x5f
V  [libjvm.so+0xe86700]  Mutex::lock_contended(Thread*)+0x12c
V  [libjvm.so+0xe867d8]  Mutex::lock(Thread*)+0x96
V  [libjvm.so+0xe86823]  Mutex::lock()+0x23
V  [libjvm.so+0x29b4bc]  MutexLocker::MutexLocker(Mutex*, Mutex::SafepointCheckFlag)+0xe2
V  [libjvm.so+0x29b533]  MonitorLocker::MonitorLocker(Monitor*, Mutex::SafepointCheckFlag)+0x29
V  [libjvm.so+0x119f2ce]  Threads::remove(JavaThread*, bool)+0x56
V  [libjvm.so+0x1198a2b]  JavaThread::exit(bool, JavaThread::ExitType)+0x905
V  [libjvm.so+0x1197fde]  JavaThread::post_run()+0x22
V  [libjvm.so+0x1193eae]  Thread::call_run()+0x230
V  [libjvm.so+0xef3e38]  thread_native_entry(Thread*)+0x1e4
This is a problem for Shenandoah, as it flushes SATB buffers during on_thread_detach() and does not expect to see any more SATB traffic. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From hohensee at amazon.com Tue Sep 29 13:46:27 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 29 Sep 2020 13:46:27 +0000 Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) Message-ID: <8D7E0A19-32C7-47CC-890D-1670A5A02D5E@amazon.com> Hi, Matthias, Kim. No problem opening a separate issue to fix CSystemColors.m. Thanks, Paul ?On 9/29/20, 4:23 AM, "hotspot-dev on behalf of Kim Barrett" wrote: > On Sep 29, 2020, at 3:14 AM, Matthias Baesken wrote: > > On Fri, 25 Sep 2020 06:06:31 GMT, Kim Barrett wrote: > >>> Please review this small patch to enable the OSX build using Xcode 12.0. >>> >>> Thanks, >>> Paul >> >> src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129: >> >>> 127: NSColor* result = nil; >>> 128: >>> 129: if (colorIndex < ((useAppleColor) ? sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS : >>> java_awt_SystemColor_NUM_COLORS)) { >> >> This looks like a plain old bug fix, nothing really to do with the compiler upgrade. The new compiler presumably just >> has a new warning that brought attention to the problem. As such, I don't think it belongs in a PR that's about issues >> related to the compiler upgrade. Someone might want to backport just this fix, for example. > > Hello Kim, Paul - so should we open a separate bug for the > src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m issue because it might be a general problem just > uncovered by the new compiler ? Paul , do you want to do this ? Or should I open a bug and post a separate change for > the useAppleColor check in CSystemColors.m ? I think so. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/348 From rrich at openjdk.java.net Tue Sep 29 13:56:47 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 29 Sep 2020 13:56:47 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v4] In-Reply-To: References: Message-ID: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. Richard Reingruber has updated the pull request incrementally with five additional commits since the last revision: - EATests.java: bugfix to prevent ObjectCollectedException - Better encapsulation of JvmtiDeferredUpdates. Moved jvmtiDeferredLocalVariableSet to jvmtiDeferredUpdates.hpp - EscapeBarrier: moved method comments. - Shuffled parameters of EscapeBarrier constructors to better match each other - Moved class EscapeBarrier and class JvmtiDeferredUpdates into dedicated files. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/119/files - new: https://git.openjdk.java.net/jdk/pull/119/files/5bf631ba..c33cc4e8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=02-03 Stats: 1385 lines in 18 files changed: 777 ins; 586 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119 PR: https://git.openjdk.java.net/jdk/pull/119 From rrich at openjdk.java.net Tue Sep 29 13:59:51 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 29 Sep 2020 13:59:51 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v3] In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 12:28:13 GMT, Richard Reingruber wrote: >> The minor updates in response to my comments are fine. >> >> The more major updates ... I can't really comment on. > >> >> >> The minor updates in response to my comments are fine. >> >> The more major updates ... I can't really comment on. > > Thanks for looking at the changes and for giving feedback. Hi Serguei, thanks for providing feedback! I've pushed the changes based on it now but I have not yet merged master again. This needs a little work... Please find my replies to your comments below. Thanks, Richard. > Could you consider to place the classes EscapeBarrier and JvmtiDeferredUpdates > into theyr own .hpp/.cpp files? The class JvmtiDeferredUpdates would be better > to put into the folder 'prims' then. Done. In addition I moved preexisting class jvmtiDeferredLocalVariableSet and class jvmtiDeferredLocalVariable from runtime/vframe_hp.hpp to prims/jvmtiDeferredUpdates.hpp. Please let me know if not ok. > src/hotspot/share/opto/macro.cpp: > > ``` > @@ -1091,11 +1091,11 @@ > bool PhaseMacroExpand::eliminate_allocate_node(AllocateNode *alloc) { > // Don't do scalar replacement if the frame can be popped by JVMTI: > // if reallocation fails during deoptimization we'll pop all > // interpreter frames for this compiled frame and that won't play > // nice with JVMTI popframe. > - if (!EliminateAllocations || JvmtiExport::can_pop_frame() || !alloc->_is_non_escaping) { > + if (!EliminateAllocations || !alloc->_is_non_escaping) { > return false; > } > ``` > > I wonder if the comment is still correct after you removed the check for JvmtiExport::can_pop_frame(). Good catch. I fixed it previously with https://github.com/openjdk/jdk/pull/119/commits/18dd54b4e6f17ca723e4ae1a1e8dc57e81878dd3 > src/hotspot/share/runtime/deoptimization.hpp: > > ``` > + EscapeBarrier(JavaThread* calling_thread, JavaThread* deoptee_thread, bool barrier_active) > + : _calling_thread(calling_thread), _deoptee_thread(deoptee_thread), > + _barrier_active(barrier_active && (JVMCI_ONLY(UseJVMCICompiler) NOT_JVMCI(false) > + COMPILER2_PRESENT(|| DoEscapeAnalysis))) > . . . . . . . . . > + > + // Revert ea based optimizations for all java threads > + EscapeBarrier(JavaThread* calling_thread, bool barrier_active) > + : _calling_thread(calling_thread), _deoptee_thread(NULL), > ``` > > Nit: would better to make the parameter deoptee_thread to be the 3rd to better mach the seconf constructor. I have shuffled the parameters and moved barrier_active at first position. Would that be ok? > > ``` > + bool all_threads() const { return _deoptee_thread == NULL; } // Should revert optimizations for all > threads. + bool self_deopt() const { return _calling_thread == _deoptee_thread; } // Current thread deoptimizes > its own objects. + bool barrier_active() const { return _barrier_active; } // Inactive barriers are > created if no local objects can escape. ``` > > I'd suggest to put comments in a line before function definitions as it is done for other declarations/definitions. Done. // Note that there are quite a few locations with the comment on the same line ;) > src/hotspot/share/runtime/deoptimization.cpp: > > ``` > @@ -349,12 +408,12 @@ > > // Now that the vframeArray has been created if we have any deferred local writes > // added by jvmti then we can free up that structure as the data is now in the > // vframeArray > > - if (thread->deferred_locals() != NULL) { > - GrowableArray* list = thread->deferred_locals(); > + if (JvmtiDeferredUpdates::deferred_locals(thread) != NULL) { > + GrowableArray* list = JvmtiDeferredUpdates::deferred_locals(thread); > int i = 0; > do { > // Because of inlining we could have multiple vframes for a single frame > // and several of the vframes could have deferred writes. Find them all. > if (list->at(i)->id() == array->original().id()) { > > @@ -365,13 +424,14 @@ > } else { > i++; > } > } while ( i < list->length() ); > if (list->length() == 0) { > - thread->set_deferred_locals(NULL); > - // free the list and elements back to C heap. > - delete list; > + JvmtiDeferredUpdates* updates = thread->deferred_updates(); > + thread->set_deferred_updates(NULL); > + // free deferred updates. > + delete updates; > } > ``` > > It is not clear why the 'list' is not deleted anymore. If it is intentional then could you, please, add a comment with > an explanation? 'list' is now embedded in JvmtiDeferredUpdates. It es deleted as part of the JvmtiDeferredUpdates instance when there are no more deferred updates. class JvmtiDeferredUpdates : public CHeapObj { [...] // Deferred updates of locals, expressions, and monitors GrowableArray _deferred_locals_updates; [...] }; I introduced JvmtiDeferredUpdates because this patch introduces a new type of deferred update: _relock_count_after_wait. I tried to improve the encapsulation of class JvmtiDeferredUpdates and simplified the location you are referring to. So when is memory for deferred updates freed? (A) Deferred local variable updates are deleted when the compiled target frame is replaced with corresponding interpreter frames. See JvmtiDeferredUpdates::delete_updates_for_frame(). (B) A thread's JvmtiDeferredUpdates instance is deleted if all updates where delivered. All updates where delivered when JvmtiDeferredUpdates::count() returns 0. This is checked whenever updates are delivered. See call sites in JvmtiDeferredUpdates::delete_updates_for_frame() and JvmtiDeferredUpdates::get_and_reset_relock_count_after_wait(). (C) Besides (B) a thread's JvmtiDeferredUpdates instance is also deleted when the thread is destroyed. All not yet delivered updates are deleted then too. See JavaThread::~JavaThread() and JvmtiDeferredUpdates::~JvmtiDeferredUpdates(). > If you are okay to separate the EscapeBarrier class into its own hpp/cpp files > then the class EscapeBarrierSuspendHandshake is better to be colocated with > it. Done. > The below functions EscapeBarrier::sync_and_suspend_one() and do_thread() make a call to the set_obj_deopt_flag() which > seems to be a duplication. At least, it is not clear why this duplication exist and so, needs to be explained in a > comment. ``` > +void EscapeBarrier::sync_and_suspend_one() { > + assert(_calling_thread != NULL, "calling thread must not be NULL"); > + assert(_deoptee_thread != NULL, "deoptee thread must not be NULL"); > + assert(barrier_active(), "should not call"); > + > + // Sync with other threads that might be doing deoptimizations > + { > + // Need to switch to _thread_blocked for the wait() call > + ThreadBlockInVM tbivm(_calling_thread); > + MonitorLocker ml(_calling_thread, EscapeBarrier_lock, Mutex::_no_safepoint_check_flag); > + while (_self_deoptimization_in_progress || _deoptee_thread->is_obj_deopt_suspend()) { > + ml.wait(); > + } > + > + if (self_deopt()) { > + _self_deoptimization_in_progress = true; > + return; > + } > + > + // set suspend flag for target thread > + _deoptee_thread->set_obj_deopt_flag(); > + } > + > + // suspend target thread > + EscapeBarrierSuspendHandshake sh(NULL, "EscapeBarrierSuspendOne"); > + Handshake::execute_direct(&sh, _deoptee_thread); > + assert(!_deoptee_thread->has_last_Java_frame() || _deoptee_thread->frame_anchor()->walkable(), > + "stack should be walkable now"); > +} > . . . . . > +class EscapeBarrierSuspendHandshake : public HandshakeClosure { > + JavaThread* _excluded_thread; > + public: > + EscapeBarrierSuspendHandshake(JavaThread* excluded_thread, const char* name) : > + HandshakeClosure(name), > + _excluded_thread(excluded_thread) {} > + void do_thread(Thread* th) { > + if (th->is_Java_thread() && !th->is_hidden_from_external_view() && (th != _excluded_thread)) { > + th->set_obj_deopt_flag(); > + } > + } > +}; > ``` I previously removed the set_obj_deopt_flag() call from EscapeBarrierSuspendHandshake::do_thread() in [1]. For synchronization it is better to set_obj_deopt_flag() before the handshake (see comment in EscapeBarrier::sync_and_suspend_all()). [1] https://github.com/openjdk/jdk/pull/119/commits/18dd54b4e6f17ca723e4ae1a1e8dc57e81878dd3 > /src/hotspot/share/prims/jvmtiImpl.cpp: > > ``` > 421 // Constructor for non-object getter > 422 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, jint depth, jint index, BasicType type) > 423 : _thread(thread) > 424 , _calling_thread(NULL) > 425 , _depth(depth) > 426 , _index(index) > 427 , _type(type) > 428 , _jvf(NULL) > 429 , _set(false) > 430 , _eb(NULL, NULL, type == T_OBJECT) > 431 , _result(JVMTI_ERROR_NONE) > 432 { > 433 } > 434 > 435 // Constructor for object or non-object setter > 436 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, jint depth, jint index, BasicType type, jvalue value) > 437 : _thread(thread) > 438 , _calling_thread(NULL) > 439 , _depth(depth) > 440 , _index(index) > 441 , _type(type) > 442 , _value(value) > 443 , _jvf(NULL) > 444 , _set(true) > 445 , _eb(JavaThread::current(), thread, type == T_OBJECT) > 446 , _result(JVMTI_ERROR_NONE) > 447 { > 448 } > 449 > 450 // Constructor for object getter > 451 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, JavaThread* calling_thread, jint depth, int index) > 452 : _thread(thread) > 453 , _calling_thread(calling_thread) > 454 , _depth(depth) > 455 , _index(index) > 456 , _type(T_OBJECT) > 457 , _jvf(NULL) > 458 , _set(false) > 459 , _eb(calling_thread, thread, true) > 460 , _result(JVMTI_ERROR_NONE) > 461 { > 462 } > ``` > > I think, false has to be passed to the constructors of non-object getters instead of expression: > "type == T_OBJECT". > The type can not be T_OBJECT for non-object getters. I used to do that. Then I changed it because the c++ compiler can fold the comparison to "false" and if somebody changes the non-object getter to get objects too then it would still be correct. Let me know if you still think it is better to pass false. Maybe add an assertion type == T_OBJECT then? > Q: Is an EscapeBarrier useful if false is passed as the barrier_active parameter? The EscapeBarrier is not needed then. In the case of the non-object getter above I'd hope that most of the constructor/desctructor of EscapeBarrier is eliminated by the c++ compiler then. Besides the changes you suggested I have made a bugfix in test/jdk/com/sun/jdi/EATests.java to prevent ObjectCollectedException. Thanks, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/119 From mbeckwit at openjdk.java.net Tue Sep 29 14:08:49 2020 From: mbeckwit at openjdk.java.net (Monica Beckwith) Date: Tue, 29 Sep 2020 14:08:49 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12] In-Reply-To: References: Message-ID: > This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html > > Changes since then: > * We've improved the write barrier as suggested by Andrew [1] > * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but > will be required for the upcoming macOS+Aarch64 [2] port as well. > * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the > Windows-specific CPU feature detection on top of it. > > [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html > [2] https://openjdk.java.net/jeps/8251280 Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: change string representation for r18 to "r18_tls" on every platform ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/212/files - new: https://git.openjdk.java.net/jdk/pull/212/files/398d7645..15466ab2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=212&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/212.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/212/head:pull/212 PR: https://git.openjdk.java.net/jdk/pull/212 From burban at openjdk.java.net Tue Sep 29 14:08:50 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Tue, 29 Sep 2020 14:08:50 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v7] In-Reply-To: References: <2yIqVzoFHyYvmsksyTt-u8UOJongLYpvejzHBy4SRWU=.1917991e-684a-4d45-95fa-6d13b365370d@github.com> Message-ID: On Fri, 25 Sep 2020 12:44:37 GMT, Andrew Haley wrote: >> Monica Beckwith has updated the pull request incrementally with two additional commits since the last revision: >> >> - os_windows: remove duplicated UMA handling >> - test_safefetch{32,N} works fine on win+aarch64 > > Marked as reviewed by aph (Reviewer). @theRealAph okay, I've changed the string representation of `r18` to `"r18_tls"` on every platform. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From mbaesken at openjdk.java.net Tue Sep 29 14:09:25 2020 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Tue, 29 Sep 2020 14:09:25 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 07:11:34 GMT, Matthias Baesken wrote: >> src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129: >> >>> 127: NSColor* result = nil; >>> 128: >>> 129: if (colorIndex < ((useAppleColor) ? sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS : >>> java_awt_SystemColor_NUM_COLORS)) { >> >> This looks like a plain old bug fix, nothing really to do with the compiler upgrade. The new compiler presumably just >> has a new warning that brought attention to the problem. As such, I don't think it belongs in a PR that's about issues >> related to the compiler upgrade. Someone might want to backport just this fix, for example. > > Hello Kim, Paul - so should we open a separate bug for the > src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m issue because it might be a general problem just > uncovered by the new compiler ? Paul , do you want to do this ? Or should I open a bug and post a separate change for > the useAppleColor check in CSystemColors.m ? I created https://bugs.openjdk.java.net/browse/JDK-8253791 8253791: Issue with useAppleColor check in CSystemColors.m for this issue (Kim and Paul are fine to have a separate JBS issue for this) ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From eosterlund at openjdk.java.net Tue Sep 29 14:14:51 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 29 Sep 2020 14:14:51 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 13:13:55 GMT, Zhengyu Gu wrote: >> I see; thank you for the explanation. > > Hi Erik, > > I have been playing with this patch for past a few days. Great work! > > I found that this patch seems to break an early assumption. > We have a comment in JavaThread::exit() says: > > 
>   // We need to cache the thread name for logging purposes below as once
>   // we have called on_thread_detach this thread must not access any oops.
>
> > Then in method : > 

> void Threads::remove(JavaThread* p, bool is_daemon)  {
>  ...
>   BarrierSet::barrier_set()->on_thread_detach(p);
> 
>   // Extra scope needed for Thread_lock, so we can check
>   // that we do not remove thread without safepoint code notice
>   { MonitorLocker ml(Threads_lock);
> ..
> }
>
> It calls barrier's on_thread_detach(), acquires Threads_lock. > The lock acquisition triggers stack processing, that potential accesses oops. > 

> V  [libjvm.so+0x10c6f5e]  StackWatermark::start_processing()+0x6a
> V  [libjvm.so+0x10c77e8]  StackWatermarkSet::start_processing(JavaThread*, StackWatermarkKind)+0x82
> V  [libjvm.so+0xfd7757]  SafepointMechanism::process(JavaThread*)+0x37
> V  [libjvm.so+0xfd796b]  SafepointMechanism::process_if_requested_slow(JavaThread*)+0x1d
> V  [libjvm.so+0x4b3683]  SafepointMechanism::process_if_requested(JavaThread*)+0x2b
> V  [libjvm.so+0xe87f0d]  ThreadBlockInVMWithDeadlockCheck::~ThreadBlockInVMWithDeadlockCheck()+0x5f
> V  [libjvm.so+0xe86700]  Mutex::lock_contended(Thread*)+0x12c
> V  [libjvm.so+0xe867d8]  Mutex::lock(Thread*)+0x96
> V  [libjvm.so+0xe86823]  Mutex::lock()+0x23
> V  [libjvm.so+0x29b4bc]  MutexLocker::MutexLocker(Mutex*, Mutex::SafepointCheckFlag)+0xe2
> V  [libjvm.so+0x29b533]  MonitorLocker::MonitorLocker(Monitor*, Mutex::SafepointCheckFlag)+0x29
> V  [libjvm.so+0x119f2ce]  Threads::remove(JavaThread*, bool)+0x56
> V  [libjvm.so+0x1198a2b]  JavaThread::exit(bool, JavaThread::ExitType)+0x905
> V  [libjvm.so+0x1197fde]  JavaThread::post_run()+0x22
> V  [libjvm.so+0x1193eae]  Thread::call_run()+0x230
> V  [libjvm.so+0xef3e38]  thread_native_entry(Thread*)+0x1e4
>
> > This is a problem for Shenandoah, as it flushes SATB buffers during on_thread_detach() and does not expect to see any > more SATB traffic. > Thanks. > Hi Erik, > > I have been playing with this patch for past a few days. Great work! > > I found that this patch seems to break an early assumption. > We have a comment in JavaThread::exit() says: > > // We need to cache the thread name for logging purposes below as once > // we have called on_thread_detach this thread must not access any oops. > > Then in method : > > ``` > > void Threads::remove(JavaThread* p, bool is_daemon) { > ... > BarrierSet::barrier_set()->on_thread_detach(p); > > // Extra scope needed for Thread_lock, so we can check > // that we do not remove thread without safepoint code notice > { MonitorLocker ml(Threads_lock); > .. > } > ``` > > It calls barrier's on_thread_detach(), acquires Threads_lock. > The lock acquisition triggers stack processing, that potential accesses oops. > > ``` > > V [libjvm.so+0x10c6f5e] StackWatermark::start_processing()+0x6a > V [libjvm.so+0x10c77e8] StackWatermarkSet::start_processing(JavaThread*, StackWatermarkKind)+0x82 > V [libjvm.so+0xfd7757] SafepointMechanism::process(JavaThread*)+0x37 > V [libjvm.so+0xfd796b] SafepointMechanism::process_if_requested_slow(JavaThread*)+0x1d > V [libjvm.so+0x4b3683] SafepointMechanism::process_if_requested(JavaThread*)+0x2b > V [libjvm.so+0xe87f0d] ThreadBlockInVMWithDeadlockCheck::~ThreadBlockInVMWithDeadlockCheck()+0x5f > V [libjvm.so+0xe86700] Mutex::lock_contended(Thread*)+0x12c > V [libjvm.so+0xe867d8] Mutex::lock(Thread*)+0x96 > V [libjvm.so+0xe86823] Mutex::lock()+0x23 > V [libjvm.so+0x29b4bc] MutexLocker::MutexLocker(Mutex*, Mutex::SafepointCheckFlag)+0xe2 > V [libjvm.so+0x29b533] MonitorLocker::MonitorLocker(Monitor*, Mutex::SafepointCheckFlag)+0x29 > V [libjvm.so+0x119f2ce] Threads::remove(JavaThread*, bool)+0x56 > V [libjvm.so+0x1198a2b] JavaThread::exit(bool, JavaThread::ExitType)+0x905 > V [libjvm.so+0x1197fde] JavaThread::post_run()+0x22 > V [libjvm.so+0x1193eae] Thread::call_run()+0x230 > V [libjvm.so+0xef3e38] thread_native_entry(Thread*)+0x1e4 > ``` > > This is a problem for Shenandoah, as it flushes SATB buffers during on_thread_detach() and does not expect to see any > more SATB traffic. > Thanks. What oop are you encountering here? You should have no frames left at this point, and all oops should have been cleared. At least that is the theory, and that was why the thread oop moved out from the thread (to enforce that). So I am curious what oop you have found to still be around at this point. Anyway, you can try moving the GC hook into the critical section. That should help. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From hohensee at amazon.com Tue Sep 29 14:18:18 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 29 Sep 2020 14:18:18 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) Message-ID: Thanks for the reviews/discussion, and apologies for the delayed reply: I've been OOTO. Kim is correct, initialize_shared_locs specifically adjusts the alignment of its buffer argument, which is why short works. char would work as well, but short happens to be the size of a relocInfo. Maybe the author of the other use in sharedRuntime.cpp at line 2682 used short to remind of that. Code that calls initialize_shared_locs is inconsistent even within itself. E.g., in c1_Compilation.cpp, we have int locs_buffer_size = 20 * (relocInfo::length_limit + sizeof(relocInfo)); char* locs_buffer = NEW_RESOURCE_ARRAY(char, locs_buffer_size); code->insts()->initialize_shared_locs((relocInfo*)locs_buffer, locs_buffer_size / sizeof(relocInfo)); relocInfo::length_limit is a count of shorts, while sizeof(relocInfo) is a count of chars. The units aren?t the same but are added together as if they were. relocInfo::length_limit is supposed to be the maximum size of a compressed relocation record, so why add sizeof(relocInfo)? And then in sharedRuntime.cpp, we have two places. The first: short buffer_locs[20]; buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, sizeof(buffer_locs)/sizeof(relocInfo)); relocInfo::length_limit is 15 on a 64-bit machine, so with a buffer of 20 shorts, alignment in initialize_shared_locs might take up to of 3 more, which is uncomfortably close to 20 afaic. And, if you add sizeof(relocInfo) as happens in c1_Compilation.cpp, you're bang on at 20. The unstated assumption seems to be that only a single relocation record will be needed. The second: double locs_buf[20]; buffer.insts()->initialize_shared_locs((relocInfo*)locs_buf, sizeof(locs_buf) / sizeof(relocInfo)); This at allocates a buffer that will hold 5 compressed relocation records with 10 bytes left over, and guarantees 8 byte alignment. Perhaps when it was written, initialize_shared_locs didn't align its buffer argument address. And, there's that sizeof(relocInfo) padding again: 2 extra bytes per relocation record. Anyway, I just wanted to make the compiler warning go away, not figure out why the code is the way it is. Matthias and Kim would like to separate out the CSystemColors.m patch into a separate bug, which is fine by me (see separate email). So, for the sharedRuntime patch, would it be ok to just use short locs_buf[84]; to account for possible alignment in initialize_shared_locs? I'm using 84 because 80 is exactly 5 records plus 5 sizeof(relocInfo)s, allowing for alignment adds 3, and rounding the total array size up to a multiple of 8 adds 1. Thanks, Paul ?On 9/29/20, 5:03 AM, "2d-dev on behalf of Kim Barrett" <2d-dev-retn at openjdk.java.net on behalf of kim.barrett at oracle.com> wrote: > On Sep 29, 2020, at 3:59 AM, Matthias Baesken wrote: > > On Fri, 25 Sep 2020 02:23:07 GMT, David Holmes wrote: > >>> Please review this small patch to enable the OSX build using Xcode 12.0. >>> >>> Thanks, >>> Paul >> >> src/hotspot/share/runtime/sharedRuntime.cpp line 2851: >> >>> 2849: if (buf != NULL) { >>> 2850: CodeBuffer buffer(buf); >>> 2851: short locs_buf[80]; >> >> This code is just weird. Why is the locs_buf array not declared to be the desired type? If the compiler rejects double >> because it isn't relocInfo* then why does it accept short? And if it accepts short will it accept int or long long or >> int64_t? Using int64_t would be a clearer change. Though semantically this code is awful. :( Should it be intptr_t ? > > Currently we have in the existing code various kind of buffers passed into initialize_shared_locs that compile nicely > on all supported compilers and on Xcode 12 as well ,see > > c1_Compilation.cpp > > 326 char* locs_buffer = NEW_RESOURCE_ARRAY(char, locs_buffer_size); > 327 code->insts()->initialize_shared_locs((relocInfo*)locs_buffer, > > sharedRuntime.cpp > > 2681 CodeBuffer buffer(buf); > 2682 short buffer_locs[20]; > 2683 buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs, > 2684 sizeof(buffer_locs)/sizeof(relocInfo)); > > So probably using short would be consistent to what we do already in the coding at another place (looking into > relocInfo it would be probably better to use unsigned short or to typedef unsigned short in the relocInfo class > and use the typedef). That?s *not* consistent, because of buffer alignment. The call to NEW_RESOURCE_ARRAY is going to return a pointer to memory that is 2*word aligned. (Interesting, possibly a 32/64 bit ?bug? here.) The existing code in sharedRuntime.cpp is allocating double-aligned. iniitalize_shared_locs wants a HeapWordSize-aligned buffer, and adjusts the pointer it uses accordingly. (I think with existing code it could just make the alignment of the buffer a precondition, but I haven?t looked at all callers.) Changing the declaration in sharedRuntime.cpp to short[] reduces the alignment requirement for the array, possibly requiring alignment adjustment (and hence size reduction) by initialize_shared_locs. Since initialize_shared_locs specifically adjusts the alignment, some downstream use of the buffer probably actually cares. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/348 From zgu at openjdk.java.net Tue Sep 29 14:41:49 2020 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 29 Sep 2020 14:41:49 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6] In-Reply-To: References: Message-ID: <1xyGgagnuexUk3CtKFjdkhM9S4jO8LpdFyTbE3sqi98=.9475a550-847b-4595-be48-3af07da0bd31@github.com> On Tue, 29 Sep 2020 14:12:26 GMT, Erik ?sterlund wrote: > > Hi Erik, > > I have been playing with this patch for past a few days. Great work! > > I found that this patch seems to break an early assumption. > > We have a comment in JavaThread::exit() says: > > // We need to cache the thread name for logging purposes below as once > > // we have called on_thread_detach this thread must not access any oops. > > Then in method : > > ``` > > > > void Threads::remove(JavaThread* p, bool is_daemon) { > > ... > > BarrierSet::barrier_set()->on_thread_detach(p); > > > > // Extra scope needed for Thread_lock, so we can check > > // that we do not remove thread without safepoint code notice > > { MonitorLocker ml(Threads_lock); > > .. > > } > > ``` > > > > > > It calls barrier's on_thread_detach(), acquires Threads_lock. > > The lock acquisition triggers stack processing, that potential accesses oops. > > ``` > > > > V [libjvm.so+0x10c6f5e] StackWatermark::start_processing()+0x6a > > V [libjvm.so+0x10c77e8] StackWatermarkSet::start_processing(JavaThread*, StackWatermarkKind)+0x82 > > V [libjvm.so+0xfd7757] SafepointMechanism::process(JavaThread*)+0x37 > > V [libjvm.so+0xfd796b] SafepointMechanism::process_if_requested_slow(JavaThread*)+0x1d > > V [libjvm.so+0x4b3683] SafepointMechanism::process_if_requested(JavaThread*)+0x2b > > V [libjvm.so+0xe87f0d] ThreadBlockInVMWithDeadlockCheck::~ThreadBlockInVMWithDeadlockCheck()+0x5f > > V [libjvm.so+0xe86700] Mutex::lock_contended(Thread*)+0x12c > > V [libjvm.so+0xe867d8] Mutex::lock(Thread*)+0x96 > > V [libjvm.so+0xe86823] Mutex::lock()+0x23 > > V [libjvm.so+0x29b4bc] MutexLocker::MutexLocker(Mutex*, Mutex::SafepointCheckFlag)+0xe2 > > V [libjvm.so+0x29b533] MonitorLocker::MonitorLocker(Monitor*, Mutex::SafepointCheckFlag)+0x29 > > V [libjvm.so+0x119f2ce] Threads::remove(JavaThread*, bool)+0x56 > > V [libjvm.so+0x1198a2b] JavaThread::exit(bool, JavaThread::ExitType)+0x905 > > V [libjvm.so+0x1197fde] JavaThread::post_run()+0x22 > > V [libjvm.so+0x1193eae] Thread::call_run()+0x230 > > V [libjvm.so+0xef3e38] thread_native_entry(Thread*)+0x1e4 > > ``` > > > > > > This is a problem for Shenandoah, as it flushes SATB buffers during on_thread_detach() and does not expect to see any > > more SATB traffic. Thanks. > > What oop are you encountering here? You should have no frames left at this point, and all oops should have been > cleared. At least that is the theory, and that was why the thread oop moved out from the thread (to enforce that). So I > am curious what oop you have found to still be around at this point. They are handles: 

V  [libjvm.so+0x98d693]  chunk_oops_do(OopClosure*, Chunk*, char*)+0xce
V  [libjvm.so+0x98d6d3]  HandleArea::oops_do(OopClosure*)+0x37
V  [libjvm.so+0x1194ad0]  Thread::oops_do_no_frames(OopClosure*, CodeBlobClosure*)+0x88
V  [libjvm.so+0x119b0c8]  JavaThread::oops_do_no_frames(OopClosure*, CodeBlobClosure*)+0x88
> > Anyway, you can try moving the GC hook into the critical section. That should help. This seems to work. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From matthias.baesken at sap.com Tue Sep 29 14:41:59 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 29 Sep 2020 14:41:59 +0000 Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: <8D7E0A19-32C7-47CC-890D-1670A5A02D5E@amazon.com> References: <8D7E0A19-32C7-47CC-890D-1670A5A02D5E@amazon.com> Message-ID: > Hi, Matthias, Kim. No problem opening a separate issue to fix CSystemColors.m. Hi Paul, did that : https://bugs.openjdk.java.net/browse/JDK-8253791 https://github.com/openjdk/jdk/pull/403 Best regards, Matthias -----Original Message----- From: Hohensee, Paul Sent: Dienstag, 29. September 2020 15:46 To: Kim Barrett ; Matthias Baesken Cc: 2d-dev at openjdk.java.net; awt-dev at openjdk.java.net; build-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: RE: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) Hi, Matthias, Kim. No problem opening a separate issue to fix CSystemColors.m. Thanks, Paul ?On 9/29/20, 4:23 AM, "hotspot-dev on behalf of Kim Barrett" wrote: > On Sep 29, 2020, at 3:14 AM, Matthias Baesken wrote: > > On Fri, 25 Sep 2020 06:06:31 GMT, Kim Barrett wrote: > >>> Please review this small patch to enable the OSX build using Xcode 12.0. >>> >>> Thanks, >>> Paul >> >> src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129: >> >>> 127: NSColor* result = nil; >>> 128: >>> 129: if (colorIndex < ((useAppleColor) ? sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS : >>> java_awt_SystemColor_NUM_COLORS)) { >> >> This looks like a plain old bug fix, nothing really to do with the compiler upgrade. The new compiler presumably just >> has a new warning that brought attention to the problem. As such, I don't think it belongs in a PR that's about issues >> related to the compiler upgrade. Someone might want to backport just this fix, for example. > > Hello Kim, Paul - so should we open a separate bug for the > src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m issue because it might be a general problem just > uncovered by the new compiler ? Paul , do you want to do this ? Or should I open a bug and post a separate change for > the useAppleColor check in CSystemColors.m ? I think so. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/348 From eosterlund at openjdk.java.net Tue Sep 29 14:51:07 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 29 Sep 2020 14:51:07 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v6] In-Reply-To: <1xyGgagnuexUk3CtKFjdkhM9S4jO8LpdFyTbE3sqi98=.9475a550-847b-4595-be48-3af07da0bd31@github.com> References: <1xyGgagnuexUk3CtKFjdkhM9S4jO8LpdFyTbE3sqi98=.9475a550-847b-4595-be48-3af07da0bd31@github.com> Message-ID: On Tue, 29 Sep 2020 14:39:23 GMT, Zhengyu Gu wrote: >>> Hi Erik, >>> >>> I have been playing with this patch for past a few days. Great work! >>> >>> I found that this patch seems to break an early assumption. >>> We have a comment in JavaThread::exit() says: >>> >>> // We need to cache the thread name for logging purposes below as once >>> // we have called on_thread_detach this thread must not access any oops. >>> >>> Then in method : >>> >>> ``` >>> >>> void Threads::remove(JavaThread* p, bool is_daemon) { >>> ... >>> BarrierSet::barrier_set()->on_thread_detach(p); >>> >>> // Extra scope needed for Thread_lock, so we can check >>> // that we do not remove thread without safepoint code notice >>> { MonitorLocker ml(Threads_lock); >>> .. >>> } >>> ``` >>> >>> It calls barrier's on_thread_detach(), acquires Threads_lock. >>> The lock acquisition triggers stack processing, that potential accesses oops. >>> >>> ``` >>> >>> V [libjvm.so+0x10c6f5e] StackWatermark::start_processing()+0x6a >>> V [libjvm.so+0x10c77e8] StackWatermarkSet::start_processing(JavaThread*, StackWatermarkKind)+0x82 >>> V [libjvm.so+0xfd7757] SafepointMechanism::process(JavaThread*)+0x37 >>> V [libjvm.so+0xfd796b] SafepointMechanism::process_if_requested_slow(JavaThread*)+0x1d >>> V [libjvm.so+0x4b3683] SafepointMechanism::process_if_requested(JavaThread*)+0x2b >>> V [libjvm.so+0xe87f0d] ThreadBlockInVMWithDeadlockCheck::~ThreadBlockInVMWithDeadlockCheck()+0x5f >>> V [libjvm.so+0xe86700] Mutex::lock_contended(Thread*)+0x12c >>> V [libjvm.so+0xe867d8] Mutex::lock(Thread*)+0x96 >>> V [libjvm.so+0xe86823] Mutex::lock()+0x23 >>> V [libjvm.so+0x29b4bc] MutexLocker::MutexLocker(Mutex*, Mutex::SafepointCheckFlag)+0xe2 >>> V [libjvm.so+0x29b533] MonitorLocker::MonitorLocker(Monitor*, Mutex::SafepointCheckFlag)+0x29 >>> V [libjvm.so+0x119f2ce] Threads::remove(JavaThread*, bool)+0x56 >>> V [libjvm.so+0x1198a2b] JavaThread::exit(bool, JavaThread::ExitType)+0x905 >>> V [libjvm.so+0x1197fde] JavaThread::post_run()+0x22 >>> V [libjvm.so+0x1193eae] Thread::call_run()+0x230 >>> V [libjvm.so+0xef3e38] thread_native_entry(Thread*)+0x1e4 >>> ``` >>> >>> This is a problem for Shenandoah, as it flushes SATB buffers during on_thread_detach() and does not expect to see any >>> more SATB traffic. >>> Thanks. >> >> What oop are you encountering here? You should have no frames left at this point, and all oops should have been >> cleared. At least that is the theory, and that was why the thread oop moved out from the thread (to enforce that). So I >> am curious what oop you have found to still be around at this point. Anyway, you can try moving the GC hook into the >> critical section. That should help. > >> > Hi Erik, >> > I have been playing with this patch for past a few days. Great work! >> > I found that this patch seems to break an early assumption. >> > We have a comment in JavaThread::exit() says: >> > // We need to cache the thread name for logging purposes below as once >> > // we have called on_thread_detach this thread must not access any oops. >> > Then in method : >> > ``` >> > >> > void Threads::remove(JavaThread* p, bool is_daemon) { >> > ... >> > BarrierSet::barrier_set()->on_thread_detach(p); >> > >> > // Extra scope needed for Thread_lock, so we can check >> > // that we do not remove thread without safepoint code notice >> > { MonitorLocker ml(Threads_lock); >> > .. >> > } >> > ``` >> > >> > >> > It calls barrier's on_thread_detach(), acquires Threads_lock. >> > The lock acquisition triggers stack processing, that potential accesses oops. >> > ``` >> > >> > V [libjvm.so+0x10c6f5e] StackWatermark::start_processing()+0x6a >> > V [libjvm.so+0x10c77e8] StackWatermarkSet::start_processing(JavaThread*, StackWatermarkKind)+0x82 >> > V [libjvm.so+0xfd7757] SafepointMechanism::process(JavaThread*)+0x37 >> > V [libjvm.so+0xfd796b] SafepointMechanism::process_if_requested_slow(JavaThread*)+0x1d >> > V [libjvm.so+0x4b3683] SafepointMechanism::process_if_requested(JavaThread*)+0x2b >> > V [libjvm.so+0xe87f0d] ThreadBlockInVMWithDeadlockCheck::~ThreadBlockInVMWithDeadlockCheck()+0x5f >> > V [libjvm.so+0xe86700] Mutex::lock_contended(Thread*)+0x12c >> > V [libjvm.so+0xe867d8] Mutex::lock(Thread*)+0x96 >> > V [libjvm.so+0xe86823] Mutex::lock()+0x23 >> > V [libjvm.so+0x29b4bc] MutexLocker::MutexLocker(Mutex*, Mutex::SafepointCheckFlag)+0xe2 >> > V [libjvm.so+0x29b533] MonitorLocker::MonitorLocker(Monitor*, Mutex::SafepointCheckFlag)+0x29 >> > V [libjvm.so+0x119f2ce] Threads::remove(JavaThread*, bool)+0x56 >> > V [libjvm.so+0x1198a2b] JavaThread::exit(bool, JavaThread::ExitType)+0x905 >> > V [libjvm.so+0x1197fde] JavaThread::post_run()+0x22 >> > V [libjvm.so+0x1193eae] Thread::call_run()+0x230 >> > V [libjvm.so+0xef3e38] thread_native_entry(Thread*)+0x1e4 >> > ``` >> > >> > >> > This is a problem for Shenandoah, as it flushes SATB buffers during on_thread_detach() and does not expect to see any >> > more SATB traffic. Thanks. >> >> What oop are you encountering here? You should have no frames left at this point, and all oops should have been >> cleared. At least that is the theory, and that was why the thread oop moved out from the thread (to enforce that). So I >> am curious what oop you have found to still be around at this point. > > They are handles: > 

> V  [libjvm.so+0x98d693]  chunk_oops_do(OopClosure*, Chunk*, char*)+0xce
> V  [libjvm.so+0x98d6d3]  HandleArea::oops_do(OopClosure*)+0x37
> V  [libjvm.so+0x1194ad0]  Thread::oops_do_no_frames(OopClosure*, CodeBlobClosure*)+0x88
> V  [libjvm.so+0x119b0c8]  JavaThread::oops_do_no_frames(OopClosure*, CodeBlobClosure*)+0x88
>
> >> >> Anyway, you can try moving the GC hook into the critical section. That should help. > > This seems to work. > > > Hi Erik, > > > I have been playing with this patch for past a few days. Great work! > > > I found that this patch seems to break an early assumption. > > > We have a comment in JavaThread::exit() says: > > > // We need to cache the thread name for logging purposes below as once > > > // we have called on_thread_detach this thread must not access any oops. > > > Then in method : > > > ``` > > > > > > void Threads::remove(JavaThread* p, bool is_daemon) { > > > ... > > > BarrierSet::barrier_set()->on_thread_detach(p); > > > > > > // Extra scope needed for Thread_lock, so we can check > > > // that we do not remove thread without safepoint code notice > > > { MonitorLocker ml(Threads_lock); > > > .. > > > } > > > ``` > > > > > > > > > It calls barrier's on_thread_detach(), acquires Threads_lock. > > > The lock acquisition triggers stack processing, that potential accesses oops. > > > ``` > > > > > > V [libjvm.so+0x10c6f5e] StackWatermark::start_processing()+0x6a > > > V [libjvm.so+0x10c77e8] StackWatermarkSet::start_processing(JavaThread*, StackWatermarkKind)+0x82 > > > V [libjvm.so+0xfd7757] SafepointMechanism::process(JavaThread*)+0x37 > > > V [libjvm.so+0xfd796b] SafepointMechanism::process_if_requested_slow(JavaThread*)+0x1d > > > V [libjvm.so+0x4b3683] SafepointMechanism::process_if_requested(JavaThread*)+0x2b > > > V [libjvm.so+0xe87f0d] ThreadBlockInVMWithDeadlockCheck::~ThreadBlockInVMWithDeadlockCheck()+0x5f > > > V [libjvm.so+0xe86700] Mutex::lock_contended(Thread*)+0x12c > > > V [libjvm.so+0xe867d8] Mutex::lock(Thread*)+0x96 > > > V [libjvm.so+0xe86823] Mutex::lock()+0x23 > > > V [libjvm.so+0x29b4bc] MutexLocker::MutexLocker(Mutex*, Mutex::SafepointCheckFlag)+0xe2 > > > V [libjvm.so+0x29b533] MonitorLocker::MonitorLocker(Monitor*, Mutex::SafepointCheckFlag)+0x29 > > > V [libjvm.so+0x119f2ce] Threads::remove(JavaThread*, bool)+0x56 > > > V [libjvm.so+0x1198a2b] JavaThread::exit(bool, JavaThread::ExitType)+0x905 > > > V [libjvm.so+0x1197fde] JavaThread::post_run()+0x22 > > > V [libjvm.so+0x1193eae] Thread::call_run()+0x230 > > > V [libjvm.so+0xef3e38] thread_native_entry(Thread*)+0x1e4 > > > ``` > > > > > > > > > This is a problem for Shenandoah, as it flushes SATB buffers during on_thread_detach() and does not expect to see any > > > more SATB traffic. Thanks. > > > > > > What oop are you encountering here? You should have no frames left at this point, and all oops should have been > > cleared. At least that is the theory, and that was why the thread oop moved out from the thread (to enforce that). So I > > am curious what oop you have found to still be around at this point. > > They are handles: > > ``` > > V [libjvm.so+0x98d693] chunk_oops_do(OopClosure*, Chunk*, char*)+0xce > V [libjvm.so+0x98d6d3] HandleArea::oops_do(OopClosure*)+0x37 > V [libjvm.so+0x1194ad0] Thread::oops_do_no_frames(OopClosure*, CodeBlobClosure*)+0x88 > V [libjvm.so+0x119b0c8] JavaThread::oops_do_no_frames(OopClosure*, CodeBlobClosure*)+0x88 > ``` > > > Anyway, you can try moving the GC hook into the critical section. That should help. > > This seems to work. Okay, I will move it. ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From eosterlund at openjdk.java.net Tue Sep 29 15:03:26 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 29 Sep 2020 15:03:26 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v8] In-Reply-To: References: Message-ID: > This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. > https://openjdk.java.net/jeps/376). > Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, > and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into > more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to > expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in > the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized > automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization > processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is > actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception > handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC > threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming > of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the > watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll > word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it > brought (and is only possible on TSO machines). So left that one out. Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Review: Move barrier detach - Review: Remove assert that has outstayed its welcome - Merge branch 'master' into 8253180_conc_stack_scanning - Review: Albert CR2 and defensive programming - Review: StefanK CR 3 - Review: Per CR 1 - Merge branch 'master' into 8253180_conc_stack_scanning - Review: Albert CR 1 - Review: SteafanK CR 2 - Merge branch 'master' into 8253180_conc_stack_scanning - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6bddeb70...2ffbd764 ------------- Changes: https://git.openjdk.java.net/jdk/pull/296/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=07 Stats: 2705 lines in 129 files changed: 2137 ins; 310 del; 258 mod Patch: https://git.openjdk.java.net/jdk/pull/296.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/296/head:pull/296 PR: https://git.openjdk.java.net/jdk/pull/296 From rehn at openjdk.java.net Tue Sep 29 16:12:17 2020 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 29 Sep 2020 16:12:17 GMT Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v8] In-Reply-To: References: Message-ID: <4sawJHiIuc7oH5ETjrwJtJE3gkB1U2VBMVJdPmxJrg4=.e4e9b4d3-a118-4870-9b5b-f23b351093e2@github.com> On Tue, 29 Sep 2020 15:03:26 GMT, Erik ?sterlund wrote: >> This PR the implementation of "JEP 376: ZGC: Concurrent Thread-Stack Processing" (cf. >> https://openjdk.java.net/jeps/376). >> Basically, this patch modifies the epilog safepoint when returning from a frame (supporting interpreter frames, c1, c2, >> and native wrapper frames), to compare the stack pointer against a thread-local value. This turns return polls into >> more of a swiss army knife that can be used to poll for safepoints, handshakes, but also returns into not yet safe to >> expose frames, denoted by a "stack watermark". ZGC will leave frames (and other thread oops) in a state of a mess in >> the GC checkpoint safepoints, rather than processing all threads and their stacks. Processing is initialized >> automagically when threads wake up for a safepoint, or get poked by a handshake or safepoint. Said initialization >> processes a few (3) frames and other thread oops. The rest - the bulk of the frame processing, is deferred until it is >> actually needed. It is needed when a frame is exposed to either 1) execution (returns or unwinding due to exception >> handling), or 2) stack walker APIs. A hook is then run to go and finish the lazy processing of frames. Mutator and GC >> threads can compete for processing. The processing is therefore performed under a per-thread lock. Note that disarming >> of the poll word (that the returns are comparing against) is only performed by the thread itself. So sliding the >> watermark up will require one runtime call for a thread to note that nothing needs to be done, and then update the poll >> word accordingly. Downgrading the poll word concurrently by other threads was simply not worth the complexity it >> brought (and is only possible on TSO machines). So left that one out. > > Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now > contains 12 commits: > - Review: Move barrier detach > - Review: Remove assert that has outstayed its welcome > - Merge branch 'master' into 8253180_conc_stack_scanning > - Review: Albert CR2 and defensive programming > - Review: StefanK CR 3 > - Review: Per CR 1 > - Merge branch 'master' into 8253180_conc_stack_scanning > - Review: Albert CR 1 > - Review: SteafanK CR 2 > - Merge branch 'master' into 8253180_conc_stack_scanning > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6bddeb70...2ffbd764 Marked as reviewed by rehn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/296 From kim.barrett at oracle.com Tue Sep 29 16:32:27 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 29 Sep 2020 12:32:27 -0400 Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <0CA82EAC-9A42-411F-8761-6D9D4F85101E@oracle.com> > On Sep 29, 2020, at 10:18 AM, Hohensee, Paul wrote: > Code that calls initialize_shared_locs is inconsistent even within itself. E.g., in c1_Compilation.cpp, we have Agreed there seems to be a bit of a mess around that function. > Anyway, I just wanted to make the compiler warning go away, not figure out why the code is the way it is. Matthias and Kim would like to separate out the CSystemColors.m patch into a separate bug, which is fine by me (see separate email). > > So, for the sharedRuntime patch, would it be ok to just use > > short locs_buf[84]; > > to account for possible alignment in initialize_shared_locs? I'm using 84 because 80 is exactly 5 records plus 5 sizeof(relocInfo)s, allowing for alignment adds 3, and rounding the total array size up to a multiple of 8 adds 1. Your analysis looks plausible. But consider instead struct { double data[20]; } locs_buf; and change next line to use &locs_buf This doesn't change the size or alignment from pre-existing code. I can't test whether this will suppress the warning, but I'm guessing it will. And the rest of below is off if that?s wrong. Changing the size and type and worrying about alignment changes seems beyond what's needed "to make the compiler warning go away, not figure out why the code is the way it is.? I dislike making weird changes to suppress compiler warnings, but changing the type and size seems more weird to me here. I mean, 84 looks like a number pulled out of a hat, unless you are going to add a bunch of commentary that probably really belongs in a bug report to look at this stuff more carefully. And file an RFE to look at initialize_shared_locs and its callers more carefully. From github.com+51754783+CoreyAshford at openjdk.java.net Tue Sep 29 16:42:03 2020 From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford) Date: Tue, 29 Sep 2020 16:42:03 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: References: Message-ID: <3zdj-jaGgS6_W7mNPSnlZr6JECPKSybWxR1-yy5bZ8Q=.90bff33b-0da1-49cf-9833-ee08caf55c6f@github.com> On Tue, 29 Sep 2020 08:41:37 GMT, Martin Doerr wrote: > Did you try on x86? AOT is not supported on PPC64. I didn't. No wonder. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/293 From kvn at openjdk.java.net Tue Sep 29 16:51:34 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 29 Sep 2020 16:51:34 GMT Subject: RFR: 8253721: Flag -XX:AVX3Threshold does not accept Zero value In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 05:53:39 GMT, Jatin Bhateja wrote: > AVX3Threshold has been used in various places to enable emitting AVX3 specific instructions in case data size being > worked over is greater than 4096 bytes. > However, user is free to set the threshold value to Zero based on his workload. > In such a case a compile time check is enough to trigger generation of AVX3 instructions. In other cases comparison is > done at the runtime though JITed comparison instruction. > Patch allows setting AVX3Threshold to a zero value. Looks good. Thank you for ding this. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/394 From thartmann at openjdk.java.net Tue Sep 29 16:58:00 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 29 Sep 2020 16:58:00 GMT Subject: RFR: 8253721: Flag -XX:AVX3Threshold does not accept Zero value In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 05:53:39 GMT, Jatin Bhateja wrote: > AVX3Threshold has been used in various places to enable emitting AVX3 specific instructions in case data size being > worked over is greater than 4096 bytes. > However, user is free to set the threshold value to Zero based on his workload. > In such a case a compile time check is enough to trigger generation of AVX3 instructions. In other cases comparison is > done at the runtime though JITed comparison instruction. > Patch allows setting AVX3Threshold to a zero value. Looks good to me. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/394 From dcubed at openjdk.java.net Tue Sep 29 17:36:20 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 29 Sep 2020 17:36:20 GMT Subject: RFR: 8253183: Fragile memory barrier selection for some weak memory model platforms In-Reply-To: References: Message-ID: <3Ss7Sekd5A3Yw2cD9CjapE-qsGh3sT22etWPKyXzP6c=.a7529a77-0b20-4f5f-b60c-a845070dd801@github.com> On Mon, 28 Sep 2020 21:11:04 GMT, Martin Doerr wrote: > Hi, I'd like to propose a fix after the discussion in https://bugs.openjdk.java.net/browse/JDK-8253183 > > Please especially review my new comments in the code. The authors of the surrounding code in objectMonitor.cpp and > synchronizer.cpp may know better. Thumbs up! Your call on whether to switch from 'iriw' to 'IRIW' in the new function name. src/hotspot/share/runtime/orderAccess.hpp line 250: > 248: // to enforce a globally consistent order of Independent Reads of > 249: // Independent Writes. Please use only for such patterns! > 250: static void loadload_for_iriw() { So why is this (lower case) 'iriw' when we almost always talk about it as IRIW? src/hotspot/share/runtime/objectMonitor.cpp line 495: > 493: // _contentions and dmw/header may get written by different threads. > 494: // Make sure to observe them in the same order when having several observers. > 495: OrderAccess::loadload_for_iriw(); The code we are replacing used 'IRIW' instead of 'iriw'. src/hotspot/share/runtime/synchronizer.cpp line 1111: > 1109: // dmw/header and _contentions may get written by different threads. > 1110: // Make sure to observe them in the same order when having several observers. > 1111: OrderAccess::loadload_for_iriw(); The code we're replacing using 'IRIW' instead of 'iriw'. ------------- PR: https://git.openjdk.java.net/jdk/pull/387 From phh at openjdk.java.net Tue Sep 29 19:33:48 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Tue, 29 Sep 2020 19:33:48 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] In-Reply-To: References: Message-ID: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch - Merge branch 'master' into JDK-8253375 - JDK-8253375 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/348/files - new: https://git.openjdk.java.net/jdk/pull/348/files/5db5edc2..cb08da07 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=348&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=348&range=00-01 Stats: 27610 lines in 391 files changed: 4691 ins; 21610 del; 1309 mod Patch: https://git.openjdk.java.net/jdk/pull/348.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/348/head:pull/348 PR: https://git.openjdk.java.net/jdk/pull/348 From kbarrett at openjdk.java.net Tue Sep 29 19:39:03 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 29 Sep 2020 19:39:03 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 19:33:48 GMT, Paul Hohensee wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since > the last revision: > - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch > - Merge branch 'master' into JDK-8253375 > - JDK-8253375 Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From lucy at openjdk.java.net Tue Sep 29 20:05:34 2020 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Tue, 29 Sep 2020 20:05:34 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 19:33:48 GMT, Paul Hohensee wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since > the last revision: > - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch > - Merge branch 'master' into JDK-8253375 > - JDK-8253375 The proposed (updated) change does _NOT_ compile on my machine (MacOS 10.15.6, Xcode 12.0): sharedRuntime.cpp:2860:46: error: cannot cast from type 'struct (anonymous struct at sharedRuntime.cpp:2859:7)' to pointer type 'relocInfo *' You will have to use a union (option (2) as proposed by Kim Barrett far above. I proved that variant compiles on my machine. ------------- Changes requested by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/348 From cjplummer at openjdk.java.net Tue Sep 29 20:11:19 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 29 Sep 2020 20:11:19 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v7] In-Reply-To: References: <2yIqVzoFHyYvmsksyTt-u8UOJongLYpvejzHBy4SRWU=.1917991e-684a-4d45-95fa-6d13b365370d@github.com> Message-ID: On Tue, 29 Sep 2020 14:03:57 GMT, Bernhard Urban-Forster wrote: >> Marked as reviewed by aph (Reviewer). > > @theRealAph okay, I've changed the string representation of `r18` to `"r18_tls"` on every platform. > @plummercj thank you for your feedback. I've updated the copyright in mentioned files. Changes look good. Thanks. I'm marking as "reviewed" for serviceability changes and copyrights. ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From cjplummer at openjdk.java.net Tue Sep 29 20:16:24 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 29 Sep 2020 20:16:24 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 14:08:49 GMT, Monica Beckwith wrote: >> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: > > change string representation for r18 to "r18_tls" on every platform Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From mdoerr at openjdk.java.net Tue Sep 29 20:39:10 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 29 Sep 2020 20:39:10 GMT Subject: RFR: 8253183: Fragile memory barrier selection for some weak memory model platforms [v2] In-Reply-To: References: Message-ID: <7VyR8rrEdsl051j0i9Qkg9JJw9IVmNh07vn0HJ96aro=.64af17d6-49a9-43fc-9bc8-b02b41df5242@github.com> > Hi, I'd like to propose a fix after the discussion in https://bugs.openjdk.java.net/browse/JDK-8253183 > > Please especially review my new comments in the code. The authors of the surrounding code in objectMonitor.cpp and > synchronizer.cpp may know better. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: rename loadload_for_iriw to loadload_for_IRIW ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/387/files - new: https://git.openjdk.java.net/jdk/pull/387/files/cd1cc97b..cc7e9c6d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=387&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=387&range=00-01 Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/387.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/387/head:pull/387 PR: https://git.openjdk.java.net/jdk/pull/387 From mdoerr at openjdk.java.net Tue Sep 29 20:41:57 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 29 Sep 2020 20:41:57 GMT Subject: RFR: 8253183: Fragile memory barrier selection for some weak memory model platforms [v2] In-Reply-To: <3Ss7Sekd5A3Yw2cD9CjapE-qsGh3sT22etWPKyXzP6c=.a7529a77-0b20-4f5f-b60c-a845070dd801@github.com> References: <3Ss7Sekd5A3Yw2cD9CjapE-qsGh3sT22etWPKyXzP6c=.a7529a77-0b20-4f5f-b60c-a845070dd801@github.com> Message-ID: <8eVj5rmPCpRxwSrzVGErWXraxqpj4zv3PZ_RYPO5Q-o=.63539b6d-1963-49d7-a909-96d52d7ef82f@github.com> On Tue, 29 Sep 2020 17:32:59 GMT, Daniel D. Daugherty wrote: >> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: >> >> rename loadload_for_iriw to loadload_for_IRIW > > src/hotspot/share/runtime/synchronizer.cpp line 1111: > >> 1109: // dmw/header and _contentions may get written by different threads. >> 1110: // Make sure to observe them in the same order when having several observers. >> 1111: OrderAccess::loadload_for_iriw(); > > The code we're replacing using 'IRIW' instead of 'iriw'. Makes sense. Renamed to upper case IRIW. Also removed unnecessary OrderAccess:: qualification inside of class OrderAccess. ------------- PR: https://git.openjdk.java.net/jdk/pull/387 From dcubed at openjdk.java.net Tue Sep 29 20:53:54 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 29 Sep 2020 20:53:54 GMT Subject: RFR: 8253183: Fragile memory barrier selection for some weak memory model platforms [v2] In-Reply-To: <7VyR8rrEdsl051j0i9Qkg9JJw9IVmNh07vn0HJ96aro=.64af17d6-49a9-43fc-9bc8-b02b41df5242@github.com> References: <7VyR8rrEdsl051j0i9Qkg9JJw9IVmNh07vn0HJ96aro=.64af17d6-49a9-43fc-9bc8-b02b41df5242@github.com> Message-ID: On Tue, 29 Sep 2020 20:39:10 GMT, Martin Doerr wrote: >> Hi, I'd like to propose a fix after the discussion in https://bugs.openjdk.java.net/browse/JDK-8253183 >> >> Please especially review my new comments in the code. The authors of the surrounding code in objectMonitor.cpp and >> synchronizer.cpp may know better. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > rename loadload_for_iriw to loadload_for_IRIW Thanks for making those changes. Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/387 From kim.barrett at oracle.com Tue Sep 29 20:53:48 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 29 Sep 2020 16:53:48 -0400 Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] In-Reply-To: References: Message-ID: > On Sep 29, 2020, at 4:05 PM, Lutz Schmidt wrote: > > On Tue, 29 Sep 2020 19:33:48 GMT, Paul Hohensee wrote: > >>> Please review this small patch to enable the OSX build using Xcode 12.0. >>> >>> Thanks, >>> Paul >> >> Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev >> excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since >> the last revision: >> - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch >> - Merge branch 'master' into JDK-8253375 >> - JDK-8253375 > > The proposed (updated) change does _NOT_ compile on my machine (MacOS 10.15.6, Xcode 12.0): > > sharedRuntime.cpp:2860:46: error: cannot cast from type 'struct (anonymous struct at sharedRuntime.cpp:2859:7)' to > pointer type 'relocInfo *? Did you use the change from the PR, or apply it manually. That looks like the error one would get if only the type of locs_buf were changed, without changing to take the address in the reference. That is, without changing `(relocInfo*)locs_buf` to `(relocInfo*)&locs_buf`. That second change is in the PR. > You will have to use a union (option (2) as proposed by Kim Barrett far above. I proved that variant compiles on my > machine. > > ------------- > > Changes requested by lucy (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/348 From psandoz at openjdk.java.net Tue Sep 29 21:51:36 2020 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 29 Sep 2020 21:51:36 GMT Subject: RFR: 8223347: Integration of Vector API (Incubator) Message-ID: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com> This pull request is for integration of the Vector API. It was previously reviewed under conditions when mercurial was used for the source code control system. Review threads can be found here (searching for issue number 8223347 in the title): https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/thread.html https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/thread.html https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/thread.html If mercurial was still being used the code would be pushed directly, once the CSR is approved. However, in this case a pull request is required and needs explicit reviewer approval. Between the final review and this pull request no code has changed, except for that related to merging. ------------- Commit messages: - Fix permissions - Fix permissions - Merge master - Vector API new files - Integration of Vector API (Incubator) Changes: https://git.openjdk.java.net/jdk/pull/367/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=367&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8223347 Stats: 295107 lines in 336 files changed: 292957 ins; 1062 del; 1088 mod Patch: https://git.openjdk.java.net/jdk/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/367/head:pull/367 PR: https://git.openjdk.java.net/jdk/pull/367 From erikj at openjdk.java.net Tue Sep 29 22:02:39 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 29 Sep 2020 22:02:39 GMT Subject: RFR: 8223347: Integration of Vector API (Incubator) In-Reply-To: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com> References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com> Message-ID: On Fri, 25 Sep 2020 20:14:29 GMT, Paul Sandoz wrote: > This pull request is for integration of the Vector API. It was previously reviewed under conditions when mercurial was > used for the source code control system. Review threads can be found here (searching for issue number 8223347 in the > title): https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/thread.html > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/thread.html > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/thread.html > > If mercurial was still being used the code would be pushed directly, once the CSR is approved. However, in this case a > pull request is required and needs explicit reviewer approval. Between the final review and this pull request no code > has changed, except for that related to merging. Build changes look ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/367 From hohensee at amazon.com Tue Sep 29 22:14:27 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 29 Sep 2020 22:14:27 +0000 Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] Message-ID: <398178BA-0420-4ED1-9B70-7FBC3336638D@amazon.com> Hmm. I'm running Xcode 12.0.1 on 10.15.6 and don't see it. Are you sure you have the '&' in front of locs_buf? I.e., buffer.insts()->initialize_shared_locs((relocInfo*)&locs_buf, sizeof(locs_buf) / sizeof(relocInfo)); ^ Thanks, Paul ?On 9/29/20, 1:07 PM, "build-dev on behalf of Lutz Schmidt" wrote: On Tue, 29 Sep 2020 19:33:48 GMT, Paul Hohensee wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since > the last revision: > - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch > - Merge branch 'master' into JDK-8253375 > - JDK-8253375 The proposed (updated) change does _NOT_ compile on my machine (MacOS 10.15.6, Xcode 12.0): sharedRuntime.cpp:2860:46: error: cannot cast from type 'struct (anonymous struct at sharedRuntime.cpp:2859:7)' to pointer type 'relocInfo *' You will have to use a union (option (2) as proposed by Kim Barrett far above. I proved that variant compiles on my machine. ------------- Changes requested by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/348 From kim.barrett at oracle.com Tue Sep 29 22:20:35 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 29 Sep 2020 18:20:35 -0400 Subject: RFR: 8253180: ZGC: Implementation of JEP 376: ZGC: Concurrent Thread-Stack Processing [v8] In-Reply-To: References: Message-ID: > On Sep 29, 2020, at 11:03 AM, Erik ?sterlund wrote: > > Changes: https://git.openjdk.java.net/jdk/pull/296/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=296&range=07 > Stats: 2705 lines in 129 files changed: 2137 ins; 310 del; 258 mod > Patch: https://git.openjdk.java.net/jdk/pull/296.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/296/head:pull/296 > > PR: https://git.openjdk.java.net/jdk/pull/296 I've only looked at scattered pieces, but what I've looked at seemed to be in good shape. Only a few minor comments. ------------------------------------------------------------------------------ src/hotspot/share/runtime/frame.cpp 456 // for(StackFrameStream fst(thread); !fst.is_done(); fst.next()) { Needs to be updated for the new constructor arguments. Just in general, the class documentation seems to need some updating for this change. ------------------------------------------------------------------------------ src/hotspot/share/runtime/frame.cpp 466 StackFrameStream(JavaThread *thread, bool update, bool process_frames); Something to consider is that bool parameters like that, especially when there are multiple, are error prone. An alternative is distinct enums, which likely also obviates the need for comments in calls. ------------------------------------------------------------------------------ src/hotspot/share/runtime/thread.hpp 956 void set_processed_thread(Thread *thread) { _processed_thread = thread; } I think this should assert that either _processed_thread or thread are NULL. Or maybe the RememberProcessedThread constructor should be asserting that _cur_thr->processed_thread() is NULL. ------------------------------------------------------------------------------ From valeriep at openjdk.java.net Tue Sep 29 22:25:24 2020 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 29 Sep 2020 22:25:24 GMT Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 09:22:25 GMT, Andrew Haley wrote: >> Acked-by: Ard Biesheuvel > >> If this feature is not auto-enabled when the SHA3 hardware feature is there, we will have one failure for the following >> test: test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java >> 15 #-----testresult----- >> 16 >> description=file:/home/yangfei/github/jdk/test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java >> 17 elapsed=31546 0:00:31.546 18 end=Mon Sep 21 10:27:58 CST 2020 >> 19 environment=regtest >> 20 execStatus=Failed. Execution failed: `main' threw exception: java.lang.AssertionError: Option 'UseSHA3Intrinsics' is >> expected to have 'true' value Option 'UseSHA3Intrinsics' should be enabled by default >> Any suggestions for this? > > I don't understand your question. There should be two acceptable results, either "Pass" or "Not supported". What else > is possible? I have looked at the java security changes, i.e. src/java.base/share/classes/sun/security/provider/SHA3.java. It looks fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/207 From dholmes at openjdk.java.net Wed Sep 30 00:37:51 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 30 Sep 2020 00:37:51 GMT Subject: RFR: 8253183: Fragile memory barrier selection for some weak memory model platforms [v2] In-Reply-To: <7VyR8rrEdsl051j0i9Qkg9JJw9IVmNh07vn0HJ96aro=.64af17d6-49a9-43fc-9bc8-b02b41df5242@github.com> References: <7VyR8rrEdsl051j0i9Qkg9JJw9IVmNh07vn0HJ96aro=.64af17d6-49a9-43fc-9bc8-b02b41df5242@github.com> Message-ID: On Tue, 29 Sep 2020 20:39:10 GMT, Martin Doerr wrote: >> Hi, I'd like to propose a fix after the discussion in https://bugs.openjdk.java.net/browse/JDK-8253183 >> >> Please especially review my new comments in the code. The authors of the surrounding code in objectMonitor.cpp and >> synchronizer.cpp may know better. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > rename loadload_for_iriw to loadload_for_IRIW Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/387 From dholmes at openjdk.java.net Wed Sep 30 00:43:13 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 30 Sep 2020 00:43:13 GMT Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 14:08:49 GMT, Monica Beckwith wrote: >> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html >> >> Changes since then: >> * We've improved the write barrier as suggested by Andrew [1] >> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but >> will be required for the upcoming macOS+Aarch64 [2] port as well. >> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the >> Windows-specific CPU feature detection on top of it. >> >> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html >> [2] https://openjdk.java.net/jeps/8251280 > > Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: > > change string representation for r18 to "r18_tls" on every platform Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/212 From david.holmes at oracle.com Wed Sep 30 00:52:37 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Sep 2020 10:52:37 +1000 Subject: RFR: 8253740: [PPC64] Minor interpreter cleanup In-Reply-To: References: <9ENQcPBWCaewPezO3ObXyRtvAW2464wWrYmn6eBExYs=.714ecad9-fca8-40a3-9f41-72875f70e54f@github.com> Message-ID: <5d2f4029-9e92-97e8-130d-499402740e70@oracle.com> On 29/09/2020 10:52 pm, Martin Doerr wrote: > On Tue, 29 Sep 2020 09:12:37 GMT, Martin Doerr wrote: > >>> This looks good but I also noticed that ppc and s390 pass an extra parameter to InterpreterRuntime::monitorenter() also. >> >> That's an interesting point: call_VM(monitorenter) uses check_for_exceptions=true on PPC64 and >> check_for_exceptions=false on s390. check_for_exceptions=true is default, so it's equivalent to omitting the explicit >> parameter. So PPC64 is implemented like x86 in this matter. Seems like we have optimized the exception check out for >> s390. This should be valid because monitorenter uses JRT_ENTRY_NO_ASYNC and doesn't throw any exception. Note that the >> JIT compiler's version uses assert(!HAS_PENDING_EXCEPTION, "Should have no exception here") in >> SharedRuntime::monitor_enter_helper. (monitor_enter_helper uses the CHECK macro which does the check for an exception, >> but this looks like a bug.) I think we could assert that in the interpreter's version and use >> check_for_exceptions=false on all platforms. It's probably not worth optimizing this, but maybe it'd be a good >> simplification wrt. complexity and readability of the gererated assembly code. At least, it'd be nice to bring the >> interpreter and the compiler version closer together. But that's a bit out of scope for this issue. > > Hi David, > thanks for reminding me of JVMTI event callbacks. So we need to check s390 code. > And in SharedRuntime::monitor_enter_helper it doesn't make sense to use CHECK macro and then > assert(!HAS_PENDING_EXCEPTION, "Should have no exception here"). But this is unrelated to this PPC64 cleanup change. The assert is somewhat redundant but not wrong, as it it is validating that the CHECK macro actually worked: ObjectSynchronizer::enter(h_obj, lock, CHECK); assert(!HAS_PENDING_EXCEPTION, "Should have no exception here"); expands to: ObjectSynchronizer::enter(h_obj, lock); if (HAS_PENDING_EXCEPTION) return; assert(!HAS_PENDING_EXCEPTION, "Should have no exception here"); Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/385 > From jiefu at openjdk.java.net Wed Sep 30 03:36:11 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 30 Sep 2020 03:36:11 GMT Subject: RFR: 8223347: Integration of Vector API (Incubator) In-Reply-To: References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com> Message-ID: <-JIanIoqecCK7WfRPElGiS9Gora2wP3NfpGZ3hNL_Hg=.2ccfa0e9-33c6-430b-9303-66829e97e6ff@github.com> On Tue, 29 Sep 2020 22:00:04 GMT, Erik Joelsson wrote: >> This pull request is for integration of the Vector API. It was previously reviewed under conditions when mercurial was >> used for the source code control system. Review threads can be found here (searching for issue number 8223347 in the >> title): https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/thread.html >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/thread.html >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/thread.html >> >> If mercurial was still being used the code would be pushed directly, once the CSR is approved. However, in this case a >> pull request is required and needs explicit reviewer approval. Between the final review and this pull request no code >> has changed, except for that related to merging. > > Build changes look ok. Hi @PaulSandoz , This integration seems to miss https://github.com/openjdk/panama-vector/pull/1, which had fixed crashes on AVX512 machines. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/367 From minqi at openjdk.java.net Wed Sep 30 04:59:20 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 30 Sep 2020 04:59:20 GMT Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v7] In-Reply-To: References: Message-ID: > This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous > webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the > regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses > function. Tests: tier1-4 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Remove trailing word of line which is not used in holder class regeneration. There is a trailing LF (Line Feed) so trim white spaces from both front and end of the line or it will fail method type validation. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/193/files - new: https://git.openjdk.java.net/jdk/pull/193/files/9ab52116..9b0f523b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=05-06 Stats: 22 lines in 2 files changed: 10 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/193.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193 PR: https://git.openjdk.java.net/jdk/pull/193 From jbhateja at openjdk.java.net Wed Sep 30 05:12:01 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 30 Sep 2020 05:12:01 GMT Subject: Integrated: 8253721: Flag -XX:AVX3Threshold does not accept Zero value In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 05:53:39 GMT, Jatin Bhateja wrote: > AVX3Threshold has been used in various places to enable emitting AVX3 specific instructions in case data size being > worked over is greater than 4096 bytes. > However, user is free to set the threshold value to Zero based on his workload. > In such a case a compile time check is enough to trigger generation of AVX3 instructions. In other cases comparison is > done at the runtime though JITed comparison instruction. > Patch allows setting AVX3Threshold to a zero value. This pull request has now been integrated. Changeset: ac02afe9 Author: Jatin Bhateja URL: https://git.openjdk.java.net/jdk/commit/ac02afe9 Stats: 23 lines in 7 files changed: 13 ins; 10 del; 0 mod 8253721: Flag -XX:AVX3Threshold does not accept Zero value Reviewed-by: kvn, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/394 From lucy at openjdk.java.net Wed Sep 30 05:54:42 2020 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 30 Sep 2020 05:54:42 GMT Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 19:33:48 GMT, Paul Hohensee wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since > the last revision: > - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch > - Merge branch 'master' into JDK-8253375 > - JDK-8253375 I just copied the declaration and oversaw that tiny little '&'. With it, sharedRuntime.cpp compiles fine. Sorry for not being careful enough. Reviewed. ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/348 From eric.c.liu at arm.com Wed Sep 30 07:30:49 2020 From: eric.c.liu at arm.com (Eric Liu) Date: Wed, 30 Sep 2020 07:30:49 +0000 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> , Message-ID: Hi Kim, Thanks for your review. I tried to solve the problem with your suggestion, and have just one question. > On 29 September 2020 18:51 PM, Kim Barrett wrote: > I don't think using memory functions in place of string functions for string > manipulation is really an improvement. Yes, the original code has no problem basically but as you said asan seems incompatible with -Wstringop-truncation. Using 'memcpy' just a workaround. > I did a bit of experimenting. > > With gcc10.2, and using the --enable-asan configure option, we get a > -Wstringop-truncation warning in CompilerCounters::set_current_method, even > after careful adjustment of the code to use the documented idiom for > avoiding that warning. > > I initially wondered whether this might be only in fastdebug builds, where > we also define _FORTIFY_SOURCE=2.? The asan faq > https://github.com/google/sanitizers/wiki/AddressSanitizer#faq > says asan doesn't work well with _FORTIFY_SOURCE. > > But the same warning occurs in a release build, where we aren't defining > _FORTIFY_SOURCE. > At this point all I can conclude is that --enable-asan (i.e. > -fsanitize=address) is simply incompatible with -Wstringop-truncation, at > least through gcc10.? That seems like a bug that someone should report. > (Might be same as or related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650) > > We don't normally build with -fsanitize=address; that's something that > someone might want to turn on sometimes for testing or debugging, but I > don't think we're planning to have it always on, even in debug builds. > Since it seems to be incompatible with various other options that we *do* > normally use, I think the way to allow --enable-asan to be (possibly) usable > is in the build system at configure time. That is, the --enable-asan > configure option should, in addition to adding -fsanitize=address, also (1) > disable -Wstringop-truncation and (2) disable the defining of > _FORTIFY_SOURCE in fastdebug builds.? It looks like making those changes > involves conditionalizing their addition/removal using ${ASAN_ENABLED}. Disable -Wstringop-truncation seems more reasonable. Is that necessary to disable _FORTIFY_SOURCE in fastdebug? With gcc10.1, disable -Wstringop-truncation seems enough. I didn't test with fastdebug mode before, and now it has been tested in our internal both with release and fastdebug mode. Thanks, Eric From felix.yang at huawei.com Wed Sep 30 08:25:54 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 30 Sep 2020 08:25:54 +0000 Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: Message-ID: Hi, > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > retn at openjdk.java.net] On Behalf Of Andrew Haley > Sent: Tuesday, September 29, 2020 5:25 PM > To: core-libs-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; > hotspot-compiler-dev at openjdk.java.net; security-dev at openjdk.java.net > Subject: Re: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic > > On Thu, 17 Sep 2020 06:03:57 GMT, Ard Biesheuvel > wrote: > > >> @ardbiesheuvel : Ard, could you please ack this patch? Thanks. > > > > Acked-by: Ard Biesheuvel > > > If this feature is not auto-enabled when the SHA3 hardware feature is > > there, we will have one failure for the following > > test: > > test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsOp > > tionOnSupportedCPU.java > > 15 #-----testresult----- > > 16 > > description=file:/home/yangfei/github/jdk/test/hotspot/jtreg/compiler/ > > intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java > > 17 elapsed=31546 0:00:31.546 18 end=Mon Sep 21 10:27:58 CST 2020 > > 19 environment=regtest > > 20 execStatus=Failed. Execution failed: `main' threw exception: > > java.lang.AssertionError: Option 'UseSHA3Intrinsics' is expected to > > have 'true' value Option 'UseSHA3Intrinsics' should be enabled by default > Any suggestions for this? > > I don't understand your question. There should be two acceptable results, > either "Pass" or "Not supported". What else is possible? This new test is similar to existing test cases in the same directory like: TestUseSHA256IntrinsicsOptionOnSupportedCPU.java Currently, we ran this new test using QEMU which supports the aarch64 SHA3 feature. This new test is expecting option 'UseSHA3Intrinsics' to be auto-enabled by the JVM when it detects the availability of SHA3 feature. But that was not satisfied since we explicitly disable this option even when SHA3 feature is available. + if (UseSHA && (_features & CPU_SHA3)) { + // Do not auto-enable UseSHA3Intrinsics until it has been fully tested on hardware + // if (FLAG_IS_DEFAULT(UseSHA3Intrinsics)) { + // FLAG_SET_DEFAULT(UseSHA3Intrinsics, true); + // } So I could thought of several choices: 1. Do not add this new test for now; 2. Keep this new test and add on extra requirement for it: @requires os.arch!="aarch64"; (We could remove this when UseSHA3Intrinsics has been fully tested on real hardware and thus could be auto-enabled.) 3. Auto-enable UseSHA3Intrinsics when SHA3 feature is available for now; Is there a better way? Thanks, Felix From felix.yang at huawei.com Wed Sep 30 08:28:13 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 30 Sep 2020 08:28:13 +0000 Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: Message-ID: Hi, > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-retn at openjdk.java.net] On Behalf > Of Valerie Peng > Sent: Wednesday, September 30, 2020 6:25 AM > To: core-libs-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; > hotspot-compiler-dev at openjdk.java.net; security-dev at openjdk.java.net > Subject: Re: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic > > On Tue, 29 Sep 2020 09:22:25 GMT, Andrew Haley > wrote: > > >> Acked-by: Ard Biesheuvel > > > >> If this feature is not auto-enabled when the SHA3 hardware feature is > >> there, we will have one failure for the following > >> test: > >> test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA3IntrinsicsO > >> ptionOnSupportedCPU.java > >> 15 #-----testresult----- > >> 16 > >> description=file:/home/yangfei/github/jdk/test/hotspot/jtreg/compiler > >> /intrinsics/sha/cli/TestUseSHA3IntrinsicsOptionOnSupportedCPU.java > >> 17 elapsed=31546 0:00:31.546 18 end=Mon Sep 21 10:27:58 CST 2020 > >> 19 environment=regtest > >> 20 execStatus=Failed. Execution failed: `main' threw exception: > >> java.lang.AssertionError: Option 'UseSHA3Intrinsics' is expected to > >> have 'true' value Option 'UseSHA3Intrinsics' should be enabled by default > Any suggestions for this? > > > > I don't understand your question. There should be two acceptable > > results, either "Pass" or "Not supported". What else is possible? > > I have looked at the java security changes, i.e. > src/java.base/share/classes/sun/security/provider/SHA3.java. It looks fine. Thanks for reviewing this part. Best Regards, Felix From mdoerr at openjdk.java.net Wed Sep 30 09:05:36 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 30 Sep 2020 09:05:36 GMT Subject: Integrated: 8253183: Fragile memory barrier selection for some weak memory model platforms In-Reply-To: References: Message-ID: On Mon, 28 Sep 2020 21:11:04 GMT, Martin Doerr wrote: > Hi, I'd like to propose a fix after the discussion in https://bugs.openjdk.java.net/browse/JDK-8253183 > > Please especially review my new comments in the code. The authors of the surrounding code in objectMonitor.cpp and > synchronizer.cpp may know better. This pull request has now been integrated. Changeset: dc3a0f5f Author: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/dc3a0f5f Stats: 32 lines in 4 files changed: 11 ins; 9 del; 12 mod 8253183: Fragile memory barrier selection for some weak memory model platforms Reviewed-by: dholmes, eosterlund, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/387 From stuefe at openjdk.java.net Wed Sep 30 10:18:39 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 30 Sep 2020 10:18:39 GMT Subject: RFR: 8253650: Cleanup: remove alignment_hint parameter from os::reserve_memory Message-ID: Hi all, since ancient times os::reserve_memory() carried around an "alignment_hint" parameter. It was undocumented but from the name it suggests it would cause os::reserve_memory() to try to align the start of the mapping to a given alignment. However, the only platform ever doing anything with this parameter was AIX, and there only in mmap() mode. All other platforms ignored the parameter. So it can be removed, provided we fix the AIX case. Notes: - if one really needs alignment memory, there is os::reserve_memory_aligned() which guarantees the alignment. It will do the usual over-reserving-and-chopping-away to do that. - On AIX there is a second reason why we align the mmap() result pointer to 64K, since we "fake" 64K pages in some places. I disentangled that alignment handling from the caller provided alignment. - This affects os::reserve_memory() as well as the new os::reserve_memory_with_fd() - I also fixed comments in virtualSpace.cpp which do not apply anymore after JDK-8253638 Tests: tier1, manual builds and tests on AIX ------------- Commit messages: - Fix AIX build error - JDK-8253650-remove-alignment-hint-from-os-reserve Changes: https://git.openjdk.java.net/jdk/pull/430/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=430&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253650 Stats: 86 lines in 12 files changed: 4 ins; 37 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/430.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/430/head:pull/430 PR: https://git.openjdk.java.net/jdk/pull/430 From mdoerr at openjdk.java.net Wed Sep 30 10:19:42 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 30 Sep 2020 10:19:42 GMT Subject: RFR: 8253740: [PPC64] Minor interpreter cleanup [v2] In-Reply-To: <9ENQcPBWCaewPezO3ObXyRtvAW2464wWrYmn6eBExYs=.714ecad9-fca8-40a3-9f41-72875f70e54f@github.com> References: <9ENQcPBWCaewPezO3ObXyRtvAW2464wWrYmn6eBExYs=.714ecad9-fca8-40a3-9f41-72875f70e54f@github.com> Message-ID: > Template interpreter on PPC64 can be cleaned up after JDK-8253540: > unlock_object has a parameter check_for_exceptions which is now unused. > > In addition to that, restore_interpreter_state is redundant after > call_VM(R4_ARG2, CAST_FROM_FN_PTR(address, InterpreterRuntime::member_name_arg_or_null) because it's already included > in call_VM. > https://bugs.openjdk.java.net/browse/JDK-8253740 Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: call_VM usages: Remove some explicit /*check_exceptions=*/true parameters which match default value. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/385/files - new: https://git.openjdk.java.net/jdk/pull/385/files/aa3dea5c..cda67a54 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=385&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=385&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/385.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/385/head:pull/385 PR: https://git.openjdk.java.net/jdk/pull/385 From mdoerr at openjdk.java.net Wed Sep 30 10:23:04 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 30 Sep 2020 10:23:04 GMT Subject: RFR: 8253740: [PPC64] Minor interpreter cleanup In-Reply-To: References: <9ENQcPBWCaewPezO3ObXyRtvAW2464wWrYmn6eBExYs=.714ecad9-fca8-40a3-9f41-72875f70e54f@github.com> Message-ID: On Tue, 29 Sep 2020 12:50:12 GMT, Martin Doerr wrote: >> That's an interesting point: call_VM(monitorenter) uses check_for_exceptions=true on PPC64 and >> check_for_exceptions=false on s390. check_for_exceptions=true is default, so it's equivalent to omitting the explicit >> parameter. So PPC64 is implemented like x86 in this matter. Seems like we have optimized the exception check out for >> s390. This should be valid because monitorenter uses JRT_ENTRY_NO_ASYNC and doesn't throw any exception. Note that the >> JIT compiler's version uses assert(!HAS_PENDING_EXCEPTION, "Should have no exception here") in >> SharedRuntime::monitor_enter_helper. (monitor_enter_helper uses the CHECK macro which does the check for an exception, >> but this looks like a bug.) I think we could assert that in the interpreter's version and use >> check_for_exceptions=false on all platforms. It's probably not worth optimizing this, but maybe it'd be a good >> simplification wrt. complexity and readability of the gererated assembly code. At least, it'd be nice to bring the >> interpreter and the compiler version closer together. But that's a bit out of scope for this issue. > > Hi David, > thanks for reminding me of JVMTI event callbacks. So we need to check s390 code. > And in SharedRuntime::monitor_enter_helper it doesn't make sense to use CHECK macro and then > assert(!HAS_PENDING_EXCEPTION, "Should have no exception here"). But this is unrelated to this PPC64 cleanup change. Hi Coleen, I've removed the explicit check_exceptions=true parameters on PPC64 so it looks more like x86. I'll take a look at s390 separately. Hi David, the assert(!HAS_PENDING_EXCEPTION, "Should have no exception here") is not wrong, but confusing IMHO. Thanks for looking at this. ------------- PR: https://git.openjdk.java.net/jdk/pull/385 From kim.barrett at oracle.com Wed Sep 30 10:23:50 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 30 Sep 2020 06:23:50 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> Message-ID: > On Sep 30, 2020, at 3:30 AM, Eric Liu wrote: > > Hi Kim, > > Thanks for your review. > I tried to solve the problem with your suggestion, and have just one question. > >> On 29 September 2020 18:51 PM, Kim Barrett wrote: >> With gcc10.2, and using the --enable-asan configure option, we get a >> -Wstringop-truncation warning in CompilerCounters::set_current_method, even >> after careful adjustment of the code to use the documented idiom for >> avoiding that warning. >> >> I initially wondered whether this might be only in fastdebug builds, where >> we also define _FORTIFY_SOURCE=2. The asan faq >> https://urldefense.com/v3/__https://github.com/google/sanitizers/wiki/AddressSanitizer*faq__;Iw!!GqivPVa7Brio!IFzpRJ6UwKlp2que6K1FLh9xe_Oe3s-shyGmlz3pzFTlEyZwdqk7yjfH_uovCn8U$ >> says asan doesn't work well with _FORTIFY_SOURCE. >> >> But the same warning occurs in a release build, where we aren't defining >> _FORTIFY_SOURCE. > >> At this point all I can conclude is that --enable-asan (i.e. >> -fsanitize=address) is simply incompatible with -Wstringop-truncation, at >> least through gcc10. That seems like a bug that someone should report. >> (Might be same as or related to https://urldefense.com/v3/__https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650__;!!GqivPVa7Brio!IFzpRJ6UwKlp2que6K1FLh9xe_Oe3s-shyGmlz3pzFTlEyZwdqk7yjfH_sMh77QA$ ) >> >> We don't normally build with -fsanitize=address; that's something that >> someone might want to turn on sometimes for testing or debugging, but I >> don't think we're planning to have it always on, even in debug builds. > >> Since it seems to be incompatible with various other options that we *do* >> normally use, I think the way to allow --enable-asan to be (possibly) usable >> is in the build system at configure time. That is, the --enable-asan >> configure option should, in addition to adding -fsanitize=address, also (1) >> disable -Wstringop-truncation and (2) disable the defining of >> _FORTIFY_SOURCE in fastdebug builds. It looks like making those changes >> involves conditionalizing their addition/removal using ${ASAN_ENABLED}. > > Disable -Wstringop-truncation seems more reasonable. > Is that necessary to disable _FORTIFY_SOURCE in fastdebug? With gcc10.1, > disable -Wstringop-truncation seems enough. > > I didn't test with fastdebug mode before, and now it has been tested in our internal > both with release and fastdebug mode. My suggestiion that _FORTIFY_SOURCE should be disabled too is based on what the ASan FAQ and various bug reports and related threads say, which seems to be that combining ASan and _FORTIFY_SOURCE can cause problems to be missed and can lead to very strange fortify warnings. I found a couple of threads from a few years ago suggesting that maybe ASan should have interceptors for the fortify functions, but didn?t find any indication that?s actually happened. If it has, then the combination is presumably no longer problematic. From stefank at openjdk.java.net Wed Sep 30 11:03:44 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 30 Sep 2020 11:03:44 GMT Subject: RFR: 8253650: Cleanup: remove alignment_hint parameter from os::reserve_memory In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 10:08:09 GMT, Thomas Stuefe wrote: > Hi all, > > since ancient times os::reserve_memory() carried around an "alignment_hint" parameter. It was undocumented but from the > name it suggests it would cause os::reserve_memory() to try to align the start of the mapping to a given alignment. > However, the only platform ever doing anything with this parameter was AIX, and there only in mmap() mode. All other > platforms ignored the parameter. So it can be removed, provided we fix the AIX case. > Notes: > - if one really needs alignment memory, there is os::reserve_memory_aligned() which guarantees the alignment. It will do > the usual over-reserving-and-chopping-away to do that. > - On AIX there is a second reason why we align the mmap() result pointer to 64K, since we "fake" 64K pages in some > places. I disentangled that alignment handling from the caller provided alignment. > - This affects os::reserve_memory() as well as the new os::reserve_memory_with_fd() > - I also fixed comments in virtualSpace.cpp which do not apply anymore after JDK-8253638 > > Tests: tier1, manual builds and tests on AIX Great! Thanks for cleaning this up. I'm glad that you took care of this, since you know about the AIX code and its history. I've marked some nits that you might want to clean up with this patch. src/hotspot/share/memory/virtualspace.cpp line 377: > 375: base = os::attempt_reserve_memory_at(requested_address, size, _fd_for_heap); > 376: } else { > 377: // Optimistically assume that the OSes returns an aligned base pointer. Pre-existing, but maybe change "OSes returns" to "OSes return" src/hotspot/os/posix/os_posix.cpp line 321: > 319: // For file mapping, we do not call os:reserve_memory() because > 320: // we need to deal with shrinking of the file space later when we release extra memory after alignment. > 321: // We also cannot called os:reserve_memory() with file_desc set to -1 because on aix we might get SHM memory. Pre-existing: "Cannot called " => "Cannot call" ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/430 From stefank at openjdk.java.net Wed Sep 30 11:03:44 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 30 Sep 2020 11:03:44 GMT Subject: RFR: 8253650: Cleanup: remove alignment_hint parameter from os::reserve_memory In-Reply-To: References: Message-ID: <_nzQjd-wbnTZWwWPSMBTovEbxVh_DkHkds5czreU4Y8=.55352c19-2f27-434f-a48b-3971efd35e66@github.com> On Wed, 30 Sep 2020 10:57:37 GMT, Stefan Karlsson wrote: >> Hi all, >> >> since ancient times os::reserve_memory() carried around an "alignment_hint" parameter. It was undocumented but from the >> name it suggests it would cause os::reserve_memory() to try to align the start of the mapping to a given alignment. >> However, the only platform ever doing anything with this parameter was AIX, and there only in mmap() mode. All other >> platforms ignored the parameter. So it can be removed, provided we fix the AIX case. >> Notes: >> - if one really needs alignment memory, there is os::reserve_memory_aligned() which guarantees the alignment. It will do >> the usual over-reserving-and-chopping-away to do that. >> - On AIX there is a second reason why we align the mmap() result pointer to 64K, since we "fake" 64K pages in some >> places. I disentangled that alignment handling from the caller provided alignment. >> - This affects os::reserve_memory() as well as the new os::reserve_memory_with_fd() >> - I also fixed comments in virtualSpace.cpp which do not apply anymore after JDK-8253638 >> >> Tests: tier1, manual builds and tests on AIX > > src/hotspot/os/posix/os_posix.cpp line 321: > >> 319: // For file mapping, we do not call os:reserve_memory() because >> 320: // we need to deal with shrinking of the file space later when we release extra memory after alignment. >> 321: // We also cannot called os:reserve_memory() with file_desc set to -1 because on aix we might get SHM memory. > > Pre-existing: "Cannot called " => "Cannot call" and maybe os::reserve_memory() => os::reserve_memory_with_fd() ------------- PR: https://git.openjdk.java.net/jdk/pull/430 From magnus.ihse.bursie at oracle.com Wed Sep 30 11:09:20 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 30 Sep 2020 13:09:20 +0200 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <2E08727F-E790-4B7F-82EC-FAE9031C7E16@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> <2E08727F-E790-4B7F-82EC-FAE9031C7E16@oracle.com> Message-ID: <0ffa79c3-bff2-cd65-0f00-df16e573cb45@oracle.com> On 2020-09-29 13:17, Kim Barrett wrote: >> On Sep 29, 2020, at 6:51 AM, Kim Barrett wrote: >> >>> On Sep 28, 2020, at 11:13 AM, Eric Liu wrote: >>> >>> Hi, >>> >>> Thanks for looking at this. >>> >>> For gcc-10, it's hard to make 'strncpy' all right with asan enabled (approaches we talked previous don't work). >>> I'm trying to find a better way to avoid using compile pragma. I suppose it would be better to use 'memcpy' >>> to replace 'strncpy'. >>> >>> >>> Thanks, >>> Eric >> [?] >> At this point all I can conclude is that --enable-asan (i.e. >> -fsanitize=address) is simply incompatible with -Wstringop-truncation, at >> least through gcc10. That seems like a bug that someone should report. >> (Might be same as or related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650) >> >> [?] >> >> Since it seems to be incompatible with various other options that we *do* >> normally use, I think the way to allow --enable-asan to be (possibly) usable >> is in the build system at configure time. That is, the --enable-asan >> configure option should, in addition to adding -fsanitize=address, also (1) >> disable -Wstringop-truncation and (2) disable the defining of >> _FORTIFY_SOURCE in fastdebug builds. It looks like making those changes >> involves conditionalizing their addition/removal using ${ASAN_ENABLED}. >> >> Scattering pragmas for disabling -Wstringop-truncation doesn't cut it. > Another option might be to solve https://bugs.openjdk.java.net/browse/JDK-8232187 > Will that really help? If a os::strncpy_s method is added to hotspot, how should NetworkInterface.c in libnet be able to use it? /Magnus From stuefe at openjdk.java.net Wed Sep 30 12:02:27 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 30 Sep 2020 12:02:27 GMT Subject: RFR: 8253650: Cleanup: remove alignment_hint parameter from os::reserve_memory In-Reply-To: <_nzQjd-wbnTZWwWPSMBTovEbxVh_DkHkds5czreU4Y8=.55352c19-2f27-434f-a48b-3971efd35e66@github.com> References: <_nzQjd-wbnTZWwWPSMBTovEbxVh_DkHkds5czreU4Y8=.55352c19-2f27-434f-a48b-3971efd35e66@github.com> Message-ID: <1BwvWz8Xe-oQGN8-aEUObAb-Vl9n_nSIj2BJC9gBK8g=.cdc6064f-b1bb-4270-a80a-42c0aebcc8dc@github.com> On Wed, 30 Sep 2020 10:58:05 GMT, Stefan Karlsson wrote: >> src/hotspot/os/posix/os_posix.cpp line 321: >> >>> 319: // For file mapping, we do not call os:reserve_memory() because >>> 320: // we need to deal with shrinking of the file space later when we release extra memory after alignment. >>> 321: // We also cannot called os:reserve_memory() with file_desc set to -1 because on aix we might get SHM memory. >> >> Pre-existing: "Cannot called " => "Cannot call" > > and maybe os::reserve_memory() => os::reserve_memory_with_fd() That comment is all over the place :) I'll try to fix it up ------------- PR: https://git.openjdk.java.net/jdk/pull/430 From hohensee at amazon.com Wed Sep 30 12:15:07 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 30 Sep 2020 12:15:07 +0000 Subject: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2] Message-ID: <364A2F2E-E8C9-4A83-94EF-D067280FE037@amazon.com> Thanks, Lutz! ?On 9/29/20, 10:56 PM, "build-dev on behalf of Lutz Schmidt" wrote: On Tue, 29 Sep 2020 19:33:48 GMT, Paul Hohensee wrote: >> Please review this small patch to enable the OSX build using Xcode 12.0. >> >> Thanks, >> Paul > > Paul Hohensee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev > excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since > the last revision: > - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch > - Merge branch 'master' into JDK-8253375 > - JDK-8253375 I just copied the declaration and oversaw that tiny little '&'. With it, sharedRuntime.cpp compiles fine. Sorry for not being careful enough. Reviewed. ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/348 From phh at openjdk.java.net Wed Sep 30 12:19:01 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Wed, 30 Sep 2020 12:19:01 GMT Subject: Integrated: 8253375: OSX build fails with Xcode 12.0 (12A7209) In-Reply-To: References: Message-ID: <-aDiMyf9VRdCWuDRYzuFLBKq2amMJspLw7Cnqt1hhTg=.404ceda1-f8a3-4b99-9a38-269da1939573@github.com> On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee wrote: > Please review this small patch to enable the OSX build using Xcode 12.0. > > Thanks, > Paul This pull request has now been integrated. Changeset: f80a6066 Author: Paul Hohensee URL: https://git.openjdk.java.net/jdk/commit/f80a6066 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8253375: OSX build fails with Xcode 12.0 (12A7209) Replace double array with short array in AdapterHandlerLibrary::create_native_wrapper, add parens around ?: in CSystemColors:getColor Reviewed-by: prr, kbarrett, lucy ------------- PR: https://git.openjdk.java.net/jdk/pull/348 From kim.barrett at oracle.com Wed Sep 30 12:19:15 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 30 Sep 2020 08:19:15 -0400 Subject: RFR(S): 8252407: Build failure with gcc-8+ and asan In-Reply-To: <0ffa79c3-bff2-cd65-0f00-df16e573cb45@oracle.com> References: <14FC5FA8-7BFF-43E0-B997-61283FA0B35C@oracle.com> <5B914D4B-3771-48D8-A649-9D2247E03F83@oracle.com> <6BDA4364-29C3-49A6-85B1-CAB5509145AF@oracle.com> <2E08727F-E790-4B7F-82EC-FAE9031C7E16@oracle.com> <0ffa79c3-bff2-cd65-0f00-df16e573cb45@oracle.com> Message-ID: <4FD74735-D627-4587-8CC0-CFF21F4FF71C@oracle.com> > On Sep 30, 2020, at 7:09 AM, Magnus Ihse Bursie wrote: > > > > On 2020-09-29 13:17, Kim Barrett wrote: >> Another option might be to solve https://bugs.openjdk.java.net/browse/JDK-8232187 >> > Will that really help? If a os::strncpy_s method is added to hotspot, how should NetworkInterface.c in libnet be able to use it? > > /Magnus That?s already mentioned in the comments for that bug. A real solution needs to figure out a solution to that part too. So not an easy solve. Also as mentioned in the comments, strncpy_s might not be the right API to provide. strscpy might be better. It might be that bug report should be retitled and the description rewritten. From stefank at openjdk.java.net Wed Sep 30 12:28:36 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 30 Sep 2020 12:28:36 GMT Subject: RFR: 8253650: Cleanup: remove alignment_hint parameter from os::reserve_memory In-Reply-To: <1BwvWz8Xe-oQGN8-aEUObAb-Vl9n_nSIj2BJC9gBK8g=.cdc6064f-b1bb-4270-a80a-42c0aebcc8dc@github.com> References: <_nzQjd-wbnTZWwWPSMBTovEbxVh_DkHkds5czreU4Y8=.55352c19-2f27-434f-a48b-3971efd35e66@github.com> <1BwvWz8Xe-oQGN8-aEUObAb-Vl9n_nSIj2BJC9gBK8g=.cdc6064f-b1bb-4270-a80a-42c0aebcc8dc@github.com> Message-ID: On Wed, 30 Sep 2020 12:00:06 GMT, Thomas Stuefe wrote: >> and maybe os::reserve_memory() => os::reserve_memory_with_fd() > > That comment is all over the place :) > I'll try to fix it up Thanks. I should have fixed it when I touched this code. ------------- PR: https://git.openjdk.java.net/jdk/pull/430 From stuefe at openjdk.java.net Wed Sep 30 12:34:45 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 30 Sep 2020 12:34:45 GMT Subject: RFR: 8253650: Cleanup: remove alignment_hint parameter from os::reserve_memory [v2] In-Reply-To: References: Message-ID: > Hi all, > > since ancient times os::reserve_memory() carried around an "alignment_hint" parameter. It was undocumented but from the > name it suggests it would cause os::reserve_memory() to try to align the start of the mapping to a given alignment. > However, the only platform ever doing anything with this parameter was AIX, and there only in mmap() mode. All other > platforms ignored the parameter. So it can be removed, provided we fix the AIX case. > Notes: > - if one really needs alignment memory, there is os::reserve_memory_aligned() which guarantees the alignment. It will do > the usual over-reserving-and-chopping-away to do that. > - On AIX there is a second reason why we align the mmap() result pointer to 64K, since we "fake" 64K pages in some > places. I disentangled that alignment handling from the caller provided alignment. > - This affects os::reserve_memory() as well as the new os::reserve_memory_with_fd() > - I also fixed comments in virtualSpace.cpp which do not apply anymore after JDK-8253638 > > Tests: tier1, manual builds and tests on AIX Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Comment fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/430/files - new: https://git.openjdk.java.net/jdk/pull/430/files/bc4caa9d..d02225e7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=430&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=430&range=00-01 Stats: 10 lines in 2 files changed: 4 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/430.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/430/head:pull/430 PR: https://git.openjdk.java.net/jdk/pull/430 From stuefe at openjdk.java.net Wed Sep 30 12:34:46 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 30 Sep 2020 12:34:46 GMT Subject: RFR: 8253650: Cleanup: remove alignment_hint parameter from os::reserve_memory [v2] In-Reply-To: References: <_nzQjd-wbnTZWwWPSMBTovEbxVh_DkHkds5czreU4Y8=.55352c19-2f27-434f-a48b-3971efd35e66@github.com> <1BwvWz8Xe-oQGN8-aEUObAb-Vl9n_nSIj2BJC9gBK8g=.cdc6064f-b1bb-4270-a80a-42c0aebcc8dc@github.com> Message-ID: <_XV-UkSYYld6_UNX6zFt1kuWdh3XnlDoBS19Ca0_GrQ=.58c34724-93df-4e6e-aac8-854593893069@github.com> On Wed, 30 Sep 2020 12:25:59 GMT, Stefan Karlsson wrote: >> That comment is all over the place :) >> I'll try to fix it up > > Thanks. I should have fixed it when I touched this code. Oh no problem. I dove into the history and now remember all that file descriptor stuff came with JEP 316, and I had been unhappy about the implementation back then. I opened JDK-8253851 to track some cleanups. ------------- PR: https://git.openjdk.java.net/jdk/pull/430 From coleenp at openjdk.java.net Wed Sep 30 12:47:46 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 30 Sep 2020 12:47:46 GMT Subject: RFR: 8253433: Remove -XX:+Debugging product option Message-ID: The Debugging option shouldn't be used on the command line. There's a SuppressErrorAt option to ignore certain asserts, if there is some situation needing that. Debugging should never be used. Tested with tier1 tests on 4 platforms. ------------- Commit messages: - Remove Debugging option - 8253433: Change -XX:+Debugging from a product to a diagnostic option Changes: https://git.openjdk.java.net/jdk/pull/434/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=434&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253433 Stats: 15 lines in 4 files changed: 8 ins; 4 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/434.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/434/head:pull/434 PR: https://git.openjdk.java.net/jdk/pull/434 From coleenp at openjdk.java.net Wed Sep 30 12:47:46 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 30 Sep 2020 12:47:46 GMT Subject: RFR: 8253433: Remove -XX:+Debugging product option In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 12:38:30 GMT, Coleen Phillimore wrote: > The Debugging option shouldn't be used on the command line. There's a SuppressErrorAt option to ignore certain > asserts, if there is some situation needing that. Debugging should never be used. > Tested with tier1 tests on 4 platforms. CSR: https://bugs.openjdk.java.net/browse/JDK-8253501 bug (I don't see linked here): https://bugs.openjdk.java.net/browse/JDK-8253433 ------------- PR: https://git.openjdk.java.net/jdk/pull/434 From coleenp at openjdk.java.net Wed Sep 30 12:47:47 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 30 Sep 2020 12:47:47 GMT Subject: RFR: 8253433: Remove -XX:+Debugging product option In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 12:41:54 GMT, Coleen Phillimore wrote: >> The Debugging option shouldn't be used on the command line. There's a SuppressErrorAt option to ignore certain >> asserts, if there is some situation needing that. Debugging should never be used. >> Tested with tier1 tests on 4 platforms. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8253501 > bug (I don't see linked here): https://bugs.openjdk.java.net/browse/JDK-8253433 Used the wrong bug number. ------------- PR: https://git.openjdk.java.net/jdk/pull/434 From stuefe at openjdk.java.net Wed Sep 30 13:00:23 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 30 Sep 2020 13:00:23 GMT Subject: RFR: 8253433: Remove -XX:+Debugging product option In-Reply-To: References: Message-ID: <1ZK-LcMEZ8V5AT0f0OlfhLeenamSKAqBuNoLOY22qiU=.046822aa-9e07-453b-9a6b-a7da663c5058@github.com> On Wed, 30 Sep 2020 12:38:30 GMT, Coleen Phillimore wrote: > The Debugging option shouldn't be used on the command line. There's a SuppressErrorAt option to ignore certain > asserts, if there is some situation needing that. Debugging should never be used. > Tested with tier1 tests on 4 platforms. src/hotspot/share/utilities/debug.cpp line 75: > 73: > 74: // Set to suppress secondary error reporting. > 75: bool Debugging = false; How would this work? You would set this while debugging? Does it also work in optimized coding or would the value getting optimized away? Maybe make volatile? ------------- PR: https://git.openjdk.java.net/jdk/pull/434 From kim.barrett at oracle.com Wed Sep 30 13:32:18 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 30 Sep 2020 09:32:18 -0400 Subject: RFR: 8253433: Remove -XX:+Debugging product option In-Reply-To: <1ZK-LcMEZ8V5AT0f0OlfhLeenamSKAqBuNoLOY22qiU=.046822aa-9e07-453b-9a6b-a7da663c5058@github.com> References: <1ZK-LcMEZ8V5AT0f0OlfhLeenamSKAqBuNoLOY22qiU=.046822aa-9e07-453b-9a6b-a7da663c5058@github.com> Message-ID: <2232EF10-0723-4586-9EF4-BE886547E6F3@oracle.com> > On Sep 30, 2020, at 9:00 AM, Thomas Stuefe wrote: > > On Wed, 30 Sep 2020 12:38:30 GMT, Coleen Phillimore wrote: > >> The Debugging option shouldn't be used on the command line. There's a SuppressErrorAt option to ignore certain >> asserts, if there is some situation needing that. Debugging should never be used. >> Tested with tier1 tests on 4 platforms. > > src/hotspot/share/utilities/debug.cpp line 75: > >> 73: >> 74: // Set to suppress secondary error reporting. >> 75: bool Debugging = false; > > How would this work? You would set this while debugging? Does it also work in optimized coding or would the value > getting optimized away? Maybe make volatile? This is really just about the one existing assignment. See the Command context class in debug.cpp. This variable probably shouldn?t be set/reset much of anywhere else. > PR: https://git.openjdk.java.net/jdk/pull/434 From rrich at openjdk.java.net Wed Sep 30 14:25:20 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 30 Sep 2020 14:25:20 GMT Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v5] In-Reply-To: References: Message-ID: > Hi, > > this is the continuation of the review of the implementation for: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references > to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such > optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka > "deoptimization". Webrev.8 was the last one before before the transition to Git/Github: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Thanks, Richard. Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge branch 'master' into JDK-8227745 - Make parameter current_thread of JvmtiEnvBase::check_top_frame() a JavaThread* again. With Asynchronous handshakes the type was changed from JavaThread* to Thread* but this is not necessary as check_top_frame() is not executed during a handshake / safepoint (robehn confirmed). - Merge branch 'master' into JDK-8227745 - EATests.java: bugfix to prevent ObjectCollectedException - Better encapsulation of JvmtiDeferredUpdates. Moved jvmtiDeferredLocalVariableSet to jvmtiDeferredUpdates.hpp - EscapeBarrier: moved method comments. - Shuffled parameters of EscapeBarrier constructors to better match each other - Moved class EscapeBarrier and class JvmtiDeferredUpdates into dedicated files. - Merge branch 'master' into JDK-8227745 - Changes based on dholmes' feedback. EscapeBarrier::sync_and_suspend_all(): - Set suspend flags before handshake because then the setting will be visible after leaving the _thread_blocked state in JavaThread::wait_for_object_deoptimization() JavaThread::wait_for_object_deoptimization() - Reuse SpinYield instead of new custom spinning code. - Do safepoint check after the loop. This is possible because the set_obj_deopt_flag is done before the handshake. - Don't set_suspend_equivalent() anymore for more simplicity. It's just an optimization (that won't pay off here). Added/updated source code comments. Additional smaller enhancements. - ... and 1 more: https://git.openjdk.java.net/jdk/compare/04775f11...af39d5b2 ------------- Changes: https://git.openjdk.java.net/jdk/pull/119/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=04 Stats: 5788 lines in 52 files changed: 5568 ins; 116 del; 104 mod Patch: https://git.openjdk.java.net/jdk/pull/119.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119 PR: https://git.openjdk.java.net/jdk/pull/119 From kbarrett at openjdk.java.net Wed Sep 30 15:32:03 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 30 Sep 2020 15:32:03 GMT Subject: RFR: 8253433: Remove -XX:+Debugging product option In-Reply-To: References: Message-ID: <_NozoRSHMJ8P4p42f-_t7SLR3siJkp-xzUaeKuXZYkM=.d8be3676-d5df-40d6-b17d-f00be0f569c5@github.com> On Wed, 30 Sep 2020 12:38:30 GMT, Coleen Phillimore wrote: > The Debugging option shouldn't be used on the command line. There's a SuppressErrorAt option to ignore certain > asserts, if there is some situation needing that. Debugging should never be used. > Tested with tier1 tests on 4 platforms. Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/434 From kim.barrett at oracle.com Wed Sep 30 15:40:15 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 30 Sep 2020 11:40:15 -0400 Subject: RFR: 8247912: Make narrowOop a scoped enum [v2] In-Reply-To: References: Message-ID: <3637E30D-FCBC-4901-ACCE-6C86110C6708@oracle.com> > On Sep 29, 2020, at 8:42 AM, Stefan Karlsson wrote: > > On Tue, 22 Sep 2020 13:43:54 GMT, Kim Barrett wrote: > >>> Please review this change to the type narrowOop from a typedef for juint to a >>> scoped enum with uint32_t as the representation type. This provides stronger >>> type checking when using this type. >>> >>> For the most part this was fairly straightforward, and the patch size is >>> relatively small. The implementation of some existing CompressedOops >>> "primitives" required adjustment. An explicit conversion to narrowOop was >>> added, with casts change to use it. There were a few places that were type >>> punning and needed explicit conversions,, mostly in platform-specific assembly >>> support. >>> >>> There are a couple of lingering problems. >>> >>> Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass >>> as a narrowOop. I adjusted the code to accommodate the narrowOop change, but >>> this probably ought to be done differently. >>> >>> There are a couple of `(narrowOop)` casts remaining in s390.ad. I'm not sure >>> whether these can be safely converted to CompressedOops::narrow_oop_cast. >>> >>> There might still be some casts from narrowOop to an integral type. Those are >>> hard to find in our cast-happy code base. >>> >>> Testing: >>> tier1-6 for Oracle supported platforms. >>> Build fastdebug linux-ppc64le and linux-s390x. >> >> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision: >> >> - improve assertion >> - remove NarrowType > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 179: > >> 177: // Move narrow OOP >> 178: narrowOop noop = CompressedOops::encode((oop)o); >> 179: uint32_t n = CompressedOops::narrow_oop_value(noop); > > I wonder if we should simply create an overload for oop so that this (and the other places) could be changed to: > n = CompressedOops::narrow_oop_value((oop)o);``` Nice idea. Will be in next PR update. > src/hotspot/cpu/ppc/relocInfo_ppc.cpp line 62: > >> 60: narrowOop no = (type() == relocInfo::oop_type) ? >> 61: CompressedOops::encode((oop)x) : >> 62: // FIXME: Cheating! Treating narrowKlass as a narrowOop. > > I think we try to avoid adding new FIXMES and TODOS to the code. Maybe create a JBS entry instead? Oops, forgot about that. I?ve changed the comment to just note the type pun, and filed https://bugs.openjdk.java.net/browse/JDK-8253860 > PR: https://git.openjdk.java.net/jdk/pull/273 From stuefe at openjdk.java.net Wed Sep 30 15:40:39 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 30 Sep 2020 15:40:39 GMT Subject: RFR: 8253433: Remove -XX:+Debugging product option In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 12:38:30 GMT, Coleen Phillimore wrote: > The Debugging option shouldn't be used on the command line. There's a SuppressErrorAt option to ignore certain > asserts, if there is some situation needing that. Debugging should never be used. > Tested with tier1 tests on 4 platforms. LGTM ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/434 From phh at openjdk.java.net Wed Sep 30 16:14:31 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Wed, 30 Sep 2020 16:14:31 GMT Subject: RFR: 8239090: Improve CPU feature support in VM_Version Message-ID: This is a holdover patch previously reviewed when the jdk was under hg control. See the thread starting at https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039887.html Reviewed by Volker Simonis (simonis) and Igor Veresov (iveresov). ------------- Commit messages: - Merge branch 'master' into JDK-8239090 - Merge branch 'master' into JDK-8239090 - Merge branch 'master' into JDK-8239090 - 8239090: Improve CPU feature support in VM_Version - 8239090: Improve CPU feature support in VM_Version Changes: https://git.openjdk.java.net/jdk/pull/436/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=436&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8239090 Stats: 274 lines in 6 files changed: 61 ins; 64 del; 149 mod Patch: https://git.openjdk.java.net/jdk/pull/436.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/436/head:pull/436 PR: https://git.openjdk.java.net/jdk/pull/436 From iveresov at openjdk.java.net Wed Sep 30 16:19:54 2020 From: iveresov at openjdk.java.net (Igor Veresov) Date: Wed, 30 Sep 2020 16:19:54 GMT Subject: RFR: 8239090: Improve CPU feature support in VM_Version In-Reply-To: References: Message-ID: <9GWiSFhZ8NH9zHahI41jXrsjQ_L9g4kmaKSBtwDhNUk=.687c992e-5919-451d-8269-f52454c36c26@github.com> On Wed, 30 Sep 2020 16:07:14 GMT, Paul Hohensee wrote: > This is a holdover patch previously reviewed when the jdk was under hg control. See the thread starting at > > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039887.html > > Reviewed by Volker Simonis (simonis) and Igor Veresov (iveresov). Looks good. ------------- Marked as reviewed by iveresov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/436 From github.com+4146708+a74nh at openjdk.java.net Wed Sep 30 16:30:50 2020 From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward) Date: Wed, 30 Sep 2020 16:30:50 GMT Subject: RFR: 8221554: aarch64 cross-modifying code Message-ID: The AArch64 port uses maybe_isb in places where an ISB might be required because the code may have safepointed. These maybe_isbs are very conservative and are used in many places are used when a safepoint has not happened. cross_modify_fence was added in common code to place a barrier in all the places after a safepoint has occurred. All the uses of it are in common code, yet it remains unimplemented on AArch64. This set of patches implements cross_modify_fence for AArch64 and reconsiders every uses of maybe_isb, discarding many of them. In addition, it introduces a new diagnostic option, which when enabled on AArch64 tests the correct usage of the barriers. Advantage of this patch is threefold: * Reducing the number of ISBs - giving a theoretical performance improvement. * Use of common code instead of backend specific code. * Additional test diagnostic options Patch 1: Split cross_modify_fence ================================= This is simply refactoring work split out to simplify the other two patches. instruction_fence() is provided by each target and simply places a fence for the instruction stream. cross_modify_fence() is now a member of JavaThread and just calls instruction_fence. This function will be extended in Patch 3. Patch 2: Use cross_modify_fence instead of maybe_isb ==================================================== The [n] References refer to the comments for cross_modify_fence in thread.hpp. This is all the existing uses of maybe_isb in the AArch64 target: 1) Instances of Java code calling a VM function * This encapsulates the changes to: ** MacroAssembler::call_VM_leaf_base() ** generate_fast_get_int_field0() ** stubGenerator_aarch64 generate_throw_exception() ** sharedRuntime_aarch64 generate_handler_blob() ** SharedRuntime::generate_resolve_blob() ** C1 LIR_Assembler::rt_call ** C1 StubAssembler::call_RT(): used by Used by generate_exception_throw, generate_handle_exception, generate_code_for. ** OptoRuntime::generate_exception_blob() * Any changes will be caught due to calls to [2] or [3] by the VM function. * Any calls that do not call [2] or [3] do not require an ISB. * This patch is more optimal for these cases. 2) Instances of Java code calling a JNI function * This encapsulates the changes to: ** SharedRuntime::generate_native_wrapper() ** TemplateInterpreterGenerator::generate_native_entry() * A safepoint still in progress after the call with be caught by [4]. * An ISB is still required for the case where there was a safepoint but it completed during the call. This happens if the code doesn't branch on safepoint_in_progress * In the SharedRuntime version, the two possible calls to reguard_yellow_pages and complete_monitor_unlocking_C are after the thread goes back into it's original state, so are covered by [2] and [3], the same as a normal VM call. * This patch is only more optimal for the two post-JNI calls. 3) Patching functions * This encapsulates the changes to: ** patch_callers_callsite() (called by gen_c2i_adapter()) * This results in code being patched, but does not safepoint * Therefore an ISB is required. * This patch introduces no change here. 4) C1 MacroAssembler::emit_static_call_stub() * Calls ISB (not maybe_isb) * By design, the patching doesn't require that the up-to-date destination is required for proper functioning. * However, the ISB makes it most likely that the new destination will be picked up. * This patch introduces no change here. Patch 3: Add cross modify fence verification ============================================ The VerifyCrossModifyFence diagnostic flag enables confirmation to the correct usage of instruction barriers. It can safely be enabled on any Java run. Enabling it will cause the following: * Once all threads have been brought to a safepoint, each thread will be marked. * On a cross_modify_fence and safepoint_fence the mark for that thread will be cleared. * On entry to a method and in a safepoint poll, then the thread is checked. If it is marked, then the code will error. ------------- Commit messages: - AArch64: Add cross modify fence verification - AArch64: Use cross_modify_fence instead of maybe_isb - Split cross_modify_fence Changes: https://git.openjdk.java.net/jdk/pull/428/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=428&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8221554 Stats: 179 lines in 26 files changed: 127 ins; 7 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/428.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/428/head:pull/428 PR: https://git.openjdk.java.net/jdk/pull/428 From simonis at openjdk.java.net Wed Sep 30 16:52:42 2020 From: simonis at openjdk.java.net (Volker Simonis) Date: Wed, 30 Sep 2020 16:52:42 GMT Subject: RFR: 8239090: Improve CPU feature support in VM_Version In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 16:07:14 GMT, Paul Hohensee wrote: > This is a holdover patch previously reviewed when the jdk was under hg control. See the thread starting at > > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039887.html > > Reviewed by Volker Simonis (simonis) and Igor Veresov (iveresov). Hi Paul, looks good! Thanks for adding the assertion. Best regards, Volker ------------- Marked as reviewed by simonis (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/436 From phh at openjdk.java.net Wed Sep 30 17:04:48 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Wed, 30 Sep 2020 17:04:48 GMT Subject: Integrated: 8239090: Improve CPU feature support in VM_Version In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 16:07:14 GMT, Paul Hohensee wrote: > This is a holdover patch previously reviewed when the jdk was under hg control. See the thread starting at > > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039887.html > > Reviewed by Volker Simonis (simonis) and Igor Veresov (iveresov). This pull request has now been integrated. Changeset: 9e453d97 Author: Paul Hohensee URL: https://git.openjdk.java.net/jdk/commit/9e453d97 Stats: 274 lines in 6 files changed: 61 ins; 64 del; 149 mod 8239090: Improve CPU feature support in VM_Version Reviewed-by: iveresov, simonis ------------- PR: https://git.openjdk.java.net/jdk/pull/436 From hohensee at amazon.com Wed Sep 30 17:02:32 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 30 Sep 2020 17:02:32 +0000 Subject: RFR: 8239090: Improve CPU feature support in VM_Version In-Reply-To: References: Message-ID: <5BE00242-2245-4D7C-84C6-0B343EB7FF4E@amazon.com> Thanks for the quick (re)reviews, Igor and Volker. Paul ?On 9/30/20, 9:55 AM, "hotspot-dev on behalf of Volker Simonis" wrote: On Wed, 30 Sep 2020 16:07:14 GMT, Paul Hohensee wrote: > This is a holdover patch previously reviewed when the jdk was under hg control. See the thread starting at > > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039887.html > > Reviewed by Volker Simonis (simonis) and Igor Veresov (iveresov). Hi Paul, looks good! Thanks for adding the assertion. Best regards, Volker ------------- Marked as reviewed by simonis (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/436 From hohensee at amazon.com Wed Sep 30 17:28:26 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 30 Sep 2020 17:28:26 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) Message-ID: <68FA0B26-8DB3-4F08-9F76-87DD570FDF28@amazon.com> I filed https://bugs.openjdk.java.net/browse/JDK-8253868: CodeSection::initialize_shared_locs buffer argument types and sizes are opaque Paul ?On 9/29/20, 9:35 AM, "Kim Barrett" wrote: > On Sep 29, 2020, at 10:18 AM, Hohensee, Paul wrote: > Code that calls initialize_shared_locs is inconsistent even within itself. E.g., in c1_Compilation.cpp, we have Agreed there seems to be a bit of a mess around that function. > Anyway, I just wanted to make the compiler warning go away, not figure out why the code is the way it is. Matthias and Kim would like to separate out the CSystemColors.m patch into a separate bug, which is fine by me (see separate email). > > So, for the sharedRuntime patch, would it be ok to just use > > short locs_buf[84]; > > to account for possible alignment in initialize_shared_locs? I'm using 84 because 80 is exactly 5 records plus 5 sizeof(relocInfo)s, allowing for alignment adds 3, and rounding the total array size up to a multiple of 8 adds 1. Your analysis looks plausible. But consider instead struct { double data[20]; } locs_buf; and change next line to use &locs_buf This doesn't change the size or alignment from pre-existing code. I can't test whether this will suppress the warning, but I'm guessing it will. And the rest of below is off if that?s wrong. Changing the size and type and worrying about alignment changes seems beyond what's needed "to make the compiler warning go away, not figure out why the code is the way it is.? I dislike making weird changes to suppress compiler warnings, but changing the type and size seems more weird to me here. I mean, 84 looks like a number pulled out of a hat, unless you are going to add a bunch of commentary that probably really belongs in a bug report to look at this stuff more carefully. And file an RFE to look at initialize_shared_locs and its callers more carefully. From psandoz at openjdk.java.net Wed Sep 30 18:22:31 2020 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 30 Sep 2020 18:22:31 GMT Subject: RFR: 8223347: Integration of Vector API (Incubator) In-Reply-To: <-JIanIoqecCK7WfRPElGiS9Gora2wP3NfpGZ3hNL_Hg=.2ccfa0e9-33c6-430b-9303-66829e97e6ff@github.com> References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com> <-JIanIoqecCK7WfRPElGiS9Gora2wP3NfpGZ3hNL_Hg=.2ccfa0e9-33c6-430b-9303-66829e97e6ff@github.com> Message-ID: On Wed, 30 Sep 2020 03:33:38 GMT, Jie Fu wrote: >> Build changes look ok. > > Hi @PaulSandoz , > > This integration seems to miss https://github.com/openjdk/panama-vector/pull/1, which had fixed crashes on AVX512 > machines. > Thanks. @DamonFool we can follow up later for that fix (and others in `vectorIntrinsics`), after this PR integrates. I don't want to perturb the code that has already been reviewed, which requires yet more additional review. ------------- PR: https://git.openjdk.java.net/jdk/pull/367 From kbarrett at openjdk.java.net Wed Sep 30 18:35:00 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 30 Sep 2020 18:35:00 GMT Subject: RFR: 8247912: Make narrowOop a scoped enum [v3] In-Reply-To: References: Message-ID: > Please review this change to the type narrowOop from a typedef for juint to a > scoped enum with uint32_t as the representation type. This provides stronger > type checking when using this type. > > For the most part this was fairly straightforward, and the patch size is > relatively small. The implementation of some existing CompressedOops > "primitives" required adjustment. An explicit conversion to narrowOop was > added, with casts change to use it. There were a few places that were type > punning and needed explicit conversions,, mostly in platform-specific assembly > support. > > There are a couple of lingering problems. > > Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass > as a narrowOop. I adjusted the code to accommodate the narrowOop change, but > this probably ought to be done differently. > > There are a couple of `(narrowOop)` casts remaining in s390.ad. I'm not sure > whether these can be safely converted to CompressedOops::narrow_oop_cast. > > There might still be some casts from narrowOop to an integral type. Those are > hard to find in our cast-happy code base. > > Testing: > tier1-6 for Oracle supported platforms. > Build fastdebug linux-ppc64le and linux-s390x. Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: stefank review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/273/files - new: https://git.openjdk.java.net/jdk/pull/273/files/e36f7895..0fba2ef1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=273&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=273&range=01-02 Stats: 39 lines in 8 files changed: 17 ins; 12 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/273.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/273/head:pull/273 PR: https://git.openjdk.java.net/jdk/pull/273 From kbarrett at openjdk.java.net Wed Sep 30 18:45:10 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 30 Sep 2020 18:45:10 GMT Subject: RFR: 8247912: Make narrowOop a scoped enum [v4] In-Reply-To: References: Message-ID: > Please review this change to the type narrowOop from a typedef for juint to a > scoped enum with uint32_t as the representation type. This provides stronger > type checking when using this type. > > For the most part this was fairly straightforward, and the patch size is > relatively small. The implementation of some existing CompressedOops > "primitives" required adjustment. An explicit conversion to narrowOop was > added, with casts change to use it. There were a few places that were type > punning and needed explicit conversions,, mostly in platform-specific assembly > support. > > There are a couple of lingering problems. > > Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass > as a narrowOop. I adjusted the code to accommodate the narrowOop change, but > this probably ought to be done differently. > > There are a couple of `(narrowOop)` casts remaining in s390.ad. I'm not sure > whether these can be safely converted to CompressedOops::narrow_oop_cast. > > There might still be some casts from narrowOop to an integral type. Those are > hard to find in our cast-happy code base. > > Testing: > tier1-6 for Oracle supported platforms. > Build fastdebug linux-ppc64le and linux-s390x. Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: add missing inlines for consistency ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/273/files - new: https://git.openjdk.java.net/jdk/pull/273/files/0fba2ef1..38d0088f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=273&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=273&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/273.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/273/head:pull/273 PR: https://git.openjdk.java.net/jdk/pull/273 From kbarrett at openjdk.java.net Wed Sep 30 18:50:46 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 30 Sep 2020 18:50:46 GMT Subject: RFR: 8247912: Make narrowOop a scoped enum [v5] In-Reply-To: References: Message-ID: > Please review this change to the type narrowOop from a typedef for juint to a > scoped enum with uint32_t as the representation type. This provides stronger > type checking when using this type. > > For the most part this was fairly straightforward, and the patch size is > relatively small. The implementation of some existing CompressedOops > "primitives" required adjustment. An explicit conversion to narrowOop was > added, with casts change to use it. There were a few places that were type > punning and needed explicit conversions,, mostly in platform-specific assembly > support. > > There are a couple of lingering problems. > > Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass > as a narrowOop. I adjusted the code to accommodate the narrowOop change, but > this probably ought to be done differently. > > There are a couple of `(narrowOop)` casts remaining in s390.ad. I'm not sure > whether these can be safely converted to CompressedOops::narrow_oop_cast. > > There might still be some casts from narrowOop to an integral type. Those are > hard to find in our cast-happy code base. > > Testing: > tier1-6 for Oracle supported platforms. > Build fastdebug linux-ppc64le and linux-s390x. Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into strong_narrowoop - add missing inlines for consistency - stefank review - improve assertion - remove NarrowType - 8247912: Make narrowOop a scoped enum ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/273/files - new: https://git.openjdk.java.net/jdk/pull/273/files/38d0088f..f6b93d4e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=273&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=273&range=03-04 Stats: 41108 lines in 2221 files changed: 9689 ins; 25600 del; 5819 mod Patch: https://git.openjdk.java.net/jdk/pull/273.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/273/head:pull/273 PR: https://git.openjdk.java.net/jdk/pull/273 From github.com+51754783+CoreyAshford at openjdk.java.net Wed Sep 30 19:19:24 2020 From: github.com+51754783+CoreyAshford at openjdk.java.net (CoreyAshford) Date: Wed, 30 Sep 2020 19:19:24 GMT Subject: RFR: 8248188: Add HotSpotIntrinsicCandidate and API for Base64 decoding In-Reply-To: <3zdj-jaGgS6_W7mNPSnlZr6JECPKSybWxR1-yy5bZ8Q=.90bff33b-0da1-49cf-9833-ee08caf55c6f@github.com> References: <3zdj-jaGgS6_W7mNPSnlZr6JECPKSybWxR1-yy5bZ8Q=.90bff33b-0da1-49cf-9833-ee08caf55c6f@github.com> Message-ID: On Tue, 29 Sep 2020 16:39:25 GMT, CoreyAshford wrote: > Did you try on x86? AOT is not supported on PPC64. After looking at this a bit, I find that there seems to be an assumption in the code that if there is an intrinsic symbol defined in aotCodeHeap.cpp using the SET_AOT_GLOBAL_SYMBOL_VALUE macro, it is required that the intrinsic is implemented for every arch that implements AOT. In this case, there isn't an implementation for x86_64 (yet), so that's why the failure is occurring. I was tempted to put in an arch-specific #if for ppc arch only, but I don't see any arch-specific code in this area, and it doesn't make sense either because AOT isn't supported on ppc at all. Another alternative is to remove the SET_AOT_GLOBAL_SYMBOL_VALUE for decodeBlock, since the implementation is not defined (yet) for any arch which supports AOT. A third alternative would be to leave the macro call in, but comment it out, saying to uncomment it when it's supported on all AOT-capable arches. Any thoughts? ------------- PR: https://git.openjdk.java.net/jdk/pull/293 From kvn at openjdk.java.net Wed Sep 30 20:05:42 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 30 Sep 2020 20:05:42 GMT Subject: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v5] In-Reply-To: References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Mon, 28 Sep 2020 19:08:04 GMT, Philippe Marschall wrote: >> @marschall I will sponsor it after you integrate the latest update. > > @vnkozlov done, I hope I now made it correctly with a merge commit for the latest merge conflict hs-tier1, hs-tier3-graal testing passed ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From github.com+471021+marschall at openjdk.java.net Wed Sep 30 20:07:31 2020 From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall) Date: Wed, 30 Sep 2020 20:07:31 GMT Subject: Integrated: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package In-Reply-To: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> References: <5_VnH6nLD06u9b1-MywH8s5JuLcMpaPNsOKEEXRjFDI=.8f07c7b8-4015-4cd2-be81-e344815e2dca@github.com> Message-ID: On Mon, 7 Sep 2020 09:44:09 GMT, Philippe Marschall wrote: > Hello, newbie here > > I picked JDK-8138732 to work on because it has a "starter" label and I believe I understand what to do. > > - I tried to update the copyright year to 2020 in every file. > - I decided to change `@since` from 9 to 16 since it is a new annotation name in a new package. > - I tried to keep code changes to a minimum, eg not change to imports if fully qualified class names are used instead of > imports. In some cases I did minor reordering of imports to keep them sorted alphabetically. > - All tier1 tests pass. > - One jpackage/jlink tier2 test fails but I don't believe it is related. > - Some tier3 Swing tests fail but I don't think they are related. This pull request has now been integrated. Changeset: 2a406f3c Author: Philippe Marschall Committer: Vladimir Kozlov URL: https://git.openjdk.java.net/jdk/commit/2a406f3c Stats: 749 lines in 65 files changed: 149 ins; 149 del; 451 mod 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package Reviewed-by: dholmes, alanb, psandoz, kvn, egahlin ------------- PR: https://git.openjdk.java.net/jdk/pull/45 From dcubed at openjdk.java.net Wed Sep 30 21:27:17 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 30 Sep 2020 21:27:17 GMT Subject: RFR: 8239090: Improve CPU feature support in VM_Version In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 16:50:18 GMT, Volker Simonis wrote: >> This is a holdover patch previously reviewed when the jdk was under hg control. See the thread starting at >> >> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-September/039887.html >> >> Reviewed by Volker Simonis (simonis) and Igor Veresov (iveresov). > > Hi Paul, > > looks good! > > Thanks for adding the assertion. > > Best regards, > Volker There's no testing information in this PR and the testing mentioned in the review on hotspot-compiler-dev is minimal. This fix is currently failing the sun/hotspot/whitebox/CPUInfoTest.java three times in the JDK16 CI in Tier1. @veresov has a fix that he has tested and will start the review process soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/436 From github.com+670087+jrziviani at openjdk.java.net Wed Sep 30 21:28:19 2020 From: github.com+670087+jrziviani at openjdk.java.net (Ziviani) Date: Wed, 30 Sep 2020 21:28:19 GMT Subject: RFR: 8230664: Fix TestInstanceKlassSize for PowerPC [v2] In-Reply-To: References: Message-ID: > TestInstanceKlassSize was failing because, for PowerPC, the following code (instanceKlass.cpp) always compiles to > `return false;` bool InstanceKlass::has_stored_fingerprint() const { > #if INCLUDE_AOT > return should_store_fingerprint() || is_shared(); > #else > return false; > #endif > } > However, in `hasStoredFingerprint()@InstanceKlass.java` the condition `shouldStoreFingerprint() || isShared();` is > always evaluated and may return true (_AFAIK isShared() returns true_). Such condition adds 8 bytes in the > `getSize()@InstanceKlass.java` causing the failure in TestInstanceKlassSize: public long getSize() { // in number of > bytes > ... > if (hasStoredFingerprint()) { > size += 8; // uint64_t > } > return alignSize(size); > } > Considering these tests are failing for PowerPC only (_based on ProblemList.txt_), my solution checks if > `hasStoredFingerprint()` is running on a PowerPC platform. I decided to go this way because there is no existing flag > informing whether AOT is included or not and creating a new one just to handle the PowerPC case seems too much. This > patch is an attempt to fix https://bugs.openjdk.java.net/browse/JDK-8230664 Ziviani has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision: 8230664: Fix TestInstanceKlassSize The code hasStoredFingerprint() at InstanceKlass.java is not considering AOT disabled at compilation time, like has_stored_fingerprint() at instanceKlass.cpp does. Such difference can cause TestInstanceKlassSize failures because all objects will have an extra 8-bytes. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/358/files - new: https://git.openjdk.java.net/jdk/pull/358/files/1d4ad824..8fc1ab6f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=358&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=358&range=00-01 Stats: 13079 lines in 1704 files changed: 5729 ins; 2398 del; 4952 mod Patch: https://git.openjdk.java.net/jdk/pull/358.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/358/head:pull/358 PR: https://git.openjdk.java.net/jdk/pull/358 From github.com+670087+jrziviani at openjdk.java.net Wed Sep 30 22:15:04 2020 From: github.com+670087+jrziviani at openjdk.java.net (Ziviani) Date: Wed, 30 Sep 2020 22:15:04 GMT Subject: RFR: 8230664: Fix TestInstanceKlassSize for PowerPC [v2] In-Reply-To: References: Message-ID: <0jROg9pR-y2KHvtOJmKcXR13C1jWVNDETVzbcftp_0k=.0a61749d-04c4-4853-a325-ea7d8c2bf338@github.com> On Tue, 29 Sep 2020 20:56:24 GMT, Ziviani wrote: >> Can you please update the JBS issue to accurately describe what the underlying cause is. It incorreclty states that it >> is 8-byte vs 16-byte aligment. >> I'd prefer that you added someting like VM.hasAOT(). This will fix the problem for other CPU ports that may be in a >> similar situation and also ensure correctness when configure a build with `--disable-aot`. > > @plummercj > Thank you for your review! > >> Can you please update the JBS issue to accurately describe what the underlying cause is. It incorreclty states that it >> is 8-byte vs 16-byte aligment. > > Unfortunately, I don't have write access to the bug system. I'll check if the original reporter would mind adding it > for me. >> I'd prefer that you added someting like VM.hasAOT(). This will fix the problem for other CPU ports that may be in a >> similar situation and also ensure correctness when configure a build with --disable-aot. > > Sure, I'll work on it. I'll update this PR as soon as I finish the tests. > > Thank you! @plummercj Hello! I implemented `hasAOT()` by using an existing variable in methodCounters that exists only if AOT is enabled. **ppc64le** ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/hotspot/jtreg/serviceability/sa/TestInstanceKlassSize.java 1 1 0 0 ============================== TEST SUCCESS ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/hotspot/jtreg/serviceability/sa/TestInstanceKlassSizeForInterface.java 1 1 0 0 ============================== TEST SUCCESS **x86-64** ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/hotspot/jtreg/serviceability/sa/TestInstanceKlassSize.java 1 1 0 0 ============================== TEST SUCCESS ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/hotspot/jtreg/serviceability/sa/TestInstanceKlassSizeForInterface.java 1 1 0 0 ============================== TEST SUCCESS``` ------------- PR: https://git.openjdk.java.net/jdk/pull/358 From iignatyev at openjdk.java.net Wed Sep 30 22:52:06 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 30 Sep 2020 22:52:06 GMT Subject: RFR: 8253882: remove PropertyResolvingWrapper Message-ID: <1DMgNmvJfsDOtn5b8yNiFMzREHTlTfH7rNQzB4-zVAo=.8f35b465-4ac9-4e7f-bf8e-7571ea9bc4aa@github.com> Hi all, could you please review this trivial patch which removes `PropertyResolvingWrapper`? from JBS: > w/ all [JDK-8219140]'s sub-tasks being done, there are no more usages of `PropertyResolvingWrapper`, so this class can > be removed. [JDK-8219140]: https://bugs.openjdk.java.net/browse/JDK-8219140 ------------- Commit messages: - 8253882: remove PropertyResolvingWrapper Changes: https://git.openjdk.java.net/jdk/pull/446/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=446&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253882 Stats: 136 lines in 1 file changed: 0 ins; 136 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/446.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/446/head:pull/446 PR: https://git.openjdk.java.net/jdk/pull/446 From cjplummer at openjdk.java.net Wed Sep 30 23:39:51 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 30 Sep 2020 23:39:51 GMT Subject: RFR: 8230664: Fix TestInstanceKlassSize for PowerPC [v2] In-Reply-To: References: Message-ID: On Wed, 30 Sep 2020 21:28:19 GMT, Ziviani wrote: >> TestInstanceKlassSize was failing because, for PowerPC, the following code (instanceKlass.cpp) always compiles to >> `return false;` bool InstanceKlass::has_stored_fingerprint() const { >> #if INCLUDE_AOT >> return should_store_fingerprint() || is_shared(); >> #else >> return false; >> #endif >> } >> However, in `hasStoredFingerprint()@InstanceKlass.java` the condition `shouldStoreFingerprint() || isShared();` is >> always evaluated and may return true (_AFAIK isShared() returns true_). Such condition adds 8 bytes in the >> `getSize()@InstanceKlass.java` causing the failure in TestInstanceKlassSize: public long getSize() { // in number of >> bytes >> ... >> if (hasStoredFingerprint()) { >> size += 8; // uint64_t >> } >> return alignSize(size); >> } >> Considering these tests are failing for PowerPC only (_based on ProblemList.txt_), my solution checks if >> `hasStoredFingerprint()` is running on a PowerPC platform. I decided to go this way because there is no existing flag >> informing whether AOT is included or not and creating a new one just to handle the PowerPC case seems too much. This >> patch is an attempt to fix https://bugs.openjdk.java.net/browse/JDK-8230664 > > Ziviani has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains > one commit: > 8230664: Fix TestInstanceKlassSize > > The code hasStoredFingerprint() at InstanceKlass.java is not considering > AOT disabled at compilation time, like has_stored_fingerprint() at > instanceKlass.cpp does. Such difference can cause TestInstanceKlassSize > failures because all objects will have an extra 8-bytes. Changes look good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/358