From dholmes at openjdk.java.net Sun May 1 01:04:31 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 1 May 2022 01:04:31 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler [v4] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 11:14:38 GMT, Johannes Bechberger wrote: >> Fix the assertion by replacing it by assertion that does not fail. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove Thread from make_walkable signature src/hotspot/cpu/x86/frame_x86.cpp line 720: > 718: // already walkable? > 719: if (walkable()) return; > 720: vmassert(Thread::current() == thread, "not current thread"); Oops! Need to delete this. ------------- PR: https://git.openjdk.java.net/jdk/pull/8209 From alanb at openjdk.java.net Mon May 2 06:24:21 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 2 May 2022 06:24:21 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v9] In-Reply-To: References: Message-ID: > This is the implementation of JEP 425: Virtual Threads (Preview). > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec - Merge with jdk-19+20 - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1 - Merge with jdk-19+19 - Refresh - Refresh - Refresh - Refresh - ... and 3 more: https://git.openjdk.java.net/jdk/compare/16a8ebbf...51bc652d ------------- Changes: https://git.openjdk.java.net/jdk/pull/8166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=08 Stats: 103888 lines in 1143 files changed: 93996 ins; 4227 del; 5665 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Mon May 2 06:33:22 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 2 May 2022 06:33:22 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: <5w1-RAMPJ1845QC0VJ2YRwifky-U04KUmBp6kQGoOF8=.8486acaa-beda-4706-b394-962f2e8954c0@github.com> References: <5w1-RAMPJ1845QC0VJ2YRwifky-U04KUmBp6kQGoOF8=.8486acaa-beda-4706-b394-962f2e8954c0@github.com> Message-ID: On Fri, 29 Apr 2022 20:57:01 GMT, Erik Gahlin wrote: >> test/jdk/jdk/jfr/api/consumer/TestManyRecordings.java line 57: >> >>> 55: int classLoaderCount = Integer.parseInt(args[0]); >>> 56: int classCount = Integer.parseInt(args[1]); >>> 57: for (int i = 0; i > >> Did you mean classLoaderCount here instead of classCount? Also, please make sure there is a space between < and classLoaderCount. > > The JFR "tests" look strange. I would expect a test called TestManyRecording to start recordings, not create a lot of classes, similar to TestManyClasses. How is this related to Loom? Could this be a merge gone bad? > > Also, in TestActiveSettingEvent.java > > +settingValues.put(EventNames.VirtualThreadPinned + "#threshold", "20 ms"); > > The reason to exclude a setting (threshold or stackTrace) from a .jfc file is if it doesn't make sense to configure. For example, if the event is always instantaneous (so duration is always 0) or periodic (so the stack trace only show JFR internals) then "threshold" and "stackTrace" can be removed from the configuration file, but needs to be added to test to avoid false positive. > > The value "20 ms" seems like something a user might want to configure. If the event is instant, then the value should be "0 ms". It seems that test/jdk/jdk/jfr/api/consumer/TestManyClasses.java, TestManyRecordings.java, and TestParse.java were added for another JFR event (nothing to do with VirtualThreadPinned). @egahlin has contributed some cleanup and these files are removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Mon May 2 06:33:23 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 2 May 2022 06:33:23 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 23:14:45 GMT, Mikhailo Seledtsov wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > test/lib/jdk/test/lib/thread/VThreadRunner.java line 61: > >> 59: /** >> 60: * Run a task in a virtual thread and wait for it to terminate. >> 61: * If the task completse with an exception then it is thrown by this method. > > typo: completse --> completes Thanks, it seems this typo was repeated several times in the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From jbachorik at openjdk.java.net Mon May 2 07:51:35 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Mon, 2 May 2022 07:51:35 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: References: Message-ID: > A gist of the fix is to allow relaxed instantiation of a frame when done from a signal handler - eg. for profiling purposes. > > Currently, a frame instantiation will fail on guarantee when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of profiling where the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. > > The behaviour defaults to checking the code blob status in the guarantee so nothing will change for the rest of the callers - just ASGCT will be affected. > >
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. > However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: Fix indentation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8061/files - new: https://git.openjdk.java.net/jdk/pull/8061/files/0469d1ca..a306d912 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8061&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8061&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8061.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8061/head:pull/8061 PR: https://git.openjdk.java.net/jdk/pull/8061 From jbachorik at openjdk.java.net Mon May 2 07:51:35 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Mon, 2 May 2022 07:51:35 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 07:57:19 GMT, Lutz Schmidt wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix indentation > > This is not a complete review yet, just some general remarks. > > While I absolutely appreciate the tedious work and time you invested, I dislike the widespread nature of your changes. This is not just your fault. Your changes only make deficiencies in the code layout really obvious. > > Did you spend a thought on consolidating e.g. the changes in `os_cpu` into a common file, potentially in `os/linux` or, even better, `os/posix`? The` cpu` tree is begging for consolidation as well. Maybe most of the init stuff can be done in `runtime/frame.*`? > > While browsing through the changes, I found that in `pd_get_top_frame()`, the code is inconsistent. Some instances provide special handling for `#if COMPILER2_OR_JVMCI`, others only for `#if COMPILER2`, and sometimes there is no special handling at all. We should either have it everywhere or nowhere. Furthermore, I would prefer to see only one syntactical form, either `#if`, or `#ifdef` or `#if defined()`. Please note the subtle differences! > > I added a few inline comments where the code needs some TLC. @RealLucy I deliberately left out any attempts on consolidation as it might make the change affecting even more files across the whole repo. From my experience it would lower the chance of getting the fix reviewed and approved significantly so I opted for the minimum number of required changes that are preventing this particular crash. There is a JEP (https://bugs.openjdk.java.net/browse/JDK-8284289) under way which is supposed to clean up and unify the implementations for obtaining profiling stacktraces. I would prefer having the sweeping changes being rather a part of the JEP effort then attaching them to this PR. I can create a follow up JIRA ticket for the tasks you have mentioned and link it with the JEP so your input does not get lost. > src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp line 52: > >> 50: assert(pauth_ptr_is_raw(pc), "cannot be signed"); >> 51: intptr_t a = intptr_t(sp); >> 52: intptr_t b = intptr_t(fp); > > What are these declarations good for? You mean `bool forSignalHandler`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8061 From iwalulya at openjdk.java.net Mon May 2 10:53:49 2022 From: iwalulya at openjdk.java.net (Ivan Walulya) Date: Mon, 2 May 2022 10:53:49 GMT Subject: RFR: 8284435: Add dedicated filler objects for known dead Java heap areas [v3] In-Reply-To: References: Message-ID: On Mon, 11 Apr 2022 14:55:32 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that adds dedicated filler objects to the VM? >> >> Currently, when formatting areas of dead objects all gcs use instances of j.l.Object and int-arrays. >> >> This has the drawback of not being easily able to discern whether a given object is actually dead (and should never be referenced) or just a regular j.l.Object/int array. >> >> This also makes enhanced error detection (any reference to such an object is an error - i.e. detecting references to such objects) and to skip potentially already unloaded classes when scanning areas of the heap below TAMS, G1 uses its prev bitmap. >> Other collectors do not have this extra information at the moment, so they can't (and don't) do this kind of verification. >> >> With [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708) the prev bitmap will effectively be removed in G1; G1 will format the dead areas with these filler objects to avoid coming across unloaded classes. This is fine wrt to normal operation, however, this looses the existing enhanced verification mentioned above. >> >> This change proposes to add dedicated VM-internal filler objects, i.e. equivalents of j.l.Object and int-arrays. >> >> This has the following benefits: >> >> - keep this error detection (actually making it much simpler) and allowing similar verification for other collectors. (This change does not add this) >> >> - this also makes it "easy" to detect references to filler objects in debugging tools - you only need to know the two klasses (or just get their friendly name) to see whether that reference may actually be valid (or refers to the inside such an object). References to these classes in the crash file may also allow the issue to be more clear. >> >> This causes some minor changes to external behavior: >> >> - logs/heap dumps now contain instances of these objects - which seems fine as previously they have just been reported as part of j.l.Object/int-arrays statistics. The VM spec also does not guarantee whether a particular kind of object should/should not show there anyway afaik. >> >> - if the application ever gets to instantiate a reference to such an object somehow, any enabled verification will crash the VM. That's bad luck for messing with internal classes, but that's the purpose of these objects. >> >> The change takes care that getting a reference will not be possible by normal means (i.e. via Class.forName() etc) - which should be sufficient to avoid the issue. Actually, existing mechanisms seem to be sufficient. >> >> >> Testing: tier1-8 >> >> There is one question I would like the reviewers to specially think about, the name of the filler array klass. I just used `Ljava/internal/vm/FillerArray;` for that, looking at other internal symbols/klasses, but I'm not sure this adheres to naming guidelines. >> >> Thanks go to @iklam for helping out with the change. >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Fix test Lgtm! ------------- Marked as reviewed by iwalulya (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8156 From tschatzl at openjdk.java.net Mon May 2 11:06:46 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 2 May 2022 11:06:46 GMT Subject: RFR: 8284435: Add dedicated filler objects for known dead Java heap areas [v3] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 16:45:01 GMT, Ioi Lam wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix test > > The latest version looks good to me. Thanks @iklam @walulyai for your reviews ------------- PR: https://git.openjdk.java.net/jdk/pull/8156 From tschatzl at openjdk.java.net Mon May 2 11:06:46 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 2 May 2022 11:06:46 GMT Subject: RFR: 8284435: Add dedicated filler objects for known dead Java heap areas [v3] In-Reply-To: References: Message-ID: <4THz_V9CeiHcEijqB1zA14uHlZ2FhSjNrmYBfmM0VJo=.69b50b2c-5ca8-4284-b782-bbbae52b1dc4@github.com> On Mon, 11 Apr 2022 14:55:32 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that adds dedicated filler objects to the VM? >> >> Currently, when formatting areas of dead objects all gcs use instances of j.l.Object and int-arrays. >> >> This has the drawback of not being easily able to discern whether a given object is actually dead (and should never be referenced) or just a regular j.l.Object/int array. >> >> This also makes enhanced error detection (any reference to such an object is an error - i.e. detecting references to such objects) and to skip potentially already unloaded classes when scanning areas of the heap below TAMS, G1 uses its prev bitmap. >> Other collectors do not have this extra information at the moment, so they can't (and don't) do this kind of verification. >> >> With [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708) the prev bitmap will effectively be removed in G1; G1 will format the dead areas with these filler objects to avoid coming across unloaded classes. This is fine wrt to normal operation, however, this looses the existing enhanced verification mentioned above. >> >> This change proposes to add dedicated VM-internal filler objects, i.e. equivalents of j.l.Object and int-arrays. >> >> This has the following benefits: >> >> - keep this error detection (actually making it much simpler) and allowing similar verification for other collectors. (This change does not add this) >> >> - this also makes it "easy" to detect references to filler objects in debugging tools - you only need to know the two klasses (or just get their friendly name) to see whether that reference may actually be valid (or refers to the inside such an object). References to these classes in the crash file may also allow the issue to be more clear. >> >> This causes some minor changes to external behavior: >> >> - logs/heap dumps now contain instances of these objects - which seems fine as previously they have just been reported as part of j.l.Object/int-arrays statistics. The VM spec also does not guarantee whether a particular kind of object should/should not show there anyway afaik. >> >> - if the application ever gets to instantiate a reference to such an object somehow, any enabled verification will crash the VM. That's bad luck for messing with internal classes, but that's the purpose of these objects. >> >> The change takes care that getting a reference will not be possible by normal means (i.e. via Class.forName() etc) - which should be sufficient to avoid the issue. Actually, existing mechanisms seem to be sufficient. >> >> >> Testing: tier1-8 >> >> There is one question I would like the reviewers to specially think about, the name of the filler array klass. I just used `Ljava/internal/vm/FillerArray;` for that, looking at other internal symbols/klasses, but I'm not sure this adheres to naming guidelines. >> >> Thanks go to @iklam for helping out with the change. >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Fix test Note that I did a tier1-5 run with the latest change with no issues before pushing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8156 From tschatzl at openjdk.java.net Mon May 2 11:06:48 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 2 May 2022 11:06:48 GMT Subject: Integrated: 8284435: Add dedicated filler objects for known dead Java heap areas In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 08:13:33 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that adds dedicated filler objects to the VM? > > Currently, when formatting areas of dead objects all gcs use instances of j.l.Object and int-arrays. > > This has the drawback of not being easily able to discern whether a given object is actually dead (and should never be referenced) or just a regular j.l.Object/int array. > > This also makes enhanced error detection (any reference to such an object is an error - i.e. detecting references to such objects) and to skip potentially already unloaded classes when scanning areas of the heap below TAMS, G1 uses its prev bitmap. > Other collectors do not have this extra information at the moment, so they can't (and don't) do this kind of verification. > > With [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708) the prev bitmap will effectively be removed in G1; G1 will format the dead areas with these filler objects to avoid coming across unloaded classes. This is fine wrt to normal operation, however, this looses the existing enhanced verification mentioned above. > > This change proposes to add dedicated VM-internal filler objects, i.e. equivalents of j.l.Object and int-arrays. > > This has the following benefits: > > - keep this error detection (actually making it much simpler) and allowing similar verification for other collectors. (This change does not add this) > > - this also makes it "easy" to detect references to filler objects in debugging tools - you only need to know the two klasses (or just get their friendly name) to see whether that reference may actually be valid (or refers to the inside such an object). References to these classes in the crash file may also allow the issue to be more clear. > > This causes some minor changes to external behavior: > > - logs/heap dumps now contain instances of these objects - which seems fine as previously they have just been reported as part of j.l.Object/int-arrays statistics. The VM spec also does not guarantee whether a particular kind of object should/should not show there anyway afaik. > > - if the application ever gets to instantiate a reference to such an object somehow, any enabled verification will crash the VM. That's bad luck for messing with internal classes, but that's the purpose of these objects. > > The change takes care that getting a reference will not be possible by normal means (i.e. via Class.forName() etc) - which should be sufficient to avoid the issue. Actually, existing mechanisms seem to be sufficient. > > > Testing: tier1-8 > > There is one question I would like the reviewers to specially think about, the name of the filler array klass. I just used `Ljava/internal/vm/FillerArray;` for that, looking at other internal symbols/klasses, but I'm not sure this adheres to naming guidelines. > > Thanks go to @iklam for helping out with the change. > > Thanks, > Thomas This pull request has now been integrated. Changeset: 70205956 Author: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/70205956313740e48e1fcb0c02c8f1488ab0d987 Stats: 86 lines in 8 files changed: 80 ins; 1 del; 5 mod 8284435: Add dedicated filler objects for known dead Java heap areas Reviewed-by: iklam, iwalulya ------------- PR: https://git.openjdk.java.net/jdk/pull/8156 From duke at openjdk.java.net Mon May 2 13:26:11 2022 From: duke at openjdk.java.net (Tobias Holenstein) Date: Mon, 2 May 2022 13:26:11 GMT Subject: RFR: JDK-8283807: Handle CompileThreshold the same as other thresholds when scaled with -XX:CompileThresholdScaling Message-ID: `CompileThresholdScaling` scales several compiler thresholds. If the scaled threshold value is outside of the allowed range, a warning is printed and the default value is kept. But when scaling `CompileThreshold` we do not check the scaled value because it is not a ranged flag. Later when verifying flags with a constraint function `OnStackReplacePercentageConstraintFunc` which calls `CompileThresholdConstraintFunc` fails because `CompileThreshold` is outside of the allowed range. This stops the VM from being created. The fix is to call `CompileThresholdConstraintFunc` when scaling `CompileThreshold` with `CompileThresholdScaling`. If `CompileThresholdConstraintFunc` fails we print a warning and keep the default value of `CompileThreshold`. This behaviour is then consistent with the other 15 other thresholds where the VM just prints a warning if the scaled value is too large and then keeps the current value. We also have to exclude `CompileThresholdScaling` from max. range testing in `TestOptionsWithRanges.java`, because it is expected to print "outside the allowed range" warnings for the scaled flag and the "outside the allowed range" warning does not refer to `CompileThresholdScaling` itself. One question that remains it why `CompileThresholdScaling` takes the default fault value when a scaled threshold is too large instead of the max. value? Because now we can have the case where some compiler thresholds are scaled to almost their max. value and others that are already larger than the maximum are default again (which can be the minimum value in some cases). I suggest to address this issue in a separate RFE. ------------- Commit messages: - JDK-8283807: Max range for -XX:CompileThresholdScaling is too large Changes: https://git.openjdk.java.net/jdk/pull/8501/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8501&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283807 Stats: 16 lines in 3 files changed: 11 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8501.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8501/head:pull/8501 PR: https://git.openjdk.java.net/jdk/pull/8501 From lucy at openjdk.java.net Mon May 2 15:55:04 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Mon, 2 May 2022 15:55:04 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 07:57:19 GMT, Lutz Schmidt wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix indentation > > This is not a complete review yet, just some general remarks. > > While I absolutely appreciate the tedious work and time you invested, I dislike the widespread nature of your changes. This is not just your fault. Your changes only make deficiencies in the code layout really obvious. > > Did you spend a thought on consolidating e.g. the changes in `os_cpu` into a common file, potentially in `os/linux` or, even better, `os/posix`? The` cpu` tree is begging for consolidation as well. Maybe most of the init stuff can be done in `runtime/frame.*`? > > While browsing through the changes, I found that in `pd_get_top_frame()`, the code is inconsistent. Some instances provide special handling for `#if COMPILER2_OR_JVMCI`, others only for `#if COMPILER2`, and sometimes there is no special handling at all. We should either have it everywhere or nowhere. Furthermore, I would prefer to see only one syntactical form, either `#if`, or `#ifdef` or `#if defined()`. Please note the subtle differences! > > I added a few inline comments where the code needs some TLC. > @RealLucy I deliberately left out any attempts on consolidation... > > There is a JEP (https://bugs.openjdk.java.net/browse/JDK-8284289) under way which is supposed to clean up... I understand your approach - don't mess with things that are not directly affected. On the other hand: if you have to touch the code anyway, why not improve the maintainability? Maybe the JEP author has an opinion whether the cleanup could be part of the JEP. And you might get support by other reviewers as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/8061 From lucy at openjdk.java.net Mon May 2 15:55:05 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Mon, 2 May 2022 15:55:05 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 07:51:35 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed instantiation of a frame when done from a signal handler - eg. for profiling purposes. >> >> Currently, a frame instantiation will fail on guarantee when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of profiling where the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >> The behaviour defaults to checking the code blob status in the guarantee so nothing will change for the rest of the callers - just ASGCT will be affected. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > > Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentation src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp line 52: > 50: assert(pauth_ptr_is_raw(pc), "cannot be signed"); > 51: intptr_t a = intptr_t(sp); > 52: intptr_t b = intptr_t(fp); What are these declarations good for? ------------- PR: https://git.openjdk.java.net/jdk/pull/8061 From lucy at openjdk.java.net Mon May 2 15:55:08 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Mon, 2 May 2022 15:55:08 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 07:45:22 GMT, Jaroslav Bachorik wrote: >> src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp line 52: >> >>> 50: assert(pauth_ptr_is_raw(pc), "cannot be signed"); >>> 51: intptr_t a = intptr_t(sp); >>> 52: intptr_t b = intptr_t(fp); >> >> What are these declarations good for? > > You mean `bool forSignalHandler`? No, I am referring to lines 51 and 52. These variables are unused as far as I can see. ------------- PR: https://git.openjdk.java.net/jdk/pull/8061 From kvn at openjdk.java.net Mon May 2 16:03:41 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 2 May 2022 16:03:41 GMT Subject: RFR: JDK-8283807: Handle CompileThreshold the same as other thresholds when scaled with -XX:CompileThresholdScaling In-Reply-To: References: Message-ID: On Mon, 2 May 2022 13:17:49 GMT, Tobias Holenstein wrote: > `CompileThresholdScaling` scales several compiler thresholds. If the scaled threshold value is outside of the allowed range, a warning is printed and the default value is kept. But when scaling `CompileThreshold` we do not check the scaled value because it is not a ranged flag. Later when verifying flags with a constraint function `OnStackReplacePercentageConstraintFunc` which calls `CompileThresholdConstraintFunc` fails because `CompileThreshold` is outside of the allowed range. This stops the VM from being created. > > The fix is to call `CompileThresholdConstraintFunc` when scaling `CompileThreshold` with `CompileThresholdScaling`. If `CompileThresholdConstraintFunc` fails we print a warning and keep the default value of `CompileThreshold`. This behaviour is then consistent with the other 15 other thresholds where the VM just prints a warning if the scaled value is too large and then keeps the current value. > > We also have to exclude `CompileThresholdScaling` from max. range testing in `TestOptionsWithRanges.java`, because > it is expected to print "outside the allowed range" warnings for the scaled flag and the "outside the allowed range" warning does not refer to `CompileThresholdScaling` itself. > > One question that remains it why `CompileThresholdScaling` takes the default value when a scaled threshold is too large instead of the max. value? Because now we can have the case where some compiler thresholds are scaled to almost their max. value and others that are already larger than the maximum are default again (which can be the minimum value in some cases). I suggest to address this issue in a separate RFE. Looks good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8501 From mseledtsov at openjdk.java.net Mon May 2 16:05:19 2022 From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov) Date: Mon, 2 May 2022 16:05:19 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v9] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 06:24:21 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview). >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: > > - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec > - Merge with jdk-19+20 > - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 > - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1 > - Merge with jdk-19+19 > - Refresh > - Refresh > - Refresh > - Refresh > - ... and 3 more: https://git.openjdk.java.net/jdk/compare/16a8ebbf...51bc652d Thank you for addressing my review feedback. HotSpot/Runtime, test library, common test and JFR test changes look good to me. ------------- Marked as reviewed by mseledtsov (Committer). PR: https://git.openjdk.java.net/jdk/pull/8166 From lmesnik at openjdk.java.net Mon May 2 17:24:13 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 2 May 2022 17:24:13 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 05:48:19 GMT, Serguei Spitsyn wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 66: > >> 64: for (i = 0; i < METH_NUM; i++) >> 65: bpEvents[i] = 0; >> 66: } > > Leonid, thank you for converting these tests from nsk.jvmti to provide test coverage for virtual threads! > As I understand all new tests are C++ based. > So, I'd suggest to always use C++ style of loops: > for (int i = 0; i < METH_NUM; i++) > > This suggestion applies to all new tests in the serviceability/jvmti folder. > One reason to keep old style would be to keep these tests comparable with the matching nsk.jvmti tests. > However, I tried to compare and found out that the difference is already pretty big. > You can consider this clean up after integration though. fixed in all ported tests were applicable ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From jbachorik at openjdk.java.net Mon May 2 17:33:18 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Mon, 2 May 2022 17:33:18 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 15:51:33 GMT, Lutz Schmidt wrote: > Maybe the JEP author has an opinion whether the cleanup could be part of the JEP. And you might get support by other reviewers as well. Let me pull @parttimenerd in so he can voice his opinion about where the cleanup should happen. ------------- PR: https://git.openjdk.java.net/jdk/pull/8061 From jbachorik at openjdk.java.net Mon May 2 17:33:31 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Mon, 2 May 2022 17:33:31 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 15:44:06 GMT, Lutz Schmidt wrote: >> You mean `bool forSignalHandler`? > > No, I am referring to lines 51 and 52. These variables are unused as far as I can see. TBH, no idea. They seem to have been added by @theRealAph some 7 years ago ... ------------- PR: https://git.openjdk.java.net/jdk/pull/8061 From lmesnik at openjdk.java.net Mon May 2 17:33:45 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 2 May 2022 17:33:45 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 06:09:35 GMT, Serguei Spitsyn wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 139: > >> 137: thr_info.name, (jni->IsVirtualThread(thread) == JNI_TRUE) ? "virtual" : "kernel", >> 138: (thr_info.is_daemon == JNI_TRUE) ? "deamon" : "user"); >> 139: } > > I'd suggest to add locals (their names are up to you): > const char* thr_virtual_tag = jni->IsVirtualThread(thread) == JNI_TRUE ? "virtual" : "kernel"; > const char* thr_daemon_tag == JNI_TRUE) ? "deamon" : "user"; > > It is better to place togeter lines: 129+130. > Line 137 is not aligned, and there are many unneeded spaces. > The '()' around conditions are not needed. At least, I do not see them increasing readability. fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From lmesnik at openjdk.java.net Mon May 2 20:04:59 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 2 May 2022 20:04:59 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 06:43:02 GMT, Serguei Spitsyn wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > test/hotspot/jtreg/serviceability/jvmti/events/Exception/exception01/libexception01.cpp line 287: > >> 285: } >> 286: >> 287: eventsCount = 0; > > Counters are not protected with locks. > I'm not sure it is a real problem here but would be better to double-check. The variable eventsCount seems to be used in the sinlge thread only. I looked on the several tests with same variable and similar logic. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From lmesnik at openjdk.java.net Mon May 2 20:16:01 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 2 May 2022 20:16:01 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: <7mvqatvgF_tC9fZB1rci31SVIh7q0JVtwGPXlWfiH9Y=.b58e30aa-101c-48d4-bed2-bcb7bf20a160@github.com> On Fri, 29 Apr 2022 06:33:42 GMT, Serguei Spitsyn wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > > test/hotspot/jtreg/serviceability/jvmti/events/ClassPrepare/classprep01/libclassprep01.cpp line 59: > >> 57: static jvmtiEventCallbacks callbacks; >> 58: static jint result = PASSED; >> 59: static volatile size_t eventsCount = 0; // TODO these 2 vars mofified from different threads in getReady/check. What to DO??? > > I'd suggest to use RawMonitorLocker with event_lock or counter_lock to protect updates of these counters. > You can remove this comment then. The variable eventsCount seems to be used in the sinlge thread only. I looked on the several tests with same variable and similar logic. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From iklam at openjdk.java.net Mon May 2 20:41:23 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 2 May 2022 20:41:23 GMT Subject: RFR: JDK-8283807: Handle CompileThreshold the same as other thresholds when scaled with -XX:CompileThresholdScaling In-Reply-To: References: Message-ID: On Mon, 2 May 2022 13:17:49 GMT, Tobias Holenstein wrote: > `CompileThresholdScaling` scales several compiler thresholds. If the scaled threshold value is outside of the allowed range, a warning is printed and the default value is kept. But when scaling `CompileThreshold` we do not check the scaled value because it is not a ranged flag. Later when verifying flags with a constraint function `OnStackReplacePercentageConstraintFunc` which calls `CompileThresholdConstraintFunc` fails because `CompileThreshold` is outside of the allowed range. This stops the VM from being created. > > The fix is to call `CompileThresholdConstraintFunc` when scaling `CompileThreshold` with `CompileThresholdScaling`. If `CompileThresholdConstraintFunc` fails we print a warning and keep the default value of `CompileThreshold`. This behaviour is then consistent with the other 15 other thresholds where the VM just prints a warning if the scaled value is too large and then keeps the current value. > > We also have to exclude `CompileThresholdScaling` from max. range testing in `TestOptionsWithRanges.java`, because > it is expected to print "outside the allowed range" warnings for the scaled flag and the "outside the allowed range" warning does not refer to `CompileThresholdScaling` itself. > > One question that remains it why `CompileThresholdScaling` takes the default value when a scaled threshold is too large instead of the max. value? Because now we can have the case where some compiler thresholds are scaled to almost their max. value and others that are already larger than the maximum are default again (which can be the minimum value in some cases). I suggest to address this issue in a separate RFE. Could you add a test case with several large values for -XX:CompileThresholdScaling and check that the warning message is printed? test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java line 264: > 262: * it is expected to print "outside the allowed range" warnings for > 263: * the scaled flags > 264: */ This comment is not very clear. Do you mean Max range tests expect a warning message of "outside the allowed range" but CompileThresholdScaling prints a different warning message when it's set too high. ------------- Changes requested by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8501 From dlong at openjdk.java.net Mon May 2 21:04:30 2022 From: dlong at openjdk.java.net (Dean Long) Date: Mon, 2 May 2022 21:04:30 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler [v4] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 11:14:38 GMT, Johannes Bechberger wrote: >> Fix the assertion by replacing it by assertion that does not fail. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove Thread from make_walkable signature How does the async profiler make the stack walkable? If it is by calling make_walkable() or capture_last_Java_pc(), and this is just a race of an idempotent operation (the PC set is always the same), then it seems like the simplest fix would have been to relax the assert like this: void JavaFrameAnchor::capture_last_Java_pc() { vmassert(_last_Java_sp != NULL, "no last frame set"); address last_Java_pc = (address)_last_Java_sp[-1]; vmassert(_last_Java_pc == NULL || _last_Java_pc == last_Java_pc, "already walkable"); _last_Java_pc = last_Java_pc; } which is similar to how frame::patch_pc() works. ------------- PR: https://git.openjdk.java.net/jdk/pull/8209 From xliu at openjdk.java.net Mon May 2 23:56:21 2022 From: xliu at openjdk.java.net (Xin Liu) Date: Mon, 2 May 2022 23:56:21 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v3] In-Reply-To: References: <6BLRx1h-CQvukYtRVcBNAROhod7j2jRNdQKU-0Cgnc0=.a0d3270e-8a82-4596-a0d0-3c295981d885@github.com> <-EEsFIwVzotOBaC9DJV9fVlXf1NBjhm51KJYeY1WDFY=.4563f592-c641-4025-986b-9c6e356100fc@github.com> Message-ID: <8c6w9Sy3iH6q7Wpr3AQUTimp04hCoYbcOgIwU7ss2d8=.49cc0946-14d8-4712-9e61-c7ab7a38dd5c@github.com> On Fri, 29 Apr 2022 22:37:25 GMT, Vladimir Kozlov wrote: >> Yes, we try to bypass trampolines during moving code into `CodeCache`: >> >> void Relocation::pd_set_call_destination(address x) { >> assert(is_call(), "should be a call here"); >> if (NativeCall::is_call_at(addr())) { >> address trampoline = nativeCall_at(addr())->get_trampoline(); >> if (trampoline) { >> nativeCall_at(addr())->set_destination_mt_safe(x, /* assert_lock */false); >> return; >> } >> } >> MacroAssembler::pd_patch_instruction(addr(), x); >> assert(pd_call_destination(addr()) == x, "fail in reloc"); >> } >> >> void NativeCall::set_destination_mt_safe(address dest, bool assert_lock) { >> .... >> ResourceMark rm; >> int code_size = NativeInstruction::instruction_size; >> address addr_call = addr_at(0); >> bool reachable = Assembler::reachable_from_branch_at(addr_call, dest); >> ... >> // Patch the constant in the call's trampoline stub. >> address trampoline_stub_addr = get_trampoline(); >> ... >> // Patch the call. >> if (reachable) { >> set_destination(dest); >> } else { >> assert (trampoline_stub_addr != NULL, "we need a trampoline"); >> set_destination(trampoline_stub_addr); >> } >> ... >> } > > So my assumption that `trampoline_call()` could be used for call outside CodeCache is wrong (and the method's comment is correct). I looked on few places where runtime call is generated and `trampoline_call()` indeed is used only for CodeCache (at least in places are looked on): > https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/aarch64.ad#L3858 > > My points 1. and 2. are void. > > Thank you for answering my questions 3. and 4. > > That also explains your `need_trampoline` code change. > > You answered all my questions. Please, do latest merge and updates if needed so I can review final changes. hi, @vnkozlov , @eastig > I would like to know why trampoline_call() could be used for relocInfo::virtual_call_type and relocInfo::opt_virtual_call_type (based on assert). They should be inside CodeCache and you don't need trampoline for it. Right? I take a look at `vmIntrinsics::does_virtual_dispatch`, it looks like there are 2 special intrinsics could be virtual. when c2 calls runtime stubs for them, we actually give up this optimization, right? Is it possible to include those 2 reloc types as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From xliu at openjdk.java.net Tue May 3 00:07:24 2022 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 3 May 2022 00:07:24 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 21:55:25 GMT, Evgeny Astigeevich wrote: >> [JDK-8280872](https://bugs.openjdk.java.net/browse/JDK-8280872) put the non-nmethod segment between two others. It made trampolines for runtime calls redundant in most cases. >> >> This PR uses `target_needs_far_branch()` for runtime calls to check whether they need trampolines. Trampolines are not generated if they are not needed. >> >> Testing: >> - `tier1`...`tier4`: Passed >> - `compiler/c2/aarch64/TestTrampoline.java`: Passed >> >> Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Move code of target_needs_trampoline inside trampoline_call src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 562: > 560: > 561: // Maybe emit a call via a trampoline. If the code cache is small > 562: // trampolines won't be emitted. > "The header comment is incorrect: "If the code cache is small trampolines won't be emitted." I feel that Vladimir's comment is still legit here. From my reading, trampoline is avoidable because of either codecache is small (far_branches() is false) or target_needs_far_branch() is false for runtime reloc. ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From xliu at openjdk.java.net Tue May 3 00:11:22 2022 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 3 May 2022 00:11:22 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v3] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 21:55:25 GMT, Evgeny Astigeevich wrote: >> [JDK-8280872](https://bugs.openjdk.java.net/browse/JDK-8280872) put the non-nmethod segment between two others. It made trampolines for runtime calls redundant in most cases. >> >> This PR uses `target_needs_far_branch()` for runtime calls to check whether they need trampolines. Trampolines are not generated if they are not needed. >> >> Testing: >> - `tier1`...`tier4`: Passed >> - `compiler/c2/aarch64/TestTrampoline.java`: Passed >> >> Note: `compiler/c2/aarch64/TestTrampoline.java` requires the release build. This is because debug builds have the branch range set to 2M which causes always generation of trampolines. > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Move code of target_needs_trampoline inside trampoline_call my comments are optional. I think the change is reasonable to me. I am not a reviewer. We still need 2 reviewers to approve it. ------------- Marked as reviewed by xliu (Committer). PR: https://git.openjdk.java.net/jdk/pull/8403 From dholmes at openjdk.java.net Tue May 3 01:33:23 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 3 May 2022 01:33:23 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: References: Message-ID: <0vNBO9qi7_bymmqqV-9uFWpBm42f9TE3cdjwU4QaCiI=.018c5654-1468-47cb-a6b9-9acfb34336c0@github.com> On Mon, 2 May 2022 07:51:35 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed instantiation of a frame when done from a signal handler - eg. for profiling purposes. >> >> Currently, a frame instantiation will fail on guarantee when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of profiling where the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >> The behaviour defaults to checking the code blob status in the guarantee so nothing will change for the rest of the callers - just ASGCT will be affected. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > > Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentation Changes requested by dholmes (Reviewer). src/hotspot/cpu/ppc/frame_ppc.inline.hpp line 39: > 37: assert(pc != NULL, "precondition: must have PC"); > 38: > 39: if (!forSignalHandler) { To reduce the duplication I suggest adding a helper method to CodeCache: CodeBlob* find_blob(address pc, bool for_signal_handler) { if (!for_signal_handler) { return find_blob(pc); } else { CodeBlob* tmp = find_blob_unsafe(pc); if (tmp != NULL && temp->is_zombie()) { tmp = null; } return tmp; } ------------- PR: https://git.openjdk.java.net/jdk/pull/8061 From duke at openjdk.java.net Tue May 3 07:31:14 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Tue, 3 May 2022 07:31:14 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment [v3] In-Reply-To: References: Message-ID: > Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. > > AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Use JavaThread::cast ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8446/files - new: https://git.openjdk.java.net/jdk/pull/8446/files/1e2885e6..e77e4665 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8446&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8446&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8446.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8446/head:pull/8446 PR: https://git.openjdk.java.net/jdk/pull/8446 From duke at openjdk.java.net Tue May 3 07:36:55 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Tue, 3 May 2022 07:36:55 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler [v5] In-Reply-To: References: Message-ID: > Fix the assertion by replacing it by assertion that does not fail. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Remove two superfluous assertions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8209/files - new: https://git.openjdk.java.net/jdk/pull/8209/files/c6b6b6d6..c96ae9b7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8209&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8209&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8209.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8209/head:pull/8209 PR: https://git.openjdk.java.net/jdk/pull/8209 From duke at openjdk.java.net Tue May 3 07:36:56 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Tue, 3 May 2022 07:36:56 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler [v4] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 11:14:38 GMT, Johannes Bechberger wrote: >> Fix the assertion by replacing it by assertion that does not fail. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove Thread from make_walkable signature You're right, but my original proposal was exactly your change. I modified because it simplifies the code. ------------- PR: https://git.openjdk.java.net/jdk/pull/8209 From duke at openjdk.java.net Tue May 3 07:36:56 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Tue, 3 May 2022 07:36:56 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler [v4] In-Reply-To: References: Message-ID: On Sun, 1 May 2022 01:01:33 GMT, David Holmes wrote: >> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove Thread from make_walkable signature > > src/hotspot/cpu/x86/frame_x86.cpp line 720: > >> 718: // already walkable? >> 719: if (walkable()) return; >> 720: vmassert(Thread::current() == thread, "not current thread"); > > Oops! Need to delete this. ... as well as the assertion that follows. ------------- PR: https://git.openjdk.java.net/jdk/pull/8209 From dholmes at openjdk.java.net Tue May 3 07:40:10 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 3 May 2022 07:40:10 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment [v2] In-Reply-To: References: Message-ID: On Sat, 30 Apr 2022 10:54:07 GMT, David Holmes wrote: >> this method does not exist > > Sorry I meant: `JavaThread::cast(rawThread)` You missed changing the cast here. You could also save the result for use below. ------------- PR: https://git.openjdk.java.net/jdk/pull/8446 From duke at openjdk.java.net Tue May 3 08:02:57 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Tue, 3 May 2022 08:02:57 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment [v4] In-Reply-To: References: Message-ID: > Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. > > AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Merge cast into condition ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8446/files - new: https://git.openjdk.java.net/jdk/pull/8446/files/e77e4665..8d4b60eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8446&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8446&range=02-03 Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8446.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8446/head:pull/8446 PR: https://git.openjdk.java.net/jdk/pull/8446 From duke at openjdk.java.net Tue May 3 08:02:57 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Tue, 3 May 2022 08:02:57 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment [v2] In-Reply-To: References: Message-ID: <77RFHswbfyDzpRaulp8oqDzQ29lA27pCABf1gDp1QCU=.f603a0c2-e533-426d-ab83-6c4fcbe2253f@github.com> On Tue, 3 May 2022 07:36:28 GMT, David Holmes wrote: >> Sorry I meant: `JavaThread::cast(rawThread)` > > You missed changing the cast here. You could also save the result for use below. You're right, I missed that cast. ------------- PR: https://git.openjdk.java.net/jdk/pull/8446 From alanb at openjdk.java.net Tue May 3 08:11:45 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 3 May 2022 08:11:45 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v10] In-Reply-To: References: Message-ID: > This is the implementation of JEP 425: Virtual Threads (Preview). > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4 - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec - Merge with jdk-19+20 - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1 - Merge with jdk-19+19 - Refresh - Refresh - ... and 5 more: https://git.openjdk.java.net/jdk/compare/cfcba1fc...f41b3131 ------------- Changes: https://git.openjdk.java.net/jdk/pull/8166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=09 Stats: 102769 lines in 1140 files changed: 92907 ins; 4216 del; 5646 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Tue May 3 08:11:47 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 3 May 2022 08:11:47 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v8] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 17:29:02 GMT, Leonid Mesnik wrote: >> test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/libbreakpoint01.cpp line 139: >> >>> 137: thr_info.name, (jni->IsVirtualThread(thread) == JNI_TRUE) ? "virtual" : "kernel", >>> 138: (thr_info.is_daemon == JNI_TRUE) ? "deamon" : "user"); >>> 139: } >> >> I'd suggest to add locals (their names are up to you): >> const char* thr_virtual_tag = jni->IsVirtualThread(thread) == JNI_TRUE ? "virtual" : "kernel"; >> const char* thr_daemon_tag == JNI_TRUE) ? "deamon" : "user"; >> >> It is better to place togeter lines: 129+130. >> Line 137 is not aligned, and there are many unneeded spaces. >> The '()' around conditions are not needed. At least, I do not see them increasing readability. > > fixed Thanks, I'll mark all the comments related to the JVMTI event tests as resolved. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From dholmes at openjdk.java.net Tue May 3 09:53:15 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 3 May 2022 09:53:15 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler [v5] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 07:36:55 GMT, Johannes Bechberger wrote: >> Fix the assertion by replacing it by assertion that does not fail. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove two superfluous assertions Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8209 From dholmes at openjdk.java.net Tue May 3 09:55:45 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 3 May 2022 09:55:45 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment [v4] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 08:02:57 GMT, Johannes Bechberger wrote: >> Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. >> >> AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Merge cast into condition Looks good. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8446 From mcimadamore at openjdk.java.net Tue May 3 10:09:36 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 3 May 2022 10:09:36 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v36] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Tweak support for Linker lookup Improve javadoc of SymbolLookup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/d1fcf012..dc309e8b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=35 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=34-35 Stats: 159 lines in 14 files changed: 96 ins; 8 del; 55 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Tue May 3 10:09:38 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 3 May 2022 10:09:38 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v35] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 08:15:32 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Tweak Addressable javadoc We've tweaked the support for looking up symbols in the standard libraries - `CLinker` used to implement `SymbolLookup`, now `CLinker` returns a "default lookup" instead. We've also greatly improved the javadoc of `SymbolLookup` - many thanks to Alex for the help! New javadoc here: http://cr.openjdk.java.net/~mcimadamore/8282191/v3/javadoc/java.base/module-summary.html ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Tue May 3 10:40:02 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 3 May 2022 10:40:02 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Tweak support for Linker lookup Improve javadoc of SymbolLookup - Tweak Addressable javadoc - Downcall and upcall tests use wrong layout which is missing some trailing padding - Simplify libraryLookup impl - Address CSR comments - Merge branch 'master' into foreign-preview - Add ValueLayout changes - Tweak support for array element var handle - ... and 47 more: https://git.openjdk.java.net/jdk/compare/af1ee1cc...41d055ab ------------- Changes: https://git.openjdk.java.net/jdk/pull/7888/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=36 Stats: 65464 lines in 367 files changed: 43470 ins; 19432 del; 2562 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From stuefe at openjdk.java.net Tue May 3 11:21:19 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 3 May 2022 11:21:19 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v9] In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 14:35:28 GMT, Lutz Schmidt wrote: >> Please review (and approve, if possible) this pull request. >> >> This is a s390-only enhancement. It introduces the implementation of an AES-CTR intrinsic, making use of the specific s390 instruction for AES counter-mode encryption. >> >> Testing: SAP does no longer maintain a full build and test environment for s390. Testing is therefore limited to running some test suites (SPECjbb*, SPECjvm*) manually. But: identical code is contained in SAP's commercial product and thoroughly tested in that context. No issues were uncovered. >> >> @backwaterred Could you please conduct some "official" testing for this PR? >> >> Thank you all! >> >> Note: some performance figures can be found in the JBS ticket. > > Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: > > 8278757: add clarifying comments Looks good to my non-mainframey eyes. Impressive work. Cheers, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8142 From duke at openjdk.java.net Tue May 3 12:34:23 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Tue, 3 May 2022 12:34:23 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v3] In-Reply-To: <8c6w9Sy3iH6q7Wpr3AQUTimp04hCoYbcOgIwU7ss2d8=.49cc0946-14d8-4712-9e61-c7ab7a38dd5c@github.com> References: <6BLRx1h-CQvukYtRVcBNAROhod7j2jRNdQKU-0Cgnc0=.a0d3270e-8a82-4596-a0d0-3c295981d885@github.com> <-EEsFIwVzotOBaC9DJV9fVlXf1NBjhm51KJYeY1WDFY=.4563f592-c641-4025-986b-9c6e356100fc@github.com> <8c6w9Sy3iH6q7Wpr3AQUTimp04hCoYbcOgIwU7ss2d8=.49cc0946-14d8-4712-9e61-c7ab7a38dd5c@github.com> Message-ID: <3_bhzCIRiiYHLYo2VUusw9UIQN2Xqye1a4Jpu_QG1ek=.39490d4f-b6c7-4fe5-9499-79c17448bd07@github.com> On Mon, 2 May 2022 23:53:19 GMT, Xin Liu wrote: >> So my assumption that `trampoline_call()` could be used for call outside CodeCache is wrong (and the method's comment is correct). I looked on few places where runtime call is generated and `trampoline_call()` indeed is used only for CodeCache (at least in places are looked on): >> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/aarch64.ad#L3858 >> >> My points 1. and 2. are void. >> >> Thank you for answering my questions 3. and 4. >> >> That also explains your `need_trampoline` code change. >> >> You answered all my questions. Please, do latest merge and updates if needed so I can review final changes. > > hi, @vnkozlov , @eastig >> I would like to know why trampoline_call() could be used for relocInfo::virtual_call_type and relocInfo::opt_virtual_call_type (based on assert). They should be inside CodeCache and you don't need trampoline for it. Right? > > I take a look at `vmIntrinsics::does_virtual_dispatch`, it looks like there are 2 special intrinsics could be virtual. > when c2 calls runtime stubs for them, we actually give up this optimization, right? Is it possible to include those 2 reloc types as well? Hi Xin(@navyxliu), > I take a look at vmIntrinsics::does_virtual_dispatch, it looks like there are 2 special intrinsics could be virtual. when c2 calls runtime stubs for them, we actually give up this optimization, right? What optimization are you referring to? ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From jbachorik at openjdk.java.net Tue May 3 12:42:19 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 3 May 2022 12:42:19 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3] In-Reply-To: References: Message-ID: > A gist of the fix is to allow relaxed instantiation of a frame when done from a signal handler - eg. for profiling purposes. > > Currently, a frame instantiation will fail on guarantee when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of profiling where the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. > > The behaviour defaults to checking the code blob status in the guarantee so nothing will change for the rest of the callers - just ASGCT will be affected. > >
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. > However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: Extract common method for finding code blob in a signal handler ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8061/files - new: https://git.openjdk.java.net/jdk/pull/8061/files/a306d912..7932a651 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8061&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8061&range=01-02 Stats: 70 lines in 8 files changed: 16 ins; 48 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8061.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8061/head:pull/8061 PR: https://git.openjdk.java.net/jdk/pull/8061 From duke at openjdk.java.net Tue May 3 12:43:54 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Tue, 3 May 2022 12:43:54 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: References: Message-ID: <7fOsn1HVr0el0AEx75DKK2m-sqs1M6ykvn3zAMFI3TA=.b550c1ed-ae47-449d-a74e-10ce519bdd11@github.com> On Mon, 2 May 2022 07:51:35 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed instantiation of a frame when done from a signal handler - eg. for profiling purposes. >> >> Currently, a frame instantiation will fail on guarantee when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of profiling where the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >> The behaviour defaults to checking the code blob status in the guarantee so nothing will change for the rest of the callers - just ASGCT will be affected. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > > Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentation The consolidation is part of my JEP and one of the main purposes. It might be easier to incorporate large clean ups into this JEP to minimize duplicated work (and code). ------------- PR: https://git.openjdk.java.net/jdk/pull/8061 From jbachorik at openjdk.java.net Tue May 3 12:52:22 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 3 May 2022 12:52:22 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: <0vNBO9qi7_bymmqqV-9uFWpBm42f9TE3cdjwU4QaCiI=.018c5654-1468-47cb-a6b9-9acfb34336c0@github.com> References: <0vNBO9qi7_bymmqqV-9uFWpBm42f9TE3cdjwU4QaCiI=.018c5654-1468-47cb-a6b9-9acfb34336c0@github.com> Message-ID: <8FBzLMUDCKhF8IHOsj-HGuey9-iinJft-PEJVoLFD1A=.ecd55f3d-6192-4a1e-ac1a-d0325b950981@github.com> On Tue, 3 May 2022 01:29:31 GMT, David Holmes wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix indentation > > src/hotspot/cpu/ppc/frame_ppc.inline.hpp line 39: > >> 37: assert(pc != NULL, "precondition: must have PC"); >> 38: >> 39: if (!forSignalHandler) { > > To reduce the duplication I suggest adding a helper method to CodeCache: > > CodeBlob* find_blob(address pc, bool for_signal_handler) { > if (!for_signal_handler) { > return find_blob(pc); > } else { > CodeBlob* tmp = find_blob_unsafe(pc); > if (tmp != NULL && temp->is_zombie()) { > tmp = null; > } > return tmp; > } Done ------------- PR: https://git.openjdk.java.net/jdk/pull/8061 From duke at openjdk.java.net Tue May 3 13:27:20 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Tue, 3 May 2022 13:27:20 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v3] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 00:04:14 GMT, Xin Liu wrote: >> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Move code of target_needs_trampoline inside trampoline_call > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 562: > >> 560: >> 561: // Maybe emit a call via a trampoline. If the code cache is small >> 562: // trampolines won't be emitted. > >> "The header comment is incorrect: "If the code cache is small trampolines won't be emitted." > > I feel that Vladimir's comment is still legit here. From my reading, trampoline is avoidable because of either codecache is small (far_branches() is false) or target_needs_far_branch() is false for runtime reloc. I've created [JDK-8286056](https://bugs.openjdk.java.net/browse/JDK-8286056) to clarify uses of `far_call`/`far_jump` and [JDK-8286058](https://bugs.openjdk.java.net/browse/JDK-8286058) to clarify uses of `trampoline_call`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From mdoerr at openjdk.java.net Tue May 3 21:06:10 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 3 May 2022 21:06:10 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler [v5] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 07:36:55 GMT, Johannes Bechberger wrote: >> Fix the assertion by replacing it by assertion that does not fail. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove two superfluous assertions LGTM, too. Thanks for simplifying it! It's a lot better readable. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8209 From dlong at openjdk.java.net Tue May 3 22:39:42 2022 From: dlong at openjdk.java.net (Dean Long) Date: Tue, 3 May 2022 22:39:42 GMT Subject: RFR: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler [v5] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 07:36:55 GMT, Johannes Bechberger wrote: >> Fix the assertion by replacing it by assertion that does not fail. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove two superfluous assertions OK, this looks good. I had to refresh my memory on why I changed this code in 8161598. In retrospect, I think having anchor frames always walkable by always storing a valid last_Java_pc would greatly simplify things, and I doubt any performance difference would be measurable. ------------- Marked as reviewed by dlong (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8209 From xliu at openjdk.java.net Wed May 4 06:11:18 2022 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 4 May 2022 06:11:18 GMT Subject: RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v3] In-Reply-To: <3_bhzCIRiiYHLYo2VUusw9UIQN2Xqye1a4Jpu_QG1ek=.39490d4f-b6c7-4fe5-9499-79c17448bd07@github.com> References: <6BLRx1h-CQvukYtRVcBNAROhod7j2jRNdQKU-0Cgnc0=.a0d3270e-8a82-4596-a0d0-3c295981d885@github.com> <-EEsFIwVzotOBaC9DJV9fVlXf1NBjhm51KJYeY1WDFY=.4563f592-c641-4025-986b-9c6e356100fc@github.com> <8c6w9Sy3iH6q7Wpr3AQUTimp04hCoYbcOgIwU7ss2d8=.49cc0946-14d8-4712-9e61-c7ab7a38dd5c@github.com> <3_bhzCIRiiYHLYo2VUusw9UIQN2Xqye1a4Jpu_QG1ek=.39490d4f-b6c7-4fe5-9499-79c17448bd07@github.com> Message-ID: On Tue, 3 May 2022 12:30:57 GMT, Evgeny Astigeevich wrote: >> hi, @vnkozlov , @eastig >>> I would like to know why trampoline_call() could be used for relocInfo::virtual_call_type and relocInfo::opt_virtual_call_type (based on assert). They should be inside CodeCache and you don't need trampoline for it. Right? >> >> I take a look at `vmIntrinsics::does_virtual_dispatch`, it looks like there are 2 special intrinsics could be virtual. >> when c2 calls runtime stubs for them, we actually give up this optimization, right? Is it possible to include those 2 reloc types as well? > > Hi Xin(@navyxliu), > >> I take a look at vmIntrinsics::does_virtual_dispatch, it looks like there are 2 special intrinsics could be virtual. > when c2 calls runtime stubs for them, we actually give up this optimization, right? > > What optimization are you referring to? hi, For both LibraryCallKit::inline_native_hashcode(), inline_native_clone(), they may generate runtime calls with rrelocInfo::opt_virtual_call_type. current trampoline_call() opts out this optimization for them, right? ------------- PR: https://git.openjdk.java.net/jdk/pull/8403 From dlong at openjdk.java.net Wed May 4 07:54:38 2022 From: dlong at openjdk.java.net (Dean Long) Date: Wed, 4 May 2022 07:54:38 GMT Subject: RFR: 8283306: re-resolving indirect call to non-entrant nmethod can crash Message-ID: This change fixes a crash that can happen in SharedRuntime::reresolve_call_site with Graal/JVMCI. See https://bugs.openjdk.java.net/browse/JDK-8283306 for details. ------------- Commit messages: - check relocations to avoid false positives Changes: https://git.openjdk.java.net/jdk/pull/8528/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8528&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283306 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8528.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8528/head:pull/8528 PR: https://git.openjdk.java.net/jdk/pull/8528 From duke at openjdk.java.net Wed May 4 07:59:31 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Wed, 4 May 2022 07:59:31 GMT Subject: Integrated: 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 16:38:11 GMT, Johannes Bechberger wrote: > Fix the assertion by replacing it by assertion that does not fail. This pull request has now been integrated. Changeset: 4b2c8220 Author: Johannes Bechberger Committer: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/4b2c82200fdc01de868cf414e40a4d891e753f89 Stats: 66 lines in 17 files changed: 2 ins; 40 del; 24 mod 8282477: [x86, aarch64] vmassert(_last_Java_pc == NULL, "already walkable"); fails with async profiler Reviewed-by: dholmes, mdoerr, dlong ------------- PR: https://git.openjdk.java.net/jdk/pull/8209 From dnsimon at openjdk.java.net Wed May 4 08:08:15 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 4 May 2022 08:08:15 GMT Subject: RFR: 8283306: re-resolving indirect call to non-entrant nmethod can crash In-Reply-To: References: Message-ID: <2F9hqk0f-T1mTTnyJr3eNydYqfHBseLTSS1oprNdRMw=.143892e5-035e-4ac0-b9fb-6e0ed5ff3341@github.com> On Wed, 4 May 2022 07:47:28 GMT, Dean Long wrote: > This change fixes a crash that can happen in SharedRuntime::reresolve_call_site with Graal/JVMCI. > See https://bugs.openjdk.java.net/browse/JDK-8283306 for details. This minimal patch looks ok but I think @tkrodriguez has something more extensive in mind. src/hotspot/share/runtime/sharedRuntime.cpp line 1837: > 1835: patch_call = true; > 1836: } else { > 1837: assert(!UseInlineCaches || caller_nm->is_compiled_by_jvmci(), "relocation info. must exist for this address"); Could we please make this a `guarantee`. This is not a particularly hot code path and the failure it can cause later is very hard to debug. ------------- PR: https://git.openjdk.java.net/jdk/pull/8528 From aph-open at littlepinkcloud.com Wed May 4 08:41:36 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Wed, 4 May 2022 09:41:36 +0100 Subject: Windows integral promotions / uint64_t In-Reply-To: References: <98a9c5c9-ff43-7f1e-b512-99161cfba43a@littlepinkcloud.com> Message-ID: <3815f72f-9273-5dc0-03d7-191b1678b340@littlepinkcloud.com> On 4/28/22 17:14, Kim Barrett wrote: >> On Apr 28, 2022, at 8:53 AM, Andrew Haley wrote: >> >> I'm seeing this failure from the Windows/AArch64 C++ compiler: >> >> * For target hotspot_variant-server_libjvm_objs_stubGenerator_aarch64.obj: >> stubGenerator_aarch64.cpp >> d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\stubGenerator_aarch64.cpp(6524): error C2668: 'MacroAssembler::sub': ambiguous call to overloaded function >> d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\macroAssembler_aarch64.hpp(1174): note: could be 'void MacroAssembler::sub(Register,Register,Register)' >> d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\macroAssembler_aarch64.hpp(1174): note: or 'void MacroAssembler::sub(Register,Register,uint64_t)' >> d:\a\jdk\jdk\jdk\src\hotspot\cpu\aarch64\stubGenerator_aarch64.cpp(6524): note: while trying to match the argument list '(const Register, const Register, unsigned int)' >> ... (rest of output omitted) >> >> 6524: __ sub(sp, rfp, ((unsigned)framesize-4) << LogBytesPerInt); // prolog > > I think what may be happening here is that the third argument to sub is a constant expression > whose value is 0, so is ambiguously either an integral 0 or a null pointer. C++14 says > only a literal 0 is supposed to be implicitly convertible to a pointer [1], but C++11 and earlier > allow any constexpr 0 to implicitly convert [2]. And I noticed a while ago that gcc seems to > have retained the old behavior even in C++14 mode (at least sometimes?). Maybe Visual > Studio is doing the same? Ahh, OK. It didn't occur to me that the result of the expression might be zero. Makes sense. > But then, why aren?t we seeing similar problems with gcc? Indeed! :-) > [1] C++14 4.10/1 A null pointer constant is an integer literal (2.14.2) with value zero ? > [2] C++11 4.10/1 A null pointer constant is an integral constant expression (5.19) prvalue of integer type that evaluates to zero? > > A way to deal with this kind of thing is to use templates to inhibit conversions and use SFINAE > to select and forward to type-specific helpers. So something like > > template::value)> > void sub(Register arg0, Register arg1, ThirdArgType arg2) { sub_integral_third_arg(arg0, arg1, arg2); } > > template::value)> > void sub(Register arg0, Register arg1, ThirdArgType arg2) { sub_ponter_third_arg(arg0, arg1, arg2); } > > This is obviously pretty ugly, and not something I would really recommend here. Right. > Once again the hacky way Register is defined is biting us. Interesting! This relates to the patch for 8276563 I wrote early this year. It fixes the Undefined Behaviour of Register, but keeps it as a pointer type. I did look at making Register a class with a single const field, but the quality of generated code was poor. In particular, for some reason I don't understand, Register instances were being passed by reference. I have it on my list of Things To Do One Day to fix x86 and VMReg in a similar way. 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 duke at openjdk.java.net Wed May 4 09:09:01 2022 From: duke at openjdk.java.net (Tobias Holenstein) Date: Wed, 4 May 2022 09:09:01 GMT Subject: RFR: JDK-8283807: Handle CompileThreshold the same as other thresholds when scaled with -XX:CompileThresholdScaling [v2] In-Reply-To: References: Message-ID: > `CompileThresholdScaling` scales several compiler thresholds. If the scaled threshold value is outside of the allowed range, a warning is printed and the default value is kept. But when scaling `CompileThreshold` we do not check the scaled value because it is not a ranged flag. Later when verifying flags with a constraint function `OnStackReplacePercentageConstraintFunc` which calls `CompileThresholdConstraintFunc` fails because `CompileThreshold` is outside of the allowed range. This stops the VM from being created. > > The fix is to call `CompileThresholdConstraintFunc` when scaling `CompileThreshold` with `CompileThresholdScaling`. If `CompileThresholdConstraintFunc` fails we print a warning and keep the default value of `CompileThreshold`. This behaviour is then consistent with the other 15 other thresholds where the VM just prints a warning if the scaled value is too large and then keeps the current value. > > We also have to exclude `CompileThresholdScaling` from max. range testing in `TestOptionsWithRanges.java`, because > it is expected to print "outside the allowed range" warnings for the scaled flag and the "outside the allowed range" warning does not refer to `CompileThresholdScaling` itself. > > One question that remains it why `CompileThresholdScaling` takes the default value when a scaled threshold is too large instead of the max. value? Because now we can have the case where some compiler thresholds are scaled to almost their max. value and others that are already larger than the maximum are default again (which can be the minimum value in some cases). I suggest to address this issue in a separate RFE. Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision: TestCompileThresholdScaling added ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8501/files - new: https://git.openjdk.java.net/jdk/pull/8501/files/834cfcfb..6d0e434a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8501&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8501&range=00-01 Stats: 72 lines in 1 file changed: 72 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8501.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8501/head:pull/8501 PR: https://git.openjdk.java.net/jdk/pull/8501 From duke at openjdk.java.net Wed May 4 09:26:04 2022 From: duke at openjdk.java.net (Tobias Holenstein) Date: Wed, 4 May 2022 09:26:04 GMT Subject: RFR: JDK-8283807: Handle CompileThreshold the same as other thresholds when scaled with -XX:CompileThresholdScaling [v3] In-Reply-To: References: Message-ID: > `CompileThresholdScaling` scales several compiler thresholds. If the scaled threshold value is outside of the allowed range, a warning is printed and the default value is kept. But when scaling `CompileThreshold` we do not check the scaled value because it is not a ranged flag. Later when verifying flags with a constraint function `OnStackReplacePercentageConstraintFunc` which calls `CompileThresholdConstraintFunc` fails because `CompileThreshold` is outside of the allowed range. This stops the VM from being created. > > The fix is to call `CompileThresholdConstraintFunc` when scaling `CompileThreshold` with `CompileThresholdScaling`. If `CompileThresholdConstraintFunc` fails we print a warning and keep the default value of `CompileThreshold`. This behaviour is then consistent with the other 15 other thresholds where the VM just prints a warning if the scaled value is too large and then keeps the current value. > > We also have to exclude `CompileThresholdScaling` from max. range testing in `TestOptionsWithRanges.java`, because > it is expected to print "outside the allowed range" warnings for the scaled flag and the "outside the allowed range" warning does not refer to `CompileThresholdScaling` itself. > > One question that remains it why `CompileThresholdScaling` takes the default value when a scaled threshold is too large instead of the max. value? Because now we can have the case where some compiler thresholds are scaled to almost their max. value and others that are already larger than the maximum are default again (which can be the minimum value in some cases). I suggest to address this issue in a separate RFE. Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision: adjusted comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8501/files - new: https://git.openjdk.java.net/jdk/pull/8501/files/6d0e434a..8879d895 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8501&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8501&range=01-02 Stats: 19 lines in 2 files changed: 1 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/8501.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8501/head:pull/8501 PR: https://git.openjdk.java.net/jdk/pull/8501 From duke at openjdk.java.net Wed May 4 09:26:05 2022 From: duke at openjdk.java.net (Tobias Holenstein) Date: Wed, 4 May 2022 09:26:05 GMT Subject: RFR: JDK-8283807: Handle CompileThreshold the same as other thresholds when scaled with -XX:CompileThresholdScaling [v3] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 20:37:34 GMT, Ioi Lam wrote: > Could you add a test case with several large values for -XX:CompileThresholdScaling and check that the warning message is printed? I added a test now > test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java line 264: > >> 262: * it is expected to print "outside the allowed range" warnings for >> 263: * the scaled flags >> 264: */ > > This comment is not very clear. Do you mean > > > Max range tests expect a warning message of "outside the allowed range" > but CompileThresholdScaling prints a different warning message when it's > set too high. I changed to comment. I hope it is clearer now ------------- PR: https://git.openjdk.java.net/jdk/pull/8501 From lucy at openjdk.java.net Wed May 4 09:42:23 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 4 May 2022 09:42:23 GMT Subject: RFR: 8278757: [s390] Implement AES Counter Mode Intrinsic [v9] In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 21:42:39 GMT, Tyler Steele wrote: >> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: >> >> 8278757: add clarifying comments > > I see I have missed a request or two to re-run these tests. Sorry to keep you waiting! The much anticipated s390x Tier1 tests are running now. Updates will appear below. > > --- > > > # newfailures.txt > compiler/c2/irTests/TestAutoVectorization2DArray.java > > > The results completed overnight. It's just our old friend that failed. Looking good @RealLucy. A big thank you to the tester (@backwaterred) and the Reviewers (@TheRealMDoerr, @tstuefe)! ------------- PR: https://git.openjdk.java.net/jdk/pull/8142 From lucy at openjdk.java.net Wed May 4 09:42:24 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 4 May 2022 09:42:24 GMT Subject: Integrated: 8278757: [s390] Implement AES Counter Mode Intrinsic In-Reply-To: References: Message-ID: On Thu, 7 Apr 2022 10:02:07 GMT, Lutz Schmidt wrote: > Please review (and approve, if possible) this pull request. > > This is a s390-only enhancement. It introduces the implementation of an AES-CTR intrinsic, making use of the specific s390 instruction for AES counter-mode encryption. > > Testing: SAP does no longer maintain a full build and test environment for s390. Testing is therefore limited to running some test suites (SPECjbb*, SPECjvm*) manually. But: identical code is contained in SAP's commercial product and thoroughly tested in that context. No issues were uncovered. > > @backwaterred Could you please conduct some "official" testing for this PR? > > Thank you all! > > Note: some performance figures can be found in the JBS ticket. This pull request has now been integrated. Changeset: 4e1e76ac Author: Lutz Schmidt URL: https://git.openjdk.java.net/jdk/commit/4e1e76acfb2ac6131297fcea282bb7f2ca556f0e Stats: 716 lines in 7 files changed: 683 ins; 5 del; 28 mod 8278757: [s390] Implement AES Counter Mode Intrinsic Reviewed-by: mdoerr, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/8142 From stuefe at openjdk.java.net Wed May 4 10:56:31 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 4 May 2022 10:56:31 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3] In-Reply-To: References: Message-ID: <8zeVzTo0MAFksNZanTwMVwLxnLqb4bQm-5VKAlRRwjc=.f08cf30c-e16d-447a-8624-85f2b6a52dae@github.com> On Tue, 3 May 2022 12:42:19 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed instantiation of a frame when done from a signal handler - eg. for profiling purposes. >> >> Currently, a frame instantiation will fail on guarantee when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of profiling where the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >> The behaviour defaults to checking the code blob status in the guarantee so nothing will change for the rest of the callers - just ASGCT will be affected. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > > Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: > > Extract common method for finding code blob in a signal handler Hi, sorry for the late chiming in. Could we find a better way to do this that to funnel "is_signal_handler" thru every layer? How about a thread-local state instead? E.g. "bool Thread::_unsafe_code_cache_lookup"? Or, for that matter, "bool Thread::in_agct"? Could be set and restored at the beginning resp. end of AGCT. I dislike the name "in_signal_handler" since the fact that we are inside signal handling is incidental. IIUC this is probably much more often a thread-safety issue than a reentrance issue, right? You would have the same problem if you analyzed the code cache without getting the code cache lock, while it is concurrently modified? So if you want to keep the argument, how about renaming it to "unsafe", or "unsafe_access", or "unsafe_codecache_lookup"? We use "unsafe" in other places as well. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/8061 From duke at openjdk.java.net Wed May 4 12:08:47 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Wed, 4 May 2022 12:08:47 GMT Subject: RFR: 8286056: AArch64: clarify uses of MacroAssembler::far_call/MacroAssembler::far_jump Message-ID: `MacroAssembler::far_call`/`MacroAssembler::far_jump` are for generating calls of/jumps to targets which are inside `CodeCache` and can `relocInfo` types: `external_word_type`, `runtime_call_type` or `none`. This PR updates the description of the functions and adds an assert checking a `relocInfo` type. Tested a fastdebug build: - `gtest`: Passed - `tier1`: Passed ------------- Commit messages: - 8286056: AArch64: clarify uses of MacroAssembler::far_call/MacroAssembler::far_jump Changes: https://git.openjdk.java.net/jdk/pull/8534/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8534&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286056 Stats: 16 lines in 3 files changed: 13 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8534.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8534/head:pull/8534 PR: https://git.openjdk.java.net/jdk/pull/8534 From alanb at openjdk.java.net Wed May 4 12:12:48 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 4 May 2022 12:12:48 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v11] In-Reply-To: References: Message-ID: > This is the implementation of JEP 425: Virtual Threads (Preview). > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05 - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89 - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4 - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec - Merge with jdk-19+20 - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1 - Merge with jdk-19+19 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/4b2c8220...f06aff75 ------------- Changes: https://git.openjdk.java.net/jdk/pull/8166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=10 Stats: 102779 lines in 1140 files changed: 92909 ins; 4219 del; 5651 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From jbachorik at openjdk.java.net Wed May 4 12:21:19 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Wed, 4 May 2022 12:21:19 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3] In-Reply-To: <8zeVzTo0MAFksNZanTwMVwLxnLqb4bQm-5VKAlRRwjc=.f08cf30c-e16d-447a-8624-85f2b6a52dae@github.com> References: <8zeVzTo0MAFksNZanTwMVwLxnLqb4bQm-5VKAlRRwjc=.f08cf30c-e16d-447a-8624-85f2b6a52dae@github.com> Message-ID: On Wed, 4 May 2022 10:53:29 GMT, Thomas Stuefe wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: >> >> Extract common method for finding code blob in a signal handler > > Hi, > > sorry for the late chiming in. > > Could we find a better way to do this that to funnel "is_signal_handler" thru every layer? How about a thread-local state instead? E.g. "bool Thread::_unsafe_code_cache_lookup"? Or, for that matter, "bool Thread::in_agct"? Could be set and restored at the beginning resp. end of AGCT. > > I dislike the name "in_signal_handler" since the fact that we are inside signal handling is incidental. IIUC this is probably much more often a thread-safety issue than a reentrance issue, right? You would have the same problem if you analyzed the code cache without getting the code cache lock, while it is concurrently modified? > > So if you want to keep the argument, how about renaming it to "unsafe", or "unsafe_access", or "unsafe_codecache_lookup"? We use "unsafe" in other places as well. > > Cheers, Thomas Hi @tstuefe , Thanks for the review. > Could we find a better way to do this that to funnel "is_signal_handler" thru every layer? How about a thread-local state instead? E.g. "bool Thread::_unsafe_code_cache_lookup"? Or, for that matter, "bool Thread::in_agct"? Could be set and restored at the beginning resp. end of AGCT. I wanted to avoid as much 'magic' as possible because usually I find such PRs as having higher chance of getting reviewed. But if using a TLS to avoid funnelling extra arg is something what would usually be done I will revisit the patch and use that instead. > I dislike the name "in_signal_handler" since the fact that we are inside signal handling is incidental. IIUC this is probably much more often a thread-safety issue than a reentrance issue, right? You would have the same problem if you analyzed the code cache without getting the code cache lock, while it is concurrently modified? > So if you want to keep the argument, how about renaming it to "unsafe", or "unsafe_access", or "unsafe_codecache_lookup"? We use "unsafe" in other places as well. Interestingly enough, my first sketch of the patch was using the `unsafe_access` named argument :) Then I renamed it to look less scary. If the TLS approach won't work out and I need to pass in the extra argument I can definitely rename it `unsafe_access` if that is not going to freak out the reviewers :) ------------- PR: https://git.openjdk.java.net/jdk/pull/8061 From aph at openjdk.java.net Wed May 4 12:59:13 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 4 May 2022 12:59:13 GMT Subject: RFR: 8286056: AArch64: clarify uses of MacroAssembler::far_call/MacroAssembler::far_jump In-Reply-To: References: Message-ID: On Wed, 4 May 2022 12:01:36 GMT, Evgeny Astigeevich wrote: > `MacroAssembler::far_call`/`MacroAssembler::far_jump` are for generating calls of/jumps to targets which are inside `CodeCache` and can `relocInfo` types: `external_word_type`, `runtime_call_type` or `none`. > This PR updates the description of the functions and adds an assert checking a `relocInfo` type. > Tested a fastdebug build: > - `gtest`: Passed > - `tier1`: Passed OK. I'm not sure the new assertions add very much, but they're harmless. ------------- Marked as reviewed by aph (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8534 From dholmes at openjdk.java.net Wed May 4 13:12:12 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 4 May 2022 13:12:12 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3] In-Reply-To: References: <8zeVzTo0MAFksNZanTwMVwLxnLqb4bQm-5VKAlRRwjc=.f08cf30c-e16d-447a-8624-85f2b6a52dae@github.com> Message-ID: <6UYelWprhbe1Kl7svX7cQoB3U9XMz8ZED7AsRBoiSEo=.efe1f6c1-3b3c-4132-973f-81a0de5a86d0@github.com> On Wed, 4 May 2022 12:17:38 GMT, Jaroslav Bachorik wrote: > But if using a TLS to avoid funnelling extra arg is something what would usually be done I will revisit the patch and use that instead. You can't set TLS from a signal handler either. Reading library-based TLS is considered safe enough. ------------- PR: https://git.openjdk.java.net/jdk/pull/8061 From stuefe at openjdk.java.net Wed May 4 13:21:16 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 4 May 2022 13:21:16 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3] In-Reply-To: <6UYelWprhbe1Kl7svX7cQoB3U9XMz8ZED7AsRBoiSEo=.efe1f6c1-3b3c-4132-973f-81a0de5a86d0@github.com> References: <8zeVzTo0MAFksNZanTwMVwLxnLqb4bQm-5VKAlRRwjc=.f08cf30c-e16d-447a-8624-85f2b6a52dae@github.com> <6UYelWprhbe1Kl7svX7cQoB3U9XMz8ZED7AsRBoiSEo=.efe1f6c1-3b3c-4132-973f-81a0de5a86d0@github.com> Message-ID: On Wed, 4 May 2022 13:08:40 GMT, David Holmes wrote: > > But if using a TLS to avoid funnelling extra arg is something what would usually be done I will revisit the patch and use that instead. > > You can't set TLS from a signal handler either. Reading library-based TLS is considered safe enough. No need, since you only need to adjust a member inside Thread. e.g. `Thread::current()->set_unsafe_access_mode(true)` inside AGCT. ------------- PR: https://git.openjdk.java.net/jdk/pull/8061 From duke at openjdk.java.net Wed May 4 13:28:14 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Wed, 4 May 2022 13:28:14 GMT Subject: RFR: 8286056: AArch64: clarify uses of MacroAssembler::far_call/MacroAssembler::far_jump In-Reply-To: References: Message-ID: On Wed, 4 May 2022 12:55:35 GMT, Andrew Haley wrote: > OK. I'm not sure the new assertions add very much, but they're harmless. Thank you for reviewing. Actually they helped. I found a use of `far_jump` I was not aware of: `InlineCacheBuffer::assemble_ic_buffer_code`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8534 From shade at openjdk.java.net Wed May 4 16:05:06 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 4 May 2022 16:05:06 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v11] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 12:12:48 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview). >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05 > - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89 > - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a > - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4 > - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec > - Merge with jdk-19+20 > - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 > - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1 > - Merge with jdk-19+19 > - ... and 7 more: https://git.openjdk.java.net/jdk/compare/4b2c8220...f06aff75 > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. So, does this PR pass current GHA checks? I see they are not enabled for this PR. It would be unfortunate for this large integration to break builds/tests for smaller PRs that would follow it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From kvn at openjdk.java.net Wed May 4 16:07:24 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 4 May 2022 16:07:24 GMT Subject: RFR: 8286056: AArch64: clarify uses of MacroAssembler::far_call/MacroAssembler::far_jump In-Reply-To: References: Message-ID: On Wed, 4 May 2022 12:01:36 GMT, Evgeny Astigeevich wrote: > `MacroAssembler::far_call`/`MacroAssembler::far_jump` are for generating calls of/jumps to targets which are inside `CodeCache` and can `relocInfo` types: `external_word_type`, `runtime_call_type` or `none`. > This PR updates the description of the functions and adds an assert checking a `relocInfo` type. > Tested a fastdebug build: > - `gtest`: Passed > - `tier1`: Passed src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1105: > 1103: // - relocInfo::none > 1104: // If the distance to the address can exceed the branch range (128M for the release build) > 1105: // for direct calls/jumps, an indirect call/jump is generated. What is `indirect` in this case? Is it the use of `adrp` or it is `trampoline` (which is also kind of `indirect`)? What is used in `debug` build (since you mentioned `release` build)? Would be nice if you also add similar extended description for `trampoline_call()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8534 From never at openjdk.java.net Wed May 4 16:34:48 2022 From: never at openjdk.java.net (Tom Rodriguez) Date: Wed, 4 May 2022 16:34:48 GMT Subject: RFR: 8283306: re-resolving indirect call to non-entrant nmethod can crash In-Reply-To: References: Message-ID: On Wed, 4 May 2022 07:47:28 GMT, Dean Long wrote: > This change fixes a crash that can happen in SharedRuntime::reresolve_call_site with Graal/JVMCI. > See https://bugs.openjdk.java.net/browse/JDK-8283306 for details. I think a formulation more like this makes it clearer. I'm not sure I agree with the assert/guarantee in the default path since it seems overly specific. if (call_addr != NULL) { // On x86 the logic for finding a call instruction is blindly checking for a call opcode 5 // bytes back in the instruction stream so we must also check for reloc info. RelocIterator iter(caller_nm, call_addr, call_addr+1); int ret = iter.next(); // Get item if (ret) { bool is_static_call = false; switch (iter.type()) { case relocInfo::static_call_type: is_static_call = true; case relocInfo::virtual_call_type: case relocInfo::opt_virtual_call_type: // Cleaning the inline cache will force a new resolve. This is more robust // than directly setting it to the new destination, since resolving of calls // is always done through the same code path. (experience shows that it // leads to very hard to track down bugs, if an inline cache gets updated // to a wrong method). It should not be performance critical, since the // resolve is only done once. guarantee(iter.addr() == call_addr, "must find call"); for (;;) { ICRefillVerifier ic_refill_verifier; if (!clear_ic_at_addr(caller_nm, call_addr, is_static_call)) { InlineCacheBuffer::refill_ic_stubs(); } else { break; } } break; default: guarantee(!UseInlineCaches || caller_nm->is_compiled_by_jvmci(), "relocation info. must exist for this address"); } } } ------------- PR: https://git.openjdk.java.net/jdk/pull/8528 From duke at openjdk.java.net Wed May 4 16:56:40 2022 From: duke at openjdk.java.net (ExE Boss) Date: Wed, 4 May 2022 16:56:40 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 10:40:02 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: > > - Merge branch 'master' into foreign-preview > - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Tweak support for Linker lookup > Improve javadoc of SymbolLookup > - Tweak Addressable javadoc > - Downcall and upcall tests use wrong layout which is missing some trailing padding > - Simplify libraryLookup impl > - Address CSR comments > - Merge branch 'master' into foreign-preview > - Add ValueLayout changes > - Tweak support for array element var handle > - ... and 47 more: https://git.openjdk.java.net/jdk/compare/af1ee1cc...41d055ab src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 116: > 114: * Linker nativeLinker = Linker.nativeLinker(); > 115: * SymbolLookup stdlib = nativeLinker.defaultLookup(); > 116: * MemorySegment malloc = stdlib.lookup("malloc"); This?should?be: Suggestion: * Optional malloc = stdlib.lookup("malloc"); or Suggestion: * MemorySegment malloc = stdlib.lookup("malloc").orElseThrow(); src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 153: > 151: static SymbolLookup loaderLookup() { > 152: Class caller = Reflection.getCallerClass(); > 153: ClassLoader loader = Objects.requireNonNull(caller.getClassLoader()); Shouldn?t?this be?changed to?throw `IllegalCallerException` instead?of?throwing `NullPointerException` when?the?`caller`?s `ClassLoader` is?`null`[^1] or?when `caller`?itself is?`null`[^2]? [^1]: This?happens when?`caller` is?on the?bootstrap?classpath. [^2]: This?happens when `SymbolLookup.loaderLookup()` is?called by?native?code and?no?**Java**?code is?on?the?call?stack. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From duke at openjdk.java.net Wed May 4 17:08:31 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Wed, 4 May 2022 17:08:31 GMT Subject: RFR: 8286056: AArch64: clarify uses of MacroAssembler::far_call/MacroAssembler::far_jump In-Reply-To: References: Message-ID: On Wed, 4 May 2022 16:04:20 GMT, Vladimir Kozlov wrote: > Would be nice if you also add similar extended description for trampoline_call(). Yes, I'll do: https://bugs.openjdk.java.net/browse/JDK-8286058 > What is indirect in this case? Is it the use of adrp or it is trampoline (which is also kind of indirect)? It is a call/branch at an address in a register. Yes, a trampoline is an indirect far call. I'll update the comment. Trampolines use `ldr` instead of `adrp` which allows jumping anywhere in the memory. `adrp` in limited to 4Gb. As trampolines are always used for calling code inside `CodeCache` and `CodeCache` is limited to 2Gb, using `ldr` might be expensive in such cases. Created https://bugs.openjdk.java.net/browse/JDK-8286140. > What is used in debug build (since you mentioned release build)? 2M. 128M is ISA limit. ------------- PR: https://git.openjdk.java.net/jdk/pull/8534 From kvn at openjdk.java.net Wed May 4 17:52:20 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 4 May 2022 17:52:20 GMT Subject: RFR: 8286056: AArch64: clarify uses of MacroAssembler::far_call/MacroAssembler::far_jump In-Reply-To: References: Message-ID: On Wed, 4 May 2022 12:01:36 GMT, Evgeny Astigeevich wrote: > `MacroAssembler::far_call`/`MacroAssembler::far_jump` are for generating calls of/jumps to targets which are inside `CodeCache` and can `relocInfo` types: `external_word_type`, `runtime_call_type` or `none`. > This PR updates the description of the functions and adds an assert checking a `relocInfo` type. > Tested a fastdebug build: > - `gtest`: Passed > - `tier1`: Passed Good. Marked as reviewed by kvn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8534 From duke at openjdk.java.net Wed May 4 18:27:14 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Wed, 4 May 2022 18:27:14 GMT Subject: RFR: 8286056: AArch64: clarify uses of MacroAssembler::far_call/MacroAssembler::far_jump [v2] In-Reply-To: References: Message-ID: > `MacroAssembler::far_call`/`MacroAssembler::far_jump` are for generating calls of/jumps to targets which are inside `CodeCache` and can `relocInfo` types: `external_word_type`, `runtime_call_type` or `none`. > This PR updates the description of the functions and adds an assert checking a `relocInfo` type. > Tested a fastdebug build: > - `gtest`: Passed > - `tier1`: Passed Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: Add additional comments to far_call/far_branch ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8534/files - new: https://git.openjdk.java.net/jdk/pull/8534/files/9e6e89df..fd5689bb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8534&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8534&range=00-01 Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8534.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8534/head:pull/8534 PR: https://git.openjdk.java.net/jdk/pull/8534 From duke at openjdk.java.net Wed May 4 18:27:14 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Wed, 4 May 2022 18:27:14 GMT Subject: RFR: 8286056: AArch64: clarify uses of MacroAssembler::far_call/MacroAssembler::far_jump [v2] In-Reply-To: References: Message-ID: <39McImyfBjPhYrWLvlE_eY_5z9WzRCXUt-YI3atZprI=.84dc6179-ac98-4014-8707-e3d605b7821a@github.com> On Wed, 4 May 2022 17:04:39 GMT, Evgeny Astigeevich wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1105: >> >>> 1103: // - relocInfo::none >>> 1104: // If the distance to the address can exceed the branch range (128M for the release build) >>> 1105: // for direct calls/jumps, an indirect call/jump is generated. >> >> What is `indirect` in this case? Is it the use of `adrp` or it is `trampoline` (which is also kind of `indirect`)? >> What is used in `debug` build (since you mentioned `release` build)? >> Would be nice if you also add similar extended description for `trampoline_call()`. > >> Would be nice if you also add similar extended description for trampoline_call(). > > Yes, I'll do: https://bugs.openjdk.java.net/browse/JDK-8286058 > >> What is indirect in this case? Is it the use of adrp or it is trampoline (which is also kind of indirect)? > > It is a call/branch at an address in a register. Yes, a trampoline is an indirect far call. I'll update the comment. > Trampolines use `ldr` instead of `adrp` which allows jumping anywhere in the memory. `adrp` in limited to 4Gb. As trampolines are always used for calling code inside `CodeCache` and `CodeCache` is limited to 2Gb, using `ldr` might be expensive in such cases. Created https://bugs.openjdk.java.net/browse/JDK-8286140. > >> What is used in debug build (since you mentioned release build)? > > 2M. 128M is ISA limit. Vladimir, I have updated the description according to your comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/8534 From kvn at openjdk.java.net Wed May 4 18:37:25 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 4 May 2022 18:37:25 GMT Subject: RFR: 8286056: AArch64: clarify uses of MacroAssembler::far_call/MacroAssembler::far_jump [v2] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 18:27:14 GMT, Evgeny Astigeevich wrote: >> `MacroAssembler::far_call`/`MacroAssembler::far_jump` are for generating calls of/jumps to targets which are inside `CodeCache` and can `relocInfo` types: `external_word_type`, `runtime_call_type` or `none`. >> This PR updates the description of the functions and adds an assert checking a `relocInfo` type. >> Tested a fastdebug build: >> - `gtest`: Passed >> - `tier1`: Passed > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Add additional comments to far_call/far_branch Looks good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8534 From dlong at openjdk.java.net Wed May 4 18:43:15 2022 From: dlong at openjdk.java.net (Dean Long) Date: Wed, 4 May 2022 18:43:15 GMT Subject: RFR: 8283306: re-resolving indirect call to non-entrant nmethod can crash [v2] In-Reply-To: References: Message-ID: > This change fixes a crash that can happen in SharedRuntime::reresolve_call_site with Graal/JVMCI. > See https://bugs.openjdk.java.net/browse/JDK-8283306 for details. Dean Long has updated the pull request incrementally with one additional commit since the last revision: Tom's suggested fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8528/files - new: https://git.openjdk.java.net/jdk/pull/8528/files/8861b248..13272e1d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8528&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8528&range=00-01 Stats: 30 lines in 1 file changed: 2 ins; 3 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/8528.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8528/head:pull/8528 PR: https://git.openjdk.java.net/jdk/pull/8528 From dlong at openjdk.java.net Wed May 4 18:46:24 2022 From: dlong at openjdk.java.net (Dean Long) Date: Wed, 4 May 2022 18:46:24 GMT Subject: RFR: 8283306: re-resolving indirect call to non-entrant nmethod can crash [v2] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 18:43:15 GMT, Dean Long wrote: >> This change fixes a crash that can happen in SharedRuntime::reresolve_call_site with Graal/JVMCI. >> See https://bugs.openjdk.java.net/browse/JDK-8283306 for details. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > Tom's suggested fix OK, I used Tom's suggested fix. I removed the !UseInlineCaches guarantee. JDK19 doesn't seem to honor the flag for x86 anymore, and if the guarantee was useful it would make sense to use it whenever we don't clean the IC, whether iter.next() returns true or false. ------------- PR: https://git.openjdk.java.net/jdk/pull/8528 From dlong at openjdk.java.net Wed May 4 18:52:12 2022 From: dlong at openjdk.java.net (Dean Long) Date: Wed, 4 May 2022 18:52:12 GMT Subject: RFR: 8283306: re-resolving indirect call to non-entrant nmethod can crash [v3] In-Reply-To: References: Message-ID: > This change fixes a crash that can happen in SharedRuntime::reresolve_call_site with Graal/JVMCI. > See https://bugs.openjdk.java.net/browse/JDK-8283306 for details. Dean Long has updated the pull request incrementally with one additional commit since the last revision: iter.next() returns bool ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8528/files - new: https://git.openjdk.java.net/jdk/pull/8528/files/13272e1d..8e1be231 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8528&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8528&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8528.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8528/head:pull/8528 PR: https://git.openjdk.java.net/jdk/pull/8528 From psandoz at openjdk.java.net Wed May 4 19:13:27 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 4 May 2022 19:13:27 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 11:03:48 GMT, Jatin Bhateja wrote: > Hi All, > > Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) > > Following is the brief summary of changes:- > > 1) Extends the scope of existing lanewise API for following new vector operations. > - VectorOperations.BIT_COUNT: counts the number of one-bits > - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits > - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits > - VectorOperations.REVERSE: reversing the order of bits > - VectorOperations.REVERSE_BYTES: reversing the order of bytes > - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. > > 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. > - Vector.compress > - Vector.expand > - VectorMask.compress > > 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. > - Vector.fromMemorySegment > - Vector.intoMemorySegment > > 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. > > > Patch has been regressed over AARCH64 and X86 targets different AVX levels. > > Kindly review and share your feedback. > > Best Regards, > Jatin src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1340: > 1338: assert_different_registers(dst, src, vtmp1, vtmp2, vtmp3, vtmp4); > 1339: assert_different_registers(mask, ptmp, pgtmp); > 1340: // Example input: src = 88 77 66 45 44 33 22 11 Suggestion: // Example input: src = 88 77 66 55 44 33 22 11 ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From egahlin at openjdk.java.net Wed May 4 21:02:31 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 4 May 2022 21:02:31 GMT Subject: RFR: 8282420: JFR: Remove event handlers Message-ID: Hi, Could I have a review of a fix that removes event handler classes for JFR. Bytecode for event instrumentation is now only added to the event class. Benefits are: - No class memory leak in the boot class loader. - Reduce overhead from class loading during startup, which is important with additional JDK events that are coming (VirtualThreadStart etc.) - One less frame to traverse when recording a Java stack trace. Future benefits are: - Simplify creating instrumentation at build step. See https://bugs.openjdk.java.net/browse/JDK-8279354 - Simplify implementation of Event Metrics. See https://bugs.openjdk.java.net/browse/JDK-8224749 When the Security Manager is removed, much of the code being added for security reasons can be deleted. There are few JFR hooks when code is being linked. Plan is to also use these for other events later. Testing: tier 1-4, jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Test cleanup - Test fixes - Fix whitespaces - Use EventWriterFactory - Initial Changes: https://git.openjdk.java.net/jdk/pull/8383/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282420 Stats: 4016 lines in 79 files changed: 2412 ins; 1010 del; 594 mod Patch: https://git.openjdk.java.net/jdk/pull/8383.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8383/head:pull/8383 PR: https://git.openjdk.java.net/jdk/pull/8383 From dlong at openjdk.java.net Wed May 4 22:57:13 2022 From: dlong at openjdk.java.net (Dean Long) Date: Wed, 4 May 2022 22:57:13 GMT Subject: RFR: 8283306: re-resolving indirect call to non-entrant nmethod can crash [v4] In-Reply-To: References: Message-ID: > This change fixes a crash that can happen in SharedRuntime::reresolve_call_site with Graal/JVMCI. > See https://bugs.openjdk.java.net/browse/JDK-8283306 for details. Dean Long has updated the pull request incrementally with one additional commit since the last revision: cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8528/files - new: https://git.openjdk.java.net/jdk/pull/8528/files/8e1be231..5433abeb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8528&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8528&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8528.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8528/head:pull/8528 PR: https://git.openjdk.java.net/jdk/pull/8528 From mcimadamore at openjdk.java.net Wed May 4 23:24:29 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 4 May 2022 23:24:29 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 16:47:28 GMT, ExE Boss wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 57 commits: >> >> - Merge branch 'master' into foreign-preview >> - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - Tweak support for Linker lookup >> Improve javadoc of SymbolLookup >> - Tweak Addressable javadoc >> - Downcall and upcall tests use wrong layout which is missing some trailing padding >> - Simplify libraryLookup impl >> - Address CSR comments >> - Merge branch 'master' into foreign-preview >> - Add ValueLayout changes >> - Tweak support for array element var handle >> - ... and 47 more: https://git.openjdk.java.net/jdk/compare/af1ee1cc...41d055ab > > src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 153: > >> 151: static SymbolLookup loaderLookup() { >> 152: Class caller = Reflection.getCallerClass(); >> 153: ClassLoader loader = Objects.requireNonNull(caller.getClassLoader()); > > Shouldn?t?this be?changed to?throw `IllegalCallerException` instead?of?throwing `NullPointerException` when?the?`caller`?s `ClassLoader` is?`null`[^1] or?when `caller`?itself is?`null`[^2]? > > [^1]: This?happens when?`caller` is?on the?bootstrap?classpath. > [^2]: This?happens when `SymbolLookup.loaderLookup()` is?called by?native?code and?no?**Java**?code is?on?the?call?stack. Good points. Regarding `ClassLoader` being null, I think we can still return something using the `BootLoader`'s `NativeLibraries` object - that would allow this method to be called internally. @mlchung Can you please confirm? As for the caller sensitive having no real caller (e.g. because method is called directly from native code), I think we should add a check in `Reflection::ensureNativeAccess`. Few weeks ago I verified that adding such a check does not compromise upcall stub created via the Linker interface (e.g. a Java upcall might require to perform restricted operations - but those operation always happen inside the upcall MH, which is always associated with some class). ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Wed May 4 23:30:35 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 4 May 2022 23:30:35 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v38] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Tweak examples in SymbolLookup javadoc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/41d055ab..853f06b8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=37 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=36-37 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Wed May 4 23:32:49 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 4 May 2022 23:32:49 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 23:20:21 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 153: >> >>> 151: static SymbolLookup loaderLookup() { >>> 152: Class caller = Reflection.getCallerClass(); >>> 153: ClassLoader loader = Objects.requireNonNull(caller.getClassLoader()); >> >> Shouldn?t?this be?changed to?throw `IllegalCallerException` instead?of?throwing `NullPointerException` when?the?`caller`?s `ClassLoader` is?`null`[^1] or?when `caller`?itself is?`null`[^2]? >> >> [^1]: This?happens when?`caller` is?on the?bootstrap?classpath. >> [^2]: This?happens when `SymbolLookup.loaderLookup()` is?called by?native?code and?no?**Java**?code is?on?the?call?stack. > > Good points. Regarding `ClassLoader` being null, I think we can still return something using the `BootLoader`'s `NativeLibraries` object - that would allow this method to be called internally. @mlchung Can you please confirm? > > As for the caller sensitive having no real caller (e.g. because method is called directly from native code), I think we should add a check in `Reflection::ensureNativeAccess`. Few weeks ago I verified that adding such a check does not compromise upcall stub created via the Linker interface (e.g. a Java upcall might require to perform restricted operations - but those operation always happen inside the upcall MH, which is always associated with some class). Another option would be to treat calls to `ensureNativeAccess` with `null` caller class as coming from unnamed module. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Wed May 4 23:47:30 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 4 May 2022 23:47:30 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 23:29:53 GMT, Maurizio Cimadamore wrote: >> Good points. Regarding `ClassLoader` being null, I think we can still return something using the `BootLoader`'s `NativeLibraries` object - that would allow this method to be called internally. @mlchung Can you please confirm? >> >> As for the caller sensitive having no real caller (e.g. because method is called directly from native code), I think we should add a check in `Reflection::ensureNativeAccess`. Few weeks ago I verified that adding such a check does not compromise upcall stub created via the Linker interface (e.g. a Java upcall might require to perform restricted operations - but those operation always happen inside the upcall MH, which is always associated with some class). > > Another option would be to treat calls to `ensureNativeAccess` with `null` caller class as coming from unnamed module. Looking deeper, `System::loadLibrary` seems to search the boot loader libraries when invoked with a `null` caller class, so replicating that behavior should be safe. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From xgong at openjdk.java.net Thu May 5 01:15:30 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 5 May 2022 01:15:30 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v2] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 21:34:13 GMT, Paul Sandoz wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename the "usePred" to "offsetInRange" > > IIUC when the hardware does not support predicated loads then any false `offsetIntRange` value causes the load intrinsic to fail resulting in the fallback, so it would not be materially any different to the current behavior, just more uniformly implemented. > > Why can't the intrinsic support the passing a boolean directly? Is it something to do with constants? If that is not possible I recommend creating named constant values and pass those all the way through rather than converting a boolean to an integer value. Then there is no need for a branch checking `offsetInRange`. > > Might be better to hold off until the JEP is integrated and then update, since this will conflict (`byte[]` and `ByteBuffer` load methods are removed and `MemorySegment` load methods are added). You could prepare for that now by branching off `vectorIntrinsics`. Thanks for your comments @PaulSandoz ! > IIUC when the hardware does not support predicated loads then any false `offsetIntRange` value causes the load intrinsic to fail resulting in the fallback, so it would not be materially any different to the current behavior, just more uniformly implemented. Yes, it's true that this patch doesn't have any different to the hardware that does not support the predicated loads. It only benefits the predicated feature supported systems like ARM SVE and X86 AVX-512. > Why can't the intrinsic support the passing a boolean directly? Is it something to do with constants? If that is not possible I recommend creating named constant values and pass those all the way through rather than converting a boolean to an integer value. Then there is no need for a branch checking offsetInRange. Yeah, I agree that it's not good by adding a branch checking for `offsetInRange`. But actually I met the constant issue that passing the values all the way cannot guarantee the argument a constant in compiler at the compile time. Do you have any better idea to fixing this? > Might be better to hold off until the JEP is integrated and then update, since this will conflict (byte[] and ByteBuffer load methods are removed and MemorySegment load methods are added). You could prepare for that now by branching off vectorIntrinsics. Agree. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From psandoz at openjdk.java.net Thu May 5 01:25:29 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 5 May 2022 01:25:29 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 01:13:23 GMT, Xiaohong Gong wrote: > Yeah, I agree that it's not good by adding a branch checking for `offsetInRange`. But actually I met the constant issue that passing the values all the way cannot guarantee the argument a constant in compiler at the compile time. Do you have any better idea to fixing this? That's odd, `boolean` constants are passed that are then converted to `int` constants. Did you try passing integer constants all the way through? ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From xgong at openjdk.java.net Thu May 5 01:46:19 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 5 May 2022 01:46:19 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 01:21:40 GMT, Paul Sandoz wrote: > > Yeah, I agree that it's not good by adding a branch checking for `offsetInRange`. But actually I met the constant issue that passing the values all the way cannot guarantee the argument a constant in compiler at the compile time. Do you have any better idea to fixing this? > > That's odd, `boolean` constants are passed that are then converted to `int` constants. Did you try passing integer constants all the way through? I will try again. I remember the main cause is the calling of `fromArray0` from `fromArray`, it is not annotated with `ForceInline`. The arguments might not be compiled to a constant for cases that the offset is not in the array range like tail loop. ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From xgong at openjdk.java.net Thu May 5 01:55:19 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 5 May 2022 01:55:19 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 01:42:48 GMT, Xiaohong Gong wrote: > > > Yeah, I agree that it's not good by adding a branch checking for `offsetInRange`. But actually I met the constant issue that passing the values all the way cannot guarantee the argument a constant in compiler at the compile time. Do you have any better idea to fixing this? > > > > > > That's odd, `boolean` constants are passed that are then converted to `int` constants. Did you try passing integer constants all the way through? > > I will try again. I remember the main cause is the calling of `fromArray0` from `fromArray`, it is not annotated with `ForceInline`. The arguments might not be compiled to a constant for cases that the offset is not in the array range like tail loop. I tried to pass the integer constant all the way, and unfortunate that the `offsetInRange` is not compiled to a constant. The following assertion in the `vectorIntrinsics.cpp` will fail: --- a/src/hotspot/share/opto/vectorIntrinsics.cpp +++ b/src/hotspot/share/opto/vectorIntrinsics.cpp @@ -1236,6 +1236,7 @@ bool LibraryCallKit::inline_vector_mem_masked_operation(bool is_store) { } else { // Masked vector load with IOOBE always uses the predicated load. const TypeInt* offset_in_range = gvn().type(argument(8))->isa_int(); + assert(offset_in_range->is_con(), "not a constant"); if (!offset_in_range->is_con()) { if (C->print_intrinsics()) { tty->print_cr(" ** missing constant: offsetInRange=%s", ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From xgong at openjdk.java.net Thu May 5 02:08:14 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 5 May 2022 02:08:14 GMT Subject: RFR: 8284050: [vectorapi] Optimize masked store for non-predicated architectures Message-ID: Currently the vectorization of masked vector store is implemented by the masked store instruction only on architectures that support the predicate feature. The compiler will fall back to the java scalar code for non-predicate supported architectures like ARM NEON. However, for these systems, the masked store can be vectorized with the non-masked vector `"load + blend + store"`. For example, storing a vector` "v"` controlled by a mask` "m"` into a memory with address` "addr" (i.e. "store(addr, v, m)")` can be implemented with: 1) mem_v = load(addr) ; non-masked load from the same memory 2) v = blend(mem_v, v, m) ; blend with the src vector with the mask 3) store(addr, v) ; non-masked store into the memory Since the first full loading needs the array offset must be inside of the valid array bounds, we make the compiler do the vectorization only when the offset is in range of the array boundary. And the compiler will still fall back to the java scalar code if not all offsets are valid. Besides, the original offset check for masked lanes are only applied when the offset is not always inside of the array range. This also improves the performance for masked store when the offset is always valid. The whole process is similar to the masked load API. Here is the performance data for the masked vector store benchmarks on a X86 non avx-512 system, which improves about `20x ~ 50x`: Benchmark before after Units StoreMaskedBenchmark.byteStoreArrayMask 221.733 11094.126 ops/ms StoreMaskedBenchmark.doubleStoreArrayMask 41.086 1034.408 ops/ms StoreMaskedBenchmark.floatStoreArrayMask 73.820 1985.015 ops/ms StoreMaskedBenchmark.intStoreArrayMask 75.028 2027.557 ops/ms StoreMaskedBenchmark.longStoreArrayMask 40.929 1032.928 ops/ms StoreMaskedBenchmark.shortStoreArrayMask 135.794 5307.567 ops/ms Similar performance gain can also be observed on ARM NEON system. And here is the performance data on X86 avx-512 system, which improves about `1.88x - 2.81x`: Benchmark before after Units StoreMaskedBenchmark.byteStoreArrayMask 11185.956 21012.824 ops/ms StoreMaskedBenchmark.doubleStoreArrayMask 1480.644 3911.720 ops/ms StoreMaskedBenchmark.floatStoreArrayMask 2738.352 7708.365 ops/ms StoreMaskedBenchmark.intStoreArrayMask 4191.904 9300.428 ops/ms StoreMaskedBenchmark.longStoreArrayMask 2025.031 4604.504 ops/ms StoreMaskedBenchmark.shortStoreArrayMask 8339.389 17817.128 ops/ms Similar performance gain can also be observed on ARM SVE system. ------------- Depends on: https://git.openjdk.java.net/jdk/pull/8035 Commit messages: - 8284050: [vectorapi] Optimize masked store for non-predicated architectures - 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature Changes: https://git.openjdk.java.net/jdk/pull/8544/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8544&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284050 Stats: 1708 lines in 44 files changed: 710 ins; 188 del; 810 mod Patch: https://git.openjdk.java.net/jdk/pull/8544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8544/head:pull/8544 PR: https://git.openjdk.java.net/jdk/pull/8544 From xgong at openjdk.java.net Thu May 5 02:09:39 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 5 May 2022 02:09:39 GMT Subject: RFR: 8284050: [vectorapi] Optimize masked store for non-predicated architectures [v2] In-Reply-To: References: Message-ID: > Currently the vectorization of masked vector store is implemented by the masked store instruction only on architectures that support the predicate feature. The compiler will fall back to the java scalar code for non-predicate supported architectures like ARM NEON. However, for these systems, the masked store can be vectorized with the non-masked vector `"load + blend + store"`. For example, storing a vector` "v"` controlled by a mask` "m"` into a memory with address` "addr" (i.e. "store(addr, v, m)")` can be implemented with: > > > 1) mem_v = load(addr) ; non-masked load from the same memory > 2) v = blend(mem_v, v, m) ; blend with the src vector with the mask > 3) store(addr, v) ; non-masked store into the memory > > > Since the first full loading needs the array offset must be inside of the valid array bounds, we make the compiler do the vectorization only when the offset is in range of the array boundary. And the compiler will still fall back to the java scalar code if not all offsets are valid. Besides, the original offset check for masked lanes are only applied when the offset is not always inside of the array range. This also improves the performance for masked store when the offset is always valid. The whole process is similar to the masked load API. > > Here is the performance data for the masked vector store benchmarks on a X86 non avx-512 system, which improves about `20x ~ 50x`: > > Benchmark before after Units > StoreMaskedBenchmark.byteStoreArrayMask 221.733 11094.126 ops/ms > StoreMaskedBenchmark.doubleStoreArrayMask 41.086 1034.408 ops/ms > StoreMaskedBenchmark.floatStoreArrayMask 73.820 1985.015 ops/ms > StoreMaskedBenchmark.intStoreArrayMask 75.028 2027.557 ops/ms > StoreMaskedBenchmark.longStoreArrayMask 40.929 1032.928 ops/ms > StoreMaskedBenchmark.shortStoreArrayMask 135.794 5307.567 ops/ms > > Similar performance gain can also be observed on ARM NEON system. > > And here is the performance data on X86 avx-512 system, which improves about `1.88x - 2.81x`: > > Benchmark before after Units > StoreMaskedBenchmark.byteStoreArrayMask 11185.956 21012.824 ops/ms > StoreMaskedBenchmark.doubleStoreArrayMask 1480.644 3911.720 ops/ms > StoreMaskedBenchmark.floatStoreArrayMask 2738.352 7708.365 ops/ms > StoreMaskedBenchmark.intStoreArrayMask 4191.904 9300.428 ops/ms > StoreMaskedBenchmark.longStoreArrayMask 2025.031 4604.504 ops/ms > StoreMaskedBenchmark.shortStoreArrayMask 8339.389 17817.128 ops/ms > > Similar performance gain can also be observed on ARM SVE system. Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: 8284050: [vectorapi] Optimize masked store for non-predicated architectures ------------- Changes: https://git.openjdk.java.net/jdk/pull/8544/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8544&range=01 Stats: 915 lines in 43 files changed: 405 ins; 80 del; 430 mod Patch: https://git.openjdk.java.net/jdk/pull/8544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8544/head:pull/8544 PR: https://git.openjdk.java.net/jdk/pull/8544 From xgong at openjdk.java.net Thu May 5 02:17:20 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 5 May 2022 02:17:20 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v2] In-Reply-To: References: Message-ID: On Thu, 28 Apr 2022 00:13:49 GMT, Sandhya Viswanathan wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename the "usePred" to "offsetInRange" > > src/hotspot/share/opto/vectorIntrinsics.cpp line 1232: > >> 1230: // out when current case uses the predicate feature. >> 1231: if (!supports_predicate) { >> 1232: bool use_predicate = false; > > If we rename this to needs_predicate it will be easier to understand. Thanks for the comment! This local variable will be removed after adding the similar intrinsify for store masked. Please help to see the PR https://github.com/openjdk/jdk/pull/8544. Thanks so much! ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From xgong at openjdk.java.net Thu May 5 02:17:20 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 5 May 2022 02:17:20 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v2] In-Reply-To: <8Yu4J-PCYFJtBXrfgWoCbaR-7QZTXH4IzmXOf_lk164=.66071c45-1f1a-4931-a414-778f353c7e83@github.com> References: <35S4J_r9jBw_-SAow2oMYaSsTvubhSmZFVPb_VM6KEg=.7feff8fa-6e20-453e-aed6-e53c7d9beaad@github.com> <8Yu4J-PCYFJtBXrfgWoCbaR-7QZTXH4IzmXOf_lk164=.66071c45-1f1a-4931-a414-778f353c7e83@github.com> Message-ID: On Thu, 31 Mar 2022 02:15:26 GMT, Quan Anh Mai wrote: >> I'm afraid not. "Load + Blend" makes the elements of unmasked lanes to be `0`. Then a full store may change the values in the unmasked memory to be 0, which is different with the mask store API definition. > > The blend should be with the intended-to-store vector, so that masked lanes contain the need-to-store elements and unmasked lanes contain the loaded elements, which would be stored back, which results in unchanged values. Hi @merykitty @jatin-bhateja , could you please help to take a review at the similar store masked PR https://github.com/openjdk/jdk/pull/8544 ? Any feedback is welcome! Thanks so much! ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From sspitsyn at openjdk.java.net Thu May 5 02:25:12 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 5 May 2022 02:25:12 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v11] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 12:12:48 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview). >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05 > - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89 > - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a > - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4 > - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec > - Merge with jdk-19+20 > - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 > - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1 > - Merge with jdk-19+19 > - ... and 7 more: https://git.openjdk.java.net/jdk/compare/4b2c8220...f06aff75 I've completed review of new vthread-related tests in the folder serviceability/jvmti. It includes sub-folders: serviceability/jvmti/events serviceability/jvmti/negative serviceability/jvmti/thread Thank you, Leonid, for resolving my comments! ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From jrose at openjdk.java.net Thu May 5 02:45:17 2022 From: jrose at openjdk.java.net (John R Rose) Date: Thu, 5 May 2022 02:45:17 GMT Subject: RFR: 8284050: [vectorapi] Optimize masked store for non-predicated architectures [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 02:09:39 GMT, Xiaohong Gong wrote: >> Currently the vectorization of masked vector store is implemented by the masked store instruction only on architectures that support the predicate feature. The compiler will fall back to the java scalar code for non-predicate supported architectures like ARM NEON. However, for these systems, the masked store can be vectorized with the non-masked vector `"load + blend + store"`. For example, storing a vector` "v"` controlled by a mask` "m"` into a memory with address` "addr" (i.e. "store(addr, v, m)")` can be implemented with: >> >> >> 1) mem_v = load(addr) ; non-masked load from the same memory >> 2) v = blend(mem_v, v, m) ; blend with the src vector with the mask >> 3) store(addr, v) ; non-masked store into the memory >> >> >> Since the first full loading needs the array offset must be inside of the valid array bounds, we make the compiler do the vectorization only when the offset is in range of the array boundary. And the compiler will still fall back to the java scalar code if not all offsets are valid. Besides, the original offset check for masked lanes are only applied when the offset is not always inside of the array range. This also improves the performance for masked store when the offset is always valid. The whole process is similar to the masked load API. >> >> Here is the performance data for the masked vector store benchmarks on a X86 non avx-512 system, which improves about `20x ~ 50x`: >> >> Benchmark before after Units >> StoreMaskedBenchmark.byteStoreArrayMask 221.733 11094.126 ops/ms >> StoreMaskedBenchmark.doubleStoreArrayMask 41.086 1034.408 ops/ms >> StoreMaskedBenchmark.floatStoreArrayMask 73.820 1985.015 ops/ms >> StoreMaskedBenchmark.intStoreArrayMask 75.028 2027.557 ops/ms >> StoreMaskedBenchmark.longStoreArrayMask 40.929 1032.928 ops/ms >> StoreMaskedBenchmark.shortStoreArrayMask 135.794 5307.567 ops/ms >> >> Similar performance gain can also be observed on ARM NEON system. >> >> And here is the performance data on X86 avx-512 system, which improves about `1.88x - 2.81x`: >> >> Benchmark before after Units >> StoreMaskedBenchmark.byteStoreArrayMask 11185.956 21012.824 ops/ms >> StoreMaskedBenchmark.doubleStoreArrayMask 1480.644 3911.720 ops/ms >> StoreMaskedBenchmark.floatStoreArrayMask 2738.352 7708.365 ops/ms >> StoreMaskedBenchmark.intStoreArrayMask 4191.904 9300.428 ops/ms >> StoreMaskedBenchmark.longStoreArrayMask 2025.031 4604.504 ops/ms >> StoreMaskedBenchmark.shortStoreArrayMask 8339.389 17817.128 ops/ms >> >> Similar performance gain can also be observed on ARM SVE system. > > Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8284050: [vectorapi] Optimize masked store for non-predicated architectures The JIT (in all other circumstances AFAIK) never produces "phantom stores", stores into Java variables which are not specified as the target of a JVM store instruction (putfield, dastore, etc.). The fact that a previously-read value is used by the phantom store does not make it any better. Yes, the memory states may be correct after the blend and store is done, but the effect on the Java Memory Model is to issue the extra phantom stores of the unselected array elements. Under certain circumstances, this will create race conditions after the optimization where there were no race conditions before the optimization. Other threads could (under Java Memory Model rules) witness the effects of the phantom stores. If the Java program is properly synchronized, the introduction of an illegitimate race condition can cause another thread, now in an illegal race, to see an old value in a variable (the recopied unselected array element) which the JMM says is impossible. Yes, this only shows up in multi-threaded programs, and ones where two threads step on one array, but Java is a multi-threaded language, and it must conform to its own specification as such. This blend technique would be very reasonable if there is no race condition. (Except at the very beginning or end of arrays.) And the JMM leaves room for many optimizations. And yet I think this is a step too far. I'd like to be wrong about this, but I don't think I am. So, I think you need to use a different technique, other than blend-and-unpredicated-store, for masked stores on non-predicated architectures. For example, you could simulate a masked store instruction on an architecture that supports scatter (scattering values of the array type). Do this by setting up two vectors of machine pointers. One vector points to each potentially-affected element of the array (some kind of index computation plus a scaled iota vector). The other vector is set up similarly, but points into a fixed-sized, thread-local buffer, what I would call the "bit bucket". Blend the addresses, and then scatter, so that selected array lanes are updated, and unselected values are sent to the "bit bucket". This is complex enough (and platform-dependent enough) that you probably need to write a hand-coded assembly language subroutine, to call from the JIT code. Sort of like the arraycopy stubs. It's even more work than the proposed patch here, but it's the right thing, I'm afraid. src/hotspot/share/opto/vectorIntrinsics.cpp line 1363: > 1361: // Use the vector blend to implement the masked store. The biased elements are the original > 1362: // values in the memory. > 1363: Node* mem_val = gvn().transform(LoadVectorNode::make(0, control(), memory(addr), addr, addr_type, mem_num_elem, mem_elem_bt)); I'm sorry to say it, but I am pretty sure this is an invalid optimization. See top-level comment for more details. ------------- Changes requested by jrose (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8544 From hboehm at google.com Thu May 5 03:15:10 2022 From: hboehm at google.com (Hans Boehm) Date: Wed, 4 May 2022 20:15:10 -0700 Subject: RFR: 8284050: [vectorapi] Optimize masked store for non-predicated architectures In-Reply-To: References: Message-ID: Naive question: What happens if one of the vector elements that should not have been updated is concurrently being written by another thread? Aren't you generating writes to vector elements that should not have been written? Hans On Wed, May 4, 2022 at 7:08 PM Xiaohong Gong wrote: > Currently the vectorization of masked vector store is implemented by the > masked store instruction only on architectures that support the predicate > feature. The compiler will fall back to the java scalar code for > non-predicate supported architectures like ARM NEON. However, for these > systems, the masked store can be vectorized with the non-masked vector > `"load + blend + store"`. For example, storing a vector` "v"` controlled by > a mask` "m"` into a memory with address` "addr" (i.e. "store(addr, v, m)")` > can be implemented with: > > > 1) mem_v = load(addr) ; non-masked load from the same memory > 2) v = blend(mem_v, v, m) ; blend with the src vector with the mask > 3) store(addr, v) ; non-masked store into the memory > > > Since the first full loading needs the array offset must be inside of the > valid array bounds, we make the compiler do the vectorization only when the > offset is in range of the array boundary. And the compiler will still fall > back to the java scalar code if not all offsets are valid. Besides, the > original offset check for masked lanes are only applied when the offset is > not always inside of the array range. This also improves the performance > for masked store when the offset is always valid. The whole process is > similar to the masked load API. > > Here is the performance data for the masked vector store benchmarks on a > X86 non avx-512 system, which improves about `20x ~ 50x`: > > Benchmark before after Units > StoreMaskedBenchmark.byteStoreArrayMask 221.733 11094.126 ops/ms > StoreMaskedBenchmark.doubleStoreArrayMask 41.086 1034.408 ops/ms > StoreMaskedBenchmark.floatStoreArrayMask 73.820 1985.015 ops/ms > StoreMaskedBenchmark.intStoreArrayMask 75.028 2027.557 ops/ms > StoreMaskedBenchmark.longStoreArrayMask 40.929 1032.928 ops/ms > StoreMaskedBenchmark.shortStoreArrayMask 135.794 5307.567 ops/ms > > Similar performance gain can also be observed on ARM NEON system. > > And here is the performance data on X86 avx-512 system, which improves > about `1.88x - 2.81x`: > > Benchmark before after Units > StoreMaskedBenchmark.byteStoreArrayMask 11185.956 21012.824 ops/ms > StoreMaskedBenchmark.doubleStoreArrayMask 1480.644 3911.720 ops/ms > StoreMaskedBenchmark.floatStoreArrayMask 2738.352 7708.365 ops/ms > StoreMaskedBenchmark.intStoreArrayMask 4191.904 9300.428 ops/ms > StoreMaskedBenchmark.longStoreArrayMask 2025.031 4604.504 ops/ms > StoreMaskedBenchmark.shortStoreArrayMask 8339.389 17817.128 ops/ms > > Similar performance gain can also be observed on ARM SVE system. > > ------------- > > Depends on: https://git.openjdk.java.net/jdk/pull/8035 > > Commit messages: > - 8284050: [vectorapi] Optimize masked store for non-predicated > architectures > - 8283667: [vectorapi] Vectorization for masked load with IOOBE with > predicate feature > > Changes: https://git.openjdk.java.net/jdk/pull/8544/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8544&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8284050 > Stats: 1708 lines in 44 files changed: 710 ins; 188 del; 810 mod > Patch: https://git.openjdk.java.net/jdk/pull/8544.diff > Fetch: git fetch https://git.openjdk.java.net/jdk > pull/8544/head:pull/8544 > > PR: https://git.openjdk.java.net/jdk/pull/8544 > From xgong at openjdk.java.net Thu May 5 03:21:25 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 5 May 2022 03:21:25 GMT Subject: RFR: 8284050: [vectorapi] Optimize masked store for non-predicated architectures [v2] In-Reply-To: References: Message-ID: <2nHlMA_m35Al9nbcBILE63XcB63XuSWI_RbcUC96-As=.4fe30c48-52ab-4995-b0a1-f327009aa8a8@github.com> On Thu, 5 May 2022 02:27:03 GMT, John R Rose wrote: >> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> 8284050: [vectorapi] Optimize masked store for non-predicated architectures > > src/hotspot/share/opto/vectorIntrinsics.cpp line 1363: > >> 1361: // Use the vector blend to implement the masked store. The biased elements are the original >> 1362: // values in the memory. >> 1363: Node* mem_val = gvn().transform(LoadVectorNode::make(0, control(), memory(addr), addr, addr_type, mem_num_elem, mem_elem_bt)); > > I'm sorry to say it, but I am pretty sure this is an invalid optimization. > See top-level comment for more details. Thanks for your comments! Yeah, this actually influences something due to the Java Memory Model rules which I missed to consider more. I will try the scatter ways instead. Thanks so much! ------------- PR: https://git.openjdk.java.net/jdk/pull/8544 From xgong at openjdk.java.net Thu May 5 03:29:16 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 5 May 2022 03:29:16 GMT Subject: RFR: 8284050: [vectorapi] Optimize masked store for non-predicated architectures [v2] In-Reply-To: References: Message-ID: <4k-ZTE8Uax5vrH9GMAc2MJClnaIc4zB9vteafm24S44=.e1f50cc8-3020-4091-831f-e5fa2b623f7a@github.com> On Thu, 5 May 2022 02:09:39 GMT, Xiaohong Gong wrote: >> Currently the vectorization of masked vector store is implemented by the masked store instruction only on architectures that support the predicate feature. The compiler will fall back to the java scalar code for non-predicate supported architectures like ARM NEON. However, for these systems, the masked store can be vectorized with the non-masked vector `"load + blend + store"`. For example, storing a vector` "v"` controlled by a mask` "m"` into a memory with address` "addr" (i.e. "store(addr, v, m)")` can be implemented with: >> >> >> 1) mem_v = load(addr) ; non-masked load from the same memory >> 2) v = blend(mem_v, v, m) ; blend with the src vector with the mask >> 3) store(addr, v) ; non-masked store into the memory >> >> >> Since the first full loading needs the array offset must be inside of the valid array bounds, we make the compiler do the vectorization only when the offset is in range of the array boundary. And the compiler will still fall back to the java scalar code if not all offsets are valid. Besides, the original offset check for masked lanes are only applied when the offset is not always inside of the array range. This also improves the performance for masked store when the offset is always valid. The whole process is similar to the masked load API. >> >> Here is the performance data for the masked vector store benchmarks on a X86 non avx-512 system, which improves about `20x ~ 50x`: >> >> Benchmark before after Units >> StoreMaskedBenchmark.byteStoreArrayMask 221.733 11094.126 ops/ms >> StoreMaskedBenchmark.doubleStoreArrayMask 41.086 1034.408 ops/ms >> StoreMaskedBenchmark.floatStoreArrayMask 73.820 1985.015 ops/ms >> StoreMaskedBenchmark.intStoreArrayMask 75.028 2027.557 ops/ms >> StoreMaskedBenchmark.longStoreArrayMask 40.929 1032.928 ops/ms >> StoreMaskedBenchmark.shortStoreArrayMask 135.794 5307.567 ops/ms >> >> Similar performance gain can also be observed on ARM NEON system. >> >> And here is the performance data on X86 avx-512 system, which improves about `1.88x - 2.81x`: >> >> Benchmark before after Units >> StoreMaskedBenchmark.byteStoreArrayMask 11185.956 21012.824 ops/ms >> StoreMaskedBenchmark.doubleStoreArrayMask 1480.644 3911.720 ops/ms >> StoreMaskedBenchmark.floatStoreArrayMask 2738.352 7708.365 ops/ms >> StoreMaskedBenchmark.intStoreArrayMask 4191.904 9300.428 ops/ms >> StoreMaskedBenchmark.longStoreArrayMask 2025.031 4604.504 ops/ms >> StoreMaskedBenchmark.shortStoreArrayMask 8339.389 17817.128 ops/ms >> >> Similar performance gain can also be observed on ARM SVE system. > > Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8284050: [vectorapi] Optimize masked store for non-predicated architectures > _Mailing list message from [Hans Boehm](mailto:hboehm at google.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.java.net):_ > > Naive question: What happens if one of the vector elements that should not have been updated is concurrently being written by another thread? Aren't you generating writes to vector elements that should not have been written? > > Hans > > On Wed, May 4, 2022 at 7:08 PM Xiaohong Gong wrote: Yeah, this is the similar concern with what @rose00 mentioned above. The current solution cannot work well for multi-thread progresses. I will consider other better solutions. Thanks for the comments! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 3483: > 3481: ByteSpecies vsp = vspecies(); > 3482: if (offset >= 0 && offset <= (a.length - vsp.length())) { > 3483: intoBooleanArray0(a, offset, m, /* offsetInRange */ true); The offset check could save the `checkMaskFromIndexSize` for cases that offset are in the valid array bounds, which also improves the performance. @rose00 , do you think this part of change is ok at least? Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8544 From jbhateja at openjdk.java.net Thu May 5 04:38:24 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 5 May 2022 04:38:24 GMT Subject: RFR: 8284050: [vectorapi] Optimize masked store for non-predicated architectures [v2] In-Reply-To: <2nHlMA_m35Al9nbcBILE63XcB63XuSWI_RbcUC96-As=.4fe30c48-52ab-4995-b0a1-f327009aa8a8@github.com> References: <2nHlMA_m35Al9nbcBILE63XcB63XuSWI_RbcUC96-As=.4fe30c48-52ab-4995-b0a1-f327009aa8a8@github.com> Message-ID: <039lZ4RUKsmDUJAZEitlkbrvCE7p9w37KIc-F7Qr7jA=.f3e24088-bba3-448a-8720-649928de23f2@github.com> On Thu, 5 May 2022 03:17:35 GMT, Xiaohong Gong wrote: >> src/hotspot/share/opto/vectorIntrinsics.cpp line 1363: >> >>> 1361: // Use the vector blend to implement the masked store. The biased elements are the original >>> 1362: // values in the memory. >>> 1363: Node* mem_val = gvn().transform(LoadVectorNode::make(0, control(), memory(addr), addr, addr_type, mem_num_elem, mem_elem_bt)); >> >> I'm sorry to say it, but I am pretty sure this is an invalid optimization. >> See top-level comment for more details. > > Thanks for your comments! Yeah, this actually influences something due to the Java Memory Model rules which I missed to consider more. I will try the scatter ways instead. Thanks so much! Yes, phantom store can write back stale unintended value and may create problem in multithreded applications since blending is done with an older loaded value. ------------- PR: https://git.openjdk.java.net/jdk/pull/8544 From thartmann at openjdk.java.net Thu May 5 05:15:20 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 5 May 2022 05:15:20 GMT Subject: RFR: JDK-8283807: Handle CompileThreshold the same as other thresholds when scaled with -XX:CompileThresholdScaling [v3] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 09:26:04 GMT, Tobias Holenstein wrote: >> `CompileThresholdScaling` scales several compiler thresholds. If the scaled threshold value is outside of the allowed range, a warning is printed and the default value is kept. But when scaling `CompileThreshold` we do not check the scaled value because it is not a ranged flag. Later when verifying flags with a constraint function `OnStackReplacePercentageConstraintFunc` which calls `CompileThresholdConstraintFunc` fails because `CompileThreshold` is outside of the allowed range. This stops the VM from being created. >> >> The fix is to call `CompileThresholdConstraintFunc` when scaling `CompileThreshold` with `CompileThresholdScaling`. If `CompileThresholdConstraintFunc` fails we print a warning and keep the default value of `CompileThreshold`. This behaviour is then consistent with the other 15 other thresholds where the VM just prints a warning if the scaled value is too large and then keeps the current value. >> >> We also have to exclude `CompileThresholdScaling` from max. range testing in `TestOptionsWithRanges.java`, because >> it is expected to print "outside the allowed range" warnings for the scaled flag and the "outside the allowed range" warning does not refer to `CompileThresholdScaling` itself. >> >> One question that remains it why `CompileThresholdScaling` takes the default value when a scaled threshold is too large instead of the max. value? Because now we can have the case where some compiler thresholds are scaled to almost their max. value and others that are already larger than the maximum are default again (which can be the minimum value in some cases). I suggest to address this issue in a separate RFE. > > Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision: > > adjusted comment Looks good. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8501 From iklam at openjdk.java.net Thu May 5 05:29:19 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 5 May 2022 05:29:19 GMT Subject: RFR: JDK-8283807: Handle CompileThreshold the same as other thresholds when scaled with -XX:CompileThresholdScaling [v3] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 09:26:04 GMT, Tobias Holenstein wrote: >> `CompileThresholdScaling` scales several compiler thresholds. If the scaled threshold value is outside of the allowed range, a warning is printed and the default value is kept. But when scaling `CompileThreshold` we do not check the scaled value because it is not a ranged flag. Later when verifying flags with a constraint function `OnStackReplacePercentageConstraintFunc` which calls `CompileThresholdConstraintFunc` fails because `CompileThreshold` is outside of the allowed range. This stops the VM from being created. >> >> The fix is to call `CompileThresholdConstraintFunc` when scaling `CompileThreshold` with `CompileThresholdScaling`. If `CompileThresholdConstraintFunc` fails we print a warning and keep the default value of `CompileThreshold`. This behaviour is then consistent with the other 15 other thresholds where the VM just prints a warning if the scaled value is too large and then keeps the current value. >> >> We also have to exclude `CompileThresholdScaling` from max. range testing in `TestOptionsWithRanges.java`, because >> it is expected to print "outside the allowed range" warnings for the scaled flag and the "outside the allowed range" warning does not refer to `CompileThresholdScaling` itself. >> >> One question that remains it why `CompileThresholdScaling` takes the default value when a scaled threshold is too large instead of the max. value? Because now we can have the case where some compiler thresholds are scaled to almost their max. value and others that are already larger than the maximum are default again (which can be the minimum value in some cases). I suggest to address this issue in a separate RFE. > > Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision: > > adjusted comment LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8501 From jbhateja at openjdk.java.net Thu May 5 05:47:47 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 5 May 2022 05:47:47 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v2] In-Reply-To: References: Message-ID: > Hi All, > > Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) > > Following is the brief summary of changes:- > > 1) Extends the scope of existing lanewise API for following new vector operations. > - VectorOperations.BIT_COUNT: counts the number of one-bits > - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits > - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits > - VectorOperations.REVERSE: reversing the order of bits > - VectorOperations.REVERSE_BYTES: reversing the order of bytes > - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. > > 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. > - Vector.compress > - Vector.expand > - VectorMask.compress > > 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. > - Vector.fromMemorySegment > - Vector.intoMemorySegment > > 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. > > > Patch has been regressed over AARCH64 and X86 targets different AVX levels. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - 8284960: Correcting a typo. - 8284960: Integrating changes from panama-vector (Add @since 19 tags). - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - 8284960: AARCH64 backend changes. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - 8284960: Integration of JEP 426: Vector API (Fourth Incubator) ------------- Changes: https://git.openjdk.java.net/jdk/pull/8425/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=01 Stats: 37900 lines in 214 files changed: 16527 ins; 16923 del; 4450 mod Patch: https://git.openjdk.java.net/jdk/pull/8425.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425 PR: https://git.openjdk.java.net/jdk/pull/8425 From john.r.rose at oracle.com Thu May 5 06:16:07 2022 From: john.r.rose at oracle.com (John Rose) Date: Thu, 5 May 2022 06:16:07 +0000 Subject: RFR: 8284050: [vectorapi] Optimize masked store for non-predicated architectures [v2] In-Reply-To: <4k-ZTE8Uax5vrH9GMAc2MJClnaIc4zB9vteafm24S44=.e1f50cc8-3020-4091-831f-e5fa2b623f7a@github.com> References: <4k-ZTE8Uax5vrH9GMAc2MJClnaIc4zB9vteafm24S44=.e1f50cc8-3020-4091-831f-e5fa2b623f7a@github.com> Message-ID: > On May 4, 2022, at 8:29 PM, Xiaohong Gong wrote: > > The offset check could save the `checkMaskFromIndexSize` for cases that offset are in the valid array bounds, which also improves the performance. @rose00 , do you think this part of change is ok at least? That part is ok, yes. I wish we could get the same effect with loop optimizations but I don?t know an easy way. The explicit check in the source code gives the JIT a crutch but I hope we can figure out a way in the future to integrate mask logic into range check elimination logic, making the crutches unnecessary. For now it?s fine. From duke at openjdk.java.net Thu May 5 06:16:18 2022 From: duke at openjdk.java.net (Tobias Holenstein) Date: Thu, 5 May 2022 06:16:18 GMT Subject: RFR: JDK-8283807: Handle CompileThreshold the same as other thresholds when scaled with -XX:CompileThresholdScaling [v3] In-Reply-To: References: Message-ID: On Mon, 2 May 2022 15:59:52 GMT, Vladimir Kozlov wrote: >> Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision: >> >> adjusted comment > > Looks good. @vnkozlov , @TobiHartmann and @iklam thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/8501 From thartmann at openjdk.java.net Thu May 5 08:12:24 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 5 May 2022 08:12:24 GMT Subject: RFR: 8283306: re-resolving indirect call to non-entrant nmethod can crash [v4] In-Reply-To: References: Message-ID: <3fSyDW84x4hyNM4NUNMhyUQy17cZ04wEVWEzlAzp1hA=.2eb1aa07-1aad-4630-af47-db7c5a3ab6b9@github.com> On Wed, 4 May 2022 22:57:13 GMT, Dean Long wrote: >> This change fixes a crash that can happen in SharedRuntime::reresolve_call_site with Graal/JVMCI. >> See https://bugs.openjdk.java.net/browse/JDK-8283306 for details. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > cleanup Looks good to me. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8528 From xgong at openjdk.java.net Thu May 5 08:41:11 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 5 May 2022 08:41:11 GMT Subject: RFR: 8284050: [vectorapi] Optimize masked store for non-predicated architectures [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 02:09:39 GMT, Xiaohong Gong wrote: >> Currently the vectorization of masked vector store is implemented by the masked store instruction only on architectures that support the predicate feature. The compiler will fall back to the java scalar code for non-predicate supported architectures like ARM NEON. However, for these systems, the masked store can be vectorized with the non-masked vector `"load + blend + store"`. For example, storing a vector` "v"` controlled by a mask` "m"` into a memory with address` "addr" (i.e. "store(addr, v, m)")` can be implemented with: >> >> >> 1) mem_v = load(addr) ; non-masked load from the same memory >> 2) v = blend(mem_v, v, m) ; blend with the src vector with the mask >> 3) store(addr, v) ; non-masked store into the memory >> >> >> Since the first full loading needs the array offset must be inside of the valid array bounds, we make the compiler do the vectorization only when the offset is in range of the array boundary. And the compiler will still fall back to the java scalar code if not all offsets are valid. Besides, the original offset check for masked lanes are only applied when the offset is not always inside of the array range. This also improves the performance for masked store when the offset is always valid. The whole process is similar to the masked load API. >> >> Here is the performance data for the masked vector store benchmarks on a X86 non avx-512 system, which improves about `20x ~ 50x`: >> >> Benchmark before after Units >> StoreMaskedBenchmark.byteStoreArrayMask 221.733 11094.126 ops/ms >> StoreMaskedBenchmark.doubleStoreArrayMask 41.086 1034.408 ops/ms >> StoreMaskedBenchmark.floatStoreArrayMask 73.820 1985.015 ops/ms >> StoreMaskedBenchmark.intStoreArrayMask 75.028 2027.557 ops/ms >> StoreMaskedBenchmark.longStoreArrayMask 40.929 1032.928 ops/ms >> StoreMaskedBenchmark.shortStoreArrayMask 135.794 5307.567 ops/ms >> >> Similar performance gain can also be observed on ARM NEON system. >> >> And here is the performance data on X86 avx-512 system, which improves about `1.88x - 2.81x`: >> >> Benchmark before after Units >> StoreMaskedBenchmark.byteStoreArrayMask 11185.956 21012.824 ops/ms >> StoreMaskedBenchmark.doubleStoreArrayMask 1480.644 3911.720 ops/ms >> StoreMaskedBenchmark.floatStoreArrayMask 2738.352 7708.365 ops/ms >> StoreMaskedBenchmark.intStoreArrayMask 4191.904 9300.428 ops/ms >> StoreMaskedBenchmark.longStoreArrayMask 2025.031 4604.504 ops/ms >> StoreMaskedBenchmark.shortStoreArrayMask 8339.389 17817.128 ops/ms >> >> Similar performance gain can also be observed on ARM SVE system. > > Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: > > 8284050: [vectorapi] Optimize masked store for non-predicated architectures > _Mailing list message from [John Rose](mailto:john.r.rose at oracle.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.java.net):_ > > > On May 4, 2022, at 8:29 PM, Xiaohong Gong wrote: > > The offset check could save the `checkMaskFromIndexSize` for cases that offset are in the valid array bounds, which also improves the performance. @rose00 , do you think this part of change is ok at least? > > That part is ok, yes. I wish we could get the same effect with loop optimizations but I don?t know an easy way. The explicit check in the source code gives the JIT a crutch but I hope we can figure out a way in the future to integrate mask logic into range check elimination logic, making the crutches unnecessary. For now it?s fine. Thanks! So I will separate this part out and fix it in another PR first. For the store masked vectorization with scatter or other ideas, I'm not quite sure whether they can always benefit cross architectures and need more investigation. I prefer to close this PR now. Thanks for all your comments! ------------- PR: https://git.openjdk.java.net/jdk/pull/8544 From xgong at openjdk.java.net Thu May 5 08:41:12 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 5 May 2022 08:41:12 GMT Subject: Withdrawn: 8284050: [vectorapi] Optimize masked store for non-predicated architectures In-Reply-To: References: Message-ID: <_XofoM1n91tFSRAE0q4CCkysHFK4Wha8a4IYaoj2xsU=.3df8d210-cf52-4bf0-81ba-a4cf3491ad20@github.com> On Thu, 5 May 2022 02:00:04 GMT, Xiaohong Gong wrote: > Currently the vectorization of masked vector store is implemented by the masked store instruction only on architectures that support the predicate feature. The compiler will fall back to the java scalar code for non-predicate supported architectures like ARM NEON. However, for these systems, the masked store can be vectorized with the non-masked vector `"load + blend + store"`. For example, storing a vector` "v"` controlled by a mask` "m"` into a memory with address` "addr" (i.e. "store(addr, v, m)")` can be implemented with: > > > 1) mem_v = load(addr) ; non-masked load from the same memory > 2) v = blend(mem_v, v, m) ; blend with the src vector with the mask > 3) store(addr, v) ; non-masked store into the memory > > > Since the first full loading needs the array offset must be inside of the valid array bounds, we make the compiler do the vectorization only when the offset is in range of the array boundary. And the compiler will still fall back to the java scalar code if not all offsets are valid. Besides, the original offset check for masked lanes are only applied when the offset is not always inside of the array range. This also improves the performance for masked store when the offset is always valid. The whole process is similar to the masked load API. > > Here is the performance data for the masked vector store benchmarks on a X86 non avx-512 system, which improves about `20x ~ 50x`: > > Benchmark before after Units > StoreMaskedBenchmark.byteStoreArrayMask 221.733 11094.126 ops/ms > StoreMaskedBenchmark.doubleStoreArrayMask 41.086 1034.408 ops/ms > StoreMaskedBenchmark.floatStoreArrayMask 73.820 1985.015 ops/ms > StoreMaskedBenchmark.intStoreArrayMask 75.028 2027.557 ops/ms > StoreMaskedBenchmark.longStoreArrayMask 40.929 1032.928 ops/ms > StoreMaskedBenchmark.shortStoreArrayMask 135.794 5307.567 ops/ms > > Similar performance gain can also be observed on ARM NEON system. > > And here is the performance data on X86 avx-512 system, which improves about `1.88x - 2.81x`: > > Benchmark before after Units > StoreMaskedBenchmark.byteStoreArrayMask 11185.956 21012.824 ops/ms > StoreMaskedBenchmark.doubleStoreArrayMask 1480.644 3911.720 ops/ms > StoreMaskedBenchmark.floatStoreArrayMask 2738.352 7708.365 ops/ms > StoreMaskedBenchmark.intStoreArrayMask 4191.904 9300.428 ops/ms > StoreMaskedBenchmark.longStoreArrayMask 2025.031 4604.504 ops/ms > StoreMaskedBenchmark.shortStoreArrayMask 8339.389 17817.128 ops/ms > > Similar performance gain can also be observed on ARM SVE system. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8544 From xgong at openjdk.java.net Thu May 5 08:56:07 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 5 May 2022 08:56:07 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v3] In-Reply-To: References: Message-ID: > Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception. > > This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize): > > > @ForceInline > public static > ByteVector fromArray(VectorSpecies species, > byte[] a, int offset, > VectorMask m) { > ByteSpecies vsp = (ByteSpecies) species; > if (offset >= 0 && offset <= (a.length - species.length())) { > return vsp.dummyVector().fromArray0(a, offset, m); > } > > // FIXME: optimize > checkMaskFromIndexSize(offset, vsp, m, 1, a.length); > return vsp.vOp(m, i -> a[offset + i]); > } > > Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed. > > Also adds the same vectorization support for masked: > - fromByteArray/fromByteBuffer > - fromBooleanArray > - fromCharArray > > The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system: > > Benchmark before After Units > LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE 737.542 1387.069 ops/ms > LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366 330.776 ops/ms > LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE 233.832 6125.026 ops/ms > LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE 233.816 7075.923 ops/ms > LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE 119.771 330.587 ops/ms > LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE 431.961 939.301 ops/ms > > Similar performance gain can also be observed on 512-bit SVE system. Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: Rename "use_predicate" to "needs_predicate" ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8035/files - new: https://git.openjdk.java.net/jdk/pull/8035/files/9b2d2f19..9c69206e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8035&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8035&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8035.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8035/head:pull/8035 PR: https://git.openjdk.java.net/jdk/pull/8035 From xgong at openjdk.java.net Thu May 5 08:56:08 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 5 May 2022 08:56:08 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 02:14:08 GMT, Xiaohong Gong wrote: >> src/hotspot/share/opto/vectorIntrinsics.cpp line 1232: >> >>> 1230: // out when current case uses the predicate feature. >>> 1231: if (!supports_predicate) { >>> 1232: bool use_predicate = false; >> >> If we rename this to needs_predicate it will be easier to understand. > > Thanks for the comment! This local variable will be removed after adding the similar intrinsify for store masked. Please help to see the PR https://github.com/openjdk/jdk/pull/8544. Thanks so much! Renamed to "needs_predicate". Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From alanb at openjdk.java.net Thu May 5 09:35:42 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 5 May 2022 09:35:42 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12] In-Reply-To: References: Message-ID: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com> > This is the implementation of JEP 425: Virtual Threads (Preview). > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5 - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05 - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89 - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4 - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec - Merge with jdk-19+20 - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/1bb4de2e...86bea8ec ------------- Changes: https://git.openjdk.java.net/jdk/pull/8166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=11 Stats: 99452 lines in 1130 files changed: 91184 ins; 3598 del; 4670 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From mdoerr at openjdk.java.net Thu May 5 09:38:20 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 5 May 2022 09:38:20 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment [v4] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 08:02:57 GMT, Johannes Bechberger wrote: >> Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. >> >> AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Merge cast into condition LGTM. src/hotspot/share/prims/forte.cpp line 571: > 569: JavaThread* thread; > 570: > 571: if (trace->env_id == NULL || raw_thread == NULL || !raw_thread->is_Java_thread() || (thread = JavaThread::cast(raw_thread))->is_exiting()) { Line is a bit long! (There are other long lines in this file, too, so, I can live with it.) ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8446 From alanb at openjdk.java.net Thu May 5 09:47:38 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 5 May 2022 09:47:38 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v11] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 16:02:36 GMT, Aleksey Shipilev wrote: > So, does this PR pass current GHA checks? I see they are not enabled for this PR. It would be unfortunate for this large integration to break builds/tests for smaller PRs that would follow it. I've enabled it on my fork and we'll see if it kicks in. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From jbachorik at openjdk.java.net Thu May 5 09:52:37 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 5 May 2022 09:52:37 GMT Subject: RFR: 8282420: JFR: Remove event handlers In-Reply-To: References: Message-ID: <_5I-X5S5yMBx0VCDRirEt6UlBqqgWFU9VcF-jDDIejM=.f250a9e7-ce30-4a8a-b641-8978a2df7735@github.com> On Mon, 25 Apr 2022 16:49:42 GMT, Erik Gahlin wrote: > Hi, > > Could I have a review of a fix that removes event handler classes for JFR. Bytecode for event instrumentation is now only added to the event class. Benefits are: > > - No class memory leak in the boot class loader. > - Reduce overhead from class loading during startup, which is important with additional JDK events that are coming (VirtualThreadStart etc.) > - One less frame to traverse when recording a Java stack trace. > > Future benefits are: > > - Simplify creating instrumentation at build step. See https://bugs.openjdk.java.net/browse/JDK-8279354 > - Simplify implementation of Event Metrics. See https://bugs.openjdk.java.net/browse/JDK-8224749 > > When the Security Manager is removed, much of the code being added for security reasons can be deleted. > > There are few JFR hooks when code is being linked. Plan is to also use these for other events later. > > Testing: tier 1-4, jdk/jdk/jfr > > Thanks > Erik src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp line 1451: > 1449: > 1450: // If for a subklass, on initial class load, an implementation exist for any of the final methods declared in Event, > 1451: // then constaints are considered breached. Suggestion: // then constraints are considered breached. src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp line 1468: > 1466: if (invalid_preconditions_for_subklass_on_initial_load(ik)) { > 1467: // Remove the tag denoting this as a jdk.jfr.Event subklass. No instrumentation, hence no events can be written. > 1468: // The class is allow to load as-is, but it is classified as outside of the jfr system. Suggestion: // The class is allowed to load as-is, but it is classified as outside of the jfr system. src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp line 1560: > 1558: (JvmtiCachedClassFileData*)NEW_C_HEAP_ARRAY_RETURN_NULL(u1, offset_of(JvmtiCachedClassFileData, data) + stream_len, mtInternal); > 1559: if (p == NULL) { > 1560: log_error(jfr, system)("Allocation using C_HEAP_ARRAY for " SIZE_FORMAT " bytes failed in JfrEventClassTransformer::on_klass_creation", Is the log text referencing a wrong method? Suggestion: log_error(jfr, system)("Allocation using C_HEAP_ARRAY for " SIZE_FORMAT " bytes failed in JfrEventClassTransformer::cache_class_file_data", src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.cpp line 190: > 188: /* Set callbacks */ > 189: memset(&callbacks, 0, sizeof(callbacks)); > 190: // callbacks.ClassFileLoadHook = jfr_on_class_file_load_hook; Perhaps you want to remove this commented out code src/hotspot/share/jfr/instrumentation/jfrResolution.hpp line 41: > 39: static void on_resolution(const CallInfo & info, TRAPS); > 40: static void on_resolution(const Parse * parse, const ciKlass * holder, const ciMethod * target); > 41: static void on_resolution(const GraphBuilder * builder, const ciKlass * holder, const ciMethod * target); Could you add brief comments as when will each callback be called? Eg. the second form is called from C1 and the third form is called from C2 (assuming based on what I see in the cpp file)? src/jdk.jfr/share/classes/jdk/jfr/internal/EventClassBuilder.java line 112: > 110: methodVisitor.visitMethodInsn(Opcodes.INVOKESPECIAL, className, m.getName(), m.getDescriptor(), false); > 111: } > 112: I wonder if it makes sense to extract this method - it is virtually replacing one method call by another. src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 92: > 90: > 91: public boolean isString() { > 92: return ASMToolkit.TYPE_STRING.getDescriptor().equals(fieldDescriptor); If this is to be called often it might be beneficial to cache the descriptor instead of recreating it each time. src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 139: > 137: this.settingInfos = buildSettingInfos(superClass, classNode); > 138: this.fieldInfos = buildFieldInfos(superClass, classNode); > 139: String n = annotationValue(classNode, ANNOTATION_TYPE_NAME.getDescriptor(), String.class); As well - the descriptor could be cached to avoid calling substring operations repeatedly. src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformEventType.java line 109: > 107: } > 108: } > 109: return 3; Why is the default stack trace offset changed? ------------- PR: https://git.openjdk.java.net/jdk/pull/8383 From duke at openjdk.java.net Thu May 5 10:29:07 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 5 May 2022 10:29:07 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment [v5] In-Reply-To: References: Message-ID: > Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. > > AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Break long line ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8446/files - new: https://git.openjdk.java.net/jdk/pull/8446/files/8d4b60eb..48f45e95 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8446&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8446&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8446.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8446/head:pull/8446 PR: https://git.openjdk.java.net/jdk/pull/8446 From jbachorik at openjdk.java.net Thu May 5 10:51:16 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 5 May 2022 10:51:16 GMT Subject: RFR: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment [v5] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 10:29:07 GMT, Johannes Bechberger wrote: >> Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. >> >> AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Break long line Marked as reviewed by jbachorik (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8446 From duke at openjdk.java.net Thu May 5 11:12:17 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 5 May 2022 11:12:17 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3] In-Reply-To: References: Message-ID: On Tue, 3 May 2022 12:42:19 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed instantiation of a frame when done from a signal handler - eg. for profiling purposes. >> >> Currently, a frame instantiation will fail on guarantee when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of profiling where the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >> The behaviour defaults to checking the code blob status in the guarantee so nothing will change for the rest of the callers - just ASGCT will be affected. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > > Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: > > Extract common method for finding code blob in a signal handler Using the approach proposed by Thomas has also the advantage, that we can use to handle other special casing for ASGCT too. ------------- PR: https://git.openjdk.java.net/jdk/pull/8061 From duke at openjdk.java.net Thu May 5 11:22:16 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 5 May 2022 11:22:16 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3] In-Reply-To: References: Message-ID: <_qDHX3E9buo5I8AkmMM0RJG91MYHFBK_yyTqO3IF0eE=.ece72a4a-0a19-4035-a51a-1b8d7ab1a274@github.com> On Tue, 3 May 2022 12:42:19 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed instantiation of a frame when done from a signal handler - eg. for profiling purposes. >> >> Currently, a frame instantiation will fail on guarantee when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of profiling where the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >> The behaviour defaults to checking the code blob status in the guarantee so nothing will change for the rest of the callers - just ASGCT will be affected. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > > Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: > > Extract common method for finding code blob in a signal handler src/hotspot/cpu/x86/frame_x86.cpp line 718: > 716: // This is a generic constructor which is only used by pns() in debug.cpp. > 717: frame::frame(void* sp, void* fp, void* pc) { > 718: init((intptr_t*)sp, (intptr_t*)fp, (address)pc, CodeCache::find_blob((address)pc)); There is no overload for `init` that accepts a `CodeBlob*` as its fourth argument. If it compiles then it converted implicitly into `CodeCache::find_blob((address)pc) != NULL`. Is this intentional? ------------- PR: https://git.openjdk.java.net/jdk/pull/8061 From jbachorik at openjdk.java.net Thu May 5 11:32:19 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 5 May 2022 11:32:19 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3] In-Reply-To: References: Message-ID: <_QHpDGQwTZMCSXemOKYMIYeijBu6E2prnyTJmTYf5Z4=.daeacb7a-57c8-4d81-b4c0-3a684e8c4325@github.com> On Tue, 3 May 2022 12:42:19 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed instantiation of a frame when done from a signal handler - eg. for profiling purposes. >> >> Currently, a frame instantiation will fail on guarantee when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of profiling where the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >> The behaviour defaults to checking the code blob status in the guarantee so nothing will change for the rest of the callers - just ASGCT will be affected. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > > Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: > > Extract common method for finding code blob in a signal handler Thank you all for the reviews! I am going to close this PR and open a new one based on the thread-local flag approach as recommended by @tstuefe The new PR is #8549 ------------- PR: https://git.openjdk.java.net/jdk/pull/8061 From jbachorik at openjdk.java.net Thu May 5 11:32:19 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 5 May 2022 11:32:19 GMT Subject: Withdrawn: 8283849: AsyncGetCallTrace may crash JVM on guarantee In-Reply-To: References: Message-ID: <1CvMnwz7eeIZUu10sp4dpYwji-0tiNFO4k2vUwv5I84=.5c339eb5-5d74-40b3-b1a5-788063992243@github.com> On Thu, 31 Mar 2022 15:45:05 GMT, Jaroslav Bachorik wrote: > A gist of the fix is to allow relaxed instantiation of a frame when done from a signal handler - eg. for profiling purposes. > > Currently, a frame instantiation will fail on guarantee when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of profiling where the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. > > The behaviour defaults to checking the code blob status in the guarantee so nothing will change for the rest of the callers - just ASGCT will be affected. > >
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. > However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8061 From jbachorik at openjdk.java.net Thu May 5 11:35:51 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 5 May 2022 11:35:51 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee Message-ID: A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it.
Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably.

_Note: This is a followup PR for #8061_ ------------- Commit messages: - 8283849: AsyncGetCallTrace may crash JVM on guarantee Changes: https://git.openjdk.java.net/jdk/pull/8549/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283849 Stats: 18 lines in 4 files changed: 18 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8549.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8549/head:pull/8549 PR: https://git.openjdk.java.net/jdk/pull/8549 From duke at openjdk.java.net Thu May 5 11:44:16 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 5 May 2022 11:44:16 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee In-Reply-To: References: Message-ID: On Thu, 5 May 2022 11:28:14 GMT, Jaroslav Bachorik wrote: > A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. > > Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. > >
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. > However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > >

> > _Note: This is a followup PR for #8061_ src/hotspot/share/code/codeCache.cpp line 658: > 656: // when in ASGCT handler things might get rough and not all guarantees are held > 657: // if the resolved blob is already a zombie return NULL instead of crashing on guarantee > 658: return result != NULL || result->is_zombie() ? NULL : result; Could you add parentheses around the condition and possibly use `&&` instead of `||`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From jbachorik at openjdk.java.net Thu May 5 11:51:47 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 5 May 2022 11:51:47 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: References: Message-ID: > A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. > > Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. > >
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. > However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > >

> > _Note: This is a followup PR for #8061_ Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: Make sure the code blob result check is correct ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8549/files - new: https://git.openjdk.java.net/jdk/pull/8549/files/2f009671..ce15582a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8549.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8549/head:pull/8549 PR: https://git.openjdk.java.net/jdk/pull/8549 From dholmes at openjdk.java.net Thu May 5 12:05:20 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 5 May 2022 12:05:20 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 11:51:47 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. >> >> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. >> >>

>> >> _Note: This is a followup PR for #8061_ > > Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: > > Make sure the code blob result check is correct Changes requested by dholmes (Reviewer). src/hotspot/share/code/codeCache.cpp line 657: > 655: if (current_thread != NULL && current_thread->in_asgct()) { > 656: // when in ASGCT handler things might get rough and not all guarantees are held > 657: // if the resolved blob is already a zombie return NULL instead of crashing on guarantee Suggestion: // If called from ACGT the usual invariants may not apply so if we find // a zombie method just return NULL. src/hotspot/share/runtime/thread.hpp line 647: > 645: #endif // __APPLE__ && AARCH64 > 646: > 647: // support ASGCT Nit: the abbreviation for AsyncGetCallTrace is AGCT not ASGCT src/hotspot/share/runtime/thread.hpp line 649: > 647: // support ASGCT > 648: private: > 649: bool _in_asgct; The position of this field may be significant. See if there are gaps in the Thread structure which this bool might be able to fill. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From jbachorik at openjdk.java.net Thu May 5 12:13:18 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 5 May 2022 12:13:18 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3] In-Reply-To: References: Message-ID: > A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. > > Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. > >
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. > However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > >

> > _Note: This is a followup PR for #8061_ Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: Naming and comments cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8549/files - new: https://git.openjdk.java.net/jdk/pull/8549/files/ce15582a..71e5a919 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=01-02 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8549.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8549/head:pull/8549 PR: https://git.openjdk.java.net/jdk/pull/8549 From duke at openjdk.java.net Thu May 5 12:13:19 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 5 May 2022 12:13:19 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 11:59:16 GMT, David Holmes wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: >> >> Make sure the code blob result check is correct > > src/hotspot/share/runtime/thread.hpp line 647: > >> 645: #endif // __APPLE__ && AARCH64 >> 646: >> 647: // support ASGCT > > Nit: the abbreviation for AsyncGetCallTrace is AGCT not ASGCT I would like to disagree: The abbreviation "ASGCT" is used in multiple places in the JVM, especially in `forte.cpp` (where "AGCT" cannot be found). ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From duke at openjdk.java.net Thu May 5 12:13:20 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 5 May 2022 12:13:20 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 12:07:10 GMT, Johannes Bechberger wrote: >> src/hotspot/share/runtime/thread.hpp line 647: >> >>> 645: #endif // __APPLE__ && AARCH64 >>> 646: >>> 647: // support ASGCT >> >> Nit: the abbreviation for AsyncGetCallTrace is AGCT not ASGCT > > I would like to disagree: The abbreviation "ASGCT" is used in multiple places in the JVM, especially in `forte.cpp` (where "AGCT" cannot be found). I found "AGCT" only in a method named "Java_MyPackage_ASGCTBaseTest_checkAsyncGetCallTraceCall". ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From dholmes at openjdk.java.net Thu May 5 12:20:20 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 5 May 2022 12:20:20 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 12:08:54 GMT, Johannes Bechberger wrote: >> I would like to disagree: The abbreviation "ASGCT" is used in multiple places in the JVM, especially in `forte.cpp` (where "AGCT" cannot be found). > > I found "AGCT" only in a method named "Java_MyPackage_ASGCTBaseTest_checkAsyncGetCallTraceCall". My apologies. I've always referred to it by the obvious abbreviation. But if the existing code uses ASGCT then lets be consistent. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From dholmes at openjdk.java.net Thu May 5 12:20:19 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 5 May 2022 12:20:19 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 12:13:18 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. >> >> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. >> >>

>> >> _Note: This is a followup PR for #8061_ > > Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: > > Naming and comments cleanup Changes requested by dholmes (Reviewer). src/hotspot/share/runtime/thread.hpp line 649: > 647: // support AGCT > 648: private: > 649: bool _in_agct; This should actually be in JavaThread as AGCT only operates on JavaThreads. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From jbachorik at openjdk.java.net Thu May 5 12:24:16 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 5 May 2022 12:24:16 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: References: Message-ID: <_sH1LiMQP6BKOS86T2wDy8JdhKws6CgOL9WuH7nTEgs=.bdc5626a-09f4-4735-b730-ee13cd169b45@github.com> On Thu, 5 May 2022 12:00:49 GMT, David Holmes wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: >> >> Make sure the code blob result check is correct > > src/hotspot/share/runtime/thread.hpp line 649: > >> 647: // support ASGCT >> 648: private: >> 649: bool _in_asgct; > > The position of this field may be significant. See if there are gaps in the Thread structure which this bool might be able to fill. Just to clarify - you mean finding a gap due to padding and putting the field there? The rest of the fields are usually clustered around the supported functionality so before I insert this flag somewhere in the middle of unrelated fields I want to be sure this is what we want. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From jbachorik at openjdk.java.net Thu May 5 12:43:18 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 5 May 2022 12:43:18 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 12:13:49 GMT, David Holmes wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: >> >> Naming and comments cleanup > > src/hotspot/share/runtime/thread.hpp line 649: > >> 647: // support AGCT >> 648: private: >> 649: bool _in_agct; > > This should actually be in JavaThread as AGCT only operates on JavaThreads. I will have to do check/cast in `CodeCache::find_blob()` as that may get called from any thread, not just Java threads. I would assume that having this flag defined at Thread level is a lesser of the evils - or am I wrong here? ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From jbachorik at openjdk.java.net Thu May 5 13:02:58 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 5 May 2022 13:02:58 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v4] In-Reply-To: References: Message-ID: > A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. > > Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. > >
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. > However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > >

> > _Note: This is a followup PR for #8061_ Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: AGCT -> ASGCT ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8549/files - new: https://git.openjdk.java.net/jdk/pull/8549/files/71e5a919..caf43e39 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=02-03 Stats: 15 lines in 3 files changed: 4 ins; 8 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8549.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8549/head:pull/8549 PR: https://git.openjdk.java.net/jdk/pull/8549 From jbachorik at openjdk.java.net Thu May 5 13:02:59 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 5 May 2022 13:02:59 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: <_sH1LiMQP6BKOS86T2wDy8JdhKws6CgOL9WuH7nTEgs=.bdc5626a-09f4-4735-b730-ee13cd169b45@github.com> References: <_sH1LiMQP6BKOS86T2wDy8JdhKws6CgOL9WuH7nTEgs=.bdc5626a-09f4-4735-b730-ee13cd169b45@github.com> Message-ID: On Thu, 5 May 2022 12:20:41 GMT, Jaroslav Bachorik wrote: >> src/hotspot/share/runtime/thread.hpp line 649: >> >>> 647: // support ASGCT >>> 648: private: >>> 649: bool _in_asgct; >> >> The position of this field may be significant. See if there are gaps in the Thread structure which this bool might be able to fill. > > Just to clarify - you mean finding a gap due to padding and putting the field there? > The rest of the fields are usually clustered around the supported functionality so before I insert this flag somewhere in the middle of unrelated fields I want to be sure this is what we want. I had tried identifying any gaps I might use but found none. Not saying they are none but it is rather difficult to spot anything with all the Thread related attributes spread across many lines, interspersed with the method declarations :( Any trick or tool I might use to find the right place for this attribute? ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From duke at openjdk.java.net Thu May 5 13:26:16 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Thu, 5 May 2022 13:26:16 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: References: <_sH1LiMQP6BKOS86T2wDy8JdhKws6CgOL9WuH7nTEgs=.bdc5626a-09f4-4735-b730-ee13cd169b45@github.com> Message-ID: On Thu, 5 May 2022 12:55:31 GMT, Jaroslav Bachorik wrote: >> Just to clarify - you mean finding a gap due to padding and putting the field there? >> The rest of the fields are usually clustered around the supported functionality so before I insert this flag somewhere in the middle of unrelated fields I want to be sure this is what we want. > > I had tried identifying any gaps I might use but found none. Not saying they are none but it is rather difficult to spot anything with all the Thread related attributes spread across many lines, interspersed with the method declarations :( > Any trick or tool I might use to find the right place for this attribute? An option would be to place it after https://github.com/openjdk/jdk/blob/ce15582a7570b529a4c9b3d500f60fa0a2dc772d/src/hotspot/share/runtime/thread.hpp#L901 but it would make the code less coherent. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From jbachorik at openjdk.java.net Thu May 5 13:45:18 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 5 May 2022 13:45:18 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: References: <_sH1LiMQP6BKOS86T2wDy8JdhKws6CgOL9WuH7nTEgs=.bdc5626a-09f4-4735-b730-ee13cd169b45@github.com> Message-ID: On Thu, 5 May 2022 13:21:39 GMT, Johannes Bechberger wrote: >> I had tried identifying any gaps I might use but found none. Not saying they are none but it is rather difficult to spot anything with all the Thread related attributes spread across many lines, interspersed with the method declarations :( >> Any trick or tool I might use to find the right place for this attribute? > > An option would be to place it after https://github.com/openjdk/jdk/blob/ce15582a7570b529a4c9b3d500f60fa0a2dc772d/src/hotspot/share/runtime/thread.hpp#L901 but it would make the code less coherent. Ok, moved it a bit around - now the bool field is after an int field which should make things slightly better, I guess. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From aph at openjdk.java.net Thu May 5 15:04:05 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 5 May 2022 15:04:05 GMT Subject: RFR: 8285923: [REDO] JDK-8285802 AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities Message-ID: It is with some trepidation that I post this after breaking things last time. However, I think I've tested this as much as it can be tested. The change from last time around is this: +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp @@ -2192,11 +2192,13 @@ void MacroAssembler::unimplemented(const char* what) { // If a constant does not fit in an immediate field, generate some // number of MOV instructions and then perform the operation. -void MacroAssembler::wrap_add_sub_imm_insn(Register Rd, Register Rn, unsigned imm, +void MacroAssembler::wrap_add_sub_imm_insn(Register Rd, Register Rn, uint64_t imm, add_sub_imm_insn insn1, - add_sub_reg_insn insn2) { + add_sub_reg_insn insn2, + bool is32) { assert(Rd != zr, "Rd = zr and not setting flags?"); - if (operand_valid_for_add_sub_immediate((int)imm)) { + bool fits = operand_valid_for_add_sub_immediate(is32 ? (int32_t)imm : imm); + if (fits) { (this->*insn1)(Rd, Rn, imm); After this patch, when an add/sub instruction has a 32-bit (rather than a 64-bit) operand, we truncate the operand to signed int. We do this because `operand_valid_for_add_sub_immediate()` takes a 64-bit signed operand, but if the instruction is only 32 bits wide we must ignore the upper 32 bits. Therefore, `wrap_add_sub_imm_insn()` needs to know the operand size in order to sign extend the operand correctly. Tested tier1-3, tier4 is still running but no regressions yet. ------------- Commit messages: - 8285923: [REDO] JDK-8285802 AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities Changes: https://git.openjdk.java.net/jdk/pull/8554/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8554&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285923 Stats: 29 lines in 3 files changed: 4 ins; 0 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/8554.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8554/head:pull/8554 PR: https://git.openjdk.java.net/jdk/pull/8554 From coffeys at openjdk.java.net Thu May 5 16:08:38 2022 From: coffeys at openjdk.java.net (Sean Coffey) Date: Thu, 5 May 2022 16:08:38 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12] In-Reply-To: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com> References: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com> Message-ID: <7N1fimic2Cdh1UG_lIkjdUZhX_r-zzC1equf9VbNU7U=.f43339fb-7797-4d84-9c87-472e6db02638@github.com> On Thu, 5 May 2022 09:35:42 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview). >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: > > - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f > - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5 > - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05 > - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89 > - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a > - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4 > - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec > - Merge with jdk-19+20 > - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 > - ... and 9 more: https://git.openjdk.java.net/jdk/compare/1bb4de2e...86bea8ec Studied the java.io package edits, the new JFR events and the new jcmd dump_to_file functionality. Looks good! ------------- Marked as reviewed by coffeys (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From jbhateja at openjdk.java.net Thu May 5 16:09:20 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 5 May 2022 16:09:20 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 05:47:47 GMT, Jatin Bhateja wrote: >> Hi All, >> >> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) >> >> Following is the brief summary of changes:- >> >> 1) Extends the scope of existing lanewise API for following new vector operations. >> - VectorOperations.BIT_COUNT: counts the number of one-bits >> - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits >> - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits >> - VectorOperations.REVERSE: reversing the order of bits >> - VectorOperations.REVERSE_BYTES: reversing the order of bytes >> - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. >> >> 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. >> - Vector.compress >> - Vector.expand >> - VectorMask.compress >> >> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. >> - Vector.fromMemorySegment >> - Vector.intoMemorySegment >> >> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. >> >> >> Patch has been regressed over AARCH64 and X86 targets different AVX levels. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - 8284960: Correcting a typo. > - 8284960: Integrating changes from panama-vector (Add @since 19 tags). > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - 8284960: AARCH64 backend changes. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - 8284960: Integration of JEP 426: Vector API (Fourth Incubator) Hi @vnkozlov , It will be helpful if you can kindly review the changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From mchung at openjdk.java.net Thu May 5 16:26:37 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 5 May 2022 16:26:37 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 23:44:08 GMT, Maurizio Cimadamore wrote: >> Another option would be to treat calls to `ensureNativeAccess` with `null` caller class as coming from unnamed module. > > Looking deeper, `System::loadLibrary` seems to search the boot loader libraries when invoked with a `null` caller class, so replicating that behavior should be safe. `BootLoader` is what you want in this case - it defines the static methods to access resources, packages etc defined to the boot loader (aka null `ClassLoader`). To find a symbol defined in the native libraries loaded by the boot loader, you can call `BootLoader.getNativeLibraries().find(name)`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mchung at openjdk.java.net Thu May 5 16:42:25 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 5 May 2022 16:42:25 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 16:22:41 GMT, Mandy Chung wrote: >> Looking deeper, `System::loadLibrary` seems to search the boot loader libraries when invoked with a `null` caller class, so replicating that behavior should be safe. > > `BootLoader` is what you want in this case - it defines the static methods to access resources, packages etc defined to the boot loader (aka null `ClassLoader`). > > To find a symbol defined in the native libraries loaded by the boot loader, you can call `BootLoader.getNativeLibraries().find(name)`. When a caller-sensitive method is invoked from a thread attached via JNI, the caller class returned from `Reflection::getCallerClass` is `null`. I would recommend the default to be a class in the unnamed module defined to the system class loader; hence it defaults to the system class loader. This is consistent with JNI `FindClass` when invoked with no caller frame. It's an open issue [1] to revisit the default for `System::load` and `System::loadLibrary` when invoked with null caller class. However, the existing behavior may likely be unchanged because of the compatibility risk. [1] https://bugs.openjdk.java.net/browse/JDK-8281001 ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From dcubed at openjdk.java.net Thu May 5 16:51:18 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 5 May 2022 16:51:18 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v4] In-Reply-To: References: Message-ID: <9y0sKLe1dZat_Av4yr-1u43ApyrnywRBzs_5OqfWD0I=.afb4105c-11ce-40f9-bb95-7f8b490660df@github.com> On Thu, 5 May 2022 13:02:58 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. >> >> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. >> >>

>> >> _Note: This is a followup PR for #8061_ > > Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: > > AGCT -> ASGCT > I would like to disagree: The abbreviation "ASGCT" is used in multiple places in the JVM, > especially in `forte.cpp` (where "AGCT" cannot be found). That was a very old mistake on my part. It should have been `AGCT` instead of `ASGCT` and I never got around to fixing that. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From darcy at openjdk.java.net Thu May 5 17:15:49 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 5 May 2022 17:15:49 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12] In-Reply-To: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com> References: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com> Message-ID: <0ntcEQFUGJN5jQeKnIZrEqQR9CDgkt9aHi-1mzUcKP0=.959c2be4-16c1-4d21-8276-a273e5945658@github.com> On Thu, 5 May 2022 09:35:42 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview). >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: > > - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f > - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5 > - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05 > - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89 > - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a > - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4 > - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec > - Merge with jdk-19+20 > - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 > - ... and 9 more: https://git.openjdk.java.net/jdk/compare/1bb4de2e...86bea8ec Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From never at openjdk.java.net Thu May 5 17:37:16 2022 From: never at openjdk.java.net (Tom Rodriguez) Date: Thu, 5 May 2022 17:37:16 GMT Subject: RFR: 8283306: re-resolving indirect call to non-entrant nmethod can crash [v4] In-Reply-To: References: Message-ID: <3qTz8p8OziCEewkjp5tMoY9SqLsnEvL6zJsX-nFjy6o=.b64155bf-6ed3-44a7-8e45-01bd91cbd595@github.com> On Wed, 4 May 2022 22:57:13 GMT, Dean Long wrote: >> This change fixes a crash that can happen in SharedRuntime::reresolve_call_site with Graal/JVMCI. >> See https://bugs.openjdk.java.net/browse/JDK-8283306 for details. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > cleanup my changes look good to me. :) ------------- Marked as reviewed by never (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8528 From lkorinth at openjdk.java.net Thu May 5 17:43:37 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Thu, 5 May 2022 17:43:37 GMT Subject: RFR: 8281297: TestStressG1Humongous fails with guarantee(is_range_uncommitted) Message-ID: TestStressG1Humongous passes 200 times with this change. I have started a new windows run with 1000 iterations. Without the fix the testcase will usually fail a few times when iterating 100 times. I have also started a tier 1-3 run. ------------- Commit messages: - 8281297: TestStressG1Humongous fails with guarantee(is_range_uncommitted) Changes: https://git.openjdk.java.net/jdk/pull/8560/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8560&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281297 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8560.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8560/head:pull/8560 PR: https://git.openjdk.java.net/jdk/pull/8560 From shade at openjdk.java.net Thu May 5 17:46:09 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 5 May 2022 17:46:09 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12] In-Reply-To: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com> References: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com> Message-ID: On Thu, 5 May 2022 09:35:42 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview). >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: > > - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f > - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5 > - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05 > - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89 > - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a > - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4 > - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec > - Merge with jdk-19+20 > - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 > - ... and 9 more: https://git.openjdk.java.net/jdk/compare/1bb4de2e...86bea8ec I am sorry to be a buzzkill here, but this integration would break lots of platforms even when Loom functionality is not enabled/used. For example, running `java -version` on RISC-V runs into many issues: `TemplateInterpreterGenerator::generate_Continuation_doYield_entry` runs into `Unimplemented()`, `UnsafeCopyMemory` asserts about UCM table size, `NativeDeoptInstruction::is_deopt` would run into `Unimplemented()` while being called from signal handler. This effectively blocks development on those platforms, and it seems to be too much breakage for a preview feature. Are we really breaking these platforms? Do we have plans in place with maintainers of those platforms to fix all this in JDK 19 timeframe? I'd suggest holding off the integration until such a plan and agreement is in place. ------------- Changes requested by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8166 From eosterlund at openjdk.java.net Thu May 5 18:04:20 2022 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 5 May 2022 18:04:20 GMT Subject: RFR: 8281297: TestStressG1Humongous fails with guarantee(is_range_uncommitted) In-Reply-To: References: Message-ID: On Thu, 5 May 2022 17:37:35 GMT, Leo Korinth wrote: > TestStressG1Humongous passes 200 times with this change. I have started a new windows run with 1000 iterations. Without the fix the testcase will usually fail a few times when iterating 100 times. I have also started a tier 1-3 run. Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8560 From iwalulya at openjdk.java.net Thu May 5 18:53:08 2022 From: iwalulya at openjdk.java.net (Ivan Walulya) Date: Thu, 5 May 2022 18:53:08 GMT Subject: RFR: 8281297: TestStressG1Humongous fails with guarantee(is_range_uncommitted) In-Reply-To: References: Message-ID: <_10cFnZUXfmEUR7FEbFURDb-H4bG2KkUxGV7vrlDCw4=.687f80f3-50c5-4619-bff4-5208216badbe@github.com> On Thu, 5 May 2022 17:37:35 GMT, Leo Korinth wrote: > TestStressG1Humongous passes 200 times with this change. I have started a new windows run with 1000 iterations. Without the fix the testcase will usually fail a few times when iterating 100 times. I have also started a tier 1-3 run. Marked as reviewed by iwalulya (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8560 From alanb at openjdk.java.net Thu May 5 19:00:42 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 5 May 2022 19:00:42 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12] In-Reply-To: References: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com> Message-ID: On Thu, 5 May 2022 17:43:58 GMT, Aleksey Shipilev wrote: > I am sorry to be a buzzkill here, but this integration would break lots of platforms even when Loom functionality is not enabled/used. For example, running `java -version` on RISC-V runs into many issues: `TemplateInterpreterGenerator::generate_Continuation_doYield_entry` runs into `Unimplemented()`, `UnsafeCopyMemory` asserts about UCM table size, `NativeDeoptInstruction::is_deopt` would run into `Unimplemented()` while being called from signal handler. > > This effectively blocks development on those platforms, and it seems to be too much breakage for a preview feature. Are we really breaking these platforms? Do we have plans in place with maintainers of those platforms to fix all this in JDK 19 timeframe? I'd suggest holding off the integration until such a plan and agreement is in place. We mailed porters-dev in Sep 2021 to give a heads up that this feature would require porting work so it shouldn't be a surprise. We have been open to including other ports with the initial integration but it was never a goal to have all the ports done in advance of that. Most of the new code in the VM is only used when running with --enable-preview. You'll see several places that test Continuations::enabled(). It should be possible to get these port running without -enable-preview without much effort. The feature has to be implemented to pass all the tests of course. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From psandoz at openjdk.java.net Thu May 5 19:30:59 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 5 May 2022 19:30:59 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v3] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 08:56:07 GMT, Xiaohong Gong wrote: >> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception. >> >> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize): >> >> >> @ForceInline >> public static >> ByteVector fromArray(VectorSpecies species, >> byte[] a, int offset, >> VectorMask m) { >> ByteSpecies vsp = (ByteSpecies) species; >> if (offset >= 0 && offset <= (a.length - species.length())) { >> return vsp.dummyVector().fromArray0(a, offset, m); >> } >> >> // FIXME: optimize >> checkMaskFromIndexSize(offset, vsp, m, 1, a.length); >> return vsp.vOp(m, i -> a[offset + i]); >> } >> >> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed. >> >> Also adds the same vectorization support for masked: >> - fromByteArray/fromByteBuffer >> - fromBooleanArray >> - fromCharArray >> >> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system: >> >> Benchmark before After Units >> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE 737.542 1387.069 ops/ms >> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366 330.776 ops/ms >> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE 233.832 6125.026 ops/ms >> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE 233.816 7075.923 ops/ms >> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE 119.771 330.587 ops/ms >> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE 431.961 939.301 ops/ms >> >> Similar performance gain can also be observed on 512-bit SVE system. > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Rename "use_predicate" to "needs_predicate" src/hotspot/share/opto/vectorIntrinsics.cpp line 1238: > 1236: } else { > 1237: // Masked vector load with IOOBE always uses the predicated load. > 1238: const TypeInt* offset_in_range = gvn().type(argument(8))->isa_int(); Should it be `argument(7)`? (and adjustments later to access the container). ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From duke at openjdk.java.net Thu May 5 20:43:20 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Thu, 5 May 2022 20:43:20 GMT Subject: RFR: 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call Message-ID: `MacroAssembler::trampoline_call` is for generating calls of targets which are inside CodeCache and can have relocInfo types: `runtime_call_type`, `opt_virtual_call_type`, `static_call_type` or `virtual_call_type`. This PR updates the description of the function and adds additional asserts. Tested a fastdebug build: - `gtest`: Passed - `tier1`: Passed ------------- Commit messages: - 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call Changes: https://git.openjdk.java.net/jdk/pull/8564/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8564&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286058 Stats: 31 lines in 2 files changed: 31 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8564.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8564/head:pull/8564 PR: https://git.openjdk.java.net/jdk/pull/8564 From mcimadamore at openjdk.java.net Thu May 5 20:54:53 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 5 May 2022 20:54:53 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v39] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI * Tweak restricted method check to work when there's no caller class ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/853f06b8..4d24ffa9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=38 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=37-38 Stats: 22 lines in 2 files changed: 16 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Thu May 5 20:54:55 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 5 May 2022 20:54:55 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v37] In-Reply-To: References: Message-ID: <-zAvw8aE9e94OWQyDLUT3IqPzKJFT3v0x_HQVJObonc=.3370a3b7-e797-439f-8a72-ff6d3ec59be4@github.com> On Thu, 5 May 2022 16:39:08 GMT, Mandy Chung wrote: >> `BootLoader` is what you want in this case - it defines the static methods to access resources, packages etc defined to the boot loader (aka null `ClassLoader`). >> >> To find a symbol defined in the native libraries loaded by the boot loader, you can call `BootLoader.getNativeLibraries().find(name)`. > > When a caller-sensitive method is invoked from a thread attached via JNI, the caller class returned from `Reflection::getCallerClass` is `null`. I would recommend the default to be a class in the unnamed module defined to the system class loader; hence it defaults to the system class loader. This is consistent with JNI `FindClass` when invoked with no caller frame. > > It's an open issue [1] to revisit the default for `System::load` and `System::loadLibrary` when invoked with null caller class. However, the existing behavior may likely be unchanged because of the compatibility risk. > > [1] https://bugs.openjdk.java.net/browse/JDK-8281001 Thanks for the comments. I've pushed a new change which fixes a couple of thing: * first, for `SymbolLookup.loaderLookup`, the system class loader is used when no caller class exists (e.g. when method is called from JNI). If caller class exist but its loader is null (boot loader), we just call ClassLoader::findNative with a `null` loader which will do the right thing (thanks @mlchung for the tips!) * second, the restricted method check in `Reflection::ensureNativeAccess` has been improved to also work in case where caller class is `null`. In such cases, a dummy unnamed module module is used for the check. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From phh at openjdk.java.net Thu May 5 20:59:50 2022 From: phh at openjdk.java.net (Paul Hohensee) Date: Thu, 5 May 2022 20:59:50 GMT Subject: RFR: 8286056: AArch64: clarify uses of MacroAssembler::far_call/MacroAssembler::far_jump [v2] In-Reply-To: References: Message-ID: <2r2W0i8wZoDCT99y1LmBdXkzbZ25zVZL1PO19kgt34Q=.0e0c63aa-c014-42c0-9bb3-497cdf83879d@github.com> On Wed, 4 May 2022 18:27:14 GMT, Evgeny Astigeevich wrote: >> `MacroAssembler::far_call`/`MacroAssembler::far_jump` are for generating calls of/jumps to targets which are inside `CodeCache` and can `relocInfo` types: `external_word_type`, `runtime_call_type` or `none`. >> This PR updates the description of the functions and adds an assert checking a `relocInfo` type. >> Tested a fastdebug build: >> - `gtest`: Passed >> - `tier1`: Passed > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Add additional comments to far_call/far_branch Lgtm. ------------- Marked as reviewed by phh (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8534 From duke at openjdk.java.net Thu May 5 20:59:52 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Thu, 5 May 2022 20:59:52 GMT Subject: Integrated: 8286056: AArch64: clarify uses of MacroAssembler::far_call/MacroAssembler::far_jump In-Reply-To: References: Message-ID: <5WLLjN0GXODXH_zeB0Ihjb-81o84SxwvKDJ3Av8RjZw=.c3e626fd-3161-4f41-a387-70acd361d73a@github.com> On Wed, 4 May 2022 12:01:36 GMT, Evgeny Astigeevich wrote: > `MacroAssembler::far_call`/`MacroAssembler::far_jump` are for generating calls of/jumps to targets which are inside `CodeCache` and can `relocInfo` types: `external_word_type`, `runtime_call_type` or `none`. > This PR updates the description of the functions and adds an assert checking a `relocInfo` type. > Tested a fastdebug build: > - `gtest`: Passed > - `tier1`: Passed This pull request has now been integrated. Changeset: 4957bc73 Author: Evgeny Astigeevich Committer: Paul Hohensee URL: https://git.openjdk.java.net/jdk/commit/4957bc739642bfdd1500fd636becd603de026980 Stats: 20 lines in 3 files changed: 17 ins; 0 del; 3 mod 8286056: AArch64: clarify uses of MacroAssembler::far_call/MacroAssembler::far_jump Reviewed-by: aph, kvn, phh ------------- PR: https://git.openjdk.java.net/jdk/pull/8534 From dlong at openjdk.java.net Thu May 5 21:32:13 2022 From: dlong at openjdk.java.net (Dean Long) Date: Thu, 5 May 2022 21:32:13 GMT Subject: RFR: 8283306: re-resolving indirect call to non-entrant nmethod can crash [v4] In-Reply-To: References: Message-ID: On Wed, 4 May 2022 22:57:13 GMT, Dean Long wrote: >> This change fixes a crash that can happen in SharedRuntime::reresolve_call_site with Graal/JVMCI. >> See https://bugs.openjdk.java.net/browse/JDK-8283306 for details. > > Dean Long has updated the pull request incrementally with one additional commit since the last revision: > > cleanup Thanks Doug, Tobias, and Tom. ------------- PR: https://git.openjdk.java.net/jdk/pull/8528 From dlong at openjdk.java.net Thu May 5 21:32:17 2022 From: dlong at openjdk.java.net (Dean Long) Date: Thu, 5 May 2022 21:32:17 GMT Subject: Integrated: 8283306: re-resolving indirect call to non-entrant nmethod can crash In-Reply-To: References: Message-ID: <2CxYioLNdlZlH2HsMcFw5_eiI3A-DROkMyn26UIesBk=.8af08f1d-9c49-42c3-8634-5008f6afd9ef@github.com> On Wed, 4 May 2022 07:47:28 GMT, Dean Long wrote: > This change fixes a crash that can happen in SharedRuntime::reresolve_call_site with Graal/JVMCI. > See https://bugs.openjdk.java.net/browse/JDK-8283306 for details. This pull request has now been integrated. Changeset: 6d7e4461 Author: Dean Long URL: https://git.openjdk.java.net/jdk/commit/6d7e4461620866992975eb9d5de1519e558de7da Stats: 30 lines in 1 file changed: 4 ins; 0 del; 26 mod 8283306: re-resolving indirect call to non-entrant nmethod can crash Reviewed-by: thartmann, never ------------- PR: https://git.openjdk.java.net/jdk/pull/8528 From mchung at openjdk.java.net Thu May 5 21:34:54 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 5 May 2022 21:34:54 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v39] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 20:54:53 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI > * Tweak restricted method check to work when there's no caller class src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 161: > 159: ClassLoader.getSystemClassLoader(); > 160: MemorySession loaderSession = (loader == null) ? > 161: MemorySession.global() : // boot loader never goes away The other built-in class loaders (`ClassLoaders::appClassLoader` and `ClassLoaders::platformClassLoader` are both instance of `BuiltinClassLoader`) will never be unloaded. Should they use the globel memory session? src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 120: > 118: // if there is no caller class, act as if the call came from an unnamed module > 119: Module module = currentClass != null ? > 120: currentClass.getModule() : Holder.FALLBACK_MODULE; This can be simplified to: Module module = currentClass != null ? currentClass.getModule() : ClassLoader::getSystemClassLoader().getUnnamedModule(); No need to have the Holder class. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From duke at openjdk.java.net Thu May 5 22:49:43 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Thu, 5 May 2022 22:49:43 GMT Subject: RFR: 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call [v2] In-Reply-To: References: Message-ID: > `MacroAssembler::trampoline_call` is for generating calls of targets which are inside CodeCache and can have relocInfo types: `runtime_call_type`, `opt_virtual_call_type`, `static_call_type` or `virtual_call_type`. > This PR updates the description of the function and adds additional asserts. > Tested a fastdebug build: > - `gtest`: Passed > - `tier1`: Passed Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: Fix assert message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8564/files - new: https://git.openjdk.java.net/jdk/pull/8564/files/da867184..d3050fba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8564&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8564&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8564.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8564/head:pull/8564 PR: https://git.openjdk.java.net/jdk/pull/8564 From duke at openjdk.java.net Thu May 5 22:49:44 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Thu, 5 May 2022 22:49:44 GMT Subject: RFR: 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call In-Reply-To: References: Message-ID: On Thu, 5 May 2022 20:36:17 GMT, Evgeny Astigeevich wrote: > `MacroAssembler::trampoline_call` is for generating calls of targets which are inside CodeCache and can have relocInfo types: `runtime_call_type`, `opt_virtual_call_type`, `static_call_type` or `virtual_call_type`. > This PR updates the description of the function and adds additional asserts. > Tested a fastdebug build: > - `gtest`: Passed > - `tier1`: Passed @vnkozlov, @theRealAph Could you please review? ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From dholmes at openjdk.java.net Fri May 6 01:21:48 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 6 May 2022 01:21:48 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 12:40:02 GMT, Jaroslav Bachorik wrote: >> src/hotspot/share/runtime/thread.hpp line 649: >> >>> 647: // support AGCT >>> 648: private: >>> 649: bool _in_agct; >> >> This should actually be in JavaThread as AGCT only operates on JavaThreads. > > I will have to do check/cast in `CodeCache::find_blob()` as that may get called from any thread, not just Java threads. > I would assume that having this flag defined at Thread level is a lesser of the evils - or am I wrong here? We have been actively moving JavaThread fields out of Thread. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From kvn at openjdk.java.net Fri May 6 01:23:48 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 6 May 2022 01:23:48 GMT Subject: RFR: 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 22:49:43 GMT, Evgeny Astigeevich wrote: >> `MacroAssembler::trampoline_call` is for generating calls of targets which are inside CodeCache and can have relocInfo types: `runtime_call_type`, `opt_virtual_call_type`, `static_call_type` or `virtual_call_type`. >> This PR updates the description of the function and adds additional asserts. >> Tested a fastdebug build: >> - `gtest`: Passed >> - `tier1`: Passed > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Fix assert message Good. I will run tests too to make sure we don't hit asserts. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8564 From dholmes at openjdk.java.net Fri May 6 01:34:00 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 6 May 2022 01:34:00 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: References: <_sH1LiMQP6BKOS86T2wDy8JdhKws6CgOL9WuH7nTEgs=.bdc5626a-09f4-4735-b730-ee13cd169b45@github.com> Message-ID: On Thu, 5 May 2022 13:42:12 GMT, Jaroslav Bachorik wrote: >> An option would be to place it after https://github.com/openjdk/jdk/blob/ce15582a7570b529a4c9b3d500f60fa0a2dc772d/src/hotspot/share/runtime/thread.hpp#L901 but it would make the code less coherent. > > Ok, moved it a bit around - now the bool field is after an int field which should make things slightly better, I guess. At the start of JavaThread we have: private: bool _on_thread_list; // Is set when this JavaThread is added to the Threads list OopHandle _threadObj; // The Java level thread object so adding it next to the existing bool seems good. The accessors don't have to be defined at the same place. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From xgong at openjdk.java.net Fri May 6 03:51:01 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Fri, 6 May 2022 03:51:01 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v3] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 19:27:47 GMT, Paul Sandoz wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename "use_predicate" to "needs_predicate" > > src/hotspot/share/opto/vectorIntrinsics.cpp line 1238: > >> 1236: } else { >> 1237: // Masked vector load with IOOBE always uses the predicated load. >> 1238: const TypeInt* offset_in_range = gvn().type(argument(8))->isa_int(); > > Should it be `argument(7)`? (and adjustments later to access the container). I'm afraid it's `argument(8)` for the load operation since the `argument(7)` is the mask input. It seems the argument number is not right begin from the mask input which is expected to be `6`. But the it's not. Actually I don't quite understand why. ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From sviswanathan at openjdk.java.net Fri May 6 04:25:49 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Fri, 6 May 2022 04:25:49 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v3] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 03:47:47 GMT, Xiaohong Gong wrote: >> src/hotspot/share/opto/vectorIntrinsics.cpp line 1238: >> >>> 1236: } else { >>> 1237: // Masked vector load with IOOBE always uses the predicated load. >>> 1238: const TypeInt* offset_in_range = gvn().type(argument(8))->isa_int(); >> >> Should it be `argument(7)`? (and adjustments later to access the container). > > I'm afraid it's `argument(8)` for the load operation since the `argument(7)` is the mask input. It seems the argument number is not right begin from the mask input which is expected to be `6`. But the it's not. Actually I don't quite understand why. offset is long so uses two argument slots (5 and 6). mask is argument (7). offsetInRange is argument(8). ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From xgong at openjdk.java.net Fri May 6 04:52:56 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Fri, 6 May 2022 04:52:56 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v3] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 04:22:30 GMT, Sandhya Viswanathan wrote: >> I'm afraid it's `argument(8)` for the load operation since the `argument(7)` is the mask input. It seems the argument number is not right begin from the mask input which is expected to be `6`. But the it's not. Actually I don't quite understand why. > > offset is long so uses two argument slots (5 and 6). > mask is argument (7). > offsetInRange is argument(8). Make sense! Thanks for the explanation! ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From alanb at openjdk.java.net Fri May 6 06:48:46 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 6 May 2022 06:48:46 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v13] In-Reply-To: References: Message-ID: > This is the implementation of JEP 425: Virtual Threads (Preview). > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Refresh 6ace49bf42e5504c69fa11c564e8e865c0a95fb3 - Merge with 9425ab2b43b649bd591706bfc820e9c8795a6fdf - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5 - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05 - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89 - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4 - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec - Merge with jdk-19+20 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/9425ab2b...6d968671 ------------- Changes: https://git.openjdk.java.net/jdk/pull/8166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=12 Stats: 99456 lines in 1130 files changed: 91188 ins; 3598 del; 4670 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From duke at openjdk.java.net Fri May 6 07:11:54 2022 From: duke at openjdk.java.net (Tobias Holenstein) Date: Fri, 6 May 2022 07:11:54 GMT Subject: Integrated: JDK-8283807: Handle CompileThreshold the same as other thresholds when scaled with -XX:CompileThresholdScaling In-Reply-To: References: Message-ID: On Mon, 2 May 2022 13:17:49 GMT, Tobias Holenstein wrote: > `CompileThresholdScaling` scales several compiler thresholds. If the scaled threshold value is outside of the allowed range, a warning is printed and the default value is kept. But when scaling `CompileThreshold` we do not check the scaled value because it is not a ranged flag. Later when verifying flags with a constraint function `OnStackReplacePercentageConstraintFunc` which calls `CompileThresholdConstraintFunc` fails because `CompileThreshold` is outside of the allowed range. This stops the VM from being created. > > The fix is to call `CompileThresholdConstraintFunc` when scaling `CompileThreshold` with `CompileThresholdScaling`. If `CompileThresholdConstraintFunc` fails we print a warning and keep the default value of `CompileThreshold`. This behaviour is then consistent with the other 15 other thresholds where the VM just prints a warning if the scaled value is too large and then keeps the current value. > > We also have to exclude `CompileThresholdScaling` from max. range testing in `TestOptionsWithRanges.java`, because > it is expected to print "outside the allowed range" warnings for the scaled flag and the "outside the allowed range" warning does not refer to `CompileThresholdScaling` itself. > > One question that remains it why `CompileThresholdScaling` takes the default value when a scaled threshold is too large instead of the max. value? Because now we can have the case where some compiler thresholds are scaled to almost their max. value and others that are already larger than the maximum are default again (which can be the minimum value in some cases). I suggest to address this issue in a separate RFE. This pull request has now been integrated. Changeset: dd06cc63 Author: Tobias Holenstein Committer: Tobias Hartmann URL: https://git.openjdk.java.net/jdk/commit/dd06cc638ec54e54cce599f82f37eb56abac2eae Stats: 89 lines in 4 files changed: 84 ins; 3 del; 2 mod 8283807: Handle CompileThreshold the same as other thresholds when scaled with -XX:CompileThresholdScaling Reviewed-by: kvn, iklam, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/8501 From tschatzl at openjdk.java.net Fri May 6 07:29:48 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 6 May 2022 07:29:48 GMT Subject: RFR: 8281297: TestStressG1Humongous fails with guarantee(is_range_uncommitted) In-Reply-To: References: Message-ID: <7IuUrsJMQ_3JFjlelDht_PrCLGOTthb8wdxXUr8B4IQ=.d451c63c-66ba-4c25-804d-dd29af300409@github.com> On Thu, 5 May 2022 17:37:35 GMT, Leo Korinth wrote: > TestStressG1Humongous passes 200 times with this change. I have started a new windows run with 1000 iterations. Without the fix the testcase will usually fail a few times when iterating 100 times. I have also started a tier 1-3 run. Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8560 From tschatzl at openjdk.java.net Fri May 6 07:34:00 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 6 May 2022 07:34:00 GMT Subject: RFR: 8281297: TestStressG1Humongous fails with guarantee(is_range_uncommitted) In-Reply-To: References: Message-ID: On Thu, 5 May 2022 17:37:35 GMT, Leo Korinth wrote: > TestStressG1Humongous passes 200 times with this change. I have started a new windows run with 1000 iterations. Without the fix the testcase will usually fail a few times when iterating 100 times. I have also started a tier 1-3 run. Fwiw, if this duplicates JDK-8283899 (which I think it does), this change ought to include the re-enablement of the G1RegionToSpaceMapper.largeStressAdjacent_vm test - unless you want to do this re-enablement as an extra CR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8560 From aph at openjdk.java.net Fri May 6 08:03:49 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 6 May 2022 08:03:49 GMT Subject: RFR: 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 22:49:43 GMT, Evgeny Astigeevich wrote: >> `MacroAssembler::trampoline_call` is for generating calls of targets which are inside CodeCache and can have relocInfo types: `runtime_call_type`, `opt_virtual_call_type`, `static_call_type` or `virtual_call_type`. >> This PR updates the description of the function and adds additional asserts. >> Tested a fastdebug build: >> - `gtest`: Passed >> - `tier1`: Passed > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Fix assert message src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1103: > 1101: // > 1102: // Trampoline_call is most suitable for calls of Java methods. Java calls callees can be changed > 1103: // to the interpreter or different versions of a compiled method. Those callees can be This is not true. Trampoline calls are needed for calls to the runtime too. ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From aph at openjdk.java.net Fri May 6 08:08:48 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 6 May 2022 08:08:48 GMT Subject: RFR: 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 22:49:43 GMT, Evgeny Astigeevich wrote: >> `MacroAssembler::trampoline_call` is for generating calls of targets which are inside CodeCache and can have relocInfo types: `runtime_call_type`, `opt_virtual_call_type`, `static_call_type` or `virtual_call_type`. >> This PR updates the description of the function and adds additional asserts. >> Tested a fastdebug build: >> - `gtest`: Passed >> - `tier1`: Passed > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Fix assert message src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1110: > 1108: // far_call does not use the stub code section for additional code. It inserts the code at a call site. > 1109: // This prevents the call from optimization to a direct call when the code is copied to CodeCache. > 1110: // I can't understand any of this. As far as I can tell it is nonsense. It introduces pointless confusing terminology such as "far-distant" and "near-distant". "This prevents the call from optimization to a direct cal" is completely wrongl src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1113: > 1111: // If a mark of the generated call BL is needed, a pointer to CodeBuffer keeping the generated code > 1112: // must be provided. > 1113: // What does "If a mark of the generated call BL is needed" mean? ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From aph at openjdk.java.net Fri May 6 08:11:48 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 6 May 2022 08:11:48 GMT Subject: RFR: 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call [v2] In-Reply-To: References: Message-ID: <0GK2fqUDn_e1Gmsqhx7uePDRo2WN5GbqbAId_SU5_ws=.6f0496a5-48a1-4172-9a3a-4cb973be0c45@github.com> On Thu, 5 May 2022 22:49:43 GMT, Evgeny Astigeevich wrote: >> `MacroAssembler::trampoline_call` is for generating calls of targets which are inside CodeCache and can have relocInfo types: `runtime_call_type`, `opt_virtual_call_type`, `static_call_type` or `virtual_call_type`. >> This PR updates the description of the function and adds additional asserts. >> Tested a fastdebug build: >> - `gtest`: Passed >> - `tier1`: Passed > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Fix assert message This commentary is garbled, misleading, and very confusing. I suspect that anyone confused about how trampoline calls work will be even more confused after trying to read this. Can you please explain what aspects of trampolines you're trying to clarify? Let's have a conversation about how to document this. ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From shade at openjdk.java.net Fri May 6 08:32:46 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 6 May 2022 08:32:46 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12] In-Reply-To: References: <_4VTPOm91qcc5CTKTtIpfdamTSI71FbHHGsBPkykuLo=.efbf169c-c94f-4a86-9f8d-ca2cb76715df@github.com> Message-ID: On Thu, 5 May 2022 18:54:49 GMT, Alan Bateman wrote: > We mailed porters-dev in Sep 2021 to give a heads up that this feature would require porting work so it shouldn't be a surprise. We have been open to including other ports with the initial integration but it was never a goal to have all the ports done in advance of that. It is understandable to ship the preview feature not implemented on all platforms. It is even understandable to ship the final product feature that breaks some platforms in an clearly understandable way, prompting platform maintainers to implement the agreed-upon, final Java feature. What I am seeing, though, is that just running `java -version` (!) after integrating a *preview feature* is broken! > Most of the new code in the VM is only used when running with --enable-preview. You'll see several places that test Continuations::enabled(). It should be possible to get these port running without -enable-preview without much effort. The feature has to be implemented to pass all the tests of course. It is not as clear-cut, unfortunately. I see there are substantial changes in deopt machinery with post-call NOPs -- and there maybe more stuff lurking after that one is implemented -- so it is not as simple as changing `Unimplemented()` to guarding with `Continuations::enabled()`. So this looks to me that the core deopt machinery is affected, whether Loom is enabled or not. Is the impact of that deopt machinery change on the VM stability and VM ports discussed, understood, documented somewhere? I would have honestly expected those core changes to be heavily conditionalized with either `ifdef`-s, or runtime checks, or both, so that both unimplemented platforms had the old behavior *and* the implemented platforms had a fallback to old behavior if preview feature was broken. The current code is fine for experimental Loom repo, but I firmly believe mainline should have much stronger safety/reliability requirements. My fear is that an integration like this would wreck JDK 19 release. So my question stands: Are we breaking those platforms? Are we sure the unconditional VM changes are problem-free, implementable everywhere, etc? The answer might be "Yes, we are integrating, let the chips fall where they may", but I also believe that should be the call made by responsible platform/VM architects, who should explicitly weigh in and accept the risk of wide JDK 19 breakage. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From mcimadamore at openjdk.java.net Fri May 6 08:44:18 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 6 May 2022 08:44:18 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v39] In-Reply-To: References: Message-ID: <388ApXPEDmJfjzRtAEJc2ZgunCC8d6gbBkCsPg5hTlU=.22af8084-2ae4-487b-b6b2-d6c6d9410429@github.com> On Thu, 5 May 2022 21:28:32 GMT, Mandy Chung wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI >> * Tweak restricted method check to work when there's no caller class > > src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 161: > >> 159: ClassLoader.getSystemClassLoader(); >> 160: MemorySession loaderSession = (loader == null) ? >> 161: MemorySession.global() : // boot loader never goes away > > The other built-in class loaders (`ClassLoaders::appClassLoader` and `ClassLoaders::platformClassLoader` are both instance of `BuiltinClassLoader`) will never be unloaded. Should they use the globel memory session? good idea > src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 120: > >> 118: // if there is no caller class, act as if the call came from an unnamed module >> 119: Module module = currentClass != null ? >> 120: currentClass.getModule() : Holder.FALLBACK_MODULE; > > This can be simplified to: > > Module module = currentClass != null ? > currentClass.getModule() : ClassLoader::getSystemClassLoader().getUnnamedModule(); > > > No need to have the Holder class. gah! I missed that :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From jbachorik at openjdk.java.net Fri May 6 08:54:31 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Fri, 6 May 2022 08:54:31 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v5] In-Reply-To: References: Message-ID: > A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. > > Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. > >
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. > However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > >

> > _Note: This is a followup PR for #8061_ Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: Move 'in_asgct' flag to JavaThread ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8549/files - new: https://git.openjdk.java.net/jdk/pull/8549/files/caf43e39..33ac63eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=03-04 Stats: 14 lines in 3 files changed: 7 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8549.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8549/head:pull/8549 PR: https://git.openjdk.java.net/jdk/pull/8549 From jbachorik at openjdk.java.net Fri May 6 08:54:31 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Fri, 6 May 2022 08:54:31 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v2] In-Reply-To: References: <_sH1LiMQP6BKOS86T2wDy8JdhKws6CgOL9WuH7nTEgs=.bdc5626a-09f4-4735-b730-ee13cd169b45@github.com> Message-ID: <8MPK8xoBXqo46Kid6aLCoSB0pSLATvGRcoVnOPlmOmA=.2be3cfd5-3b4c-4c3f-9725-774413f414b4@github.com> On Fri, 6 May 2022 01:30:35 GMT, David Holmes wrote: >> Ok, moved it a bit around - now the bool field is after an int field which should make things slightly better, I guess. > > At the start of JavaThread we have: > > private: > bool _on_thread_list; // Is set when this JavaThread is added to the Threads list > OopHandle _threadObj; // The Java level thread object > > so adding it next to the existing bool seems good. The accessors don't have to be defined at the same place. Ok. Done. This requires an extra check and a static cast to `JavaThread` in `CodeCache::find_blob()` but it should not be that bad. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From jbachorik at openjdk.java.net Fri May 6 08:54:32 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Fri, 6 May 2022 08:54:32 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v3] In-Reply-To: References: Message-ID: <2bq1e0fu0GA9-r2adZq1sy7LszW-Wbg_Cm1LshoALfw=.e78796d9-9769-49f5-ab44-2d6c7c1a6600@github.com> On Fri, 6 May 2022 01:18:21 GMT, David Holmes wrote: >> I will have to do check/cast in `CodeCache::find_blob()` as that may get called from any thread, not just Java threads. >> I would assume that having this flag defined at Thread level is a lesser of the evils - or am I wrong here? > > We have been actively moving JavaThread fields out of Thread. Ok. Moved to `JavaThread`. There is a small cost to pay in `CodeCache::find_blob()` where we need to check if the thread is a `JavaThread` because that function can be called also from non-java threads, AFAIK. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From duke at openjdk.java.net Fri May 6 09:13:48 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Fri, 6 May 2022 09:13:48 GMT Subject: RFR: 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call [v2] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 08:00:22 GMT, Andrew Haley wrote: >> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix assert message > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1103: > >> 1101: // >> 1102: // Trampoline_call is most suitable for calls of Java methods. Java calls callees can be changed >> 1103: // to the interpreter or different versions of a compiled method. Those callees can be > > This is not true. Trampoline calls are needed for calls to the runtime too. Why? What are the cases? This is not clear from sources. ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From jbachorik at openjdk.java.net Fri May 6 09:40:37 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Fri, 6 May 2022 09:40:37 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6] In-Reply-To: References: Message-ID: > A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. > > Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. > >
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. > However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > >

> > _Note: This is a followup PR for #8061_ Jaroslav Bachorik 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: Move 'in_asgct' flag to JavaThread ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8549/files - new: https://git.openjdk.java.net/jdk/pull/8549/files/33ac63eb..949609c8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8549.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8549/head:pull/8549 PR: https://git.openjdk.java.net/jdk/pull/8549 From duke at openjdk.java.net Fri May 6 09:45:49 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Fri, 6 May 2022 09:45:49 GMT Subject: RFR: 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call [v2] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 08:04:25 GMT, Andrew Haley wrote: > "This prevents the call from optimization to a direct cal" is completely wrongl If I am wrong, could you please point me at the place where 'adrp, add, bl' is optimized? > As far as I can tell it is nonsense. Could you please be more constructive? > It introduces pointless confusing terminology such as "far-distant" and "near-distant". Please, offer your variant. There is no standard terminology: - GCC uses: long/short https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/ARM-Function-Attributes.html - TI uses: relative/absolute/far away/near call https://downloads.ti.com/docs/esd/SPNU118/generate-far-call-trampolines-trampolines-option-stdz0755016.html - ARM always calls tramopolines veneers: https://developer.arm.com/documentation/dui0803/d/pge1406301797482 We can use: short/long like GCC. What do you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From alanb at openjdk.java.net Fri May 6 09:51:20 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 6 May 2022 09:51:20 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v13] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 06:48:46 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview). >> >> We will refresh this PR periodically to pick up changes and fixes from the loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Refresh 6ace49bf42e5504c69fa11c564e8e865c0a95fb3 > - Merge with 9425ab2b43b649bd591706bfc820e9c8795a6fdf > - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f > - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5 > - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05 > - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89 > - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a > - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4 > - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec > - Merge with jdk-19+20 > - ... and 11 more: https://git.openjdk.java.net/jdk/compare/9425ab2b...6d968671 > It is understandable to ship the preview feature not implemented on all platforms. It is even understandable to ship the final product feature that breaks some platforms in an clearly understandable way, prompting platform maintainers to implement the agreed-upon, final Java feature. What I am seeing, though, is that just running `java -version` (!) after integrating a _preview feature_ is broken! Preview features need to be implemented by a port before it can be released. For JDK 19 this means that the maintainers of ports will have work to do for both JEP 424 and JEP 425 (ifdef is not an option). I think the issue that are concerned about is the interim period between the JEP 425 integration and the port/implementation of this feature to other architectures. I think the answer is that it will vary. It may be that some port maintainers decide to do something very short term so they can run without --enable-preview and buy time before they do the port/implementation for JDK 19. Good progress has been reported on at least ppc64le port and maybe that port be ready before others. So yes, some ports may crash until they receive attention, others (like zero) should be able to run tests that don't use --enable-preview. I've no doubt there will be a flurry of changes post integration. The motivation for Continuations::enabled() was to reduce risk and disable a lot of the new code by default. The motivation wasn't porting but it may be helpful during the interim period. That is probably a topic for loom-dev rather here. ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From duke at openjdk.java.net Fri May 6 09:56:48 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Fri, 6 May 2022 09:56:48 GMT Subject: RFR: 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call [v2] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 08:05:00 GMT, Andrew Haley wrote: >> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix assert message > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1113: > >> 1111: // If a mark of the generated call BL is needed, a pointer to CodeBuffer keeping the generated code >> 1112: // must be provided. >> 1113: // > > What does "If a mark of the generated call BL is needed" mean? This is what is done in the function: address MacroAssembler::trampoline_call(Address entry, CodeBuffer* cbuf = NULL) { ... if (cbuf) cbuf->set_insts_mark(); relocate(entry.rspec()); if (!far_branches()) { bl(entry.target()); } else { bl(pc()); } And most of the time NULL is passed. I don't know how this code passed review. It smells badly. What written is based on what I see: how the function is used. For example, can `cbuf` be any `CodeBuffer`? If not, how is it connected to the current CodeBuffer? If it is the same, why we pass a pointer but not a flag. ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From duke at openjdk.java.net Fri May 6 10:09:39 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Fri, 6 May 2022 10:09:39 GMT Subject: RFR: 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call [v2] In-Reply-To: <0GK2fqUDn_e1Gmsqhx7uePDRo2WN5GbqbAId_SU5_ws=.6f0496a5-48a1-4172-9a3a-4cb973be0c45@github.com> References: <0GK2fqUDn_e1Gmsqhx7uePDRo2WN5GbqbAId_SU5_ws=.6f0496a5-48a1-4172-9a3a-4cb973be0c45@github.com> Message-ID: <8tycniY0shUiB39KXvDRrsVwZXJzl3if-oIMMTSpagA=.dd03bb92-d186-4bb3-b2d3-ead0ab89fc7a@github.com> On Fri, 6 May 2022 08:08:48 GMT, Andrew Haley wrote: > This commentary is garbled, misleading, and very confusing. Could you please be more neutral in your words? > I suspect that anyone confused about how trampoline calls work will be even more confused after trying to read this. This is why we have the review process to make things better. > Can you please explain what aspects of trampolines you're trying to clarify? Let's have a conversation about how to document this. I am trying to clarify why we have two ways for long calls, pros/cons, which of two can be optimized. This mechanism of long call is very important part but it is not documented. ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From dholmes at openjdk.java.net Fri May 6 10:11:49 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 6 May 2022 10:11:49 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 09:40:37 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. >> >> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. >> >>

>> >> _Note: This is a followup PR for #8061_ > > Jaroslav Bachorik 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: > > Move 'in_asgct' flag to JavaThread Functionally this looks good now - thanks. The only concern is the overhead added to `find_blob` to account for this very special case. Can you do some benchmarking of this? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From ngasson at openjdk.java.net Fri May 6 10:24:41 2022 From: ngasson at openjdk.java.net (Nick Gasson) Date: Fri, 6 May 2022 10:24:41 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 05:47:47 GMT, Jatin Bhateja wrote: >> Hi All, >> >> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) >> >> Following is the brief summary of changes:- >> >> 1) Extends the scope of existing lanewise API for following new vector operations. >> - VectorOperations.BIT_COUNT: counts the number of one-bits >> - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits >> - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits >> - VectorOperations.REVERSE: reversing the order of bits >> - VectorOperations.REVERSE_BYTES: reversing the order of bytes >> - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. >> >> 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. >> - Vector.compress >> - Vector.expand >> - VectorMask.compress >> >> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. >> - Vector.fromMemorySegment >> - Vector.intoMemorySegment >> >> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. >> >> >> Patch has been regressed over AARCH64 and X86 targets different AVX levels. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - 8284960: Correcting a typo. > - 8284960: Integrating changes from panama-vector (Add @since 19 tags). > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - 8284960: AARCH64 backend changes. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - 8284960: Integration of JEP 426: Vector API (Fourth Incubator) `cpu/aarch64` changes look good. ------------- Marked as reviewed by ngasson (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8425 From ngasson at openjdk.java.net Fri May 6 11:39:59 2022 From: ngasson at openjdk.java.net (Nick Gasson) Date: Fri, 6 May 2022 11:39:59 GMT Subject: RFR: 8285923: [REDO] JDK-8285802 AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities In-Reply-To: References: Message-ID: On Thu, 5 May 2022 14:56:38 GMT, Andrew Haley wrote: > It is with some trepidation that I post this after breaking things last time. However, I think I've tested this as much as it can be tested. > > The change from last time around is this: > > > +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp > @@ -2192,11 +2192,13 @@ void MacroAssembler::unimplemented(const char* what) { > > // If a constant does not fit in an immediate field, generate some > // number of MOV instructions and then perform the operation. > -void MacroAssembler::wrap_add_sub_imm_insn(Register Rd, Register Rn, unsigned imm, > +void MacroAssembler::wrap_add_sub_imm_insn(Register Rd, Register Rn, uint64_t imm, > add_sub_imm_insn insn1, > - add_sub_reg_insn insn2) { > + add_sub_reg_insn insn2, > + bool is32) { > assert(Rd != zr, "Rd = zr and not setting flags?"); > - if (operand_valid_for_add_sub_immediate((int)imm)) { > + bool fits = operand_valid_for_add_sub_immediate(is32 ? (int32_t)imm : imm); > + if (fits) { > (this->*insn1)(Rd, Rn, imm); > > > After this patch, when an add/sub instruction has a 32-bit (rather than a 64-bit) operand, we truncate the operand to signed int. We do this because `operand_valid_for_add_sub_immediate()` takes a 64-bit signed operand, but if the instruction is only 32 bits wide we must ignore the upper 32 bits. Therefore, the call site to `wrap_add_sub_imm_insn()` needs to know the operand size in order to sign extend the operand correctly. > > Tested tier1-3, tier4 is still running but no regressions yet. I also ran tier1-3 and didn't see any regressions. src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1178: > 1176: #undef WRAP > 1177: #define WRAP(INSN, is32) \ > 1178: void INSN(Register Rd, Register Rn, uint64_t imm) { \ Align the trailing backslash here and above? ------------- Marked as reviewed by ngasson (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8554 From mcimadamore at openjdk.java.net Fri May 6 11:51:46 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 6 May 2022 11:51:46 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v40] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Add tests for loaderLookup/restricted method corner cases ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/4d24ffa9..b71c4e93 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=39 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=38-39 Stats: 248 lines in 10 files changed: 239 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Fri May 6 11:51:46 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 6 May 2022 11:51:46 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v39] In-Reply-To: <388ApXPEDmJfjzRtAEJc2ZgunCC8d6gbBkCsPg5hTlU=.22af8084-2ae4-487b-b6b2-d6c6d9410429@github.com> References: <388ApXPEDmJfjzRtAEJc2ZgunCC8d6gbBkCsPg5hTlU=.22af8084-2ae4-487b-b6b2-d6c6d9410429@github.com> Message-ID: On Fri, 6 May 2022 08:42:12 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 120: >> >>> 118: // if there is no caller class, act as if the call came from an unnamed module >>> 119: Module module = currentClass != null ? >>> 120: currentClass.getModule() : Holder.FALLBACK_MODULE; >> >> This can be simplified to: >> >> Module module = currentClass != null ? >> currentClass.getModule() : ClassLoader::getSystemClassLoader().getUnnamedModule(); >> >> >> No need to have the Holder class. > > gah! I missed that :-) I've addressed these comments (thanks!) and also added some tests for these corner cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From aph at openjdk.java.net Fri May 6 12:03:27 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 6 May 2022 12:03:27 GMT Subject: RFR: 8285923: [REDO] JDK-8285802 AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities [v2] In-Reply-To: References: Message-ID: <-ci84vmsYRvLR4fGmvP6WStOlHOczgCccpazaPZj3fQ=.f8fbe2f8-6e29-4c95-bc9f-84cc216b348e@github.com> > It is with some trepidation that I post this after breaking things last time. However, I think I've tested this as much as it can be tested. > > The change from last time around is this: > > > +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp > @@ -2192,11 +2192,13 @@ void MacroAssembler::unimplemented(const char* what) { > > // If a constant does not fit in an immediate field, generate some > // number of MOV instructions and then perform the operation. > -void MacroAssembler::wrap_add_sub_imm_insn(Register Rd, Register Rn, unsigned imm, > +void MacroAssembler::wrap_add_sub_imm_insn(Register Rd, Register Rn, uint64_t imm, > add_sub_imm_insn insn1, > - add_sub_reg_insn insn2) { > + add_sub_reg_insn insn2, > + bool is32) { > assert(Rd != zr, "Rd = zr and not setting flags?"); > - if (operand_valid_for_add_sub_immediate((int)imm)) { > + bool fits = operand_valid_for_add_sub_immediate(is32 ? (int32_t)imm : imm); > + if (fits) { > (this->*insn1)(Rd, Rn, imm); > > > After this patch, when an add/sub instruction has a 32-bit (rather than a 64-bit) operand, we truncate the operand to signed int. We do this because `operand_valid_for_add_sub_immediate()` takes a 64-bit signed operand, but if the instruction is only 32 bits wide we must ignore the upper 32 bits. Therefore, the call site to `wrap_add_sub_imm_insn()` needs to know the operand size in order to sign extend the operand correctly. > > Tested tier1-3, tier4 is still running but no regressions yet. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: 8285923: [REDO] JDK-8285802 AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8554/files - new: https://git.openjdk.java.net/jdk/pull/8554/files/2613c9bd..cf1e926a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8554&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8554&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8554.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8554/head:pull/8554 PR: https://git.openjdk.java.net/jdk/pull/8554 From aph at openjdk.java.net Fri May 6 12:03:27 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 6 May 2022 12:03:27 GMT Subject: RFR: 8285923: [REDO] JDK-8285802 AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities [v2] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 11:34:54 GMT, Nick Gasson wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> 8285923: [REDO] JDK-8285802 AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1178: > >> 1176: #undef WRAP >> 1177: #define WRAP(INSN, is32) \ >> 1178: void INSN(Register Rd, Register Rn, uint64_t imm) { \ > > Align the trailing backslash here and above? Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/8554 From aph at openjdk.java.net Fri May 6 12:44:43 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 6 May 2022 12:44:43 GMT Subject: RFR: 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 22:49:43 GMT, Evgeny Astigeevich wrote: >> `MacroAssembler::trampoline_call` is for generating calls of targets which are inside CodeCache and can have relocInfo types: `runtime_call_type`, `opt_virtual_call_type`, `static_call_type` or `virtual_call_type`. >> This PR updates the description of the function and adds additional asserts. >> Tested a fastdebug build: >> - `gtest`: Passed >> - `tier1`: Passed > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Fix assert message On 5/6/22 10:42, Evgeny Astigeevich wrote: > ***@***.**** commented on this pull request. > > -------- > > In src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp : > >> + // If the distance to the address can exceed the branch range > + // (128M for the release build, 2M for the debug build; see branch_range definition) > + // for direct calls(BL), a special code with BR (trampoline) is put in the stub code section. > + // The call is redirected to it. When CodeBuffer is copied to CodeCache, the distance to > + // callee's address is checked to bypass the trampoline by replacing the call of the trampoline > + // with the call of the target. > + // > + // Trampoline_call is most suitable for calls of Java methods. Java calls callees can be changed > + // to the interpreter or different versions of a compiled method. Those callees can be > + // near-distant or far-distant. Trampoline_call supports switching between near-distant callees > + // and far-distant callees by having a reserved trampoline. The trampoline is only used if needed. > + // > + // The code for runtime calls can also be generated with far_call. For possible far-distant callees > + // far_call does not use the stub code section for additional code. It inserts the code at a call site. > + // This prevents the call from optimization to a direct call when the code is copied to CodeCache. > + // > > "This prevents the call from optimization to a direct cal" is completely wrongl > > If I am wrong, could you please point me at the place where 'adrp, add, bl' is optimized? Ah, I think I see. Are you saying that a far call is not converted to a direct call when the code is moved into the code cache, even if a direct call might reach its target? And that far calls do not need a trampoline. OK. > As far as I can tell it is nonsense. > > Could you please be more constructive? I did not understand what you were saying. And I wrote all of the code you're trying to describe. > It introduces pointless confusing terminology such as "far-distant" and "near-distant". > > Please, offer your variant. There is no standard terminology: The names we already use are direct call, far call, and trampoline call. Direct calls can reach +/- 128M, so unless our code cache is < 128M we can't always use them. Far calls have a range of 4G, so can be reach anything in the code cache, but not C++ code in a shared library. Trampoline calls can reach anywhere in the address space. When we're generating code in C2, we can always generate a trampoline, and trampolines can reach anywhere. Outside C2 we may not have a stub section so we can't generate a trampoline. However, we can generate a far call, which can reach anywhere in the code cache, but not the entire address space. When patching code at runtime we are restricted by the rules in the Arm ARM. We can replace a call with another call, but we can't, for example, replace an ADRP with a CALL, or a CALL with an ADRP. ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From aph-open at littlepinkcloud.com Fri May 6 12:51:28 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Fri, 6 May 2022 13:51:28 +0100 Subject: RFR: 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call [v2] In-Reply-To: <8tycniY0shUiB39KXvDRrsVwZXJzl3if-oIMMTSpagA=.dd03bb92-d186-4bb3-b2d3-ead0ab89fc7a@github.com> References: <0GK2fqUDn_e1Gmsqhx7uePDRo2WN5GbqbAId_SU5_ws=.6f0496a5-48a1-4172-9a3a-4cb973be0c45@github.com> <8tycniY0shUiB39KXvDRrsVwZXJzl3if-oIMMTSpagA=.dd03bb92-d186-4bb3-b2d3-ead0ab89fc7a@github.com> Message-ID: <872611ea-23f2-bbfe-996b-d4624cf1760a@littlepinkcloud.com> On 5/6/22 11:09, Evgeny Astigeevich wrote: > On Fri, 6 May 2022 08:08:48 GMT, Andrew Haley wrote: > >> Can you please explain what aspects of trampolines you're trying to clarify? Let's have a conversation about how to document this. > > I am trying to clarify why we have two ways for long calls, pros/cons, which of two can be optimized. This mechanism of long call is very important part but it is not documented. OK. Please see my other response, which explains the details of how and why the three types of calls are used. If there's anything missing from there please ask, and I'll explain more. From tschatzl at openjdk.java.net Fri May 6 12:59:17 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 6 May 2022 12:59:17 GMT Subject: RFR: 8286285: Rank issues with ParGCRareEvent_lock and Threads_lock Message-ID: Hi all, can I have reviews for this change that fixes up the rank of the `ParGCRareEvent_lock` lock? It might be called in the vm-thread that holds the `Threads_lock` during (single-threaded) verification. Testing: gha, local testing inducing uses of `ParGCRareEvent_lock` in the VM thread Thanks, Thomas ------------- Commit messages: - initial changes Changes: https://git.openjdk.java.net/jdk/pull/8573/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8573&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286285 Stats: 7 lines in 2 files changed: 2 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8573.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8573/head:pull/8573 PR: https://git.openjdk.java.net/jdk/pull/8573 From jbachorik at openjdk.java.net Fri May 6 14:23:51 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Fri, 6 May 2022 14:23:51 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6] In-Reply-To: References: Message-ID: <8VU_enlG3aCFUT3veoiW0n8n5OiM5vskYL0QJsbo1V0=.c786d6f7-8ce2-4f1e-938c-b7fefbca65d9@github.com> On Fri, 6 May 2022 10:08:09 GMT, David Holmes wrote: >> Jaroslav Bachorik 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: >> >> Move 'in_asgct' flag to JavaThread > > Functionally this looks good now - thanks. > > The only concern is the overhead added to `find_blob` to account for this very special case. Can you do some benchmarking of this? > > Thanks. Hi @dholmes-ora , thanks for taking time to review this. I am running `jmh-jdk-microbenchmarks` now but I am going to be away for a week now so I will get back to you with the results only then. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From psandoz at openjdk.java.net Fri May 6 15:02:53 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 6 May 2022 15:02:53 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v3] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 04:49:39 GMT, Xiaohong Gong wrote: >> offset is long so uses two argument slots (5 and 6). >> mask is argument (7). >> offsetInRange is argument(8). > > Make sense! Thanks for the explanation! Doh! of course. This is not the first and will not be the last time i get caught out by the 2-slot requirement. It may be useful to do this: Node* mask_arg = is_store ? argument(8) : argument(7); ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From duke at openjdk.java.net Fri May 6 16:00:59 2022 From: duke at openjdk.java.net (ExE Boss) Date: Fri, 6 May 2022 16:00:59 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v40] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 11:51:46 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add tests for loaderLookup/restricted method corner cases src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 116: > 114: // if there is no caller class, act as if the call came from unnamed module of system class loader > 115: Module module = currentClass != null ? > 116: currentClass.getModule() : ClassLoader.getSystemClassLoader().getUnnamedModule(); **Nit:** maybe?add a?line?break Suggestion: currentClass.getModule() : ClassLoader.getSystemClassLoader().getUnnamedModule(); ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From kvn at openjdk.java.net Fri May 6 16:34:54 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 6 May 2022 16:34:54 GMT Subject: RFR: 8285923: [REDO] JDK-8285802 AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities [v2] In-Reply-To: <-ci84vmsYRvLR4fGmvP6WStOlHOczgCccpazaPZj3fQ=.f8fbe2f8-6e29-4c95-bc9f-84cc216b348e@github.com> References: <-ci84vmsYRvLR4fGmvP6WStOlHOczgCccpazaPZj3fQ=.f8fbe2f8-6e29-4c95-bc9f-84cc216b348e@github.com> Message-ID: <_E1t40GCDGoDM7qIFVHTfr4bsGqn-hAeYKs6YE9CP-g=.3689ad0d-e450-41d4-94a1-971b860b21ec@github.com> On Fri, 6 May 2022 12:03:27 GMT, Andrew Haley wrote: >> It is with some trepidation that I post this after breaking things last time. However, I think I've tested this as much as it can be tested. >> >> The change from last time around is this: >> >> >> +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp >> @@ -2192,11 +2192,13 @@ void MacroAssembler::unimplemented(const char* what) { >> >> // If a constant does not fit in an immediate field, generate some >> // number of MOV instructions and then perform the operation. >> -void MacroAssembler::wrap_add_sub_imm_insn(Register Rd, Register Rn, unsigned imm, >> +void MacroAssembler::wrap_add_sub_imm_insn(Register Rd, Register Rn, uint64_t imm, >> add_sub_imm_insn insn1, >> - add_sub_reg_insn insn2) { >> + add_sub_reg_insn insn2, >> + bool is32) { >> assert(Rd != zr, "Rd = zr and not setting flags?"); >> - if (operand_valid_for_add_sub_immediate((int)imm)) { >> + bool fits = operand_valid_for_add_sub_immediate(is32 ? (int32_t)imm : imm); >> + if (fits) { >> (this->*insn1)(Rd, Rn, imm); >> >> >> After this patch, when an add/sub instruction has a 32-bit (rather than a 64-bit) operand, we truncate the operand to signed int. We do this because `operand_valid_for_add_sub_immediate()` takes a 64-bit signed operand, but if the instruction is only 32 bits wide we must ignore the upper 32 bits. Therefore, the call site to `wrap_add_sub_imm_insn()` needs to know the operand size in order to sign extend the operand correctly. >> >> Tested tier1-3, tier4 is still running but no regressions yet. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > 8285923: [REDO] JDK-8285802 AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities Looks reasonable. Dan is running our testing. Please, wait results from him. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8554 From mcimadamore at openjdk.java.net Fri May 6 16:48:11 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 6 May 2022 16:48:11 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v41] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/b71c4e93..f823bf84 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=40 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=39-40 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mchung at openjdk.java.net Fri May 6 16:55:12 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 6 May 2022 16:55:12 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v41] In-Reply-To: References: Message-ID: <0liX9cVSEjplWxVgGoM5rN2JZLqN27jSsNxjbucze_o=.fbc3a8fa-acdf-45f4-a717-0fbaa13760d2@github.com> On Fri, 6 May 2022 16:48:11 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From zgu at openjdk.java.net Fri May 6 18:02:02 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 6 May 2022 18:02:02 GMT Subject: RFR: 8286331: jni_GetStringUTFChars() uses wrong heap allocator Message-ID: jni_GetStringUTFChars() calls `AllocateHeap(length + 1, mtInternal, 0, AllocFailStrategy::RETURN_NULL);` to allocate memory, where it passes `0` as `NativeCallStack` reference, that results construction of `NativeCallStack`. In `NativeCallStack`'s constructor, it performs stack walk to capture native call stack. This is unnecessary, if NMT detail tracking is not enabled. It should use `char* AllocateHeap(size_t size, MEMFLAGS flags, AllocFailType alloc_failmode /* = AllocFailStrategy::EXIT_OOM*/)` heap allocator instead. ------------- Commit messages: - v0 Changes: https://git.openjdk.java.net/jdk/pull/8579/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8579&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286331 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8579.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8579/head:pull/8579 PR: https://git.openjdk.java.net/jdk/pull/8579 From lkorinth at openjdk.java.net Fri May 6 18:17:36 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Fri, 6 May 2022 18:17:36 GMT Subject: RFR: 8281297: TestStressG1Humongous fails with guarantee(is_range_uncommitted) In-Reply-To: References: Message-ID: On Thu, 5 May 2022 17:37:35 GMT, Leo Korinth wrote: > TestStressG1Humongous passes 200 times with this change. I have started a new windows run with 1000 iterations. Without the fix the testcase will usually fail a few times when iterating 100 times. I have also started a tier 1-3 run. I will revert it in a separate pull request (https://github.com/openjdk/jdk/pull/8580). That pull request will be a clean `git revert` rebased on this fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/8560 From dlong at openjdk.java.net Fri May 6 20:21:46 2022 From: dlong at openjdk.java.net (Dean Long) Date: Fri, 6 May 2022 20:21:46 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 09:40:37 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. >> >> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. >> >>

>> >> _Note: This is a followup PR for #8061_ > > Jaroslav Bachorik 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: > > Move 'in_asgct' flag to JavaThread It seems like you should be able to mitigate the extra overhead by only doing that extra work when we actually see a zombie method, which should be rare. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From dlong at openjdk.java.net Fri May 6 20:49:55 2022 From: dlong at openjdk.java.net (Dean Long) Date: Fri, 6 May 2022 20:49:55 GMT Subject: RFR: 8286331: jni_GetStringUTFChars() uses wrong heap allocator In-Reply-To: References: Message-ID: On Fri, 6 May 2022 17:54:45 GMT, Zhengyu Gu wrote: > jni_GetStringUTFChars() calls `AllocateHeap(length + 1, mtInternal, 0, AllocFailStrategy::RETURN_NULL);` to allocate memory, where it passes `0` as `NativeCallStack` reference, that results construction of `NativeCallStack`. > > In `NativeCallStack`'s constructor, it performs stack walk to capture native call stack. This is unnecessary, if NMT detail tracking is not enabled. > > It should use `char* AllocateHeap(size_t size, > MEMFLAGS flags, > AllocFailType alloc_failmode /* = AllocFailStrategy::EXIT_OOM*/)` heap allocator instead. The changes looks correct, but I don't think it will give the desired behavior. It looks like there is a bug in the 3-parameter version of AllocateHeap where it ignores the alloc_failmode argument. You will need to fix that too for your change to work correctly. Try forcing an allocation failure and verify that it returns NULL instead of exiting with OOM. ------------- Changes requested by dlong (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8579 From zgu at openjdk.java.net Fri May 6 22:28:50 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 6 May 2022 22:28:50 GMT Subject: RFR: 8286331: jni_GetStringUTFChars() uses wrong heap allocator In-Reply-To: References: Message-ID: On Fri, 6 May 2022 17:54:45 GMT, Zhengyu Gu wrote: > jni_GetStringUTFChars() calls `AllocateHeap(length + 1, mtInternal, 0, AllocFailStrategy::RETURN_NULL);` to allocate memory, where it passes `0` as `NativeCallStack` reference, that results construction of `NativeCallStack`. > > In `NativeCallStack`'s constructor, it performs stack walk to capture native call stack. This is unnecessary, if NMT detail tracking is not enabled. > > It should use `char* AllocateHeap(size_t size, > MEMFLAGS flags, > AllocFailType alloc_failmode /* = AllocFailStrategy::EXIT_OOM*/)` heap allocator instead. > You are right, filed [JDK-8286346](https://bugs.openjdk.java.net/browse/JDK-8286346). ------------- PR: https://git.openjdk.java.net/jdk/pull/8579 From dholmes at openjdk.java.net Fri May 6 23:14:39 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 6 May 2022 23:14:39 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 20:17:53 GMT, Dean Long wrote: >> Jaroslav Bachorik 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: >> >> Move 'in_asgct' flag to JavaThread > > It seems like you should be able to mitigate the extra overhead by only doing that extra work when we actually see a zombie method, which should be rare. Yes good point @dean-long ! Check for the zombie first and only then do the expensive Thread::current_or_null_safe() etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From dholmes at openjdk.java.net Fri May 6 23:22:52 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 6 May 2022 23:22:52 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 09:40:37 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. >> >> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. >> >>

>> >> _Note: This is a followup PR for #8061_ > > Jaroslav Bachorik 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: > > Move 'in_asgct' flag to JavaThread Looking more closely this even be put in a new final clause in the guarantee: guarantee(result == NULL || !result->is_zombie() || result->is_locked_by_vm() || VMError::is_error_reported() || result->is_zombie() && current_thread_in_asgct() , "unsafe access to zombie method"); where `current_thread_in_asgct()` is a static helper. That addresses all overhead concerns. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From dlong at openjdk.java.net Sat May 7 00:09:46 2022 From: dlong at openjdk.java.net (Dean Long) Date: Sat, 7 May 2022 00:09:46 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 09:40:37 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. >> >> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. >> >>

>> >> _Note: This is a followup PR for #8061_ > > Jaroslav Bachorik 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: > > Move 'in_asgct' flag to JavaThread David, your example has an extra || result->is_zombie(), but otherwise this sounds perfect. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From xgong at openjdk.java.net Sat May 7 01:49:40 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Sat, 7 May 2022 01:49:40 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v3] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 14:59:26 GMT, Paul Sandoz wrote: >> Make sense! Thanks for the explanation! > > Doh! of course. This is not the first and will not be the last time i get caught out by the 2-slot requirement. > It may be useful to do this: > > Node* mask_arg = is_store ? argument(8) : argument(7); Yes, the mask argument is got like: Node* mask = unbox_vector(is_store ? argument(8) : argument(7), mbox_type, elem_bt, num_elem); ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From dholmes at openjdk.java.net Sat May 7 02:11:44 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 7 May 2022 02:11:44 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 09:40:37 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. >> >> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. >> >>

>> >> _Note: This is a followup PR for #8061_ > > Jaroslav Bachorik 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: > > Move 'in_asgct' flag to JavaThread Good catch! ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From egahlin at openjdk.java.net Sat May 7 02:38:22 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Sat, 7 May 2022 02:38:22 GMT Subject: RFR: 8282420: JFR: Remove event handlers [v2] In-Reply-To: References: Message-ID: > Hi, > > Could I have a review of a fix that removes event handler classes for JFR. Bytecode for event instrumentation is now only added to the event class. Benefits are: > > - No class memory leak in the boot class loader. > - Reduce overhead from class loading during startup, which is important with additional JDK events that are coming (VirtualThreadStart etc.) > - One less frame to traverse when recording a Java stack trace. > > Future benefits are: > > - Simplify creating instrumentation as a build step. See https://bugs.openjdk.java.net/browse/JDK-8279354 > - Simplify implementation of Event Metrics. See https://bugs.openjdk.java.net/browse/JDK-8224749 > > When the Security Manager is removed, much of the code being added for security reasons can be deleted. > > There are few JFR hooks when code is being linked. Plan is to also use these for other events later. > > Testing: tier 1-4, jdk/jdk/jfr > > Thanks > Erik Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: Cleanups ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8383/files - new: https://git.openjdk.java.net/jdk/pull/8383/files/28de553d..3e4d9068 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=00-01 Stats: 124 lines in 12 files changed: 11 ins; 50 del; 63 mod Patch: https://git.openjdk.java.net/jdk/pull/8383.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8383/head:pull/8383 PR: https://git.openjdk.java.net/jdk/pull/8383 From egahlin at openjdk.java.net Sat May 7 02:38:23 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Sat, 7 May 2022 02:38:23 GMT Subject: RFR: 8282420: JFR: Remove event handlers [v2] In-Reply-To: <_5I-X5S5yMBx0VCDRirEt6UlBqqgWFU9VcF-jDDIejM=.f250a9e7-ce30-4a8a-b641-8978a2df7735@github.com> References: <_5I-X5S5yMBx0VCDRirEt6UlBqqgWFU9VcF-jDDIejM=.f250a9e7-ce30-4a8a-b641-8978a2df7735@github.com> Message-ID: On Thu, 5 May 2022 07:05:07 GMT, Jaroslav Bachorik wrote: >> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanups > > src/hotspot/share/jfr/instrumentation/jfrResolution.hpp line 41: > >> 39: static void on_resolution(const CallInfo & info, TRAPS); >> 40: static void on_resolution(const Parse * parse, const ciKlass * holder, const ciMethod * target); >> 41: static void on_resolution(const GraphBuilder * builder, const ciKlass * holder, const ciMethod * target); > > Could you add brief comments as when will each callback be called? > Eg. the second form is called from C1 and the third form is called from C2 (assuming based on what I see in the cpp file)? Renamed the methods to on_runtime_resolution, on_c1_resolution and on_c2_resolution to make it clearer. I hope this is sufficient. > src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 92: > >> 90: >> 91: public boolean isString() { >> 92: return ASMToolkit.TYPE_STRING.getDescriptor().equals(fieldDescriptor); > > If this is to be called often it might be beneficial to cache the descriptor instead of recreating it each time. Turns out this method is not needed, so I removed it. I also changed the classes FieldInfo and SettingInfo into record classes and while at it, I also made EventInstrumentation (shallow) immutable so guardEventConfiguration is now passed in the constructor. ------------- PR: https://git.openjdk.java.net/jdk/pull/8383 From egahlin at openjdk.java.net Sat May 7 02:49:41 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Sat, 7 May 2022 02:49:41 GMT Subject: RFR: 8282420: JFR: Remove event handlers [v2] In-Reply-To: <_5I-X5S5yMBx0VCDRirEt6UlBqqgWFU9VcF-jDDIejM=.f250a9e7-ce30-4a8a-b641-8978a2df7735@github.com> References: <_5I-X5S5yMBx0VCDRirEt6UlBqqgWFU9VcF-jDDIejM=.f250a9e7-ce30-4a8a-b641-8978a2df7735@github.com> Message-ID: <4bA2dwkR9Pkvu8toW69vI9Z4tEEg1wyDbXwZ5uw57Q8=.cacb7815-d439-48d0-898b-e44fb7cf442c@github.com> On Thu, 5 May 2022 09:36:27 GMT, Jaroslav Bachorik wrote: >> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanups > > src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformEventType.java line 109: > >> 107: } >> 108: } >> 109: return 3; > > Why is the default stack trace offset changed? Previously the stack looked like this: UserEvent::commit() { UserEventHandler::write(startTime, duration ...); EventWriter::puStackTrace(); JVM::getStackTraceId(4); Now it looks like this: UserEvent::commit() { EventWriter::puStackTrace(); JVM::getStackTraceId(3); The branches isUsingConfiguration() and isExceptionEvent() are not affected because they used the EventHandler directly previously. ------------- PR: https://git.openjdk.java.net/jdk/pull/8383 From egahlin at openjdk.java.net Sat May 7 03:02:39 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Sat, 7 May 2022 03:02:39 GMT Subject: RFR: 8282420: JFR: Remove event handlers [v2] In-Reply-To: <_5I-X5S5yMBx0VCDRirEt6UlBqqgWFU9VcF-jDDIejM=.f250a9e7-ce30-4a8a-b641-8978a2df7735@github.com> References: <_5I-X5S5yMBx0VCDRirEt6UlBqqgWFU9VcF-jDDIejM=.f250a9e7-ce30-4a8a-b641-8978a2df7735@github.com> Message-ID: On Thu, 5 May 2022 09:20:09 GMT, Jaroslav Bachorik wrote: >> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanups > > src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java line 139: > >> 137: this.settingInfos = buildSettingInfos(superClass, classNode); >> 138: this.fieldInfos = buildFieldInfos(superClass, classNode); >> 139: String n = annotationValue(classNode, ANNOTATION_TYPE_NAME.getDescriptor(), String.class); > > As well - the descriptor could be cached to avoid calling substring operations repeatedly. Changed from Type to String in some places to reduce allocation. More could be done with the Method descriptor, but I didn't want to go overboard. If needed, I rather handle it separately. ------------- PR: https://git.openjdk.java.net/jdk/pull/8383 From egahlin at openjdk.java.net Sat May 7 03:14:06 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Sat, 7 May 2022 03:14:06 GMT Subject: RFR: 8282420: JFR: Remove event handlers [v3] In-Reply-To: References: Message-ID: > Hi, > > Could I have a review of a fix that removes event handler classes for JFR. Bytecode for event instrumentation is now only added to the event class. Benefits are: > > - No class memory leak in the boot class loader. > - Reduce overhead from class loading during startup, which is important with additional JDK events that are coming (VirtualThreadStart etc.) > - One less frame to traverse when recording a Java stack trace. > > Future benefits are: > > - Simplify creating instrumentation as a build step. See https://bugs.openjdk.java.net/browse/JDK-8279354 > - Simplify implementation of Event Metrics. See https://bugs.openjdk.java.net/browse/JDK-8224749 > > When the Security Manager is removed, much of the code being added for security reasons can be deleted. > > There are few JFR hooks when code is being linked. Plan is to also use these for other events later. > > Testing: tier 1-4, jdk/jdk/jfr > > Thanks > Erik Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: Typos in cleanups ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8383/files - new: https://git.openjdk.java.net/jdk/pull/8383/files/3e4d9068..81989dd6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=01-02 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8383.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8383/head:pull/8383 PR: https://git.openjdk.java.net/jdk/pull/8383 From stuefe at openjdk.java.net Sat May 7 03:46:45 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 7 May 2022 03:46:45 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6] In-Reply-To: <8VU_enlG3aCFUT3veoiW0n8n5OiM5vskYL0QJsbo1V0=.c786d6f7-8ce2-4f1e-938c-b7fefbca65d9@github.com> References: <8VU_enlG3aCFUT3veoiW0n8n5OiM5vskYL0QJsbo1V0=.c786d6f7-8ce2-4f1e-938c-b7fefbca65d9@github.com> Message-ID: On Fri, 6 May 2022 14:20:30 GMT, Jaroslav Bachorik wrote: >> Functionally this looks good now - thanks. >> >> The only concern is the overhead added to `find_blob` to account for this very special case. Can you do some benchmarking of this? >> >> Thanks. > > Hi @dholmes-ora , thanks for taking time to review this. > > I am running `jmh-jdk-microbenchmarks` now but I am going to be away for a week now so I will get back to you with the results only then. Hi @jbachorik, thanks a lot for taking my suggestion. This looks way less intrusive now! ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From stuefe at openjdk.java.net Sat May 7 05:02:35 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 7 May 2022 05:02:35 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6] In-Reply-To: References: Message-ID: <6ikleowciR73wkChDKRAhEgUEuHH1ZtFXze7VjptS3Q=.29ab42a4-4926-420c-8ce8-8ed2db7ec8db@github.com> On Fri, 6 May 2022 09:40:37 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. >> >> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. >> >>

>> >> _Note: This is a followup PR for #8061_ > > Jaroslav Bachorik 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: > > Move 'in_asgct' flag to JavaThread src/hotspot/share/prims/forte.cpp line 594: > 592: } > 593: > 594: thread->set_in_asgct(true); Suggestion: Use a small RAII Mark object instead. That way you prevent future errors if someone should add a return in the mids of AGCT. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From alanb at openjdk.java.net Sat May 7 06:04:51 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 7 May 2022 06:04:51 GMT Subject: RFR: 8284161: Implementation of Virtual Threads (Preview) [v14] In-Reply-To: References: Message-ID: <3Qd4HYCpL8oQztouBMiY7c_7lMBS16X23WTpP65FIzk=.6e4209ba-ce7f-4049-807b-5b6b6ad459ff@github.com> > This is the implementation of JEP 425: Virtual Threads (Preview). > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - Refresh 4e99b5185eef9398c4cc4e90544de4a3153d61a9 - Merge with 5212535a276a92d96ca20bdcfccfbce956febdb1 - Refresh 6ace49bf42e5504c69fa11c564e8e865c0a95fb3 - Merge with 9425ab2b43b649bd591706bfc820e9c8795a6fdf - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5 - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05 - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89 - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/5212535a...df43e6fc ------------- Changes: https://git.openjdk.java.net/jdk/pull/8166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8166&range=13 Stats: 99468 lines in 1133 files changed: 91198 ins; 3598 del; 4672 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166 From alanb at openjdk.java.net Sat May 7 08:09:45 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 7 May 2022 08:09:45 GMT Subject: Integrated: 8284161: Implementation of Virtual Threads (Preview) In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman wrote: > This is the implementation of JEP 425: Virtual Threads (Preview). > > We will refresh this PR periodically to pick up changes and fixes from the loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for zero and some of the other ports. Additional ports can be contributed via PRs against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels have been trimmed down for now to hotspot, serviceability and core-libs. We can add additional labels, if required, as the PR progresses. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from Doug Lea's CVS. These changes will probably be proposed and integrated in advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to make life a bit easier and avoid having to separate VM changes and juggle branches at this time. This pull request has now been integrated. Changeset: 9583e365 Author: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/9583e3657e43cc1c6f2101a64534564db2a9bd84 Stats: 99468 lines in 1133 files changed: 91198 ins; 3598 del; 4672 mod 8284161: Implementation of Virtual Threads (Preview) Co-authored-by: Ron Pressler Co-authored-by: Alan Bateman Co-authored-by: Erik ?sterlund Co-authored-by: Andrew Haley Co-authored-by: Rickard B?ckman Co-authored-by: Markus Gr?nlund Co-authored-by: Leonid Mesnik Co-authored-by: Serguei Spitsyn Co-authored-by: Chris Plummer Co-authored-by: Coleen Phillimore Co-authored-by: Robbin Ehn Co-authored-by: Stefan Karlsson Co-authored-by: Thomas Schatzl Co-authored-by: Sergey Kuksenko Reviewed-by: lancea, eosterlund, rehn, sspitsyn, stefank, tschatzl, dfuchs, lmesnik, dcubed, kevinw, amenkov, dlong, mchung, psandoz, bpb, coleenp, smarks, egahlin, mseledtsov, coffeys, darcy ------------- PR: https://git.openjdk.java.net/jdk/pull/8166 From jvernee at openjdk.java.net Sat May 7 12:51:12 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Sat, 7 May 2022 12:51:12 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v4] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits: - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 - Merge branch 'master' into JEP-19-VM-IMPL2 - 8284161: Implementation of Virtual Threads (Preview) Co-authored-by: Ron Pressler Co-authored-by: Alan Bateman Co-authored-by: Erik ?sterlund Co-authored-by: Andrew Haley Co-authored-by: Rickard B?ckman Co-authored-by: Markus Gr?nlund Co-authored-by: Leonid Mesnik Co-authored-by: Serguei Spitsyn Co-authored-by: Chris Plummer Co-authored-by: Coleen Phillimore Co-authored-by: Robbin Ehn Co-authored-by: Stefan Karlsson Co-authored-by: Thomas Schatzl Co-authored-by: Sergey Kuksenko Reviewed-by: lancea, eosterlund, rehn, sspitsyn, stefank, tschatzl, dfuchs, lmesnik, dcubed, kevinw, amenkov, dlong, mchung, psandoz, bpb, coleenp, smarks, egahlin, mseledtsov, coffeys, darcy - 8282218: C1: Missing side effects of dynamic class loading during constant linkage Reviewed-by: thartmann, kvn - 8286342: ProblemList compiler/c2/irTests/TestEnumFinalFold.java Reviewed-by: mikael - 8286263: compiler/c1/TestPinnedIntrinsics.java failed with "RuntimeException: testCurrentTimeMillis failed with -3" Reviewed-by: thartmann, kvn - 8285295: Need better testing for IdentityHashMap Reviewed-by: jpai, lancea - 8286190: Add test to verify constant folding for Enum fields Reviewed-by: kvn, thartmann - 8286154: Fix 3rd party notices in test files Reviewed-by: darcy, joehw, iris - 8286291: G1: Remove unused segment allocator printouts Reviewed-by: ayang, iwalulya - ... and 80 more: https://git.openjdk.java.net/jdk/compare/f823bf84...5cef96f7 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7959/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=03 Stats: 117182 lines in 1482 files changed: 100895 ins; 8432 del; 7855 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Sat May 7 12:59:05 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Sat, 7 May 2022 12:59:05 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v5] In-Reply-To: References: Message-ID: <0jKvCItLYrueCki_LnvoP5uRXjLF-a2M5qW6l1Mjpo4=.be3b10da-1c4d-4c41-95db-252ab28ee897@github.com> > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Revert "Merge branch 'master' into JEP-19-VM-IMPL2" This reverts commit 98864b62749f3a482dbb0516a987f38904142042, reversing changes made to a7b9f131c4cc5fbec81811941e5c3e164838a88d. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/5cef96f7..f195789f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=03-04 Stats: 332953 lines in 4896 files changed: 22818 ins; 256179 del; 53956 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Sat May 7 13:05:38 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Sat, 7 May 2022 13:05:38 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v6] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee 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 20 new commits since the last revision: - Remove unneeded ComputeMoveOrder - Remove comment about native calls in lcm.cpp - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 Reviewed-by: jvernee, mcimadamore - Update riscv and arm stubs - Remove spurious ProblemList change - Pass pointer to LogStream - Polish - Replace TraceNativeInvokers flag with unified logging - Fix other platforms, take 2 - Fix other platforms - ... and 10 more: https://git.openjdk.java.net/jdk/compare/f195789f...e84e3379 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/f195789f..e84e3379 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=04-05 Stats: 222764 lines in 3783 files changed: 157991 ins; 17628 del; 47145 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Sat May 7 13:05:45 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Sat, 7 May 2022 13:05:45 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v4] In-Reply-To: References: Message-ID: On Sat, 7 May 2022 12:51:12 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20. >> >> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. >> >> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: >> >> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. >> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. >> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). >> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. >> >> While the patch mostly consists of VM changes, there are also some Java changes to support (2). >> >> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. >> >> Testing: Tier1-4 >> >> Thanks, >> Jorn >> >> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 >> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 >> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 >> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 >> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 >> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a >> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 >> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f >> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits: > > - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 > - Merge branch 'master' into JEP-19-VM-IMPL2 > - 8284161: Implementation of Virtual Threads (Preview) > > Co-authored-by: Ron Pressler > Co-authored-by: Alan Bateman > Co-authored-by: Erik ?sterlund > Co-authored-by: Andrew Haley > Co-authored-by: Rickard B?ckman > Co-authored-by: Markus Gr?nlund > Co-authored-by: Leonid Mesnik > Co-authored-by: Serguei Spitsyn > Co-authored-by: Chris Plummer > Co-authored-by: Coleen Phillimore > Co-authored-by: Robbin Ehn > Co-authored-by: Stefan Karlsson > Co-authored-by: Thomas Schatzl > Co-authored-by: Sergey Kuksenko > Reviewed-by: lancea, eosterlund, rehn, sspitsyn, stefank, tschatzl, dfuchs, lmesnik, dcubed, kevinw, amenkov, dlong, mchung, psandoz, bpb, coleenp, smarks, egahlin, mseledtsov, coffeys, darcy > - 8282218: C1: Missing side effects of dynamic class loading during constant linkage > > Reviewed-by: thartmann, kvn > - 8286342: ProblemList compiler/c2/irTests/TestEnumFinalFold.java > > Reviewed-by: mikael > - 8286263: compiler/c1/TestPinnedIntrinsics.java failed with "RuntimeException: testCurrentTimeMillis failed with -3" > > Reviewed-by: thartmann, kvn > - 8285295: Need better testing for IdentityHashMap > > Reviewed-by: jpai, lancea > - 8286190: Add test to verify constant folding for Enum fields > > Reviewed-by: kvn, thartmann > - 8286154: Fix 3rd party notices in test files > > Reviewed-by: darcy, joehw, iris > - 8286291: G1: Remove unused segment allocator printouts > > Reviewed-by: ayang, iwalulya > - ... and 80 more: https://git.openjdk.java.net/jdk/compare/f823bf84...5cef96f7 I brought in the changes from master after the Virtual Threads integration, but because the PR branch I'm basing on doesn't have those changes, they showed up in the diff. I've undone this mistake by rebasing onto the target branch, which gives a clean diff that should be unchanged from before (but shuffles the commit history to the end of the convo tab). ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From dcubed at openjdk.java.net Sat May 7 14:02:44 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 7 May 2022 14:02:44 GMT Subject: RFR: 8285923: [REDO] JDK-8285802 AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities [v2] In-Reply-To: <-ci84vmsYRvLR4fGmvP6WStOlHOczgCccpazaPZj3fQ=.f8fbe2f8-6e29-4c95-bc9f-84cc216b348e@github.com> References: <-ci84vmsYRvLR4fGmvP6WStOlHOczgCccpazaPZj3fQ=.f8fbe2f8-6e29-4c95-bc9f-84cc216b348e@github.com> Message-ID: On Fri, 6 May 2022 12:03:27 GMT, Andrew Haley wrote: >> It is with some trepidation that I post this after breaking things last time. However, I think I've tested this as much as it can be tested. >> >> The change from last time around is this: >> >> >> +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp >> @@ -2192,11 +2192,13 @@ void MacroAssembler::unimplemented(const char* what) { >> >> // If a constant does not fit in an immediate field, generate some >> // number of MOV instructions and then perform the operation. >> -void MacroAssembler::wrap_add_sub_imm_insn(Register Rd, Register Rn, unsigned imm, >> +void MacroAssembler::wrap_add_sub_imm_insn(Register Rd, Register Rn, uint64_t imm, >> add_sub_imm_insn insn1, >> - add_sub_reg_insn insn2) { >> + add_sub_reg_insn insn2, >> + bool is32) { >> assert(Rd != zr, "Rd = zr and not setting flags?"); >> - if (operand_valid_for_add_sub_immediate((int)imm)) { >> + bool fits = operand_valid_for_add_sub_immediate(is32 ? (int32_t)imm : imm); >> + if (fits) { >> (this->*insn1)(Rd, Rn, imm); >> >> >> After this patch, when an add/sub instruction has a 32-bit (rather than a 64-bit) operand, we truncate the operand to signed int. We do this because `operand_valid_for_add_sub_immediate()` takes a 64-bit signed operand, but if the instruction is only 32 bits wide we must ignore the upper 32 bits. Therefore, the call site to `wrap_add_sub_imm_insn()` needs to know the operand size in order to sign extend the operand correctly. >> >> Tested tier1-3, tier4 is still running but no regressions yet. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > 8285923: [REDO] JDK-8285802 AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities Mach5 testing: Mach5 Tier1: - no failures Mach5 Tier2: - 1 unrelated, known failure Mach5 Tier3: - no failures Mach5 Tier4: - no failures Mach5 Tier5: - no failures ------------- PR: https://git.openjdk.java.net/jdk/pull/8554 From stuefe at openjdk.java.net Sun May 8 09:15:45 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sun, 8 May 2022 09:15:45 GMT Subject: RFR: 8286331: jni_GetStringUTFChars() uses wrong heap allocator In-Reply-To: References: Message-ID: On Fri, 6 May 2022 17:54:45 GMT, Zhengyu Gu wrote: > jni_GetStringUTFChars() calls `AllocateHeap(length + 1, mtInternal, 0, AllocFailStrategy::RETURN_NULL);` to allocate memory, where it passes `0` as `NativeCallStack` reference, that results construction of `NativeCallStack`. > > In `NativeCallStack`'s constructor, it performs stack walk to capture native call stack. This is unnecessary, if NMT detail tracking is not enabled. > > It should use `char* AllocateHeap(size_t size, > MEMFLAGS flags, > AllocFailType alloc_failmode /* = AllocFailStrategy::EXIT_OOM*/)` heap allocator instead. Change looks good. So, we accidentally call `NativeCallStack(int toSkip);` ? If yes, and we don't like that, should we declare that constructor as explicit? ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8579 From egahlin at openjdk.java.net Sun May 8 13:02:14 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Sun, 8 May 2022 13:02:14 GMT Subject: RFR: 8282420: JFR: Remove event handlers [v4] In-Reply-To: References: Message-ID: > Hi, > > Could I have a review of a fix that removes event handler classes for JFR. Bytecode for event instrumentation is now only added to the event class. Benefits are: > > - No class memory leak in the boot class loader. > - Reduce overhead from class loading during startup, which is important with additional JDK events that are coming (VirtualThreadStart etc.) > - One less frame to traverse when recording a Java stack trace. > > Future benefits are: > > - Simplify creating instrumentation as a build step. See https://bugs.openjdk.java.net/browse/JDK-8279354 > - Simplify implementation of Event Metrics. See https://bugs.openjdk.java.net/browse/JDK-8224749 > > When the Security Manager is removed, much of the code being added for security reasons can be deleted. > > There are few JFR hooks when code is being linked. Plan is to also use these for other events later. > > Testing: tier 1-4, jdk/jdk/jfr > > Thanks > Erik Erik Gahlin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge - Typos in cleanups - Cleanups - Test cleanup - Test fixes - Fix whitespaces - Use EventWriterFactory - Initial ------------- Changes: https://git.openjdk.java.net/jdk/pull/8383/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=03 Stats: 4076 lines in 82 files changed: 2415 ins; 1050 del; 611 mod Patch: https://git.openjdk.java.net/jdk/pull/8383.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8383/head:pull/8383 PR: https://git.openjdk.java.net/jdk/pull/8383 From lmesnik at openjdk.java.net Sun May 8 22:06:02 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Sun, 8 May 2022 22:06:02 GMT Subject: RFR: 8284550: test failure_handler is not properly invoking jhsdb jstack, resulting in failure to produce a stack when a test times out Message-ID: ?resulting in failure to produce a stack when a test times out ------------- Commit messages: - 8284550: test failure_handler is not properly invoking jhsdb jstack, resulting in failure to produce a stack when a test times out Changes: https://git.openjdk.java.net/jdk/pull/8588/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8588&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284550 Stats: 7 lines in 1 file changed: 1 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8588.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8588/head:pull/8588 PR: https://git.openjdk.java.net/jdk/pull/8588 From dholmes at openjdk.java.net Sun May 8 22:24:42 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 8 May 2022 22:24:42 GMT Subject: RFR: 8284550: test failure_handler is not properly invoking jhsdb jstack, resulting in failure to produce a stack when a test times out In-Reply-To: References: Message-ID: On Sun, 8 May 2022 21:57:20 GMT, Leonid Mesnik wrote: > ?resulting in failure to produce a stack when a test times out Looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8588 From alanb at openjdk.java.net Mon May 9 06:03:47 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 9 May 2022 06:03:47 GMT Subject: RFR: 8284550: test failure_handler is not properly invoking jhsdb jstack, resulting in failure to produce a stack when a test times out In-Reply-To: References: Message-ID: On Sun, 8 May 2022 21:57:20 GMT, Leonid Mesnik wrote: > ?resulting in failure to produce a stack when a test times out Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8588 From lkorinth at openjdk.java.net Mon May 9 07:19:50 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Mon, 9 May 2022 07:19:50 GMT Subject: RFR: 8281297: TestStressG1Humongous fails with guarantee(is_range_uncommitted) In-Reply-To: References: Message-ID: On Thu, 5 May 2022 17:37:35 GMT, Leo Korinth wrote: > TestStressG1Humongous passes 200 times with this change. I have started a new windows run with 1000 iterations. Without the fix the testcase will usually fail a few times when iterating 100 times. I have also started a tier 1-3 run. Thanks for the review Erik, Ivan and Thomas. ------------- PR: https://git.openjdk.java.net/jdk/pull/8560 From lkorinth at openjdk.java.net Mon May 9 07:19:51 2022 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Mon, 9 May 2022 07:19:51 GMT Subject: Integrated: 8281297: TestStressG1Humongous fails with guarantee(is_range_uncommitted) In-Reply-To: References: Message-ID: <50WAV-VIdQXfvcBMvZnKapnNNhyaiMlRAeX_HXlecCA=.07400ea4-334d-4074-ab83-044753c6769e@github.com> On Thu, 5 May 2022 17:37:35 GMT, Leo Korinth wrote: > TestStressG1Humongous passes 200 times with this change. I have started a new windows run with 1000 iterations. Without the fix the testcase will usually fail a few times when iterating 100 times. I have also started a tier 1-3 run. This pull request has now been integrated. Changeset: 1ce72eab Author: Leo Korinth URL: https://git.openjdk.java.net/jdk/commit/1ce72eabe54520845d8466c9d3ac07b60597182a Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8281297: TestStressG1Humongous fails with guarantee(is_range_uncommitted) Reviewed-by: eosterlund, iwalulya, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/8560 From ayang at openjdk.java.net Mon May 9 08:06:29 2022 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 9 May 2022 08:06:29 GMT Subject: RFR: 8285364: Remove REF_ enum for java.lang.ref.Reference [v6] In-Reply-To: References: Message-ID: <6q2SxqnLGaxGSFuk-1LU2iRIjPFEugDVxiEBAkzToJA=.4708294b-9d73-4998-b5bc-30f6a92f3fc1@github.com> > Simple rename and some comments update. > > Test: build Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - merge - review - comment - Rework reference type initialization Signed-off-by: Albert Yang - Remove REF_ enum for java.lang.ref.Reference Signed-off-by: Albert Yang - review - ref-rename ------------- Changes: https://git.openjdk.java.net/jdk/pull/8332/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8332&range=05 Stats: 119 lines in 14 files changed: 81 ins; 31 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8332.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8332/head:pull/8332 PR: https://git.openjdk.java.net/jdk/pull/8332 From duke at openjdk.java.net Mon May 9 08:20:59 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Mon, 9 May 2022 08:20:59 GMT Subject: Integrated: 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment In-Reply-To: References: Message-ID: <_BOhxnPQETIY7FOlNzMt85lE-mGHzT_hYRnrSFLeEFM=.33512418-56ff-4d54-bc9d-b9321a785bc8@github.com> On Thu, 28 Apr 2022 09:38:30 GMT, Johannes Bechberger wrote: > Calling JavaThread::thread_from_jni_environment for a terminated thread in AsyncGetCallTrace might cause the acquisition of a lock, making AsyncGetCallTrace non-signal-safe. > > AsyncGetCallTrace can only be called for the current threads (there are asserts for that), therefore using JavaThread::current directly and checking the termination status is semantically equivalent. This pull request has now been integrated. Changeset: d4474b58 Author: Johannes Bechberger Committer: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/d4474b5816c2ec8daaf1c905b77d8ba4e23c9439 Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod 8285794: AsyncGetCallTrace might acquire a lock via JavaThread::thread_from_jni_environment Reviewed-by: dholmes, mdoerr, jbachorik ------------- PR: https://git.openjdk.java.net/jdk/pull/8446 From mcimadamore at openjdk.java.net Mon May 9 08:26:35 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 9 May 2022 08:26:35 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v42] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits: - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Add tests for loaderLookup/restricted method corner cases - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI * Tweak restricted method check to work when there's no caller class - Tweak examples in SymbolLookup javadoc - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Tweak support for Linker lookup Improve javadoc of SymbolLookup - Tweak Addressable javadoc - Downcall and upcall tests use wrong layout which is missing some trailing padding - ... and 52 more: https://git.openjdk.java.net/jdk/compare/39f4434f...3c88a2ef ------------- Changes: https://git.openjdk.java.net/jdk/pull/7888/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=41 Stats: 65712 lines in 373 files changed: 43721 ins; 19432 del; 2559 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From tschatzl at openjdk.java.net Mon May 9 08:30:24 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 9 May 2022 08:30:24 GMT Subject: RFR: 8286303: Serial: Remove reference to ParGCRareEvent_lock Message-ID: Hi all, can I have reviews for this removal of an unused reference of ParGCRareEvent_lock in serial gc code - it is the only user of this BOT code, the other collectors have their own, completely separate one as far as I can tell. Testing: gha, tier1-5 Thanks, Thomas ------------- Depends on: https://git.openjdk.java.net/jdk/pull/8573 Commit messages: - Initial implementation Changes: https://git.openjdk.java.net/jdk/pull/8576/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8576&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286303 Stats: 5 lines in 2 files changed: 1 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8576.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8576/head:pull/8576 PR: https://git.openjdk.java.net/jdk/pull/8576 From jvernee at openjdk.java.net Mon May 9 10:28:27 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 9 May 2022 10:28:27 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 - Remove unneeded ComputeMoveOrder - Remove comment about native calls in lcm.cpp - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 Reviewed-by: jvernee, mcimadamore - Update riscv and arm stubs - Remove spurious ProblemList change - Pass pointer to LogStream - Polish - Replace TraceNativeInvokers flag with unified logging - Fix other platforms, take 2 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7959/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=06 Stats: 6934 lines in 157 files changed: 2678 ins; 3218 del; 1038 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From eosterlund at openjdk.java.net Mon May 9 11:20:12 2022 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 9 May 2022 11:20:12 GMT Subject: RFR: 8286376: Wrong condition for using non-immediate oops on AArch64 Message-ID: With the introduction of loom, nmethod entry barriers were added for all GCs. So far, the use of nmethod entry barriers has implied that nmethod oops are patched in the instruction stream. That is no longer the case. A condition was added to make sure we still get non-immediate oops on AArch64 for collectors that use nmethod entry barriers, and support immediate oops. However, the condition was messed up, so we instead end up doing the wrong thing. We should do the right thing. ------------- Commit messages: - 8286376: Wrong condition for using non-immediate oops on AArch64 Changes: https://git.openjdk.java.net/jdk/pull/8593/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8593&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286376 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8593.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8593/head:pull/8593 PR: https://git.openjdk.java.net/jdk/pull/8593 From aph at openjdk.java.net Mon May 9 12:05:49 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 9 May 2022 12:05:49 GMT Subject: RFR: 8286376: Wrong condition for using non-immediate oops on AArch64 In-Reply-To: References: Message-ID: <_XqkXAcbdS59hhrWAE6cOWZb4okKbE_TAS5YvjyV2kE=.71120938-8dfa-4ae2-8a16-d863f63a495e@github.com> On Mon, 9 May 2022 11:12:32 GMT, Erik ?sterlund wrote: > With the introduction of loom, nmethod entry barriers were added for all GCs. So far, the use of nmethod entry barriers has implied that nmethod oops are patched in the instruction stream. That is no longer the case. A condition was added to make sure we still get non-immediate oops on AArch64 for collectors that use nmethod entry barriers, and support immediate oops. However, the condition was messed up, so we instead end up doing the wrong thing. We should do the right thing. Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8593 From zgu at openjdk.java.net Mon May 9 12:51:33 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 9 May 2022 12:51:33 GMT Subject: RFR: 8286331: jni_GetStringUTFChars() uses wrong heap allocator [v2] In-Reply-To: References: Message-ID: <92fzc9FoxO86AUcAIk4GqQ7xHeihtURQAIJzafs0yC4=.25ce9fb9-55fa-4885-b292-36f28fb5192c@github.com> > jni_GetStringUTFChars() calls `AllocateHeap(length + 1, mtInternal, 0, AllocFailStrategy::RETURN_NULL);` to allocate memory, where it passes `0` as `NativeCallStack` reference, that results construction of `NativeCallStack`. > > In `NativeCallStack`'s constructor, it performs stack walk to capture native call stack. This is unnecessary, if NMT detail tracking is not enabled. > > It should use `char* AllocateHeap(size_t size, > MEMFLAGS flags, > AllocFailType alloc_failmode /* = AllocFailStrategy::EXIT_OOM*/)` heap allocator instead. Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Thomas' suggestion ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8579/files - new: https://git.openjdk.java.net/jdk/pull/8579/files/df1b8c33..8c13d81d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8579&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8579&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8579.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8579/head:pull/8579 PR: https://git.openjdk.java.net/jdk/pull/8579 From zgu at openjdk.java.net Mon May 9 12:56:54 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 9 May 2022 12:56:54 GMT Subject: RFR: 8286331: jni_GetStringUTFChars() uses wrong heap allocator In-Reply-To: References: Message-ID: On Sun, 8 May 2022 09:12:10 GMT, Thomas Stuefe wrote: > So, we accidentally call `NativeCallStack(int toSkip);` ? If yes, and we don't like that, should we declare that constructor as explicit? Good point, fixed. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/8579 From yadongwang at openjdk.java.net Mon May 9 13:09:11 2022 From: yadongwang at openjdk.java.net (Yadong Wang) Date: Mon, 9 May 2022 13:09:11 GMT Subject: RFR: 8286367: riscv: riscv port is broken after JDK-8284161 Message-ID: [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) implements a preview version of virtual threads on x86_64 and aarch64, and riscv port is broken everywhere. The initial patch is required to make everything on riscv work without "--enable-preview". Hotspot/jdk tier1 and all jtreg cases have been tested on Unmatched and Qemu respectively without new failures, except for the "-enable-preview" ones. ------------- Commit messages: - 8286367: riscv: riscv port is broken after JDK-8284161 Changes: https://git.openjdk.java.net/jdk/pull/8595/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8595&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286367 Stats: 183 lines in 7 files changed: 150 ins; 18 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/8595.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8595/head:pull/8595 PR: https://git.openjdk.java.net/jdk/pull/8595 From aph at openjdk.java.net Mon May 9 13:40:55 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 9 May 2022 13:40:55 GMT Subject: Integrated: 8285923: [REDO] JDK-8285802 AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities In-Reply-To: References: Message-ID: <8iXzqcOnHJIayQ3efRSri7ZC9H8sPrR-8WdKLW2x2BQ=.d2e7eded-5515-4262-857e-22bb69252ad9@github.com> On Thu, 5 May 2022 14:56:38 GMT, Andrew Haley wrote: > It is with some trepidation that I post this after breaking things last time. However, I think I've tested this as much as it can be tested. > > The change from last time around is this: > > > +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp > @@ -2192,11 +2192,13 @@ void MacroAssembler::unimplemented(const char* what) { > > // If a constant does not fit in an immediate field, generate some > // number of MOV instructions and then perform the operation. > -void MacroAssembler::wrap_add_sub_imm_insn(Register Rd, Register Rn, unsigned imm, > +void MacroAssembler::wrap_add_sub_imm_insn(Register Rd, Register Rn, uint64_t imm, > add_sub_imm_insn insn1, > - add_sub_reg_insn insn2) { > + add_sub_reg_insn insn2, > + bool is32) { > assert(Rd != zr, "Rd = zr and not setting flags?"); > - if (operand_valid_for_add_sub_immediate((int)imm)) { > + bool fits = operand_valid_for_add_sub_immediate(is32 ? (int32_t)imm : imm); > + if (fits) { > (this->*insn1)(Rd, Rn, imm); > > > After this patch, when an add/sub instruction has a 32-bit (rather than a 64-bit) operand, we truncate the operand to signed int. We do this because `operand_valid_for_add_sub_immediate()` takes a 64-bit signed operand, but if the instruction is only 32 bits wide we must ignore the upper 32 bits. Therefore, the call site to `wrap_add_sub_imm_insn()` needs to know the operand size in order to sign extend the operand correctly. > > Tested tier1-3, tier4 is still running but no regressions yet. This pull request has now been integrated. Changeset: b849efdf Author: Andrew Haley URL: https://git.openjdk.java.net/jdk/commit/b849efdf154552903faaddd69cac1fe5f1ddf18a Stats: 29 lines in 3 files changed: 4 ins; 0 del; 25 mod 8285923: [REDO] JDK-8285802 AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities Reviewed-by: ngasson, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/8554 From zgu at openjdk.java.net Mon May 9 13:41:50 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 9 May 2022 13:41:50 GMT Subject: RFR: 8286331: jni_GetStringUTFChars() uses wrong heap allocator In-Reply-To: References: Message-ID: On Fri, 6 May 2022 22:25:26 GMT, Zhengyu Gu wrote: > > > > You are right, filed [JDK-8286346](https://bugs.openjdk.java.net/browse/JDK-8286346). @dean-long JDK-8286346 has been integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8579 From rrich at openjdk.java.net Mon May 9 15:52:49 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 9 May 2022 15:52:49 GMT Subject: RFR: 8286367: riscv: riscv port is broken after JDK-8284161 In-Reply-To: References: Message-ID: <8BvAPzIaf7DquIe6dfRfGIswh5UEpGqd07ZAuLTywYw=.cfa4e02a-0c86-470f-b94f-ff253159a49b@github.com> On Mon, 9 May 2022 13:02:36 GMT, Yadong Wang wrote: > [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) implements a preview version of virtual threads on x86_64 and aarch64, and riscv port is broken everywhere. The initial patch is required to make everything on riscv work without "--enable-preview". > > Hotspot/jdk tier1 and all jtreg cases have been tested on Unmatched and Qemu respectively without new failures, except for the "-enable-preview" ones. Hi, haven't you also got issues with the assertion at [signature.cpp:185](https://github.com/openjdk/jdk/blob/fe6e0c0beba5065cca4e2e5d1a89125d5bd0dba6/src/hotspot/share/runtime/signature.cpp#L185) because the implementation of `Fingerprinter::do_type_calling_convention()` needs to be adapted? Thanks, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/8595 From eosterlund at openjdk.java.net Mon May 9 16:50:50 2022 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 9 May 2022 16:50:50 GMT Subject: RFR: 8286376: Wrong condition for using non-immediate oops on AArch64 In-Reply-To: <_XqkXAcbdS59hhrWAE6cOWZb4okKbE_TAS5YvjyV2kE=.71120938-8dfa-4ae2-8a16-d863f63a495e@github.com> References: <_XqkXAcbdS59hhrWAE6cOWZb4okKbE_TAS5YvjyV2kE=.71120938-8dfa-4ae2-8a16-d863f63a495e@github.com> Message-ID: On Mon, 9 May 2022 12:02:44 GMT, Andrew Haley wrote: >> With the introduction of loom, nmethod entry barriers were added for all GCs. So far, the use of nmethod entry barriers has implied that nmethod oops are patched in the instruction stream. That is no longer the case. A condition was added to make sure we still get non-immediate oops on AArch64 for collectors that use nmethod entry barriers, and support immediate oops. However, the condition was messed up, so we instead end up doing the wrong thing. We should do the right thing. > > Marked as reviewed by aph (Reviewer). Thanks for the review, @theRealAph ------------- PR: https://git.openjdk.java.net/jdk/pull/8593 From lmesnik at openjdk.java.net Mon May 9 17:29:10 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 9 May 2022 17:29:10 GMT Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled Message-ID: The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview. It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled. ------------- Commit messages: - 8285739: disable EA when both JVMTI and Preview are enabled Changes: https://git.openjdk.java.net/jdk/pull/8589/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8589&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285739 Stats: 10 lines in 3 files changed: 5 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8589.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8589/head:pull/8589 PR: https://git.openjdk.java.net/jdk/pull/8589 From mcimadamore at openjdk.java.net Mon May 9 17:41:10 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 9 May 2022 17:41:10 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v43] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix crashes in heap segment benchmarks due to misaligned access ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/3c88a2ef..7b774297 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=42 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=41-42 Stats: 41 lines in 2 files changed: 3 ins; 4 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From lmesnik at openjdk.java.net Mon May 9 18:03:08 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 9 May 2022 18:03:08 GMT Subject: Withdrawn: 8285739: disable EA when both JVMTI and Preview are enabled In-Reply-To: References: Message-ID: On Mon, 9 May 2022 01:36:39 GMT, Leonid Mesnik wrote: > The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview. > > It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8589 From lmesnik at openjdk.java.net Mon May 9 18:03:01 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 9 May 2022 18:03:01 GMT Subject: Withdrawn: 8284550: test failure_handler is not properly invoking jhsdb jstack, resulting in failure to produce a stack when a test times out In-Reply-To: References: Message-ID: On Sun, 8 May 2022 21:57:20 GMT, Leonid Mesnik wrote: > ?resulting in failure to produce a stack when a test times out This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8588 From duke at openjdk.java.net Mon May 9 18:17:00 2022 From: duke at openjdk.java.net (ExE Boss) Date: Mon, 9 May 2022 18:17:00 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v43] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 17:41:10 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix crashes in heap segment benchmarks due to misaligned access test/micro/org/openjdk/bench/java/lang/foreign/LoopOverPollutedSegments.java line 69: > 67: static final ValueLayout.OfInt JAVA_INT_UNALIGNED = JAVA_INT.withBitAlignment(8); > 68: static final ValueLayout.OfFloat JAVA_FLOAT_UNALIGNED = JAVA_FLOAT.withBitAlignment(8); > 69: static final VarHandle intHandleUnaligned = JAVA_INT_UNALIGNED.arrayElementVarHandle(); To?match `LoopOverNonConstantHeap`, this?should?probably be?named `VH_INT_UNALIGNED`. -------------------------------------------------------------------------------- Maybe?these could?also be?moved?into `org.openjdk.bench.java.lang.foreign.Utils`[^1] [^1]: https://github.com/openjdk/jdk/blob/7b774297b1d04e104a988ea5bd2f2b04c8de3461/test/micro/org/openjdk/bench/java/lang/foreign/Utils.java#L29-L43 ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From lmesnik at openjdk.java.net Mon May 9 18:29:57 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 9 May 2022 18:29:57 GMT Subject: Integrated: 8284550: test failure_handler is not properly invoking jhsdb jstack, resulting in failure to produce a stack when a test times out In-Reply-To: References: Message-ID: <0Kz-7aDguMharRzLo7GFJhkNx3b7RNGGvoCj0EV4of0=.53c26982-b214-4be7-b751-49c4e0a242d9@github.com> On Sun, 8 May 2022 21:57:20 GMT, Leonid Mesnik wrote: > ?resulting in failure to produce a stack when a test times out This pull request has now been integrated. Changeset: 40470d83 Author: Leonid Mesnik URL: https://git.openjdk.java.net/jdk/commit/40470d83e4d8d4a48eb87e6bf4d221460bddfd75 Stats: 7 lines in 1 file changed: 1 ins; 1 del; 5 mod 8284550: test failure_handler is not properly invoking jhsdb jstack, resulting in failure to produce a stack when a test times out Reviewed-by: dholmes, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/8588 From lmesnik at openjdk.java.net Mon May 9 18:33:38 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 9 May 2022 18:33:38 GMT Subject: RFR: 8286368: Cleanup problem lists after loom integration Message-ID: 8286368: Cleanup problem lists after loom integration ------------- Commit messages: - 8286368: Cleanup problem lists after loom integration Changes: https://git.openjdk.java.net/jdk/pull/8604/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8604&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286368 Stats: 27 lines in 4 files changed: 1 ins; 20 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8604.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8604/head:pull/8604 PR: https://git.openjdk.java.net/jdk/pull/8604 From kvn at openjdk.java.net Mon May 9 18:42:50 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 9 May 2022 18:42:50 GMT Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled In-Reply-To: References: Message-ID: On Mon, 9 May 2022 01:36:39 GMT, Leonid Mesnik wrote: > The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview. > > It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled. Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8589 From alanb at openjdk.java.net Mon May 9 19:17:49 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 9 May 2022 19:17:49 GMT Subject: RFR: 8286368: Cleanup problem lists after loom integration In-Reply-To: References: Message-ID: On Mon, 9 May 2022 18:17:13 GMT, Leonid Mesnik wrote: > 8286368: Cleanup problem lists after loom integration Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8604 From dlong at openjdk.java.net Mon May 9 19:40:50 2022 From: dlong at openjdk.java.net (Dean Long) Date: Mon, 9 May 2022 19:40:50 GMT Subject: RFR: 8286331: jni_GetStringUTFChars() uses wrong heap allocator [v2] In-Reply-To: <92fzc9FoxO86AUcAIk4GqQ7xHeihtURQAIJzafs0yC4=.25ce9fb9-55fa-4885-b292-36f28fb5192c@github.com> References: <92fzc9FoxO86AUcAIk4GqQ7xHeihtURQAIJzafs0yC4=.25ce9fb9-55fa-4885-b292-36f28fb5192c@github.com> Message-ID: On Mon, 9 May 2022 12:51:33 GMT, Zhengyu Gu wrote: >> jni_GetStringUTFChars() calls `AllocateHeap(length + 1, mtInternal, 0, AllocFailStrategy::RETURN_NULL);` to allocate memory, where it passes `0` as `NativeCallStack` reference, that results construction of `NativeCallStack`. >> >> In `NativeCallStack`'s constructor, it performs stack walk to capture native call stack. This is unnecessary, if NMT detail tracking is not enabled. >> >> It should use `char* AllocateHeap(size_t size, >> MEMFLAGS flags, >> AllocFailType alloc_failmode /* = AllocFailStrategy::EXIT_OOM*/)` heap allocator instead. > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Thomas' suggestion Marked as reviewed by dlong (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8579 From zgu at openjdk.java.net Mon May 9 19:48:56 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 9 May 2022 19:48:56 GMT Subject: RFR: 8286331: jni_GetStringUTFChars() uses wrong heap allocator [v2] In-Reply-To: References: <92fzc9FoxO86AUcAIk4GqQ7xHeihtURQAIJzafs0yC4=.25ce9fb9-55fa-4885-b292-36f28fb5192c@github.com> Message-ID: On Mon, 9 May 2022 19:37:01 GMT, Dean Long wrote: >> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: >> >> Thomas' suggestion > > Marked as reviewed by dlong (Reviewer). Thanks, @dean-long @tstuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/8579 From zgu at openjdk.java.net Mon May 9 19:48:57 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 9 May 2022 19:48:57 GMT Subject: Integrated: 8286331: jni_GetStringUTFChars() uses wrong heap allocator In-Reply-To: References: Message-ID: On Fri, 6 May 2022 17:54:45 GMT, Zhengyu Gu wrote: > jni_GetStringUTFChars() calls `AllocateHeap(length + 1, mtInternal, 0, AllocFailStrategy::RETURN_NULL);` to allocate memory, where it passes `0` as `NativeCallStack` reference, that results construction of `NativeCallStack`. > > In `NativeCallStack`'s constructor, it performs stack walk to capture native call stack. This is unnecessary, if NMT detail tracking is not enabled. > > It should use `char* AllocateHeap(size_t size, > MEMFLAGS flags, > AllocFailType alloc_failmode /* = AllocFailStrategy::EXIT_OOM*/)` heap allocator instead. This pull request has now been integrated. Changeset: b0d2b0a3 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/b0d2b0a3553cbb2db23d543b98ab1401b3dbfa91 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod 8286331: jni_GetStringUTFChars() uses wrong heap allocator Reviewed-by: dlong, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/8579 From cjplummer at openjdk.java.net Mon May 9 19:53:49 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 9 May 2022 19:53:49 GMT Subject: RFR: 8284550: test failure_handler is not properly invoking jhsdb jstack, resulting in failure to produce a stack when a test times out In-Reply-To: References: Message-ID: On Sun, 8 May 2022 21:57:20 GMT, Leonid Mesnik wrote: > ?resulting in failure to produce a stack when a test times out test/failure_handler/src/share/conf/common.properties line 67: > 65: > 66: jhsdb.app=jhsdb > 67: jhsdb.jstack.live.args=jstack --mixed --pid %p What is the plan to address the fact that `--mixed` is not supported on macOS (and produces an error), so on macOS it would be best to leave `--mixed` off so we at least get java stack traces. ------------- PR: https://git.openjdk.java.net/jdk/pull/8588 From mcimadamore at openjdk.java.net Mon May 9 20:30:09 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 9 May 2022 20:30:09 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v43] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 18:09:51 GMT, ExE Boss wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix crashes in heap segment benchmarks due to misaligned access > > test/micro/org/openjdk/bench/java/lang/foreign/LoopOverPollutedSegments.java line 69: > >> 67: static final ValueLayout.OfInt JAVA_INT_UNALIGNED = JAVA_INT.withBitAlignment(8); >> 68: static final ValueLayout.OfFloat JAVA_FLOAT_UNALIGNED = JAVA_FLOAT.withBitAlignment(8); >> 69: static final VarHandle intHandleUnaligned = JAVA_INT_UNALIGNED.arrayElementVarHandle(); > > To?match `LoopOverNonConstantHeap`, this?should?probably be?named `VH_INT_UNALIGNED`. > > -------------------------------------------------------------------------------- > > Maybe?these could?also be?moved?into `org.openjdk.bench.java.lang.foreign.Utils`[^1] > > [^1]: https://github.com/openjdk/jdk/blob/7b774297b1d04e104a988ea5bd2f2b04c8de3461/test/micro/org/openjdk/bench/java/lang/foreign/Utils.java#L29-L43 I noted other possible cleanups for benchmarks, I'll work on something after we integrate this PR as I'd like to minimize the churn. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From kbarrett at openjdk.java.net Mon May 9 20:45:53 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 9 May 2022 20:45:53 GMT Subject: RFR: 8286303: Serial: Remove reference to ParGCRareEvent_lock In-Reply-To: References: Message-ID: On Fri, 6 May 2022 13:39:22 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this removal of an unused reference of ParGCRareEvent_lock in serial gc code - it is the only user of this BOT code, the other collectors have their own, completely separate one as far as I can tell. > > Testing: gha, tier1-5 > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8576 From rrich at openjdk.java.net Mon May 9 21:34:55 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 9 May 2022 21:34:55 GMT Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled In-Reply-To: References: Message-ID: On Mon, 9 May 2022 01:36:39 GMT, Leonid Mesnik wrote: > The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview. > > It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled. Hi Leonid, have you done some testing? [JDK-8227745](https://bugs.openjdk.java.net/browse/JDK-8227745) came with a bunch of tests. I wonder how they behave with your change. Thanks, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/8589 From lmesnik at openjdk.java.net Mon May 9 21:51:56 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 9 May 2022 21:51:56 GMT Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled In-Reply-To: References: Message-ID: On Mon, 9 May 2022 21:31:12 GMT, Richard Reingruber wrote: > Hi Leonid, > > have you done some testing? [JDK-8227745](https://bugs.openjdk.java.net/browse/JDK-8227745) came with a bunch of tests. I wonder how they behave with your change. > > Thanks, Richard. Thank you for looking on this. The EA-related tests passed and still pass when are executed without any additional options. There is a special mode when the test runs main() method in the virtual thread. Test IterateHeapWithEscapeAnalysisEnabled.java failed before the fix and start passing after my fix. It failed because before the fix EscapeBarrier was disabled while EA was enabled and we got incorrect data. Unfortunately, I was unable to run EATests.java in this mode even before the fix. (Not all tests are compatible with this "wrapper" mode) The goal is to restore the same behavior as it was before JDK-8227745 is implemented when virtual threads are enabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/8589 From lmesnik at openjdk.java.net Mon May 9 21:51:57 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 9 May 2022 21:51:57 GMT Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled In-Reply-To: References: Message-ID: On Mon, 9 May 2022 01:36:39 GMT, Leonid Mesnik wrote: > The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview. > > It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled. Also I run all our testing on the linux-x64-debug to ensure that there are no regressions. ------------- PR: https://git.openjdk.java.net/jdk/pull/8589 From psandoz at openjdk.java.net Mon May 9 21:58:54 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 9 May 2022 21:58:54 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v3] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 08:56:07 GMT, Xiaohong Gong wrote: >> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception. >> >> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize): >> >> >> @ForceInline >> public static >> ByteVector fromArray(VectorSpecies species, >> byte[] a, int offset, >> VectorMask m) { >> ByteSpecies vsp = (ByteSpecies) species; >> if (offset >= 0 && offset <= (a.length - species.length())) { >> return vsp.dummyVector().fromArray0(a, offset, m); >> } >> >> // FIXME: optimize >> checkMaskFromIndexSize(offset, vsp, m, 1, a.length); >> return vsp.vOp(m, i -> a[offset + i]); >> } >> >> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed. >> >> Also adds the same vectorization support for masked: >> - fromByteArray/fromByteBuffer >> - fromBooleanArray >> - fromCharArray >> >> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system: >> >> Benchmark before After Units >> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE 737.542 1387.069 ops/ms >> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366 330.776 ops/ms >> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE 233.832 6125.026 ops/ms >> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE 233.816 7075.923 ops/ms >> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE 119.771 330.587 ops/ms >> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE 431.961 939.301 ops/ms >> >> Similar performance gain can also be observed on 512-bit SVE system. > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Rename "use_predicate" to "needs_predicate" I did modified the code of this PR to avoid the conversion of `boolean` to `int` and the masked load is made intrinsic from the method at which the constants are passed as arguments i.e. the public `fromArray` mask accepting method. ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From rrich at openjdk.java.net Mon May 9 22:10:55 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 9 May 2022 22:10:55 GMT Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled In-Reply-To: References: Message-ID: On Mon, 9 May 2022 01:36:39 GMT, Leonid Mesnik wrote: > The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview. > > It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled. Hi Leonid, your changes look good to me. Thanks, Richard. Ok, thanks for letting me know. ------------- Marked as reviewed by rrich (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8589 From rrich at openjdk.java.net Mon May 9 23:40:36 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 9 May 2022 23:40:36 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) Message-ID: With this change `java -version` succeeds with the devkit build also the standard build on a ppc64le box does not crash anymore. Also tier1 tests don't look too bad. ------------- Commit messages: - frame::patch_pc - frame::get_oop_map - Initialize new frame members - Fix Continuation::is_cont_barrier_frame - Fix ppc StubGenerator - TemplateInterpreterGenerator::generate_Continuation_doYield_entry - Fingerprinter::do_type_calling_convention - NativeDeoptInstruction::is_deopt_at Changes: https://git.openjdk.java.net/jdk/pull/8617/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8617&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286446 Stats: 225 lines in 8 files changed: 177 ins; 10 del; 38 mod Patch: https://git.openjdk.java.net/jdk/pull/8617.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8617/head:pull/8617 PR: https://git.openjdk.java.net/jdk/pull/8617 From rrich at openjdk.java.net Mon May 9 23:40:37 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 9 May 2022 23:40:37 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) In-Reply-To: References: Message-ID: On Mon, 9 May 2022 22:45:49 GMT, Richard Reingruber wrote: > With this change `java -version` succeeds with the devkit build also the standard build on a ppc64le box does not crash anymore. > > Also tier1 tests don't look too bad. @coleenp @pron would be great if you could have a look at the small shared code changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From coleenp at openjdk.java.net Tue May 10 00:28:47 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 10 May 2022 00:28:47 GMT Subject: RFR: 8286367: riscv: riscv port is broken after JDK-8284161 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 13:02:36 GMT, Yadong Wang wrote: > [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) implements a preview version of virtual threads on x86_64 and aarch64, and riscv port is broken everywhere. The initial patch is required to make everything on riscv work without "--enable-preview". > > Hotspot/jdk tier1 and all jtreg cases have been tested on Unmatched and Qemu respectively without new failures, except for the "-enable-preview" ones. The parts of this that I know look good to me. Thank you for fixing this. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8595 From xgong at openjdk.java.net Tue May 10 01:20:40 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Tue, 10 May 2022 01:20:40 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v3] In-Reply-To: References: Message-ID: <_QEcTANm1mniixGLtt_oJ7O97TbPRriNKizi6MCViiM=.70b10358-a8ae-440a-a3a2-ff0fefd3d0b3@github.com> On Mon, 9 May 2022 21:55:27 GMT, Paul Sandoz wrote: > I modified the code of this PR to avoid the conversion of `boolean` to `int`, so a constant integer value is passed all the way through, and the masked load is made intrinsic from the method at which the constants are passed as arguments i.e. the public `fromArray` mask accepting method. Great and thanks! Could you please show me the changes or an example? I can push the changes to this PR. Thanks so much! ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From fyang at openjdk.java.net Tue May 10 02:08:36 2022 From: fyang at openjdk.java.net (Fei Yang) Date: Tue, 10 May 2022 02:08:36 GMT Subject: RFR: 8286367: riscv: riscv port is broken after JDK-8284161 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 13:02:36 GMT, Yadong Wang wrote: > [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) implements a preview version of virtual threads on x86_64 and aarch64, and riscv port is broken everywhere. The initial patch is required to make everything on riscv work without "--enable-preview". > > Hotspot/jdk tier1 and all jtreg cases have been tested on Unmatched and Qemu respectively without new failures, except for the "-enable-preview" ones. Looks good to me. Thanks. ------------- Marked as reviewed by fyang (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8595 From dholmes at openjdk.java.net Tue May 10 02:49:45 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 10 May 2022 02:49:45 GMT Subject: RFR: 8286285: G1: Rank issues with ParGCRareEvent_lock and Threads_lock In-Reply-To: References: Message-ID: On Fri, 6 May 2022 12:51:24 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that fixes up the rank of the `ParGCRareEvent_lock` lock? It might be called in the vm-thread that holds the `Threads_lock` during (single-threaded) verification. > > Testing: gha, local testing inducing uses of `ParGCRareEvent_lock` in the VM thread > > Thanks, > Thomas Seems okay. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8573 From yadongwang at openjdk.java.net Tue May 10 03:30:59 2022 From: yadongwang at openjdk.java.net (Yadong Wang) Date: Tue, 10 May 2022 03:30:59 GMT Subject: RFR: 8286367: riscv: riscv port is broken after JDK-8284161 In-Reply-To: <8BvAPzIaf7DquIe6dfRfGIswh5UEpGqd07ZAuLTywYw=.cfa4e02a-0c86-470f-b94f-ff253159a49b@github.com> References: <8BvAPzIaf7DquIe6dfRfGIswh5UEpGqd07ZAuLTywYw=.cfa4e02a-0c86-470f-b94f-ff253159a49b@github.com> Message-ID: On Mon, 9 May 2022 15:49:49 GMT, Richard Reingruber wrote: > Hi, > > haven't you also got issues with the assertion at [signature.cpp:185](https://github.com/openjdk/jdk/blob/fe6e0c0beba5065cca4e2e5d1a89125d5bd0dba6/src/hotspot/share/runtime/signature.cpp#L185) because the implementation of `Fingerprinter::do_type_calling_convention()` needs to be adapted? > > Thanks, Richard. We didn't have that kind of problem. Because we use two 4-byte stack slots for sub-pointer-size arguments in SharedRuntime::java_calling_convention. ------------- PR: https://git.openjdk.java.net/jdk/pull/8595 From iklam at openjdk.java.net Tue May 10 04:09:57 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 10 May 2022 04:09:57 GMT Subject: RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach() Message-ID: The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified. It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode. I also cleaned up related code in the JDK and HotSpot. Testing: - Passed tiers 1 and 2 - Tiers 3, 4, 5 are in progress ------------- Commit messages: - 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach() Changes: https://git.openjdk.java.net/jdk/pull/8622/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8622&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286441 Stats: 193 lines in 15 files changed: 0 ins; 144 del; 49 mod Patch: https://git.openjdk.java.net/jdk/pull/8622.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8622/head:pull/8622 PR: https://git.openjdk.java.net/jdk/pull/8622 From rrich at openjdk.java.net Tue May 10 06:54:44 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 10 May 2022 06:54:44 GMT Subject: RFR: 8286367: riscv: riscv port is broken after JDK-8284161 In-Reply-To: References: <8BvAPzIaf7DquIe6dfRfGIswh5UEpGqd07ZAuLTywYw=.cfa4e02a-0c86-470f-b94f-ff253159a49b@github.com> Message-ID: On Tue, 10 May 2022 03:28:58 GMT, Yadong Wang wrote: > > Hi, > > haven't you also got issues with the assertion at [signature.cpp:185](https://github.com/openjdk/jdk/blob/fe6e0c0beba5065cca4e2e5d1a89125d5bd0dba6/src/hotspot/share/runtime/signature.cpp#L185) because the implementation of `Fingerprinter::do_type_calling_convention()` needs to be adapted? > > Thanks, Richard. > > We didn't have that kind of problem. Because we use two 4-byte stack slots for sub-pointer-size arguments in SharedRuntime::java_calling_convention. I see. Thanks for clearifying. ------------- PR: https://git.openjdk.java.net/jdk/pull/8595 From alanb at openjdk.java.net Tue May 10 07:18:47 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 10 May 2022 07:18:47 GMT Subject: RFR: 8286367: riscv: riscv port is broken after JDK-8284161 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 13:02:36 GMT, Yadong Wang wrote: > [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) implements a preview version of virtual threads on x86_64 and aarch64, and riscv port is broken everywhere. The initial patch is required to make everything on riscv work without "--enable-preview". > > Hotspot/jdk tier1 and all jtreg cases have been tested on Unmatched and Qemu respectively without new failures, except for the "-enable-preview" ones. Thanks for doing this, I can spsonor it for you. ------------- PR: https://git.openjdk.java.net/jdk/pull/8595 From yadongwang at openjdk.java.net Tue May 10 07:18:47 2022 From: yadongwang at openjdk.java.net (Yadong Wang) Date: Tue, 10 May 2022 07:18:47 GMT Subject: Integrated: 8286367: riscv: riscv port is broken after JDK-8284161 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 13:02:36 GMT, Yadong Wang wrote: > [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) implements a preview version of virtual threads on x86_64 and aarch64, and riscv port is broken everywhere. The initial patch is required to make everything on riscv work without "--enable-preview". > > Hotspot/jdk tier1 and all jtreg cases have been tested on Unmatched and Qemu respectively without new failures, except for the "-enable-preview" ones. This pull request has now been integrated. Changeset: bf0dc4f8 Author: Yadong Wang Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/bf0dc4f844ca83855e7fde19313d92da055dcb77 Stats: 183 lines in 7 files changed: 150 ins; 18 del; 15 mod 8286367: riscv: riscv port is broken after JDK-8284161 Co-authored-by: Fei Yang Reviewed-by: coleenp, fyang ------------- PR: https://git.openjdk.java.net/jdk/pull/8595 From iwalulya at openjdk.java.net Tue May 10 08:29:50 2022 From: iwalulya at openjdk.java.net (Ivan Walulya) Date: Tue, 10 May 2022 08:29:50 GMT Subject: RFR: 8286303: Serial: Remove reference to ParGCRareEvent_lock In-Reply-To: References: Message-ID: On Fri, 6 May 2022 13:39:22 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this removal of an unused reference of ParGCRareEvent_lock in serial gc code - it is the only user of this BOT code, the other collectors have their own, completely separate one as far as I can tell. > > Testing: gha, tier1-5 > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8576 From iwalulya at openjdk.java.net Tue May 10 08:30:38 2022 From: iwalulya at openjdk.java.net (Ivan Walulya) Date: Tue, 10 May 2022 08:30:38 GMT Subject: RFR: 8286285: G1: Rank issues with ParGCRareEvent_lock and Threads_lock In-Reply-To: References: Message-ID: On Fri, 6 May 2022 12:51:24 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that fixes up the rank of the `ParGCRareEvent_lock` lock? It might be called in the vm-thread that holds the `Threads_lock` during (single-threaded) verification. > > Testing: gha, local testing inducing uses of `ParGCRareEvent_lock` in the VM thread > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8573 From tschatzl at openjdk.java.net Tue May 10 08:51:51 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 10 May 2022 08:51:51 GMT Subject: RFR: 8286285: G1: Rank issues with ParGCRareEvent_lock and Threads_lock In-Reply-To: References: Message-ID: On Tue, 10 May 2022 02:46:33 GMT, David Holmes wrote: >> Hi all, >> >> can I have reviews for this change that fixes up the rank of the `ParGCRareEvent_lock` lock? It might be called in the vm-thread that holds the `Threads_lock` during (single-threaded) verification. >> >> Testing: gha, local testing inducing uses of `ParGCRareEvent_lock` in the VM thread >> >> Thanks, >> Thomas > > Seems okay. > > Thanks. Thanks @dholmes-ora @walulyai for your reviews. Fwiw, this passed tier1-5 too ------------- PR: https://git.openjdk.java.net/jdk/pull/8573 From tschatzl at openjdk.java.net Tue May 10 08:51:52 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 10 May 2022 08:51:52 GMT Subject: Integrated: 8286285: G1: Rank issues with ParGCRareEvent_lock and Threads_lock In-Reply-To: References: Message-ID: On Fri, 6 May 2022 12:51:24 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that fixes up the rank of the `ParGCRareEvent_lock` lock? It might be called in the vm-thread that holds the `Threads_lock` during (single-threaded) verification. > > Testing: gha, local testing inducing uses of `ParGCRareEvent_lock` in the VM thread > > Thanks, > Thomas This pull request has now been integrated. Changeset: 60a91d15 Author: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/60a91d15adf0f3c836d4a06a79b2fee96c914f21 Stats: 7 lines in 2 files changed: 2 ins; 3 del; 2 mod 8286285: G1: Rank issues with ParGCRareEvent_lock and Threads_lock Reviewed-by: dholmes, iwalulya ------------- PR: https://git.openjdk.java.net/jdk/pull/8573 From tschatzl at openjdk.java.net Tue May 10 08:59:36 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 10 May 2022 08:59:36 GMT Subject: RFR: 8286303: Serial: Remove reference to ParGCRareEvent_lock [v2] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this removal of an unused reference of ParGCRareEvent_lock in serial gc code - it is the only user of this BOT code, the other collectors have their own, completely separate one as far as I can tell. > > Testing: gha, tier1-5 > > Thanks, > Thomas Thomas Schatzl 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. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8576/files - new: https://git.openjdk.java.net/jdk/pull/8576/files/d195077b..d195077b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8576&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8576&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8576.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8576/head:pull/8576 PR: https://git.openjdk.java.net/jdk/pull/8576 From duke at openjdk.java.net Tue May 10 08:59:37 2022 From: duke at openjdk.java.net (openjdk-notifier[bot]) Date: Tue, 10 May 2022 08:59:37 GMT Subject: RFR: 8286303: Serial: Remove reference to ParGCRareEvent_lock In-Reply-To: References: Message-ID: On Fri, 6 May 2022 13:39:22 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this removal of an unused reference of ParGCRareEvent_lock in serial gc code - it is the only user of this BOT code, the other collectors have their own, completely separate one as far as I can tell. > > Testing: gha, tier1-5 > > Thanks, > Thomas The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork: git checkout submit/8286303-pargcrareeventlock-remove-serial git fetch https://git.openjdk.java.net/jdk master git merge FETCH_HEAD # if there are conflicts, follow the instructions given by git merge git commit -m "Merge master" git push ------------- PR: https://git.openjdk.java.net/jdk/pull/8576 From tschatzl at openjdk.java.net Tue May 10 09:13:46 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 10 May 2022 09:13:46 GMT Subject: RFR: 8286303: Serial: Remove reference to ParGCRareEvent_lock [v3] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this removal of an unused reference of ParGCRareEvent_lock in serial gc code - it is the only user of this BOT code, the other collectors have their own, completely separate one as far as I can tell. > > Testing: gha, tier1-5 > > Thanks, > Thomas Thomas Schatzl 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 8286303-pargcrareeventlock-remove-serial - Initial implementation - initial changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8576/files - new: https://git.openjdk.java.net/jdk/pull/8576/files/d195077b..a09c65b6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8576&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8576&range=01-02 Stats: 103469 lines in 1246 files changed: 93928 ins; 4531 del; 5010 mod Patch: https://git.openjdk.java.net/jdk/pull/8576.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8576/head:pull/8576 PR: https://git.openjdk.java.net/jdk/pull/8576 From mdoerr at openjdk.java.net Tue May 10 10:41:49 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 10 May 2022 10:41:49 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) In-Reply-To: References: Message-ID: <-BvlKJ2LJ1JkHH1M7cG3Jx8WzjUoHJpmYpDCOifbU8g=.56a86fb3-67a6-4593-898f-c6e5133d3bee@github.com> On Mon, 9 May 2022 22:45:49 GMT, Richard Reingruber wrote: > With this change `java -version` succeeds with the devkit build also the standard build on a ppc64le box does not crash anymore. > > Also tier1 tests don't look too bad. Looks great! Thanks for fixing PPC64 so quickly! I only have a few minor requests. Otherwise, good to go. src/hotspot/cpu/ppc/frame_ppc.cpp line 239: > 237: } > 238: assert(!Continuation::is_return_barrier_entry(*pc_addr), "return barrier"); > 239: assert(_pc == *pc_addr || pc == *pc_addr || *pc_addr == 0, "must be (pc: " INTPTR_FORMAT " _pc: " INTPTR_FORMAT " pc_addr: " INTPTR_FORMAT " *pc_addr: " INTPTR_FORMAT " sp: " INTPTR_FORMAT ")", p2i(pc), p2i(_pc), p2i(pc_addr), p2i(*pc_addr), p2i(sp())); Please break down this huge line! (Optional: I think having *pc_addr always on the same side would be a bit better readable.) src/hotspot/cpu/ppc/frame_ppc.inline.hpp line 36: > 34: // Inline functions for ppc64 frames: > 35: > 36: // Initialize frame members Add `(_pc and _sp must be given)`? src/hotspot/cpu/ppc/frame_ppc.inline.hpp line 106: > 104: // In thaw, non-heap frames use this constructor to pass oop_map. I don't know why. > 105: assert(_on_heap || _cb != nullptr, "these frames are always heap frames"); > 106: if (cb != NULL) { Wouldn't usability be better without this check? (Call `setup()` regardless of `cb` provided or not.) Or is there any reason? src/hotspot/cpu/ppc/frame_ppc.inline.hpp line 109: > 107: setup(); > 108: } > 109: #ifdef ASSERT (Redundant.) src/hotspot/share/runtime/signature.cpp line 265: > 263: _fp_args++; > 264: } else { > 265: PPC64_ONLY(_stack_arg_slots = align_up(_stack_arg_slots, 2)); Looks good. Alternatively, we could think about dropping alignment on PPC64, but I think such changes could be done later (improvements of other platforms may also be worth being discussed). Your version fits to the current PPC64 platform code. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8617 From rrich at openjdk.java.net Tue May 10 10:56:49 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 10 May 2022 10:56:49 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) In-Reply-To: <-BvlKJ2LJ1JkHH1M7cG3Jx8WzjUoHJpmYpDCOifbU8g=.56a86fb3-67a6-4593-898f-c6e5133d3bee@github.com> References: <-BvlKJ2LJ1JkHH1M7cG3Jx8WzjUoHJpmYpDCOifbU8g=.56a86fb3-67a6-4593-898f-c6e5133d3bee@github.com> Message-ID: <43euAAW684JkwFh4DEnIH6-mtquayu_t_B0mQMv2GBg=.fb34923d-e83a-45c5-8048-79fd89b7e8df@github.com> On Tue, 10 May 2022 09:57:07 GMT, Martin Doerr wrote: >> With this change `java -version` succeeds with the devkit build also the standard build on a ppc64le box does not crash anymore. >> >> Also tier1 tests don't look too bad. > > src/hotspot/cpu/ppc/frame_ppc.cpp line 239: > >> 237: } >> 238: assert(!Continuation::is_return_barrier_entry(*pc_addr), "return barrier"); >> 239: assert(_pc == *pc_addr || pc == *pc_addr || *pc_addr == 0, "must be (pc: " INTPTR_FORMAT " _pc: " INTPTR_FORMAT " pc_addr: " INTPTR_FORMAT " *pc_addr: " INTPTR_FORMAT " sp: " INTPTR_FORMAT ")", p2i(pc), p2i(_pc), p2i(pc_addr), p2i(*pc_addr), p2i(sp())); > > Please break down this huge line! (Optional: I think having *pc_addr always on the same side would be a bit better readable.) Done > src/hotspot/cpu/ppc/frame_ppc.inline.hpp line 36: > >> 34: // Inline functions for ppc64 frames: >> 35: >> 36: // Initialize frame members > > Add `(_pc and _sp must be given)`? Done > src/hotspot/share/runtime/signature.cpp line 265: > >> 263: _fp_args++; >> 264: } else { >> 265: PPC64_ONLY(_stack_arg_slots = align_up(_stack_arg_slots, 2)); > > Looks good. Alternatively, we could think about dropping alignment on PPC64, but I think such changes could be done later (improvements of other platforms may also be worth being discussed). Your version fits to the current PPC64 platform code. I'd agree ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From rrich at openjdk.java.net Tue May 10 11:08:48 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 10 May 2022 11:08:48 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) In-Reply-To: <-BvlKJ2LJ1JkHH1M7cG3Jx8WzjUoHJpmYpDCOifbU8g=.56a86fb3-67a6-4593-898f-c6e5133d3bee@github.com> References: <-BvlKJ2LJ1JkHH1M7cG3Jx8WzjUoHJpmYpDCOifbU8g=.56a86fb3-67a6-4593-898f-c6e5133d3bee@github.com> Message-ID: On Tue, 10 May 2022 10:36:03 GMT, Martin Doerr wrote: >> With this change `java -version` succeeds with the devkit build also the standard build on a ppc64le box does not crash anymore. >> >> Also tier1 tests don't look too bad. > > src/hotspot/cpu/ppc/frame_ppc.inline.hpp line 106: > >> 104: // In thaw, non-heap frames use this constructor to pass oop_map. I don't know why. >> 105: assert(_on_heap || _cb != nullptr, "these frames are always heap frames"); >> 106: if (cb != NULL) { > > Wouldn't usability be better without this check? (Call `setup()` regardless of `cb` provided or not.) Or is there any reason? This ctor is currently not used. I simply copy'n'pasted the complete set of constructors. I'll remove it because a review without uses is hardly possible. ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From rrich at openjdk.java.net Tue May 10 11:14:51 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 10 May 2022 11:14:51 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) In-Reply-To: <-BvlKJ2LJ1JkHH1M7cG3Jx8WzjUoHJpmYpDCOifbU8g=.56a86fb3-67a6-4593-898f-c6e5133d3bee@github.com> References: <-BvlKJ2LJ1JkHH1M7cG3Jx8WzjUoHJpmYpDCOifbU8g=.56a86fb3-67a6-4593-898f-c6e5133d3bee@github.com> Message-ID: <14r-1gDDfv4xvxZdODYv1iAGl8zZdSqWDLxGk0HuALA=.69a14525-5377-4d83-a45e-d9cda6b1e6c1@github.com> On Tue, 10 May 2022 10:36:34 GMT, Martin Doerr wrote: >> With this change `java -version` succeeds with the devkit build also the standard build on a ppc64le box does not crash anymore. >> >> Also tier1 tests don't look too bad. > > src/hotspot/cpu/ppc/frame_ppc.inline.hpp line 109: > >> 107: setup(); >> 108: } >> 109: #ifdef ASSERT > > (Redundant.) Removed the unused ctor for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From coleenp at openjdk.java.net Tue May 10 12:15:47 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 10 May 2022 12:15:47 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) In-Reply-To: References: Message-ID: On Mon, 9 May 2022 22:45:49 GMT, Richard Reingruber wrote: > With this change `java -version` succeeds with the devkit build also the standard build on a ppc64le box does not crash anymore. > > Also tier1 tests don't look too bad. Thanks for fixing PPC. The changes look like the riscv ones. src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 4545: > 4543: > 4544: address start = __ pc(); > 4545: __ unimplemented(FILE_AND_LINE); If this is going to call unimplemented(), you might have to not define JFR_HAVE_INTRINSICS for PPC. src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 4701: > 4699: } else { > 4700: generate_all(); > 4701: } Does this fix this assert? # guarantee(_table_length < _table_max_length) failed: Incorrect UnsafeCopyMemory::_table_max_length I tried to trace through source code to see why and failed to do so. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8617 From coleenp at openjdk.java.net Tue May 10 12:15:48 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 10 May 2022 12:15:48 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) In-Reply-To: <43euAAW684JkwFh4DEnIH6-mtquayu_t_B0mQMv2GBg=.fb34923d-e83a-45c5-8048-79fd89b7e8df@github.com> References: <-BvlKJ2LJ1JkHH1M7cG3Jx8WzjUoHJpmYpDCOifbU8g=.56a86fb3-67a6-4593-898f-c6e5133d3bee@github.com> <43euAAW684JkwFh4DEnIH6-mtquayu_t_B0mQMv2GBg=.fb34923d-e83a-45c5-8048-79fd89b7e8df@github.com> Message-ID: On Tue, 10 May 2022 10:53:34 GMT, Richard Reingruber wrote: >> src/hotspot/share/runtime/signature.cpp line 265: >> >>> 263: _fp_args++; >>> 264: } else { >>> 265: PPC64_ONLY(_stack_arg_slots = align_up(_stack_arg_slots, 2)); >> >> Looks good. Alternatively, we could think about dropping alignment on PPC64, but I think such changes could be done later (improvements of other platforms may also be worth being discussed). Your version fits to the current PPC64 platform code. > > I'd agree These ifdefs are fine but argues for making this code platform dependent. not in this change though. ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From rrich at openjdk.java.net Tue May 10 12:35:59 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 10 May 2022 12:35:59 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) In-Reply-To: References: Message-ID: On Tue, 10 May 2022 12:12:50 GMT, Coleen Phillimore wrote: > Thanks for fixing PPC. The changes look like the riscv ones. Thanks for reviewing, Richard. > src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 4545: > >> 4543: >> 4544: address start = __ pc(); >> 4545: __ unimplemented(FILE_AND_LINE); > > If this is going to call unimplemented(), you might have to not define JFR_HAVE_INTRINSICS for PPC. Will JFR not work otherwise even if the preview is disabled? > src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 4701: > >> 4699: } else { >> 4700: generate_all(); >> 4701: } > > Does this fix this assert? > # guarantee(_table_length < _table_max_length) failed: Incorrect UnsafeCopyMemory::_table_max_length > I tried to trace through source code to see why and failed to do so. Yes it does. I've just copied what was needed from the ppc loom port and it worked. Havn't investigated further why it did. ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From jbhateja at openjdk.java.net Tue May 10 12:48:25 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 10 May 2022 12:48:25 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v3] In-Reply-To: References: Message-ID: <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com> > Hi All, > > Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) > > Following is the brief summary of changes:- > > 1) Extends the scope of existing lanewise API for following new vector operations. > - VectorOperations.BIT_COUNT: counts the number of one-bits > - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits > - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits > - VectorOperations.REVERSE: reversing the order of bits > - VectorOperations.REVERSE_BYTES: reversing the order of bytes > - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. > > 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. > - Vector.compress > - Vector.expand > - VectorMask.compress > > 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. > - Vector.fromMemorySegment > - Vector.intoMemorySegment > > 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. > > > Patch has been regressed over AARCH64 and X86 targets different AVX levels. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja 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' of http://github.com/openjdk/jdk into JDK-8284960 - 8284960: Correcting a typo. - 8284960: Integrating changes from panama-vector (Add @since 19 tags). - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - 8284960: AARCH64 backend changes. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3fa1c404...b021e082 ------------- Changes: https://git.openjdk.java.net/jdk/pull/8425/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=02 Stats: 37901 lines in 214 files changed: 16527 ins; 16924 del; 4450 mod Patch: https://git.openjdk.java.net/jdk/pull/8425.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425 PR: https://git.openjdk.java.net/jdk/pull/8425 From rrich at openjdk.java.net Tue May 10 12:45:27 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 10 May 2022 12:45:27 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) [v2] In-Reply-To: References: Message-ID: > With this change `java -version` succeeds with the devkit build also the standard build on a ppc64le box does not crash anymore. > > Also tier1 tests don't look too bad. Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Martin's feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8617/files - new: https://git.openjdk.java.net/jdk/pull/8617/files/c1416e59..ed466a24 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8617&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8617&range=00-01 Stats: 33 lines in 3 files changed: 3 ins; 27 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8617.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8617/head:pull/8617 PR: https://git.openjdk.java.net/jdk/pull/8617 From duke at openjdk.java.net Tue May 10 13:03:13 2022 From: duke at openjdk.java.net (Haomin) Date: Tue, 10 May 2022 13:03:13 GMT Subject: RFR: 8286452: The array length of testSmallConstArray should be small and const Message-ID: testLargeVariableArray and testSmallConstArray are the same, the localArrlen of testSmallConstArray should be small and const. ------------- Commit messages: - 8286452: The array length of testSmallConstArray should be small and const Changes: https://git.openjdk.java.net/jdk/pull/8621/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8621&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286452 Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8621.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8621/head:pull/8621 PR: https://git.openjdk.java.net/jdk/pull/8621 From rrich at openjdk.java.net Tue May 10 13:09:49 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 10 May 2022 13:09:49 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) [v2] In-Reply-To: <-BvlKJ2LJ1JkHH1M7cG3Jx8WzjUoHJpmYpDCOifbU8g=.56a86fb3-67a6-4593-898f-c6e5133d3bee@github.com> References: <-BvlKJ2LJ1JkHH1M7cG3Jx8WzjUoHJpmYpDCOifbU8g=.56a86fb3-67a6-4593-898f-c6e5133d3bee@github.com> Message-ID: <-D-b6170QbMsx5Q1AB71agYtddGHW0uttjFWiAAF2lU=.292cc019-35f4-4bba-a2de-75029ad24ea6@github.com> On Tue, 10 May 2022 10:38:33 GMT, Martin Doerr wrote: > Looks great! Thanks for fixing PPC64 so quickly! I only have a few minor requests. Otherwise, good to go. Thanks for reviewing! Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From mdoerr at openjdk.java.net Tue May 10 13:38:59 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 10 May 2022 13:38:59 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) [v2] In-Reply-To: References: Message-ID: <10h0IjDhwNS5J28c-tXiq2bXxtlKRedLPIkBFITSJWY=.e1804e46-3435-4a65-b1ca-a301cf5990e0@github.com> On Tue, 10 May 2022 12:45:27 GMT, Richard Reingruber wrote: >> With this change `java -version` succeeds with the devkit build also the standard build on a ppc64le box does not crash anymore. >> >> Also tier1 tests don't look too bad. > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Martin's feedback Thanks for the update! I can see the tests failing which enable "--enable-preview", but that's a different issue. I haven't seen JFR problems as long as preview is not enabled. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8617 From coleenp at openjdk.java.net Tue May 10 13:39:02 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 10 May 2022 13:39:02 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 12:32:22 GMT, Richard Reingruber wrote: >> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 4545: >> >>> 4543: >>> 4544: address start = __ pc(); >>> 4545: __ unimplemented(FILE_AND_LINE); >> >> If this is going to call unimplemented(), you might have to not define JFR_HAVE_INTRINSICS for PPC. > > Will JFR not work otherwise even if the preview is disabled? See https://bugs.openjdk.java.net/browse/JDK-8286480 I was discussing this with Markus earlier. He's going to fix this and then it's fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From mdoerr at openjdk.java.net Tue May 10 13:39:03 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 10 May 2022 13:39:03 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) [v2] In-Reply-To: References: Message-ID: <5pe5fVDCEVaTUqD5U-Zkxz1FhGJ_uEWnUM6vYbyHNxY=.ceb446db-489c-471a-a931-a49ff8a47a17@github.com> On Tue, 10 May 2022 13:33:49 GMT, Coleen Phillimore wrote: >> Will JFR not work otherwise even if the preview is disabled? > > See https://bugs.openjdk.java.net/browse/JDK-8286480 I was discussing this with Markus earlier. He's going to fix this and then it's fine. Thanks for the hint! ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From shade at openjdk.java.net Tue May 10 13:49:16 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 10 May 2022 13:49:16 GMT Subject: RFR: 8286476: x86_32: Fix crashes with non-preview mode after JDK-8284161 (Virtual Threads) Message-ID: <2uCMTSh-lg_tcEYZMpiAfHqiax8WXxRb4eEHzAsu12Y=.fb33363c-1f0a-4e46-959d-6e3fc5af89f6@github.com> Virtual Threads are not fully implemented on x86_32. The feature is guarded with `--enable-preview`. But there is some VM code that is executed unconditionally anyway, crashing the VM on some tests. This improves the x86_32 code to the point that tests without `--enable-preview` run successfully. This adds the scaffolding for full implementation too. Additional testing: - [x] Linux x86_32 fastdebug, `tier1` failures only with `--enable-preview` - [x] Linux x86_32 fastdebug, `tier2` failures only with `--enable-preview` ------------- Commit messages: - Fallback for 32-bit port signature helpers - Fix jdk_jfr Changes: https://git.openjdk.java.net/jdk/pull/8630/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8630&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286476 Stats: 145 lines in 2 files changed: 135 ins; 6 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8630.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8630/head:pull/8630 PR: https://git.openjdk.java.net/jdk/pull/8630 From egahlin at openjdk.java.net Tue May 10 13:56:42 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 10 May 2022 13:56:42 GMT Subject: RFR: 8282420: JFR: Remove event handlers [v5] In-Reply-To: References: Message-ID: > Hi, > > Could I have a review of a fix that removes event handler classes for JFR. Bytecode for event instrumentation is now only added to the event class. Benefits are: > > - No class memory leak in the boot class loader. > - Reduce overhead from class loading during startup, which is important with additional JDK events that are coming (VirtualThreadStart etc.) > - One less frame to traverse when recording a Java stack trace. > > Future benefits are: > > - Simplify creating instrumentation as a build step. See https://bugs.openjdk.java.net/browse/JDK-8279354 > - Simplify implementation of Event Metrics. See https://bugs.openjdk.java.net/browse/JDK-8224749 > > When the Security Manager is removed, much of the code being added for security reasons can be deleted. > > There are few JFR hooks when code is being linked. Plan is to also use these for other events later. > > Testing: tier 1-4, jdk/jdk/jfr > > Thanks > Erik Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: Reviewer feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8383/files - new: https://git.openjdk.java.net/jdk/pull/8383/files/2bf6ed15..2a9081d1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=03-04 Stats: 25 lines in 10 files changed: 7 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/8383.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8383/head:pull/8383 PR: https://git.openjdk.java.net/jdk/pull/8383 From shade at openjdk.java.net Tue May 10 13:57:37 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 10 May 2022 13:57:37 GMT Subject: RFR: 8286476: x86_32: Fix crashes with non-preview mode after JDK-8284161 (Virtual Threads) [v2] In-Reply-To: <2uCMTSh-lg_tcEYZMpiAfHqiax8WXxRb4eEHzAsu12Y=.fb33363c-1f0a-4e46-959d-6e3fc5af89f6@github.com> References: <2uCMTSh-lg_tcEYZMpiAfHqiax8WXxRb4eEHzAsu12Y=.fb33363c-1f0a-4e46-959d-6e3fc5af89f6@github.com> Message-ID: > Virtual Threads are not fully implemented on x86_32. The feature is guarded with `--enable-preview`. But there is some VM code that is executed unconditionally anyway, crashing the VM on some tests. This improves the x86_32 code to the point that tests without `--enable-preview` run successfully. This adds the scaffolding for full implementation too. > > Additional testing: > - [x] Linux x86_32 fastdebug, `tier1` failures only with `--enable-preview` > - [x] Linux x86_32 fastdebug, `tier2` failures only with `--enable-preview` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Fix x86_64 release build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8630/files - new: https://git.openjdk.java.net/jdk/pull/8630/files/e1f7a5f2..621424b2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8630&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8630&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8630.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8630/head:pull/8630 PR: https://git.openjdk.java.net/jdk/pull/8630 From shade at openjdk.java.net Tue May 10 14:06:32 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 10 May 2022 14:06:32 GMT Subject: RFR: 8286476: x86_32: Fix crashes with non-preview mode after JDK-8284161 (Virtual Threads) [v3] In-Reply-To: <2uCMTSh-lg_tcEYZMpiAfHqiax8WXxRb4eEHzAsu12Y=.fb33363c-1f0a-4e46-959d-6e3fc5af89f6@github.com> References: <2uCMTSh-lg_tcEYZMpiAfHqiax8WXxRb4eEHzAsu12Y=.fb33363c-1f0a-4e46-959d-6e3fc5af89f6@github.com> Message-ID: > Virtual Threads are not fully implemented on x86_32. The feature is guarded with `--enable-preview`. But there is some VM code that is executed unconditionally anyway, crashing the VM on some tests. This improves the x86_32 code to the point that tests without `--enable-preview` run successfully. This adds the scaffolding for full implementation too. > > Additional testing: > - [x] Linux x86_32 fastdebug, `tier1` failures only with `--enable-preview` > - [x] Linux x86_32 fastdebug, `tier2` failures only with `--enable-preview` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: x86-64 code still a bit wrong ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8630/files - new: https://git.openjdk.java.net/jdk/pull/8630/files/621424b2..5dddb9ba Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8630&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8630&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8630.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8630/head:pull/8630 PR: https://git.openjdk.java.net/jdk/pull/8630 From mgronlun at openjdk.java.net Tue May 10 14:09:10 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 10 May 2022 14:09:10 GMT Subject: RFR: 8286480: Remove the c1 getEventWriter() intrinsic to simplify post-Loom integration platform-porting efforts Message-ID: Greetings, The C1 intrinsic for getEventWriter() did not materialize and is currently only bouncing a platform-specific stub to enter the VM, putting an unnecessary burden on post-Loom integration platform-porting efforts. The platform-specific stub for C2, jfr_write_checkpoint, is still needed but is only called if a java/lang/VirtualThread is mounted. As such, it could be left unimplemented. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8286480 Changes: https://git.openjdk.java.net/jdk/pull/8631/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8631&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286480 Stats: 83 lines in 9 files changed: 5 ins; 68 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/8631.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8631/head:pull/8631 PR: https://git.openjdk.java.net/jdk/pull/8631 From coleenp at openjdk.java.net Tue May 10 14:16:45 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 10 May 2022 14:16:45 GMT Subject: RFR: 8286476: x86_32: Fix crashes with non-preview mode after JDK-8284161 (Virtual Threads) [v3] In-Reply-To: References: <2uCMTSh-lg_tcEYZMpiAfHqiax8WXxRb4eEHzAsu12Y=.fb33363c-1f0a-4e46-959d-6e3fc5af89f6@github.com> Message-ID: On Tue, 10 May 2022 14:06:32 GMT, Aleksey Shipilev wrote: >> Virtual Threads are not fully implemented on x86_32. The feature is guarded with `--enable-preview`. But there is some VM code that is executed unconditionally anyway, crashing the VM on some tests. This improves the x86_32 code to the point that tests without `--enable-preview` run successfully. This adds the scaffolding for full implementation too. >> >> Additional testing: >> - [x] Linux x86_32 fastdebug, `tier1` failures only with `--enable-preview` >> - [x] Linux x86_32 fastdebug, `tier2` failures only with `--enable-preview` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > x86-64 code still a bit wrong Looks good. Thanks for fixing this. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8630 From coleenp at openjdk.java.net Tue May 10 14:21:49 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 10 May 2022 14:21:49 GMT Subject: RFR: 8286480: Remove the c1 getEventWriter() intrinsic to simplify post-Loom integration platform-porting efforts In-Reply-To: References: Message-ID: On Tue, 10 May 2022 14:01:24 GMT, Markus Gr?nlund wrote: > Greetings, > > The C1 intrinsic for getEventWriter() did not materialize and is currently only bouncing a platform-specific stub to enter the VM, putting an unnecessary burden on post-Loom integration platform-porting efforts. > > The platform-specific stub for C2, jfr_write_checkpoint, is still needed but is only called if a java/lang/VirtualThread is mounted. As such, it could be left unimplemented. > > Testing: jdk_jfr > > Thanks > Markus This looks good but might want to time it with the x86 32 and ppc loom changes, where they've added stubs for these already. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8631 From stuefe at openjdk.java.net Tue May 10 14:22:49 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 10 May 2022 14:22:49 GMT Subject: RFR: 8286476: x86_32: Fix crashes with non-preview mode after JDK-8284161 (Virtual Threads) [v3] In-Reply-To: References: <2uCMTSh-lg_tcEYZMpiAfHqiax8WXxRb4eEHzAsu12Y=.fb33363c-1f0a-4e46-959d-6e3fc5af89f6@github.com> Message-ID: <0wZles3uWcwiDDzu8s8bdycmi9U67nvqxfBbdgfDbCI=.5d7da966-c62e-4c08-9aac-6e6a2492b69f@github.com> On Tue, 10 May 2022 14:06:32 GMT, Aleksey Shipilev wrote: >> Virtual Threads are not fully implemented on x86_32. The feature is guarded with `--enable-preview`. But there is some VM code that is executed unconditionally anyway, crashing the VM on some tests. This improves the x86_32 code to the point that tests without `--enable-preview` run successfully. This adds the scaffolding for full implementation too. >> >> Additional testing: >> - [x] Linux x86_32 fastdebug, `tier1` failures only with `--enable-preview` >> - [x] Linux x86_32 fastdebug, `tier2` failures only with `--enable-preview` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > x86-64 code still a bit wrong This fixes my build and gtest and looks good to me. Thanks a lot for fixing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8630 From shade at openjdk.java.net Tue May 10 14:35:50 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 10 May 2022 14:35:50 GMT Subject: RFR: 8286480: Remove the c1 getEventWriter() intrinsic to simplify post-Loom integration platform-porting efforts In-Reply-To: References: Message-ID: <-JlqRE2WTj_RZffHmw9q_zpeSCNIz2p8pdryV6pctcc=.aa2b38c1-5450-4a6e-afee-f2c1f816e2b1@github.com> On Tue, 10 May 2022 14:01:24 GMT, Markus Gr?nlund wrote: > Greetings, > > The C1 intrinsic for getEventWriter() did not materialize and is currently only bouncing a platform-specific stub to enter the VM, putting an unnecessary burden on post-Loom integration platform-porting efforts. > > The platform-specific stub for C2, jfr_write_checkpoint, is still needed but is only called if a java/lang/VirtualThread is mounted. As such, it could be left unimplemented. > > Testing: jdk_jfr > > Thanks > Markus If you can integrate this soon, I can rebase #8630 afterwards. This would probably break RISC-V that is already in the mainline, though. ------------- PR: https://git.openjdk.java.net/jdk/pull/8631 From egahlin at openjdk.java.net Tue May 10 14:42:58 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 10 May 2022 14:42:58 GMT Subject: RFR: 8282420: JFR: Remove event handlers [v6] In-Reply-To: References: Message-ID: > Hi, > > Could I have a review of a fix that removes event handler classes for JFR. Bytecode for event instrumentation is now only added to the event class. Benefits are: > > - No class memory leak in the boot class loader. > - Reduce overhead from class loading during startup, which is important with additional JDK events that are coming (VirtualThreadStart etc.) > - One less frame to traverse when recording a Java stack trace. > > Future benefits are: > > - Simplify creating instrumentation as a build step. See https://bugs.openjdk.java.net/browse/JDK-8279354 > - Simplify implementation of Event Metrics. See https://bugs.openjdk.java.net/browse/JDK-8224749 > > When the Security Manager is removed, much of the code being added for security reasons can be deleted. > > There are few JFR hooks when code is being linked. Plan is to also use these for other events later. > > Testing: tier 1-4, jdk/jdk/jfr > > Thanks > Erik Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: Minor fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8383/files - new: https://git.openjdk.java.net/jdk/pull/8383/files/2a9081d1..193c9d80 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=04-05 Stats: 5 lines in 3 files changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8383.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8383/head:pull/8383 PR: https://git.openjdk.java.net/jdk/pull/8383 From mgronlun at openjdk.java.net Tue May 10 14:43:00 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 10 May 2022 14:43:00 GMT Subject: RFR: 8282420: JFR: Remove event handlers [v5] In-Reply-To: References: Message-ID: <1cp7VMWSN1Vr12vH329tgudVuQrEIpzaYvx-Qjzwl5Y=.5719a33a-ef81-431c-8893-8d6c96ec7886@github.com> On Tue, 10 May 2022 13:56:42 GMT, Erik Gahlin wrote: >> Hi, >> >> Could I have a review of a fix that removes event handler classes for JFR. Bytecode for event instrumentation is now only added to the event class. Benefits are: >> >> - No class memory leak in the boot class loader. >> - Reduce overhead from class loading during startup, which is important with additional JDK events that are coming (VirtualThreadStart etc.) >> - One less frame to traverse when recording a Java stack trace. >> >> Future benefits are: >> >> - Simplify creating instrumentation as a build step. See https://bugs.openjdk.java.net/browse/JDK-8279354 >> - Simplify implementation of Event Metrics. See https://bugs.openjdk.java.net/browse/JDK-8224749 >> >> When the Security Manager is removed, much of the code being added for security reasons can be deleted. >> >> There are few JFR hooks when code is being linked. Plan is to also use these for other events later. >> >> Testing: tier 1-4, jdk/jdk/jfr >> >> Thanks >> Erik > > Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: > > Reviewer feedback Marked as reviewed by mgronlun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8383 From mgronlun at openjdk.java.net Tue May 10 14:46:07 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 10 May 2022 14:46:07 GMT Subject: RFR: 8286480: Remove the c1 getEventWriter() intrinsic to simplify post-Loom integration platform-porting efforts In-Reply-To: <-JlqRE2WTj_RZffHmw9q_zpeSCNIz2p8pdryV6pctcc=.aa2b38c1-5450-4a6e-afee-f2c1f816e2b1@github.com> References: <-JlqRE2WTj_RZffHmw9q_zpeSCNIz2p8pdryV6pctcc=.aa2b38c1-5450-4a6e-afee-f2c1f816e2b1@github.com> Message-ID: On Tue, 10 May 2022 14:33:39 GMT, Aleksey Shipilev wrote: > This would probably break RISC-V that is already in the mainline, though. Good catch, I will update that code as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/8631 From shade at openjdk.java.net Tue May 10 14:46:08 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 10 May 2022 14:46:08 GMT Subject: RFR: 8286480: Remove the c1 getEventWriter() intrinsic to simplify post-Loom integration platform-porting efforts In-Reply-To: References: <-JlqRE2WTj_RZffHmw9q_zpeSCNIz2p8pdryV6pctcc=.aa2b38c1-5450-4a6e-afee-f2c1f816e2b1@github.com> Message-ID: <84kjihd6lw1C35L01WoBjrsXmIr42Leh3X8TridI9mA=.74a48d40-bff8-4ffc-a71a-f393ca562854@github.com> On Tue, 10 May 2022 14:40:41 GMT, Markus Gr?nlund wrote: > > This would probably break RISC-V that is already in the mainline, though. > > Good catch, I will update that code as well. Just take this patch, I already tested it on RISC-V box: http://cr.openjdk.java.net/~shade/8286480/risc-v.patch ------------- PR: https://git.openjdk.java.net/jdk/pull/8631 From tschatzl at openjdk.java.net Tue May 10 14:55:03 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 10 May 2022 14:55:03 GMT Subject: RFR: 8286303: Serial: Remove reference to ParGCRareEvent_lock [v3] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 09:13:46 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this removal of an unused reference of ParGCRareEvent_lock in serial gc code - it is the only user of this BOT code, the other collectors have their own, completely separate one as far as I can tell. >> >> Testing: gha, tier1-5 >> >> Thanks, >> Thomas > > Thomas Schatzl 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 8286303-pargcrareeventlock-remove-serial > - Initial implementation > - initial changes The failures on x86_32 seem to be related to recent Loom integration and are in the process of being fixed (PR#8630). Thanks @kimbarrett @walulyai for your reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/8576 From tschatzl at openjdk.java.net Tue May 10 14:55:06 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 10 May 2022 14:55:06 GMT Subject: Integrated: 8286303: Serial: Remove reference to ParGCRareEvent_lock In-Reply-To: References: Message-ID: On Fri, 6 May 2022 13:39:22 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this removal of an unused reference of ParGCRareEvent_lock in serial gc code - it is the only user of this BOT code, the other collectors have their own, completely separate one as far as I can tell. > > Testing: gha, tier1-5 > > Thanks, > Thomas This pull request has now been integrated. Changeset: ecbb3804 Author: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/ecbb380450b79d5d7830e8c06d78bf933289d514 Stats: 5 lines in 2 files changed: 1 ins; 3 del; 1 mod 8286303: Serial: Remove reference to ParGCRareEvent_lock Reviewed-by: kbarrett, iwalulya ------------- PR: https://git.openjdk.java.net/jdk/pull/8576 From mgronlun at openjdk.java.net Tue May 10 15:02:29 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 10 May 2022 15:02:29 GMT Subject: RFR: 8286480: Remove the c1 getEventWriter() intrinsic to simplify post-Loom integration platform-porting efforts [v2] In-Reply-To: References: Message-ID: > Greetings, > > The C1 intrinsic for getEventWriter() did not materialize and is currently only bouncing a platform-specific stub to enter the VM, putting an unnecessary burden on post-Loom integration platform-porting efforts. > > The platform-specific stub for C2, jfr_write_checkpoint, is still needed but is only called if a java/lang/VirtualThread is mounted. As such, it could be left unimplemented. > > Testing: jdk_jfr > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision: - missing comma - riscv ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8631/files - new: https://git.openjdk.java.net/jdk/pull/8631/files/4e38c4ba..c21ec34e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8631&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8631&range=00-01 Stats: 20 lines in 1 file changed: 2 ins; 13 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8631.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8631/head:pull/8631 PR: https://git.openjdk.java.net/jdk/pull/8631 From shade at openjdk.java.net Tue May 10 15:02:29 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 10 May 2022 15:02:29 GMT Subject: RFR: 8286480: Remove the c1 getEventWriter() intrinsic to simplify post-Loom integration platform-porting efforts [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 14:59:38 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> The C1 intrinsic for getEventWriter() did not materialize and is currently only bouncing a platform-specific stub to enter the VM, putting an unnecessary burden on post-Loom integration platform-porting efforts. >> >> The platform-specific stub for C2, jfr_write_checkpoint, is still needed but is only called if a java/lang/VirtualThread is mounted. As such, it could be left unimplemented. >> >> Testing: jdk_jfr >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision: > > - missing comma > - riscv Changes requested by shade (Reviewer). src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 3770: > 3768: address the_pc = __ pc(); > 3769: jfr_prologue(the_pc, _masm, xthread); > 3770: __ call_VM_leaf(CAST_FROM_FN_PTR(address, JfrIntrinsicSupport::write_checkpoint) 1); Spot the missing comma. ;) ------------- PR: https://git.openjdk.java.net/jdk/pull/8631 From mgronlun at openjdk.java.net Tue May 10 15:02:30 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 10 May 2022 15:02:30 GMT Subject: RFR: 8286480: Remove the c1 getEventWriter() intrinsic to simplify post-Loom integration platform-porting efforts [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 14:55:33 GMT, Aleksey Shipilev wrote: >> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision: >> >> - missing comma >> - riscv > > src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 3770: > >> 3768: address the_pc = __ pc(); >> 3769: jfr_prologue(the_pc, _masm, xthread); >> 3770: __ call_VM_leaf(CAST_FROM_FN_PTR(address, JfrIntrinsicSupport::write_checkpoint) 1); > > Spot the missing comma. ;) Haha, should have taken your patch :) ------------- PR: https://git.openjdk.java.net/jdk/pull/8631 From shade at openjdk.java.net Tue May 10 15:08:13 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 10 May 2022 15:08:13 GMT Subject: RFR: 8286480: Remove the c1 getEventWriter() intrinsic to simplify post-Loom integration platform-porting efforts [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 15:02:29 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> The C1 intrinsic for getEventWriter() did not materialize and is currently only bouncing a platform-specific stub to enter the VM, putting an unnecessary burden on post-Loom integration platform-porting efforts. >> >> The platform-specific stub for C2, jfr_write_checkpoint, is still needed but is only called if a java/lang/VirtualThread is mounted. As such, it could be left unimplemented. >> >> Testing: jdk_jfr >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision: > > - missing comma > - riscv RISC-V runs more or less fine with this patch. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8631 From mgronlun at openjdk.java.net Tue May 10 15:13:49 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 10 May 2022 15:13:49 GMT Subject: RFR: 8286480: Remove the c1 getEventWriter() intrinsic to simplify post-Loom integration platform-porting efforts [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 15:02:29 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> The C1 intrinsic for getEventWriter() did not materialize and is currently only bouncing a platform-specific stub to enter the VM, putting an unnecessary burden on post-Loom integration platform-porting efforts. >> >> The platform-specific stub for C2, jfr_write_checkpoint, is still needed but is only called if a java/lang/VirtualThread is mounted. As such, it could be left unimplemented. >> >> Testing: jdk_jfr >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision: > > - missing comma > - riscv Thanks for reviewing! I would propose to integrate this right away to help unblock porting efforts. ------------- PR: https://git.openjdk.java.net/jdk/pull/8631 From mgronlun at openjdk.java.net Tue May 10 15:19:00 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 10 May 2022 15:19:00 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 12:32:22 GMT, Richard Reingruber wrote: >> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 4545: >> >>> 4543: >>> 4544: address start = __ pc(); >>> 4545: __ unimplemented(FILE_AND_LINE); >> >> If this is going to call unimplemented(), you might have to not define JFR_HAVE_INTRINSICS for PPC. > > Will JFR not work otherwise even if the preview is disabled? Hi @reinrich, I am about to check in https://github.com/openjdk/jdk/pull/8631, hopefully making this a bit easier on you. ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From mgronlun at openjdk.java.net Tue May 10 15:21:58 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 10 May 2022 15:21:58 GMT Subject: Integrated: 8286480: Remove the c1 getEventWriter() intrinsic to simplify post-Loom integration platform-porting efforts In-Reply-To: References: Message-ID: <68hgoKnLfKHemcM9kmkQ3ctZIQqo5rSid3tKuKThwAE=.778f223c-ae05-4fac-9041-af647073f3a4@github.com> On Tue, 10 May 2022 14:01:24 GMT, Markus Gr?nlund wrote: > Greetings, > > The C1 intrinsic for getEventWriter() did not materialize and is currently only bouncing a platform-specific stub to enter the VM, putting an unnecessary burden on post-Loom integration platform-porting efforts. > > The platform-specific stub for C2, jfr_write_checkpoint, is still needed but is only called if a java/lang/VirtualThread is mounted. As such, it could be left unimplemented. > > Testing: jdk_jfr > > Thanks > Markus This pull request has now been integrated. Changeset: fa25733d Author: Markus Gr?nlund URL: https://git.openjdk.java.net/jdk/commit/fa25733d7603dff214a17c2ce95a564de965b6af Stats: 103 lines in 10 files changed: 7 ins; 81 del; 15 mod 8286480: Remove the c1 getEventWriter() intrinsic to simplify post-Loom integration platform-porting efforts Reviewed-by: coleenp, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/8631 From shade at openjdk.java.net Tue May 10 15:25:50 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 10 May 2022 15:25:50 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 12:45:27 GMT, Richard Reingruber wrote: >> With this change `java -version` succeeds with the devkit build also the standard build on a ppc64le box does not crash anymore. >> >> Also tier1 tests don't look too bad. > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Martin's feedback This needs rebasing after #8631, otherwise the PPC64 build would break. ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From shade at openjdk.java.net Tue May 10 15:29:40 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 10 May 2022 15:29:40 GMT Subject: RFR: 8286476: x86_32: Fix crashes with non-preview mode after JDK-8284161 (Virtual Threads) [v4] In-Reply-To: <2uCMTSh-lg_tcEYZMpiAfHqiax8WXxRb4eEHzAsu12Y=.fb33363c-1f0a-4e46-959d-6e3fc5af89f6@github.com> References: <2uCMTSh-lg_tcEYZMpiAfHqiax8WXxRb4eEHzAsu12Y=.fb33363c-1f0a-4e46-959d-6e3fc5af89f6@github.com> Message-ID: > Virtual Threads are not fully implemented on x86_32. The feature is guarded with `--enable-preview`. But there is some VM code that is executed unconditionally anyway, crashing the VM on some tests. This improves the x86_32 code to the point that tests without `--enable-preview` run successfully. This adds the scaffolding for full implementation too. > > Additional testing: > - [x] Linux x86_32 fastdebug, `tier1` failures only with `--enable-preview` > - [x] Linux x86_32 fastdebug, `tier2` failures only with `--enable-preview` Aleksey Shipilev 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: - Rebasing after JDK-8286480 - Merge branch 'master' into JDK-8286476-loom-x86-32-no-preview - x86-64 code still a bit wrong - Fix x86_64 release build - Fallback for 32-bit port signature helpers - Fix jdk_jfr ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8630/files - new: https://git.openjdk.java.net/jdk/pull/8630/files/5dddb9ba..3d510b80 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8630&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8630&range=02-03 Stats: 470 lines in 34 files changed: 201 ins; 199 del; 70 mod Patch: https://git.openjdk.java.net/jdk/pull/8630.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8630/head:pull/8630 PR: https://git.openjdk.java.net/jdk/pull/8630 From egahlin at openjdk.java.net Tue May 10 16:17:44 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 10 May 2022 16:17:44 GMT Subject: Integrated: 8282420: JFR: Remove event handlers In-Reply-To: References: Message-ID: On Mon, 25 Apr 2022 16:49:42 GMT, Erik Gahlin wrote: > Hi, > > Could I have a review of a fix that removes event handler classes for JFR. Bytecode for event instrumentation is now only added to the event class. Benefits are: > > - No class memory leak in the boot class loader. > - Reduce overhead from class loading during startup, which is important with additional JDK events that are coming (VirtualThreadStart etc.) > - One less frame to traverse when recording a Java stack trace. > > Future benefits are: > > - Simplify creating instrumentation as a build step. See https://bugs.openjdk.java.net/browse/JDK-8279354 > - Simplify implementation of Event Metrics. See https://bugs.openjdk.java.net/browse/JDK-8224749 > > When the Security Manager is removed, much of the code being added for security reasons can be deleted. > > There are few JFR hooks when code is being linked. Plan is to also use these for other events later. > > Testing: tier 1-4, jdk/jdk/jfr > > Thanks > Erik This pull request has now been integrated. Changeset: 0f377363 Author: Erik Gahlin URL: https://git.openjdk.java.net/jdk/commit/0f3773635d3f20866472b505ac390bac10ed4676 Stats: 4083 lines in 82 files changed: 2420 ins; 1050 del; 613 mod 8282420: JFR: Remove event handlers Reviewed-by: mgronlun ------------- PR: https://git.openjdk.java.net/jdk/pull/8383 From stuefe at openjdk.java.net Tue May 10 16:22:33 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 10 May 2022 16:22:33 GMT Subject: RFR: 8286476: x86_32: Fix crashes with non-preview mode after JDK-8284161 (Virtual Threads) [v4] In-Reply-To: References: <2uCMTSh-lg_tcEYZMpiAfHqiax8WXxRb4eEHzAsu12Y=.fb33363c-1f0a-4e46-959d-6e3fc5af89f6@github.com> Message-ID: <3dOOuyE59aisqpr2lqk_d5666I77okwjvClLsHYWK5E=.6f863f68-0c78-4cb0-b269-f3e946ec8177@github.com> On Tue, 10 May 2022 15:29:40 GMT, Aleksey Shipilev wrote: >> Virtual Threads are not fully implemented on x86_32. The feature is guarded with `--enable-preview`. But there is some VM code that is executed unconditionally anyway, crashing the VM on some tests. This improves the x86_32 code to the point that tests without `--enable-preview` run successfully. This adds the scaffolding for full implementation too. >> >> Additional testing: >> - [x] Linux x86_32 fastdebug, `tier1` failures only with `--enable-preview` >> - [x] Linux x86_32 fastdebug, `tier2` failures only with `--enable-preview` > > Aleksey Shipilev 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: > > - Rebasing after JDK-8286480 > - Merge branch 'master' into JDK-8286476-loom-x86-32-no-preview > - x86-64 code still a bit wrong > - Fix x86_64 release build > - Fallback for 32-bit port signature helpers > - Fix jdk_jfr Marked as reviewed by stuefe (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8630 From stumon01 at arm.com Tue May 10 17:02:55 2022 From: stumon01 at arm.com (Stuart Monteith) Date: Tue, 10 May 2022 18:02:55 +0100 Subject: RFC onSpinWait() counter intrinsic. In-Reply-To: References: Message-ID: Hello, Following on from Evgeny's patch, I've been looking at an alternative way implementation of onSpinWait. It is great that we can choose between YIELDs, NOPs and ISBs or none, but it is desirable to move away from ISB. They are not intended to be used for delays, and their implementation would likely change in future. There are other possible implementations with Arm V8.7 features besides what we've implemented here, but silicon is just not there yet. I've put a patch here: https://github.com/stooart-mon/jdk/commit/5a973ac9c67db32c649be1c317adc2185c2568fd This implements a delay by reading a virtualized timer and waiting for a period of time to be exceeded: MRS X0, CNTVCT_EL0 ADD X0, X0, # loop: YIELD MRS X1, CNTVCT_EL0 CMP X1, X0 B.LT loop The counter is incremented at a rate that is particular to the CPU implementation - this is held in the CNTFRQ_EL0 register. For example, an Altra may tick at 25 MHz (40ns per tick), a RaspberryPi 4b will tick at 54Mhz (18ns). This is straightforward in Java, we can just generate the static code as is. However, other software would need to load the delay each time. To enable this implementation, pass options like so: -XX:OnSpinWaitInst=counter -XX:OnSpinWaitCounterDelay=10 One of the problems with this approach, and spinwaits in general, is knowing what the correct value should be. As the counter frequency varies between machines, and it is not clear what the actual delay itself should be - I would expect we'd offer a minimum value, and expect the algorithm calling the wait to adjust as necessary for its purposes. Ideally we'd implement our spinloops in such a way that all this may be unnecessary - objectMonitor.cpp alludes to spinning locally such as MCS. For most systems, a delay of "2" to "15" would be a good range to test. With future revisions of the Arm ARM and some more recent cores, the CNTFRQ register will report the counters increasing by 1 billion every second, but not necessarily in increments of 1. I'll be interested in hearing what people think. BR, Stuart For the the ThreadProducerConsumer spinwait tests, On 17/09/2021 12:36, Evgeny Astigeevich wrote: > This PR is a follow-up on the discussion [?RFC: AArch64: Implementing spin pauses with ISB?](https://mail.openjdk.java.net/pipermail/hotspot-dev/2021-August/054033.html). > > It adds the option `UsePauseImpl=value`, where `value` can be: > > - `none`: no implementation for spin pauses. This is the default value. > - `Nnop`: use `nop` instruction for spin pauses. Optional `N` can be `2..9` to specify a number of `nop` instructions. > - `Nisb`: use `isb` instruction for spin pauses. Optional `N` can be `2..9` to specify a number of `isb` instructions. > - `Nyield`: use `yield` instruction for spin pauses. Optional `N` can be `2..9` to specify a number of `yield` instructions. > > The code for the `Thread.onSpinWait` intrinsic is generated based on the value of `UsePauseImpl`. > > Testing: > > - `make test TEST="gtest"`: Passed > - `make run-test TEST="tier1"`: Passed > - `make run-test TEST="tier2"`: Passed > - `make run-test TEST=hotspot/jtreg/compiler/onSpinWait`: Passed > > ------------- > > Commit messages: > - Add missing header file > - 8186670: Implement _onSpinWait() intrinsic for AArch64 > > Changes: https://git.openjdk.java.net/jdk/pull/5562/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5562&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8186670 > Stats: 460 lines in 9 files changed: 458 ins; 0 del; 2 mod > Patch: https://git.openjdk.java.net/jdk/pull/5562.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/5562/head:pull/5562 > > PR: https://git.openjdk.java.net/jdk/pull/5562 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From lmesnik at openjdk.java.net Tue May 10 19:16:34 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 10 May 2022 19:16:34 GMT Subject: RFR: 8286368: Cleanup problem lists after loom integration [v2] In-Reply-To: References: Message-ID: > 8286368: Cleanup problem lists after loom integration Leonid Mesnik 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 - 8286368: Cleanup problem lists after loom integration ------------- Changes: https://git.openjdk.java.net/jdk/pull/8604/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8604&range=01 Stats: 29 lines in 4 files changed: 1 ins; 22 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8604.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8604/head:pull/8604 PR: https://git.openjdk.java.net/jdk/pull/8604 From lmesnik at openjdk.java.net Tue May 10 19:16:34 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 10 May 2022 19:16:34 GMT Subject: Integrated: 8286368: Cleanup problem lists after loom integration In-Reply-To: References: Message-ID: On Mon, 9 May 2022 18:17:13 GMT, Leonid Mesnik wrote: > 8286368: Cleanup problem lists after loom integration This pull request has now been integrated. Changeset: dcec1d2a Author: Leonid Mesnik URL: https://git.openjdk.java.net/jdk/commit/dcec1d2a68e2c82e27174c3dc52bb17316530966 Stats: 29 lines in 4 files changed: 1 ins; 22 del; 6 mod 8286368: Cleanup problem lists after loom integration Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/8604 From alanb at openjdk.java.net Tue May 10 20:02:48 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 10 May 2022 20:02:48 GMT Subject: RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach() In-Reply-To: References: Message-ID: On Tue, 10 May 2022 04:00:29 GMT, Ioi Lam wrote: > The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified. > > It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode. > > I also cleaned up related code in the JDK and HotSpot. > > Testing: > - Passed tiers 1 and 2 > - Tiers 3, 4, 5 are in progress src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/PerfDataBuffer.java line 60: > 58: FileChannel fc = new RandomAccessFile(f, "r").getChannel(); > 59: ByteBuffer bb = fc.map(FileChannel.MapMode.READ_ONLY, 0L, (int)fc.size()); > 60: fc.close(); // doesn't need to remain open I think you can change this to: try (FileChannel fc = FileChannel.open(f.toPath())) { ByteBuffer bb = ... createPerfDataBuffer(bb, 0); } ------------- PR: https://git.openjdk.java.net/jdk/pull/8622 From alanb at openjdk.java.net Tue May 10 20:06:47 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 10 May 2022 20:06:47 GMT Subject: RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach() In-Reply-To: References: Message-ID: On Tue, 10 May 2022 04:00:29 GMT, Ioi Lam wrote: > The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified. > > It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode. > > I also cleaned up related code in the JDK and HotSpot. > > Testing: > - Passed tiers 1 and 2 > - Tiers 3, 4, 5 are in progress I skimmed through the changes and I think they look okay. In the distant past there were tools outside of the JDK that used the jvmstat API directly. It's possible that VisualVM still does but it would only compile/run if --add-exports is used to export the sun.jvmstat.* packages. So it might be that dropping the parameter from a method in RemoteHost is noticed and I think that is okay because this package is not exported and is not meant to be used by code outside of the JDK. ------------- PR: https://git.openjdk.java.net/jdk/pull/8622 From rrich at openjdk.java.net Tue May 10 21:04:53 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Tue, 10 May 2022 21:04:53 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) [v2] In-Reply-To: References: Message-ID: <8JAfCqv5PimgnU3fFrBBupoPhvKJPWc8cq-7K4KxFs0=.73436b43-5269-4721-8bd6-904362e04beb@github.com> On Tue, 10 May 2022 12:45:27 GMT, Richard Reingruber wrote: >> With this change `java -version` succeeds with the devkit build also the standard build on a ppc64le box does not crash anymore. >> >> Also tier1 tests don't look too bad. > > Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: > > Martin's feedback Thanks for making me aware of #8631 @mgronlun and @shipilev. I'm working on it. Should I actually rebase the branch underlying the pr or should I merge master into it? ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From vlivanov at openjdk.java.net Tue May 10 21:06:18 2022 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 10 May 2022 21:06:18 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: Message-ID: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> On Mon, 9 May 2022 10:28:27 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20. >> >> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. >> >> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: >> >> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. >> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. >> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). >> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. >> >> While the patch mostly consists of VM changes, there are also some Java changes to support (2). >> >> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. >> >> Testing: Tier1-4 >> >> Thanks, >> Jorn >> >> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 >> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 >> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 >> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 >> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 >> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a >> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 >> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f >> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 > - Remove unneeded ComputeMoveOrder > - Remove comment about native calls in lcm.cpp > - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 > > Reviewed-by: jvernee, mcimadamore > - Update riscv and arm stubs > - Remove spurious ProblemList change > - Pass pointer to LogStream > - Polish > - Replace TraceNativeInvokers flag with unified logging > - Fix other platforms, take 2 > - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 Nice work! Looks good. Some minor comments/questions follow. src/hotspot/cpu/aarch64/frame_aarch64.cpp line 379: > 377: // need unextended_sp here, since normal sp is wrong for interpreter callees > 378: return reinterpret_cast( > 379: reinterpret_cast(frame.unextended_sp()) + in_bytes(_frame_data_offset)); Maybe use `address` instead of `char*`? src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5531: > 5529: } > 5530: > 5531: // On 64 bit we will store integer like items to the stack as Time for a cleanup? `64 bit` vs `64bit`, `abi`, `Aarch64`. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5547: > 5545: } else if (dst.first()->is_stack()) { > 5546: // reg to stack > 5547: // Do we really have to sign extend??? Obsolete? Remove? src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 306: > 304: intptr_t exception_handler_offset = __ pc() - start; > 305: > 306: // Native caller has no idea how to handle exceptions, Can you elaborate, please, how it is expected to work in presence of asynchronous exceptions? I'd expect to see a code which unconditionally clears pending exception with an assertion that verifies that the exception is of expected type. src/hotspot/cpu/x86/foreign_globals_x86.hpp line 30: > 28: #include "utilities/growableArray.hpp" > 29: > 30: class outputStream; Redundant declaration? src/hotspot/cpu/x86/foreign_globals_x86_64.cpp line 52: > 50: > 51: objArrayOop inputStorage = jdk_internal_foreign_abi_ABIDescriptor::inputStorage(abi_oop); > 52: loadArray(inputStorage, INTEGER_TYPE, abi._integer_argument_registers, as_Register); `loadArray` helper looks a bit misleading. In presence of `javaClass`-style accessors, it misleadingly hints that it refers to some Java-level operation/entity, though what it does it parses register list representation backed by a Java array. I suggest to rename it to something like `parse_argument_registers_array()`). src/hotspot/cpu/x86/macroAssembler_x86.cpp line 933: > 931: } else { > 932: assert(dst.is_single_reg(), "not a stack pair: (%s, %s), (%s, %s)", > 933: src.first()->name(), src.second()->name(), dst.first()->name(), dst.second()->name()); Wrong indentation. src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 36: > 34: #include "code/nativeInst.hpp" > 35: #include "code/vtableStubs.hpp" > 36: #include "compiler/disassembler.hpp" Redundant includes? No new code added in the file. src/hotspot/share/c1/c1_GraphBuilder.cpp line 4230: > 4228: > 4229: case vmIntrinsics::_linkToNative: > 4230: print_inlining(callee, "Native call", /*success*/ false); Since the message is appended, lower case is preferred:`"native call"`. src/hotspot/share/code/codeBlob.hpp line 754: > 752: class ProgrammableUpcallHandler; > 753: > 754: class OptimizedEntryBlob: public RuntimeBlob { What's the motivation to move `OptimizedEntryBlob` up in the hierarchy (from `BufferBlob` to `RuntimeBlob`)? src/hotspot/share/opto/callGenerator.cpp line 1131: > 1129: > 1130: case vmIntrinsics::_linkToNative: > 1131: print_inlining_failure(C, callee, jvms->depth() - 1, jvms->bci(), Why is it unconditionally reported as inlining failure? src/hotspot/share/prims/foreign_globals.cpp line 147: > 145: // based on ComputeMoveOrder from x86_64 shared runtime code. > 146: // with some changes. > 147: class ForeignCMO: public StackObj { Considering how seldom it is used, I don't see much value in abbreviating it. Also, the comment is misleading: there's no such entity as `ComputeMoveOrder` in the code. And `compute_move_order` is completely removed by this change. src/hotspot/share/prims/foreign_globals.cpp line 217: > 215: > 216: public: > 217: ForeignCMO(int total_in_args, const VMRegPair* in_regs, int total_out_args, VMRegPair* out_regs, I propose to turn it into a trivial ctor and move all the logic into a helper static function which returns the computed moves. src/hotspot/share/prims/foreign_globals.hpp line 35: > 33: #include CPU_HEADER(foreign_globals) > 34: > 35: class CallConvClosure { Just a question on terminology: why is it called a `Closure`? src/hotspot/share/prims/foreign_globals.hpp line 62: > 60: > 61: > 62: class JavaCallConv : public CallConvClosure { Does it really worth to abbreviate `CallingConvention` to `CallConv`? src/java.base/share/classes/jdk/internal/foreign/abi/SharedUtils.java line 313: > 311: MethodType newType = oldType.dropParameterTypes(destIndex, destIndex + 1); > 312: int[] reorder = new int[oldType.parameterCount()]; > 313: if (destIndex < sourceIndex) Misses braces. src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/AArch64Architecture.java line 169: > 167: stackAlignment, > 168: shadowSpace, > 169: targetAddrStorage, retBufAddrStorage); Wrong indentation. src/java.base/share/classes/jdk/internal/foreign/abi/x64/X86_64Architecture.java line 156: > 154: stackAlignment, > 155: shadowSpace, > 156: targetAddrStorage, retBufAddrStorage); Wrong indentation. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From vlivanov at openjdk.java.net Tue May 10 21:06:20 2022 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 10 May 2022 21:06:20 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 12:15:10 GMT, Jorn Vernee wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/share/utilities/growableArray.hpp line 151: > >> 149: return _data; >> 150: } >> 151: > > This accessor is added to be able to temporarily view a stable GrowableArray instance as a C-style array. It is used to by `NativeCallConv` and `RegSpiller` in `foreign_globals.hpp`. > > GrowableArray already has an `adr_at` accessor that does something similar, but using `adr_at(0)` fails on empty growable arrays since it also performs a bounds check. So it can not be used. Any problems with migrating `CallConv` and `RegSpiller`away from ` VMReg* + int` to `GrowableArray`? ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From redestad at openjdk.java.net Tue May 10 21:47:50 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 10 May 2022 21:47:50 GMT Subject: RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach() In-Reply-To: References: Message-ID: <5AjTeD3XkuyBV8Dux7QVRkJgDwTiJ4Et9303eiMLjNU=.84477522-bbdb-4215-976f-729910707634@github.com> On Tue, 10 May 2022 04:00:29 GMT, Ioi Lam wrote: > The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified. > > It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode. > > I also cleaned up related code in the JDK and HotSpot. > > Testing: > - Passed tiers 1 and 2 > - Tiers 3, 4, 5 are in progress Nice cleanup! (Some stylistic suggestions inline, feel free to ignore) src/hotspot/os/windows/perfMemory_windows.cpp line 1781: > 1779: // address space. > 1780: // > 1781: void PerfMemory::attach(const char* user, int vmid, One line? src/hotspot/share/prims/perf.cpp line 84: > 82: > 83: // attach to the PerfData memory region for the specified VM > 84: PerfMemory::attach(user_utf, vmid, One line? src/hotspot/share/runtime/perfMemory.hpp line 146: > 144: // methods for attaching to and detaching from the PerfData > 145: // memory segment of another JVM process on the same system. > 146: static void attach(const char* user, int vmid, One line? src/jdk.jstatd/share/classes/sun/tools/jstatd/RemoteHostImpl.java line 74: > 72: Integer v = lvmid; > 73: RemoteVm stub = null; > 74: StringBuilder sb = new StringBuilder(); Suggestion: String vmidStr = "local://" + lvmid + "@localhost"; ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8622 From iklam at openjdk.java.net Wed May 11 02:43:21 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 11 May 2022 02:43:21 GMT Subject: RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach() [v2] In-Reply-To: References: Message-ID: > The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified. > > It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode. > > I also cleaned up related code in the JDK and HotSpot. > > Testing: > - Passed tiers 1 and 2 > - Tiers 3, 4, 5 are in progress Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8622/files - new: https://git.openjdk.java.net/jdk/pull/8622/files/22c22c30..34a01f71 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8622&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8622&range=00-01 Stats: 14 lines in 5 files changed: 1 ins; 7 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8622.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8622/head:pull/8622 PR: https://git.openjdk.java.net/jdk/pull/8622 From iklam at openjdk.java.net Wed May 11 02:43:24 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 11 May 2022 02:43:24 GMT Subject: RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach() [v2] In-Reply-To: <5AjTeD3XkuyBV8Dux7QVRkJgDwTiJ4Et9303eiMLjNU=.84477522-bbdb-4215-976f-729910707634@github.com> References: <5AjTeD3XkuyBV8Dux7QVRkJgDwTiJ4Et9303eiMLjNU=.84477522-bbdb-4215-976f-729910707634@github.com> Message-ID: On Tue, 10 May 2022 21:43:44 GMT, Claes Redestad wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > src/hotspot/os/windows/perfMemory_windows.cpp line 1781: > >> 1779: // address space. >> 1780: // >> 1781: void PerfMemory::attach(const char* user, int vmid, > > One line? Fixed > src/hotspot/share/prims/perf.cpp line 84: > >> 82: >> 83: // attach to the PerfData memory region for the specified VM >> 84: PerfMemory::attach(user_utf, vmid, > > One line? Fixed > src/hotspot/share/runtime/perfMemory.hpp line 146: > >> 144: // methods for attaching to and detaching from the PerfData >> 145: // memory segment of another JVM process on the same system. >> 146: static void attach(const char* user, int vmid, > > One line? Fixed > src/jdk.jstatd/share/classes/sun/tools/jstatd/RemoteHostImpl.java line 74: > >> 72: Integer v = lvmid; >> 73: RemoteVm stub = null; >> 74: StringBuilder sb = new StringBuilder(); > > Suggestion: > > String vmidStr = "local://" + lvmid + "@localhost"; Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/8622 From iklam at openjdk.java.net Wed May 11 02:43:25 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 11 May 2022 02:43:25 GMT Subject: RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach() [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 19:59:41 GMT, Alan Bateman wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/PerfDataBuffer.java line 60: > >> 58: FileChannel fc = new RandomAccessFile(f, "r").getChannel(); >> 59: ByteBuffer bb = fc.map(FileChannel.MapMode.READ_ONLY, 0L, (int)fc.size()); >> 60: fc.close(); // doesn't need to remain open > > I think you can change this to: > > > try (FileChannel fc = FileChannel.open(f.toPath())) { > ByteBuffer bb = ... > createPerfDataBuffer(bb, 0); > } Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8622 From iklam at openjdk.java.net Wed May 11 02:52:47 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 11 May 2022 02:52:47 GMT Subject: RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach() In-Reply-To: References: Message-ID: On Tue, 10 May 2022 20:03:45 GMT, Alan Bateman wrote: > I skimmed through the changes and I think they look okay. In the distant past there were tools outside of the JDK that used the jvmstat API directly. It's possible that VisualVM still does but it would only compile/run if --add-exports is used to export the sun.jvmstat.* packages. So it might be that dropping the parameter from a method in RemoteHost is noticed and I think that is okay because this package is not exported and is not meant to be used by code outside of the JDK. The APIs changed by this PR are: - sun.jvmstat.monitor.remote.RemoteHost::attachVm - sun.jvmstat.monitor.VmIdentifier::getMode - sun.jvmstat.monitor.HostIdentifier::getMode - jdk.internal.perf.Perf::attach I checked the latest VisualVM source code. Some of the above classes are referenced, but none of the affected APIs are called. ------------- PR: https://git.openjdk.java.net/jdk/pull/8622 From xgong at openjdk.java.net Wed May 11 03:26:57 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 11 May 2022 03:26:57 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v3] In-Reply-To: References: Message-ID: On Mon, 9 May 2022 21:55:27 GMT, Paul Sandoz wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename "use_predicate" to "needs_predicate" > > I modified the code of this PR to avoid the conversion of `boolean` to `int`, so a constant integer value is passed all the way through, and the masked load is made intrinsic from the method at which the constants are passed as arguments i.e. the public `fromArray` mask accepting method. Hi @PaulSandoz , thanks for the patch for the constant int parameter. I think the main change is: - ByteVector fromArray0Template(Class maskClass, C base, long offset, int index, M m, boolean offsetInRange, + ByteVector fromArray0Template(Class maskClass, C base, long offset, int index, M m, int offsetInRange, VectorSupport.LoadVectorMaskedOperation defaultImpl) { m.check(species()); ByteSpecies vsp = vspecies(); - if (offsetInRange) { - return VectorSupport.loadMasked( - vsp.vectorType(), maskClass, vsp.elementType(), vsp.laneCount(), - base, offset, m, /* offsetInRange */ 1, - base, index, vsp, defaultImpl); - } else { - return VectorSupport.loadMasked( - vsp.vectorType(), maskClass, vsp.elementType(), vsp.laneCount(), - base, offset, m, /* offsetInRange */ 0, - base, index, vsp, defaultImpl); - } + return VectorSupport.loadMasked( + vsp.vectorType(), maskClass, vsp.elementType(), vsp.laneCount(), + base, offset, m, offsetInRange == 1 ? 1 : 0, + base, index, vsp, defaultImpl); } which uses `offsetInRange == 1 ? 1 : 0`. Unfortunately this could not always make sure the `offsetInRange` a constant a the compiler time. Again, this change could also make the assertion fail randomly: --- a/src/hotspot/share/opto/vectorIntrinsics.cpp +++ b/src/hotspot/share/opto/vectorIntrinsics.cpp @@ -1236,6 +1236,7 @@ bool LibraryCallKit::inline_vector_mem_masked_operation(bool is_store) { } else { // Masked vector load with IOOBE always uses the predicated load. const TypeInt* offset_in_range = gvn().type(argument(8))->isa_int(); + assert(offset_in_range->is_con(), "must be a constant"); if (!offset_in_range->is_con()) { if (C->print_intrinsics()) { tty->print_cr(" ** missing constant: offsetInRange=%s", Sometimes, the compiler can parse it a constant. I think this depends on the compiler OSR and speculative optimization. Did you try an example with IOOBE on a non predicated hardware? Here is the main code of my unittest to reproduce the issue: static final VectorSpecies I_SPECIES = IntVector.SPECIES_128; static final int LENGTH = 1026; public static int[] ia; public static int[] ib; private static void init() { for (int i = 0; i < LENGTH; i++) { ia[i] = i; ib[i] = 0; } for (int i = 0; i < 2; i++) { m[i] = i % 2 == 0; } } private static void func() { VectorMask mask = VectorMask.fromArray(I_SPECIES, m, 0); for (int i = 0; i < LENGTH; i += vl) { IntVector av = IntVector.fromArray(I_SPECIES, ia, i, mask); av.lanewise(VectorOperators.ABS).intoArray(ic, i, mask); } } public static void main(String[] args) { init(); for (int i = 0; i < 10000; i++) { func(); } } ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From ysuenaga at openjdk.java.net Wed May 11 06:03:58 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 11 May 2022 06:03:58 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings Message-ID: I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. As you can see, the warnings spreads several areas. Let me know if I should separate them by area. * -Wstringop-overflow * src/hotspot/share/oops/array.hpp * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: ------------- Commit messages: - 8286562: GCC 12 reports some compiler warnings Changes: https://git.openjdk.java.net/jdk/pull/8646/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286562 Stats: 63 lines in 13 files changed: 51 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From rrich at openjdk.java.net Wed May 11 07:37:56 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 11 May 2022 07:37:56 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) [v3] In-Reply-To: References: Message-ID: > With this change `java -version` succeeds with the devkit build also the standard build on a ppc64le box does not crash anymore. > > Also tier1 tests don't look too bad. 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 11 additional commits since the last revision: - Impl. generate_jfr_write_checkpoint() after JDK-8286480 - Merge branch 'master' into fix_ppc_after_virtual_threads_integration - Martin's feedback - frame::patch_pc - frame::get_oop_map - Initialize new frame members - Fix Continuation::is_cont_barrier_frame - Fix ppc StubGenerator - TemplateInterpreterGenerator::generate_Continuation_doYield_entry - Fingerprinter::do_type_calling_convention - ... and 1 more: https://git.openjdk.java.net/jdk/compare/f0a6c870...c92b1b57 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8617/files - new: https://git.openjdk.java.net/jdk/pull/8617/files/ed466a24..c92b1b57 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8617&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8617&range=01-02 Stats: 7286 lines in 198 files changed: 4222 ins; 2135 del; 929 mod Patch: https://git.openjdk.java.net/jdk/pull/8617.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8617/head:pull/8617 PR: https://git.openjdk.java.net/jdk/pull/8617 From rrich at openjdk.java.net Wed May 11 07:55:53 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 11 May 2022 07:55:53 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) [v3] In-Reply-To: References: Message-ID: <4mJMMQ8ZFHOCHO_GS9uZK_PTK-6Dh-SbskieA6gRv5E=.a6a65edb-bc1b-42bc-b819-788645643f36@github.com> On Wed, 11 May 2022 07:37:56 GMT, Richard Reingruber wrote: >> With this change `java -version` succeeds with the devkit build also the standard build on a ppc64le box does not crash anymore. >> >> Also tier1 tests don't look too bad. > > 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 11 additional commits since the last revision: > > - Impl. generate_jfr_write_checkpoint() after JDK-8286480 > - Merge branch 'master' into fix_ppc_after_virtual_threads_integration > - Martin's feedback > - frame::patch_pc > - frame::get_oop_map > - Initialize new frame members > - Fix Continuation::is_cont_barrier_frame > - Fix ppc StubGenerator > - TemplateInterpreterGenerator::generate_Continuation_doYield_entry > - Fingerprinter::do_type_calling_convention > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/63afde54...c92b1b57 So I've merged master after #8631 and implemented `generate_jfr_write_checkpoint()`. Unfortunately I wasn't able to test anything except building since the ppc servers I normally use are not accessible since yesterday. C'est la vie... ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From ysuenaga at openjdk.java.net Wed May 11 08:40:21 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 11 May 2022 08:40:21 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Avoid pragma error in before GCC 12 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/8154f6ea..7f155256 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=00-01 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From shade at openjdk.java.net Wed May 11 08:57:51 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 11 May 2022 08:57:51 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) [v3] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 07:37:56 GMT, Richard Reingruber wrote: >> With this change `java -version` succeeds with the devkit build also the standard build on a ppc64le box does not crash anymore. >> >> Also tier1 tests don't look too bad. > > 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 11 additional commits since the last revision: > > - Impl. generate_jfr_write_checkpoint() after JDK-8286480 > - Merge branch 'master' into fix_ppc_after_virtual_threads_integration > - Martin's feedback > - frame::patch_pc > - frame::get_oop_map > - Initialize new frame members > - Fix Continuation::is_cont_barrier_frame > - Fix ppc StubGenerator > - TemplateInterpreterGenerator::generate_Continuation_doYield_entry > - Fingerprinter::do_type_calling_convention > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/94940268...c92b1b57 Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From shade at openjdk.java.net Wed May 11 08:57:53 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 11 May 2022 08:57:53 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) [v3] In-Reply-To: <4mJMMQ8ZFHOCHO_GS9uZK_PTK-6Dh-SbskieA6gRv5E=.a6a65edb-bc1b-42bc-b819-788645643f36@github.com> References: <4mJMMQ8ZFHOCHO_GS9uZK_PTK-6Dh-SbskieA6gRv5E=.a6a65edb-bc1b-42bc-b819-788645643f36@github.com> Message-ID: On Wed, 11 May 2022 07:52:04 GMT, Richard Reingruber wrote: > So I've merged master after #8631 and implemented `generate_jfr_write_checkpoint()`. Unfortunately I wasn't able to test anything except building since the ppc servers I normally use are not accessible since yesterday. C'est la vie... Should be fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From rrich at openjdk.java.net Wed May 11 09:03:50 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 11 May 2022 09:03:50 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) [v3] In-Reply-To: References: <4mJMMQ8ZFHOCHO_GS9uZK_PTK-6Dh-SbskieA6gRv5E=.a6a65edb-bc1b-42bc-b819-788645643f36@github.com> Message-ID: On Wed, 11 May 2022 08:54:05 GMT, Aleksey Shipilev wrote: >> So I've merged master after #8631 and implemented `generate_jfr_write_checkpoint()`. Unfortunately I wasn't able to test anything except building since the ppc servers I normally use are not accessible since yesterday. C'est la vie... > >> So I've merged master after #8631 and implemented `generate_jfr_write_checkpoint()`. Unfortunately I wasn't able to test anything except building since the ppc servers I normally use are not accessible since yesterday. C'est la vie... > > Should be fine. Thanks for reviewing @shipilev ! I just found a server where I've successfully tested `java -version`. I guess this is ready for integration. @TheRealMDoerr you might want to have a quick look at `generate_jfr_write_checkpoint()` before. ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From mdoerr at openjdk.java.net Wed May 11 09:47:46 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 11 May 2022 09:47:46 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) [v3] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 07:37:56 GMT, Richard Reingruber wrote: >> With this change `java -version` succeeds with the devkit build also the standard build on a ppc64le box does not crash anymore. >> >> Also tier1 tests don't look too bad. > > 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 11 additional commits since the last revision: > > - Impl. generate_jfr_write_checkpoint() after JDK-8286480 > - Merge branch 'master' into fix_ppc_after_virtual_threads_integration > - Martin's feedback > - frame::patch_pc > - frame::get_oop_map > - Initialize new frame members > - Fix Continuation::is_cont_barrier_frame > - Fix ppc StubGenerator > - TemplateInterpreterGenerator::generate_Continuation_doYield_entry > - Fingerprinter::do_type_calling_convention > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/335a9df0...c92b1b57 I couldn't spot any obvious bug. Still good. Thanks! ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8617 From mcimadamore at openjdk.java.net Wed May 11 10:39:44 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 11 May 2022 10:39:44 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v44] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits: - Merge branch 'master' into foreign-preview - Fix crashes in heap segment benchmarks due to misaligned access - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Add tests for loaderLookup/restricted method corner cases - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI * Tweak restricted method check to work when there's no caller class - Tweak examples in SymbolLookup javadoc - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Tweak support for Linker lookup Improve javadoc of SymbolLookup - ... and 54 more: https://git.openjdk.java.net/jdk/compare/73c5e993...cdd006e7 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7888/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=43 Stats: 65711 lines in 373 files changed: 43720 ins; 19432 del; 2559 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From jvernee at openjdk.java.net Wed May 11 10:45:12 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 10:45:12 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Tue, 10 May 2022 18:44:01 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/cpu/aarch64/frame_aarch64.cpp line 379: > >> 377: // need unextended_sp here, since normal sp is wrong for interpreter callees >> 378: return reinterpret_cast( >> 379: reinterpret_cast(frame.unextended_sp()) + in_bytes(_frame_data_offset)); > > Maybe use `address` instead of `char*`? Ok. I think I used `char*` to try and avoid a potential strict-aliasing violation, but I don't think we compile with that turned on any ways. Will change it to `address` (for x86 too) ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 10:50:47 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 10:50:47 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Tue, 10 May 2022 18:48:08 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5547: > >> 5545: } else if (dst.first()->is_stack()) { >> 5546: // reg to stack >> 5547: // Do we really have to sign extend??? > > Obsolete? Remove? Yes, this looks like it can be removed. (was copied over from SharedRuntime_aarch64) ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 10:55:09 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 10:55:09 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Tue, 10 May 2022 18:55:03 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/cpu/x86/foreign_globals_x86.hpp line 30: > >> 28: #include "utilities/growableArray.hpp" >> 29: >> 30: class outputStream; > > Redundant declaration? Yeah, this whole file is redundant :) (replaced by foreign_globals_x86_64.hpp) ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 11:02:47 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 11:02:47 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Tue, 10 May 2022 19:16:35 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/share/code/codeBlob.hpp line 754: > >> 752: class ProgrammableUpcallHandler; >> 753: >> 754: class OptimizedEntryBlob: public RuntimeBlob { > > What's the motivation to move `OptimizedEntryBlob` up in the hierarchy (from `BufferBlob` to `RuntimeBlob`)? Some of it is discussed here: https://github.com/openjdk/panama-foreign/pull/617 Essentially, it is to avoid accidentally inheriting behavior from BufferBlob which we don't want. Also, BufferBlob currently expects a fixed-sized header (`sizeof(BufferBlob)`), while OptimizedEntryBlobs has fields, so we'd have to pass the real header size to the `BufferBlob` constructor, which is a bit messy. It felt better to just cleanly break away from BufferBlob. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 11:09:52 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 11:09:52 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Tue, 10 May 2022 19:21:58 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/share/opto/callGenerator.cpp line 1131: > >> 1129: >> 1130: case vmIntrinsics::_linkToNative: >> 1131: print_inlining_failure(C, callee, jvms->depth() - 1, jvms->bci(), > > Why is it unconditionally reported as inlining failure? The call that is being processed here is `linkToNative`, and that call is not inlined, so reporting an inlining failure seems correct. We still go through the method handle trampoline stub which loads the actual target from the NativeEntryPoint (`jump_to_native_invoker` in methodHandles_x86.cpp). It's potentially faster here to generate a runtime call to the underlying invoker/downcall stub if the NativeEntryPoint is constant (i.e. avoid the lookup through NEP in the MH trampoline), but I hadn't gotten to investigating that yet. >From comparing the benchmark times between this and the old implementation (which generated an inline call), they are not all that different. So it seemed that doing something special here would not save that much time any ways. (but, still would be good to investigate at some point) ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 11:13:53 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 11:13:53 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Tue, 10 May 2022 20:30:09 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/share/prims/foreign_globals.cpp line 147: > >> 145: // based on ComputeMoveOrder from x86_64 shared runtime code. >> 146: // with some changes. >> 147: class ForeignCMO: public StackObj { > > Considering how seldom it is used, I don't see much value in abbreviating it. Also, the comment is misleading: there's no such entity as `ComputeMoveOrder` in the code. And `compute_move_order` is completely removed by this change. Good points, I think we can just rename this class to `ComputeMoveOrder` at this point. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 11:28:05 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 11:28:05 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Tue, 10 May 2022 20:48:47 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/share/prims/foreign_globals.hpp line 35: > >> 33: #include CPU_HEADER(foreign_globals) >> 34: >> 35: class CallConvClosure { > > Just a question on terminology: why is it called a `Closure`? It is the terminology used in other parts of hotspot for function objects it seems. See for instance the classes in `iterator.hpp` > src/hotspot/share/prims/foreign_globals.hpp line 62: > >> 60: >> 61: >> 62: class JavaCallConv : public CallConvClosure { > > Does it really worth to abbreviate `CallingConvention` to `CallConv`? Maybe not... I'll spell out the full thing. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From ihse at openjdk.java.net Wed May 11 11:50:50 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 11 May 2022 11:50:50 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: <-mPdhdleBhN1u3x1eNcP5p7LThXEeyIUCWVYrzJwEXM=.4b165c47-4081-401d-9f7f-ffd40369a114@github.com> On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Avoid pragma error in before GCC 12 The harfbuzz disabled warning looks good, so build changes are approved. You'll still need approval for the rest of the changes. While it's not my place really to say about the code changes, I think hiding the warnings with pragmas like this is the least attractive option. But if the code owners are okay with it... ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8646 From jvernee at openjdk.java.net Wed May 11 12:08:53 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 12:08:53 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Tue, 10 May 2022 21:01:48 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 306: > >> 304: intptr_t exception_handler_offset = __ pc() - start; >> 305: >> 306: // Native caller has no idea how to handle exceptions, > > Can you elaborate, please, how it is expected to work in presence of asynchronous exceptions? I'd expect to see a code which unconditionally clears pending exception with an assertion that verifies that the exception is of expected type. We have an exception handler in Java as well, so this code is only a fail safe. But, I think in the case of asynchronous exceptions this might be problematic if the exception is discovered by the current thread outside of the Java exception handler, turned into a synchronous exception and then we get here and call `ProgrammableUpcallhandler::handle_uncaught_exception` and then crash. Or if the asynchronous exception is discovered in `ProgrammableUpcallHandler::on_exit` (where there is currently an assert for no exceptions). I think you're right that, in both of those cases, if the exception is asynchronous, we should just ignore it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 12:19:05 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 12:19:05 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Wed, 11 May 2022 10:51:10 GMT, Jorn Vernee wrote: >> src/hotspot/cpu/x86/foreign_globals_x86.hpp line 30: >> >>> 28: #include "utilities/growableArray.hpp" >>> 29: >>> 30: class outputStream; >> >> Redundant declaration? > > Yeah, this whole file is redundant :) (replaced by foreign_globals_x86_64.hpp) Hmm, it doesn't look like having x64 specific header files is support by the CPU_HEADER macros. Will stick to the shared header file for x86_32 and x86_64 for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 12:23:59 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 12:23:59 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Tue, 10 May 2022 20:45:02 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/cpu/x86/foreign_globals_x86_64.cpp line 52: > >> 50: >> 51: objArrayOop inputStorage = jdk_internal_foreign_abi_ABIDescriptor::inputStorage(abi_oop); >> 52: loadArray(inputStorage, INTEGER_TYPE, abi._integer_argument_registers, as_Register); > > `loadArray` helper looks a bit misleading. In presence of `javaClass`-style accessors, it misleadingly hints that it refers to some Java-level operation/entity, though what it does it parses register list representation backed by a Java array. I suggest to rename it to something like `parse_argument_registers_array()`). I went with `parse_register_array` (since it's also used for return registers) ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 12:24:02 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 12:24:02 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 20:53:37 GMT, Vladimir Ivanov wrote: >> src/hotspot/share/utilities/growableArray.hpp line 151: >> >>> 149: return _data; >>> 150: } >>> 151: >> >> This accessor is added to be able to temporarily view a stable GrowableArray instance as a C-style array. It is used to by `NativeCallConv` and `RegSpiller` in `foreign_globals.hpp`. >> >> GrowableArray already has an `adr_at` accessor that does something similar, but using `adr_at(0)` fails on empty growable arrays since it also performs a bounds check. So it can not be used. > > Any problems with migrating `CallConv` and `RegSpiller`away from ` VMReg* + int` to `GrowableArray`? I'll try migrating to `GrowableArray` ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From ysuenaga at openjdk.java.net Wed May 11 12:38:58 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 11 May 2022 12:38:58 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: <-mPdhdleBhN1u3x1eNcP5p7LThXEeyIUCWVYrzJwEXM=.4b165c47-4081-401d-9f7f-ffd40369a114@github.com> References: <-mPdhdleBhN1u3x1eNcP5p7LThXEeyIUCWVYrzJwEXM=.4b165c47-4081-401d-9f7f-ffd40369a114@github.com> Message-ID: On Wed, 11 May 2022 11:48:00 GMT, Magnus Ihse Bursie wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > The harfbuzz disabled warning looks good, so build changes are approved. You'll still need approval for the rest of the changes. > > While it's not my place really to say about the code changes, I think hiding the warnings with pragmas like this is the least attractive option. But if the code owners are okay with it... Thanks @magicus for your review! > While it's not my place really to say about the code changes, I think hiding the warnings with pragmas like this is the least attractive option. But if the code owners are okay with it... Agree, so I fixed bugs which were found out by compiler warnings in this PR - they are in libjli. I think we can ignore the others because they are already checked in other methods (e.g. `assert`), or due to structure of `Array` class which has payload in `_data[1]` (and it is also checked in `assert`). ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Wed May 11 12:43:01 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 11 May 2022 12:43:01 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: <2NpNw3Q9tkAShuydzhDKopMf3mLCyAwmSFoWzC665pI=.dbe3b460-d267-42ab-b08d-553bf133b796@github.com> On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Avoid pragma error in before GCC 12 It is better to add pragma to `Array::at_put()` in src/hotspot/share/oops/array.hpp , but I couldn't suppress warnings. So I added pragmas to its caller - bytecodeAssembler.cpp, classFileParser.cpp, symbolTable.cpp . ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From shade at openjdk.java.net Wed May 11 12:49:59 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 11 May 2022 12:49:59 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) [v3] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 07:37:56 GMT, Richard Reingruber wrote: >> With this change `java -version` succeeds with the devkit build also the standard build on a ppc64le box does not crash anymore. >> >> Also tier1 tests don't look too bad. > > 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 11 additional commits since the last revision: > > - Impl. generate_jfr_write_checkpoint() after JDK-8286480 > - Merge branch 'master' into fix_ppc_after_virtual_threads_integration > - Martin's feedback > - frame::patch_pc > - frame::get_oop_map > - Initialize new frame members > - Fix Continuation::is_cont_barrier_frame > - Fix ppc StubGenerator > - TemplateInterpreterGenerator::generate_Continuation_doYield_entry > - Fingerprinter::do_type_calling_convention > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/dfcd510f...c92b1b57 FYI, I am waiting for this integration to proceed with other platforms. So if you wonder in what sequence we should do the merges, my x86_32 and ARM32 PRs yield in favor of this one :) ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From alanb at openjdk.java.net Wed May 11 12:51:56 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 11 May 2022 12:51:56 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Avoid pragma error in before GCC 12 src/java.base/unix/native/libjli/java_md_common.c line 135: > 133: if ((JLI_StrLen(indir) + JLI_StrLen(cmd) + 2) > sizeof(name)) return 0; > 134: JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); > 135: #pragma GCC diagnostic pop Can we just replace this code rather than putting pragmas here? ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Wed May 11 13:24:38 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 11 May 2022 13:24:38 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 12:48:38 GMT, Alan Bateman wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > src/java.base/unix/native/libjli/java_md_common.c line 135: > >> 133: if ((JLI_StrLen(indir) + JLI_StrLen(cmd) + 2) > sizeof(name)) return 0; >> 134: JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); >> 135: #pragma GCC diagnostic pop > > Can we just replace this code rather than putting pragmas here? I tried several patterns, but I couldn't find out a solution other than pragmas. Do you have any ideas? For example: if ((JLI_StrLen(indir) + JLI_StrLen(cmd) + 2) < sizeof(name)) { JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); } else { return 0; } Compiler warnings: ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From rrich at openjdk.java.net Wed May 11 13:26:39 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 11 May 2022 13:26:39 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) [v3] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 12:46:42 GMT, Aleksey Shipilev wrote: > FYI, I am waiting for this integration to proceed with other platforms. So if you wonder in what sequence we should do the merges, my x86_32 and ARM32 PRs yield in favor of this one :) I wanted to wait for the GHA. Ok, there you go :) ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From rrich at openjdk.java.net Wed May 11 13:26:40 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 11 May 2022 13:26:40 GMT Subject: Integrated: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) In-Reply-To: References: Message-ID: On Mon, 9 May 2022 22:45:49 GMT, Richard Reingruber wrote: > With this change `java -version` succeeds with the devkit build also the standard build on a ppc64le box does not crash anymore. > > Also tier1 tests don't look too bad. This pull request has now been integrated. Changeset: 87f3d2b8 Author: Richard Reingruber URL: https://git.openjdk.java.net/jdk/commit/87f3d2b870a1534183c4a70db4526532bc858d04 Stats: 216 lines in 8 files changed: 166 ins; 12 del; 38 mod 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) Reviewed-by: mdoerr, coleenp, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From kbarrett at openjdk.java.net Wed May 11 14:01:52 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 11 May 2022 14:01:52 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 08:40:21 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Avoid pragma error in before GCC 12 Changes requested by kbarrett (Reviewer). make/modules/java.desktop/lib/Awt2dLibraries.gmk line 462: > 460: HARFBUZZ_DISABLED_WARNINGS_gcc := type-limits missing-field-initializers strict-aliasing > 461: HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-overflow \ > 462: maybe-uninitialized class-memaccess unused-result extra use-after-free Globally disabling use-after-free warnings for this package seems really questionable. If these are problems in the code, just suppressing the warning and leaving the problems to bite us seems like a bad idea. And the problems ought to be reported upstream to the HarfBuzz folks. src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 51: > 49: > 50: #define PRAGMA_STRINGOP_OVERFLOW_IGNORED \ > 51: PRAGMA_DISABLE_GCC_WARNING("-Wstringop-overflow") Are the reported problems with format/stringop-overflow real? Or are they false positives? If they are real then I'm not going to approve ignoring them, unless there is some urgent reason and there are followup bug reports for fixing them. src/java.base/share/native/libjli/java.c line 1629: > 1627: const char *arg = jargv[i]; > 1628: if (arg[0] == '-' && arg[1] == 'J') { > 1629: *nargv++ = (arg[2] == '\0') ? NULL : JLI_StringDup(arg + 2); Wow! src/java.base/unix/native/libjli/java_md_common.c line 135: > 133: if ((JLI_StrLen(indir) + JLI_StrLen(cmd) + 2) > sizeof(name)) return 0; > 134: JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); > 135: #pragma GCC diagnostic pop Wouldn't it be better to just call JLI_Snprintf without the precheck and check the result to determine whether it was successful or was truncated? I think that kind of check is supposed to make gcc's truncation checker happy. src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c line 193: > 191: #if defined(__GNUC__) && __GNUC__ >= 12 > 192: #pragma GCC diagnostic pop > 193: #endif Rather than all this warning suppression cruft and the comment explaining why it's okay, just compute the `(strBufNextChar - strBufBegin)` offset a few lines earlier, before the realloc. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From shade at openjdk.java.net Wed May 11 14:14:38 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 11 May 2022 14:14:38 GMT Subject: RFR: 8286476: x86_32: Fix crashes with non-preview mode after JDK-8284161 (Virtual Threads) [v5] In-Reply-To: <2uCMTSh-lg_tcEYZMpiAfHqiax8WXxRb4eEHzAsu12Y=.fb33363c-1f0a-4e46-959d-6e3fc5af89f6@github.com> References: <2uCMTSh-lg_tcEYZMpiAfHqiax8WXxRb4eEHzAsu12Y=.fb33363c-1f0a-4e46-959d-6e3fc5af89f6@github.com> Message-ID: <3TH-IYSvbSO6BiLMJMLIC5dg84a-v6QmnuO3-_KqC_0=.29aaf36d-f69c-4f1d-b6bc-dfdb2b8716bb@github.com> > Virtual Threads are not fully implemented on x86_32. The feature is guarded with `--enable-preview`. But there is some VM code that is executed unconditionally anyway, crashing the VM on some tests. This improves the x86_32 code to the point that tests without `--enable-preview` run successfully. This adds the scaffolding for full implementation too. > > Additional testing: > - [x] Linux x86_32 fastdebug, `tier1` failures only with `--enable-preview` > - [x] Linux x86_32 fastdebug, `tier2` failures only with `--enable-preview` Aleksey Shipilev 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 JDK-8286476-loom-x86-32-no-preview - Rebasing after JDK-8286480 - Merge branch 'master' into JDK-8286476-loom-x86-32-no-preview - x86-64 code still a bit wrong - Fix x86_64 release build - Fallback for 32-bit port signature helpers - Fix jdk_jfr ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8630/files - new: https://git.openjdk.java.net/jdk/pull/8630/files/3d510b80..3c12ac74 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8630&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8630&range=03-04 Stats: 6079 lines in 160 files changed: 3396 ins; 1467 del; 1216 mod Patch: https://git.openjdk.java.net/jdk/pull/8630.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8630/head:pull/8630 PR: https://git.openjdk.java.net/jdk/pull/8630 From shade at openjdk.java.net Wed May 11 14:18:57 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 11 May 2022 14:18:57 GMT Subject: RFR: 8286476: x86_32: Fix crashes with non-preview mode after JDK-8284161 (Virtual Threads) [v4] In-Reply-To: References: <2uCMTSh-lg_tcEYZMpiAfHqiax8WXxRb4eEHzAsu12Y=.fb33363c-1f0a-4e46-959d-6e3fc5af89f6@github.com> Message-ID: On Tue, 10 May 2022 15:29:40 GMT, Aleksey Shipilev wrote: >> Virtual Threads are not fully implemented on x86_32. The feature is guarded with `--enable-preview`. But there is some VM code that is executed unconditionally anyway, crashing the VM on some tests. This improves the x86_32 code to the point that tests without `--enable-preview` run successfully. This adds the scaffolding for full implementation too. >> >> Additional testing: >> - [x] Linux x86_32 fastdebug, `tier1` failures only with `--enable-preview` >> - [x] Linux x86_32 fastdebug, `tier2` failures only with `--enable-preview` > > Aleksey Shipilev 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: > > - Rebasing after JDK-8286480 > - Merge branch 'master' into JDK-8286476-loom-x86-32-no-preview > - x86-64 code still a bit wrong > - Fix x86_64 release build > - Fallback for 32-bit port signature helpers > - Fix jdk_jfr I merged from master to check there are no conflicts with PPC64 code. Looks fine on x86_32 side. ------------- PR: https://git.openjdk.java.net/jdk/pull/8630 From shade at openjdk.java.net Wed May 11 14:18:59 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 11 May 2022 14:18:59 GMT Subject: Integrated: 8286476: x86_32: Fix crashes with non-preview mode after JDK-8284161 (Virtual Threads) In-Reply-To: <2uCMTSh-lg_tcEYZMpiAfHqiax8WXxRb4eEHzAsu12Y=.fb33363c-1f0a-4e46-959d-6e3fc5af89f6@github.com> References: <2uCMTSh-lg_tcEYZMpiAfHqiax8WXxRb4eEHzAsu12Y=.fb33363c-1f0a-4e46-959d-6e3fc5af89f6@github.com> Message-ID: On Tue, 10 May 2022 13:42:03 GMT, Aleksey Shipilev wrote: > Virtual Threads are not fully implemented on x86_32. The feature is guarded with `--enable-preview`. But there is some VM code that is executed unconditionally anyway, crashing the VM on some tests. This improves the x86_32 code to the point that tests without `--enable-preview` run successfully. This adds the scaffolding for full implementation too. > > Additional testing: > - [x] Linux x86_32 fastdebug, `tier1` failures only with `--enable-preview` > - [x] Linux x86_32 fastdebug, `tier2` failures only with `--enable-preview` This pull request has now been integrated. Changeset: ae695d6c Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/ae695d6cb79afbca6e38ede59b366ec55eced76a Stats: 131 lines in 2 files changed: 122 ins; 4 del; 5 mod 8286476: x86_32: Fix crashes with non-preview mode after JDK-8284161 (Virtual Threads) Reviewed-by: coleenp, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/8630 From jvernee at openjdk.java.net Wed May 11 14:29:19 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 14:29:19 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v8] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: - Migrate to GrowableArray - Address some review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/43fd1b91..abd2b6ca Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=06-07 Stats: 254 lines in 23 files changed: 22 ins; 125 del; 107 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 14:29:25 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 14:29:25 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: <9eViilPD2YEH0Lt8StEhiGJfDlMSSa1NpPC02MKItuM=.0ce2490e-9a53-46b3-a14b-ab88b4a0f3fc@github.com> On Tue, 10 May 2022 21:02:39 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > Nice work! Looks good. Some minor comments/questions follow. @iwanowww Thanks for the review! I've addressed most comments already, but will have to think a bit on how to handle the asynchronous exceptions issue. > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5531: > >> 5529: } >> 5530: >> 5531: // On 64 bit we will store integer like items to the stack as > > Time for a cleanup? `64 bit` vs `64bit`, `abi`, `Aarch64`. I've cleaned up the spaces and capitalization here a bit. > src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 36: > >> 34: #include "code/nativeInst.hpp" >> 35: #include "code/vtableStubs.hpp" >> 36: #include "compiler/disassembler.hpp" > > Redundant includes? No new code added in the file. Good catch. Seems like a merge artifact maybe. Removing them seems to be fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From coleenp at openjdk.java.net Wed May 11 14:30:48 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 11 May 2022 14:30:48 GMT Subject: RFR: 8286556: Remove EagerInitialization develop option Message-ID: This is a long unused option which interferes with code I'm trying to replace, so removing it. Tested with tier1-4. ------------- Commit messages: - Remove EagerInitialization develop option Changes: https://git.openjdk.java.net/jdk/pull/8653/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8653&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286556 Stats: 72 lines in 5 files changed: 0 ins; 71 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8653.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8653/head:pull/8653 PR: https://git.openjdk.java.net/jdk/pull/8653 From rehn at openjdk.java.net Wed May 11 14:30:48 2022 From: rehn at openjdk.java.net (Robbin Ehn) Date: Wed, 11 May 2022 14:30:48 GMT Subject: RFR: 8286556: Remove EagerInitialization develop option In-Reply-To: References: Message-ID: On Wed, 11 May 2022 14:21:09 GMT, Coleen Phillimore wrote: > This is a long unused option which interferes with code I'm trying to replace, so removing it. > Tested with tier1-4. Looks good! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8653 From kbarrett at openjdk.java.net Wed May 11 14:31:02 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 11 May 2022 14:31:02 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 13:56:44 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > src/java.base/share/native/libjli/java.c line 1629: > >> 1627: const char *arg = jargv[i]; >> 1628: if (arg[0] == '-' && arg[1] == 'J') { >> 1629: *nargv++ = (arg[2] == '\0') ? NULL : JLI_StringDup(arg + 2); > > Wow! I wonder if the client expects NULL strings in the result, or if the NULL value should be an empty string? If empty strings are okay, this would be simpler without the conditional, just dup from arg + 2 to the terminating byte (which might be immediate). ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From jvernee at openjdk.java.net Wed May 11 14:33:56 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 14:33:56 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: On Wed, 11 May 2022 11:06:51 GMT, Jorn Vernee wrote: >> src/hotspot/share/opto/callGenerator.cpp line 1131: >> >>> 1129: >>> 1130: case vmIntrinsics::_linkToNative: >>> 1131: print_inlining_failure(C, callee, jvms->depth() - 1, jvms->bci(), >> >> Why is it unconditionally reported as inlining failure? > > The call that is being processed here is `linkToNative`, and that call is not inlined, so reporting an inlining failure seems correct. We still go through the method handle trampoline stub which loads the actual target from the NativeEntryPoint appendix argument (`jump_to_native_invoker` in methodHandles_x86.cpp). > > It's potentially faster here to generate a runtime call to the underlying invoker/downcall stub if the NativeEntryPoint is constant (i.e. avoid the lookup through NEP in the MH trampoline), but I hadn't gotten to investigating that yet. > > From comparing the benchmark times between this and the old implementation (which generated an inline call), they are not all that different. So it seemed that doing something special here would not save that much time any ways. (but, still would be good to investigate at some point) I've filed: https://bugs.openjdk.java.net/browse/JDK-8286588 ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 14:34:02 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 14:34:02 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: <1xENEcoejLZmUfLYTJsJ-nUWF9dlZ3BdXdpvSU_JoPk=.8efe4cde-cdc1-4174-a4a2-5437464f55d2@github.com> On Tue, 10 May 2022 20:38:05 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - Remove spurious ProblemList change >> - Pass pointer to LogStream >> - Polish >> - Replace TraceNativeInvokers flag with unified logging >> - Fix other platforms, take 2 >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91 > > src/hotspot/share/prims/foreign_globals.cpp line 217: > >> 215: >> 216: public: >> 217: ForeignCMO(int total_in_args, const VMRegPair* in_regs, int total_out_args, VMRegPair* out_regs, > > I propose to turn it into a trivial ctor and move all the logic into a helper static function which returns the computed moves. Done. Moved constructor logic into a `compute` method, and added a static helper that constructs a ComputeMoveOrder, calls `compute`, and then returns the moves. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From redestad at openjdk.java.net Wed May 11 15:01:49 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 11 May 2022 15:01:49 GMT Subject: RFR: 8286556: Remove EagerInitialization develop option In-Reply-To: References: Message-ID: On Wed, 11 May 2022 14:21:09 GMT, Coleen Phillimore wrote: > This is a long unused option which interferes with code I'm trying to replace, so removing it. > Tested with tier1-4. Nice! ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8653 From psandoz at openjdk.java.net Wed May 11 15:07:57 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 11 May 2022 15:07:57 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v3] In-Reply-To: References: Message-ID: <4LG2tZgoxvuaUEi78DyUrMbI9dIOM8CPk7GbkpZtp6M=.49894db1-a271-47a1-b8dc-68a1d5f46915@github.com> On Wed, 11 May 2022 03:23:13 GMT, Xiaohong Gong wrote: >> I modified the code of this PR to avoid the conversion of `boolean` to `int`, so a constant integer value is passed all the way through, and the masked load is made intrinsic from the method at which the constants are passed as arguments i.e. the public `fromArray` mask accepting method. > > Hi @PaulSandoz , thanks for the patch for the constant int parameter. I think the main change is: > > - ByteVector fromArray0Template(Class maskClass, C base, long offset, int index, M m, boolean offsetInRange, > + ByteVector fromArray0Template(Class maskClass, C base, long offset, int index, M m, int offsetInRange, > VectorSupport.LoadVectorMaskedOperation defaultImpl) { > m.check(species()); > ByteSpecies vsp = vspecies(); > - if (offsetInRange) { > - return VectorSupport.loadMasked( > - vsp.vectorType(), maskClass, vsp.elementType(), vsp.laneCount(), > - base, offset, m, /* offsetInRange */ 1, > - base, index, vsp, defaultImpl); > - } else { > - return VectorSupport.loadMasked( > - vsp.vectorType(), maskClass, vsp.elementType(), vsp.laneCount(), > - base, offset, m, /* offsetInRange */ 0, > - base, index, vsp, defaultImpl); > - } > + return VectorSupport.loadMasked( > + vsp.vectorType(), maskClass, vsp.elementType(), vsp.laneCount(), > + base, offset, m, offsetInRange == 1 ? 1 : 0, > + base, index, vsp, defaultImpl); > } > > which uses `offsetInRange == 1 ? 1 : 0`. Unfortunately this could not always make sure the `offsetInRange` a constant a the compiler time. Again, this change could also make the assertion fail randomly: > > --- a/src/hotspot/share/opto/vectorIntrinsics.cpp > +++ b/src/hotspot/share/opto/vectorIntrinsics.cpp > @@ -1236,6 +1236,7 @@ bool LibraryCallKit::inline_vector_mem_masked_operation(bool is_store) { > } else { > // Masked vector load with IOOBE always uses the predicated load. > const TypeInt* offset_in_range = gvn().type(argument(8))->isa_int(); > + assert(offset_in_range->is_con(), "must be a constant"); > if (!offset_in_range->is_con()) { > if (C->print_intrinsics()) { > tty->print_cr(" ** missing constant: offsetInRange=%s", > > Sometimes, the compiler can parse it a constant. I think this depends on the compiler OSR and speculative optimization. Did you try an example with IOOBE on a non predicated hardware? > > Here is the main code of my unittest to reproduce the issue: > > static final VectorSpecies I_SPECIES = IntVector.SPECIES_128; > static final int LENGTH = 1026; > public static int[] ia; > public static int[] ib; > > private static void init() { > for (int i = 0; i < LENGTH; i++) { > ia[i] = i; > ib[i] = 0; > } > > for (int i = 0; i < 2; i++) { > m[i] = i % 2 == 0; > } > } > > private static void func() { > VectorMask mask = VectorMask.fromArray(I_SPECIES, m, 0); > for (int i = 0; i < LENGTH; i += vl) { > IntVector av = IntVector.fromArray(I_SPECIES, ia, i, mask); > av.lanewise(VectorOperators.ABS).intoArray(ic, i, mask); > } > } > > public static void main(String[] args) { > init(); > for (int i = 0; i < 10000; i++) { > func(); > } > } @XiaohongGong Doh! The ternary was an experiment, and I forgot to re-run the code gen script before sending your the patch. See `IntVector`, which does not have that. I presume when the offset is not in range and the other code path is taken then it might be problematic unless all code paths are inlined. I will experiment further with tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From jvernee at openjdk.java.net Wed May 11 15:24:39 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 15:24:39 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v9] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Fix use of rt_call ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/abd2b6ca..c6754a1c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From coleenp at openjdk.java.net Wed May 11 15:35:49 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 11 May 2022 15:35:49 GMT Subject: RFR: 8286556: Remove EagerInitialization develop option In-Reply-To: References: Message-ID: On Wed, 11 May 2022 14:21:09 GMT, Coleen Phillimore wrote: > This is a long unused option which interferes with code I'm trying to replace, so removing it. > Tested with tier1-4. Do I hear a trivial? Thanks for the reviews Robbin and Claes! ------------- PR: https://git.openjdk.java.net/jdk/pull/8653 From tsteele at openjdk.java.net Wed May 11 15:35:56 2022 From: tsteele at openjdk.java.net (Tyler Steele) Date: Wed, 11 May 2022 15:35:56 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) [v3] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 13:20:31 GMT, Richard Reingruber wrote: >> FYI, I am waiting for this integration to proceed with other platforms. So if you wonder in what sequence we should do the merges, my x86_32 and ARM32 PRs yield in favor of this one :) > >> FYI, I am waiting for this integration to proceed with other platforms. So if you wonder in what sequence we should do the merges, my x86_32 and ARM32 PRs yield in favor of this one :) > > I wanted to wait for the GHA. Ok, there you go :) @reinrich This is very much appreciated ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From redestad at openjdk.java.net Wed May 11 15:45:52 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 11 May 2022 15:45:52 GMT Subject: RFR: 8286556: Remove EagerInitialization develop option In-Reply-To: References: Message-ID: On Wed, 11 May 2022 15:32:16 GMT, Coleen Phillimore wrote: > Do I hear a trivial? Sure! ------------- PR: https://git.openjdk.java.net/jdk/pull/8653 From jvernee at openjdk.java.net Wed May 11 15:47:11 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 15:47:11 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> Message-ID: <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> On Wed, 11 May 2022 12:05:29 GMT, Jorn Vernee wrote: >> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 306: >> >>> 304: intptr_t exception_handler_offset = __ pc() - start; >>> 305: >>> 306: // Native caller has no idea how to handle exceptions, >> >> Can you elaborate, please, how it is expected to work in presence of asynchronous exceptions? I'd expect to see a code which unconditionally clears pending exception with an assertion that verifies that the exception is of expected type. > > We have an exception handler in Java as well, so this code is only a fail safe. But, I think in the case of asynchronous exceptions this might be problematic if the exception is discovered by the current thread outside of the Java exception handler, turned into a synchronous exception and then we get here and call `ProgrammableUpcallhandler::handle_uncaught_exception` and then crash. Or if the asynchronous exception is discovered in `ProgrammableUpcallHandler::on_exit` (where there is currently an assert for no exceptions). > > I think you're right that, in both of those cases, if the exception is asynchronous, we should just ignore it. Discussed this with Maurizio as well. My understanding is as follows: 1. Async exceptions are installed into a thread's `pending_exception` field by handshake at a safepoint 2. From there they are "thrown" (I guess during the same safepoint?), in which case we either end up in a user-defined exception handler (higher up the stack), in our Java fallback exception handler (print stack trace and terminate), or in this fallback exception handler (print and terminate). 3. If we end up in this exception handler it means the async exception was installed somewhere outside of our Java exception handler and "thrown" from there. However, it also means that the Java code we were calling into completed abruptly. 4. We've previously established that we have no way of signalling to the native code that is calling us that something went wrong, and so the only safe option is to terminate, as to not leave the application in an inconsistent state. As a consequence, I don't think we have much choice in the case of async exceptions if we get here. Silently clearing them seems like it will leave the program in an inconsistent state (since we unwound some frames), so we have to terminate I think. (@dholmes-ora is my understanding of async exceptions in point 1. and 2. correct here?) ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 15:47:12 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 15:47:12 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v9] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 12:20:43 GMT, Jorn Vernee wrote: >> Any problems with migrating `CallConv` and `RegSpiller`away from ` VMReg* + int` to `GrowableArray`? > > I'll try migrating to `GrowableArray` Done. I've removed these accessors as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From rrich at openjdk.java.net Wed May 11 15:47:49 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 11 May 2022 15:47:49 GMT Subject: RFR: 8286446: PPC64: fix crashes after JDK-8284161 (virtual threads preview) [v3] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 13:20:31 GMT, Richard Reingruber wrote: >> FYI, I am waiting for this integration to proceed with other platforms. So if you wonder in what sequence we should do the merges, my x86_32 and ARM32 PRs yield in favor of this one :) > >> FYI, I am waiting for this integration to proceed with other platforms. So if you wonder in what sequence we should do the merges, my x86_32 and ARM32 PRs yield in favor of this one :) > > I wanted to wait for the GHA. Ok, there you go :) > @reinrich This is very much appreciated ?? Thanks :) ------------- PR: https://git.openjdk.java.net/jdk/pull/8617 From coleenp at openjdk.java.net Wed May 11 16:22:54 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 11 May 2022 16:22:54 GMT Subject: RFR: 8286556: Remove EagerInitialization develop option In-Reply-To: References: Message-ID: On Wed, 11 May 2022 14:21:09 GMT, Coleen Phillimore wrote: > This is a long unused option which interferes with code I'm trying to replace, so removing it. > Tested with tier1-4. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8653 From coleenp at openjdk.java.net Wed May 11 16:22:55 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 11 May 2022 16:22:55 GMT Subject: Integrated: 8286556: Remove EagerInitialization develop option In-Reply-To: References: Message-ID: On Wed, 11 May 2022 14:21:09 GMT, Coleen Phillimore wrote: > This is a long unused option which interferes with code I'm trying to replace, so removing it. > Tested with tier1-4. This pull request has now been integrated. Changeset: cec23b1b Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/cec23b1b078cd0c82063dda1af5a54ea561855c9 Stats: 72 lines in 5 files changed: 0 ins; 71 del; 1 mod 8286556: Remove EagerInitialization develop option Reviewed-by: rehn, redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/8653 From pchilanomate at openjdk.java.net Wed May 11 16:24:02 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 11 May 2022 16:24:02 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> Message-ID: <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> On Wed, 11 May 2022 15:44:19 GMT, Jorn Vernee wrote: >> We have an exception handler in Java as well, so this code is only a fail safe. But, I think in the case of asynchronous exceptions this might be problematic if the exception is discovered by the current thread outside of the Java exception handler, turned into a synchronous exception and then we get here and call `ProgrammableUpcallhandler::handle_uncaught_exception` and then crash. Or if the asynchronous exception is discovered in `ProgrammableUpcallHandler::on_exit` (where there is currently an assert for no exceptions). >> >> I think you're right that, in both of those cases, if the exception is asynchronous, we should just ignore it. > > Discussed this with Maurizio as well. > > My understanding is as follows: > 1. Async exceptions are installed into a thread's `pending_exception` field by handshake at a safepoint > 2. From there they are "thrown" (I guess during the same safepoint?), in which case we either end up in a user-defined exception handler (higher up the stack), in our Java fallback exception handler (print stack trace and terminate), or in this fallback exception handler (print and terminate). > 3. If we end up in this exception handler it means the async exception was installed somewhere outside of our Java exception handler and "thrown" from there. However, it also means that the Java code we were calling into completed abruptly. > 4. We've previously established that we have no way of signalling to the native code that is calling us that something went wrong, and so the only safe option is to terminate, as to not leave the application in an inconsistent state. > > As a consequence, I don't think we have much choice in the case of async exceptions if we get here. Silently clearing them seems like it will leave the program in an inconsistent state (since we unwound some frames), so we have to terminate I think. > > (@dholmes-ora is my understanding of async exceptions in point 1. and 2. correct here?) If you want to avoid processing asynchronous exceptions during this upcall you could block them (check NoAsyncExceptionDeliveryMark in JavaThread::exit()). Seems you could set the flag in ProgrammableUpcallhandler::on_entry() and unset it back on ProgrammableUpcallhandler::on_exit(). While that flag is set any asynchronous exception in the handshake queue of this thread will be skipped from processing. Maybe we should add a public method in the JavaThread class, block_async_exceptions()/unblock_async_exceptions() so we hide the handshake implementation. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 16:42:59 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 16:42:59 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> Message-ID: On Wed, 11 May 2022 16:20:32 GMT, Patricio Chilano Mateo wrote: >> Discussed this with Maurizio as well. >> >> My understanding is as follows: >> 1. Async exceptions are installed into a thread's `pending_exception` field by handshake at a safepoint >> 2. From there they are "thrown" (I guess during the same safepoint?), in which case we either end up in a user-defined exception handler (higher up the stack), in our Java fallback exception handler (print stack trace and terminate), or in this fallback exception handler (print and terminate). >> 3. If we end up in this exception handler it means the async exception was installed somewhere outside of our Java exception handler and "thrown" from there. However, it also means that the Java code we were calling into completed abruptly. >> 4. We've previously established that we have no way of signalling to the native code that is calling us that something went wrong, and so the only safe option is to terminate, as to not leave the application in an inconsistent state. >> >> As a consequence, I don't think we have much choice in the case of async exceptions if we get here. Silently clearing them seems like it will leave the program in an inconsistent state (since we unwound some frames), so we have to terminate I think. >> >> (@dholmes-ora is my understanding of async exceptions in point 1. and 2. correct here?) > > If you want to avoid processing asynchronous exceptions during this upcall you could block them (check NoAsyncExceptionDeliveryMark in JavaThread::exit()). Seems you could set the flag in ProgrammableUpcallhandler::on_entry() and unset it back on ProgrammableUpcallhandler::on_exit(). While that flag is set any asynchronous exception in the handshake queue of this thread will be skipped from processing. Maybe we should add a public method in the JavaThread class, block_async_exceptions()/unblock_async_exceptions() so we hide the handshake implementation. Oh nice! I was just thinking that the only possible way out of this conundrum would be to somehow block the delivery of async exceptions (at least outside of the user's exception handler). So, that seems to be exactly what we need :) ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 17:51:31 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 17:51:31 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v10] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: - Block async exceptions during upcalls - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 - Fix use of rt_call - Migrate to GrowableArray - Address some review comments - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 - Remove unneeded ComputeMoveOrder - Remove comment about native calls in lcm.cpp - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 Reviewed-by: jvernee, mcimadamore - Update riscv and arm stubs - ... and 16 more: https://git.openjdk.java.net/jdk/compare/cdd006e7...b29ad8f4 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7959/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=09 Stats: 6870 lines in 157 files changed: 2596 ins; 3218 del; 1056 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Wed May 11 17:58:46 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 11 May 2022 17:58:46 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> Message-ID: On Wed, 11 May 2022 16:38:54 GMT, Jorn Vernee wrote: >> If you want to avoid processing asynchronous exceptions during this upcall you could block them (check NoAsyncExceptionDeliveryMark in JavaThread::exit()). Seems you could set the flag in ProgrammableUpcallhandler::on_entry() and unset it back on ProgrammableUpcallhandler::on_exit(). While that flag is set any asynchronous exception in the handshake queue of this thread will be skipped from processing. Maybe we should add a public method in the JavaThread class, block_async_exceptions()/unblock_async_exceptions() so we hide the handshake implementation. > > Oh nice! I was just thinking that the only possible way out of this conundrum would be to somehow block the delivery of async exceptions (at least outside of the user's exception handler). So, that seems to be exactly what we need :) I went ahead and implemented this suggestion. Now we block async exceptions in on_entry, and unblock in on_exit. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From alanb at openjdk.java.net Wed May 11 18:12:53 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 11 May 2022 18:12:53 GMT Subject: RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach() [v2] In-Reply-To: References: Message-ID: <_-q4dXADJO6xSX8M9-NhCN7WcPzea67b7Dr6VTru5Ug=.f06265df-c88e-40ab-8955-dfdf00157dab@github.com> On Wed, 11 May 2022 02:43:21 GMT, Ioi Lam wrote: >> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified. >> >> It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode. >> >> I also cleaned up related code in the JDK and HotSpot. >> >> Testing: >> - Passed tiers 1 and 2 >> - Tiers 3, 4, 5 are in progress > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8622 From prr at openjdk.java.net Wed May 11 19:14:03 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 11 May 2022 19:14:03 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 13:35:00 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > make/modules/java.desktop/lib/Awt2dLibraries.gmk line 462: > >> 460: HARFBUZZ_DISABLED_WARNINGS_gcc := type-limits missing-field-initializers strict-aliasing >> 461: HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-overflow \ >> 462: maybe-uninitialized class-memaccess unused-result extra use-after-free > > Globally disabling use-after-free warnings for this package seems really > questionable. If these are problems in the code, just suppressing the warning > and leaving the problems to bite us seems like a bad idea. And the problems > ought to be reported upstream to the HarfBuzz folks. I don't understand what the actual warning is getting at .. can anyone explain it ? FWIW the code is still the same in upstream harfbuzz https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-font.cc ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From iklam at openjdk.java.net Wed May 11 19:29:57 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 11 May 2022 19:29:57 GMT Subject: RFR: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach() In-Reply-To: References: Message-ID: On Tue, 10 May 2022 20:03:45 GMT, Alan Bateman wrote: >> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified. >> >> It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode. >> >> I also cleaned up related code in the JDK and HotSpot. >> >> Testing: >> - Passed tiers 1 ~ 5 > > I skimmed through the changes and I think they look okay. In the distant past there were tools outside of the JDK that used the jvmstat API directly. It's possible that VisualVM still does but it would only compile/run if --add-exports is used to export the sun.jvmstat.* packages. So it might be that dropping the parameter from a method in RemoteHost is noticed and I think that is okay because this package is not exported and is not meant to be used by code outside of the JDK. Thanks to @AlanBateman and @cl4es for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8622 From iklam at openjdk.java.net Wed May 11 19:29:59 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 11 May 2022 19:29:59 GMT Subject: Integrated: 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach() In-Reply-To: References: Message-ID: On Tue, 10 May 2022 04:00:29 GMT, Ioi Lam wrote: > The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never supported the value `"rw"` since the source code was imported to the openjdk repo more than 15 years ago. In fact HotSpot throws `IllegalArgumentException` when such a mode is specified. > > It's unlikely such a mode will be required for future enhancements. Support for `"rw"` is removed. The "mode" parameter is also removed, since now `"r"` is the only supported mode. > > I also cleaned up related code in the JDK and HotSpot. > > Testing: > - Passed tiers 1 ~ 5 This pull request has now been integrated. Changeset: fcf49f42 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/fcf49f42cef4ac3e50b3b480aecf6fa38cf5be00 Stats: 205 lines in 15 files changed: 3 ins; 153 del; 49 mod 8286441: Remove mode parameter from jdk.internal.perf.Perf.attach() Reviewed-by: redestad, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/8622 From psandoz at openjdk.java.net Wed May 11 19:49:47 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 11 May 2022 19:49:47 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v3] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 08:56:07 GMT, Xiaohong Gong wrote: >> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception. >> >> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize): >> >> >> @ForceInline >> public static >> ByteVector fromArray(VectorSpecies species, >> byte[] a, int offset, >> VectorMask m) { >> ByteSpecies vsp = (ByteSpecies) species; >> if (offset >= 0 && offset <= (a.length - species.length())) { >> return vsp.dummyVector().fromArray0(a, offset, m); >> } >> >> // FIXME: optimize >> checkMaskFromIndexSize(offset, vsp, m, 1, a.length); >> return vsp.vOp(m, i -> a[offset + i]); >> } >> >> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed. >> >> Also adds the same vectorization support for masked: >> - fromByteArray/fromByteBuffer >> - fromBooleanArray >> - fromCharArray >> >> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system: >> >> Benchmark before After Units >> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE 737.542 1387.069 ops/ms >> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366 330.776 ops/ms >> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE 233.832 6125.026 ops/ms >> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE 233.816 7075.923 ops/ms >> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE 119.771 330.587 ops/ms >> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE 431.961 939.301 ops/ms >> >> Similar performance gain can also be observed on 512-bit SVE system. > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Rename "use_predicate" to "needs_predicate" I tried your test code with the patch and logged compilation (`-XX:-TieredCompilation -XX:+PrintCompilation -XX:+PrintInlining -XX:+PrintIntrinsics -Xbatch`) For `func` the first call to `VectorSupport::loadMasked` is intrinsic and inlined: @ 45 jdk.internal.vm.vector.VectorSupport::loadMasked (40 bytes) (intrinsic) But the second call (for the last loop iteration) fails to inline: @ 45 jdk.internal.vm.vector.VectorSupport::loadMasked (40 bytes) failed to inline (intrinsic) Since i am running on an mac book this looks right and aligns with the `-XX:+PrintIntrinsics` output: ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it ** not supported: op=loadMasked vlen=8 etype=int using_byte_array=0 ? I have not looked at the code gen nor measured performance comparing the case when never out of bounds and only out of bounds for the last loop iteration. ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From pchilanomate at openjdk.java.net Wed May 11 20:31:05 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 11 May 2022 20:31:05 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> Message-ID: On Wed, 11 May 2022 17:55:16 GMT, Jorn Vernee wrote: >> Oh nice! I was just thinking that the only possible way out of this conundrum would be to somehow block the delivery of async exceptions (at least outside of the user's exception handler). So, that seems to be exactly what we need :) > > I went ahead and implemented this suggestion. Now we block async exceptions in on_entry, and unblock in on_exit. Is it possible for these upcalls to be nested? If yes, we could add a boolean to context to avoid unsetting the flag in those nested cases. And now that I think we should probably add that check in NoAsyncExceptionDeliveryMark too if we allow broader use of this flag. David added the NoAsyncExceptionDeliveryMark code with that assert about nesting so maybe he might have more insights about that. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From iklam at openjdk.java.net Wed May 11 23:29:12 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 11 May 2022 23:29:12 GMT Subject: RFR: 8286560: Remove user parameter from jdk.internal.perf.Perf.attach() Message-ID: The API `jdk.internal.perf.Perf.::attach(String user, int lvmid)` is never used. It should be removed, and all the handling of a specified user name should be removed. ------------- Commit messages: - more cleanup - 8286560: Remove user parameter from jdk.internal.perf.Perf.attach() Changes: https://git.openjdk.java.net/jdk/pull/8669/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8669&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286560 Stats: 120 lines in 5 files changed: 2 ins; 95 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/8669.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8669/head:pull/8669 PR: https://git.openjdk.java.net/jdk/pull/8669 From ysuenaga at openjdk.java.net Thu May 12 00:29:47 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 00:29:47 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 19:11:16 GMT, Phil Race wrote: >> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 462: >> >>> 460: HARFBUZZ_DISABLED_WARNINGS_gcc := type-limits missing-field-initializers strict-aliasing >>> 461: HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := reorder delete-non-virtual-dtor strict-overflow \ >>> 462: maybe-uninitialized class-memaccess unused-result extra use-after-free >> >> Globally disabling use-after-free warnings for this package seems really >> questionable. If these are problems in the code, just suppressing the warning >> and leaving the problems to bite us seems like a bad idea. And the problems >> ought to be reported upstream to the HarfBuzz folks. > > I don't understand what the actual warning is getting at .. can anyone explain it ? > > FWIW the code is still the same in upstream harfbuzz > https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-font.cc I've pasted a part of warning messages to description of this PR, all of messages are here: In function 'void trampoline_reference(hb_trampoline_closure_t*)', inlined from 'void hb_font_funcs_set_glyph_func(hb_font_funcs_t*, hb_font_get_glyph_func_t, void*, hb_destroy_func_t)' at /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libharfbuzz/hb-font.cc:2368:24: ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 12 00:38:34 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 00:38:34 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 13:35:43 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 51: > >> 49: >> 50: #define PRAGMA_STRINGOP_OVERFLOW_IGNORED \ >> 51: PRAGMA_DISABLE_GCC_WARNING("-Wstringop-overflow") > > Are the reported problems with format/stringop-overflow real? Or are they > false positives? If they are real then I'm not going to approve ignoring them, > unless there is some urgent reason and there are followup bug reports for > fixing them. I think all of warnings in HotSpot are false-positives, so I added new pragmas to compilerWarnings.hpp, and use it in HotSpot code. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From dholmes at openjdk.java.net Thu May 12 01:02:48 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 12 May 2022 01:02:48 GMT Subject: RFR: 8286556: Remove EagerInitialization develop option In-Reply-To: References: Message-ID: On Wed, 11 May 2022 14:21:09 GMT, Coleen Phillimore wrote: > This is a long unused option which interferes with code I'm trying to replace, so removing it. > Tested with tier1-4. Interesting - for some reason I thought eager initialization was always on as it seemed a useful optimization. Though technically it might violate the spec if we have an API that exposes only initialized classes ... ------------- PR: https://git.openjdk.java.net/jdk/pull/8653 From ysuenaga at openjdk.java.net Thu May 12 01:11:39 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 01:11:39 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 14:27:27 GMT, Kim Barrett wrote: >> src/java.base/share/native/libjli/java.c line 1629: >> >>> 1627: const char *arg = jargv[i]; >>> 1628: if (arg[0] == '-' && arg[1] == 'J') { >>> 1629: *nargv++ = (arg[2] == '\0') ? NULL : JLI_StringDup(arg + 2); >> >> Wow! > > I wonder if the client expects NULL strings in the result, or if the NULL value should be an empty string? If empty strings are okay, this would be simpler without the conditional, just dup from arg + 2 to the terminating byte (which might be immediate). `NULL` affects as a loop stopper in `ParseArguments()` as following: static jboolean ParseArguments(int *pargc, char ***pargv, int *pmode, char **pwhat, int *pret, const char *jrepath) { int argc = *pargc; char **argv = *pargv; int mode = LM_UNKNOWN; char *arg; *pret = 0; while ((arg = *argv) != 0 && *arg == '-') { But I'm not sure it is valid, I think it might be discussed as another issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 12 01:17:36 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 01:17:36 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v3] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Use return value from JLI_Snprintf ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/7f155256..8d608414 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=01-02 Stats: 11 lines in 1 file changed: 4 ins; 5 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 12 01:17:37 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 01:17:37 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 13:43:55 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > src/java.base/unix/native/libjli/java_md_common.c line 135: > >> 133: if ((JLI_StrLen(indir) + JLI_StrLen(cmd) + 2) > sizeof(name)) return 0; >> 134: JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); >> 135: #pragma GCC diagnostic pop > > Wouldn't it be better to just call JLI_Snprintf without the precheck and check the result to determine whether it was successful or was truncated? I think that kind of check is supposed to make gcc's truncation checker happy. The warning has gone when using return value from `JLI_Snprintf()` in new commit! ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 12 01:27:30 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 01:27:30 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Calculate char offset before realloc() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/8d608414..b3afa3e0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=02-03 Stats: 18 lines in 1 file changed: 3 ins; 14 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 12 01:27:30 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 01:27:30 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 13:47:43 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Avoid pragma error in before GCC 12 > > src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c line 193: > >> 191: #if defined(__GNUC__) && __GNUC__ >= 12 >> 192: #pragma GCC diagnostic pop >> 193: #endif > > Rather than all this warning suppression cruft and the comment explaining why > it's okay, just compute the `(strBufNextChar - strBufBegin)` offset a few > lines earlier, before the realloc. I did do that in new commit, and the warning has gone! ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 12 01:32:42 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 12 May 2022 01:32:42 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 01:27:30 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Calculate char offset before realloc() Thanks for all to review this PR! I think we should separate this issue as following: * Suppress warnings * make/modules/java.desktop/lib/Awt2dLibraries.gmk * src/hotspot/share/classfile/bytecodeAssembler.cpp * src/hotspot/share/classfile/classFileParser.cpp * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp * src/hotspot/share/opto/memnode.cpp * src/hotspot/share/opto/type.cpp * src/hotspot/share/utilities/compilerWarnings.hpp * src/hotspot/share/utilities/compilerWarnings_gcc.hpp * src/java.base/unix/native/libjli/java_md_common.c * Bug fixes * src/java.base/share/native/libjli/java.c * src/java.base/share/native/libjli/parse_manifest.c * src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c I want to include the change of Awt2dLibraries.gmk (HarfBuzz) in this PR because it is 3rd party library. I will separate in above if I do not hear any objections, and this issue (PR) handles "suppress warnings" only. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From dholmes at openjdk.java.net Thu May 12 03:37:53 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 12 May 2022 03:37:53 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v10] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 17:51:31 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. >> >> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. >> >> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: >> >> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. >> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. >> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). >> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. >> >> While the patch mostly consists of VM changes, there are also some Java changes to support (2). >> >> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. >> >> Testing: Tier1-4 >> >> Thanks, >> Jorn >> >> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 >> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 >> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 >> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 >> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 >> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a >> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 >> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f >> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: > > - Block async exceptions during upcalls > - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 > - Fix use of rt_call > - Migrate to GrowableArray > - Address some review comments > - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 > - Remove unneeded ComputeMoveOrder > - Remove comment about native calls in lcm.cpp > - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 > > Reviewed-by: jvernee, mcimadamore > - Update riscv and arm stubs > - ... and 16 more: https://git.openjdk.java.net/jdk/compare/cdd006e7...b29ad8f4 src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp line 3: > 1: /* > 2: * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved. > 3: * Copyright (c) 2019, 2021, Arm Limited. All rights reserved. Only update third-party copyrights under direction from that copyright holder. This may not be the correct format for example. Also it is 2022. :) ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From dholmes at openjdk.java.net Thu May 12 03:37:54 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 12 May 2022 03:37:54 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> Message-ID: <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com> On Wed, 11 May 2022 20:27:42 GMT, Patricio Chilano Mateo wrote: >> I went ahead and implemented this suggestion. Now we block async exceptions in on_entry, and unblock in on_exit. > > Is it possible for these upcalls to be nested? If yes, we could add a boolean to context to avoid unsetting the flag in those nested cases. And now that I think we should probably add that check in NoAsyncExceptionDeliveryMark too if we allow broader use of this flag. David added the NoAsyncExceptionDeliveryMark code with that assert about nesting so maybe he might have more insights about that. NoAsyncExceptionDeliveryMark is not for general use! There is no provision for blocking async exceptions when running user-defined Java code. NoAsyncExceptionDeliveryMark was purely for protecting "system Java code". ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From xgong at openjdk.java.net Thu May 12 03:42:40 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 12 May 2022 03:42:40 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v3] In-Reply-To: References: Message-ID: On Wed, 11 May 2022 19:45:55 GMT, Paul Sandoz wrote: > I tried your test code with the patch and logged compilation (`-XX:-TieredCompilation -XX:+PrintCompilation -XX:+PrintInlining -XX:+PrintIntrinsics -Xbatch`) > > For `func` the first call to `VectorSupport::loadMasked` is intrinsic and inlined: > > ``` > @ 45 jdk.internal.vm.vector.VectorSupport::loadMasked (40 bytes) (intrinsic) > ``` > > But the second call (for the last loop iteration) fails to inline: > > ``` > @ 45 jdk.internal.vm.vector.VectorSupport::loadMasked (40 bytes) failed to inline (intrinsic) > ``` > > Since i am running on an mac book this looks right and aligns with the `-XX:+PrintIntrinsics` output: > > ``` > ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it > ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it > ** not supported: op=loadMasked vlen=8 etype=int using_byte_array=0 > ``` > > ? > > I have not looked at the code gen nor measured performance comparing the case when never out of bounds and only out of bounds for the last loop iteration. Yeah, it looks right from the log. Did you try to find whether there is the log `** missing constant: offsetInRange=Parm` with `XX:+PrintIntrinsics` ? Or insert an assertion in `vectorIntrinsics.cpp` like: --- a/src/hotspot/share/opto/vectorIntrinsics.cpp +++ b/src/hotspot/share/opto/vectorIntrinsics.cpp @@ -1236,6 +1236,7 @@ bool LibraryCallKit::inline_vector_mem_masked_operation(bool is_store) { } else { // Masked vector load with IOOBE always uses the predicated load. const TypeInt* offset_in_range = gvn().type(argument(8))->isa_int(); + assert(offset_in_range->is_con(), "must be a constant"); if (!offset_in_range->is_con()) { if (C->print_intrinsics()) { tty->print_cr(" ** missing constant: offsetInRange=%s", And run the tests with debug mode. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From dholmes at openjdk.java.net Thu May 12 04:09:41 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 12 May 2022 04:09:41 GMT Subject: RFR: 8286560: Remove user parameter from jdk.internal.perf.Perf.attach() In-Reply-To: References: Message-ID: On Wed, 11 May 2022 23:08:32 GMT, Ioi Lam wrote: > The API `jdk.internal.perf.Perf.::attach(String user, int lvmid)` is never used. It should be removed, and all the handling of a specified user name should be removed. Nice cleanup! I checked back in JDK 7 and couldn't find any use of this particular API. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8669 From duke at openjdk.java.net Thu May 12 07:32:56 2022 From: duke at openjdk.java.net (duke) Date: Thu, 12 May 2022 07:32:56 GMT Subject: Withdrawn: 8283147: Include NonJavaThread stacktrace during thread dump In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 02:40:15 GMT, Yi Yang wrote: > When we use jcmd Thread.dump/jstack , we could dump all Java thread stack trace, but unfortunately we are not able to print NonJavaThread stack trace such as VMThread/GCWorker, etc. For these threads, we know nothing about what are they doing/are they blocked in pthread condition from jstack output. An alternative is to use pstack, it internally attaches destination process and uses `thread apply all bt`, which introduces more overhead and much more dangerous. > > ====== JStack Ouput(Currrent) > > ... > "ApplicationImpl pooled thread 441" #1478 prio=4 os_prio=31 cpu=11.71ms elapsed=60.30s tid=0x00007f8d32171000 nid=0x22f23 waiting on condition [0x0000700010d5d000] > java.lang.Thread.State: TIMED_WAITING (parking) > at jdk.internal.misc.Unsafe.park(java.base at 11.0.11/Native Method) > - parking to wait for <0x00000007af851760> (a java.util.concurrent.SynchronousQueue$TransferStack) > at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 11.0.11/LockSupport.java:234) > at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base at 11.0.11/SynchronousQueue.java:462) > at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 11.0.11/SynchronousQueue.java:361) > at java.util.concurrent.SynchronousQueue.poll(java.base at 11.0.11/SynchronousQueue.java:937) > at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 11.0.11/ThreadPoolExecutor.java:1053) > at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 11.0.11/ThreadPoolExecutor.java:1114) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 11.0.11/ThreadPoolExecutor.java:628) > at java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(java.base at 11.0.11/Executors.java:668) > at java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(java.base at 11.0.11/Executors.java:665) > at java.security.AccessController.doPrivileged(java.base at 11.0.11/Native Method) > at java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(java.base at 11.0.11/Executors.java:665) > at java.lang.Thread.run(java.base at 11.0.11/Thread.java:829) > > "VM Thread" os_prio=31 cpu=31205.83ms elapsed=154131.15s tid=0x00007f8d49046000 nid=0x4703 runnable > > "GC Thread#0" os_prio=31 cpu=3811.96ms elapsed=154131.18s tid=0x00007f8d49809800 nid=0x3603 runnable > > "GC Thread#1" os_prio=31 cpu=3749.09ms elapsed=154130.24s tid=0x00007f8d4a9b3000 nid=0x6103 runnable > > "GC Thread#2" os_prio=31 cpu=3745.73ms elapsed=154129.74s tid=0x00007f8d48249000 nid=0x12f27 runnable > > "GC Thread#3" os_prio=31 cpu=3692.77ms elapsed=154129.74s tid=0x00007f8d48b93000 nid=0xe50b runnable > > "GC Thread#4" os_prio=31 cpu=3728.57ms elapsed=154129.74s tid=0x00007f8d47b0b000 nid=0xe603 runnable > > "GC Thread#5" os_prio=31 cpu=3726.08ms elapsed=154129.74s tid=0x00007f8d47afc800 nid=0xe803 runnable > > "GC Thread#6" os_prio=31 cpu=3660.35ms elapsed=154129.02s tid=0x00007f8d48de5800 nid=0x15d2f runnable > > "GC Thread#7" os_prio=31 cpu=3676.68ms elapsed=154129.02s tid=0x00007f8d48dc4800 nid=0x16103 runnable > > "GC Thread#8" os_prio=31 cpu=3676.15ms elapsed=154128.31s tid=0x00007f8d4849d800 nid=0x1f503 runnable > > "GC Thread#9" os_prio=31 cpu=3570.95ms elapsed=154128.31s tid=0x00007f8d494ab000 nid=0x1f303 runnable > > "CMS Main Thread" os_prio=31 cpu=6715.33ms elapsed=154131.18s tid=0x00007f8d4780f800 nid=0x4b03 runnable > > "CMS Thread#0" os_prio=31 cpu=2429.86ms elapsed=154131.18s tid=0x00007f8d4900e000 nid=0x3703 runnable > > "CMS Thread#1" os_prio=31 cpu=2422.35ms elapsed=154129.72s tid=0x00007f8d4d044000 nid=0x11a03 runnable > > "CMS Thread#2" os_prio=31 cpu=2418.81ms elapsed=154129.72s tid=0x00007f8d48b93800 nid=0xea03 runnable > > "VM Periodic Task Thread" os_prio=31 cpu=10658.80ms elapsed=154130.41s tid=0x00007f8d49035000 nid=0xa003 waiting on condition > > JNI global refs: 660, weak refs: 1217 > > > Most of above information makes no sense for further debugging. I think we can extend this functionality, e.g. add a new flag such as DumpAllThreadStackTrace, to print non java thread stack trace: > > ====== JStack Ouput(Modified) > > 2022-03-16 10:46:55 > Full thread dump OpenJDK 64-Bit Server VM (19-internal-adhoc.qingfengyy.jdktip mixed mode, sharing): > > Threads class SMR info: > _java_thread_list=0x00007f15040015f0, length=22, elements={ > 0x00007f159c0255b0, 0x00007f159c1babc0, 0x00007f159c1bc180, 0x00007f159c1c21d0, > 0x00007f159c1c36a0, 0x00007f159c1c4bb0, 0x00007f159c1c6730, 0x00007f159c1c7db0, > 0x00007f159c1c9330, 0x00007f159c1fc300, 0x00007f159c211a60, 0x00007f159c213b60, > 0x00007f159c302960, 0x00007f14cc0319d0, 0x00007f14cc0375c0, 0x00007f159c307e80, > 0x00007f159c30db30, 0x00007f159c3e6db0, 0x00007f159c647300, 0x00007f159c64b600, > 0x00007f159c678910, 0x00007f1504000be0 > } > > "main" #1 prio=5 os_prio=0 cpu=766.48ms elapsed=23.73s tid=0x00007f159c0255b0 nid=115919 in Object.wait() [0x00007f15a3e58000] > java.lang.Thread.State: TIMED_WAITING (on object monitor) > at java.lang.Object.wait(java.base at 19-internal/Native Method) > - waiting on > at jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.read(jdk.internal.le at 19-internal/NonBlockingInputStreamImpl.java:139) > - locked <0x00000000a2000368> (a jdk.internal.jshell.tool.ConsoleIOContext$1) > at jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 19-internal/NonBlockingInputStream.java:62) > at jdk.internal.org.jline.utils.NonBlocking$NonBlockingInputStreamReader.read(jdk.internal.le at 19-internal/NonBlocking.java:168) > at jdk.internal.org.jline.utils.NonBlockingReader.read(jdk.internal.le at 19-internal/NonBlockingReader.java:57) > at jdk.internal.org.jline.keymap.BindingReader.readCharacter(jdk.internal.le at 19-internal/BindingReader.java:160) > at jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 19-internal/BindingReader.java:110) > at jdk.internal.org.jline.keymap.BindingReader.readBinding(jdk.internal.le at 19-internal/BindingReader.java:61) > at jdk.internal.org.jline.reader.impl.LineReaderImpl.doReadBinding(jdk.internal.le at 19-internal/LineReaderImpl.java:923) > at jdk.internal.org.jline.reader.impl.LineReaderImpl.readBinding(jdk.internal.le at 19-internal/LineReaderImpl.java:956) > at jdk.internal.jshell.tool.ConsoleIOContext$2.readBinding(jdk.jshell at 19-internal/ConsoleIOContext.java:173) > at jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 19-internal/LineReaderImpl.java:651) > at jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(jdk.internal.le at 19-internal/LineReaderImpl.java:468) > at jdk.internal.jshell.tool.ConsoleIOContext.readLine(jdk.jshell at 19-internal/ConsoleIOContext.java:249) > at jdk.internal.jshell.tool.JShellTool.getInput(jdk.jshell at 19-internal/JShellTool.java:1281) > at jdk.internal.jshell.tool.JShellTool.run(jdk.jshell at 19-internal/JShellTool.java:1215) > at jdk.internal.jshell.tool.JShellTool.start(jdk.jshell at 19-internal/JShellTool.java:1001) > at jdk.internal.jshell.tool.JShellToolBuilder.start(jdk.jshell at 19-internal/JShellToolBuilder.java:261) > at jdk.internal.jshell.tool.JShellToolProvider.main(jdk.jshell at 19-internal/JShellToolProvider.java:120) > > "Reference Handler" #2 daemon prio=10 os_prio=0 cpu=1.04ms elapsed=23.72s tid=0x00007f159c1babc0 nid=115926 waiting on condition [0x00007f1529302000] > java.lang.Thread.State: RUNNABLE > at java.lang.ref.Reference.waitForReferencePendingList(java.base at 19-internal/Native Method) > at java.lang.ref.Reference.processPendingReferences(java.base at 19-internal/Reference.java:253) > at java.lang.ref.Reference$ReferenceHandler.run(java.base at 19-internal/Reference.java:215) > > "Finalizer" #3 daemon prio=8 os_prio=0 cpu=0.35ms elapsed=23.72s tid=0x00007f159c1bc180 nid=115927 in Object.wait() [0x00007f1529201000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(java.base at 19-internal/Native Method) > - waiting on <0x00000000a00002e8> (a java.lang.ref.ReferenceQueue$Lock) > at java.lang.ref.ReferenceQueue.remove(java.base at 19-internal/ReferenceQueue.java:155) > - locked <0x00000000a00002e8> (a java.lang.ref.ReferenceQueue$Lock) > at java.lang.ref.ReferenceQueue.remove(java.base at 19-internal/ReferenceQueue.java:176) > at java.lang.ref.Finalizer$FinalizerThread.run(java.base at 19-internal/Finalizer.java:183) > > "Signal Dispatcher" #4 daemon prio=9 os_prio=0 cpu=0.24ms elapsed=23.71s tid=0x00007f159c1c21d0 nid=115928 waiting on condition [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "Service Thread" #5 daemon prio=9 os_prio=0 cpu=0.20ms elapsed=23.71s tid=0x00007f159c1c36a0 nid=115929 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "Monitor Deflation Thread" #6 daemon prio=9 os_prio=0 cpu=0.24ms elapsed=23.71s tid=0x00007f159c1c4bb0 nid=115930 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "C2 CompilerThread0" #7 daemon prio=9 os_prio=0 cpu=527.71ms elapsed=23.71s tid=0x00007f159c1c6730 nid=115931 waiting on condition [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > No compile task > > "C1 CompilerThread0" #19 daemon prio=9 os_prio=0 cpu=216.87ms elapsed=23.71s tid=0x00007f159c1c7db0 nid=115932 waiting on condition [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > No compile task > > "Sweeper thread" #25 daemon prio=9 os_prio=0 cpu=0.04ms elapsed=23.71s tid=0x00007f159c1c9330 nid=115933 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "Notification Thread" #26 daemon prio=9 os_prio=0 cpu=0.05ms elapsed=23.70s tid=0x00007f159c1fc300 nid=115936 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "Common-Cleaner" #27 daemon prio=8 os_prio=0 cpu=0.99ms elapsed=23.68s tid=0x00007f159c211a60 nid=115938 in Object.wait() [0x00007f15282d2000] > java.lang.Thread.State: TIMED_WAITING (on object monitor) > at java.lang.Object.wait(java.base at 19-internal/Native Method) > - waiting on > at java.lang.ref.ReferenceQueue.remove(java.base at 19-internal/ReferenceQueue.java:155) > - locked <0x00000000a0000628> (a java.lang.ref.ReferenceQueue$Lock) > at jdk.internal.ref.CleanerImpl.run(java.base at 19-internal/CleanerImpl.java:140) > at java.lang.Thread.run(java.base at 19-internal/Thread.java:828) > at jdk.internal.misc.InnocuousThread.run(java.base at 19-internal/InnocuousThread.java:162) > > "Timer-0" #28 daemon prio=5 os_prio=0 cpu=0.10ms elapsed=23.68s tid=0x00007f159c213b60 nid=115939 in Object.wait() [0x00007f15281d1000] > java.lang.Thread.State: TIMED_WAITING (on object monitor) > at java.lang.Object.wait(java.base at 19-internal/Native Method) > - waiting on <0x00000000a00007e8> (a java.util.TaskQueue) > at java.util.TimerThread.mainLoop(java.base at 19-internal/Timer.java:563) > - locked <0x00000000a00007e8> (a java.util.TaskQueue) > at java.util.TimerThread.run(java.base at 19-internal/Timer.java:516) > > "process reaper" #30 daemon prio=10 os_prio=0 cpu=0.17ms elapsed=23.53s tid=0x00007f159c302960 nid=115944 runnable [0x00007f15a3c9e000] > java.lang.Thread.State: RUNNABLE > at java.lang.ProcessHandleImpl.waitForProcessExit0(java.base at 19-internal/Native Method) > at java.lang.ProcessHandleImpl$1.run(java.base at 19-internal/ProcessHandleImpl.java:147) > at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 19-internal/ThreadPoolExecutor.java:1136) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 19-internal/ThreadPoolExecutor.java:635) > at java.lang.Thread.run(java.base at 19-internal/Thread.java:828) > > "JDI Internal Event Handler" #34 daemon prio=5 os_prio=0 cpu=14.16ms elapsed=23.49s tid=0x00007f14cc0319d0 nid=115971 in Object.wait() [0x00007f15096b7000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(java.base at 19-internal/Native Method) > - waiting on > at java.lang.Object.wait(java.base at 19-internal/Object.java:338) > at com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 19-internal/EventQueueImpl.java:190) > - locked <0x00000000a0000e80> (a com.sun.tools.jdi.EventQueueImpl) > at com.sun.tools.jdi.EventQueueImpl.removeInternal(jdk.jdi at 19-internal/EventQueueImpl.java:125) > at com.sun.tools.jdi.InternalEventHandler.run(jdk.jdi at 19-internal/InternalEventHandler.java:61) > at java.lang.Thread.run(java.base at 19-internal/Thread.java:828) > > "JDI Target VM Interface" #33 daemon prio=5 os_prio=0 cpu=16.02ms elapsed=23.49s tid=0x00007f14cc0375c0 nid=115972 runnable [0x00007f15095b6000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.SocketDispatcher.read0(java.base at 19-internal/Native Method) > at sun.nio.ch.SocketDispatcher.read(java.base at 19-internal/SocketDispatcher.java:47) > at sun.nio.ch.NioSocketImpl.tryRead(java.base at 19-internal/NioSocketImpl.java:258) > at sun.nio.ch.NioSocketImpl.implRead(java.base at 19-internal/NioSocketImpl.java:309) > at sun.nio.ch.NioSocketImpl.read(java.base at 19-internal/NioSocketImpl.java:347) > at sun.nio.ch.NioSocketImpl$1.read(java.base at 19-internal/NioSocketImpl.java:800) > at java.net.Socket$SocketInputStream.read(java.base at 19-internal/Socket.java:966) > at java.net.Socket$SocketInputStream.read(java.base at 19-internal/Socket.java:961) > at com.sun.tools.jdi.SocketConnection.readPacket(jdk.jdi at 19-internal/SocketConnection.java:82) > - locked <0x00000000a00012e0> (a java.lang.Object) > at com.sun.tools.jdi.TargetVM.run(jdk.jdi at 19-internal/TargetVM.java:123) > at java.lang.Thread.run(java.base at 19-internal/Thread.java:828) > > "event-handler" #35 daemon prio=5 os_prio=0 cpu=8.29ms elapsed=23.48s tid=0x00007f159c307e80 nid=115973 in Object.wait() [0x00007f15098b9000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(java.base at 19-internal/Native Method) > - waiting on > at java.lang.Object.wait(java.base at 19-internal/Object.java:338) > at com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(jdk.jdi at 19-internal/EventQueueImpl.java:190) > - locked <0x00000000a0001e98> (a com.sun.tools.jdi.EventQueueImpl) > at com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 19-internal/EventQueueImpl.java:97) > at com.sun.tools.jdi.EventQueueImpl.remove(jdk.jdi at 19-internal/EventQueueImpl.java:83) > at jdk.jshell.execution.JdiEventHandler.run(jdk.jshell at 19-internal/JdiEventHandler.java:79) > at java.lang.Thread.run(java.base at 19-internal/Thread.java:828) > > "output reader" #36 daemon prio=5 os_prio=0 cpu=0.30ms elapsed=23.44s tid=0x00007f159c30db30 nid=115990 runnable [0x00007f15097b8000] > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.SocketDispatcher.read0(java.base at 19-internal/Native Method) > at sun.nio.ch.SocketDispatcher.read(java.base at 19-internal/SocketDispatcher.java:47) > at sun.nio.ch.NioSocketImpl.tryRead(java.base at 19-internal/NioSocketImpl.java:258) > at sun.nio.ch.NioSocketImpl.implRead(java.base at 19-internal/NioSocketImpl.java:309) > at sun.nio.ch.NioSocketImpl.read(java.base at 19-internal/NioSocketImpl.java:347) > at sun.nio.ch.NioSocketImpl$1.read(java.base at 19-internal/NioSocketImpl.java:800) > at java.net.Socket$SocketInputStream.read(java.base at 19-internal/Socket.java:966) > at java.net.Socket$SocketInputStream.read(java.base at 19-internal/Socket.java:961) > at java.io.FilterInputStream.read(java.base at 19-internal/FilterInputStream.java:79) > at jdk.jshell.execution.DemultiplexInput.run(jdk.jshell at 19-internal/DemultiplexInput.java:60) > > "Thread-1" #38 daemon prio=5 os_prio=0 cpu=222.19ms elapsed=23.37s tid=0x00007f159c3e6db0 nid=115995 waiting on condition [0x00007f15094b5000] > java.lang.Thread.State: WAITING (parking) > at jdk.internal.misc.Unsafe.park(java.base at 19-internal/Native Method) > - parking to wait for <0x00000000a007a880> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(java.base at 19-internal/LockSupport.java:341) > at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base at 19-internal/AbstractQueuedSynchronizer.java:506) > at java.util.concurrent.ForkJoinPool.unmanagedBlock(java.base at 19-internal/ForkJoinPool.java:3464) > at java.util.concurrent.ForkJoinPool.managedBlock(java.base at 19-internal/ForkJoinPool.java:3435) > at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 19-internal/AbstractQueuedSynchronizer.java:1623) > at java.util.concurrent.LinkedBlockingQueue.take(java.base at 19-internal/LinkedBlockingQueue.java:435) > at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 19-internal/ThreadPoolExecutor.java:1062) > at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 19-internal/ThreadPoolExecutor.java:1122) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 19-internal/ThreadPoolExecutor.java:635) > at java.lang.Thread.run(java.base at 19-internal/Thread.java:828) > > "process reaper" #40 daemon prio=10 os_prio=0 cpu=1.83ms elapsed=22.94s tid=0x00007f159c647300 nid=116044 waiting on condition [0x00007f15280d0000] > java.lang.Thread.State: TIMED_WAITING (parking) > at jdk.internal.misc.Unsafe.park(java.base at 19-internal/Native Method) > - parking to wait for <0x00000000a0079fb0> (a java.util.concurrent.SynchronousQueue$TransferStack) > at java.util.concurrent.locks.LockSupport.parkNanos(java.base at 19-internal/LockSupport.java:252) > at java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base at 19-internal/SynchronousQueue.java:401) > at java.util.concurrent.SynchronousQueue.poll(java.base at 19-internal/SynchronousQueue.java:903) > at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 19-internal/ThreadPoolExecutor.java:1061) > at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 19-internal/ThreadPoolExecutor.java:1122) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 19-internal/ThreadPoolExecutor.java:635) > at java.lang.Thread.run(java.base at 19-internal/Thread.java:828) > > "Thread-3" #41 daemon prio=5 os_prio=0 cpu=1.39ms elapsed=22.94s tid=0x00007f159c64b600 nid=116045 runnable [0x00007f14734ed000] > java.lang.Thread.State: RUNNABLE > at java.io.FileInputStream.read0(java.base at 19-internal/Native Method) > at java.io.FileInputStream.read(java.base at 19-internal/FileInputStream.java:228) > at jdk.internal.org.jline.terminal.impl.AbstractPty$PtyInputStream.read(jdk.internal.le at 19-internal/AbstractPty.java:73) > at jdk.internal.org.jline.utils.NonBlockingInputStream.read(jdk.internal.le at 19-internal/NonBlockingInputStream.java:62) > at jdk.internal.jshell.tool.StopDetectingInputStream.lambda$setInputStream$0(jdk.jshell at 19-internal/StopDetectingInputStream.java:74) > at jdk.internal.jshell.tool.StopDetectingInputStream$$Lambda$355/0x0000000800dd68d0.run(jdk.jshell at 19-internal/Unknown Source) > at java.lang.Thread.run(java.base at 19-internal/Thread.java:828) > > "null non blocking reader thread" #43 daemon prio=5 os_prio=0 cpu=0.15ms elapsed=22.78s tid=0x00007f159c678910 nid=116063 in Object.wait() [0x00007f1472ee6000] > java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(java.base at 19-internal/Native Method) > - waiting on > at java.lang.Object.wait(java.base at 19-internal/Object.java:338) > at jdk.internal.jshell.tool.StopDetectingInputStream.read(jdk.jshell at 19-internal/StopDetectingInputStream.java:111) > - locked <0x00000000a2000908> (a jdk.internal.jshell.tool.StopDetectingInputStream) > at jdk.internal.org.jline.utils.NonBlockingInputStreamImpl.run(jdk.internal.le at 19-internal/NonBlockingInputStreamImpl.java:216) > at jdk.internal.org.jline.utils.NonBlockingInputStreamImpl$$Lambda$530/0x0000000800dfde40.run(jdk.internal.le at 19-internal/Unknown Source) > at java.lang.Thread.run(java.base at 19-internal/Thread.java:828) > > "Attach Listener" #44 daemon prio=9 os_prio=0 cpu=0.17ms elapsed=0.10s tid=0x00007f1504000be0 nid=116383 waiting on condition [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > > "VM Thread" os_prio=0 cpu=8.31ms elapsed=23.72s tid=0x00007f159c1b78f0 nid=115925 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0xf21ec5] VM_PrintThreads::doit()+0x25 > V [libjvm.so+0xf225aa] VM_Operation::evaluate()+0xea > V [libjvm.so+0xf23f18] VMThread::evaluate_operation(VM_Operation*)+0xb8 > V [libjvm.so+0xf245c7] VMThread::inner_execute(VM_Operation*)+0x3a7 > V [libjvm.so+0xf24877] VMThread::run()+0xb7 > V [libjvm.so+0xe99770] Thread::call_run()+0xc0 > V [libjvm.so+0xc37a08] thread_native_entry(Thread*)+0xd8 > > "GC Thread#0" os_prio=0 cpu=39.19ms elapsed=23.73s tid=0x00007f159c066a10 nid=115920 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "GC Thread#1" os_prio=0 cpu=9.75ms elapsed=23.16s tid=0x00007f15180140e0 nid=116014 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "GC Thread#2" os_prio=0 cpu=0.48ms elapsed=23.15s tid=0x00007f151801b730 nid=116015 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "GC Thread#3" os_prio=0 cpu=11.09ms elapsed=23.15s tid=0x00007f151801c160 nid=116016 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "GC Thread#4" os_prio=0 cpu=24.95ms elapsed=23.15s tid=0x00007f151801ccc0 nid=116017 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "GC Thread#5" os_prio=0 cpu=0.58ms elapsed=23.15s tid=0x00007f151801d820 nid=116018 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "GC Thread#6" os_prio=0 cpu=35.58ms elapsed=23.15s tid=0x00007f151801e380 nid=116019 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "GC Thread#7" os_prio=0 cpu=13.88ms elapsed=22.98s tid=0x00007f151801b050 nid=116042 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "GC Thread#8" os_prio=0 cpu=12.97ms elapsed=22.92s tid=0x00007f1518021950 nid=116047 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "G1 Main Marker" os_prio=0 cpu=0.84ms elapsed=23.73s tid=0x00007f159c076ed0 nid=115921 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xba33] pthread_cond_wait+0xc3 > V [libjvm.so+0xbf1589] Monitor::wait_without_safepoint_check(long)+0x39 > V [libjvm.so+0x725fda] G1ConcurrentMarkThread::wait_for_next_cycle()+0x3a > V [libjvm.so+0x7270bb] G1ConcurrentMarkThread::run_service()+0xdb > V [libjvm.so+0x60be0b] ConcurrentGCThread::run()+0x1b > V [libjvm.so+0xe99770] Thread::call_run()+0xc0 > V [libjvm.so+0xc37a08] thread_native_entry(Thread*)+0xd8 > > "G1 Conc#0" os_prio=0 cpu=6.39ms elapsed=23.73s tid=0x00007f159c077f50 nid=115922 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "G1 Conc#1" os_prio=0 cpu=1.74ms elapsed=23.05s tid=0x00007f152c000960 nid=116022 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "G1 Conc#2" os_prio=0 cpu=1.23ms elapsed=23.05s tid=0x00007f152c001490 nid=116023 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "G1 Conc#3" os_prio=0 cpu=2.04ms elapsed=23.05s tid=0x00007f152c001ff0 nid=116024 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "G1 Conc#4" os_prio=0 cpu=1.28ms elapsed=23.05s tid=0x00007f152c002b50 nid=116025 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "G1 Conc#5" os_prio=0 cpu=1.60ms elapsed=23.05s tid=0x00007f152c0036b0 nid=116026 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "G1 Conc#6" os_prio=0 cpu=1.61ms elapsed=23.05s tid=0x00007f152c004210 nid=116027 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "G1 Conc#7" os_prio=0 cpu=2.00ms elapsed=23.05s tid=0x00007f152c005160 nid=116028 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "G1 Conc#8" os_prio=0 cpu=1.58ms elapsed=23.05s tid=0x00007f152c0060b0 nid=116029 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "G1 Conc#9" os_prio=0 cpu=1.26ms elapsed=23.05s tid=0x00007f152c007000 nid=116030 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "G1 Conc#10" os_prio=0 cpu=1.61ms elapsed=23.05s tid=0x00007f152c007f50 nid=116031 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "G1 Conc#11" os_prio=0 cpu=1.52ms elapsed=23.05s tid=0x00007f152c008ea0 nid=116032 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "G1 Conc#12" os_prio=0 cpu=1.17ms elapsed=23.05s tid=0x00007f152c009df0 nid=116033 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "G1 Conc#13" os_prio=0 cpu=1.88ms elapsed=23.05s tid=0x00007f152c00ad40 nid=116034 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "G1 Conc#14" os_prio=0 cpu=1.31ms elapsed=23.05s tid=0x00007f152c00bc90 nid=116035 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "G1 Conc#15" os_prio=0 cpu=1.52ms elapsed=23.05s tid=0x00007f152c00cbe0 nid=116036 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "G1 Refine#0" os_prio=0 cpu=0.03ms elapsed=23.73s tid=0x00007f159c1881d0 nid=115923 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > "G1 Service" os_prio=0 cpu=0.72ms elapsed=23.73s tid=0x00007f159c189290 nid=115924 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xbde2] pthread_cond_timedwait+0x132 > V [libjvm.so+0xbf1589] Monitor::wait_without_safepoint_check(long)+0x39 > V [libjvm.so+0x77d208] G1ServiceThread::wait_for_task()+0xf8 > V [libjvm.so+0x77d600] G1ServiceThread::run_service()+0x20 > V [libjvm.so+0x60be0b] ConcurrentGCThread::run()+0x1b > V [libjvm.so+0xe99770] Thread::call_run()+0xc0 > V [libjvm.so+0xc37a08] thread_native_entry(Thread*)+0xd8 > > "VM Periodic Task Thread" os_prio=0 cpu=4.05ms elapsed=23.71s tid=0x00007f159c1fddf0 nid=115937 waiting on condition > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libpthread.so.0+0xbde2] pthread_cond_timedwait+0x132 > V [libjvm.so+0xbf1589] Monitor::wait_without_safepoint_check(long)+0x39 > V [libjvm.so+0xc07015] WatcherThread::sleep() const+0xa5 > V [libjvm.so+0xc070e5] WatcherThread::run()+0x35 > V [libjvm.so+0xe99770] Thread::call_run()+0xc0 > V [libjvm.so+0xc37a08] thread_native_entry(Thread*)+0xd8 > > JNI global refs: 28, weak refs: 0 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7833 From aph at openjdk.java.net Thu May 12 07:57:47 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 12 May 2022 07:57:47 GMT Subject: RFR: 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call [v2] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 09:53:10 GMT, Evgeny Astigeevich wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1113: >> >>> 1111: // If a mark of the generated call BL is needed, a pointer to CodeBuffer keeping the generated code >>> 1112: // must be provided. >>> 1113: // >> >> What does "If a mark of the generated call BL is needed" mean? > > This is what is done in the function: > > address MacroAssembler::trampoline_call(Address entry, CodeBuffer* cbuf = NULL) { > ... > if (cbuf) cbuf->set_insts_mark(); > relocate(entry.rspec()); > if (!far_branches()) { > bl(entry.target()); > } else { > bl(pc()); > } > > > And most of the time NULL is passed. > I don't know how this code passed review. It smells badly. > What written is based on what I see: how the function is used. For example, can `cbuf` be any `CodeBuffer`? If not, how is it connected to the current CodeBuffer? If it is the same, why we pass a pointer but not a flag. Sorry, I didn't realize what "mark of the generated call" meant. Good point. I think it is likely that the `inst_mark` is no longer needed by the AArch64 back end. When we were experimenting with trampoline calls we did a lot of experiments, and I believe that `inst_mark` was needed at one time. However, I do not think that any current user of `trampoline_call()` uses the insts_mark for anything, and it could usefully be removed as part of a cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From ngasson at openjdk.java.net Thu May 12 08:27:00 2022 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 12 May 2022 08:27:00 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v10] In-Reply-To: References: Message-ID: <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com> On Thu, 12 May 2022 03:34:19 GMT, David Holmes wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits: >> >> - Block async exceptions during upcalls >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Fix use of rt_call >> - Migrate to GrowableArray >> - Address some review comments >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - Remove unneeded ComputeMoveOrder >> - Remove comment about native calls in lcm.cpp >> - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 >> >> Reviewed-by: jvernee, mcimadamore >> - Update riscv and arm stubs >> - ... and 16 more: https://git.openjdk.java.net/jdk/compare/cdd006e7...b29ad8f4 > > src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp line 3: > >> 1: /* >> 2: * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved. >> 3: * Copyright (c) 2019, 2021, Arm Limited. All rights reserved. > > Only update third-party copyrights under direction from that copyright holder. This may not be the correct format for example. > Also it is 2022. :) I think the Arm Ltd one was probably changed by me in one of the PRs in the Panama repo. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From aph-open at littlepinkcloud.com Thu May 12 08:49:06 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Thu, 12 May 2022 09:49:06 +0100 Subject: RFC onSpinWait() counter intrinsic. In-Reply-To: References: Message-ID: <82a6e221-2130-d219-b7e7-682ae0291c15@littlepinkcloud.com> On 5/10/22 18:02, Stuart Monteith wrote: > I'll be interested in hearing what people think. This looks like a very interesting ides. Evgeny, could you try this on some of your benchmarks? Thanks you, -- 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 Thu May 12 08:49:52 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 12 May 2022 08:49:52 GMT Subject: RFR: 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call [v2] In-Reply-To: <8tycniY0shUiB39KXvDRrsVwZXJzl3if-oIMMTSpagA=.dd03bb92-d186-4bb3-b2d3-ead0ab89fc7a@github.com> References: <0GK2fqUDn_e1Gmsqhx7uePDRo2WN5GbqbAId_SU5_ws=.6f0496a5-48a1-4172-9a3a-4cb973be0c45@github.com> <8tycniY0shUiB39KXvDRrsVwZXJzl3if-oIMMTSpagA=.dd03bb92-d186-4bb3-b2d3-ead0ab89fc7a@github.com> Message-ID: <-tSNRT1bLXKngsbwNrGDpLXje8WIkuDhw3qfQZZiHSs=.eacfd195-8b29-4141-963f-06e76a326a89@github.com> On Fri, 6 May 2022 10:06:51 GMT, Evgeny Astigeevich wrote: > Could you please be more neutral in your words? I apologize for my use of words. It was an inappropriate thing to say, and I wish I hadn't said it. If you would like to continue, perhaps we could work on this together, and come up with something we both like. Would you be happy to try that? I think it could look something like a list. Here's a rough sketch of what I think might work. AArch64 OpenJDK uses four different types of call direct call: bl address This is the shortest and the fastest, but only has a reach of ... far call: adrp; add; bl reg This is longer and slower than a direct call, but can reach anywhere in the code cache... trampoline call: This is only available in C2-compiled code. It is a combination of a direct call, which is used if the destination of a call is in range, and a register-indirect call. It has the advantages that it can reach anywhere in the AArch64 address space and that it is patchable at runtime when the generated code is being executed by other threads. bl trampoline Stub: trampoline: ldr reg, pc + 8 br reg <64-bit destination address> indirect call: move reg, address; blr reg This too can reach anywhere in the address space, but it cannot be patch while code is running, so it must be used at a safepoint. ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From jvernee at openjdk.java.net Thu May 12 09:28:59 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 09:28:59 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v11] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Revert "Block async exceptions during upcalls" This reverts commit b29ad8f46732666f2d07e63ce8701b1eb7bed790. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/b29ad8f4..1c04a42e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=09-10 Stats: 25 lines in 3 files changed: 0 ins; 21 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Thu May 12 09:29:00 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 09:29:00 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com> Message-ID: On Thu, 12 May 2022 03:32:15 GMT, David Holmes wrote: >> Is it possible for these upcalls to be nested? If yes, we could add a boolean to context to avoid unsetting the flag in those nested cases. And now that I think we should probably add that check in NoAsyncExceptionDeliveryMark too if we allow broader use of this flag. David added the NoAsyncExceptionDeliveryMark code with that assert about nesting so maybe he might have more insights about that. > > NoAsyncExceptionDeliveryMark is not for general use! There is no provision for blocking async exceptions when running user-defined Java code. NoAsyncExceptionDeliveryMark was purely for protecting "system Java code". Okay, I see. I think I acted a little too hastily on this yesterday. I'll revert the change that uses this blocking mechanism. The stack more or less looks like this during an upcall: | --- | | | --- | <1: user define try block with exception handler (maybe)> | | --- | <2: user code start> | | --- | <3: method handle impl frames 1> | | --- | <4: upcall wrapper class with fallback handler 1> | | --- | <5: method handle impl frames 2> | | --- | <6: upcallk stub with fallback handler 2> | | <7: unknown native code> | --- | | I think there are several options to address async exceptions: 1. Do nothing special for async exceptions. i.e. if they happen anywhere between 1. and 6. they will up in one of the fallback handlers and the VM will be terminated. 2. Block async exceptions in all code up from 6. 3. Somehow only block async exceptions only between 6. and 1. I think that is possible by changing the API so that the user passes us a method handle to their fallback exception handler. We would need 2 methods for blocking and unblocking async exceptions from Java. Then we could disable async exceptions at the start of 6. enabled them at the start of the try block in 4. (around the call to user code), and disable them at the end of this try block. Then finally re-enable them at the end of 6. If an exception occurs in the try block in 4., delegate to the user-defined exception handler (but use the VM terminate strategy as a fallback for when another exception occurs). The other problem I see with that is that to make that fast enough (i.e. not incur a ~1.5-2x cost on call overhead), we would need compiler intrinsics for the blocking/unblocking, and in the past we've been unable to define 'critical' sections of code like that in C2 (it's an unsolved problem at this point). ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Thu May 12 09:31:36 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 09:31:36 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v10] In-Reply-To: <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com> References: <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com> Message-ID: On Thu, 12 May 2022 08:23:11 GMT, Nick Gasson wrote: >> src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp line 3: >> >>> 1: /* >>> 2: * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved. >>> 3: * Copyright (c) 2019, 2021, Arm Limited. All rights reserved. >> >> Only update third-party copyrights under direction from that copyright holder. This may not be the correct format for example. >> Also it is 2022. :) > > I think the Arm Ltd one was probably changed by me in one of the PRs in the Panama repo. Right, I brought in these commits from the Panama repo, so this is from Nick's updates there (specifically from this PR: https://github.com/openjdk/panama-foreign/pull/610). I'm not sure what to do here. I own the PR, but Nick is a contributor on it, so some of the changes are his (including this copyright year change). ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From duke at openjdk.java.net Thu May 12 10:46:50 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Thu, 12 May 2022 10:46:50 GMT Subject: RFR: 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call [v2] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 22:49:43 GMT, Evgeny Astigeevich wrote: >> `MacroAssembler::trampoline_call` is for generating calls of targets which are inside CodeCache and can have relocInfo types: `runtime_call_type`, `opt_virtual_call_type`, `static_call_type` or `virtual_call_type`. >> This PR updates the description of the function and adds additional asserts. >> Tested a fastdebug build: >> - `gtest`: Passed >> - `tier1`: Passed > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Fix assert message Hi Andrew, > If you would like to continue, perhaps we could work on this together, and come up with something we both like. Would you be happy to try that? Sorry for the late response. I am on a business trip. Yes, I am keen to finish this. BTW, we have a new `trampoline_call1`: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp#L1101. This is a surprise from the project Loom. I'll try to handle it as well. > I apologize for my use of words. It was an inappropriate thing to say, and I wish I hadn't said it. Thank you. Apologies accepted. Thank you for the details. They helped a lot. Most of them are aligned with what I've read in sources and seen in a debugger. > trampoline call: ... It has the advantages that it can reach anywhere in the AArch64 address space. I created a bug: https://bugs.openjdk.java.net/browse/JDK-8286314. With small CodeCache, trampolines are not created for out of range targets which are outside CodeCache. > Ah, I think I see. Are you saying that a far call is not converted to a direct call when the code is moved into the code cache, even if a direct call might reach its target? And that far calls do not need a trampoline. I wanted to say that trampoline calls support link-time optimization: replacing a trampoline call by a direct one. Link-time optimization are not applied to far calls at the moment. Could I write in this way? BTW, if we are not going to relocate code (this is true for non-nmethod), we can patch far calls as well. During copying code to CodeCache, we can: - keep `adrp;add` but replace `blr` with `bl` - replace `adrp;add;blr` with `nop;nop;bl` What do you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From ihse at openjdk.java.net Thu May 12 11:04:08 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 12 May 2022 11:04:08 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: References: Message-ID: <-yJMgbHWlT4vecBv2EJIPe6_ITN_s8VYFkwnfPB67NM=.75b5fb61-88a0-4c01-800d-7a300dc6daac@github.com> On Thu, 12 May 2022 01:29:13 GMT, Yasumasa Suenaga wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Calculate char offset before realloc() > > Thanks for all to review this PR! I think we should separate this issue as following: > > * Suppress warnings > * make/modules/java.desktop/lib/Awt2dLibraries.gmk > * src/hotspot/share/classfile/bytecodeAssembler.cpp > * src/hotspot/share/classfile/classFileParser.cpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > * src/hotspot/share/opto/memnode.cpp > * src/hotspot/share/opto/type.cpp > * src/hotspot/share/utilities/compilerWarnings.hpp > * src/hotspot/share/utilities/compilerWarnings_gcc.hpp > * src/java.base/unix/native/libjli/java_md_common.c > * Bug fixes > * src/java.base/share/native/libjli/java.c > * src/java.base/share/native/libjli/parse_manifest.c > * src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c > > I want to include the change of Awt2dLibraries.gmk (HarfBuzz) in this PR because it is 3rd party library. > > I will separate in above if I do not hear any objections, and this issue (PR) handles "suppress warnings" only. @YaSuenag From my PoV this sounds like a good suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From mcimadamore at openjdk.java.net Thu May 12 12:12:55 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 12 May 2022 12:12:55 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com> Message-ID: On Thu, 12 May 2022 09:24:23 GMT, Jorn Vernee wrote: > Do nothing special for async exceptions. i.e. if they happen anywhere between 1. and 6. they will end up in one of the fallback handlers and the VM will be terminated. My understanding is that if they materialize while we're executing the upcall Java code, if that code has a try/catch block, we will go there, rather than crash the VM. In other words, IMHO the only problem with async exception is if they occur _after_ the Java user code has completed, because that will crash the Java adapter, this preventing it from returning to native call cleanly. So, either we disable async exceptions during that phase (e.g. after user code has executed, but before we return back to native code), or we just punt and stop. Since this seems like a corner^3 case, and since there are also other issue with upcalls that can occur if other threads do not cooperate (e.g. an upcall can get stuck into an infinite safepoint if the VM exits while an async native thread runs the upcall), and given that obtaining a linker is a restricted operation anyway, I don't think we should bend over backwards to try to add 1% more safety to something that's unavoidably sharp anyways. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From redestad at openjdk.java.net Thu May 12 12:19:05 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 12 May 2022 12:19:05 GMT Subject: RFR: 8286556: Remove EagerInitialization develop option In-Reply-To: References: Message-ID: On Thu, 12 May 2022 00:57:12 GMT, David Holmes wrote: >> This is a long unused option which interferes with code I'm trying to replace, so removing it. >> Tested with tier1-4. > > Interesting - for some reason I thought eager initialization was always on as it seemed a useful optimization. Though technically it might violate the spec if we have an API that exposes only initialized classes ... @dholmes-ora: If this eager initialization mechanism lead to the initialization of every class that gets loaded, say for the purpose of class verification, then it could - or rather would - lead to fascinating cascades of a lot of things getting eagerly loaded (and initialized) in turn - things that would typically never be loaded or initialized otherwise. Doesn't seem very helpful as an optimization. Not to mention that we have roped off some initialization to inner Holder classes in tricky places of the libraries to defer the initialization of certain things until things are up and running to avoid bootstrap issues, which means forced and eager initialization might lead to any number of bootstrapping bugs. ------------- PR: https://git.openjdk.java.net/jdk/pull/8653 From aph at openjdk.java.net Thu May 12 12:20:48 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 12 May 2022 12:20:48 GMT Subject: RFR: 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call [v2] In-Reply-To: References: Message-ID: <69NmNPPghBR3YWlrpjfMdkvKdsw5F8sRrVWaTt_8jZM=.22c4268f-0760-4ceb-808b-7fdafc8e0da0@github.com> On Thu, 5 May 2022 22:49:43 GMT, Evgeny Astigeevich wrote: >> `MacroAssembler::trampoline_call` is for generating calls of targets which are inside CodeCache and can have relocInfo types: `runtime_call_type`, `opt_virtual_call_type`, `static_call_type` or `virtual_call_type`. >> This PR updates the description of the function and adds additional asserts. >> Tested a fastdebug build: >> - `gtest`: Passed >> - `tier1`: Passed > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Fix assert message Hi, > Thank you for the details. They helped a lot. Most of them are aligned with what I've read in sources and seen in a debugger. > > > trampoline call: > > ... > > It has the advantages that it can > > reach anywhere in the AArch64 address space. > > I created a bug: https://bugs.openjdk.java.net/browse/JDK-8286314. With small CodeCache, trampolines are not created for out of range targets which are outside CodeCache. Oh! Thank you. I wonder why we never saw that one before. I guess because we don't normally have a small-enough CodeCache. > I wanted to say that trampoline calls support link-time optimization: replacing a trampoline call by a direct one. Link-time optimization are not applied to far calls at the moment. Could I write in this way? Sounds good. > BTW, if we are not going to relocate code (this is true for non-nmethod), we can patch far calls as well. During copying code to CodeCache, we can: > > * keep `adrp;add` but replace `blr` with `bl` > > * replace `adrp;add;blr` with `nop;nop;bl` > > What do you think? Either sounds fine. I guess the latter will be a bit more efficient. ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From shade at openjdk.java.net Thu May 12 13:00:04 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 12 May 2022 13:00:04 GMT Subject: RFR: 8286636: MacroAssembler::post_call_nop should have InstructionMark Message-ID: <9FGAXDJlzHK85Pz6nPimWEYlSwxJqWcfMSqAlncSyzc=.a8f06546-1087-477f-90ea-1cdb6f046991@github.com> `InstructionMark` checks the instruction boundaries, which is important for relocatable instructions. Everywhere where we do any (?) sort of relocation, we do `InstructionMark`. I found that newly added `MacroAssembler::post_call_nop` does not have it, and thus some new code in x86_32 Loom prototype fails with instruction mark / instruction overlapping checks. If we add it to `InstructionMark` in AArch64 code, then "overlapping instructions" asserts start to fire, because Loom inserted `post_call_nops` when there was an active instruction mark. x86_64 solves this by [resetting the mark before the nop](https://github.com/openjdk/jdk/blob/40f43c6b1ffc88d55dd3223f5d0259ae73cf0356/src/hotspot/cpu/x86/x86_64.ad#L2084), this patch does the same. Additional testing: - [x] Linux x86_64 fastdebug `tier1` - [x] Linux AArch64 fastdebug `tier1` ------------- Commit messages: - Some AArch64 paths need a clear insn mark - Fix Changes: https://git.openjdk.java.net/jdk/pull/8678/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8678&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286636 Stats: 5 lines in 3 files changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8678.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8678/head:pull/8678 PR: https://git.openjdk.java.net/jdk/pull/8678 From coleenp at openjdk.java.net Thu May 12 13:04:57 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 12 May 2022 13:04:57 GMT Subject: RFR: 8286556: Remove EagerInitialization develop option In-Reply-To: References: Message-ID: On Wed, 11 May 2022 14:21:09 GMT, Coleen Phillimore wrote: > This is a long unused option which interferes with code I'm trying to replace, so removing it. > Tested with tier1-4. Eager initialization was sort of funny in that it only tried to initialize classes without a function, so could provoke some class loading during linking these classes. It wasn't all of the classes. It also had a dubious way of handling link-time exceptions. I tried to make sense of this code, which is a waste of time, so removed it instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/8653 From redestad at openjdk.java.net Thu May 12 13:09:54 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 12 May 2022 13:09:54 GMT Subject: RFR: 8286556: Remove EagerInitialization develop option In-Reply-To: References: Message-ID: On Wed, 11 May 2022 14:21:09 GMT, Coleen Phillimore wrote: > This is a long unused option which interferes with code I'm trying to replace, so removing it. > Tested with tier1-4. Perhaps someone ran into some bootstrapping issues when it was unconstrained and tried limiting its reach like that to keep it working and still being somewhat useful? Either way I think you're right that removing it is preferable at this point (I'm biased against all the unused/untested diagnostic/develop flags, though). ------------- PR: https://git.openjdk.java.net/jdk/pull/8653 From dholmes at openjdk.java.net Thu May 12 13:12:04 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 12 May 2022 13:12:04 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v10] In-Reply-To: <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com> References: <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com> Message-ID: On Thu, 12 May 2022 08:23:11 GMT, Nick Gasson wrote: >> src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp line 3: >> >>> 1: /* >>> 2: * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved. >>> 3: * Copyright (c) 2019, 2021, Arm Limited. All rights reserved. >> >> Only update third-party copyrights under direction from that copyright holder. This may not be the correct format for example. >> Also it is 2022. :) > > I think the Arm Ltd one was probably changed by me in one of the PRs in the Panama repo. That's fine, just needed to check. But as these are now being committed to mainline the year does need to change to 2022 - at least in Oracle copyright. @nick-arm will have to advise what he thinks should be done with the ARM copyright. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From aph-open at littlepinkcloud.com Thu May 12 13:13:00 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Thu, 12 May 2022 14:13:00 +0100 Subject: RFR: 8286636: MacroAssembler::post_call_nop should have InstructionMark In-Reply-To: <9FGAXDJlzHK85Pz6nPimWEYlSwxJqWcfMSqAlncSyzc=.a8f06546-1087-477f-90ea-1cdb6f046991@github.com> References: <9FGAXDJlzHK85Pz6nPimWEYlSwxJqWcfMSqAlncSyzc=.a8f06546-1087-477f-90ea-1cdb6f046991@github.com> Message-ID: <492ea2a1-ec4c-6e2e-188c-3096d91f47ff@littlepinkcloud.com> On 5/12/22 14:00, Aleksey Shipilev wrote: > `InstructionMark` checks the instruction boundaries, which is important for relocatable instructions. Everywhere where we do any (?) sort of relocation, we do `InstructionMark`. I found that newly ad What is the meaning of "checks the instruction boundaries"? Just that we make sure that we cannot ever have multiple relocations of the same address, or something more subtle than that? Or, how would overlapping instructions happen? 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 ngasson at openjdk.java.net Thu May 12 13:59:11 2022 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 12 May 2022 13:59:11 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v10] In-Reply-To: References: <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com> Message-ID: On Thu, 12 May 2022 13:07:24 GMT, David Holmes wrote: >> I think the Arm Ltd one was probably changed by me in one of the PRs in the Panama repo. > > That's fine, just needed to check. But as these are now being committed to mainline the year does need to change to 2022 - at least in Oracle copyright. @nick-arm will have to advise what he thinks should be done with the ARM copyright. I think the Arm line can be updated to 2022 at the same time. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From dholmes at openjdk.java.net Thu May 12 14:01:58 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 12 May 2022 14:01:58 GMT Subject: RFR: 8286556: Remove EagerInitialization develop option In-Reply-To: References: Message-ID: On Thu, 12 May 2022 13:07:30 GMT, Claes Redestad wrote: >> This is a long unused option which interferes with code I'm trying to replace, so removing it. >> Tested with tier1-4. > > Perhaps someone ran into some bootstrapping issues when it was unconstrained and tried limiting its reach like that to keep it working and still being somewhat useful? Either way I think you're right that removing it is preferable at this point (I'm biased against all the unused/untested diagnostic/develop flags, though). @cl4es as Coleen explained this was an optimisation for classes with empty clinit, the intent being to mark the class as initialized upfront so that we can skip all those places where we have to check a class is initialized before we use it - that could potentially be of benefit and doesn't lead to the problems you outline. But the eager linking could potentially cause more class loading to occur at the time. @coleenp if I'm reading things right if eager linking got any exceptions it would reset the state so that we'd try to re-link at the regular time. I'm not sure how valid that actually is. In any case it was unused code so removing it is definitely the right thing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8653 From alanb at openjdk.java.net Thu May 12 14:12:02 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 12 May 2022 14:12:02 GMT Subject: RFR: 8286560: Remove user parameter from jdk.internal.perf.Perf.attach() In-Reply-To: References: Message-ID: On Wed, 11 May 2022 23:08:32 GMT, Ioi Lam wrote: > The API `jdk.internal.perf.Perf.::attach(String user, int lvmid)` is never used. It should be removed, and all the handling of a specified user name should be removed. Marked as reviewed by alanb (Reviewer). src/java.base/share/classes/jdk/internal/perf/Perf.java line 246: > 244: */ > 245: private native ByteBuffer attach0(int lvmid) > 246: throws IllegalArgumentException, IOException; You can drop the "throws IllegalArgumentException" here if you want, it's not needed as it's a runtime exception. ------------- PR: https://git.openjdk.java.net/jdk/pull/8669 From jvernee at openjdk.java.net Thu May 12 14:53:03 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 14:53:03 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v12] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Update Oracle copyright years ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/1c04a42e..9a7bb6bb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=10-11 Stats: 70 lines in 70 files changed: 0 ins; 0 del; 70 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Thu May 12 15:03:05 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 15:03:05 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v10] In-Reply-To: References: <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com> Message-ID: On Thu, 12 May 2022 13:55:20 GMT, Nick Gasson wrote: >> That's fine, just needed to check. But as these are now being committed to mainline the year does need to change to 2022 - at least in Oracle copyright. @nick-arm will have to advise what he thinks should be done with the ARM copyright. > > I think the Arm line can be updated to 2022 at the same time. I've updated all the Oracle copyright years in the files touched by this PR. @nick-arm If you wouldn't mind, could you use the "Add a suggestion" feature (the +/- button when leaving a review comment) to suggest copyright year updates to the relevant files (I think it's just foreign_globals_aarch64.cpp and universalUpcallHandler_aarch64.cpp). That way, when I accept those suggestions, an automatic commit will be made with you as the commit co-author, and it's even clearer that I'm making that change on your behalf. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From shade at openjdk.java.net Thu May 12 15:07:49 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 12 May 2022 15:07:49 GMT Subject: RFR: 8286636: MacroAssembler::post_call_nop should have InstructionMark In-Reply-To: <492ea2a1-ec4c-6e2e-188c-3096d91f47ff@littlepinkcloud.com> References: <9FGAXDJlzHK85Pz6nPimWEYlSwxJqWcfMSqAlncSyzc=.a8f06546-1087-477f-90ea-1cdb6f046991@github.com> <492ea2a1-ec4c-6e2e-188c-3096d91f47ff@littlepinkcloud.com> Message-ID: <6tAsxllnf0EJJIw9cERVsP1aaQjO9FEqH9mdgAnY9FY=.0402a056-ac80-4635-a2a4-270946b3b056@github.com> On Thu, 12 May 2022 13:19:53 GMT, Andrew Haley wrote: > On 5/12/22 14:00, Aleksey Shipilev wrote: > > `InstructionMark` checks the instruction boundaries, which is important for relocatable instructions. Everywhere where we do any (?) sort of relocation, we do `InstructionMark`. I found that newly ad > > What is the meaning of "checks the instruction boundaries"? Just that we make sure that we cannot ever have multiple relocations of the same address, or something more subtle than that? AFAICS, among other things, yes, we are making sure no more than one relocation per instruction happens. > Or, how would overlapping instructions happen? Pretty easy, this is what I had in x86_32 and AArch64: we expand the "instruction" through the .ad / macroAssembler, and then circle back to `MacroAssembler::post_call_nop`, which is a relocation-bearing instruction in its own right. `InstructionMark` in `post_call_nop` then rightfully asserts that we are in the middle of emitting another "instruction". AFAICS, this whole thing is an optional check that protects us from calling into `Assembler`/`MacroAssembler` haphazardly. ------------- PR: https://git.openjdk.java.net/jdk/pull/8678 From jvernee at openjdk.java.net Thu May 12 15:07:57 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 15:07:57 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v13] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Missed 2 years ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/9a7bb6bb..8100e0a7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=11-12 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From ngasson at openjdk.java.net Thu May 12 15:08:01 2022 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 12 May 2022 15:08:01 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v12] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 14:53:03 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. >> >> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. >> >> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: >> >> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. >> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. >> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). >> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. >> >> While the patch mostly consists of VM changes, there are also some Java changes to support (2). >> >> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. >> >> Testing: Tier1-4 >> >> Thanks, >> Jorn >> >> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 >> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 >> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 >> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 >> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 >> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a >> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 >> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f >> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Update Oracle copyright years src/hotspot/cpu/aarch64/foreign_globals_aarch64.cpp line 3: > 1: /* > 2: * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved. > 3: * Copyright (c) 2019, 2021, Arm Limited. All rights reserved. Suggestion: * Copyright (c) 2019, 2022, Arm Limited. All rights reserved. src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 3: > 1: /* > 2: * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved. > 3: * Copyright (c) 2019, 2021, Arm Limited. All rights reserved. Suggestion: * Copyright (c) 2019, 2022, Arm Limited. All rights reserved. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From shade at openjdk.java.net Thu May 12 15:13:48 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 12 May 2022 15:13:48 GMT Subject: RFR: 8286636: MacroAssembler::post_call_nop should have InstructionMark In-Reply-To: <9FGAXDJlzHK85Pz6nPimWEYlSwxJqWcfMSqAlncSyzc=.a8f06546-1087-477f-90ea-1cdb6f046991@github.com> References: <9FGAXDJlzHK85Pz6nPimWEYlSwxJqWcfMSqAlncSyzc=.a8f06546-1087-477f-90ea-1cdb6f046991@github.com> Message-ID: On Thu, 12 May 2022 11:32:05 GMT, Aleksey Shipilev wrote: > `InstructionMark` checks the instruction boundaries, which is important for relocatable instructions. Everywhere where we do any (?) sort of relocation, we do `InstructionMark`. I found that newly added `MacroAssembler::post_call_nop` does not have it, and thus some new code in x86_32 Loom prototype fails with missing instruction mark / instruction overlapping checks. > > If we add it to `InstructionMark` in AArch64 code, then "overlapping instructions" asserts start to fire, because Loom inserted `post_call_nops` when there was an active instruction mark. x86_64 solves this by [resetting the mark before the nop](https://github.com/openjdk/jdk/blob/40f43c6b1ffc88d55dd3223f5d0259ae73cf0356/src/hotspot/cpu/x86/x86_64.ad#L2084), this patch does the same. > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux AArch64 fastdebug `tier1` > Pretty easy, this is what I had in x86_32 and AArch64: we expand the "instruction" through the .ad / macroAssembler, and then circle back to `MacroAssembler::post_call_nop`, which is a relocation-bearing instruction in its own right. `InstructionMark` in `post_call_nop` then rightfully asserts that we are in the middle of emitting another "instruction". AFAICS, this whole thing is an optional check that protects us from calling into `Assembler`/`MacroAssembler` haphazardly. Oh, and to add to that, on x86_32 another thing also happens: calls to `relocate` [check](https://github.com/openjdk/jdk/blob/1904e9d280d1cce2deead4d4aa39dda1beb9dff1/src/hotspot/share/asm/assembler.hpp#L342-L344) there is an `InstructionMark` in place. So we either relax that assert (dubious), or we do `InstructionMark` everywhere we do `relocate()`. `MacroAssembler::post_call_nop` is a new place with `relocate()` without `InstructionMark`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8678 From jvernee at openjdk.java.net Thu May 12 15:16:08 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 15:16:08 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v14] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Apply copyright year updates per request of @nick-arm Co-authored-by: Nick Gasson ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/8100e0a7..0f49ff0b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=12-13 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Thu May 12 15:16:10 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 15:16:10 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v10] In-Reply-To: References: <61uaOdBJDL6FscYySqo_tZCDdBiitl8AwNYqmV1w-aU=.80f61175-19aa-4bfc-9301-e5930d54b0a2@github.com> Message-ID: On Thu, 12 May 2022 13:55:20 GMT, Nick Gasson wrote: >> That's fine, just needed to check. But as these are now being committed to mainline the year does need to change to 2022 - at least in Oracle copyright. @nick-arm will have to advise what he thinks should be done with the ARM copyright. > > I think the Arm line can be updated to 2022 at the same time. @nick-arm Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From mcimadamore at openjdk.java.net Thu May 12 15:45:01 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 12 May 2022 15:45:01 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: - Merge branch 'master' into foreign-preview - Merge branch 'master' into foreign-preview - Fix crashes in heap segment benchmarks due to misaligned access - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Add tests for loaderLookup/restricted method corner cases - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI * Tweak restricted method check to work when there's no caller class - Tweak examples in SymbolLookup javadoc - Merge branch 'master' into foreign-preview - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - ... and 55 more: https://git.openjdk.java.net/jdk/compare/82aa0455...f170415b ------------- Changes: https://git.openjdk.java.net/jdk/pull/7888/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=44 Stats: 65711 lines in 373 files changed: 43720 ins; 19432 del; 2559 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Thu May 12 15:51:00 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 12 May 2022 15:51:00 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v34] In-Reply-To: References: Message-ID: On Fri, 29 Apr 2022 08:29:52 GMT, Guoxiong Li wrote: >>> Remind: please use the command `/jep JEP-424` [1] to mark this PR. >>> >>> [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/jep >> >> Question: I'm willing to try it out. If something goes wrong - would a `jep unneeded` be enough to "unstuck" this PR? > >> would a jep unneeded be enough to "unstuck" this PR? > > Yes if no bug. Conceptually, the `/jep unneeded` will behave as no jep command. @lgxbslgx - JEP has been targeted, but the JEP action seems to be blocking this - what should we do? ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From jvernee at openjdk.java.net Thu May 12 15:58:04 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 15:58:04 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v15] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'JEP-19-VM-IMPL2' of https://github.com/JornVernee/jdk into JEP-19-VM-IMPL2 - Fix overwritten copyright years. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/0f49ff0b..aab2d15c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=13-14 Stats: 36 lines in 33 files changed: 4 ins; 0 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Thu May 12 16:01:17 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 16:01:17 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v16] In-Reply-To: References: Message-ID: <1WJgr8j7aHe_iD2t5KwVDk3c-raW7Q0NEbaSNfeo3zA=.5b14ab8c-b2a3-4fba-8209-643228a8b85d@github.com> > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Undo spurious changes. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/aab2d15c..f961121a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=14-15 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From psandoz at openjdk.java.net Thu May 12 16:11:58 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 12 May 2022 16:11:58 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v3] In-Reply-To: References: Message-ID: On Thu, 5 May 2022 08:56:07 GMT, Xiaohong Gong wrote: >> Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception. >> >> This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize): >> >> >> @ForceInline >> public static >> ByteVector fromArray(VectorSpecies species, >> byte[] a, int offset, >> VectorMask m) { >> ByteSpecies vsp = (ByteSpecies) species; >> if (offset >= 0 && offset <= (a.length - species.length())) { >> return vsp.dummyVector().fromArray0(a, offset, m); >> } >> >> // FIXME: optimize >> checkMaskFromIndexSize(offset, vsp, m, 1, a.length); >> return vsp.vOp(m, i -> a[offset + i]); >> } >> >> Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed. >> >> Also adds the same vectorization support for masked: >> - fromByteArray/fromByteBuffer >> - fromBooleanArray >> - fromCharArray >> >> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system: >> >> Benchmark before After Units >> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE 737.542 1387.069 ops/ms >> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366 330.776 ops/ms >> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE 233.832 6125.026 ops/ms >> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE 233.816 7075.923 ops/ms >> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE 119.771 330.587 ops/ms >> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE 431.961 939.301 ops/ms >> >> Similar performance gain can also be observed on 512-bit SVE system. > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Rename "use_predicate" to "needs_predicate" Yes, the tests were run in debug mode. The reporting of the missing constant occurs for the compiled method that is called from the method where the constants are declared e.g.: 719 240 b jdk.incubator.vector.Int256Vector::fromArray0 (15 bytes) ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it ** missing constant: offsetInRange=Parm @ 11 jdk.incubator.vector.IntVector::fromArray0Template (22 bytes) force inline by annotation So it appears to be working as expected. A similar pattern occurs at a lower-level for the passing of the mask class. `Int256Vector::fromArray0` passes a constant class to `IntVector::fromArray0Template` (the compilation of which bails out before checking that the `offsetInRange` is constant). ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From mcimadamore at openjdk.java.net Thu May 12 16:21:59 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 12 May 2022 16:21:59 GMT Subject: Integrated: 8282191: Implementation of Foreign Function & Memory API (Preview) In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 This pull request has now been integrated. Changeset: 2c5d1362 Author: Maurizio Cimadamore URL: https://git.openjdk.java.net/jdk/commit/2c5d136260fa717afa374db8b923b7c886d069b7 Stats: 65711 lines in 373 files changed: 43720 ins; 19432 del; 2559 mod 8282191: Implementation of Foreign Function & Memory API (Preview) Reviewed-by: erikj, jvernee, psandoz, dholmes, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From duke at openjdk.java.net Thu May 12 16:26:41 2022 From: duke at openjdk.java.net (openjdk-notifier[bot]) Date: Thu, 12 May 2022 16:26:41 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v16] In-Reply-To: <1WJgr8j7aHe_iD2t5KwVDk3c-raW7Q0NEbaSNfeo3zA=.5b14ab8c-b2a3-4fba-8209-643228a8b85d@github.com> References: <1WJgr8j7aHe_iD2t5KwVDk3c-raW7Q0NEbaSNfeo3zA=.5b14ab8c-b2a3-4fba-8209-643228a8b85d@github.com> Message-ID: On Thu, 12 May 2022 16:01:17 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. >> >> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. >> >> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: >> >> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. >> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. >> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). >> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. >> >> While the patch mostly consists of VM changes, there are also some Java changes to support (2). >> >> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. >> >> Testing: Tier1-4 >> >> Thanks, >> Jorn >> >> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 >> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 >> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 >> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 >> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 >> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a >> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 >> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f >> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Undo spurious changes. The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork: git checkout JEP-19-VM-IMPL2 git fetch https://git.openjdk.java.net/jdk master git merge FETCH_HEAD # if there are conflicts, follow the instructions given by git merge git commit -m "Merge master" git push ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Thu May 12 16:58:36 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 16:58:36 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v17] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 98 commits: - Merge branch 'master' into JEP-19-VM-IMPL2 - Undo spurious changes. - Merge branch 'JEP-19-VM-IMPL2' of https://github.com/JornVernee/jdk into JEP-19-VM-IMPL2 - Apply copyright year updates per request of @nick-arm Co-authored-by: Nick Gasson - Fix overwritten copyright years. - Missed 2 years - Update Oracle copyright years - Revert "Block async exceptions during upcalls" This reverts commit b29ad8f46732666f2d07e63ce8701b1eb7bed790. - Block async exceptions during upcalls - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 - ... and 88 more: https://git.openjdk.java.net/jdk/compare/2c5d1362...f55b6c59 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7959/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=16 Stats: 6913 lines in 155 files changed: 2576 ins; 3219 del; 1118 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From iklam at openjdk.java.net Thu May 12 17:16:34 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 12 May 2022 17:16:34 GMT Subject: RFR: 8286560: Remove user parameter from jdk.internal.perf.Perf.attach() [v2] In-Reply-To: References: Message-ID: > The API `jdk.internal.perf.Perf.::attach(String user, int lvmid)` is never used. It should be removed, and all the handling of a specified user name should be removed. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @AlanBateman comments - remove thros IllegalArgumentException clause ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8669/files - new: https://git.openjdk.java.net/jdk/pull/8669/files/afa66232..0b73a9d4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8669&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8669&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8669.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8669/head:pull/8669 PR: https://git.openjdk.java.net/jdk/pull/8669 From jvernee at openjdk.java.net Thu May 12 17:30:00 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 17:30:00 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com> Message-ID: <9NhIJsBLpV42NNz7rjhBu_cEvljMy1KIAA7IdTz1aGM=.1ac390e6-4834-4616-b85d-fda842c8e4fa@github.com> On Thu, 12 May 2022 12:10:53 GMT, Maurizio Cimadamore wrote: >> Okay, I see. I think I acted a little too hastily on this yesterday. I'll revert the change that uses this blocking mechanism. >> >> The stack more or less looks like this during an upcall: >> >> >> | --- >> | | >> | --- >> | <1: user define try block with exception handler (maybe)> | >> | --- >> | <2: user code start> | >> | --- >> | <3: method handle impl frames 1> | >> | --- >> | <4: upcall wrapper class with fallback handler 1> | >> | --- >> | <5: method handle impl frames 2> | >> | --- >> | <6: upcallk stub with fallback handler 2> | >> | <7: unknown native code> >> | --- >> | | >> >> >> I think there are several options to address async exceptions: >> 1. Do nothing special for async exceptions. i.e. if they happen anywhere between 1. and 6. they will end up in one of the fallback handlers and the VM will be terminated. >> 2. Block async exceptions in all code up from 6. >> 3. Somehow only block async exceptions only between 6. and 1. >> I think that is possible by changing the API so that the user passes us a method handle to their fallback exception handler, and we invoke it in our code in 4. We would need 2 methods for blocking and unblocking async exceptions from Java. Then we could disable async exceptions at the start of 6. enabled them at the start of the try block in 4. (around the call to user code), and disable them at the end of this try block. Then finally re-enable them at the end of 6. If an exception occurs in the try block in 4., delegate to the user-defined exception handler (but use the VM terminate strategy as a fallback for when another exception occurs). The other problem I see with that is that to make that fast enough (i.e. not incur a ~1.5-2x cost on call overhead), we would need compiler intrinsics for the blocking/unblocking, and in the past we've been unable to define 'critical' sections of code like that in C2 (it's an unsolved problem at this point). > >> Do nothing special for async exceptions. i.e. if they happen anywhere between 1. and 6. they will end up in one of the fallback handlers and the VM will be terminated. > > My understanding is that if they materialize while we're executing the upcall Java code, if that code has a try/catch block, we will go there, rather than crash the VM. > > In other words, IMHO the only problem with async exception is if they occur _after_ the Java user code has completed, because that will crash the Java adapter, this preventing it from returning to native call cleanly. > > So, either we disable async exceptions during that phase (e.g. after user code has executed, but before we return back to native code), or we just punt and stop. Since this seems like a corner^3 case, and since there are also other issue with upcalls that can occur if other threads do not cooperate (e.g. an upcall can get stuck into an infinite safepoint if the VM exits while an async native thread runs the upcall), and given that obtaining a linker is a restricted operation anyway, I don't think we should bend over backwards to try to add 1% more safety to something that's unavoidably sharp anyways. Ok. Then, if no one objects, I will leave this area as-is for now. (and perhaps come back to this issue in the future, if it becomes more pressing). ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Thu May 12 17:36:31 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 17:36:31 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline Message-ID: Hi, This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well. Thanks, Jorn ------------- Depends on: https://git.openjdk.java.net/jdk/pull/7959 Commit messages: - Fix LinkUpcall benchmark - 8286306: Upcall wrapper class sharing - Polish - 8281595: ASM-ify scope acquire/release for down call parameters - 8281228: Preview branch's CLinker.downcallHandle crashes inside asm - 8278414: Replace binding recipe customization using MH combinators with bytecode spinning - 8276648: Downcall stubs are never freed Changes: https://git.openjdk.java.net/jdk/pull/8685/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8685&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286669 Stats: 2171 lines in 24 files changed: 1384 ins; 660 del; 127 mod Patch: https://git.openjdk.java.net/jdk/pull/8685.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8685/head:pull/8685 PR: https://git.openjdk.java.net/jdk/pull/8685 From duke at openjdk.java.net Thu May 12 18:20:00 2022 From: duke at openjdk.java.net (liach) Date: Thu, 12 May 2022 18:20:00 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline In-Reply-To: References: Message-ID: <_vOeEJsQJfMPt3ECcI2OKwrFBS4WPRqJA8O6YtFkiI4=.f5285c7b-cf85-4f6e-a206-1262ee29bec2@github.com> On Thu, 12 May 2022 17:17:37 GMT, Jorn Vernee wrote: > Hi, > > This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well. > > Thanks, > Jorn test/micro/org/openjdk/bench/java/lang/foreign/LinkUpcall.java line 61: > 59: BLANK = lookup().findStatic(LinkUpcall.class, "blank", MethodType.methodType(void.class)); > 60: } catch (ReflectiveOperationException e) { > 61: throw new BootstrapMethodError(e); You probably mean exception in initializer error. ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From iklam at openjdk.java.net Thu May 12 18:20:57 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 12 May 2022 18:20:57 GMT Subject: RFR: 8286560: Remove user parameter from jdk.internal.perf.Perf.attach() [v2] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 04:06:44 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @AlanBateman comments - remove thros IllegalArgumentException clause > > Nice cleanup! I checked back in JDK 7 and couldn't find any use of this particular API. > > Thanks. Thanks to @dholmes-ora and @AlanBateman for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8669 From iklam at openjdk.java.net Thu May 12 18:21:00 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 12 May 2022 18:21:00 GMT Subject: RFR: 8286560: Remove user parameter from jdk.internal.perf.Perf.attach() [v2] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 14:08:11 GMT, Alan Bateman wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @AlanBateman comments - remove thros IllegalArgumentException clause > > src/java.base/share/classes/jdk/internal/perf/Perf.java line 246: > >> 244: */ >> 245: private native ByteBuffer attach0(int lvmid) >> 246: throws IllegalArgumentException, IOException; > > You can drop the "throws IllegalArgumentException" here if you want, it's not needed as it's a runtime exception. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8669 From iklam at openjdk.java.net Thu May 12 18:21:03 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 12 May 2022 18:21:03 GMT Subject: Integrated: 8286560: Remove user parameter from jdk.internal.perf.Perf.attach() In-Reply-To: References: Message-ID: <384C9guIuWTysRpqKNFMYODCCbfDkRMGVuxpFGm4DrQ=.aa54d9fc-00d1-4589-a0aa-1f3f1eee7b42@github.com> On Wed, 11 May 2022 23:08:32 GMT, Ioi Lam wrote: > The API `jdk.internal.perf.Perf.::attach(String user, int lvmid)` is never used. It should be removed, and all the handling of a specified user name should be removed. This pull request has now been integrated. Changeset: 74eee28a Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/74eee28a710f2d0c9f613522ee3d228d6b601252 Stats: 123 lines in 5 files changed: 2 ins; 97 del; 24 mod 8286560: Remove user parameter from jdk.internal.perf.Perf.attach() Reviewed-by: dholmes, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/8669 From kbarrett at openjdk.java.net Thu May 12 18:31:49 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 12 May 2022 18:31:49 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 01:29:13 GMT, Yasumasa Suenaga wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Calculate char offset before realloc() > > Thanks for all to review this PR! I think we should separate this issue as following: > > * Suppress warnings > * make/modules/java.desktop/lib/Awt2dLibraries.gmk > * src/hotspot/share/classfile/bytecodeAssembler.cpp > * src/hotspot/share/classfile/classFileParser.cpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > * src/hotspot/share/opto/memnode.cpp > * src/hotspot/share/opto/type.cpp > * src/hotspot/share/utilities/compilerWarnings.hpp > * src/hotspot/share/utilities/compilerWarnings_gcc.hpp > * src/java.base/unix/native/libjli/java_md_common.c > * Bug fixes > * src/java.base/share/native/libjli/java.c > * src/java.base/share/native/libjli/parse_manifest.c > * src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c > > I want to include the change of Awt2dLibraries.gmk (HarfBuzz) in this PR because it is 3rd party library. > > I will separate in above if I do not hear any objections, and this issue (PR) handles "suppress warnings" only. > @YaSuenag From my PoV this sounds like a good suggestion. +1 ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From prr at openjdk.java.net Thu May 12 19:10:51 2022 From: prr at openjdk.java.net (Phil Race) Date: Thu, 12 May 2022 19:10:51 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 01:27:30 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Calculate char offset before realloc() I will see what upstream thinks about the harfbuzz warning but in the mean time we can just disable it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From jvernee at openjdk.java.net Thu May 12 21:25:52 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 12 May 2022 21:25:52 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline In-Reply-To: References: Message-ID: On Thu, 12 May 2022 17:17:37 GMT, Jorn Vernee wrote: > Hi, > > This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well. > > Thanks, > Jorn Hmm, looks like there's an unexpected a tier1 failure on SysV in the GHA (I only tested Windows locally, since these changes have been live in the panama repo for a while now...). Will convert back to draft and see what's up. ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From forax at univ-mlv.fr Thu May 12 22:11:47 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 13 May 2022 00:11:47 +0200 (CEST) Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline In-Reply-To: References: Message-ID: <1527742474.1903577.1652393507927.JavaMail.zimbra@u-pem.fr> Ok, let us know when it's out of draft, i've several minor modifications about the code. regards, R?mi ----- Original Message ----- > From: "Jorn Vernee" > To: "core-libs-dev" , "hotspot-dev" > Sent: Thursday, May 12, 2022 11:25:52 PM > Subject: Re: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline > On Thu, 12 May 2022 17:17:37 GMT, Jorn Vernee wrote: > >> Hi, >> >> This PR brings over commits from the panama-foreign repo. These commits mostly >> pertain to the switch to ASM and away from MethodHandle combinators for the >> binding recipe specialization. But, there is one more commit which adds freeing >> of downcall stubs, since those changes were mostly Java as well. >> >> Thanks, >> Jorn > > Hmm, looks like there's an unexpected a tier1 failure on SysV in the GHA (I only > tested Windows locally, since these changes have been live in the panama repo > for a while now...). Will convert back to draft and see what's up. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/8685 From vlivanov at openjdk.java.net Thu May 12 23:59:46 2022 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 12 May 2022 23:59:46 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v3] In-Reply-To: <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com> References: <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com> Message-ID: On Tue, 10 May 2022 12:48:25 GMT, Jatin Bhateja wrote: >> Hi All, >> >> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) >> >> Following is the brief summary of changes:- >> >> 1) Extends the scope of existing lanewise API for following new vector operations. >> - VectorOperations.BIT_COUNT: counts the number of one-bits >> - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits >> - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits >> - VectorOperations.REVERSE: reversing the order of bits >> - VectorOperations.REVERSE_BYTES: reversing the order of bytes >> - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. >> >> 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. >> - Vector.compress >> - Vector.expand >> - VectorMask.compress >> >> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. >> - Vector.fromMemorySegment >> - Vector.intoMemorySegment >> >> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. >> >> >> Patch has been regressed over AARCH64 and X86 targets different AVX levels. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja 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' of http://github.com/openjdk/jdk into JDK-8284960 > - 8284960: Correcting a typo. > - 8284960: Integrating changes from panama-vector (Add @since 19 tags). > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - 8284960: AARCH64 backend changes. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3fa1c404...b021e082 Overall, looks good. Some minor questions/suggestions follow. src/hotspot/cpu/aarch64/aarch64_neon.ad line 5700: > 5698: as_FloatRegister($dst$$reg)); > 5699: } > 5700: if (bt == T_INT) { I find it hard to reason about the code in its current form. Maybe make the second `if` (`bt == T_INT`) nested and move it under `if (bt == T_SHORT || bt == T_INT)`? src/hotspot/cpu/x86/macroAssembler_x86.cpp line 2587: > 2585: > 2586: void MacroAssembler::vmovdqu(XMMRegister dst, AddressLiteral src, Register scratch_reg, int vector_len) { > 2587: assert(vector_len <= AVX_512bit, "unexpected vector length"); The assert becomes redundant. src/hotspot/cpu/x86/matcher_x86.hpp line 195: > 193: case Op_PopCountVI: > 194: return ((ety == T_INT && VM_Version::supports_avx512_vpopcntdq()) || > 195: (is_subword_type(ety) && VM_Version::supports_avx512_bitalg())) ? 0 : 50; Should be easier to read when the condition is split. E.g.: if (is_subword_type(ety)) { return VM_Version::supports_avx512_bitalg())) ? 0 : 50; } else { assert(ety == T_INT, "sanity"); // for documentation purposes return VM_Version::supports_avx512_vpopcntdq() ? 0 : 50; } src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7953: > 7951: StubRoutines::x86::_vector_iota_indices = generate_iota_indices("iota_indices"); > 7952: > 7953: if (UsePopCountInstruction && VM_Version::supports_avx2() && !VM_Version::supports_avx512_vpopcntdq()) { Why is the LUT unconditionally generated? `UsePopCountInstruction` still guides the usages. src/hotspot/cpu/x86/vm_version_x86.hpp line 375: > 373: decl(RDTSCP, "rdtscp", 48) /* RDTSCP instruction */ \ > 374: decl(RDPID, "rdpid", 49) /* RDPID instruction */ \ > 375: decl(FSRM, "fsrm", 50) /* Fast Short REP MOV */ \ `test/lib-test/jdk/test/whitebox/CPUInfoTest.java` should be adjusted as well, shouldn't it? src/hotspot/cpu/x86/x86.ad line 2113: > 2111: > 2112: case Op_CountLeadingZerosV: > 2113: if ((bt == T_INT || bt == T_LONG) && VM_Version::supports_avx512cd()) { Newly introduced `is_non_subword_integral_type(bt)` can be used here instead of `bt == T_INT || bt == T_LONG`. src/hotspot/share/classfile/vmIntrinsics.hpp line 1152: > 1150: "Ljdk/internal/vm/vector/VectorSupport$ComExpOperation;)" \ > 1151: "Ljdk/internal/vm/vector/VectorSupport$VectorPayload;") \ > 1152: do_name(vector_comexp_op_name, "comExpOp") \ I don't see much value in trying to shorten the name by abbreviating it. I find it easier to read in an expanded form: ` compressExpandOp`, `vector_compress_expand_op_name`, `_VectorCompressExpand`, etc. src/hotspot/share/opto/c2compiler.cpp line 521: > 519: if (!Matcher::match_rule_supported(Op_SignumF)) return false; > 520: break; > 521: case vmIntrinsics::_VectorComExp: Why `_VectorComExp` intrinsic is special? Other vector intrinsics are handled later and in a different manner. What about `ExpandV` case? src/hotspot/share/opto/compile.cpp line 3416: > 3414: > 3415: case Op_ReverseBytesV: > 3416: case Op_ReverseV: { Can you elaborate, please, why it is performed so late in the optimization phase (at the very end during graph reshaping) and not during GVN? ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From xgong at openjdk.java.net Fri May 13 01:52:44 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Fri, 13 May 2022 01:52:44 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v3] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 16:07:54 GMT, Paul Sandoz wrote: > Yes, the tests were run in debug mode. The reporting of the missing constant occurs for the compiled method that is called from the method where the constants are declared e.g.: > > ``` > 719 240 b jdk.incubator.vector.Int256Vector::fromArray0 (15 bytes) > ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it > ** missing constant: offsetInRange=Parm > @ 11 jdk.incubator.vector.IntVector::fromArray0Template (22 bytes) force inline by annotation > ``` > > So it appears to be working as expected. A similar pattern occurs at a lower-level for the passing of the mask class. `Int256Vector::fromArray0` passes a constant class to `IntVector::fromArray0Template` (the compilation of which bails out before checking that the `offsetInRange` is constant). Make sense to me! I think I understand what you mean. I will have more tests with the integer constant change. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From duke at openjdk.java.net Fri May 13 02:01:44 2022 From: duke at openjdk.java.net (Haomin) Date: Fri, 13 May 2022 02:01:44 GMT Subject: RFR: 8286452: The array length of testSmallConstArray should be small and const In-Reply-To: References: Message-ID: On Tue, 10 May 2022 03:19:36 GMT, Haomin wrote: > testLargeVariableArray and testSmallConstArray are the same, the localArrlen of testSmallConstArray should be small and const. @DamonFool Please review :) ------------- PR: https://git.openjdk.java.net/jdk/pull/8621 From jbhateja at openjdk.java.net Fri May 13 08:31:09 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 13 May 2022 08:31:09 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v4] In-Reply-To: References: Message-ID: <9BFz3-71uc1dcsLybF4_IGlQmh43DBdLkI6FEGxKTro=.d020993a-a112-46fe-9902-6c057918b700@github.com> > Hi All, > > Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) > > Following is the brief summary of changes:- > > 1) Extends the scope of existing lanewise API for following new vector operations. > - VectorOperations.BIT_COUNT: counts the number of one-bits > - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits > - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits > - VectorOperations.REVERSE: reversing the order of bits > - VectorOperations.REVERSE_BYTES: reversing the order of bytes > - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. > > 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. > - Vector.compress > - Vector.expand > - VectorMask.compress > > 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. > - Vector.fromMemorySegment > - Vector.intoMemorySegment > > 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. > > > Patch has been regressed over AARCH64 and X86 targets different AVX levels. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8284960: Review comments resolution. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8425/files - new: https://git.openjdk.java.net/jdk/pull/8425/files/b021e082..adf205f9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=02-03 Stats: 121 lines in 49 files changed: 8 ins; 5 del; 108 mod Patch: https://git.openjdk.java.net/jdk/pull/8425.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425 PR: https://git.openjdk.java.net/jdk/pull/8425 From jbhateja at openjdk.java.net Fri May 13 08:31:22 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 13 May 2022 08:31:22 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v3] In-Reply-To: References: <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com> Message-ID: On Thu, 12 May 2022 22:40:50 GMT, Vladimir Ivanov wrote: >> Jatin Bhateja 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' of http://github.com/openjdk/jdk into JDK-8284960 >> - 8284960: Correcting a typo. >> - 8284960: Integrating changes from panama-vector (Add @since 19 tags). >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 >> - 8284960: AARCH64 backend changes. >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 >> - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3fa1c404...b021e082 > > src/hotspot/cpu/x86/matcher_x86.hpp line 195: > >> 193: case Op_PopCountVI: >> 194: return ((ety == T_INT && VM_Version::supports_avx512_vpopcntdq()) || >> 195: (is_subword_type(ety) && VM_Version::supports_avx512_bitalg())) ? 0 : 50; > > Should be easier to read when the condition is split. E.g.: > > if (is_subword_type(ety)) { > return VM_Version::supports_avx512_bitalg())) ? 0 : 50; > } else { > assert(ety == T_INT, "sanity"); // for documentation purposes > return VM_Version::supports_avx512_vpopcntdq() ? 0 : 50; > } DONE > src/hotspot/cpu/x86/vm_version_x86.hpp line 375: > >> 373: decl(RDTSCP, "rdtscp", 48) /* RDTSCP instruction */ \ >> 374: decl(RDPID, "rdpid", 49) /* RDPID instruction */ \ >> 375: decl(FSRM, "fsrm", 50) /* Fast Short REP MOV */ \ > > `test/lib-test/jdk/test/whitebox/CPUInfoTest.java` should be adjusted as well, shouldn't it? Yes, test updated appropriately. > src/hotspot/share/classfile/vmIntrinsics.hpp line 1152: > >> 1150: "Ljdk/internal/vm/vector/VectorSupport$ComExpOperation;)" \ >> 1151: "Ljdk/internal/vm/vector/VectorSupport$VectorPayload;") \ >> 1152: do_name(vector_comexp_op_name, "comExpOp") \ > > I don't see much value in trying to shorten the name by abbreviating it. I find it easier to read in an expanded form: > ` compressExpandOp`, `vector_compress_expand_op_name`, `_VectorCompressExpand`, etc. DONE > src/hotspot/share/opto/c2compiler.cpp line 521: > >> 519: if (!Matcher::match_rule_supported(Op_SignumF)) return false; >> 520: break; >> 521: case vmIntrinsics::_VectorComExp: > > Why `_VectorComExp` intrinsic is special? Other vector intrinsics are handled later and in a different manner. > > What about `ExpandV` case? It was an attempt to facilitate in-lining of these APIs over targets which do not intrinsify them. I agree its not a generic fix since three APIs are piggybacking on same entry point and without the knowledge of opcode it will be inappropriate to take any call at this place, lazy intrinsification gives opportunity for some of the predications to concertize as compilation happens under closed world assumptions. > src/hotspot/share/opto/compile.cpp line 3416: > >> 3414: >> 3415: case Op_ReverseBytesV: >> 3416: case Op_ReverseV: { > > Can you elaborate, please, why it is performed so late in the optimization phase (at the very end during graph reshaping) and not during GVN? Its more of a chicken-egg problem here, for masked reverse operation, Reverse IR node is followed by a Blend Node, thus in such a case doing an eager Identity transform in Reverse::Identity will not work, also deferring this to blend may also not work since it could be a non-masked reverse operation, we could have handled it as a special case in inline_vector_nary_operation, but handling such special case in final graph reshaping looked more appropriate. https://github.com/openjdk/panama-vector/pull/182#discussion_r845678080 ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From jbhateja at openjdk.java.net Fri May 13 08:31:24 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 13 May 2022 08:31:24 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v4] In-Reply-To: References: <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com> Message-ID: On Thu, 12 May 2022 22:48:26 GMT, Vladimir Ivanov wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8284960: Review comments resolution. > > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7953: > >> 7951: StubRoutines::x86::_vector_iota_indices = generate_iota_indices("iota_indices"); >> 7952: >> 7953: if (UsePopCountInstruction && VM_Version::supports_avx2() && !VM_Version::supports_avx512_vpopcntdq()) { > > Why is the LUT unconditionally generated? `UsePopCountInstruction` still guides the usages. LUT should be generated only if UsePopCountInsturction is false and iff target does not support necessary features, AVX512POPCNTDQ (for int/long vectors) and AVX512_BITALG (for sub-word vectors). Please refer to following discussion where it was suggested to restrict the scope of flag to only scalar popcount operation. https://github.com/openjdk/panama-vector/pull/185#discussion_r847758463 ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From uschindler at openjdk.java.net Fri May 13 08:37:17 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Fri, 13 May 2022 08:37:17 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 15:45:01 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: > > - Merge branch 'master' into foreign-preview > - Merge branch 'master' into foreign-preview > - Fix crashes in heap segment benchmarks due to misaligned access > - Merge branch 'master' into foreign-preview > - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Add tests for loaderLookup/restricted method corner cases > - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI > * Tweak restricted method check to work when there's no caller class > - Tweak examples in SymbolLookup javadoc > - Merge branch 'master' into foreign-preview > - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - ... and 55 more: https://git.openjdk.java.net/jdk/compare/82aa0455...f170415b Some late comments and suggestions to fix inconsistencies and wrong javadocs. src/java.base/share/classes/java/nio/channels/FileChannel.java line 1045: > 1043: * > 1044: * @throws UnsupportedOperationException > 1045: * If an unsupported map mode is specified. I think this should mention that UOE is also throws if the filesystem implementation does not support memory mapping. This may happen for filesystems like jrtfs or custom wrapper filesystems that do not implement the method below. As this is already merged, should I open a PR fixing the docs or open an issue? src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1164: > 1162: } > 1163: if (unmapper != null) { > 1164: AbstractMemorySegmentImpl segment = new MappedMemorySegmentImpl(unmapper.address(), unmapper, size, When reviewing the method for MappedByteBuffer: I think to make this consistent the "old" method should also use `address()` which applies the pagePosition. Currently it is confusing: - New code returning `MemorySegment` uses `unmapper.address()` - Old code returning `MappedByteBuffer` uses `unmapper.address + unmapper.pagePosition` (fields) Should I open an issue or a PR to fix this (because this is already merged)? See the mailing list posts: - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016981.html - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016990.html ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From uschindler at openjdk.java.net Fri May 13 08:37:18 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Fri, 13 May 2022 08:37:18 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 08:25:01 GMT, Uwe Schindler wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: >> >> - Merge branch 'master' into foreign-preview >> - Merge branch 'master' into foreign-preview >> - Fix crashes in heap segment benchmarks due to misaligned access >> - Merge branch 'master' into foreign-preview >> - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - Add tests for loaderLookup/restricted method corner cases >> - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI >> * Tweak restricted method check to work when there's no caller class >> - Tweak examples in SymbolLookup javadoc >> - Merge branch 'master' into foreign-preview >> - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - ... and 55 more: https://git.openjdk.java.net/jdk/compare/82aa0455...f170415b > > src/java.base/share/classes/java/nio/channels/FileChannel.java line 1045: > >> 1043: * >> 1044: * @throws UnsupportedOperationException >> 1045: * If an unsupported map mode is specified. > > I think this should mention that UOE is also throws if the filesystem implementation does not support memory mapping. This may happen for filesystems like jrtfs or custom wrapper filesystems that do not implement the method below. > > As this is already merged, should I open a PR fixing the docs or open an issue? This change here also closes [JDK-8259034](https://bugs.openjdk.java.net/browse/JDK-8259034) ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From duke at openjdk.java.net Fri May 13 08:53:04 2022 From: duke at openjdk.java.net (limck599) Date: Fri, 13 May 2022 08:53:04 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v8] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 11:11:29 GMT, Christian Hagedorn wrote: >> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method: >> >> Stack: [0x00007f6e01739000,0x00007f6e0183a000], sp=0x00007f6e01838110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f >> >> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method. >> >> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)): >> >> Stack: [0x00007f34fca18000,0x00007f34fcb19000], sp=0x00007f34fcb17110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 (c1_Compilation.cpp:607) >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec (c1_Compiler.cpp:250) >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 (compileBroker.cpp:2291) >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df (compileBroker.cpp:1966) >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 (compilerThread.cpp:59) >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d (thread.cpp:1297) >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 (thread.cpp:1280) >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 (thread.cpp:358) >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f (os_linux.cpp:705) >> >> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. >> >> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf >> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. >> >> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability. >> >> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. >> >> **Testing:** >> Apart from manual testing, I've added two kinds of tests: >> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers. >> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename. >> >> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation. >> >> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number. >> >> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user). >> >> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`! >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits: > > - Merge branch 'master' into JDK-8242181 > - Fix build, add GCC flag gdwarf-4 to exclude DWARF 5, add assertions > - Apply remaining review comments from Thomas Stuefe > - Change load_dwarf_file with DwarfFilePath and DebugInfo > - Revert renaming on Windows > - Merge branch 'master' into JDK-8242181 > - Updating some comments > - Cleanup loading dwarf file and add summary > - Review comments of first pass by Thomas except dwarf file loading > - Merge branch 'master' into JDK-8242181 > - ... and 50 more: https://git.openjdk.java.net/jdk/compare/60281810...229f1b90 Marked as reviewed by limck599 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jdk/pull/7126 From chagedorn at openjdk.java.net Fri May 13 08:53:06 2022 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Fri, 13 May 2022 08:53:06 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v8] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 13:34:03 GMT, Magnus Ihse Bursie wrote: >> make/autoconf/flags-cflags.m4 line 116: >> >>> 114: fi >>> 115: >>> 116: CFLAGS_DEBUG_SYMBOLS="-g -gdwarf-4" >> >> We may need to guard this with a FLAGS_COMPILER_CHECK_ARGUMENTS. Perhaps it should also be applied only on Linux since the whole feature is Linux only. What do you think @magicus? > > I'm googling around for some information about -gdwarf-4 but is mostly coming up empty handed. :( I found [this](https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-DWARF-5-Possible-Default) saying that dwarf-5 became default in gcc11. It also claims dwarf-4 is about 10 years old. My guess is that all our supported gcc versions do support -gdwarf-4, but this needs to be verified. > > In practice, we only use gcc on linux so I'm not convinced we need to have an addition check for that. If we ever are going to support gcc on other OSes I think we'll have many more, much harder problems, than to remove the -gdwarf-4 flag. I'm back to work again. I also had a look but could not find something on Google, either. I then skimmed through the old GCC manuals. I found the first occurrence of `-gdwarf-4` in the manual for GCC 4.5.4 [here](https://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc.pdf): - gdwarf-version Produce debugging information in DWARF format (if that is supported). This is the format used by DBX on IRIX 6. The value of version may be either 2, 3 or 4; the default version is 2. While the manual for GCC 4.4.7 only mentions `-gdwarf-2`: -gdwarf-2 Produce debugging information in DWARF version 2 format (if that is supported). This is the format used by DBX on IRIX 6. With this option, GCC uses features of DWARF version 3 when they are useful; version 3 is upward compatible with version 2, but may still cause problems for older debuggers. The minimum accepted GCC version is currently 5.0 according to: https://github.com/openjdk/jdk/blob/d5ae3833b1b71eb84fadb69c0c92851400f8921c/doc/building.md?plain=1#L341-L344 This suggests that all our supported GCC versions should accept `-gdwarf-4`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7126 From xgong at openjdk.java.net Fri May 13 09:01:49 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Fri, 13 May 2022 09:01:49 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v3] In-Reply-To: References: Message-ID: <_c_QPZQIL-ZxBs9TaKmrh7_1WcbEDH1pUwhTpOc6PD8=.75e4a61b-ebb6-491c-9c5b-9a035f0b9eaf@github.com> On Thu, 12 May 2022 16:07:54 GMT, Paul Sandoz wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename "use_predicate" to "needs_predicate" > > Yes, the tests were run in debug mode. The reporting of the missing constant occurs for the compiled method that is called from the method where the constants are declared e.g.: > > 719 240 b jdk.incubator.vector.Int256Vector::fromArray0 (15 bytes) > ** Rejected vector op (LoadVectorMasked,int,8) because architecture does not support it > ** missing constant: offsetInRange=Parm > @ 11 jdk.incubator.vector.IntVector::fromArray0Template (22 bytes) force inline by annotation > > > So it appears to be working as expected. A similar pattern occurs at a lower-level for the passing of the mask class. `Int256Vector::fromArray0` passes a constant class to `IntVector::fromArray0Template` (the compilation of which bails out before checking that the `offsetInRange` is constant). You are right @PaulSandoz ! I ran the tests and benchmarks with your patch, and no failure and performance regression are found. I will update the patch soon. Thanks for the help! ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From mcimadamore at openjdk.java.net Fri May 13 09:48:02 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 13 May 2022 09:48:02 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 08:33:11 GMT, Uwe Schindler wrote: >> src/java.base/share/classes/java/nio/channels/FileChannel.java line 1045: >> >>> 1043: * >>> 1044: * @throws UnsupportedOperationException >>> 1045: * If an unsupported map mode is specified. >> >> I think this should mention that UOE is also throws if the filesystem implementation does not support memory mapping. This may happen for filesystems like jrtfs or custom wrapper filesystems that do not implement the method below. >> >> As this is already merged, should I open a PR fixing the docs or open an issue? > > This change here also closes [JDK-8259034](https://bugs.openjdk.java.net/browse/JDK-8259034) @uschindler - the issue you mention with respect lack of UOE for wrong file system applies to BB as well. I suggest filing an issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Fri May 13 09:48:08 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 13 May 2022 09:48:08 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: Message-ID: <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com> On Fri, 13 May 2022 08:29:13 GMT, Uwe Schindler wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 65 commits: >> >> - Merge branch 'master' into foreign-preview >> - Merge branch 'master' into foreign-preview >> - Fix crashes in heap segment benchmarks due to misaligned access >> - Merge branch 'master' into foreign-preview >> - Update src/java.base/share/classes/jdk/internal/reflect/Reflection.java >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - Add tests for loaderLookup/restricted method corner cases >> - * Clarify what happens when SymbolLookup::loaderLookup is invoked from JNI >> * Tweak restricted method check to work when there's no caller class >> - Tweak examples in SymbolLookup javadoc >> - Merge branch 'master' into foreign-preview >> - Update src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - ... and 55 more: https://git.openjdk.java.net/jdk/compare/82aa0455...f170415b > > src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1164: > >> 1162: } >> 1163: if (unmapper != null) { >> 1164: AbstractMemorySegmentImpl segment = new MappedMemorySegmentImpl(unmapper.address(), unmapper, size, > > When reviewing the method for MappedByteBuffer: I think to make this consistent the "old" method should also use `address()` which applies the pagePosition. Currently it is confusing: > - New code returning `MemorySegment` uses `unmapper.address()` > - Old code returning `MappedByteBuffer` uses `unmapper.address + unmapper.pagePosition` (fields) > > Should I open an issue or a PR to fix this (because this is already merged)? > > See the mailing list posts: > - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016981.html > - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016990.html Please file an RFE. I suspect that there will be more little improvements and consolidation like this we'll want to make to this code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From xgong at openjdk.java.net Fri May 13 09:57:40 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Fri, 13 May 2022 09:57:40 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v4] In-Reply-To: References: Message-ID: <5WQ3tKFVgp4s4hW0rMZ4aVOo24I32lsIcrFG2cqkszc=.62ce9cc7-9b41-4a59-adff-cbd50e34069f@github.com> > Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception. > > This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize): > > > @ForceInline > public static > ByteVector fromArray(VectorSpecies species, > byte[] a, int offset, > VectorMask m) { > ByteSpecies vsp = (ByteSpecies) species; > if (offset >= 0 && offset <= (a.length - species.length())) { > return vsp.dummyVector().fromArray0(a, offset, m); > } > > // FIXME: optimize > checkMaskFromIndexSize(offset, vsp, m, 1, a.length); > return vsp.vOp(m, i -> a[offset + i]); > } > > Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed. > > Also adds the same vectorization support for masked: > - fromByteArray/fromByteBuffer > - fromBooleanArray > - fromCharArray > > The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system: > > Benchmark before After Units > LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE 737.542 1387.069 ops/ms > LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366 330.776 ops/ms > LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE 233.832 6125.026 ops/ms > LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE 233.816 7075.923 ops/ms > LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE 119.771 330.587 ops/ms > LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE 431.961 939.301 ops/ms > > Similar performance gain can also be observed on 512-bit SVE system. Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: Use integer constant for offsetInRange all the way through ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8035/files - new: https://git.openjdk.java.net/jdk/pull/8035/files/9c69206e..07edfbd5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8035&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8035&range=02-03 Stats: 438 lines in 39 files changed: 33 ins; 118 del; 287 mod Patch: https://git.openjdk.java.net/jdk/pull/8035.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8035/head:pull/8035 PR: https://git.openjdk.java.net/jdk/pull/8035 From ysuenaga at openjdk.java.net Fri May 13 10:02:30 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 13 May 2022 10:02:30 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Revert change for java.c , parse_manifest.c , LinuxPackage.c ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/b3afa3e0..d5ef2c63 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=03-04 Stats: 10 lines in 3 files changed: 1 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ihse at openjdk.java.net Fri May 13 10:07:27 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 10:07:27 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v8] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 11:11:29 GMT, Christian Hagedorn wrote: >> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method: >> >> Stack: [0x00007f6e01739000,0x00007f6e0183a000], sp=0x00007f6e01838110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f >> >> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method. >> >> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)): >> >> Stack: [0x00007f34fca18000,0x00007f34fcb19000], sp=0x00007f34fcb17110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 (c1_Compilation.cpp:607) >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec (c1_Compiler.cpp:250) >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 (compileBroker.cpp:2291) >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df (compileBroker.cpp:1966) >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 (compilerThread.cpp:59) >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d (thread.cpp:1297) >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 (thread.cpp:1280) >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 (thread.cpp:358) >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f (os_linux.cpp:705) >> >> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. >> >> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf >> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. >> >> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability. >> >> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. >> >> **Testing:** >> Apart from manual testing, I've added two kinds of tests: >> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers. >> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename. >> >> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation. >> >> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number. >> >> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user). >> >> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`! >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits: > > - Merge branch 'master' into JDK-8242181 > - Fix build, add GCC flag gdwarf-4 to exclude DWARF 5, add assertions > - Apply remaining review comments from Thomas Stuefe > - Change load_dwarf_file with DwarfFilePath and DebugInfo > - Revert renaming on Windows > - Merge branch 'master' into JDK-8242181 > - Updating some comments > - Cleanup loading dwarf file and add summary > - Review comments of first pass by Thomas except dwarf file loading > - Merge branch 'master' into JDK-8242181 > - ... and 50 more: https://git.openjdk.java.net/jdk/compare/60281810...229f1b90 Build changes look good. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7126 From ihse at openjdk.java.net Fri May 13 10:07:29 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 13 May 2022 10:07:29 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v8] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 08:43:35 GMT, Christian Hagedorn wrote: >> I'm googling around for some information about -gdwarf-4 but is mostly coming up empty handed. :( I found [this](https://www.phoronix.com/scan.php?page=news_item&px=GCC-11-DWARF-5-Possible-Default) saying that dwarf-5 became default in gcc11. It also claims dwarf-4 is about 10 years old. My guess is that all our supported gcc versions do support -gdwarf-4, but this needs to be verified. >> >> In practice, we only use gcc on linux so I'm not convinced we need to have an addition check for that. If we ever are going to support gcc on other OSes I think we'll have many more, much harder problems, than to remove the -gdwarf-4 flag. > > I'm back to work again. I also had a look but could not find something on Google, either. I then skimmed through the old GCC manuals. I found the first occurrence of `-gdwarf-4` in the manual for GCC 4.5.4 [here](https://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc.pdf): > > > - gdwarf-version > Produce debugging information in DWARF format (if that is supported). This > is the format used by DBX on IRIX 6. The value of version may be either 2, 3 > or 4; the default version is 2. > > While the manual for GCC 4.4.7 only mentions `-gdwarf-2`: > > -gdwarf-2 > Produce debugging information in DWARF version 2 format (if that is supported). This is the format used by DBX on > IRIX 6. With this option, GCC > uses features of DWARF version 3 when they are useful; version 3 is upward > compatible with version 2, but may still cause problems for older debuggers. > > > The minimum accepted GCC version is currently 5.0 according to: > https://github.com/openjdk/jdk/blob/d5ae3833b1b71eb84fadb69c0c92851400f8921c/doc/building.md?plain=1#L341-L344 > > This suggests that all our supported GCC versions should accept `-gdwarf-4`. @chhagedorn Thanks for the research. You provide more than necessary reason to accept `-gdwarf-4` without any further checks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7126 From uschindler at openjdk.java.net Fri May 13 11:06:12 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Fri, 13 May 2022 11:06:12 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com> References: <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com> Message-ID: <1YnnVIjQpjhYiSltazpn6tcdsisidHt_We7nSdorE7c=.d9c8451c-3c6b-491e-8fbe-8222f3087a75@github.com> On Fri, 13 May 2022 09:43:55 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1164: >> >>> 1162: } >>> 1163: if (unmapper != null) { >>> 1164: AbstractMemorySegmentImpl segment = new MappedMemorySegmentImpl(unmapper.address(), unmapper, size, >> >> When reviewing the method for MappedByteBuffer: I think to make this consistent the "old" method should also use `address()` which applies the pagePosition. Currently it is confusing: >> - New code returning `MemorySegment` uses `unmapper.address()` >> - Old code returning `MappedByteBuffer` uses `unmapper.address + unmapper.pagePosition` (fields) >> >> Should I open an issue or a PR to fix this (because this is already merged)? >> >> See the mailing list posts: >> - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016981.html >> - https://mail.openjdk.java.net/pipermail/panama-dev/2022-May/016990.html > > Please file an RFE. I suspect that there will be more little improvements and consolidation like this we'll want to make to this code. RFE = issue? ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Fri May 13 12:03:01 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 13 May 2022 12:03:01 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: <1YnnVIjQpjhYiSltazpn6tcdsisidHt_We7nSdorE7c=.d9c8451c-3c6b-491e-8fbe-8222f3087a75@github.com> References: <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com> <1YnnVIjQpjhYiSltazpn6tcdsisidHt_We7nSdorE7c=.d9c8451c-3c6b-491e-8fbe-8222f3087a75@github.com> Message-ID: On Fri, 13 May 2022 11:01:09 GMT, Uwe Schindler wrote: > RFE = issue? issue, with type RFE (request for enhancement) ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From uschindler at openjdk.java.net Fri May 13 12:19:15 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Fri, 13 May 2022 12:19:15 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: <0UyanEJDi08XdftuxNahqEyc3B0nGEdiq2GPmGYHafc=.a9d9a535-34c1-4a49-9d36-df724e1a0c3b@github.com> <1YnnVIjQpjhYiSltazpn6tcdsisidHt_We7nSdorE7c=.d9c8451c-3c6b-491e-8fbe-8222f3087a75@github.com> Message-ID: On Fri, 13 May 2022 11:59:12 GMT, Maurizio Cimadamore wrote: >> RFE = issue? > >> RFE = issue? > > issue, with type RFE (request for enhancement) See: https://bugs.openjdk.java.net/browse/JDK-8286734 ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From uschindler at openjdk.java.net Fri May 13 12:29:09 2022 From: uschindler at openjdk.java.net (Uwe Schindler) Date: Fri, 13 May 2022 12:29:09 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v45] In-Reply-To: References: Message-ID: <_qJfbHWbWDSXgHQx9PRP2YDQ7cLkC41BmxL_osQIRhs=.dd01fb6e-e671-4bb4-8332-9c9d337abaf9@github.com> On Fri, 13 May 2022 09:42:44 GMT, Maurizio Cimadamore wrote: >> This change here also closes [JDK-8259034](https://bugs.openjdk.java.net/browse/JDK-8259034) > > @uschindler - the issue you mention with respect lack of UOE for wrong file system applies to BB as well. I suggest filing an issue. See https://bugs.openjdk.java.net/browse/JDK-8286735 ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From jvernee at openjdk.java.net Fri May 13 13:23:41 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 13 May 2022 13:23:41 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v2] In-Reply-To: References: Message-ID: <7VrPuAg8gehM1WFBIRt780PFam3f28f6FBd2jLVRATM=.c6e003c8-93c4-4bb9-a95c-bbcbe916233d@github.com> > Hi, > > This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well. > > Thanks, > Jorn Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Use unaligned layout constants when filling in reconstituted structs (was accidentally dropped change) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8685/files - new: https://git.openjdk.java.net/jdk/pull/8685/files/6e038edf..80640bac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8685&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8685&range=00-01 Stats: 22 lines in 1 file changed: 12 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/8685.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8685/head:pull/8685 PR: https://git.openjdk.java.net/jdk/pull/8685 From ysuenaga at openjdk.java.net Fri May 13 14:17:44 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 13 May 2022 14:17:44 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 10:02:30 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Revert change for java.c , parse_manifest.c , LinuxPackage.c I've sent another review request for bug fixes as #8694 and #8696 , and I reverted change for them from this PR. Could you review this PR to suppress warnings which we can ignore? ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From jvernee at openjdk.java.net Fri May 13 15:10:57 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 13 May 2022 15:10:57 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v2] In-Reply-To: <7VrPuAg8gehM1WFBIRt780PFam3f28f6FBd2jLVRATM=.c6e003c8-93c4-4bb9-a95c-bbcbe916233d@github.com> References: <7VrPuAg8gehM1WFBIRt780PFam3f28f6FBd2jLVRATM=.c6e003c8-93c4-4bb9-a95c-bbcbe916233d@github.com> Message-ID: On Fri, 13 May 2022 13:23:41 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well. >> >> Thanks, >> Jorn >> >> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Use unaligned layout constants when filling in reconstituted structs (was accidentally dropped change) I seem to have found the issue. One required change was not included brought over from panama-foreign yet. I've included it now, so this should be ready for review. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From vlivanov at openjdk.java.net Fri May 13 19:17:46 2022 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 13 May 2022 19:17:46 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: <9NhIJsBLpV42NNz7rjhBu_cEvljMy1KIAA7IdTz1aGM=.1ac390e6-4834-4616-b85d-fda842c8e4fa@github.com> References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com> <9NhIJsBLpV42NNz7rjhBu_cEvljMy1KIAA7IdTz1aGM=.1ac390e6-4834-4616-b85d-fda842c8e4fa@github.com> Message-ID: On Thu, 12 May 2022 17:26:44 GMT, Jorn Vernee wrote: >>> Do nothing special for async exceptions. i.e. if they happen anywhere between 1. and 6. they will end up in one of the fallback handlers and the VM will be terminated. >> >> My understanding is that if they materialize while we're executing the upcall Java code, if that code has a try/catch block, we will go there, rather than crash the VM. >> >> In other words, IMHO the only problem with async exception is if they occur _after_ the Java user code has completed, because that will crash the Java adapter, this preventing it from returning to native call cleanly. >> >> So, either we disable async exceptions during that phase (e.g. after user code has executed, but before we return back to native code), or we just punt and stop. Since this seems like a corner^3 case, and since there are also other issue with upcalls that can occur if other threads do not cooperate (e.g. an upcall can get stuck into an infinite safepoint if the VM exits while an async native thread runs the upcall), and given that obtaining a linker is a restricted operation anyway, I don't think we should bend over backwards to try to add 1% more safety to something that's unavoidably sharp anyways. > > Ok. Then, if no one objects, I will leave this area as-is for now. (and perhaps come back to this issue in the future, if it becomes more pressing). > > (I'll also note that this issue already exists in the current code that's in mainline. So, it seems fair to address this as a followup as well, if needed). I don't see a way to reliably handle async exceptions purely with `try/catch`. In the end, there's always a safepoint poll right before returning from a method where new exception can be installed. So, there's always a small chance present to observe a pending exception on VM side irrespective of how hard you try on Java side. >From reliability perspective, I find it important to gracefully handle such corner cases. But I'm fine with addressing the problem separately. As an alternative solution, exception handling for upcalls can be handled by another upcall (into catch handler when pending exception is encountered). As a bonus, it allows to handle repeated exceptions. In the worst case, it would manifest as a hang (when async exceptions are continuously delivered). Still, some special handling is needed for stack overflow errors. (Not sure how those are handled now. Are they?) ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From vlivanov at openjdk.java.net Fri May 13 19:24:41 2022 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 13 May 2022 19:24:41 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v17] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 16:58:36 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. >> >> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. >> >> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: >> >> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. >> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. >> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). >> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. >> >> While the patch mostly consists of VM changes, there are also some Java changes to support (2). >> >> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. >> >> Testing: Tier1-4 >> >> Thanks, >> Jorn >> >> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 >> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 >> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 >> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 >> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 >> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a >> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 >> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f >> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 98 commits: > > - Merge branch 'master' into JEP-19-VM-IMPL2 > - Undo spurious changes. > - Merge branch 'JEP-19-VM-IMPL2' of https://github.com/JornVernee/jdk into JEP-19-VM-IMPL2 > - Apply copyright year updates per request of @nick-arm > > Co-authored-by: Nick Gasson > - Fix overwritten copyright years. > - Missed 2 years > - Update Oracle copyright years > - Revert "Block async exceptions during upcalls" > > This reverts commit b29ad8f46732666f2d07e63ce8701b1eb7bed790. > - Block async exceptions during upcalls > - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 > - ... and 88 more: https://git.openjdk.java.net/jdk/compare/2c5d1362...f55b6c59 Looks good. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5531: > 5529: } > 5530: > 5531: // On64 bit we will store integer like items to the stack as Missing space. src/hotspot/cpu/x86/macroAssembler_x86.cpp line 933: > 931: } else { > 932: assert(dst.is_single_reg(), "not a stack pair: (%s, %s), (%s, %s)", > 933: src.first()->name(), src.second()->name(), dst.first()->name(), dst.second()->name()); Still not indented properly. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Fri May 13 20:03:11 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 13 May 2022 20:03:11 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v17] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 19:16:36 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 98 commits: >> >> - Merge branch 'master' into JEP-19-VM-IMPL2 >> - Undo spurious changes. >> - Merge branch 'JEP-19-VM-IMPL2' of https://github.com/JornVernee/jdk into JEP-19-VM-IMPL2 >> - Apply copyright year updates per request of @nick-arm >> >> Co-authored-by: Nick Gasson >> - Fix overwritten copyright years. >> - Missed 2 years >> - Update Oracle copyright years >> - Revert "Block async exceptions during upcalls" >> >> This reverts commit b29ad8f46732666f2d07e63ce8701b1eb7bed790. >> - Block async exceptions during upcalls >> - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 >> - ... and 88 more: https://git.openjdk.java.net/jdk/compare/2c5d1362...f55b6c59 > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5531: > >> 5529: } >> 5530: >> 5531: // On64 bit we will store integer like items to the stack as > > Missing space. Oh, looks like i deleted the wrong space by accident. > src/hotspot/cpu/x86/macroAssembler_x86.cpp line 933: > >> 931: } else { >> 932: assert(dst.is_single_reg(), "not a stack pair: (%s, %s), (%s, %s)", >> 933: src.first()->name(), src.second()->name(), dst.first()->name(), dst.second()->name()); > > Still not indented properly. Shouldn't there be a 2-space indentation wrt the assert here? I could also indent all the arguments to be aligned with the format string, if that seems better. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Fri May 13 20:15:47 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 13 May 2022 20:15:47 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v7] In-Reply-To: References: <1Y6gupd3SigdhlFjonKu4x4z-0mwPwCc-LJsqt6pp4c=.201b0c49-4887-4440-8526-31420fa3dda3@github.com> <_lwAL7Yg4Rr98gmWeQisR1ioc8MkVK87npZEUbB4vOw=.6434e6a4-35b9-4f81-9df3-d71973f1d75e@github.com> <9J0HneQ8kNy0t1-JDUQsXzoj4ljYwg80jiespX8laL8=.c02f9a8e-04b5-40db-8024-cdec556fcc53@github.com> <95e2d32uLxJbWldoqsr9yAoT3LD8Yyd6cLmnFuvSEOI=.4e961828-6086-4c63-9bc3-6bb60f8a5931@github.com> <9NhIJsBLpV42NNz7rjhBu_cEvljMy1KIAA7IdTz1aGM=.1ac390e6-4834-4616-b85d-fda842c8e4fa@github.com> Message-ID: On Fri, 13 May 2022 19:13:46 GMT, Vladimir Ivanov wrote: >> Ok. Then, if no one objects, I will leave this area as-is for now. (and perhaps come back to this issue in the future, if it becomes more pressing). >> >> (I'll also note that this issue already exists in the current code that's in mainline. So, it seems fair to address this as a followup as well, if needed). > > I don't see a way to reliably handle async exceptions purely with `try/catch`. In the end, there's always a safepoint poll right before returning from a method where new exception can be installed. So, there's always a small chance present to observe a pending exception on VM side irrespective of how hard you try on Java side. > > From reliability perspective, I find it important to gracefully handle such corner cases. But I'm fine with addressing the problem separately. > > As an alternative solution, exception handling for upcalls can be handled by another upcall (into catch handler when pending exception is encountered). As a bonus, it allows to handle repeated exceptions. In the worst case, it would manifest as a hang (when async exceptions are continuously delivered). Still, some special handling is needed for stack overflow errors. (Not sure how those are handled now. Are they?) SOE (of the Java exception kind) is not specially handled right now. I think the same rule applies there: we can't unwind or return to native frames (at least not without some guidance from the user). I've filed an issue here to capture some of the discussion: https://bugs.openjdk.java.net/browse/JDK-8286761 ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From vlivanov at openjdk.java.net Fri May 13 20:50:46 2022 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 13 May 2022 20:50:46 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v17] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 19:59:40 GMT, Jorn Vernee wrote: >> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 933: >> >>> 931: } else { >>> 932: assert(dst.is_single_reg(), "not a stack pair: (%s, %s), (%s, %s)", >>> 933: src.first()->name(), src.second()->name(), dst.first()->name(), dst.second()->name()); >> >> Still not indented properly. > > Shouldn't there be a 2-space indentation wrt the assert here? I could also indent all the arguments to be aligned with the format string, if that seems better. It's preferred to indent multi-line argument lists on the column where argument list starts. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From vlivanov at openjdk.java.net Fri May 13 20:50:46 2022 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 13 May 2022 20:50:46 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v17] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 20:46:19 GMT, Vladimir Ivanov wrote: >> Shouldn't there be a 2-space indentation wrt the assert here? I could also indent all the arguments to be aligned with the format string, if that seems better. > > It's preferred to indent multi-line argument lists on the column where argument list starts. assert(dst.is_single_reg(), "not a stack pair: (%s, %s), (%s, %s)", src.first()->name(), src.second()->name(), dst.first()->name(), dst.second()->name()); ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Fri May 13 21:01:10 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 13 May 2022 21:01:10 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v18] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: - indentation - fix space ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/f55b6c59..2ea5bc94 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=16-17 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Fri May 13 21:01:11 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 13 May 2022 21:01:11 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v18] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 20:47:22 GMT, Vladimir Ivanov wrote: >> It's preferred to indent multi-line argument lists on the column where argument list starts. > > assert(dst.is_single_reg(), "not a stack pair: (%s, %s), (%s, %s)", > src.first()->name(), src.second()->name(), dst.first()->name(), dst.second()->name()); Done ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From kbarrett at openjdk.java.net Sun May 15 21:00:09 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 15 May 2022 21:00:09 GMT Subject: RFR: 8286262: Windows: Cleanup deprecation warning suppression Message-ID: Please review this cleanup of deprecation warning suppression when building for Windows. This change consists of several parts. (1) Remove the global deprecation warning suppression when building HotSpot for Windows. (2) Add macro definitions requesting suppression of selected sets of deprecation warnings when building HotSpot for Windows. (3) Remove unnecessary forwarding macros for various POSIX functions in globalDefinitions_visCPP.hpp. These were provided to avoid deprecation warnings (that were previously also being suppressed by the global request). They are now covered by the new macros provided by change (2) above. An alternative to item (3) is to not define _CRT_NONSTDC_NO_DEPRECATE (in item (2)) and either retain the forwarding macros or define os:: wrapper functions for all of the affected functions. We might eventually do the latter because of other reasons for avoiding some of these functions, but the approach being taken here is simpler. For documentation of _CRT_NONSTDC_NO_DEPRECATE, see: https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4996 Similarly for _CRT_SECURE_NO_WARNINGS. Perhaps similarly for _WINSOCK_DEPRECATED_NO_WARNINGS (though I didn't find any documentation for the latter). But it might be better to not supress the warnings and instead use the alternatives (JDK-8286781). Testing: mach5 tier1 ------------- Commit messages: - cleanup Windows deprecation warning suppression Changes: https://git.openjdk.java.net/jdk/pull/8718/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8718&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286262 Stats: 21 lines in 4 files changed: 2 ins; 13 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8718.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8718/head:pull/8718 PR: https://git.openjdk.java.net/jdk/pull/8718 From dholmes at openjdk.java.net Mon May 16 01:26:43 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 16 May 2022 01:26:43 GMT Subject: RFR: 8286368: Cleanup problem lists after loom integration [v2] In-Reply-To: References: Message-ID: On Tue, 10 May 2022 19:16:34 GMT, Leonid Mesnik wrote: >> 8286368: Cleanup problem lists after loom integration > > Leonid Mesnik 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 > - 8286368: Cleanup problem lists after loom integration test/hotspot/jtreg/ProblemList-Xcomp.txt line 38: > 36: serviceability/sa/TestJhsdbJstackMixed.java 8248675 linux-aarch64 > 37: > 38: compiler/c2/irTests/TestSkeletonPredicates.java 8286361 generic-all @lmesnik This line should not have been removed! ------------- PR: https://git.openjdk.java.net/jdk/pull/8604 From duke at openjdk.java.net Mon May 16 02:21:44 2022 From: duke at openjdk.java.net (Haomin) Date: Mon, 16 May 2022 02:21:44 GMT Subject: RFR: 8286452: The array length of testSmallConstArray should be small and const [v2] In-Reply-To: References: Message-ID: > testLargeVariableArray and testSmallConstArray are the same, the localArrlen of testSmallConstArray should be small and const. Haomin has updated the pull request incrementally with one additional commit since the last revision: modify copyright ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8621/files - new: https://git.openjdk.java.net/jdk/pull/8621/files/a7930fd5..00487af7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8621&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8621&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8621.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8621/head:pull/8621 PR: https://git.openjdk.java.net/jdk/pull/8621 From lmesnik at openjdk.java.net Mon May 16 02:28:47 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 16 May 2022 02:28:47 GMT Subject: RFR: 8286368: Cleanup problem lists after loom integration [v2] In-Reply-To: References: Message-ID: On Mon, 16 May 2022 01:23:09 GMT, David Holmes wrote: >> Leonid Mesnik 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 >> - 8286368: Cleanup problem lists after loom integration > > test/hotspot/jtreg/ProblemList-Xcomp.txt line 38: > >> 36: serviceability/sa/TestJhsdbJstackMixed.java 8248675 linux-aarch64 >> 37: >> 38: compiler/c2/irTests/TestSkeletonPredicates.java 8286361 generic-all > > @lmesnik This line should not have been removed! It might be a merge problem. My PR was submitted before 8286442. I remereged changes, however my merge commit also doesn't have removal of this line: https://github.com/openjdk/jdk/pull/8604/commits/8255e760ff1a2ff616f00f559de29e66d7036b39 So I am really confused and can't understand how I managed to introduce this problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/8604 From dholmes at openjdk.java.net Mon May 16 02:41:48 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 16 May 2022 02:41:48 GMT Subject: RFR: 8286368: Cleanup problem lists after loom integration [v2] In-Reply-To: References: Message-ID: On Mon, 16 May 2022 02:25:26 GMT, Leonid Mesnik wrote: >> test/hotspot/jtreg/ProblemList-Xcomp.txt line 38: >> >>> 36: serviceability/sa/TestJhsdbJstackMixed.java 8248675 linux-aarch64 >>> 37: >>> 38: compiler/c2/irTests/TestSkeletonPredicates.java 8286361 generic-all >> >> @lmesnik This line should not have been removed! > > It might be a merge problem. My PR was submitted before 8286442. I remereged changes, however my merge commit also doesn't have removal of this line: > https://github.com/openjdk/jdk/pull/8604/commits/8255e760ff1a2ff616f00f559de29e66d7036b39 > > So I am really confused and can't understand how I managed to introduce this problem. That is really bizarre. No individual commit shows the line being deleted, yet in the final commit it is. ------------- PR: https://git.openjdk.java.net/jdk/pull/8604 From duke at openjdk.java.net Mon May 16 06:47:50 2022 From: duke at openjdk.java.net (Haomin) Date: Mon, 16 May 2022 06:47:50 GMT Subject: RFR: 8286452: The array length of testSmallConstArray should be small and const [v2] In-Reply-To: References: Message-ID: On Mon, 16 May 2022 02:21:44 GMT, Haomin wrote: >> testLargeVariableArray and testSmallConstArray are the same, the localArrlen of testSmallConstArray should be small and const. > > Haomin has updated the pull request incrementally with one additional commit since the last revision: > > modify copyright @cl4es please review :) ------------- PR: https://git.openjdk.java.net/jdk/pull/8621 From chagedorn at openjdk.java.net Mon May 16 07:18:12 2022 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 16 May 2022 07:18:12 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v8] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 10:04:25 GMT, Magnus Ihse Bursie wrote: >> I'm back to work again. I also had a look but could not find something on Google, either. I then skimmed through the old GCC manuals. I found the first occurrence of `-gdwarf-4` in the manual for GCC 4.5.4 [here](https://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc.pdf): >> >> >> - gdwarf-version >> Produce debugging information in DWARF format (if that is supported). This >> is the format used by DBX on IRIX 6. The value of version may be either 2, 3 >> or 4; the default version is 2. >> >> While the manual for GCC 4.4.7 only mentions `-gdwarf-2`: >> >> -gdwarf-2 >> Produce debugging information in DWARF version 2 format (if that is supported). This is the format used by DBX on >> IRIX 6. With this option, GCC >> uses features of DWARF version 3 when they are useful; version 3 is upward >> compatible with version 2, but may still cause problems for older debuggers. >> >> >> The minimum accepted GCC version is currently 5.0 according to: >> https://github.com/openjdk/jdk/blob/d5ae3833b1b71eb84fadb69c0c92851400f8921c/doc/building.md?plain=1#L341-L344 >> >> This suggests that all our supported GCC versions should accept `-gdwarf-4`. > > @chhagedorn Thanks for the research. You provide more than necessary reason to accept `-gdwarf-4` without any further checks. Great, thanks for confirming this and reviewing the build changes! ------------- PR: https://git.openjdk.java.net/jdk/pull/7126 From jbachorik at openjdk.java.net Mon May 16 08:27:36 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Mon, 16 May 2022 08:27:36 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v7] In-Reply-To: References: Message-ID: <-Qyxt1vJeKwHeORs4OHDaSwa2OrMCCWgQD5tO9nVvfI=.6a4a2180-9c53-4164-868b-36b05827c919@github.com> > A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. > > Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. > >
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. > However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > >

> > _Note: This is a followup PR for #8061_ Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: Avoid check overhead when possible ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8549/files - new: https://git.openjdk.java.net/jdk/pull/8549/files/949609c8..5b1debc3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=05-06 Stats: 16 lines in 1 file changed: 8 ins; 6 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8549.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8549/head:pull/8549 PR: https://git.openjdk.java.net/jdk/pull/8549 From jbachorik at openjdk.java.net Mon May 16 08:49:40 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Mon, 16 May 2022 08:49:40 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v8] In-Reply-To: References: Message-ID: > A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. > > Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. > >
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. > However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > >

> > _Note: This is a followup PR for #8061_ Jaroslav Bachorik 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 two new commits since the last revision: - Use RAII object to manage thread in_asgct status - Avoid check overhead when possible ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8549/files - new: https://git.openjdk.java.net/jdk/pull/8549/files/5b1debc3..3db28ccf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=06-07 Stats: 23 lines in 3 files changed: 20 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8549.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8549/head:pull/8549 PR: https://git.openjdk.java.net/jdk/pull/8549 From shade at openjdk.java.net Mon May 16 09:26:47 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 16 May 2022 09:26:47 GMT Subject: RFR: 8286636: MacroAssembler::post_call_nop should have InstructionMark In-Reply-To: <9FGAXDJlzHK85Pz6nPimWEYlSwxJqWcfMSqAlncSyzc=.a8f06546-1087-477f-90ea-1cdb6f046991@github.com> References: <9FGAXDJlzHK85Pz6nPimWEYlSwxJqWcfMSqAlncSyzc=.a8f06546-1087-477f-90ea-1cdb6f046991@github.com> Message-ID: On Thu, 12 May 2022 11:32:05 GMT, Aleksey Shipilev wrote: > `InstructionMark` checks the instruction boundaries, which is important for relocatable instructions. Everywhere where we do any (?) sort of relocation, we do `InstructionMark`. I found that newly added `MacroAssembler::post_call_nop` does not have it, and thus some new code in x86_32 Loom prototype fails with missing instruction mark / instruction overlapping checks. > > If we add it to `InstructionMark` in AArch64 code, then "overlapping instructions" asserts start to fire, because Loom inserted `post_call_nops` when there was an active instruction mark. x86_64 solves this by [resetting the mark before the nop](https://github.com/openjdk/jdk/blob/40f43c6b1ffc88d55dd3223f5d0259ae73cf0356/src/hotspot/cpu/x86/x86_64.ad#L2084), this patch does the same. > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux AArch64 fastdebug `tier1` Any comments? ------------- PR: https://git.openjdk.java.net/jdk/pull/8678 From jbachorik at openjdk.java.net Mon May 16 09:51:43 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Mon, 16 May 2022 09:51:43 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v8] In-Reply-To: References: Message-ID: On Mon, 16 May 2022 08:49:40 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. >> >> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. >> >>

>> >> _Note: This is a followup PR for #8061_ > > Jaroslav Bachorik 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 two new commits since the last revision: > > - Use RAII object to manage thread in_asgct status > - Avoid check overhead when possible Ok, I moved the expensive check only after it is sure we are dealing with a zombie method. Thanks for all the suggestions! This change now looks much more self-contained than I hoped for. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From jbachorik at openjdk.java.net Mon May 16 09:51:45 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Mon, 16 May 2022 09:51:45 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v6] In-Reply-To: <6ikleowciR73wkChDKRAhEgUEuHH1ZtFXze7VjptS3Q=.29ab42a4-4926-420c-8ce8-8ed2db7ec8db@github.com> References: <6ikleowciR73wkChDKRAhEgUEuHH1ZtFXze7VjptS3Q=.29ab42a4-4926-420c-8ce8-8ed2db7ec8db@github.com> Message-ID: On Sat, 7 May 2022 04:59:44 GMT, Thomas Stuefe wrote: >> Jaroslav Bachorik 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: >> >> Move 'in_asgct' flag to JavaThread > > src/hotspot/share/prims/forte.cpp line 594: > >> 592: } >> 593: >> 594: thread->set_in_asgct(true); > > Suggestion: Use a small RAII Mark object instead. That way you prevent future errors if someone should add a return in the mids of AGCT. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From mgronlun at openjdk.java.net Mon May 16 10:25:28 2022 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 16 May 2022 10:25:28 GMT Subject: RFR: 8280844: Epoch shift synchronization point for Compiler threads is inadequate Message-ID: Greetings, [JDK-8233111](https://bugs.openjdk.java.net/browse/JDK-8233111) attempted to address artefact tagging for Compiler threads, letting threads run _thread_in_native to avoid the transition. Unfortunately, that attempt proved inadequate. The epoch race is avoided only by performing the transition to _thread_in_vm. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8280844 Changes: https://git.openjdk.java.net/jdk/pull/8724/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8724&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280844 Stats: 102 lines in 6 files changed: 14 ins; 84 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8724.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8724/head:pull/8724 PR: https://git.openjdk.java.net/jdk/pull/8724 From shade at openjdk.java.net Mon May 16 11:19:28 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 16 May 2022 11:19:28 GMT Subject: RFR: 8286808: Loom: Simplify generate_cont_thaw by passing thaw_kind directly Message-ID: I was staring at this code for x86_32 port, and it seems `exception` implies `return_barrier`. This mostly irks me because we are passing `2` to `Continuation::prepare_thaw` and implicitly coercing it to `bool` during the call. We can instead call with `1` when `return_barrier`. Further cleanup makes the change more obvious; we can pass `thaw_kind` directly to `generate_cont_thaw`, and thus simplify the code. Additional testing: - [x] `java/lang/Thread/virtual` on Linux x86_64 fastdebug - [x] `java/lang/Thread/virtual` on Linux AArch64 fastdebug ------------- Commit messages: - Fix AArch64 - Fix Changes: https://git.openjdk.java.net/jdk/pull/8725/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8725&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286808 Stats: 33 lines in 3 files changed: 12 ins; 4 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/8725.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8725/head:pull/8725 PR: https://git.openjdk.java.net/jdk/pull/8725 From shade at openjdk.java.net Mon May 16 11:29:06 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 16 May 2022 11:29:06 GMT Subject: RFR: 8286808: Loom: Simplify generate_cont_thaw by passing thaw_kind directly [v2] In-Reply-To: References: Message-ID: > I was staring at this code for x86_32 port, and it seems `exception` implies `return_barrier`. This mostly irks me because we are passing `2` to `Continuation::prepare_thaw` and implicitly coercing it to `bool` during the call. We can instead call with `1` when `return_barrier`. > > Further cleanup makes the change more obvious; we can pass `thaw_kind` directly to `generate_cont_thaw`, and thus simplify the code. Unused x86_32 and PPC64 stubs are just deleted without refactoring the args; this is supposed to produce a cleaner merge problem for current porting work. > > Additional testing: > - [x] `java/lang/Thread/virtual` on Linux x86_64 fastdebug > - [x] `java/lang/Thread/virtual` on Linux AArch64 fastdebug > - [x] Build Linux x86_32 > - [x] Build Linux PPC64 Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Remove unused generate_cont_thaw stubs too ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8725/files - new: https://git.openjdk.java.net/jdk/pull/8725/files/0d986818..d97dab48 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8725&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8725&range=00-01 Stats: 12 lines in 2 files changed: 0 ins; 12 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8725.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8725/head:pull/8725 PR: https://git.openjdk.java.net/jdk/pull/8725 From rpressler at openjdk.java.net Mon May 16 11:32:50 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Mon, 16 May 2022 11:32:50 GMT Subject: RFR: 8286808: Loom: Simplify generate_cont_thaw by passing thaw_kind directly [v2] In-Reply-To: References: Message-ID: On Mon, 16 May 2022 11:29:06 GMT, Aleksey Shipilev wrote: >> I was staring at this code for x86_32 port, and it seems `exception` implies `return_barrier`. This mostly irks me because we are passing `2` to `Continuation::prepare_thaw` and implicitly coercing it to `bool` during the call. We can instead call with `1` when `return_barrier`. >> >> Further cleanup makes the change more obvious; we can pass `thaw_kind` directly to `generate_cont_thaw`, and thus simplify the code. Unused x86_32 and PPC64 stubs are just deleted without refactoring the args; this is supposed to produce a cleaner merge problem for current porting work. >> >> Additional testing: >> - [x] `java/lang/Thread/virtual` on Linux x86_64 fastdebug >> - [x] `java/lang/Thread/virtual` on Linux AArch64 fastdebug >> - [x] Build Linux x86_32 >> - [x] Build Linux PPC64 > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused generate_cont_thaw stubs too Looks good. ------------- Marked as reviewed by rpressler (Author). PR: https://git.openjdk.java.net/jdk/pull/8725 From thartmann at openjdk.java.net Mon May 16 12:30:50 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 16 May 2022 12:30:50 GMT Subject: RFR: 8286376: Wrong condition for using non-immediate oops on AArch64 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 11:12:32 GMT, Erik ?sterlund wrote: > With the introduction of loom, nmethod entry barriers were added for all GCs. So far, the use of nmethod entry barriers has implied that nmethod oops are patched in the instruction stream. That is no longer the case. A condition was added to make sure we still get non-immediate oops on AArch64 for collectors that use nmethod entry barriers, and support immediate oops. However, the condition was messed up, so we instead end up doing the wrong thing. We should do the right thing. Looks good to me too. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8593 From smonteith at openjdk.java.net Mon May 16 12:55:50 2022 From: smonteith at openjdk.java.net (Stuart Monteith) Date: Mon, 16 May 2022 12:55:50 GMT Subject: RFR: 8286376: Wrong condition for using non-immediate oops on AArch64 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 11:12:32 GMT, Erik ?sterlund wrote: > With the introduction of loom, nmethod entry barriers were added for all GCs. So far, the use of nmethod entry barriers has implied that nmethod oops are patched in the instruction stream. That is no longer the case. A condition was added to make sure we still get non-immediate oops on AArch64 for collectors that use nmethod entry barriers, and support immediate oops. However, the condition was messed up, so we instead end up doing the wrong thing. We should do the right thing. LGTM. We should look at the effect of removing these immediates and just use the constant pool in all cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/8593 From rehn at openjdk.java.net Mon May 16 13:16:46 2022 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 16 May 2022 13:16:46 GMT Subject: RFR: 8286808: Loom: Simplify generate_cont_thaw by passing thaw_kind directly [v2] In-Reply-To: References: Message-ID: On Mon, 16 May 2022 11:29:06 GMT, Aleksey Shipilev wrote: >> I was staring at this code for x86_32 port, and it seems `exception` implies `return_barrier`. This mostly irks me because we are passing `2` to `Continuation::prepare_thaw` and implicitly coercing it to `bool` during the call. We can instead call with `1` when `return_barrier`. >> >> Further cleanup makes the change more obvious; we can pass `thaw_kind` directly to `generate_cont_thaw`, and thus simplify the code. Unused x86_32 and PPC64 stubs are just deleted without refactoring the args; this is supposed to produce a cleaner merge problem for current porting work. >> >> Additional testing: >> - [x] `java/lang/Thread/virtual` on Linux x86_64 fastdebug >> - [x] `java/lang/Thread/virtual` on Linux AArch64 fastdebug >> - [x] Build Linux x86_32 >> - [x] Build Linux PPC64 > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused generate_cont_thaw stubs too Looks good. ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8725 From jvernee at openjdk.java.net Mon May 16 14:52:04 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 16 May 2022 14:52:04 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v19] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Fix failure with SPEC disabled (accidentally dropped change) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/2ea5bc94..ff8835ee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=18 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=17-18 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jbachorik at openjdk.java.net Mon May 16 15:14:25 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Mon, 16 May 2022 15:14:25 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9] In-Reply-To: References: Message-ID: > A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. > > Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. > >
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. > However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > >

> > _Note: This is a followup PR for #8061_ Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: Restore the original find_blob behavior regarding dead blobs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8549/files - new: https://git.openjdk.java.net/jdk/pull/8549/files/3db28ccf..546dc819 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=07-08 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8549.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8549/head:pull/8549 PR: https://git.openjdk.java.net/jdk/pull/8549 From aph at openjdk.java.net Mon May 16 15:41:23 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 16 May 2022 15:41:23 GMT Subject: RFR: 8272094: compiler/codecache/TestStressCodeBuffers.java crashes with "failed to allocate space for trampoline" Message-ID: This problem is, I believe, caused by an assertion left in the source code after development. The fix is simply to remove the assertion. It's not at all easy to reproduce this bug, being a very intermittent failure, but in the end I reproduced it by making `-XX:+StressCodeBuffers` much more stressful, like so: diff --git a/src/hotspot/share/asm/codeBuffer.cpp b/src/hotspot/share/asm/codeBuffer.cpp index ddd946d7542..c74ba21cf63 100644 --- a/src/hotspot/share/asm/codeBuffer.cpp +++ b/src/hotspot/share/asm/codeBuffer.cpp @@ -837,7 +837,8 @@ void CodeBuffer::expand(CodeSection* which_cs, csize_t amount) { if (StressCodeBuffers && blob() != NULL) { static int expand_count = 0; if (expand_count >= 0) expand_count += 1; - if (expand_count > 100 && is_power_of_2(expand_count)) { + if (expand_count > 100 && // is_power_of_2(expand_count) + expand_count % 40 == 0) { tty->print_cr("StressCodeBuffers: have expanded %d times", expand_count); // simulate an occasional allocation failure: free_blob(); ------------- Commit messages: - 8272094: compiler/codecache/TestStressCodeBuffers.java crashes with "failed to allocate space for trampoline" Changes: https://git.openjdk.java.net/jdk/pull/8730/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8730&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272094 Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8730.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8730/head:pull/8730 PR: https://git.openjdk.java.net/jdk/pull/8730 From duke at openjdk.java.net Mon May 16 16:01:17 2022 From: duke at openjdk.java.net (olivergillespie) Date: Mon, 16 May 2022 16:01:17 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs Message-ID: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> The current code already does this for 'older' Skylake processors, namely those with _stepping < 5. My testing indicates this is a problem for later processors in this family too, so I have removed the max stepping condition. The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. A general description of the overall issue is given at https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using -XX:UseAVX=3, along with a corresponding performance reduction. I first saw this issue in a real production workload, where the main AVX3 instructions being executed were those generated for various flavours of disjoint_arraycopy. I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ -jar SPECjvm2008.jar -ikv -ict xml.transform Before the change, or with -XX:UseAVX=3: Valid run! Score on xml.transform: 776.00 ops/m After the change, or with -XX:UseAVX=2: Valid run! Score on xml.transform: 894.07 ops/m So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively affected by this change, but I contend that this is still the right move given the stark difference in this benchmark combined with the fact that use of AVX3 instructions can affect *all* processes/code on the host due to the downclocking, and the fact that this effect is very hard to root-cause, for example CPU profiles look very similar before and after since all code is equally slowed. ------------- Commit messages: - 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs Changes: https://git.openjdk.java.net/jdk/pull/8731/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8731&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286823 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8731/head:pull/8731 PR: https://git.openjdk.java.net/jdk/pull/8731 From shade at openjdk.java.net Mon May 16 16:04:48 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 16 May 2022 16:04:48 GMT Subject: RFR: 8272094: compiler/codecache/TestStressCodeBuffers.java crashes with "failed to allocate space for trampoline" In-Reply-To: References: Message-ID: On Mon, 16 May 2022 15:33:55 GMT, Andrew Haley wrote: > This problem is, I believe, caused by an assertion left in the source code after development. > The fix is simply to remove the assertion. > > It's not at all easy to reproduce this bug, being a very intermittent failure, but in the end I reproduced it by making `-XX:+StressCodeBuffers` much more stressful, like so: > > > diff --git a/src/hotspot/share/asm/codeBuffer.cpp b/src/hotspot/share/asm/codeBuffer.cpp > index ddd946d7542..c74ba21cf63 100644 > --- a/src/hotspot/share/asm/codeBuffer.cpp > +++ b/src/hotspot/share/asm/codeBuffer.cpp > @@ -837,7 +837,8 @@ void CodeBuffer::expand(CodeSection* which_cs, csize_t amount) { > if (StressCodeBuffers && blob() != NULL) { > static int expand_count = 0; > if (expand_count >= 0) expand_count += 1; > - if (expand_count > 100 && is_power_of_2(expand_count)) { > + if (expand_count > 100 && // is_power_of_2(expand_count) > + expand_count % 40 == 0) { > tty->print_cr("StressCodeBuffers: have expanded %d times", expand_count); > // simulate an occasional allocation failure: > free_blob(); Okay, so what is supposed to happen on failure? I see `aarch64.ad` has two rules that use `__ zero_words`. `clearArray_reg_reg` does: address tpc = __ zero_words($base$$Register, $cnt$$Register); if (tpc == NULL) { ciEnv::current()->record_failure("CodeCache is full"); return; } ...while `clearArray_imm_reg` calls through to `MacroAssembler::zero_words(Register base, uint64_t cnt)`, which still enters this method without checking the result? Maybe the predicate saves us here, IDK. ------------- PR: https://git.openjdk.java.net/jdk/pull/8730 From jvernee at openjdk.java.net Mon May 16 16:06:24 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 16 May 2022 16:06:24 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v20] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Cleanup UL usage ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/ff8835ee..d611f365 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=18-19 Stats: 14 lines in 5 files changed: 2 ins; 1 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Mon May 16 16:06:25 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 16 May 2022 16:06:25 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v19] In-Reply-To: References: Message-ID: On Mon, 16 May 2022 14:52:04 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. >> >> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. >> >> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: >> >> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. >> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. >> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). >> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. >> >> While the patch mostly consists of VM changes, there are also some Java changes to support (2). >> >> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. >> >> Testing: Tier1-4 >> >> Thanks, >> Jorn >> >> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 >> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 >> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 >> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 >> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 >> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a >> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 >> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f >> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Fix failure with SPEC disabled (accidentally dropped change) @robehn found a test failure in a non-default configuration that I've fixed [1] (it was addressed in the panama repo by a different patch). I've also cleaned up use of UL a bit [2]: the `panama` tag was renamed to `foreign` and I've added the `downcall` and `upcall` tags as well, for down/up call logging respectively. This is now all under NOT_PRODUCT. [1]: https://github.com/openjdk/jdk/pull/7959/commits/ff8835ee99203e94fb216c5bd7cf1ce610d5737f [2]: https://github.com/openjdk/jdk/pull/7959/commits/d611f365ade15cd7a7d005547814ce88fff0ca1a ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From kvn at openjdk.java.net Mon May 16 16:09:39 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 16 May 2022 16:09:39 GMT Subject: RFR: 8286636: MacroAssembler::post_call_nop should have InstructionMark In-Reply-To: <9FGAXDJlzHK85Pz6nPimWEYlSwxJqWcfMSqAlncSyzc=.a8f06546-1087-477f-90ea-1cdb6f046991@github.com> References: <9FGAXDJlzHK85Pz6nPimWEYlSwxJqWcfMSqAlncSyzc=.a8f06546-1087-477f-90ea-1cdb6f046991@github.com> Message-ID: On Thu, 12 May 2022 11:32:05 GMT, Aleksey Shipilev wrote: > `InstructionMark` checks the instruction boundaries, which is important for relocatable instructions. Everywhere where we do any (?) sort of relocation, we do `InstructionMark`. I found that newly added `MacroAssembler::post_call_nop` does not have it, and thus some new code in x86_32 Loom prototype fails with missing instruction mark / instruction overlapping checks. > > If we add it to `InstructionMark` in AArch64 code, then "overlapping instructions" asserts start to fire, because Loom inserted `post_call_nops` when there was an active instruction mark. x86_64 solves this by [resetting the mark before the nop](https://github.com/openjdk/jdk/blob/40f43c6b1ffc88d55dd3223f5d0259ae73cf0356/src/hotspot/cpu/x86/x86_64.ad#L2084), this patch does the same. > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux AArch64 fastdebug `tier1` Looks good. And your analysis is correct. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8678 From jvernee at openjdk.java.net Mon May 16 16:15:49 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 16 May 2022 16:15:49 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v21] In-Reply-To: References: Message-ID: <-H-hj0CmArcV48YOFCPUC1yIZXJxZ41p9PGBP-E_Vc0=.dad63c91-0e01-4124-9b44-467134a26b75@github.com> > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Missing ASSERT -> NOT_PRODUCT ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/d611f365..406f3e83 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=20 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=19-20 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From shade at openjdk.java.net Mon May 16 16:19:55 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 16 May 2022 16:19:55 GMT Subject: RFR: 8286636: MacroAssembler::post_call_nop should have InstructionMark In-Reply-To: References: <9FGAXDJlzHK85Pz6nPimWEYlSwxJqWcfMSqAlncSyzc=.a8f06546-1087-477f-90ea-1cdb6f046991@github.com> Message-ID: <9kcsnmhxkdE_mrRyFXQcmzI_oSdq47ANF-6td5sNqBI=.4413d460-459b-4ad8-bff7-d22601e3ccad@github.com> On Mon, 16 May 2022 16:06:32 GMT, Vladimir Kozlov wrote: > Looks good. And your analysis is correct. Thanks! @theRealAph, are you good with this discussion? ------------- PR: https://git.openjdk.java.net/jdk/pull/8678 From aph at openjdk.java.net Mon May 16 16:58:34 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 16 May 2022 16:58:34 GMT Subject: RFR: 8272094: compiler/codecache/TestStressCodeBuffers.java crashes with "failed to allocate space for trampoline" In-Reply-To: References: Message-ID: On Mon, 16 May 2022 16:01:46 GMT, Aleksey Shipilev wrote: > Okay, so what is supposed to happen on failure? I see `aarch64.ad` has two rules that use `__ zero_words`. > > `clearArray_reg_reg` does: > > ``` > address tpc = __ zero_words($base$$Register, $cnt$$Register); > if (tpc == NULL) { > ciEnv::current()->record_failure("CodeCache is full"); > return; > } > ``` > > ...while `clearArray_imm_reg` calls through to `MacroAssembler::zero_words(Register base, uint64_t cnt)`, which still enters this method without checking the result? Maybe the predicate saves us here, IDK. Good catch. Yes, it is saved by the predicate, which is `cnt < (BlockZeroingLowLimit >> LogBytesPerWord)`. The macro checks for `cnt <= (uint64_t)BlockZeroingLowLimit / BytesPerWord`, and in that case generates a short inline sequence. It's pretty evil code, though. (Can we say "pathological coupling"?. I think I'll add a check, although it will be unreachable in the current source because of the predicate. ------------- PR: https://git.openjdk.java.net/jdk/pull/8730 From aph-open at littlepinkcloud.com Mon May 16 17:03:22 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Mon, 16 May 2022 18:03:22 +0100 Subject: RFR: 8286636: MacroAssembler::post_call_nop should have InstructionMark In-Reply-To: <9kcsnmhxkdE_mrRyFXQcmzI_oSdq47ANF-6td5sNqBI=.4413d460-459b-4ad8-bff7-d22601e3ccad@github.com> References: <9FGAXDJlzHK85Pz6nPimWEYlSwxJqWcfMSqAlncSyzc=.a8f06546-1087-477f-90ea-1cdb6f046991@github.com> <9kcsnmhxkdE_mrRyFXQcmzI_oSdq47ANF-6td5sNqBI=.4413d460-459b-4ad8-bff7-d22601e3ccad@github.com> Message-ID: <06899fe7-7e2d-1346-e8af-30323455da5d@littlepinkcloud.com> On 5/16/22 17:19, Aleksey Shipilev wrote: > On Mon, 16 May 2022 16:06:32 GMT, Vladimir Kozlov wrote: > >> Looks good. And your analysis is correct. > > Thanks! @theRealAph, are you good with this discussion? As far as I understand it, yes. But my understanding of inst_mark is somewhat threadbare. From aph at openjdk.java.net Mon May 16 17:26:09 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 16 May 2022 17:26:09 GMT Subject: RFR: 8272094: compiler/codecache/TestStressCodeBuffers.java crashes with "failed to allocate space for trampoline" [v2] In-Reply-To: References: Message-ID: > This problem is, I believe, caused by an assertion left in the source code after development. > The fix is simply to remove the assertion. > > It's not at all easy to reproduce this bug, being a very intermittent failure, but in the end I reproduced it by making `-XX:+StressCodeBuffers` much more stressful, like so: > > > diff --git a/src/hotspot/share/asm/codeBuffer.cpp b/src/hotspot/share/asm/codeBuffer.cpp > index ddd946d7542..c74ba21cf63 100644 > --- a/src/hotspot/share/asm/codeBuffer.cpp > +++ b/src/hotspot/share/asm/codeBuffer.cpp > @@ -837,7 +837,8 @@ void CodeBuffer::expand(CodeSection* which_cs, csize_t amount) { > if (StressCodeBuffers && blob() != NULL) { > static int expand_count = 0; > if (expand_count >= 0) expand_count += 1; > - if (expand_count > 100 && is_power_of_2(expand_count)) { > + if (expand_count > 100 && // is_power_of_2(expand_count) > + expand_count % 40 == 0) { > tty->print_cr("StressCodeBuffers: have expanded %d times", expand_count); > // simulate an occasional allocation failure: > free_blob(); Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: 8272094: compiler/codecache/TestStressCodeBuffers.java crashes with "failed to allocate space for trampoline" ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8730/files - new: https://git.openjdk.java.net/jdk/pull/8730/files/ae6335a3..c06acfac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8730&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8730&range=00-01 Stats: 11 lines in 3 files changed: 7 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8730.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8730/head:pull/8730 PR: https://git.openjdk.java.net/jdk/pull/8730 From shade at openjdk.java.net Mon May 16 17:35:33 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 16 May 2022 17:35:33 GMT Subject: RFR: 8272094: compiler/codecache/TestStressCodeBuffers.java crashes with "failed to allocate space for trampoline" [v2] In-Reply-To: References: Message-ID: On Mon, 16 May 2022 17:26:09 GMT, Andrew Haley wrote: >> This problem is, I believe, caused by an assertion left in the source code after development. >> The fix is simply to remove the assertion. >> >> It's not at all easy to reproduce this bug, being a very intermittent failure, but in the end I reproduced it by making `-XX:+StressCodeBuffers` much more stressful, like so: >> >> >> diff --git a/src/hotspot/share/asm/codeBuffer.cpp b/src/hotspot/share/asm/codeBuffer.cpp >> index ddd946d7542..c74ba21cf63 100644 >> --- a/src/hotspot/share/asm/codeBuffer.cpp >> +++ b/src/hotspot/share/asm/codeBuffer.cpp >> @@ -837,7 +837,8 @@ void CodeBuffer::expand(CodeSection* which_cs, csize_t amount) { >> if (StressCodeBuffers && blob() != NULL) { >> static int expand_count = 0; >> if (expand_count >= 0) expand_count += 1; >> - if (expand_count > 100 && is_power_of_2(expand_count)) { >> + if (expand_count > 100 && // is_power_of_2(expand_count) >> + expand_count % 40 == 0) { >> tty->print_cr("StressCodeBuffers: have expanded %d times", expand_count); >> // simulate an occasional allocation failure: >> free_blob(); > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > 8272094: compiler/codecache/TestStressCodeBuffers.java crashes with "failed to allocate space for trampoline" I would just do `return pc()` and `return zero_words(...)`. Or at least initialize `address result = nullptr;`? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8730 From jvernee at openjdk.java.net Mon May 16 17:40:41 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 16 May 2022 17:40:41 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: References: Message-ID: > Hi, > > This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well. > > Thanks, > Jorn > > Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: BootstrapMethodError -> ExceptionInInitializerError ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8685/files - new: https://git.openjdk.java.net/jdk/pull/8685/files/80640bac..cd3daab5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8685&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8685&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8685.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8685/head:pull/8685 PR: https://git.openjdk.java.net/jdk/pull/8685 From jvernee at openjdk.java.net Mon May 16 17:40:42 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 16 May 2022 17:40:42 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: <_vOeEJsQJfMPt3ECcI2OKwrFBS4WPRqJA8O6YtFkiI4=.f5285c7b-cf85-4f6e-a206-1262ee29bec2@github.com> References: <_vOeEJsQJfMPt3ECcI2OKwrFBS4WPRqJA8O6YtFkiI4=.f5285c7b-cf85-4f6e-a206-1262ee29bec2@github.com> Message-ID: On Thu, 12 May 2022 18:15:54 GMT, liach wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> BootstrapMethodError -> ExceptionInInitializerError > > test/micro/org/openjdk/bench/java/lang/foreign/LinkUpcall.java line 61: > >> 59: BLANK = lookup().findStatic(LinkUpcall.class, "blank", MethodType.methodType(void.class)); >> 60: } catch (ReflectiveOperationException e) { >> 61: throw new BootstrapMethodError(e); > > You probably mean exception in initializer error. Change it to ExceptionInInitializerError ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From aph at openjdk.java.net Mon May 16 17:43:10 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 16 May 2022 17:43:10 GMT Subject: RFR: 8272094: compiler/codecache/TestStressCodeBuffers.java crashes with "failed to allocate space for trampoline" [v3] In-Reply-To: References: Message-ID: > This problem is, I believe, caused by an assertion left in the source code after development. > The fix is simply to remove the assertion. > > It's not at all easy to reproduce this bug, being a very intermittent failure, but in the end I reproduced it by making `-XX:+StressCodeBuffers` much more stressful, like so: > > > diff --git a/src/hotspot/share/asm/codeBuffer.cpp b/src/hotspot/share/asm/codeBuffer.cpp > index ddd946d7542..c74ba21cf63 100644 > --- a/src/hotspot/share/asm/codeBuffer.cpp > +++ b/src/hotspot/share/asm/codeBuffer.cpp > @@ -837,7 +837,8 @@ void CodeBuffer::expand(CodeSection* which_cs, csize_t amount) { > if (StressCodeBuffers && blob() != NULL) { > static int expand_count = 0; > if (expand_count >= 0) expand_count += 1; > - if (expand_count > 100 && is_power_of_2(expand_count)) { > + if (expand_count > 100 && // is_power_of_2(expand_count) > + expand_count % 40 == 0) { > tty->print_cr("StressCodeBuffers: have expanded %d times", expand_count); > // simulate an occasional allocation failure: > free_blob(); Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: 8272094: compiler/codecache/TestStressCodeBuffers.java crashes with "failed to allocate space for trampoline" ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8730/files - new: https://git.openjdk.java.net/jdk/pull/8730/files/c06acfac..5183ed17 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8730&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8730&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8730.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8730/head:pull/8730 PR: https://git.openjdk.java.net/jdk/pull/8730 From aph at openjdk.java.net Mon May 16 17:43:11 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 16 May 2022 17:43:11 GMT Subject: RFR: 8272094: compiler/codecache/TestStressCodeBuffers.java crashes with "failed to allocate space for trampoline" [v2] In-Reply-To: References: Message-ID: On Mon, 16 May 2022 17:32:30 GMT, Aleksey Shipilev wrote: > I would just do `return pc()` and `return zero_words(...)`. Or at least initialize `address result = nullptr;`? I'd rather the branches in an if/else likr this come together at the end than jump out in the middle. But yes, i take your point about the initialization. ------------- PR: https://git.openjdk.java.net/jdk/pull/8730 From kvn at openjdk.java.net Mon May 16 17:53:32 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 16 May 2022 17:53:32 GMT Subject: RFR: 8272094: compiler/codecache/TestStressCodeBuffers.java crashes with "failed to allocate space for trampoline" [v3] In-Reply-To: References: Message-ID: On Mon, 16 May 2022 17:43:10 GMT, Andrew Haley wrote: >> This problem is, I believe, caused by an assertion left in the source code after development. >> The fix is simply to remove the assertion. >> >> It's not at all easy to reproduce this bug, being a very intermittent failure, but in the end I reproduced it by making `-XX:+StressCodeBuffers` much more stressful, like so: >> >> >> diff --git a/src/hotspot/share/asm/codeBuffer.cpp b/src/hotspot/share/asm/codeBuffer.cpp >> index ddd946d7542..c74ba21cf63 100644 >> --- a/src/hotspot/share/asm/codeBuffer.cpp >> +++ b/src/hotspot/share/asm/codeBuffer.cpp >> @@ -837,7 +837,8 @@ void CodeBuffer::expand(CodeSection* which_cs, csize_t amount) { >> if (StressCodeBuffers && blob() != NULL) { >> static int expand_count = 0; >> if (expand_count >= 0) expand_count += 1; >> - if (expand_count > 100 && is_power_of_2(expand_count)) { >> + if (expand_count > 100 && // is_power_of_2(expand_count) >> + expand_count % 40 == 0) { >> tty->print_cr("StressCodeBuffers: have expanded %d times", expand_count); >> // simulate an occasional allocation failure: >> free_blob(); > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > 8272094: compiler/codecache/TestStressCodeBuffers.java crashes with "failed to allocate space for trampoline" Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8730 From ihse at openjdk.java.net Mon May 16 18:34:40 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 16 May 2022 18:34:40 GMT Subject: RFR: 8286262: Windows: Cleanup deprecation warning suppression In-Reply-To: References: Message-ID: On Sun, 15 May 2022 20:50:25 GMT, Kim Barrett wrote: > Please review this cleanup of deprecation warning suppression when building > for Windows. > > This change consists of several parts. > > (1) Remove the global deprecation warning suppression when building HotSpot > for Windows. > > (2) Add macro definitions requesting suppression of selected sets of > deprecation warnings when building HotSpot for Windows. > > (3) Remove unnecessary forwarding macros for various POSIX functions in > globalDefinitions_visCPP.hpp. These were provided to avoid deprecation > warnings (that were previously also being suppressed by the global request). > They are now covered by the new macros provided by change (2) above. > > An alternative to item (3) is to not define _CRT_NONSTDC_NO_DEPRECATE (in item > (2)) and either retain the forwarding macros or define os:: wrapper functions > for all of the affected functions. We might eventually do the latter because > of other reasons for avoiding some of these functions, but the approach being > taken here is simpler. > > For documentation of _CRT_NONSTDC_NO_DEPRECATE, see: > https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility > https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4996 > > Similarly for _CRT_SECURE_NO_WARNINGS. > > Perhaps similarly for _WINSOCK_DEPRECATED_NO_WARNINGS (though I didn't find > any documentation for the latter). But it might be better to not supress the > warnings and instead use the alternatives (JDK-8286781). > > Testing: > mach5 tier1 Looks good to me, build-wise. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8718 From prr at openjdk.java.net Mon May 16 19:25:45 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 16 May 2022 19:25:45 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 10:02:30 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Revert change for java.c , parse_manifest.c , LinuxPackage.c Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From prr at openjdk.java.net Mon May 16 19:25:45 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 16 May 2022 19:25:45 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v2] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 00:26:41 GMT, Yasumasa Suenaga wrote: >> I don't understand what the actual warning is getting at .. can anyone explain it ? >> >> FWIW the code is still the same in upstream harfbuzz >> https://github.com/harfbuzz/harfbuzz/blob/main/src/hb-font.cc > > I've pasted a part of warning messages to description of this PR, all of messages are here: > > > In function 'void trampoline_reference(hb_trampoline_closure_t*)', > inlined from 'void hb_font_funcs_set_glyph_func(hb_font_funcs_t*, hb_font_get_glyph_func_t, void*, hb_destroy_func_t)' at /home/ysuenaga/github-forked/jdk/src/java.desktop/share/native/libharfbuzz/hb-font.cc:2368:24: So upstream say it is not a problem since the analysis overlooks that it would not reach that free if it were immutable because of a previous check. I guess we disable the false positive warning for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From redestad at openjdk.java.net Mon May 16 20:12:35 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 16 May 2022 20:12:35 GMT Subject: RFR: 8286452: The array length of testSmallConstArray should be small and const [v2] In-Reply-To: References: Message-ID: On Mon, 16 May 2022 02:21:44 GMT, Haomin wrote: >> testLargeVariableArray and testSmallConstArray are the same, the localArrlen of testSmallConstArray should be small and const. > > Haomin has updated the pull request incrementally with one additional commit since the last revision: > > modify copyright Looks reasonable to me. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8621 From ysuenaga at openjdk.java.net Tue May 17 01:28:49 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 01:28:49 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: <-yJMgbHWlT4vecBv2EJIPe6_ITN_s8VYFkwnfPB67NM=.75b5fb61-88a0-4c01-800d-7a300dc6daac@github.com> References: <-yJMgbHWlT4vecBv2EJIPe6_ITN_s8VYFkwnfPB67NM=.75b5fb61-88a0-4c01-800d-7a300dc6daac@github.com> Message-ID: On Thu, 12 May 2022 11:02:02 GMT, Magnus Ihse Bursie wrote: >> Thanks for all to review this PR! I think we should separate this issue as following: >> >> * Suppress warnings >> * make/modules/java.desktop/lib/Awt2dLibraries.gmk >> * src/hotspot/share/classfile/bytecodeAssembler.cpp >> * src/hotspot/share/classfile/classFileParser.cpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> * src/hotspot/share/opto/memnode.cpp >> * src/hotspot/share/opto/type.cpp >> * src/hotspot/share/utilities/compilerWarnings.hpp >> * src/hotspot/share/utilities/compilerWarnings_gcc.hpp >> * src/java.base/unix/native/libjli/java_md_common.c >> * Bug fixes >> * src/java.base/share/native/libjli/java.c >> * src/java.base/share/native/libjli/parse_manifest.c >> * src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c >> >> I want to include the change of Awt2dLibraries.gmk (HarfBuzz) in this PR because it is 3rd party library. >> >> I will separate in above if I do not hear any objections, and this issue (PR) handles "suppress warnings" only. > > @YaSuenag From my PoV this sounds like a good suggestion. @magicus @prrace Thanks for your review! Can I get the review from HotSpot folks? @kimbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Tue May 17 02:20:56 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 17 May 2022 02:20:56 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v4] In-Reply-To: References: Message-ID: On Thu, 12 May 2022 18:28:02 GMT, Kim Barrett wrote: >> Thanks for all to review this PR! I think we should separate this issue as following: >> >> * Suppress warnings >> * make/modules/java.desktop/lib/Awt2dLibraries.gmk >> * src/hotspot/share/classfile/bytecodeAssembler.cpp >> * src/hotspot/share/classfile/classFileParser.cpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> * src/hotspot/share/opto/memnode.cpp >> * src/hotspot/share/opto/type.cpp >> * src/hotspot/share/utilities/compilerWarnings.hpp >> * src/hotspot/share/utilities/compilerWarnings_gcc.hpp >> * src/java.base/unix/native/libjli/java_md_common.c >> * Bug fixes >> * src/java.base/share/native/libjli/java.c >> * src/java.base/share/native/libjli/parse_manifest.c >> * src/jdk.jpackage/linux/native/applauncher/LinuxPackage.c >> >> I want to include the change of Awt2dLibraries.gmk (HarfBuzz) in this PR because it is 3rd party library. >> >> I will separate in above if I do not hear any objections, and this issue (PR) handles "suppress warnings" only. > >> @YaSuenag From my PoV this sounds like a good suggestion. > > +1 > Can I get the review from HotSpot folks? @kimbarrett Already working on it. There are some I don't understand yet. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From duke at openjdk.java.net Tue May 17 02:21:36 2022 From: duke at openjdk.java.net (Haomin) Date: Tue, 17 May 2022 02:21:36 GMT Subject: Integrated: 8286452: The array length of testSmallConstArray should be small and const In-Reply-To: References: Message-ID: On Tue, 10 May 2022 03:19:36 GMT, Haomin wrote: > testLargeVariableArray and testSmallConstArray are the same, the localArrlen of testSmallConstArray should be small and const. This pull request has now been integrated. Changeset: d65fba41 Author: wanghaomin Committer: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/d65fba412ec8e5a076d4940c932b70c629bb9dc7 Stats: 9 lines in 1 file changed: 1 ins; 0 del; 8 mod 8286452: The array length of testSmallConstArray should be small and const Reviewed-by: redestad ------------- PR: https://git.openjdk.java.net/jdk/pull/8621 From kbarrett at openjdk.java.net Tue May 17 03:19:55 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 17 May 2022 03:19:55 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Fri, 13 May 2022 10:02:30 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Revert change for java.c , parse_manifest.c , LinuxPackage.c Some suggestions for code changes instead of warning suppression. And some warnings that I don't yet understand and don't think should be suppressed without more details or investigation. src/hotspot/share/classfile/bytecodeAssembler.cpp line 95: > 93: ShouldNotReachHere(); > 94: } > 95: PRAGMA_DIAG_POP One of these is another of the symbol_at_put cases that I don't understand. Are there other cases in the switch that warn? And if so, which ones and how? There are no details of this one in the PR cover description. src/hotspot/share/classfile/classFileParser.cpp line 5970: > 5968: PRAGMA_STRINGOP_OVERFLOW_IGNORED > 5969: _cp->symbol_at_put(hidden_index, _class_name); > 5970: PRAGMA_DIAG_POP I don't understand these warning suppressions for symbol_at_put (here and elsewhere). I don't see any stringops here. What is the compiler complaining about? (There's no mention of classfile stuff in the review cover message.) src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp line 103: > 101: PRAGMA_STRINGOP_OVERFLOW_IGNORED > 102: *dest = op(bits, *dest); > 103: PRAGMA_DIAG_POP I see no stringop here. I'm still trying to understand what the compiler is complaining about. src/hotspot/share/opto/memnode.cpp line 1413: > 1411: bt == T_BYTE || bt == T_SHORT || > 1412: bt == T_INT || bt == T_LONG, "wrong type = %s", type2name(bt)); > 1413: PRAGMA_DIAG_POP The problem here is the definition of type2name, which returns NULL for an unknown BasicType. It would probably be better if it returned a recognizable string for that situation, eliminating this warning at it's source. src/hotspot/share/opto/type.cpp line 4300: > 4298: PRAGMA_FORMAT_OVERFLOW_IGNORED > 4299: fatal("not an element type: %s", type2name(etype)); > 4300: PRAGMA_DIAG_POP Another occurrence of type2name returning NULL for unknown BasicType. ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Tue May 17 04:56:00 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 17 May 2022 04:56:00 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 03:05:09 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert change for java.c , parse_manifest.c , LinuxPackage.c > > src/hotspot/share/opto/memnode.cpp line 1413: > >> 1411: bt == T_BYTE || bt == T_SHORT || >> 1412: bt == T_INT || bt == T_LONG, "wrong type = %s", type2name(bt)); >> 1413: PRAGMA_DIAG_POP > > The problem here is the definition of type2name, which returns NULL for an unknown BasicType. It would probably be better if it returned a recognizable string for that situation, eliminating this warning at it's source. While looking at type2name, I noticed the comment for the immediately preceding type2name_tab is wrong. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From dholmes at openjdk.java.net Tue May 17 05:41:54 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 17 May 2022 05:41:54 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9] In-Reply-To: References: Message-ID: On Mon, 16 May 2022 15:14:25 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. >> >> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. >> >>

>> >> _Note: This is a followup PR for #8061_ > > Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: > > Restore the original find_blob behavior regarding dead blobs src/hotspot/share/prims/forte.hpp line 53: > 51: ASGCTMark() : ASGCTMark(JavaThread::current()) {} > 52: ~ASGCTMark() { > 53: JavaThread::current()->set_in_asgct(false); You can't call `JavaThread::current()` in any of this code as it is not safe from a signal handling context. (There is an existing use in ASGCT that is also unsafe.) I suggest not having the no-arg constructor and require the current JavaThread, or null, to be passed in (having already been safely obtained by the caller). You can then assert using `Thread::current_or_null_safe()`. Personally I find the ASGCTMark complete overkill for this situation as there is only ever going to be a single use - sorry @tstuefe - it is just complicating things IMO. src/hotspot/share/runtime/thread.hpp line 1650: > 1648: static void vm_exit_on_osthread_failure(JavaThread* thread); > 1649: > 1650: Don't need two blank lines. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From forax at openjdk.java.net Tue May 17 05:57:57 2022 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Tue, 17 May 2022 05:57:57 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: References: Message-ID: On Mon, 16 May 2022 17:40:41 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well. >> >> Thanks, >> Jorn >> >> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > BootstrapMethodError -> ExceptionInInitializerError src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 98: > 96: private static final String CLASS_DATA_DESC = methodType(Object.class, MethodHandles.Lookup.class, String.class, Class.class).descriptorString(); > 97: private static final String RELEASE0_DESC = methodType(void.class).descriptorString(); > 98: private static final String ACQUIRE0_DESC = methodType(void.class).descriptorString(); calling methodType() is quite slow because of the cache of MethodType so maybe those initialization should be done explicitly in a static block to avoid to recompute methodType(long).descriptorString() several times src/java.base/share/classes/jdk/internal/foreign/abi/SoftReferenceCache.java line 42: > 40: > 41: private class Node { > 42: private SoftReference ref; this code looks like a double check locking so ref should be volatile ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From forax at openjdk.java.net Tue May 17 06:05:44 2022 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Tue, 17 May 2022 06:05:44 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: References: Message-ID: On Mon, 16 May 2022 17:40:41 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well. >> >> Thanks, >> Jorn >> >> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > BootstrapMethodError -> ExceptionInInitializerError src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 157: > 155: } > 156: > 157: static MethodHandle doSpecialize(MethodHandle leafHandle, CallingSequence callingSequence, ABIDescriptor abi) { I think thise method should be split in to, one version for the upcall, one for the downcall, i do not see the point of merging the two codes. src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 816: > 814: return; > 815: } > 816: if (con instanceof Integer) { those can use the instanceof + type pattern ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From forax at openjdk.java.net Tue May 17 06:13:00 2022 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Tue, 17 May 2022 06:13:00 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: References: Message-ID: <90FVgw2gmUdqeq6_HDCMfsRiGvEqVpXIq_a4_Cw6Jss=.a8a82f5a-6892-4d30-b53b-45f39632b19c@github.com> On Mon, 16 May 2022 17:40:41 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well. >> >> Thanks, >> Jorn >> >> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > BootstrapMethodError -> ExceptionInInitializerError src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 967: > 965: > 966: // unaligned constants > 967: public final static ValueLayout.OfBoolean JAVA_BOOLEAN_UNALIGNED = JAVA_BOOLEAN; as far as i understand, those constants are accessed from the bytecode, they should be in their own class to cleanly separate the specializer part and the runtime part. ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From forax at openjdk.java.net Tue May 17 06:16:54 2022 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Tue, 17 May 2022 06:16:54 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: References: Message-ID: On Mon, 16 May 2022 17:40:41 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well. >> >> Thanks, >> Jorn >> >> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > BootstrapMethodError -> ExceptionInInitializerError src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 943: > 941: Z, B, S, C, I, J, F, D, L; > 942: > 943: static BasicType of(Class cls) { This seems a duplication of ASM Type class for no good reason, Type.getOpcode(ILOAD) or Type.getOpcode(IRETURN) gives you the proper variant opcode ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From dholmes at openjdk.java.net Tue May 17 06:33:59 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 17 May 2022 06:33:59 GMT Subject: RFR: 8286262: Windows: Cleanup deprecation warning suppression In-Reply-To: References: Message-ID: On Sun, 15 May 2022 20:50:25 GMT, Kim Barrett wrote: > Please review this cleanup of deprecation warning suppression when building > for Windows. > > This change consists of several parts. > > (1) Remove the global deprecation warning suppression when building HotSpot > for Windows. > > (2) Add macro definitions requesting suppression of selected sets of > deprecation warnings when building HotSpot for Windows. > > (3) Remove unnecessary forwarding macros for various POSIX functions in > globalDefinitions_visCPP.hpp. These were provided to avoid deprecation > warnings (that were previously also being suppressed by the global request). > They are now covered by the new macros provided by change (2) above. > > An alternative to item (3) is to not define _CRT_NONSTDC_NO_DEPRECATE (in item > (2)) and either retain the forwarding macros or define os:: wrapper functions > for all of the affected functions. We might eventually do the latter because > of other reasons for avoiding some of these functions, but the approach being > taken here is simpler. > > For documentation of _CRT_NONSTDC_NO_DEPRECATE, see: > https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility > https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4996 > > Similarly for _CRT_SECURE_NO_WARNINGS. > > Perhaps similarly for _WINSOCK_DEPRECATED_NO_WARNINGS (though I didn't find > any documentation for the latter). But it might be better to not supress the > warnings and instead use the alternatives (JDK-8286781). > > Testing: > mach5 tier1 Sorry Kim I'm having trouble seeing what change corresponds to (1) ?? Also the PR talks only about hotspot, but you're changing the JDK flags as well. ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/8718 From jbachorik at openjdk.java.net Tue May 17 07:52:31 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 17 May 2022 07:52:31 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v10] In-Reply-To: References: Message-ID: <_XPbmmj0IKyltlA6zfsgfXw0zOg3FGAwK_4_5jQMvEo=.af18c47a-8202-49b5-9118-0d1cc510c807@github.com> > A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. > > Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. > >
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. > However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > >

> > _Note: This is a followup PR for #8061_ Jaroslav Bachorik has updated the pull request incrementally with two additional commits since the last revision: - Remove extra new line - Fix ASGCTMark safety issues ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8549/files - new: https://git.openjdk.java.net/jdk/pull/8549/files/546dc819..356462a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=08-09 Stats: 19 lines in 3 files changed: 8 ins; 6 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8549.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8549/head:pull/8549 PR: https://git.openjdk.java.net/jdk/pull/8549 From jbhateja at openjdk.java.net Tue May 17 08:11:37 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 17 May 2022 08:11:37 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v5] In-Reply-To: References: Message-ID: > Hi All, > > Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) > > Following is the brief summary of changes:- > > 1) Extends the scope of existing lanewise API for following new vector operations. > - VectorOperations.BIT_COUNT: counts the number of one-bits > - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits > - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits > - VectorOperations.REVERSE: reversing the order of bits > - VectorOperations.REVERSE_BYTES: reversing the order of bytes > - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. > > 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. > - Vector.compress > - Vector.expand > - VectorMask.compress > > 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. > - Vector.fromMemorySegment > - Vector.intoMemorySegment > > 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. > > > Patch has been regressed over AARCH64 and X86 targets different AVX levels. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - 8284960: Review comments resolution. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - 8284960: Correcting a typo. - 8284960: Integrating changes from panama-vector (Add @since 19 tags). - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - 8284960: AARCH64 backend changes. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/5e5500cb...df7eb90e ------------- Changes: https://git.openjdk.java.net/jdk/pull/8425/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=04 Stats: 38068 lines in 254 files changed: 16705 ins; 16921 del; 4442 mod Patch: https://git.openjdk.java.net/jdk/pull/8425.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425 PR: https://git.openjdk.java.net/jdk/pull/8425 From jbachorik at openjdk.java.net Tue May 17 08:16:49 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 17 May 2022 08:16:49 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 05:38:01 GMT, David Holmes wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore the original find_blob behavior regarding dead blobs > > src/hotspot/share/prims/forte.hpp line 53: > >> 51: ASGCTMark() : ASGCTMark(JavaThread::current()) {} >> 52: ~ASGCTMark() { >> 53: JavaThread::current()->set_in_asgct(false); > > You can't call `JavaThread::current()` in any of this code as it is not safe from a signal handling context. (There is an existing use in ASGCT that is also unsafe.) I suggest not having the no-arg constructor and require the current JavaThread, or null, to be passed in (having already been safely obtained by the caller). You can then assert using `Thread::current_or_null_safe()`. > > Personally I find the ASGCTMark complete overkill for this situation as there is only ever going to be a single use - sorry @tstuefe - it is just complicating things IMO. Ok, I fixed the `ASGCTMark` to be safe to use from a signal handler. I have no strong opinion about whether we should keep it or not - it makes the code in `forte.cpp` slightly more resilient in case of further modifications for the price of more complexity introduced by the mark class ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From mcimadamore at openjdk.java.net Tue May 17 08:31:03 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 17 May 2022 08:31:03 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v21] In-Reply-To: <-H-hj0CmArcV48YOFCPUC1yIZXJxZ41p9PGBP-E_Vc0=.dad63c91-0e01-4124-9b44-467134a26b75@github.com> References: <-H-hj0CmArcV48YOFCPUC1yIZXJxZ41p9PGBP-E_Vc0=.dad63c91-0e01-4124-9b44-467134a26b75@github.com> Message-ID: On Mon, 16 May 2022 16:15:49 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. >> >> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. >> >> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: >> >> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. >> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. >> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). >> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. >> >> While the patch mostly consists of VM changes, there are also some Java changes to support (2). >> >> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. >> >> Testing: Tier1-4 >> >> Thanks, >> Jorn >> >> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 >> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 >> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 >> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 >> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 >> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a >> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 >> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f >> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Missing ASSERT -> NOT_PRODUCT src/java.base/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java line 66: > 64: private static final boolean USE_SPEC = Boolean.parseBoolean( > 65: GetPropertyAction.privilegedGetProperty("jdk.internal.foreign.ProgrammableInvoker.USE_SPEC", "true")); > 66: private static final boolean USE_INTRINSICS = Boolean.parseBoolean( Do we need to update TestMatrix given that we're removing one dimension in the invokers? ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From shade at openjdk.java.net Tue May 17 08:50:48 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 17 May 2022 08:50:48 GMT Subject: RFR: 8286636: MacroAssembler::post_call_nop should have InstructionMark In-Reply-To: <9FGAXDJlzHK85Pz6nPimWEYlSwxJqWcfMSqAlncSyzc=.a8f06546-1087-477f-90ea-1cdb6f046991@github.com> References: <9FGAXDJlzHK85Pz6nPimWEYlSwxJqWcfMSqAlncSyzc=.a8f06546-1087-477f-90ea-1cdb6f046991@github.com> Message-ID: On Thu, 12 May 2022 11:32:05 GMT, Aleksey Shipilev wrote: > `InstructionMark` checks the instruction boundaries, which is important for relocatable instructions. Everywhere where we do any (?) sort of relocation, we do `InstructionMark`. I found that newly added `MacroAssembler::post_call_nop` does not have it, and thus some new code in x86_32 Loom prototype fails with missing instruction mark / instruction overlapping checks. > > If we add it to `InstructionMark` in AArch64 code, then "overlapping instructions" asserts start to fire, because Loom inserted `post_call_nops` when there was an active instruction mark. x86_64 solves this by [resetting the mark before the nop](https://github.com/openjdk/jdk/blob/40f43c6b1ffc88d55dd3223f5d0259ae73cf0356/src/hotspot/cpu/x86/x86_64.ad#L2084), this patch does the same. > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux AArch64 fastdebug `tier1` I would like a second Reviewer, please. ------------- PR: https://git.openjdk.java.net/jdk/pull/8678 From aph at openjdk.java.net Tue May 17 09:05:49 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 17 May 2022 09:05:49 GMT Subject: Integrated: 8272094: compiler/codecache/TestStressCodeBuffers.java crashes with "failed to allocate space for trampoline" In-Reply-To: References: Message-ID: On Mon, 16 May 2022 15:33:55 GMT, Andrew Haley wrote: > This problem is, I believe, caused by an assertion left in the source code after development. > The fix is simply to remove the assertion. > > It's not at all easy to reproduce this bug, being a very intermittent failure, but in the end I reproduced it by making `-XX:+StressCodeBuffers` much more stressful, like so: > > > diff --git a/src/hotspot/share/asm/codeBuffer.cpp b/src/hotspot/share/asm/codeBuffer.cpp > index ddd946d7542..c74ba21cf63 100644 > --- a/src/hotspot/share/asm/codeBuffer.cpp > +++ b/src/hotspot/share/asm/codeBuffer.cpp > @@ -837,7 +837,8 @@ void CodeBuffer::expand(CodeSection* which_cs, csize_t amount) { > if (StressCodeBuffers && blob() != NULL) { > static int expand_count = 0; > if (expand_count >= 0) expand_count += 1; > - if (expand_count > 100 && is_power_of_2(expand_count)) { > + if (expand_count > 100 && // is_power_of_2(expand_count) > + expand_count % 40 == 0) { > tty->print_cr("StressCodeBuffers: have expanded %d times", expand_count); > // simulate an occasional allocation failure: > free_blob(); This pull request has now been integrated. Changeset: 0948c097 Author: Andrew Haley URL: https://git.openjdk.java.net/jdk/commit/0948c097a855dcc9a8a437b4618d7c1922722eab Stats: 13 lines in 4 files changed: 7 ins; 2 del; 4 mod 8272094: compiler/codecache/TestStressCodeBuffers.java crashes with "failed to allocate space for trampoline" Reviewed-by: shade, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/8730 From stuefe at openjdk.java.net Tue May 17 09:10:49 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 17 May 2022 09:10:49 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 08:13:11 GMT, Jaroslav Bachorik wrote: >> src/hotspot/share/prims/forte.hpp line 53: >> >>> 51: ASGCTMark() : ASGCTMark(JavaThread::current()) {} >>> 52: ~ASGCTMark() { >>> 53: JavaThread::current()->set_in_asgct(false); >> >> You can't call `JavaThread::current()` in any of this code as it is not safe from a signal handling context. (There is an existing use in ASGCT that is also unsafe.) I suggest not having the no-arg constructor and require the current JavaThread, or null, to be passed in (having already been safely obtained by the caller). You can then assert using `Thread::current_or_null_safe()`. >> >> Personally I find the ASGCTMark complete overkill for this situation as there is only ever going to be a single use - sorry @tstuefe - it is just complicating things IMO. > > Ok, I fixed the `ASGCTMark` to be safe to use from a signal handler. > > I have no strong opinion about whether we should keep it or not - it makes the code in `forte.cpp` slightly more resilient in case of further modifications for the price of more complexity introduced by the mark class ?? Hi David, > You can't call `JavaThread::current()` in any of this code as it is not safe from a signal handling context. (There is an existing use in ASGCT that is also unsafe.) I suggest not having the no-arg constructor and require the current JavaThread, or null, to be passed in (having already been safely obtained by the caller). You can then assert using `Thread::current_or_null_safe()`. > > Personally I find the ASGCTMark complete overkill for this situation as there is only ever going to be a single use - sorry @tstuefe - it is just complicating things IMO. No problem, that's why we talk :) To make an argument for this: if you compare the first iterations of this patch to the current one, the current one is a lot simpler. I really dislike funneling arguments through many layers down to a utility function, only to fine control one specific behavioral aspect of that tiny function, and that aspect is only relevant for one outlier use case. I dislike this more than the RAII object. Look at it this way. We have a thread-specific state (we are in AGCT and deep down somewhere we want to do something different depending on that state). We need to pass that information down. The only difference is where we keep the "we are in thread-specific state" info - on the stack as an argument chain, or anchored to TLS. Putting it into arguments is one way, but I find this rather ugly. Now every caller of this function has to care. With the RAII, we have the information as a mark exactly where it matters - in the entrance frame of AGCT - and no outside code needs to care. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From mcimadamore at openjdk.java.net Tue May 17 09:47:40 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 17 May 2022 09:47:40 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: References: Message-ID: <_V3vkhcEtDHkPVK-nFLMiNPP-4zuL6-oh6lktwpFnb8=.bb53c336-e10d-4008-a346-43764e77efcf@github.com> On Mon, 16 May 2022 17:40:41 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well. >> >> Thanks, >> Jorn >> >> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > BootstrapMethodError -> ExceptionInInitializerError src/java.base/share/classes/jdk/internal/foreign/abi/Binding.java line 257: > 255: * the context's allocator is accessed. > 256: */ > 257: public static Context ofSession() { Thanks for fixing this src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 131: > 129: private int[] scopeSlots; > 130: private int curScopeLocalIdx = -1; > 131: private int RETURN_ALLOCATOR_IDX = -1; These are not constants, so it is odd to see the name capitalized src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 291: > 289: emitGetStatic(Binding.Context.class, "DUMMY", BINDING_CONTEXT_DESC); > 290: } else { > 291: emitInvokeStatic(Binding.Context.class, "ofSession", OF_SESSION_DESC); Maybe this is micro-optimization, but I realized that in reality we probably don't need any scope/session if there are no "ToSegment" bindings. src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 336: > 334: > 335: if (callingSequence.forUpcall()) { > 336: // for upcalls, recipes have a result, which we handle here I find this part a bit confusing. The comment speaks about recipes input and outputs, hinting at the fact that downcall bindings have inputs, while upcall bindings have outputs. In reality, if we look at the bindings themselves, they look pretty symmetric: * UNBOX_ADDRESS = pops an Addressable and push a long on the stack * BOX_ADDRESS = pops a long and push a MemoryAddress on the stack That is, in both cases it appears we have an input and an output (and the binding is just the function which maps one into another). I think the input/output asymmetry comes in when we consider the full recipes. In downcalls, for a given argument we will have the following sequence: Binding0, Binding1, ... BindingN-1, VMStore While for upcalls we will have: VMLoad, Binding1, Binding2, ... BindingN So (ignoring return buffer for simplicity), for downcalls, it is obvious that before we can execute Binding0, we need some kind of "input value" (e.g. the value of some local). For upcalls, this is not needed, as the VMLoad binding will basically do that for free. When we finished executing the bindings, again, for downcalls there's nothing to do, as the chain always ends with a VMStore (which stores binding result into some local), while for upcalls we do need to set the output value explicitly. In other words, it seems to me that having VMLoad and VMStore in the chains of bindings to be interpreted/specialized does more harm than good here. These low level bindings make sense for the VM code, as the VM needs to know how to load a value from a register, or how to store a value into a register. But in terms of the specializing Java code, these bindings are immaterial. At the same time, the fact that we have these bindings, and that they are virtualized, makes the code hard to follow, as some preparation happens in `BindingSpecializer::specialize`, while some other preparation happens inside `BindingSpecializer::doBindings`, as part of the virtualized impl of VMLoad/VMStore. And, this virtualized implementation ends up doing similar steps as what the preparation code before/after the binding execution does (e.g. for downcalls/VMStore we call setOutput, while for upcalls/VMLoad we call getInput). All I'm saying here is that, for bindings to work, we _always_ need to call both getInput and setOutput - but it is easy to overlook this when looking at the code, because the getInput/setOutput calls are spread across two different places in the specializing code, perhaps making things more asymmetric than they need to be. (I realize I'm simplifying here, and that some details of the return buffer are not 100% quite as symmetric). ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From mcimadamore at openjdk.java.net Tue May 17 09:47:41 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 17 May 2022 09:47:41 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 05:54:39 GMT, R?mi Forax wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> BootstrapMethodError -> ExceptionInInitializerError > > src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 98: > >> 96: private static final String CLASS_DATA_DESC = methodType(Object.class, MethodHandles.Lookup.class, String.class, Class.class).descriptorString(); >> 97: private static final String RELEASE0_DESC = methodType(void.class).descriptorString(); >> 98: private static final String ACQUIRE0_DESC = methodType(void.class).descriptorString(); > > calling methodType() is quite slow because of the cache of MethodType so maybe those initialization should be done explicitly in a static block to avoid to recompute methodType(long).descriptorString() several times What about using MethodTypeDesc/ClassDesc as building block? ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From mcimadamore at openjdk.java.net Tue May 17 09:47:41 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 17 May 2022 09:47:41 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v2] In-Reply-To: <7VrPuAg8gehM1WFBIRt780PFam3f28f6FBd2jLVRATM=.c6e003c8-93c4-4bb9-a95c-bbcbe916233d@github.com> References: <7VrPuAg8gehM1WFBIRt780PFam3f28f6FBd2jLVRATM=.c6e003c8-93c4-4bb9-a95c-bbcbe916233d@github.com> Message-ID: On Fri, 13 May 2022 13:23:41 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well. >> >> Thanks, >> Jorn >> >> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Use unaligned layout constants when filling in reconstituted structs (was accidentally dropped change) src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequence.java line 109: > 107: * @return the caller method type. > 108: */ > 109: public MethodType callerMethodType() { Would it make sense to either rename these, or to point to the fact that these are equivalent to Linker::downcallType/upcallType ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From jvernee at openjdk.java.net Tue May 17 10:06:05 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 17 May 2022 10:06:05 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v21] In-Reply-To: References: <-H-hj0CmArcV48YOFCPUC1yIZXJxZ41p9PGBP-E_Vc0=.dad63c91-0e01-4124-9b44-467134a26b75@github.com> Message-ID: On Tue, 17 May 2022 08:27:41 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Missing ASSERT -> NOT_PRODUCT > > src/java.base/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java line 66: > >> 64: private static final boolean USE_SPEC = Boolean.parseBoolean( >> 65: GetPropertyAction.privilegedGetProperty("jdk.internal.foreign.ProgrammableInvoker.USE_SPEC", "true")); >> 66: private static final boolean USE_INTRINSICS = Boolean.parseBoolean( > > Do we need to update TestMatrix given that we're removing one dimension in the invokers? Looks like that already happened as part of the main JEP integration. ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Tue May 17 10:11:57 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 17 May 2022 10:11:57 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: <_V3vkhcEtDHkPVK-nFLMiNPP-4zuL6-oh6lktwpFnb8=.bb53c336-e10d-4008-a346-43764e77efcf@github.com> References: <_V3vkhcEtDHkPVK-nFLMiNPP-4zuL6-oh6lktwpFnb8=.bb53c336-e10d-4008-a346-43764e77efcf@github.com> Message-ID: <4HyW0Kv4vN-7wXdlxTzXFer1oLP6e2w_Z3XlxZT5w00=.f066b4a6-e471-43a3-873c-d5d6db9cbb95@github.com> On Tue, 17 May 2022 08:32:54 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> BootstrapMethodError -> ExceptionInInitializerError > > src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 131: > >> 129: private int[] scopeSlots; >> 130: private int curScopeLocalIdx = -1; >> 131: private int RETURN_ALLOCATOR_IDX = -1; > > These are not constants, so it is odd to see the name capitalized Right, habit of writing lambda forms, where name variables are capitalized. ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From jvernee at openjdk.java.net Tue May 17 10:22:57 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 17 May 2022 10:22:57 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v2] In-Reply-To: References: <7VrPuAg8gehM1WFBIRt780PFam3f28f6FBd2jLVRATM=.c6e003c8-93c4-4bb9-a95c-bbcbe916233d@github.com> Message-ID: On Mon, 16 May 2022 12:58:51 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> Use unaligned layout constants when filling in reconstituted structs (was accidentally dropped change) > > src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequence.java line 109: > >> 107: * @return the caller method type. >> 108: */ >> 109: public MethodType callerMethodType() { > > Would it make sense to either rename these, or to point to the fact that these are equivalent to Linker::downcallType/upcallType ? I don't think renaming them to down/upcallType makes sense, since both down/up calls use both the caller and callee method type. There can also be things that make these not equivalent to downcallType/upcallType, such as the SysV need to pass the number of floating point arguments for variadic calls as well: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java#L109-L111 ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From jvernee at openjdk.java.net Tue May 17 10:38:39 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 17 May 2022 10:38:39 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v22] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: ifdef NOT_PRODUCT -> ifndef PRODUCT ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/406f3e83..c3abb732 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=21 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=20-21 Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From shade at openjdk.java.net Tue May 17 10:53:54 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 17 May 2022 10:53:54 GMT Subject: RFR: 8286808: Loom: Simplify generate_cont_thaw by passing thaw_kind directly [v2] In-Reply-To: References: Message-ID: On Mon, 16 May 2022 11:29:06 GMT, Aleksey Shipilev wrote: >> I was staring at this code for x86_32 port, and it seems `exception` implies `return_barrier`. This mostly irks me because we are passing `2` to `Continuation::prepare_thaw` and implicitly coercing it to `bool` during the call. We can instead call with `1` when `return_barrier`. >> >> Further cleanup makes the change more obvious; we can pass `thaw_kind` directly to `generate_cont_thaw`, and thus simplify the code. Unused x86_32 and PPC64 stubs are just deleted without refactoring the args; this is supposed to produce a cleaner merge problem for current porting work. >> >> Additional testing: >> - [x] `java/lang/Thread/virtual` on Linux x86_64 fastdebug >> - [x] `java/lang/Thread/virtual` on Linux AArch64 fastdebug >> - [x] Build Linux x86_32 >> - [x] Build Linux PPC64 > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused generate_cont_thaw stubs too Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8725 From shade at openjdk.java.net Tue May 17 10:53:55 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 17 May 2022 10:53:55 GMT Subject: Integrated: 8286808: Loom: Simplify generate_cont_thaw by passing thaw_kind directly In-Reply-To: References: Message-ID: <3plSypfkO-Q49Kyu0UQ-AKmuFcioO94QOcgh9XvtpKU=.7dec3013-e637-4a84-a831-5652ceb1c90b@github.com> On Mon, 16 May 2022 11:11:45 GMT, Aleksey Shipilev wrote: > I was staring at this code for x86_32 port, and it seems `exception` implies `return_barrier`. This mostly irks me because we are passing `2` to `Continuation::prepare_thaw` and implicitly coercing it to `bool` during the call. We can instead call with `1` when `return_barrier`. > > Further cleanup makes the change more obvious; we can pass `thaw_kind` directly to `generate_cont_thaw`, and thus simplify the code. Unused x86_32 and PPC64 stubs are just deleted without refactoring the args; this is supposed to produce a cleaner merge problem for current porting work. > > Additional testing: > - [x] `java/lang/Thread/virtual` on Linux x86_64 fastdebug > - [x] `java/lang/Thread/virtual` on Linux AArch64 fastdebug > - [x] Build Linux x86_32 > - [x] Build Linux PPC64 This pull request has now been integrated. Changeset: b434b1f2 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/b434b1f23373280bfa38ea1cf8c97e5ef2ce25ab Stats: 45 lines in 5 files changed: 12 ins; 16 del; 17 mod 8286808: Loom: Simplify generate_cont_thaw by passing thaw_kind directly Reviewed-by: rpressler, rehn ------------- PR: https://git.openjdk.java.net/jdk/pull/8725 From jvernee at openjdk.java.net Tue May 17 11:21:49 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 17 May 2022 11:21:49 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 06:13:04 GMT, R?mi Forax wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> BootstrapMethodError -> ExceptionInInitializerError > > src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 943: > >> 941: Z, B, S, C, I, J, F, D, L; >> 942: >> 943: static BasicType of(Class cls) { > > This seems a duplication of ASM Type class for no good reason, Type.getOpcode(ILOAD) or Type.getOpcode(IRETURN) gives you the proper variant opcode Didn't know about that. Neat! ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From jvernee at openjdk.java.net Tue May 17 12:01:44 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 17 May 2022 12:01:44 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: References: Message-ID: <766Q0H0VVoOXTVMM_IB-ZufIxO74PmF77-rFVmzlz3s=.9ffd2e8d-66e2-4f63-8b5d-a3542e3de4dd@github.com> On Tue, 17 May 2022 05:51:58 GMT, R?mi Forax wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> BootstrapMethodError -> ExceptionInInitializerError > > src/java.base/share/classes/jdk/internal/foreign/abi/SoftReferenceCache.java line 42: > >> 40: >> 41: private class Node { >> 42: private SoftReference ref; > > this code looks like a double check locking so ref should be volatile Thanks. I thought the `moniterenter` & `monitorexit` were enough here for visibility. I've read up on this and it looks like `volatile` is needed to correctly order the constructor and apply call (and contents) before the write to the `ref` field. ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From rehn at openjdk.java.net Tue May 17 12:27:11 2022 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 17 May 2022 12:27:11 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v22] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 10:38:39 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. >> >> I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. >> >> This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: >> >> 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. >> 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. >> 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). >> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. >> >> While the patch mostly consists of VM changes, there are also some Java changes to support (2). >> >> The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. >> >> Testing: Tier1-4 >> >> Thanks, >> Jorn >> >> [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 >> [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 >> [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 >> [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 >> [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 >> [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a >> [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 >> [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f >> [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > ifdef NOT_PRODUCT -> ifndef PRODUCT Looks good, thanks. ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7959 From dholmes at openjdk.java.net Tue May 17 12:27:43 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 17 May 2022 12:27:43 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 09:07:26 GMT, Thomas Stuefe wrote: >> Ok, I fixed the `ASGCTMark` to be safe to use from a signal handler. >> >> I have no strong opinion about whether we should keep it or not - it makes the code in `forte.cpp` slightly more resilient in case of further modifications for the price of more complexity introduced by the mark class ?? > > Hi David, > >> You can't call `JavaThread::current()` in any of this code as it is not safe from a signal handling context. (There is an existing use in ASGCT that is also unsafe.) I suggest not having the no-arg constructor and require the current JavaThread, or null, to be passed in (having already been safely obtained by the caller). You can then assert using `Thread::current_or_null_safe()`. >> >> Personally I find the ASGCTMark complete overkill for this situation as there is only ever going to be a single use - sorry @tstuefe - it is just complicating things IMO. > > No problem, that's why we talk :) > > To make an argument for this: if you compare the first iterations of this patch to the current one, the current one is a lot simpler. I really dislike funneling arguments through many layers down to a utility function, only to fine control one specific behavioral aspect of that tiny function, and that aspect is only relevant for one outlier use case. I dislike this more than the RAII object. > > Look at it this way. We have a thread-specific state (we are in AGCT and deep down somewhere we want to do something different depending on that state). We need to pass that information down. The only difference is where we keep the "we are in thread-specific state" info - on the stack as an argument chain, or anchored to TLS. > > Putting it into arguments is one way, but I find this rather ugly. Now every caller of this function has to care. With the RAII, we have the information as a mark exactly where it matters - in the entrance frame of AGCT - and no outside code needs to care. > > Cheers, Thomas But you aren't keeping it on the stack versus TLS you are using a stack object to set the TLS. All we have done in this final form is replace: thread->set_in_asgct(true); thread->set_in_asgct(false); with ASGCTMark mark(thread); but now ASGCTMark has to worry about whether `thread` is NULL, whether it is the current javaThread, when we've already done all that for `thread`. And this is the only place we will ever use ASGCTMark. Now if we had lots of return points in `` then RAII would definitely be better to ensure we can't forget to reset the state. But we don't. So use of RAII adds complexity cost now just in case in the future RAII might be useful. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From ysuenaga at openjdk.java.net Tue May 17 12:41:16 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 12:41:16 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 01:43:25 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert change for java.c , parse_manifest.c , LinuxPackage.c > > src/hotspot/share/classfile/classFileParser.cpp line 5970: > >> 5968: PRAGMA_STRINGOP_OVERFLOW_IGNORED >> 5969: _cp->symbol_at_put(hidden_index, _class_name); >> 5970: PRAGMA_DIAG_POP > > I don't understand these warning suppressions for symbol_at_put (here and elsewhere). I don't see any stringops here. What is the compiler complaining about? (There's no mention of classfile stuff in the review cover message.) Like the others, it is caused by `Array::at_put()`. In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/annotations.hpp:28, from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/instanceKlass.hpp:29, from /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/javaClasses.hpp:30, from /home/ysuenaga/github-forked/jdk/src/hotspot/share/precompiled/precompiled.hpp:35: In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, inlined from 'void ConstantPool::symbol_at_put(int, Symbol*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:362:15, inlined from 'void ClassFileParser::mangle_hidden_class_name(InstanceKlass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/classFileParser.cpp:5966:21: ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From jbachorik at openjdk.java.net Tue May 17 12:45:52 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 17 May 2022 12:45:52 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v11] In-Reply-To: References: Message-ID: > A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. > > Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. > >
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. > However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > >

> > _Note: This is a followup PR for #8061_ Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: Remove ASGCTMark ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8549/files - new: https://git.openjdk.java.net/jdk/pull/8549/files/356462a8..bdd758fb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=09-10 Stats: 25 lines in 2 files changed: 3 ins; 21 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8549.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8549/head:pull/8549 PR: https://git.openjdk.java.net/jdk/pull/8549 From jbachorik at openjdk.java.net Tue May 17 12:45:54 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 17 May 2022 12:45:54 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9] In-Reply-To: References: Message-ID: <04ZPdzZZEw_lJvtvxDZikSEVLbieDOo_ZtW85P9VEL4=.48564ed6-3065-4951-a7f8-d3aa7465da9c@github.com> On Tue, 17 May 2022 12:23:56 GMT, David Holmes wrote: >> Hi David, >> >>> You can't call `JavaThread::current()` in any of this code as it is not safe from a signal handling context. (There is an existing use in ASGCT that is also unsafe.) I suggest not having the no-arg constructor and require the current JavaThread, or null, to be passed in (having already been safely obtained by the caller). You can then assert using `Thread::current_or_null_safe()`. >>> >>> Personally I find the ASGCTMark complete overkill for this situation as there is only ever going to be a single use - sorry @tstuefe - it is just complicating things IMO. >> >> No problem, that's why we talk :) >> >> To make an argument for this: if you compare the first iterations of this patch to the current one, the current one is a lot simpler. I really dislike funneling arguments through many layers down to a utility function, only to fine control one specific behavioral aspect of that tiny function, and that aspect is only relevant for one outlier use case. I dislike this more than the RAII object. >> >> Look at it this way. We have a thread-specific state (we are in AGCT and deep down somewhere we want to do something different depending on that state). We need to pass that information down. The only difference is where we keep the "we are in thread-specific state" info - on the stack as an argument chain, or anchored to TLS. >> >> Putting it into arguments is one way, but I find this rather ugly. Now every caller of this function has to care. With the RAII, we have the information as a mark exactly where it matters - in the entrance frame of AGCT - and no outside code needs to care. >> >> Cheers, Thomas > > But you aren't keeping it on the stack versus TLS you are using a stack object to set the TLS. All we have done in this final form is replace: > > > thread->set_in_asgct(true); > > thread->set_in_asgct(false); > > with > > > ASGCTMark mark(thread); > > > but now ASGCTMark has to worry about whether `thread` is NULL, whether it is the current javaThread, when we've already done all that for `thread`. > > And this is the only place we will ever use ASGCTMark. Now if we had lots of return points in `` then RAII would definitely be better to ensure we can't forget to reset the state. But we don't. So use of RAII adds complexity cost now just in case in the future RAII might be useful. Fair enough. I removed the RAII and added a comment making explicit the requirement to reset the 'in_asgct' flag on method return. If there ever appear more return points in that method the RAII can be reconsidered. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From ysuenaga at openjdk.java.net Tue May 17 12:46:03 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 12:46:03 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 03:02:55 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert change for java.c , parse_manifest.c , LinuxPackage.c > > src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp line 103: > >> 101: PRAGMA_STRINGOP_OVERFLOW_IGNORED >> 102: *dest = op(bits, *dest); >> 103: PRAGMA_DIAG_POP > > I see no stringop here. I'm still trying to understand what the compiler is complaining about. I guess GCC cannot understand `assert(dest != NULL` immediately preceding it. In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp:33, from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:30, from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:30: In function 'void set_form(jbyte, jbyte*) [with jbyte (* op)(jbyte, jbyte) = traceid_or]', inlined from 'void set(jbyte, jbyte*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:129:23, inlined from 'static void JfrTraceIdBits::store(jbyte, const T*) [with T = Klass]' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:135:6, inlined from 'static void JfrTraceId::tag_as_jdk_jfr_event(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:106:3, inlined from 'static void JdkJfrEvent::tag_as(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:176:35: ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From stuefe at openjdk.java.net Tue May 17 12:55:58 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 17 May 2022 12:55:58 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 12:23:56 GMT, David Holmes wrote: >> Hi David, >> >>> You can't call `JavaThread::current()` in any of this code as it is not safe from a signal handling context. (There is an existing use in ASGCT that is also unsafe.) I suggest not having the no-arg constructor and require the current JavaThread, or null, to be passed in (having already been safely obtained by the caller). You can then assert using `Thread::current_or_null_safe()`. >>> >>> Personally I find the ASGCTMark complete overkill for this situation as there is only ever going to be a single use - sorry @tstuefe - it is just complicating things IMO. >> >> No problem, that's why we talk :) >> >> To make an argument for this: if you compare the first iterations of this patch to the current one, the current one is a lot simpler. I really dislike funneling arguments through many layers down to a utility function, only to fine control one specific behavioral aspect of that tiny function, and that aspect is only relevant for one outlier use case. I dislike this more than the RAII object. >> >> Look at it this way. We have a thread-specific state (we are in AGCT and deep down somewhere we want to do something different depending on that state). We need to pass that information down. The only difference is where we keep the "we are in thread-specific state" info - on the stack as an argument chain, or anchored to TLS. >> >> Putting it into arguments is one way, but I find this rather ugly. Now every caller of this function has to care. With the RAII, we have the information as a mark exactly where it matters - in the entrance frame of AGCT - and no outside code needs to care. >> >> Cheers, Thomas > > But you aren't keeping it on the stack versus TLS you are using a stack object to set the TLS. All we have done in this final form is replace: > > > thread->set_in_asgct(true); > > thread->set_in_asgct(false); > > with > > > ASGCTMark mark(thread); > > > but now ASGCTMark has to worry about whether `thread` is NULL, whether it is the current javaThread, when we've already done all that for `thread`. > > And this is the only place we will ever use ASGCTMark. Now if we had lots of return points in `` then RAII would definitely be better to ensure we can't forget to reset the state. But we don't. So use of RAII adds complexity cost now just in case in the future RAII might be useful. @dholmes-ora Oh, you are only objecting to the RAII mark, not to the fact that we store the state in Thread? Ok, sure. In my view, a mark prevents the "on" state from escaping the frame, e.g. if stray return calls sneak in with future changes. But I don't have strong emotions here. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From duke at openjdk.java.net Tue May 17 12:56:00 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Tue, 17 May 2022 12:56:00 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 12:50:22 GMT, Thomas Stuefe wrote: >> But you aren't keeping it on the stack versus TLS you are using a stack object to set the TLS. All we have done in this final form is replace: >> >> >> thread->set_in_asgct(true); >> >> thread->set_in_asgct(false); >> >> with >> >> >> ASGCTMark mark(thread); >> >> >> but now ASGCTMark has to worry about whether `thread` is NULL, whether it is the current javaThread, when we've already done all that for `thread`. >> >> And this is the only place we will ever use ASGCTMark. Now if we had lots of return points in `` then RAII would definitely be better to ensure we can't forget to reset the state. But we don't. So use of RAII adds complexity cost now just in case in the future RAII might be useful. > > @dholmes-ora Oh, you are only objecting to the RAII mark, not to the fact that we store the state in Thread? Ok, sure. In my view, a mark prevents the "on" state from escaping the frame, e.g. if stray return calls sneak in with future changes. But I don't have strong emotions here. It would be interesting to see if it this ASGCT flag is useful in JFR, i.e. if JFR suffers potentially from the same problem. There would then be two additional places for setting this flag. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From duke at openjdk.java.net Tue May 17 13:04:55 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Tue, 17 May 2022 13:04:55 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v11] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 12:45:52 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. >> >> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. >> >>

>> >> _Note: This is a followup PR for #8061_ > > Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: > > Remove ASGCTMark src/hotspot/share/prims/forte.cpp line 594: > 592: } > 593: > 594: // !important! make sure all return points will reset the IN_ASGCT flag to 'false' Please change it to something like "// !important! make sure all to call set_in_asgct(false) before every return" as this is clearer in the context of the forte.cpp and omits mentioning the encapsulated state. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From ysuenaga at openjdk.java.net Tue May 17 13:15:24 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 13:15:24 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v6] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Add assert to check the range of BasicType - Merge remote-tracking branch 'upstream/master' into HEAD - Revert change for java.c , parse_manifest.c , LinuxPackage.c - Calculate char offset before realloc() - Use return value from JLI_Snprintf - Avoid pragma error in before GCC 12 - 8286562: GCC 12 reports some compiler warnings ------------- Changes: https://git.openjdk.java.net/jdk/pull/8646/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=05 Stats: 56 lines in 11 files changed: 46 ins; 1 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Tue May 17 13:24:50 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 13:24:50 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: <63OHghBxNm4xJxaud2ThDD4e3TN_ENSU4Yeh2wZcqR4=.0bcbd897-c9a3-4e48-9416-47deb17c777e@github.com> On Tue, 17 May 2022 03:14:05 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert change for java.c , parse_manifest.c , LinuxPackage.c > > src/hotspot/share/classfile/bytecodeAssembler.cpp line 95: > >> 93: ShouldNotReachHere(); >> 94: } >> 95: PRAGMA_DIAG_POP > > One of these is another of the symbol_at_put cases that I don't understand. Are there other cases in the switch that warn? And if so, which ones and how? There are no details of this one in the PR cover description. Most of switch cases are warned. Please see [logs](https://github.com/openjdk/jdk/files/8708578/hotspot_variant-server_libjvm_objs_bytecodeAssembler.o.log) ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Tue May 17 13:32:42 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 13:32:42 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v7] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: revert changes for memnode.cpp and type.cpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/73c306d7..88cbf46d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=05-06 Stats: 7 lines in 2 files changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Tue May 17 13:32:43 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 13:32:43 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 04:52:44 GMT, Kim Barrett wrote: >> src/hotspot/share/opto/memnode.cpp line 1413: >> >>> 1411: bt == T_BYTE || bt == T_SHORT || >>> 1412: bt == T_INT || bt == T_LONG, "wrong type = %s", type2name(bt)); >>> 1413: PRAGMA_DIAG_POP >> >> The problem here is the definition of type2name, which returns NULL for an unknown BasicType. It would probably be better if it returned a recognizable string for that situation, eliminating this warning at it's source. > > While looking at type2name, I noticed the comment for the immediately preceding type2name_tab is wrong. The warning has gone in new commit, and I fixed the comment for `type2name_tab` in it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Tue May 17 13:32:45 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 17 May 2022 13:32:45 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: <-VtXM4fP_wQp_OWiDuU5FmEvFfDK8Y6_lJ7xHI2doYM=.0a7e6002-9b6a-4bdd-b508-7510fe82230c@github.com> On Tue, 17 May 2022 03:06:49 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert change for java.c , parse_manifest.c , LinuxPackage.c > > src/hotspot/share/opto/type.cpp line 4300: > >> 4298: PRAGMA_FORMAT_OVERFLOW_IGNORED >> 4299: fatal("not an element type: %s", type2name(etype)); >> 4300: PRAGMA_DIAG_POP > > Another occurrence of type2name returning NULL for unknown BasicType. The warning has gone in new commit due to change of `type2name`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From jbachorik at openjdk.java.net Tue May 17 13:53:36 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 17 May 2022 13:53:36 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v12] In-Reply-To: References: Message-ID: > A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. > > Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. > >
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. > However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > >

> > _Note: This is a followup PR for #8061_ Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: Change comment wording ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8549/files - new: https://git.openjdk.java.net/jdk/pull/8549/files/bdd758fb..ce5924d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8549.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8549/head:pull/8549 PR: https://git.openjdk.java.net/jdk/pull/8549 From jbachorik at openjdk.java.net Tue May 17 13:53:36 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 17 May 2022 13:53:36 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v11] In-Reply-To: References: Message-ID: <5-T9t-DGHtnBKJdhr1oq2nNPTuWi0jwa0ZrTwmtlqKE=.1296aa86-fef9-4811-80e0-3b03f6210ea4@github.com> On Tue, 17 May 2022 13:01:36 GMT, Johannes Bechberger wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove ASGCTMark > > src/hotspot/share/prims/forte.cpp line 594: > >> 592: } >> 593: >> 594: // !important! make sure all return points will reset the IN_ASGCT flag to 'false' > > Please change it to something like "// !important! make sure all to call set_in_asgct(false) before every return" as this is clearer in the context of the forte.cpp and omits mentioning the encapsulated state. ?? I have modified the comment wording ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From duke at openjdk.java.net Tue May 17 14:20:58 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Tue, 17 May 2022 14:20:58 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v11] In-Reply-To: <5-T9t-DGHtnBKJdhr1oq2nNPTuWi0jwa0ZrTwmtlqKE=.1296aa86-fef9-4811-80e0-3b03f6210ea4@github.com> References: <5-T9t-DGHtnBKJdhr1oq2nNPTuWi0jwa0ZrTwmtlqKE=.1296aa86-fef9-4811-80e0-3b03f6210ea4@github.com> Message-ID: On Tue, 17 May 2022 13:49:25 GMT, Jaroslav Bachorik wrote: >> src/hotspot/share/prims/forte.cpp line 594: >> >>> 592: } >>> 593: >>> 594: // !important! make sure all return points will reset the IN_ASGCT flag to 'false' >> >> Please change it to something like "// !important! make sure all to call set_in_asgct(false) before every return" as this is clearer in the context of the forte.cpp and omits mentioning the encapsulated state. > > ?? > I have modified the comment wording There is an "all" to much in the new version, I forgot to remove it in my suggestion ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From forax at openjdk.java.net Tue May 17 14:33:50 2022 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Tue, 17 May 2022 14:33:50 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 08:16:32 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 98: >> >>> 96: private static final String CLASS_DATA_DESC = methodType(Object.class, MethodHandles.Lookup.class, String.class, Class.class).descriptorString(); >>> 97: private static final String RELEASE0_DESC = methodType(void.class).descriptorString(); >>> 98: private static final String ACQUIRE0_DESC = methodType(void.class).descriptorString(); >> >> calling methodType() is quite slow because of the cache of MethodType so maybe those initialization should be done explicitly in a static block to avoid to recompute methodType(long).descriptorString() several times > > What about using MethodTypeDesc/ClassDesc as building block? yes, it should be less expensive, the ClassDesc still need to be constructed from Class to allow refactoring. ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From forax at openjdk.java.net Tue May 17 14:33:52 2022 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Tue, 17 May 2022 14:33:52 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: <766Q0H0VVoOXTVMM_IB-ZufIxO74PmF77-rFVmzlz3s=.9ffd2e8d-66e2-4f63-8b5d-a3542e3de4dd@github.com> References: <766Q0H0VVoOXTVMM_IB-ZufIxO74PmF77-rFVmzlz3s=.9ffd2e8d-66e2-4f63-8b5d-a3542e3de4dd@github.com> Message-ID: On Tue, 17 May 2022 11:57:01 GMT, Jorn Vernee wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/SoftReferenceCache.java line 42: >> >>> 40: >>> 41: private class Node { >>> 42: private SoftReference ref; >> >> this code looks like a double check locking so ref should be volatile > > Thanks. I thought the `moniterenter` & `monitorexit` were enough here for visibility. I've read up on this and it looks like `volatile` is needed to correctly order the constructor and apply call (and contents) before the write to the `ref` field. yes, otherwise another thread than the one inside the `monitorenter`/`monitorexit` that is initializing the object can see the object half initialized. ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From jbachorik at openjdk.java.net Tue May 17 14:43:00 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 17 May 2022 14:43:00 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 12:52:30 GMT, Johannes Bechberger wrote: >> @dholmes-ora Oh, you are only objecting to the RAII mark, not to the fact that we store the state in Thread? Ok, sure. In my view, a mark prevents the "on" state from escaping the frame, e.g. if stray return calls sneak in with future changes. But I don't have strong emotions here. > > It would be interesting to see if it this ASGCT flag is useful in JFR, i.e. if JFR suffers potentially from the same problem. There would then be two additional places for setting this flag. AFAIK, currently JFR is 'wrapping' the code in a crash-handler. We can take a look at reusing this approach there in some follow-up PR but for now I would really prefer getting this one merged without attaching any more bells&whistles. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From duke at openjdk.java.net Tue May 17 14:58:53 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Tue, 17 May 2022 14:58:53 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 12:23:56 GMT, David Holmes wrote: >> Hi David, >> >>> You can't call `JavaThread::current()` in any of this code as it is not safe from a signal handling context. (There is an existing use in ASGCT that is also unsafe.) I suggest not having the no-arg constructor and require the current JavaThread, or null, to be passed in (having already been safely obtained by the caller). You can then assert using `Thread::current_or_null_safe()`. >>> >>> Personally I find the ASGCTMark complete overkill for this situation as there is only ever going to be a single use - sorry @tstuefe - it is just complicating things IMO. >> >> No problem, that's why we talk :) >> >> To make an argument for this: if you compare the first iterations of this patch to the current one, the current one is a lot simpler. I really dislike funneling arguments through many layers down to a utility function, only to fine control one specific behavioral aspect of that tiny function, and that aspect is only relevant for one outlier use case. I dislike this more than the RAII object. >> >> Look at it this way. We have a thread-specific state (we are in AGCT and deep down somewhere we want to do something different depending on that state). We need to pass that information down. The only difference is where we keep the "we are in thread-specific state" info - on the stack as an argument chain, or anchored to TLS. >> >> Putting it into arguments is one way, but I find this rather ugly. Now every caller of this function has to care. With the RAII, we have the information as a mark exactly where it matters - in the entrance frame of AGCT - and no outside code needs to care. >> >> Cheers, Thomas > > But you aren't keeping it on the stack versus TLS you are using a stack object to set the TLS. All we have done in this final form is replace: > > > thread->set_in_asgct(true); > > thread->set_in_asgct(false); > > with > > > ASGCTMark mark(thread); > > > but now ASGCTMark has to worry about whether `thread` is NULL, whether it is the current javaThread, when we've already done all that for `thread`. > > And this is the only place we will ever use ASGCTMark. Now if we had lots of return points in `` then RAII would definitely be better to ensure we can't forget to reset the state. But we don't. So use of RAII adds complexity cost now just in case in the future RAII might be useful. But the crash-handler does not prevent that `guarantee` aborts the VM, as we discussed already in my related PR. My comment was more a suggestion and related to "And this is the only place we will ever use ASGCTMark" by @dholmes-ora . I agree with you that changing JFR should be done in another PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From stuefe at openjdk.java.net Tue May 17 14:58:54 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 17 May 2022 14:58:54 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 14:54:23 GMT, Johannes Bechberger wrote: >> But you aren't keeping it on the stack versus TLS you are using a stack object to set the TLS. All we have done in this final form is replace: >> >> >> thread->set_in_asgct(true); >> >> thread->set_in_asgct(false); >> >> with >> >> >> ASGCTMark mark(thread); >> >> >> but now ASGCTMark has to worry about whether `thread` is NULL, whether it is the current javaThread, when we've already done all that for `thread`. >> >> And this is the only place we will ever use ASGCTMark. Now if we had lots of return points in `` then RAII would definitely be better to ensure we can't forget to reset the state. But we don't. So use of RAII adds complexity cost now just in case in the future RAII might be useful. > > But the crash-handler does not prevent that `guarantee` aborts the VM, as we discussed already in my related PR. My comment was more a suggestion and related to "And this is the only place we will ever use ASGCTMark" by @dholmes-ora . I agree with you that changing JFR should be done in another PR. > AFAIK, currently JFR is 'wrapping' the code in a crash-handler. We can take a look at reusing this approach there in some follow-up PR but for now I would really prefer getting this one merged without attaching any more bells&whistles. @jbachorik No, please don't do that. That approach is very unsafe and should be used with extreme care. I would actually prefer for it to get removed completely, not to be reused. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From jvernee at openjdk.java.net Tue May 17 15:26:08 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 17 May 2022 15:26:08 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: References: Message-ID: <4qq76p-B4KhP--Kkk7mgjLMQFyEacYv5GfqqCGCk2KA=.62383464-9935-430d-bb5a-0b8ffaac30dc@github.com> On Tue, 17 May 2022 14:28:11 GMT, R?mi Forax wrote: >> What about using MethodTypeDesc/ClassDesc as building block? > > yes, it should be less expensive, the ClassDesc still need to be constructed from Class to allow refactoring. Can't wait for constant folding :) I'll pull the `methodType(void.class).descriptorString()` into a separate constant, and reuse that. I don't think it's worth it to spend too much time here at this point though, since this code is only executed once. ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From duke at openjdk.java.net Tue May 17 15:26:58 2022 From: duke at openjdk.java.net (Johannes Bechberger) Date: Tue, 17 May 2022 15:26:58 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 14:55:56 GMT, Thomas Stuefe wrote: >> But the crash-handler does not prevent that `guarantee` aborts the VM, as we discussed already in my related PR. My comment was more a suggestion and related to "And this is the only place we will ever use ASGCTMark" by @dholmes-ora . I agree with you that changing JFR should be done in another PR. > >> AFAIK, currently JFR is 'wrapping' the code in a crash-handler. We can take a look at reusing this approach there in some follow-up PR but for now I would really prefer getting this one merged without attaching any more bells&whistles. > > @jbachorik No, please don't do that. That approach is very unsafe and should be used with extreme care. I would actually prefer for it to get removed completely, not to be reused. I thought that "this approach" referred to the approach of this PR (possibly renaming the flag), as CrashProtection is orthogonal to the issue that this PR solves. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From jbachorik at openjdk.java.net Tue May 17 15:51:11 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 17 May 2022 15:51:11 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9] In-Reply-To: References: Message-ID: <_uTaFAbOYQ7YMhOYF93FWwR41KdviVvFFXKKsTYS3eI=.55ee82a6-c6b0-42f1-b8bd-fd8294788dd8@github.com> On Tue, 17 May 2022 15:23:04 GMT, Johannes Bechberger wrote: > thought that "this approach" referred to the approach of this PR (possibly renaming the flag) ^ this But still, I would prefer to defer any further improvements into a separate PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From jvernee at openjdk.java.net Tue May 17 15:53:05 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 17 May 2022 15:53:05 GMT Subject: RFR: 8283689: Update the foreign linker VM implementation [v23] In-Reply-To: References: Message-ID: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits: - Merge branch 'master' into JEP-19-VM-IMPL2 - ifdef NOT_PRODUCT -> ifndef PRODUCT - Missing ASSERT -> NOT_PRODUCT - Cleanup UL usage - Fix failure with SPEC disabled (accidentally dropped change) - indentation - fix space - Merge branch 'master' into JEP-19-VM-IMPL2 - Undo spurious changes. - Merge branch 'JEP-19-VM-IMPL2' of https://github.com/JornVernee/jdk into JEP-19-VM-IMPL2 - ... and 95 more: https://git.openjdk.java.net/jdk/compare/af07919e...c3c1421b ------------- Changes: https://git.openjdk.java.net/jdk/pull/7959/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7959&range=22 Stats: 6914 lines in 155 files changed: 2577 ins; 3219 del; 1118 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959 From jvernee at openjdk.java.net Tue May 17 16:22:15 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 17 May 2022 16:22:15 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v4] In-Reply-To: References: Message-ID: > Hi, > > This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well. > > Thanks, > Jorn > > Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux. Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'pr/7959' into JEP-19-ASM - BootstrapMethodError -> ExceptionInInitializerError - Use unaligned layout constants when filling in reconstituted structs (was accidentally dropped change) - Fix LinkUpcall benchmark - 8286306: Upcall wrapper class sharing Reviewed-by: mcimadamore - Polish - 8281595: ASM-ify scope acquire/release for down call parameters 8281387: Some downcall shapes show unexpected allocations Co-authored-by: Maurizio Cimadamore Reviewed-by: mcimadamore - 8281228: Preview branch's CLinker.downcallHandle crashes inside asm Reviewed-by: sundar, jvernee - 8278414: Replace binding recipe customization using MH combinators with bytecode spinning Reviewed-by: mcimadamore - 8276648: Downcall stubs are never freed Reviewed-by: mcimadamore ------------- Changes: https://git.openjdk.java.net/jdk/pull/8685/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8685&range=03 Stats: 2182 lines in 24 files changed: 1396 ins; 660 del; 126 mod Patch: https://git.openjdk.java.net/jdk/pull/8685.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8685/head:pull/8685 PR: https://git.openjdk.java.net/jdk/pull/8685 From shade at openjdk.java.net Tue May 17 16:47:23 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 17 May 2022 16:47:23 GMT Subject: RFR: 8286897: Loom: Cleanup x86_64 StubGenerator Message-ID: <1CsFzv8wOJwBF2f7wET15LwMZoY-mX2wKXq5bGibrzM=.cd19bdbf-1a84-4dd0-beb4-a3d60763854e@github.com> During x86_32 porting, I ended up rewriting the copy of x86_64 StubGenerator significantly to make it more streamlined. The original x86_64 StubGenerator should enjoy the similar streamlining, since it would likely to be the template for many other architectures. There should be no behavior changes. The changes themselves should speak for themselves, but here is a brief list: - no need for `assert_asm` macros, instead do the inline checks, like the rest of Hotspot and Loom code - `_masm` and `masm` shadowing can just use whatever is currently defined as `__` - more strong cohesion between `post_call_nop`, its associated PC and its oopmap - consistently use `call_VM_leaf` that only takes the number of arguments, as we are doing argument pushes ourselves anyway; - for many moves, it is easier to use `ptr` flavors (e.g. `testq` -> `testptr`) to ease copy-pasting to other arches; - `generate_cont_thaw` should just do the `enabled()` check and carry the `StubCodeMark`, like other stubs do; - inline comments are reflowed to block-like comments, matching the usual style of stub code; - labels are prefixed with `L_` for clarity (used in some places in Hotspot); - `jfr_prolog` and `jfr_epilog` are used only once and do not carry their weight; - `continuation_*` are documented a bit better; Additional testing: - [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual` - [x] Linux x86_64 fastdebug, `serviceability/jvmti` - [x] Linux x86_64 fastdebug, `runtime/vthread` ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/8755/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8755&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286897 Stats: 251 lines in 3 files changed: 103 ins; 68 del; 80 mod Patch: https://git.openjdk.java.net/jdk/pull/8755.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8755/head:pull/8755 PR: https://git.openjdk.java.net/jdk/pull/8755 From rpressler at openjdk.java.net Tue May 17 17:07:34 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Tue, 17 May 2022 17:07:34 GMT Subject: RFR: 8286897: Loom: Cleanup x86_64 StubGenerator In-Reply-To: <1CsFzv8wOJwBF2f7wET15LwMZoY-mX2wKXq5bGibrzM=.cd19bdbf-1a84-4dd0-beb4-a3d60763854e@github.com> References: <1CsFzv8wOJwBF2f7wET15LwMZoY-mX2wKXq5bGibrzM=.cd19bdbf-1a84-4dd0-beb4-a3d60763854e@github.com> Message-ID: On Tue, 17 May 2022 16:39:55 GMT, Aleksey Shipilev wrote: > During x86_32 porting, I ended up rewriting the copy of x86_64 StubGenerator significantly to make it more streamlined. The original x86_64 StubGenerator should enjoy the similar streamlining, since it would likely to be the template for many other architectures. > > There should be no behavior changes. The changes themselves should speak for themselves, but here is a brief list: > - no need for `assert_asm` macros, instead do the inline checks, like the rest of Hotspot and Loom code > - `_masm` and `masm` shadowing can just use whatever is currently defined as `__` > - more strong cohesion between `post_call_nop`, its associated PC and its oopmap > - consistently use `call_VM_leaf` that only takes the number of arguments, as we are doing argument pushes ourselves anyway; > - for many moves, it is easier to use `ptr` flavors (e.g. `testq` -> `testptr`) to ease copy-pasting to other arches; > - `generate_cont_thaw` should just do the `enabled()` check and carry the `StubCodeMark`, like other stubs do; > - inline comments are reflowed to block-like comments, matching the usual style of stub code; > - labels are prefixed with `L_` for clarity (used in some places in Hotspot); > - `jfr_prolog` and `jfr_epilog` are used only once and do not carry their weight; > - `continuation_*` are documented a bit better; > > Additional testing: > - [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual` > - [x] Linux x86_64 fastdebug, `serviceability/jvmti` > - [x] Linux x86_64 fastdebug, `runtime/vthread` The changes looks fine, but why do you want to remove assert_asm? It's useful even though it's new and not applied to old code. But if there's a good reason to do so, then it should also be removed from the aarch64 port. ------------- PR: https://git.openjdk.java.net/jdk/pull/8755 From shade at openjdk.java.net Tue May 17 17:21:10 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 17 May 2022 17:21:10 GMT Subject: RFR: 8286897: Loom: Cleanup x86_64 StubGenerator [v2] In-Reply-To: <1CsFzv8wOJwBF2f7wET15LwMZoY-mX2wKXq5bGibrzM=.cd19bdbf-1a84-4dd0-beb4-a3d60763854e@github.com> References: <1CsFzv8wOJwBF2f7wET15LwMZoY-mX2wKXq5bGibrzM=.cd19bdbf-1a84-4dd0-beb4-a3d60763854e@github.com> Message-ID: > During x86_32 porting, I ended up rewriting the copy of x86_64 StubGenerator significantly to make it more streamlined. The original x86_64 StubGenerator should enjoy the similar streamlining, since it would likely to be the template for many other architectures. > > There should be no behavior changes. The changes themselves should speak for themselves, but here is a brief list: > - no need for `assert_asm` macros, instead do the inline checks, like the rest of Hotspot and Loom code > - `_masm` and `masm` shadowing can just use whatever is currently defined as `__` > - more strong cohesion between `post_call_nop`, its associated PC and its oopmap > - consistently use `call_VM_leaf` that only takes the number of arguments, as we are doing argument pushes ourselves anyway; > - for many moves, it is easier to use `ptr` flavors (e.g. `testq` -> `testptr`) to ease copy-pasting to other arches; > - `generate_cont_thaw` should just do the `enabled()` check and carry the `StubCodeMark`, like other stubs do; > - inline comments are reflowed to block-like comments, matching the usual style of stub code; > - labels are prefixed with `L_` for clarity (used in some places in Hotspot); > - `jfr_prolog` and `jfr_epilog` are used only once and do not carry their weight; > - `continuation_*` are documented a bit better; > > Additional testing: > - [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual` > - [x] Linux x86_64 fastdebug, `serviceability/jvmti` > - [x] Linux x86_64 fastdebug, `runtime/vthread` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: More changes from x86_32 PR ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8755/files - new: https://git.openjdk.java.net/jdk/pull/8755/files/5fc3759e..b4a29e72 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8755&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8755&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8755.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8755/head:pull/8755 PR: https://git.openjdk.java.net/jdk/pull/8755 From shade at openjdk.java.net Tue May 17 17:21:12 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 17 May 2022 17:21:12 GMT Subject: RFR: 8286897: Loom: Cleanup x86_64 StubGenerator In-Reply-To: References: <1CsFzv8wOJwBF2f7wET15LwMZoY-mX2wKXq5bGibrzM=.cd19bdbf-1a84-4dd0-beb4-a3d60763854e@github.com> Message-ID: On Tue, 17 May 2022 17:04:37 GMT, Ron Pressler wrote: > The changes looks fine, but why do you want to remove assert_asm? It's useful even though it's new and not applied to old code. It is quite fiddly and clunky, TBH. My concern is accidentally putting the wrong inline assembly into macro and producing weird side-effects that behave differently when assertions are enabled. This is a risk every assertion carries, by the assembly carries much greater risk here. I don't even want to start thinking how would a badly matched macro play out. (Also, in x86_32 port, I discovered the definition is under wrong `LP64` block, which ends up with funky linking errors). I can leave `assert_asm` in, but this cleanup had removed the only two uses. > But if there's a good reason to do so, then it should also be removed from the aarch64 port. That would be something to do when cleaning up AArch64 StubGenerator. ------------- PR: https://git.openjdk.java.net/jdk/pull/8755 From duke at openjdk.java.net Tue May 17 17:23:03 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Tue, 17 May 2022 17:23:03 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Mon, 16 May 2022 15:52:22 GMT, olivergillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. @olivergillespie, how did you test your changes? src/hotspot/cpu/x86/vm_version_x86.cpp line 900: > 898: // Don't use AVX-512 on Skylake (or the related Cascade Lake) CPUs unless explicitly > 899: // requested - these instructions can cause performance issues on these processors. > 900: if (use_avx_limit > 2 && is_intel_skylake()) { Maybe `is_intel_skylake` needs to be changed to `is_cpu_model_intel_skylake`? It will make clear that all CPUs based on Skylake model are excluded. ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From jbhateja at openjdk.java.net Tue May 17 17:29:00 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 17 May 2022 17:29:00 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v6] In-Reply-To: References: Message-ID: > Hi All, > > Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) > > Following is the brief summary of changes:- > > 1) Extends the scope of existing lanewise API for following new vector operations. > - VectorOperations.BIT_COUNT: counts the number of one-bits > - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits > - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits > - VectorOperations.REVERSE: reversing the order of bits > - VectorOperations.REVERSE_BYTES: reversing the order of bytes > - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. > > 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. > - Vector.compress > - Vector.expand > - VectorMask.compress > > 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. > - Vector.fromMemorySegment > - Vector.intoMemorySegment > > 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. > > > Patch has been regressed over AARCH64 and X86 targets different AVX levels. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8284960: Adding --enable-preview in vectorAPI benchmarks. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8425/files - new: https://git.openjdk.java.net/jdk/pull/8425/files/df7eb90e..0b7f84bb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=04-05 Stats: 21 lines in 10 files changed: 7 ins; 4 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/8425.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425 PR: https://git.openjdk.java.net/jdk/pull/8425 From duke at openjdk.java.net Tue May 17 17:36:48 2022 From: duke at openjdk.java.net (olivergillespie) Date: Tue, 17 May 2022 17:36:48 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Mon, 16 May 2022 15:52:22 GMT, olivergillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. My testing was simply running the SPECjvm2008 `xml.transform` benchmark before and after as shared in the description. ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From duke at openjdk.java.net Tue May 17 17:36:48 2022 From: duke at openjdk.java.net (olivergillespie) Date: Tue, 17 May 2022 17:36:48 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Tue, 17 May 2022 17:18:01 GMT, Evgeny Astigeevich wrote: >> The current code already does this for 'older' Skylake processors, >> namely those with _stepping < 5. My testing indicates this is a >> problem for later processors in this family too, so I have removed the >> max stepping condition. >> >> The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. >> >> A general description of the overall issue is given at >> https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. >> >> According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, >> stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, >> and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using >> -XX:UseAVX=3, along with a corresponding performance reduction. >> >> I first saw this issue in a real production workload, where the main AVX3 instructions >> being executed were those generated for various flavours of disjoint_arraycopy. >> >> I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. >> >> >> java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ >> --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ >> -jar SPECjvm2008.jar -ikv -ict xml.transform >> >> >> Before the change, or with -XX:UseAVX=3: >> >> >> Valid run! >> Score on xml.transform: 776.00 ops/m >> >> >> After the change, or with -XX:UseAVX=2: >> >> >> Valid run! >> Score on xml.transform: 894.07 ops/m >> >> >> So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively >> affected by this change, but I contend that this is still the right move given the stark >> difference in this benchmark combined with the fact that use of AVX3 instructions can >> affect *all* processes/code on the host due to the downclocking, and the fact that this >> effect is very hard to root-cause, for example CPU profiles look very similar before and >> after since all code is equally slowed. > > src/hotspot/cpu/x86/vm_version_x86.cpp line 900: > >> 898: // Don't use AVX-512 on Skylake (or the related Cascade Lake) CPUs unless explicitly >> 899: // requested - these instructions can cause performance issues on these processors. >> 900: if (use_avx_limit > 2 && is_intel_skylake()) { > > Maybe `is_intel_skylake` needs to be changed to `is_cpu_model_intel_skylake`? It will make clear that all CPUs based on Skylake model are excluded. I agree it's not necessarily a perfect name, but I haven't changed its behaviour so I figured I can avoid making my change any bigger than necessary. The intention of this particular usage is clarified in my comment. It's used in [another place](https://github.com/openjdk/jdk/blob/d77e5680af382f8215b5b1f9cd4754056bccc9e5/src/hotspot/cpu/x86/vm_version_x86.hpp#L1083) too, where it's evidently understood to include Cascade lake since the comment mentions Ice lake + (Cascade lake successor). ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From duke at openjdk.java.net Tue May 17 17:46:41 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Tue, 17 May 2022 17:46:41 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Mon, 16 May 2022 15:52:22 GMT, olivergillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. You need to run gtest and tier1 at least. The PR did not started them automatically. ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From rpressler at openjdk.java.net Tue May 17 17:46:45 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Tue, 17 May 2022 17:46:45 GMT Subject: RFR: 8286897: Loom: Cleanup x86_64 StubGenerator [v2] In-Reply-To: References: <1CsFzv8wOJwBF2f7wET15LwMZoY-mX2wKXq5bGibrzM=.cd19bdbf-1a84-4dd0-beb4-a3d60763854e@github.com> Message-ID: On Tue, 17 May 2022 17:21:10 GMT, Aleksey Shipilev wrote: >> During x86_32 porting, I ended up rewriting the copy of x86_64 StubGenerator significantly to make it more streamlined. The original x86_64 StubGenerator should enjoy the similar streamlining, since it would likely to be the template for many other architectures. >> >> There should be no behavior changes. The changes themselves should speak for themselves, but here is a brief list: >> - no need for `assert_asm` macros, instead do the inline checks, like the rest of Hotspot and Loom code >> - `_masm` and `masm` shadowing can just use whatever is currently defined as `__` >> - more strong cohesion between `post_call_nop`, its associated PC and its oopmap >> - consistently use `call_VM_leaf` that only takes the number of arguments, as we are doing argument pushes ourselves anyway; >> - for many moves, it is easier to use `ptr` flavors (e.g. `testq` -> `testptr`) to ease copy-pasting to other arches; >> - `generate_cont_thaw` should just do the `enabled()` check and carry the `StubCodeMark`, like other stubs do; >> - inline comments are reflowed to block-like comments, matching the usual style of stub code; >> - labels are prefixed with `L_` for clarity (used in some places in Hotspot); >> - `jfr_prolog` and `jfr_epilog` are used only once and do not carry their weight; >> - `continuation_*` are documented a bit better; >> >> Additional testing: >> - [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual` >> - [x] Linux x86_64 fastdebug, `serviceability/jvmti` >> - [x] Linux x86_64 fastdebug, `runtime/vthread` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > More changes from x86_32 PR Marked as reviewed by rpressler (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/8755 From aph at openjdk.java.net Tue May 17 18:16:15 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 17 May 2022 18:16:15 GMT Subject: RFR: 8272791: java -XX:BlockZeroingLowLimit=1 crashes after 8270947 Message-ID: This is an assertion failure caused by setting `BlockZeroingLowLimit` < `wordSize`. I believe there was some confusion when writing this code about whether `BlockZeroingLowLimit` should be in words or bytes, and it makes no sense for it to be less than a single word. If anyone ever tried to use a parameter < 8, it triggers an assertion. This patch does two things. Firstly, it corrects a `guarantee` which erroneously used `zero_words_block_size` rather than `wordSize`. The value of both of these is 8, so it doesn't change anything in the generated code. Secondly, it clips the `BlockZeroingLowLimit` so that it doesn't trigger the assertion. Perhaps it would be better to change the lower limit to 8 instead of this silent correction. There is no backward compatibility issue here, because any attempt to set `BlockZeroingLowLimit` < 8 in the past would have exited the VM with an error, so I don't believe a CSR is warranted if we do change the allowable range. So, which should it be? Change the lower limit of the range of the `BlockZeroingLowLimit` system flag, or allow 1 still to be used and silently fix it? Opinions welcome. ------------- Commit messages: - 8272791: java -XX:BlockZeroingLowLimit=1 crashes after 8270947 Changes: https://git.openjdk.java.net/jdk/pull/8756/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8756&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272791 Stats: 7 lines in 2 files changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8756.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8756/head:pull/8756 PR: https://git.openjdk.java.net/jdk/pull/8756 From kvn at openjdk.java.net Tue May 17 18:25:40 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 17 May 2022 18:25:40 GMT Subject: RFR: 8286897: Loom: Cleanup x86_64 StubGenerator [v2] In-Reply-To: References: <1CsFzv8wOJwBF2f7wET15LwMZoY-mX2wKXq5bGibrzM=.cd19bdbf-1a84-4dd0-beb4-a3d60763854e@github.com> Message-ID: On Tue, 17 May 2022 17:21:10 GMT, Aleksey Shipilev wrote: >> During x86_32 porting, I ended up rewriting the copy of x86_64 StubGenerator significantly to make it more streamlined. The original x86_64 StubGenerator should enjoy the similar streamlining, since it would likely to be the template for many other architectures. >> >> There should be no behavior changes. The changes themselves should speak for themselves, but here is a brief list: >> - no need for `assert_asm` macros, instead do the inline checks, like the rest of Hotspot and Loom code >> - `_masm` and `masm` shadowing can just use whatever is currently defined as `__` >> - more strong cohesion between `post_call_nop`, its associated PC and its oopmap >> - consistently use `call_VM_leaf` that only takes the number of arguments, as we are doing argument pushes ourselves anyway; >> - for many moves, it is easier to use `ptr` flavors (e.g. `testq` -> `testptr`) to ease copy-pasting to other arches; >> - `generate_cont_thaw` should just do the `enabled()` check and carry the `StubCodeMark`, like other stubs do; >> - inline comments are reflowed to block-like comments, matching the usual style of stub code; >> - labels are prefixed with `L_` for clarity (used in some places in Hotspot); >> - `jfr_prolog` and `jfr_epilog` are used only once and do not carry their weight; >> - `continuation_*` are documented a bit better; >> >> Additional testing: >> - [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual` >> - [x] Linux x86_64 fastdebug, `serviceability/jvmti` >> - [x] Linux x86_64 fastdebug, `runtime/vthread` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > More changes from x86_32 PR Nice cleanup. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7455: > 7453: OopMapSet* oop_maps = new OopMapSet(); > 7454: OopMap* map = new OopMap(framesize, 1); > 7455: oop_maps->add_gc_map(the_pc - start, map); Use `frame_complete`. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7460: > 7458: __ movptr(c_rarg0, r15_thread); > 7459: __ movptr(c_rarg1, rsp); > 7460: __ call_VM_leaf(Continuation::freeze_entry(), 2); Was it bug to not set `c_rarg1`? stubGenerator_aarch64.cpp has the same issue. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7666: > 7664: OopMapSet* oop_maps = new OopMapSet(); > 7665: OopMap* map = new OopMap(framesize, 1); // rbp > 7666: oop_maps->add_gc_map(the_pc - start, map); You can use `frame_complete` here too. ------------- PR: https://git.openjdk.java.net/jdk/pull/8755 From kvn at openjdk.java.net Tue May 17 18:29:48 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 17 May 2022 18:29:48 GMT Subject: RFR: 8272791: java -XX:BlockZeroingLowLimit=1 crashes after 8270947 In-Reply-To: References: Message-ID: On Tue, 17 May 2022 18:08:58 GMT, Andrew Haley wrote: > This is an assertion failure caused by setting `BlockZeroingLowLimit` < `wordSize`. > > I believe there was some confusion when writing this code about whether `BlockZeroingLowLimit` should be in words or bytes, and it makes no sense for it to be less than a single word. If anyone ever tried to use a parameter < 8, it triggers an assertion. > > This patch does two things. Firstly, it corrects a `guarantee` which erroneously used `zero_words_block_size` rather than `wordSize`. The value of both of these is 8, so it doesn't change anything in the generated code. Secondly, it clips the `BlockZeroingLowLimit` so that it doesn't trigger the assertion. > > Perhaps it would be better to change the lower limit to 8 instead of this silent correction. There is no backward compatibility issue here, because any attempt to set `BlockZeroingLowLimit` < 8 in the past would have exited the VM with an error, so I don't believe a CSR is warranted if we do change the allowable range. > > So, which should it be? Change the lower limit of the range of the `BlockZeroingLowLimit` system flag, or allow 1 still to be used and silently fix it? Opinions welcome. Change the lower limit of the range of the BlockZeroingLowLimit system flag. Seems RISCV code has the same issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/8756 From duke at openjdk.java.net Tue May 17 18:30:49 2022 From: duke at openjdk.java.net (olivergillespie) Date: Tue, 17 May 2022 18:30:49 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Tue, 17 May 2022 17:43:08 GMT, Evgeny Astigeevich wrote: > You need to run gtest and tier1 at least. The PR did not started them automatically. Thanks, I have now run tier1 and gtest successfully with my change. ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From aph at openjdk.java.net Tue May 17 18:41:36 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 17 May 2022 18:41:36 GMT Subject: RFR: 8272791: java -XX:BlockZeroingLowLimit=1 crashes after 8270947 In-Reply-To: References: Message-ID: On Tue, 17 May 2022 18:26:48 GMT, Vladimir Kozlov wrote: > Change the lower limit of the range of the BlockZeroingLowLimit system flag. Seems RISCV code has the same issue. OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/8756 From kvn at openjdk.java.net Tue May 17 18:53:56 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 17 May 2022 18:53:56 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Mon, 16 May 2022 15:52:22 GMT, olivergillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. Seems reasonable. I have to run testing before approval. ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From zgu at openjdk.java.net Tue May 17 19:10:42 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 17 May 2022 19:10:42 GMT Subject: RFR: 8286814: Shenandoah: RedefineRunningMethods.java test failed with Loom Message-ID: Please review this patch that fixed failed tests. To determine if a barrier is needed for newly allocated `stackChunkOop`, it needs to consider current GC phases, as TAMS and update watermark are specific to corresponding GC phase. Test: - [x] tier1 with `--enable-preview -XX:+UseShenandoahGC` on Linux x86_64 - [x] tier2 with `--enable-preview -XX:+UseShenandoahGC` on Linux x86_64 ------------- Commit messages: - Add comments - v0 Changes: https://git.openjdk.java.net/jdk/pull/8757/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8757&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286814 Stats: 17 lines in 2 files changed: 9 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8757.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8757/head:pull/8757 PR: https://git.openjdk.java.net/jdk/pull/8757 From sviswanathan at openjdk.java.net Tue May 17 21:14:49 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 17 May 2022 21:14:49 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Mon, 16 May 2022 15:52:22 GMT, olivergillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. We restricted this to Skylake only as Cascade Lake has improvements in this regard on the platform. There are AVX512 optimizations in the JVM that are beneficial on Cascade Lake. ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From duke at openjdk.java.net Tue May 17 22:18:40 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Tue, 17 May 2022 22:18:40 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: <_XuazOpynw1Gln1JJBWWUV6kP336atYvUWHBjp5USK4=.c5fc0436-c2a3-400b-ae99-c1fe35980eb9@github.com> On Mon, 16 May 2022 15:52:22 GMT, olivergillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. Hi Sandhya, Oli's main point is: > use of AVX3 instructions can > affect all processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. Oli mentioned `disjoint_arraycopy`. I found https://github.com/openjdk/jdk/pull/6512. The PR mentions 'old' and 'latest' CPUs but it does not specify them. Was the PR tested on Cascade Lake? Also SPECjvm2008 was mentioned in the PR but without details. Microbenchmarks show single-thread improvements. Do you have any improvements in multi-threaded benchmarks, like SPECjbb, DaCapo or Renaissance? Maybe `disjoint_arraycopy` should not use AVX3 on Cascade Lake? Or `AVX3Threshold` should not be set to 0 for Cascade Lake? ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From sviswanathan at openjdk.java.net Tue May 17 23:13:50 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 17 May 2022 23:13:50 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <_XuazOpynw1Gln1JJBWWUV6kP336atYvUWHBjp5USK4=.c5fc0436-c2a3-400b-ae99-c1fe35980eb9@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> <_XuazOpynw1Gln1JJBWWUV6kP336atYvUWHBjp5USK4=.c5fc0436-c2a3-400b-ae99-c1fe35980eb9@github.com> Message-ID: On Tue, 17 May 2022 22:15:19 GMT, Evgeny Astigeevich wrote: >> The current code already does this for 'older' Skylake processors, >> namely those with _stepping < 5. My testing indicates this is a >> problem for later processors in this family too, so I have removed the >> max stepping condition. >> >> The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. >> >> A general description of the overall issue is given at >> https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. >> >> According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, >> stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, >> and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using >> -XX:UseAVX=3, along with a corresponding performance reduction. >> >> I first saw this issue in a real production workload, where the main AVX3 instructions >> being executed were those generated for various flavours of disjoint_arraycopy. >> >> I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. >> >> >> java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ >> --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ >> -jar SPECjvm2008.jar -ikv -ict xml.transform >> >> >> Before the change, or with -XX:UseAVX=3: >> >> >> Valid run! >> Score on xml.transform: 776.00 ops/m >> >> >> After the change, or with -XX:UseAVX=2: >> >> >> Valid run! >> Score on xml.transform: 894.07 ops/m >> >> >> So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively >> affected by this change, but I contend that this is still the right move given the stark >> difference in this benchmark combined with the fact that use of AVX3 instructions can >> affect *all* processes/code on the host due to the downclocking, and the fact that this >> effect is very hard to root-cause, for example CPU profiles look very similar before and >> after since all code is equally slowed. > > Hi Sandhya, > Oli's main point is: >> use of AVX3 instructions can >> affect all processes/code on the host due to the downclocking, and the fact that this >> effect is very hard to root-cause, for example CPU profiles look very similar before and >> after since all code is equally slowed. > > Oli mentioned `disjoint_arraycopy`. I found https://github.com/openjdk/jdk/pull/6512. The PR mentions 'old' and 'latest' CPUs but it does not specify them. Was the PR tested on Cascade Lake? Also SPECjvm2008 was mentioned in the PR but without details. Microbenchmarks show single-thread improvements. Do you have any improvements in multi-threaded benchmarks, like SPECjbb, DaCapo or Renaissance? Maybe `disjoint_arraycopy` should not use AVX3 on Cascade Lake? Or `AVX3Threshold` should not be set to 0 for Cascade Lake? @eastig AVX3Threshold is not set to 0 for CascadeLake. ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From iklam at openjdk.java.net Tue May 17 23:47:15 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 17 May 2022 23:47:15 GMT Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate Message-ID: I added two new template functions to reduce the boilerplate code when walking the entries in a ResourceHashtable - `template void ResourceHashtable::iterate(F f)` - `template void ResourceHashtable::iterate_all(F f)` I also modified a couple of places in systemDictionaryShared.cpp to use the new functionality. Testing with tiers 1-4. ------------- Commit messages: - 8276789: Support C++ lambda in ResourceHashtable::iterate Changes: https://git.openjdk.java.net/jdk/pull/8761/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8761&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276789 Stats: 106 lines in 4 files changed: 46 ins; 36 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/8761.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8761/head:pull/8761 PR: https://git.openjdk.java.net/jdk/pull/8761 From iklam at openjdk.java.net Tue May 17 23:47:16 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 17 May 2022 23:47:16 GMT Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate In-Reply-To: References: Message-ID: On Tue, 17 May 2022 23:37:52 GMT, Ioi Lam wrote: > I added two new template functions to reduce the boilerplate code when walking the entries in a ResourceHashtable > > - `template void ResourceHashtable::iterate(F f)` > - `template void ResourceHashtable::iterate_all(F f)` > > I also modified a couple of places in systemDictionaryShared.cpp to use the new functionality. > > Testing with tiers 1-4. GCC 10.3.0 generates identical code for the following before and after this PR. So there should be no impact with existing code that uses the old style iterator. class MyIter : StackObj { public: int _count; MyIter() : _count(0) {} bool do_entry(InstanceKlass* k, DumpTimeClassInfo& info) { _count ++; return true; // keep on iterating } }; int doit(DumpTimeSharedClassTable* dumptime_table) { MyIter myiter; dumptime_table->iterate(&myiter); return myiter._count; } ------------- PR: https://git.openjdk.java.net/jdk/pull/8761 From kvn at openjdk.java.net Wed May 18 00:09:56 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 18 May 2022 00:09:56 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: <4yWJDTM60waqLfTFh4VHyVUE1OcTxquv79RUNouy530=.b8ce6bdc-72f1-467d-ad39-b5974f23e4e3@github.com> On Mon, 16 May 2022 15:52:22 GMT, olivergillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. I ran very briefly specjvm2008 on CascadeLake and I see big regression in crypto.aes with AVX2. ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From kvn at openjdk.java.net Wed May 18 00:12:48 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 18 May 2022 00:12:48 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Tue, 17 May 2022 18:27:00 GMT, olivergillespie wrote: >> You need to run gtest and tier1 at least. The PR did not started them automatically. > >> You need to run gtest and tier1 at least. The PR did not started them automatically. > > Thanks, I have now run tier1 and gtest successfully with my change. @olivergillespie, do you have results for other SPECjvm2008 benchmarks? ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From dholmes at openjdk.java.net Wed May 18 01:50:03 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 18 May 2022 01:50:03 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v12] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 13:53:36 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. >> >> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. >> >>

>> >> _Note: This is a followup PR for #8061_ > > Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: > > Change comment wording One minor unneeded change to revert but otherwise this is good to go. Lets ship these and leave other issues for other PRs. Thanks. src/hotspot/share/prims/forte.hpp line 29: > 27: > 28: #include "memory/allocation.hpp" > 29: No longer needed. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8549 From dholmes at openjdk.java.net Wed May 18 01:50:05 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 18 May 2022 01:50:05 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v9] In-Reply-To: <_uTaFAbOYQ7YMhOYF93FWwR41KdviVvFFXKKsTYS3eI=.55ee82a6-c6b0-42f1-b8bd-fd8294788dd8@github.com> References: <_uTaFAbOYQ7YMhOYF93FWwR41KdviVvFFXKKsTYS3eI=.55ee82a6-c6b0-42f1-b8bd-fd8294788dd8@github.com> Message-ID: On Tue, 17 May 2022 15:48:47 GMT, Jaroslav Bachorik wrote: >> I thought that "this approach" referred to the approach of this PR (possibly renaming the flag), as CrashProtection is orthogonal to the issue that this PR solves. > >> thought that "this approach" referred to the approach of this PR (possibly renaming the flag) > > ^ this > > But still, I would prefer to defer any further improvements into a separate PR. > It would be interesting to see if it this ASGCT flag is useful in JFR @parttimenerd , if you mean whether JFR might also benefit from a flag that indicates whether a thread is executing in some "sensitive" location, then perhaps. But there is only one ASGCT and AFAIK JFR does not use it. But that is a discussion for another place. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From dholmes at openjdk.java.net Wed May 18 02:10:00 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 18 May 2022 02:10:00 GMT Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate In-Reply-To: References: Message-ID: <-wZ6XE3AIJ1vE7_vmF8MPjMFv-FLGu7xhLeCvbUNnCA=.e16d413e-1ce8-47e9-97b9-c9bd3c74947c@github.com> On Tue, 17 May 2022 23:37:52 GMT, Ioi Lam wrote: > I added two new template functions to reduce the boilerplate code when walking the entries in a ResourceHashtable > > - `template void ResourceHashtable::iterate(F f)` > - `template void ResourceHashtable::iterate_all(F f)` > > I also modified a couple of places in systemDictionaryShared.cpp to use the new functionality. > > Testing with tiers 1-4. src/hotspot/share/cds/dumpTimeClassInfo.inline.hpp line 43: > 41: template > 42: void DumpTimeSharedClassTable::iterate(F f) const { > 43: auto g = [=] (InstanceKlass* k, DumpTimeClassInfo& info) { The style guide states we should try to only use `[&]` for capture by reference. ------------- PR: https://git.openjdk.java.net/jdk/pull/8761 From iklam at openjdk.java.net Wed May 18 02:49:29 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 18 May 2022 02:49:29 GMT Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate [v2] In-Reply-To: References: Message-ID: > I added two new template functions to reduce the boilerplate code when walking the entries in a ResourceHashtable > > - `template void ResourceHashtable::iterate(F f)` > - `template void ResourceHashtable::iterate_all(F f)` > > I also modified a couple of places in systemDictionaryShared.cpp to use the new functionality. > > Testing with tiers 1-4. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: changed to use lambda capture by reference [&] ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8761/files - new: https://git.openjdk.java.net/jdk/pull/8761/files/e4828286..97cf613a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8761&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8761&range=00-01 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8761.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8761/head:pull/8761 PR: https://git.openjdk.java.net/jdk/pull/8761 From iklam at openjdk.java.net Wed May 18 02:49:29 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 18 May 2022 02:49:29 GMT Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate [v2] In-Reply-To: <-wZ6XE3AIJ1vE7_vmF8MPjMFv-FLGu7xhLeCvbUNnCA=.e16d413e-1ce8-47e9-97b9-c9bd3c74947c@github.com> References: <-wZ6XE3AIJ1vE7_vmF8MPjMFv-FLGu7xhLeCvbUNnCA=.e16d413e-1ce8-47e9-97b9-c9bd3c74947c@github.com> Message-ID: On Wed, 18 May 2022 02:06:21 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> changed to use lambda capture by reference [&] > > src/hotspot/share/cds/dumpTimeClassInfo.inline.hpp line 43: > >> 41: template >> 42: void DumpTimeSharedClassTable::iterate(F f) const { >> 43: auto g = [=] (InstanceKlass* k, DumpTimeClassInfo& info) { > > The style guide states we should try to only use `[&]` for capture by reference. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8761 From stuefe at openjdk.java.net Wed May 18 05:34:55 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 18 May 2022 05:34:55 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v12] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 13:53:36 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. >> >> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. >> >>

>> >> _Note: This is a followup PR for #8061_ > > Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: > > Change comment wording src/hotspot/share/code/codeCache.cpp line 662: > 660: bool is_zombie = result != NULL && result->is_zombie(); > 661: bool is_result_safe = !is_zombie || result->is_locked_by_vm() || VMError::is_error_reported(); > 662: guarantee(is_result_safe || is_in_asgct(), "unsafe access to zombie method"); Why is this a guarantee? Does it still need to be one? We usually avoid paying for assert setup in release VMs, its rather uncommon to use guarantee. ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From stuefe at openjdk.java.net Wed May 18 05:58:59 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 18 May 2022 05:58:59 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v12] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 13:53:36 GMT, Jaroslav Bachorik wrote: >> A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. >> >> Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. >> >>
>> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. >> However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. >> >>

>> >> _Note: This is a followup PR for #8061_ > > Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: > > Change comment wording Looks good to me now. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8549 From shade at openjdk.java.net Wed May 18 06:05:50 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 18 May 2022 06:05:50 GMT Subject: RFR: 8286897: Loom: Cleanup x86_64 StubGenerator [v3] In-Reply-To: <1CsFzv8wOJwBF2f7wET15LwMZoY-mX2wKXq5bGibrzM=.cd19bdbf-1a84-4dd0-beb4-a3d60763854e@github.com> References: <1CsFzv8wOJwBF2f7wET15LwMZoY-mX2wKXq5bGibrzM=.cd19bdbf-1a84-4dd0-beb4-a3d60763854e@github.com> Message-ID: > During x86_32 porting, I ended up rewriting the copy of x86_64 StubGenerator significantly to make it more streamlined. The original x86_64 StubGenerator should enjoy the similar streamlining, since it would likely to be the template for many other architectures. > > There should be no behavior changes, except one small one. For some weird reason, the `__ movptr(c_rarg1, rsp);` in `generate_cont_doYield` used to be much earlier, between `start` and `the_pc`. I don't believe that's part of the frame setup. It looks like a copy-paste glitch from `generate_throw_exception`. So I just moved it here. No tests complain about this move. > > The rest of the changes themselves should speak for themselves, but here is a brief list: > - no need for `assert_asm` macros, instead do the inline checks, like the rest of Hotspot and Loom code > - `_masm` and `masm` shadowing can just use whatever is currently defined as `__` > - more strong cohesion between `post_call_nop`, its associated PC and its oopmap > - consistently use `call_VM_leaf` that only takes the number of arguments, as we are doing argument pushes ourselves anyway; > - for many moves, it is easier to use `ptr` flavors (e.g. `testq` -> `testptr`) to ease copy-pasting to other arches; > - `generate_cont_thaw` should just do the `enabled()` check and carry the `StubCodeMark`, like other stubs do; > - inline comments are reflowed to block-like comments, matching the usual style of stub code; > - labels are prefixed with `L_` for clarity (used in some places in Hotspot); > - `jfr_prolog` and `jfr_epilog` are used only once and do not carry their weight; > - `continuation_*` are documented a bit better; > > Additional testing: > - [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual` > - [x] Linux x86_64 fastdebug, `serviceability/jvmti` > - [x] Linux x86_64 fastdebug, `runtime/vthread` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Review feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8755/files - new: https://git.openjdk.java.net/jdk/pull/8755/files/b4a29e72..8a840a81 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8755&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8755&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8755.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8755/head:pull/8755 PR: https://git.openjdk.java.net/jdk/pull/8755 From shade at openjdk.java.net Wed May 18 06:05:53 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 18 May 2022 06:05:53 GMT Subject: RFR: 8286897: Loom: Cleanup x86_64 StubGenerator [v2] In-Reply-To: References: <1CsFzv8wOJwBF2f7wET15LwMZoY-mX2wKXq5bGibrzM=.cd19bdbf-1a84-4dd0-beb4-a3d60763854e@github.com> Message-ID: On Tue, 17 May 2022 18:03:04 GMT, Vladimir Kozlov wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> More changes from x86_32 PR > > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7455: > >> 7453: OopMapSet* oop_maps = new OopMapSet(); >> 7454: OopMap* map = new OopMap(framesize, 1); >> 7455: oop_maps->add_gc_map(the_pc - start, map); > > Use `frame_complete`. Done. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7460: > >> 7458: __ movptr(c_rarg0, r15_thread); >> 7459: __ movptr(c_rarg1, rsp); >> 7460: __ call_VM_leaf(Continuation::freeze_entry(), 2); > > Was it bug to not set `c_rarg1`? stubGenerator_aarch64.cpp has the same issue. Ah, so this one is little "behavioral" change. For some weird reason, the `__ movptr(c_rarg1, rsp);` used to be much earlier, between `start` and `the_pc`. I don't believe that's part of the frame setup. It looks like a copy-paste glitch from `generate_throw_exception`. So I just moved it here. No tests complain about this move. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7666: > >> 7664: OopMapSet* oop_maps = new OopMapSet(); >> 7665: OopMap* map = new OopMap(framesize, 1); // rbp >> 7666: oop_maps->add_gc_map(the_pc - start, map); > > You can use `frame_complete` here too. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/8755 From shade at openjdk.java.net Wed May 18 06:25:59 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 18 May 2022 06:25:59 GMT Subject: RFR: 8286814: Shenandoah: RedefineRunningMethods.java test failed with Loom In-Reply-To: References: Message-ID: On Tue, 17 May 2022 19:02:54 GMT, Zhengyu Gu wrote: > Please review this patch that fixed failed tests. > > To determine if a barrier is needed for newly allocated `stackChunkOop`, it needs to consider current GC phases, as TAMS and update watermark are specific to corresponding GC phase. > > Test: > > - [x] tier1 with `--enable-preview -XX:+UseShenandoahGC` on Linux x86_64 > - [x] tier2 with `--enable-preview -XX:+UseShenandoahGC` on Linux x86_64 > - [ ] GHA Looks fine. src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2318: > 2316: return false; > 2317: } > 2318: // Objects allocated after evacuation start are guaranteed in to-space, don't need any barriers Newline missing between these two, I think. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8757 From shade at openjdk.java.net Wed May 18 06:30:53 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 18 May 2022 06:30:53 GMT Subject: RFR: 8272791: java -XX:BlockZeroingLowLimit=1 crashes after 8270947 In-Reply-To: References: Message-ID: On Tue, 17 May 2022 18:08:58 GMT, Andrew Haley wrote: > This is an assertion failure caused by setting `BlockZeroingLowLimit` < `wordSize`. > > I believe there was some confusion when writing this code about whether `BlockZeroingLowLimit` should be in words or bytes, and it makes no sense for it to be less than a single word. If anyone ever tried to use a parameter < 8, it triggers an assertion. > > This patch does two things. Firstly, it corrects a `guarantee` which erroneously used `zero_words_block_size` rather than `wordSize`. The value of both of these is 8, so it doesn't change anything in the generated code. Secondly, it clips the `BlockZeroingLowLimit` so that it doesn't trigger the assertion. > > Perhaps it would be better to change the lower limit to 8 instead of this silent correction. There is no backward compatibility issue here, because any attempt to set `BlockZeroingLowLimit` < 8 in the past would have exited the VM with an error, so I don't believe a CSR is warranted if we do change the allowable range. > > So, which should it be? Change the lower limit of the range of the `BlockZeroingLowLimit` system flag, or allow 1 still to be used and silently fix it? Opinions welcome. Why not just do: diff --git a/src/hotspot/cpu/aarch64/globals_aarch64.hpp b/src/hotspot/cpu/aarch64/globals_aarch64.hpp index 56fc873267d..b6310127a4d 100644 --- a/src/hotspot/cpu/aarch64/globals_aarch64.hpp +++ b/src/hotspot/cpu/aarch64/globals_aarch64.hpp @@ -105,7 +105,7 @@ define_pd_global(intx, InlineSmallCode, 1000); "Use DC ZVA for block zeroing") \ product(intx, BlockZeroingLowLimit, 256, \ "Minimum size in bytes when block zeroing will be used") \ - range(1, max_jint) \ + range(wordSize, max_jint) \ product(bool, TraceTraps, false, "Trace all traps the signal handler")\ product(int, SoftwarePrefetchHintDistance, -1, \ "Use prfm hint with specified distance in compiled code." \ ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8756 From jbachorik at openjdk.java.net Wed May 18 06:43:43 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Wed, 18 May 2022 06:43:43 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v13] In-Reply-To: References: Message-ID: > A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. > > Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. > >
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. > However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > >

> > _Note: This is a followup PR for #8061_ Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: Remove unneeded import ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8549/files - new: https://git.openjdk.java.net/jdk/pull/8549/files/ce5924d7..f9e42fd8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8549&range=11-12 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8549.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8549/head:pull/8549 PR: https://git.openjdk.java.net/jdk/pull/8549 From jbachorik at openjdk.java.net Wed May 18 06:45:41 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Wed, 18 May 2022 06:45:41 GMT Subject: RFR: 8283849: AsyncGetCallTrace may crash JVM on guarantee [v12] In-Reply-To: References: Message-ID: On Wed, 18 May 2022 05:30:53 GMT, Thomas Stuefe wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision: >> >> Change comment wording > > src/hotspot/share/code/codeCache.cpp line 662: > >> 660: bool is_zombie = result != NULL && result->is_zombie(); >> 661: bool is_result_safe = !is_zombie || result->is_locked_by_vm() || VMError::is_error_reported(); >> 662: guarantee(is_result_safe || is_in_asgct(), "unsafe access to zombie method"); > > Why is this a guarantee? Does it still need to be one? We usually avoid paying for assert setup in release VMs, its rather uncommon to use guarantee. Not the original author so it is just my best guess - the consequences of accidentally touching dead code blob (where the data structures could have been freed or reused) were considered bad enough to justify the 'guarantee'. Unfortunately, if the code blob is not locked even this guarantee can pass but we can still return a zombie a moment later. But that is another story that will need to be ironed out for ASGCT(2?) ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From jbachorik at openjdk.java.net Wed May 18 06:49:00 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Wed, 18 May 2022 06:49:00 GMT Subject: Integrated: 8283849: AsyncGetCallTrace may crash JVM on guarantee In-Reply-To: References: Message-ID: On Thu, 5 May 2022 11:28:14 GMT, Jaroslav Bachorik wrote: > A gist of the fix is to allow relaxed special handling of code blob lookup when done for ASGCT. > > Currently, a guarantee will fail when we happen to hit a zombie method which is still on stack. While this would indicate a serious error for the normal execution flow, in case of ASGCT being in progress when the executing thread can be expected at any possible method this is something which may happen and we really should not take the profiled JVM down due to it. > >
> Unfortunately, I am not able to create a simple reproducer for the crash other that testing in our production where the crash is happening sporadically. > However, thanks to @parttimenerd and his [ASGCT stress test](https://github.com/parttimenerd/asgct2-tester.git) the problem can be reproduced quite reliably. > >

> > _Note: This is a followup PR for #8061_ This pull request has now been integrated. Changeset: 93c88690 Author: Jaroslav Bachorik URL: https://git.openjdk.java.net/jdk/commit/93c88690a1c2cbc7ba7fc70ddef9bf5928e4de03 Stats: 21 lines in 4 files changed: 19 ins; 0 del; 2 mod 8283849: AsyncGetCallTrace may crash JVM on guarantee Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/8549 From dnsimon at openjdk.java.net Wed May 18 07:05:01 2022 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 18 May 2022 07:05:01 GMT Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate [v2] In-Reply-To: References: Message-ID: On Wed, 18 May 2022 02:49:29 GMT, Ioi Lam wrote: >> I added two new template functions to reduce the boilerplate code when walking the entries in a ResourceHashtable >> >> - `template void ResourceHashtable::iterate(F f)` >> - `template void ResourceHashtable::iterate_all(F f)` >> >> I also modified a couple of places in systemDictionaryShared.cpp to use the new functionality. >> >> Testing with tiers 1-4. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > changed to use lambda capture by reference [&] src/hotspot/share/cds/dumpTimeClassInfo.inline.hpp line 38: > 36: #if INCLUDE_CDS > 37: > 38: // For safety, only iterate over a class if it loader is alive. "if it loader" -> "if its loader is" ------------- PR: https://git.openjdk.java.net/jdk/pull/8761 From eosterlund at openjdk.java.net Wed May 18 07:10:55 2022 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 18 May 2022 07:10:55 GMT Subject: RFR: 8286636: MacroAssembler::post_call_nop should have InstructionMark In-Reply-To: <9FGAXDJlzHK85Pz6nPimWEYlSwxJqWcfMSqAlncSyzc=.a8f06546-1087-477f-90ea-1cdb6f046991@github.com> References: <9FGAXDJlzHK85Pz6nPimWEYlSwxJqWcfMSqAlncSyzc=.a8f06546-1087-477f-90ea-1cdb6f046991@github.com> Message-ID: On Thu, 12 May 2022 11:32:05 GMT, Aleksey Shipilev wrote: > `InstructionMark` checks the instruction boundaries, which is important for relocatable instructions. Everywhere where we do any (?) sort of relocation, we do `InstructionMark`. I found that newly added `MacroAssembler::post_call_nop` does not have it, and thus some new code in x86_32 Loom prototype fails with missing instruction mark / instruction overlapping checks. > > If we add it to `InstructionMark` in AArch64 code, then "overlapping instructions" asserts start to fire, because Loom inserted `post_call_nops` when there was an active instruction mark. x86_64 solves this by [resetting the mark before the nop](https://github.com/openjdk/jdk/blob/40f43c6b1ffc88d55dd3223f5d0259ae73cf0356/src/hotspot/cpu/x86/x86_64.ad#L2084), this patch does the same. > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux AArch64 fastdebug `tier1` Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8678 From shade at openjdk.java.net Wed May 18 07:10:55 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 18 May 2022 07:10:55 GMT Subject: RFR: 8286636: MacroAssembler::post_call_nop should have InstructionMark In-Reply-To: <9FGAXDJlzHK85Pz6nPimWEYlSwxJqWcfMSqAlncSyzc=.a8f06546-1087-477f-90ea-1cdb6f046991@github.com> References: <9FGAXDJlzHK85Pz6nPimWEYlSwxJqWcfMSqAlncSyzc=.a8f06546-1087-477f-90ea-1cdb6f046991@github.com> Message-ID: On Thu, 12 May 2022 11:32:05 GMT, Aleksey Shipilev wrote: > `InstructionMark` checks the instruction boundaries, which is important for relocatable instructions. Everywhere where we do any (?) sort of relocation, we do `InstructionMark`. I found that newly added `MacroAssembler::post_call_nop` does not have it, and thus some new code in x86_32 Loom prototype fails with missing instruction mark / instruction overlapping checks. > > If we add it to `InstructionMark` in AArch64 code, then "overlapping instructions" asserts start to fire, because Loom inserted `post_call_nops` when there was an active instruction mark. x86_64 solves this by [resetting the mark before the nop](https://github.com/openjdk/jdk/blob/40f43c6b1ffc88d55dd3223f5d0259ae73cf0356/src/hotspot/cpu/x86/x86_64.ad#L2084), this patch does the same. > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux AArch64 fastdebug `tier1` Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8678 From shade at openjdk.java.net Wed May 18 07:12:09 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 18 May 2022 07:12:09 GMT Subject: Integrated: 8286636: MacroAssembler::post_call_nop should have InstructionMark In-Reply-To: <9FGAXDJlzHK85Pz6nPimWEYlSwxJqWcfMSqAlncSyzc=.a8f06546-1087-477f-90ea-1cdb6f046991@github.com> References: <9FGAXDJlzHK85Pz6nPimWEYlSwxJqWcfMSqAlncSyzc=.a8f06546-1087-477f-90ea-1cdb6f046991@github.com> Message-ID: On Thu, 12 May 2022 11:32:05 GMT, Aleksey Shipilev wrote: > `InstructionMark` checks the instruction boundaries, which is important for relocatable instructions. Everywhere where we do any (?) sort of relocation, we do `InstructionMark`. I found that newly added `MacroAssembler::post_call_nop` does not have it, and thus some new code in x86_32 Loom prototype fails with missing instruction mark / instruction overlapping checks. > > If we add it to `InstructionMark` in AArch64 code, then "overlapping instructions" asserts start to fire, because Loom inserted `post_call_nops` when there was an active instruction mark. x86_64 solves this by [resetting the mark before the nop](https://github.com/openjdk/jdk/blob/40f43c6b1ffc88d55dd3223f5d0259ae73cf0356/src/hotspot/cpu/x86/x86_64.ad#L2084), this patch does the same. > > Additional testing: > - [x] Linux x86_64 fastdebug `tier1` > - [x] Linux AArch64 fastdebug `tier1` This pull request has now been integrated. Changeset: 44b243a0 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/44b243a0619d69830a029f93a7ce2b68159e9e8f Stats: 5 lines in 3 files changed: 5 ins; 0 del; 0 mod 8286636: MacroAssembler::post_call_nop should have InstructionMark Reviewed-by: kvn, eosterlund ------------- PR: https://git.openjdk.java.net/jdk/pull/8678 From duke at openjdk.java.net Wed May 18 08:55:47 2022 From: duke at openjdk.java.net (olivergillespie) Date: Wed, 18 May 2022 08:55:47 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: <593XoxrsJZIckhlB8dtRmUU7SeQrgYRbVMnncZrcvS4=.675f22e6-d81e-4739-bc1b-2cc6bb43e1e8@github.com> On Mon, 16 May 2022 15:52:22 GMT, olivergillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. Thanks for the comments, all. I will run all SPECjvm2008 benchmarks before and after the change for us to look at - I'll share the results later today. In the application that uncovered this issue for me, minor use of AVX3 instructions (about 3-4% of the overall CPU usage, all in various flavours of disjoint_arraycopy) on my Cascade Lake processor downclocks the whole machine by ~15% - that means all threads/cores/processes slowed by 15% across the board. The local speedup thanks to AVX3 has to be weighed against the global downclocking overhead, and I contend that most real-world applications will see far more overhead than benefit from AVX3 on Cascade Lake. ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From jvernee at openjdk.java.net Wed May 18 09:53:31 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 18 May 2022 09:53:31 GMT Subject: Integrated: 8283689: Update the foreign linker VM implementation In-Reply-To: References: Message-ID: <96UqTMEdAdl4yleY0IBU6LJjL8ww23IUcktML7Aa8UM=.9bfa69dc-720b-43aa-9b77-147b29d925cd@github.com> On Fri, 25 Mar 2022 13:48:20 GMT, Jorn Vernee wrote: > Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited resources to handle this. As such, this PR might fall over to 20, but it would be nice if we could get it into 19. > > I've written up an overview of the Linker architecture here: http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful to read that first. > > This patch moves from the "legacy" implementation, to what is currently implemented in the panama-foreign repo, except for replacing the use of method handle combinators with ASM. That will come in a later path. To recap. This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. And VM stubs and Java code implementing the buffered invocation strategy has been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method handle linker was no longer needed and has been removed [6] (support might be re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now implements RuntimeBlob directly. Binding to java classes has been rewritten to use javaClasses.h/cpp (this wasn't previously possible due to these java classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java changes to support (2). > > The original commit structure has been mostly retained, so it might be useful to look at a specific commit, or the corresponding patch in the [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) repo as well. I've also left some inline comments to explain some of the changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 This pull request has now been integrated. Changeset: 81e4bdbe Author: Jorn Vernee URL: https://git.openjdk.java.net/jdk/commit/81e4bdbe1358b7feced08ba758ddb66415968036 Stats: 6914 lines in 155 files changed: 2577 ins; 3219 del; 1118 mod 8283689: Update the foreign linker VM implementation Co-authored-by: Jorn Vernee Co-authored-by: Nick Gasson Reviewed-by: mcimadamore, vlivanov, rehn ------------- PR: https://git.openjdk.java.net/jdk/pull/7959 From shade at openjdk.java.net Wed May 18 09:53:32 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 18 May 2022 09:53:32 GMT Subject: RFR: 8286944: Loom: Common ContinuationEntry cookie handling Message-ID: <3A1mwN4h3ZuTYYUl9bnXs7uEw32KNX3mmDU0XeGSPn0=.236ce636-4201-4d96-bf30-89256374c8cc@github.com> Platform-specific code injects the cookie to the head of ContinuationEntry. The value for this cookie is hard-coded in platform-specific code, which is fragile. It would be better to common the cookie handling a bit to ease porting. In fact, I have spent an hour trying to debug a thing where I mistyped a cookie value in x86_32 code, hence my interest. Additional testing: - [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual` - [ ] Linux AArch64 fastdebug, `java/lang/Thread/virtual` ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/8762/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8762&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286944 Stats: 12 lines in 3 files changed: 8 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8762.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8762/head:pull/8762 PR: https://git.openjdk.java.net/jdk/pull/8762 From duke at openjdk.java.net Wed May 18 09:56:58 2022 From: duke at openjdk.java.net (openjdk-notifier[bot]) Date: Wed, 18 May 2022 09:56:58 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v4] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 16:22:15 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well. >> >> Thanks, >> Jorn >> >> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux. > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge branch 'pr/7959' into JEP-19-ASM > - BootstrapMethodError -> ExceptionInInitializerError > - Use unaligned layout constants when filling in reconstituted structs (was accidentally dropped change) > - Fix LinkUpcall benchmark > - 8286306: Upcall wrapper class sharing > > Reviewed-by: mcimadamore > - Polish > - 8281595: ASM-ify scope acquire/release for down call parameters > 8281387: Some downcall shapes show unexpected allocations > > Co-authored-by: Maurizio Cimadamore > Reviewed-by: mcimadamore > - 8281228: Preview branch's CLinker.downcallHandle crashes inside asm > > Reviewed-by: sundar, jvernee > - 8278414: Replace binding recipe customization using MH combinators with bytecode spinning > > Reviewed-by: mcimadamore > - 8276648: Downcall stubs are never freed > > Reviewed-by: mcimadamore The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork: git checkout JEP-19-ASM git fetch https://git.openjdk.java.net/jdk master git merge FETCH_HEAD # if there are conflicts, follow the instructions given by git merge git commit -m "Merge master" git push ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From rbackman at openjdk.java.net Wed May 18 10:23:55 2022 From: rbackman at openjdk.java.net (Rickard =?UTF-8?B?QsOkY2ttYW4=?=) Date: Wed, 18 May 2022 10:23:55 GMT Subject: RFR: 8286944: Loom: Common ContinuationEntry cookie handling In-Reply-To: <3A1mwN4h3ZuTYYUl9bnXs7uEw32KNX3mmDU0XeGSPn0=.236ce636-4201-4d96-bf30-89256374c8cc@github.com> References: <3A1mwN4h3ZuTYYUl9bnXs7uEw32KNX3mmDU0XeGSPn0=.236ce636-4201-4d96-bf30-89256374c8cc@github.com> Message-ID: On Wed, 18 May 2022 09:46:43 GMT, Aleksey Shipilev wrote: > Platform-specific code injects the cookie to the head of ContinuationEntry. The value for this cookie is hard-coded in platform-specific code, which is fragile. It would be better to common the cookie handling a bit to ease porting. In fact, I have spent an hour trying to debug a thing where I mistyped a cookie value in x86_32 code, hence my interest. > > Additional testing: > - [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual` > - [x] Linux AArch64 fastdebug, `java/lang/Thread/virtual` Looks good. ------------- Marked as reviewed by rbackman (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8762 From alanb at openjdk.java.net Wed May 18 10:56:40 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 18 May 2022 10:56:40 GMT Subject: RFR: 8286944: Loom: Common ContinuationEntry cookie handling In-Reply-To: <3A1mwN4h3ZuTYYUl9bnXs7uEw32KNX3mmDU0XeGSPn0=.236ce636-4201-4d96-bf30-89256374c8cc@github.com> References: <3A1mwN4h3ZuTYYUl9bnXs7uEw32KNX3mmDU0XeGSPn0=.236ce636-4201-4d96-bf30-89256374c8cc@github.com> Message-ID: On Wed, 18 May 2022 09:46:43 GMT, Aleksey Shipilev wrote: > * [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual` > * [x] Linux AArch64 fastdebug, `java/lang/Thread/virtual` It would be good to run test/jdk/jdk/internal/vm/Continuation too. We didn't bring the jdk_loom and hotspot_loom test groups into the main line as the assumption was that they would only be needed when working in loom repo. But now I wonder if it might be useful to have these in the main line, at least until the ports and other cleanup are done. ------------- PR: https://git.openjdk.java.net/jdk/pull/8762 From shade at openjdk.java.net Wed May 18 11:02:48 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 18 May 2022 11:02:48 GMT Subject: RFR: 8286944: Loom: Common ContinuationEntry cookie handling In-Reply-To: References: <3A1mwN4h3ZuTYYUl9bnXs7uEw32KNX3mmDU0XeGSPn0=.236ce636-4201-4d96-bf30-89256374c8cc@github.com> Message-ID: On Wed, 18 May 2022 10:53:30 GMT, Alan Bateman wrote: > > * [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual` > > * [x] Linux AArch64 fastdebug, `java/lang/Thread/virtual` > > It would be good to run test/jdk/jdk/internal/vm/Continuation too. We didn't bring the jdk_loom and hotspot_loom test groups into the main line as the assumption was that they would only be needed when working in loom repo. But now I wonder if it might be useful to have these in the main line, at least until the ports and other cleanup are done. Yes, I was honestly surprised these did not make into mainline. I can bring this commit as mainline PR: https://github.com/openjdk/loom/commit/e470f96787332f6cc353a57a39e17841c68714fd ------------- PR: https://git.openjdk.java.net/jdk/pull/8762 From alanb at openjdk.java.net Wed May 18 11:07:50 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 18 May 2022 11:07:50 GMT Subject: RFR: 8286944: Loom: Common ContinuationEntry cookie handling In-Reply-To: <3A1mwN4h3ZuTYYUl9bnXs7uEw32KNX3mmDU0XeGSPn0=.236ce636-4201-4d96-bf30-89256374c8cc@github.com> References: <3A1mwN4h3ZuTYYUl9bnXs7uEw32KNX3mmDU0XeGSPn0=.236ce636-4201-4d96-bf30-89256374c8cc@github.com> Message-ID: On Wed, 18 May 2022 09:46:43 GMT, Aleksey Shipilev wrote: > Platform-specific code injects the cookie to the head of ContinuationEntry. The value for this cookie is hard-coded in platform-specific code, which is fragile. It would be better to common the cookie handling a bit to ease porting. In fact, I have spent an hour trying to debug a thing where I mistyped a cookie value in x86_32 code, hence my interest. > > Additional testing: > - [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual` > - [x] Linux AArch64 fastdebug, `java/lang/Thread/virtual` > I can bring this commit as mainline PR: [openjdk/loom at e470f96](https://github.com/openjdk/loom/commit/e470f96787332f6cc353a57a39e17841c68714fd) That commit is a bit of out date as there are new/changed locations so best to just take the latest from the fibers branch of the loom repo. ------------- PR: https://git.openjdk.java.net/jdk/pull/8762 From shade at openjdk.java.net Wed May 18 11:14:55 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 18 May 2022 11:14:55 GMT Subject: RFR: 8286944: Loom: Common ContinuationEntry cookie handling In-Reply-To: References: <3A1mwN4h3ZuTYYUl9bnXs7uEw32KNX3mmDU0XeGSPn0=.236ce636-4201-4d96-bf30-89256374c8cc@github.com> Message-ID: <9OToGgXGNla5-__jFrpRR_d0YiAnq-I4MPYE7YMjBaM=.34d94f2d-ba1f-46e2-a89c-b29efb0704d9@github.com> On Wed, 18 May 2022 11:04:20 GMT, Alan Bateman wrote: > > I can bring this commit as mainline PR: [openjdk/loom at e470f96](https://github.com/openjdk/loom/commit/e470f96787332f6cc353a57a39e17841c68714fd) > > That commit is a bit of out date as there are new/changed locations so best to just take the latest from the fibers branch of the loom repo. See #8765. I'll retest this PR once test groups land. ------------- PR: https://git.openjdk.java.net/jdk/pull/8762 From shade at openjdk.java.net Wed May 18 11:17:37 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 18 May 2022 11:17:37 GMT Subject: RFR: 8286956: Loom: Define test groups for development/porting use Message-ID: It would be beneficial to bring over the Loom-specific test groups from the loom repo to aid development/porting work. https://github.com/openjdk/loom/blob/fibers/test/jdk/TEST.groups#L97-L108 https://github.com/openjdk/loom/blob/6f42923b3342e41d95b262733205283068802b40/test/hotspot/jtreg/TEST.groups#L111-L125 I had to drop `jdk/incubator/concurrent` from JDK definition, because there are no tests in that folder and tests break. Additional testing: - [x] Linux x86_64 fastdebug `hotspot_loom jdk_loom` - [ ] Linux AArch64 fastdebug `hotspot_loom jdk_loom` ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/8765/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8765&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286956 Stats: 28 lines in 2 files changed: 28 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8765.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8765/head:pull/8765 PR: https://git.openjdk.java.net/jdk/pull/8765 From jvernee at openjdk.java.net Wed May 18 11:27:24 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 18 May 2022 11:27:24 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v5] In-Reply-To: References: Message-ID: > Hi, > > This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well. > > Thanks, > Jorn > > Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux. Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 118 commits: - Merge branch 'JEP-19-ASM' of https://github.com/JornVernee/jdk into JEP-19-ASM - Merge branch 'pr/7959' into JEP-19-ASM - Merge branch 'master' into JEP-19-VM-IMPL2 - ifdef NOT_PRODUCT -> ifndef PRODUCT - Missing ASSERT -> NOT_PRODUCT - Cleanup UL usage - Fix failure with SPEC disabled (accidentally dropped change) - indentation - fix space - Merge branch 'master' into JEP-19-ASM - ... and 108 more: https://git.openjdk.java.net/jdk/compare/81e4bdbe...ce5c677a ------------- Changes: https://git.openjdk.java.net/jdk/pull/8685/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8685&range=04 Stats: 2142 lines in 24 files changed: 1357 ins; 660 del; 125 mod Patch: https://git.openjdk.java.net/jdk/pull/8685.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8685/head:pull/8685 PR: https://git.openjdk.java.net/jdk/pull/8685 From jvernee at openjdk.java.net Wed May 18 11:27:26 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 18 May 2022 11:27:26 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: <4HyW0Kv4vN-7wXdlxTzXFer1oLP6e2w_Z3XlxZT5w00=.f066b4a6-e471-43a3-873c-d5d6db9cbb95@github.com> References: <_V3vkhcEtDHkPVK-nFLMiNPP-4zuL6-oh6lktwpFnb8=.bb53c336-e10d-4008-a346-43764e77efcf@github.com> <4HyW0Kv4vN-7wXdlxTzXFer1oLP6e2w_Z3XlxZT5w00=.f066b4a6-e471-43a3-873c-d5d6db9cbb95@github.com> Message-ID: On Tue, 17 May 2022 10:08:00 GMT, Jorn Vernee wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 131: >> >>> 129: private int[] scopeSlots; >>> 130: private int curScopeLocalIdx = -1; >>> 131: private int RETURN_ALLOCATOR_IDX = -1; >> >> These are not constants, so it is odd to see the name capitalized > > Right, habit of writing lambda forms, where name variables are capitalized. Changed to lowercase. ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From jvernee at openjdk.java.net Wed May 18 11:27:29 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 18 May 2022 11:27:29 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 06:00:37 GMT, R?mi Forax wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> BootstrapMethodError -> ExceptionInInitializerError > > src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 157: > >> 155: } >> 156: >> 157: static MethodHandle doSpecialize(MethodHandle leafHandle, CallingSequence callingSequence, ABIDescriptor abi) { > > I think thise method should be split in to, one version for the upcall, one for the downcall, i do not see the point of merging the two codes. I've split this method into a specializeDowncall and specializeUpcall method. > src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 816: > >> 814: return; >> 815: } >> 816: if (con instanceof Integer) { > > those can use the instanceof + type pattern Done > src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 967: > >> 965: >> 966: // unaligned constants >> 967: public final static ValueLayout.OfBoolean JAVA_BOOLEAN_UNALIGNED = JAVA_BOOLEAN; > > as far as i understand, those constants are accessed from the bytecode, they should be in their own class to cleanly separate the specializer part and the runtime part. I've put these in a nest `Runtime` class, with a comment explaining that they are referenced from the generated code. ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From jvernee at openjdk.java.net Wed May 18 11:27:31 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 18 May 2022 11:27:31 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: <_V3vkhcEtDHkPVK-nFLMiNPP-4zuL6-oh6lktwpFnb8=.bb53c336-e10d-4008-a346-43764e77efcf@github.com> References: <_V3vkhcEtDHkPVK-nFLMiNPP-4zuL6-oh6lktwpFnb8=.bb53c336-e10d-4008-a346-43764e77efcf@github.com> Message-ID: On Tue, 17 May 2022 08:41:59 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: >> >> BootstrapMethodError -> ExceptionInInitializerError > > src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 291: > >> 289: emitGetStatic(Binding.Context.class, "DUMMY", BINDING_CONTEXT_DESC); >> 290: } else { >> 291: emitInvokeStatic(Binding.Context.class, "ofSession", OF_SESSION_DESC); > > Maybe this is micro-optimization, but I realized that in reality we probably don't need any scope/session if there are no "ToSegment" bindings. Done > src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 336: > >> 334: >> 335: if (callingSequence.forUpcall()) { >> 336: // for upcalls, recipes have a result, which we handle here > > I find this part a bit confusing. The comment speaks about recipes input and outputs, hinting at the fact that downcall bindings have inputs, while upcall bindings have outputs. > In reality, if we look at the bindings themselves, they look pretty symmetric: > > * UNBOX_ADDRESS = pops an Addressable and push a long on the stack > * BOX_ADDRESS = pops a long and push a MemoryAddress on the stack > > That is, in both cases it appears we have an input and an output (and the binding is just the function which maps one into another). > > I think the input/output asymmetry comes in when we consider the full recipes. In downcalls, for a given argument we will have the following sequence: > > Binding0, Binding1, ... BindingN-1, VMStore > > While for upcalls we will have: > > VMLoad, Binding1, Binding2, ... BindingN > > So (ignoring return buffer for simplicity), for downcalls, it is obvious that before we can execute Binding0, we need some kind of "input value" (e.g. the value of some local). For upcalls, this is not needed, as the VMLoad binding will basically do that for free. > When we finished executing the bindings, again, for downcalls there's nothing to do, as the chain always ends with a VMStore (which stores binding result into some local), while for upcalls we do need to set the output value explicitly. > > In other words, it seems to me that having VMLoad and VMStore in the chains of bindings to be interpreted/specialized does more harm than good here. These low level bindings make sense for the VM code, as the VM needs to know how to load a value from a register, or how to store a value into a register. But in terms of the specializing Java code, these bindings are immaterial. At the same time, the fact that we have these bindings, and that they are virtualized, makes the code hard to follow, as some preparation happens in `BindingSpecializer::specialize`, while some other preparation happens inside `BindingSpecializer::doBindings`, as part of the virtualized impl of VMLoad/VMStore. And, this virtualized implementation ends up doing similar steps as what the preparation code before/after the binding execution does (e.g. for downcalls/VMStore we call setOutput, while for upcalls/VMLoad we call getInput). > > All I'm saying here is that, for bindings to work, we _always_ need to call both getInput and setOutput - but it is easy to overlook this when looking at the code, because the getInput/setOutput calls are spread across two different places in the specializing code, perhaps making things more asymmetric than they need to be. (I realize I'm simplifying here, and that some details of the return buffer are not 100% quite as symmetric). I'm not sure if there is anything actionable here? I've thought in the past that it might be nice to have `GetArgument`/`SetArgument` and `GetReturnValue`/`SetReturnValue` binding operators as well, to make the inputs/outputs more explicit in the recipe. But, it doesn't seem like that would make things _much_ better... ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From jvernee at openjdk.java.net Wed May 18 11:27:31 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 18 May 2022 11:27:31 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 11:18:20 GMT, Jorn Vernee wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 943: >> >>> 941: Z, B, S, C, I, J, F, D, L; >>> 942: >>> 943: static BasicType of(Class cls) { >> >> This seems a duplication of ASM Type class for no good reason, Type.getOpcode(ILOAD) or Type.getOpcode(IRETURN) gives you the proper variant opcode > > Didn't know about that. Neat! Removed the `BasicType` enum, switched to using `Type` and `Type.getSort()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From jvernee at openjdk.java.net Wed May 18 11:27:32 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 18 May 2022 11:27:32 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v2] In-Reply-To: References: <7VrPuAg8gehM1WFBIRt780PFam3f28f6FBd2jLVRATM=.c6e003c8-93c4-4bb9-a95c-bbcbe916233d@github.com> Message-ID: <4_AWyEgqDZdWB7_m3BFbGgPAhmUdQ_JIOPbr9aWMixw=.4fc4165e-1484-45fb-82d5-a35ba7d83e17@github.com> On Tue, 17 May 2022 10:19:04 GMT, Jorn Vernee wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequence.java line 109: >> >>> 107: * @return the caller method type. >>> 108: */ >>> 109: public MethodType callerMethodType() { >> >> Would it make sense to either rename these, or to point to the fact that these are equivalent to Linker::downcallType/upcallType ? > > I don't think renaming them to down/upcallType makes sense, since both down/up calls use both the caller and callee method type. There can also be things that make these not equivalent to downcallType/upcallType, such as the SysV need to pass the number of floating point arguments for variadic calls as well: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java#L109-L111 I've left this as is for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From alanb at openjdk.java.net Wed May 18 12:23:49 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 18 May 2022 12:23:49 GMT Subject: RFR: 8286956: Loom: Define test groups for development/porting use In-Reply-To: References: Message-ID: On Wed, 18 May 2022 11:10:58 GMT, Aleksey Shipilev wrote: > It would be beneficial to bring over the Loom-specific test groups from the loom repo to aid development/porting work. > > https://github.com/openjdk/loom/blob/fibers/test/jdk/TEST.groups#L97-L108 > https://github.com/openjdk/loom/blob/6f42923b3342e41d95b262733205283068802b40/test/hotspot/jtreg/TEST.groups#L111-L125 > > I had to drop `jdk/incubator/concurrent` from JDK definition, because there are no tests in that folder and tests break. > > Additional testing: > - [x] Linux x86_64 fastdebug `hotspot_loom jdk_loom` > - [x] Linux AArch64 fastdebug `hotspot_loom jdk_loom` Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8765 From coleenp at openjdk.java.net Wed May 18 12:29:55 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 18 May 2022 12:29:55 GMT Subject: RFR: 8286944: Loom: Common ContinuationEntry cookie handling In-Reply-To: <3A1mwN4h3ZuTYYUl9bnXs7uEw32KNX3mmDU0XeGSPn0=.236ce636-4201-4d96-bf30-89256374c8cc@github.com> References: <3A1mwN4h3ZuTYYUl9bnXs7uEw32KNX3mmDU0XeGSPn0=.236ce636-4201-4d96-bf30-89256374c8cc@github.com> Message-ID: <5AIQgUGeeOe6eIP8wJCkp2V8rgYHos74UgeiQfflpCk=.02c346e6-23de-4c73-aec4-e751a84fae38@github.com> On Wed, 18 May 2022 09:46:43 GMT, Aleksey Shipilev wrote: > Platform-specific code injects the cookie to the head of ContinuationEntry. The value for this cookie is hard-coded in platform-specific code, which is fragile. It would be better to common the cookie handling a bit to ease porting. In fact, I have spent an hour trying to debug a thing where I mistyped a cookie value in x86_32 code, hence my interest. > > Additional testing: > - [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual` > - [x] Linux AArch64 fastdebug, `java/lang/Thread/virtual` Thanks. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8762 From zgu at openjdk.java.net Wed May 18 12:34:54 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 18 May 2022 12:34:54 GMT Subject: RFR: 8286814: Shenandoah: RedefineRunningMethods.java test failed with Loom [v2] In-Reply-To: References: Message-ID: > Please review this patch that fixed failed tests. > > To determine if a barrier is needed for newly allocated `stackChunkOop`, it needs to consider current GC phases, as TAMS and update watermark are specific to corresponding GC phase. > > Test: > > - [x] tier1 with `--enable-preview -XX:+UseShenandoahGC` on Linux x86_64 > - [x] tier2 with `--enable-preview -XX:+UseShenandoahGC` on Linux x86_64 > - [ ] GHA Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Added space line ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8757/files - new: https://git.openjdk.java.net/jdk/pull/8757/files/c565201f..69c24158 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8757&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8757&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8757.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8757/head:pull/8757 PR: https://git.openjdk.java.net/jdk/pull/8757 From coleenp at openjdk.java.net Wed May 18 12:37:00 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 18 May 2022 12:37:00 GMT Subject: RFR: 8286944: Loom: Common ContinuationEntry cookie handling In-Reply-To: <9OToGgXGNla5-__jFrpRR_d0YiAnq-I4MPYE7YMjBaM=.34d94f2d-ba1f-46e2-a89c-b29efb0704d9@github.com> References: <3A1mwN4h3ZuTYYUl9bnXs7uEw32KNX3mmDU0XeGSPn0=.236ce636-4201-4d96-bf30-89256374c8cc@github.com> <9OToGgXGNla5-__jFrpRR_d0YiAnq-I4MPYE7YMjBaM=.34d94f2d-ba1f-46e2-a89c-b29efb0704d9@github.com> Message-ID: <8t8BBZeDzcGw1cbtu8rXmgFa5_mHYahMlNTNVaQUITY=.11defc8c-96ae-4fb8-9f65-e567ab3d212f@github.com> On Wed, 18 May 2022 11:11:23 GMT, Aleksey Shipilev wrote: >>> I can bring this commit as mainline PR: [openjdk/loom at e470f96](https://github.com/openjdk/loom/commit/e470f96787332f6cc353a57a39e17841c68714fd) >> >> That commit is a bit of out date as there are new/changed locations so best to just take the latest from the fibers branch of the loom repo. > >> > I can bring this commit as mainline PR: [openjdk/loom at e470f96](https://github.com/openjdk/loom/commit/e470f96787332f6cc353a57a39e17841c68714fd) >> >> That commit is a bit of out date as there are new/changed locations so best to just take the latest from the fibers branch of the loom repo. > > See #8765. I'll retest this PR once test groups land. We were thinking of renaming the ContinuationEntry class because it's not an entry but more of an anchor. Your suggestions are welcome @shipilev since it appears that you're doing a lot of porting work. We'll wait until things settle down though (maybe in JDK 20). ------------- PR: https://git.openjdk.java.net/jdk/pull/8762 From duke at openjdk.java.net Wed May 18 13:12:38 2022 From: duke at openjdk.java.net (olivergillespie) Date: Wed, 18 May 2022 13:12:38 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: <7e-IJESlulr9lwDP65526zzB2JTJlPOO6iYhrrNwt0Y=.936bff79-3380-47c7-8838-307d291cd918@github.com> On Mon, 16 May 2022 15:52:22 GMT, olivergillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. Below are my complete SPECjvm2008 results, running on an AWS EC2 m4.4xl host (CPU details also shared below), with warmup time of 120s and 1 iteration of 240s per benchmark. My results are somewhat noisy, in part due to running on virtualized hardware. There are a range of both regressions and improvements after my change, roughly equal in count and magnitudes. Do keep in mind that any regressions (where UseAVX=2 is slower) are local to that operation, but improvements (where UseAVX=2 is faster) can often be felt by the whole machine - avoiding 15% downclocking is worth a lot more than 15% speedup in one code path. On this basis, I think UseAVX=2 is the right default for this hardware. @vnkozlov - I don't see a significant regression in crypto.aes on my runs, could you please share more info about your test and hardware? cpu family : 6 model : 85 model name : Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz stepping : 7 microcode : 0x5003103 Note for the `Change` column: a positive % means the UseAVX=2 run is faster/better (higher ops/m) compared to the UseAVX=3 baseline/default behaviour. Negative means it was slower. | | UseAVX=3 (ops/m) | UseAVX=2 (ops/m) | Change | |-----------------------------|------------------|------------------|--------| | startup.helloworld | 217 | 190 | -12% | | startup.compiler.compiler | 218 | 205 | -6% | | startup.compiler.sunflow | 218 | 221 | +1% | | startup.compress | 42 | 42 | +1% | | startup.crypto.aes | 18 | 18 | -1% | | startup.crypto.rsa | 99 | 94 | -5% | | startup.crypto.signverify | 80 | 77 | -5% | | startup.mpegaudio | 29 | 28 | -4% | | startup.scimark.fft | 67 | 69 | +3% | | startup.scimark.lu | 90 | 75 | -17% | | startup.scimark.monte_carlo | 17 | 17 | +1% | | startup.scimark.sor | 32 | 35 | +9% | | startup.scimark.sparse | 42 | 42 | +0% | | startup.serial | 31 | 32 | +2% | | startup.sunflow | 37 | 34 | -9% | | startup.xml.transform | 35 | 35 | -1% | | startup.xml.validation | 47 | 50 | +7% | | compress | 576 | 568 | -1% | | crypto.aes | 202 | 200 | -1% | | crypto.rsa | 4065 | 4049 | -0% | | crypto.signverify | 2033 | 1964 | -3% | | derby | 1391 | 1411 | +1% | | mpegaudio | 324 | 363 | +12% | | scimark.fft.large | 274 | 271 | -1% | | scimark.lu.large | 73 | 73 | -0% | | scimark.sor.large | 160 | 154 | -4% | | scimark.sparse.large | 155 | 129 | -17% | | scimark.fft.small | 1340 | 1421 | +6% | | scimark.lu.small | 1967 | 2467 | +25% | | scimark.sor.small | 700 | 679 | -3% | | scimark.sparse.small | 544 | 492 | -10% | | scimark.monte_carlo | 729 | 700 | -4% | | serial | 477 | 466 | -2% | | sunflow | 208 | 219 | +5% | | xml.transform | 778 | 894 | +15% | | xml.validation | 1610 | 1926 | +20% | ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From aivanov at openjdk.java.net Wed May 18 13:34:24 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 18 May 2022 13:34:24 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base Message-ID: Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? Also, I fixed a couple of spelling mistakes. ------------- Commit messages: - 8284191: Replace usages of 'the an' in hotspot and java.base - 8284191: Replace usages of 'the an' in hotspot and java.base - 8284191: Replace usages of 'the an' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - 8284191: Replace usages of 'the the' in hotspot and java.base - ... and 13 more: https://git.openjdk.java.net/jdk/compare/69ff86a3...c7e73658 Changes: https://git.openjdk.java.net/jdk/pull/8768/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284191 Stats: 202 lines in 162 files changed: 0 ins; 11 del; 191 mod Patch: https://git.openjdk.java.net/jdk/pull/8768.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768 PR: https://git.openjdk.java.net/jdk/pull/8768 From jvernee at openjdk.java.net Wed May 18 13:37:59 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 18 May 2022 13:37:59 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v5] In-Reply-To: References: Message-ID: <4wEDBYrAp2-fKxMHbnM06x28_Uq1KTQW5UMQSlSw3Jk=.fe10ad78-73ae-4f8d-9f83-c061a68e30b1@github.com> On Wed, 18 May 2022 11:27:24 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well. >> >> Thanks, >> Jorn >> >> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux. > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 118 commits: > > - Merge branch 'JEP-19-ASM' of https://github.com/JornVernee/jdk into JEP-19-ASM > - Merge branch 'pr/7959' into JEP-19-ASM > - Merge branch 'master' into JEP-19-VM-IMPL2 > - ifdef NOT_PRODUCT -> ifndef PRODUCT > - Missing ASSERT -> NOT_PRODUCT > - Cleanup UL usage > - Fix failure with SPEC disabled (accidentally dropped change) > - indentation > - fix space > - Merge branch 'master' into JEP-19-ASM > - ... and 108 more: https://git.openjdk.java.net/jdk/compare/81e4bdbe...ce5c677a I think I've addressed most review comments now. Please take another look. ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From forax at openjdk.java.net Wed May 18 13:57:55 2022 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 18 May 2022 13:57:55 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v5] In-Reply-To: References: Message-ID: <2jc-7Db8s6I1EpSD8hCcjirMA49Mv_d2Qh0yQ1upsCM=.26508852-5649-4a90-b171-62f173f40400@github.com> On Wed, 18 May 2022 11:27:24 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well. >> >> Thanks, >> Jorn >> >> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux. > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 118 commits: > > - Merge branch 'JEP-19-ASM' of https://github.com/JornVernee/jdk into JEP-19-ASM > - Merge branch 'pr/7959' into JEP-19-ASM > - Merge branch 'master' into JEP-19-VM-IMPL2 > - ifdef NOT_PRODUCT -> ifndef PRODUCT > - Missing ASSERT -> NOT_PRODUCT > - Cleanup UL usage > - Fix failure with SPEC disabled (accidentally dropped change) > - indentation > - fix space > - Merge branch 'master' into JEP-19-ASM > - ... and 108 more: https://git.openjdk.java.net/jdk/compare/81e4bdbe...ce5c677a LGTM ! ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From mcimadamore at openjdk.java.net Wed May 18 14:25:46 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 18 May 2022 14:25:46 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: References: <_V3vkhcEtDHkPVK-nFLMiNPP-4zuL6-oh6lktwpFnb8=.bb53c336-e10d-4008-a346-43764e77efcf@github.com> Message-ID: On Wed, 18 May 2022 11:23:07 GMT, Jorn Vernee wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 336: >> >>> 334: >>> 335: if (callingSequence.forUpcall()) { >>> 336: // for upcalls, recipes have a result, which we handle here >> >> I find this part a bit confusing. The comment speaks about recipes input and outputs, hinting at the fact that downcall bindings have inputs, while upcall bindings have outputs. >> In reality, if we look at the bindings themselves, they look pretty symmetric: >> >> * UNBOX_ADDRESS = pops an Addressable and push a long on the stack >> * BOX_ADDRESS = pops a long and push a MemoryAddress on the stack >> >> That is, in both cases it appears we have an input and an output (and the binding is just the function which maps one into another). >> >> I think the input/output asymmetry comes in when we consider the full recipes. In downcalls, for a given argument we will have the following sequence: >> >> Binding0, Binding1, ... BindingN-1, VMStore >> >> While for upcalls we will have: >> >> VMLoad, Binding1, Binding2, ... BindingN >> >> So (ignoring return buffer for simplicity), for downcalls, it is obvious that before we can execute Binding0, we need some kind of "input value" (e.g. the value of some local). For upcalls, this is not needed, as the VMLoad binding will basically do that for free. >> When we finished executing the bindings, again, for downcalls there's nothing to do, as the chain always ends with a VMStore (which stores binding result into some local), while for upcalls we do need to set the output value explicitly. >> >> In other words, it seems to me that having VMLoad and VMStore in the chains of bindings to be interpreted/specialized does more harm than good here. These low level bindings make sense for the VM code, as the VM needs to know how to load a value from a register, or how to store a value into a register. But in terms of the specializing Java code, these bindings are immaterial. At the same time, the fact that we have these bindings, and that they are virtualized, makes the code hard to follow, as some preparation happens in `BindingSpecializer::specialize`, while some other preparation happens inside `BindingSpecializer::doBindings`, as part of the virtualized impl of VMLoad/VMStore. And, this virtualized implementation ends up doing similar steps as what the preparation code before/after the binding execution does (e.g. for downcalls/VMStore we call setOutput, while for upcalls/VMLoad we call getInput). >> >> All I'm saying here is that, for bindings to work, we _always_ need to call both getInput and setOutput - but it is easy to overlook this when looking at the code, because the getInput/setOutput calls are spread across two different places in the specializing code, perhaps making things more asymmetric than they need to be. (I realize I'm simplifying here, and that some details of the return buffer are not 100% quite as symmetric). > > I'm not sure if there is anything actionable here? > > I've thought in the past that it might be nice to have `GetArgument`/`SetArgument` and `GetReturnValue`/`SetReturnValue` binding operators as well, to make the inputs/outputs more explicit in the recipe. But, it doesn't seem like that would make things _much_ better... I wasn't suggesting to add more bindings. I was more suggesting to filter out the load/store from the set of bindings (since these are virtualized anyways) that are passed to `doBindings`. Then, before executing a set of bindings, (if we are in downcall mode) we load the corresponding input local var. After executing bindings (if we are in upcall mode) we store result in corresponding var. E.g. make the logic that load locals and store locals explicit in the `specialize` method, rather than have parts of it execute "in disguise" as "binding interpretation". ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From kvn at openjdk.java.net Wed May 18 14:37:47 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 18 May 2022 14:37:47 GMT Subject: RFR: 8286897: Loom: Cleanup x86_64 StubGenerator [v3] In-Reply-To: References: <1CsFzv8wOJwBF2f7wET15LwMZoY-mX2wKXq5bGibrzM=.cd19bdbf-1a84-4dd0-beb4-a3d60763854e@github.com> Message-ID: On Wed, 18 May 2022 06:05:50 GMT, Aleksey Shipilev wrote: >> During x86_32 porting, I ended up rewriting the copy of x86_64 StubGenerator significantly to make it more streamlined. The original x86_64 StubGenerator should enjoy the similar streamlining, since it would likely to be the template for many other architectures. >> >> There should be no behavior changes, except one small one. For some weird reason, the `__ movptr(c_rarg1, rsp);` in `generate_cont_doYield` used to be much earlier, between `start` and `the_pc`. I don't believe that's part of the frame setup. It looks like a copy-paste glitch from `generate_throw_exception`. So I just moved it here. No tests complain about this move. >> >> The rest of the changes themselves should speak for themselves, but here is a brief list: >> - no need for `assert_asm` macros, instead do the inline checks, like the rest of Hotspot and Loom code >> - `_masm` and `masm` shadowing can just use whatever is currently defined as `__` >> - more strong cohesion between `post_call_nop`, its associated PC and its oopmap >> - consistently use `call_VM_leaf` that only takes the number of arguments, as we are doing argument pushes ourselves anyway; >> - for many moves, it is easier to use `ptr` flavors (e.g. `testq` -> `testptr`) to ease copy-pasting to other arches; >> - `generate_cont_thaw` should just do the `enabled()` check and carry the `StubCodeMark`, like other stubs do; >> - inline comments are reflowed to block-like comments, matching the usual style of stub code; >> - labels are prefixed with `L_` for clarity (used in some places in Hotspot); >> - `jfr_prolog` and `jfr_epilog` are used only once and do not carry their weight; >> - `continuation_*` are documented a bit better; >> >> Additional testing: >> - [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual` >> - [x] Linux x86_64 fastdebug, `serviceability/jvmti` >> - [x] Linux x86_64 fastdebug, `runtime/vthread` >> - [x] Linux x86_64 fastdebug, `tier1` >> - [x] Linux x86_64 fastdebug, `tier2` >> - [x] Linux x86_64 fastdebug, `tier3` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8755 From kvn at openjdk.java.net Wed May 18 14:37:48 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 18 May 2022 14:37:48 GMT Subject: RFR: 8286897: Loom: Cleanup x86_64 StubGenerator [v2] In-Reply-To: References: <1CsFzv8wOJwBF2f7wET15LwMZoY-mX2wKXq5bGibrzM=.cd19bdbf-1a84-4dd0-beb4-a3d60763854e@github.com> Message-ID: <96UGyRjGXfSX5U9P16zgKTN4bImQCxiCo34AGP2sHg8=.b85e7555-5525-4d87-99fa-db036c31ec92@github.com> On Wed, 18 May 2022 05:55:31 GMT, Aleksey Shipilev wrote: >> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 7460: >> >>> 7458: __ movptr(c_rarg0, r15_thread); >>> 7459: __ movptr(c_rarg1, rsp); >>> 7460: __ call_VM_leaf(Continuation::freeze_entry(), 2); >> >> Was it bug to not set `c_rarg1`? stubGenerator_aarch64.cpp has the same issue. > > Ah, so this one is little "behavioral" change. For some weird reason, the `__ movptr(c_rarg1, rsp);` used to be much earlier, between `start` and `the_pc`. I don't believe that's part of the frame setup. It looks like a copy-paste glitch from `generate_throw_exception`. So I just moved it here. No tests complain about this move. Okay. I missed it in original place (too far away) and I thought it is new instruction. ------------- PR: https://git.openjdk.java.net/jdk/pull/8755 From lancea at openjdk.java.net Wed May 18 14:42:53 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 18 May 2022 14:42:53 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From jvernee at openjdk.java.net Wed May 18 14:55:00 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 18 May 2022 14:55:00 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: References: <_V3vkhcEtDHkPVK-nFLMiNPP-4zuL6-oh6lktwpFnb8=.bb53c336-e10d-4008-a346-43764e77efcf@github.com> Message-ID: <5-HktPHZPp7wH-7WdGkE6DnPqqAeG7It7Qp2e571aus=.b858f1b8-37a3-44be-a75e-3fb722d05573@github.com> On Wed, 18 May 2022 14:21:55 GMT, Maurizio Cimadamore wrote: >> I'm not sure if there is anything actionable here? >> >> I've thought in the past that it might be nice to have `GetArgument`/`SetArgument` and `GetReturnValue`/`SetReturnValue` binding operators as well, to make the inputs/outputs more explicit in the recipe. But, it doesn't seem like that would make things _much_ better... > > I wasn't suggesting to add more bindings. I was more suggesting to filter out the load/store from the set of bindings (since these are virtualized anyways) that are passed to `doBindings`. Then, before executing a set of bindings, (if we are in downcall mode) we load the corresponding input local var. After executing bindings (if we are in upcall mode) we store result in corresponding var. > > E.g. make the logic that load locals and store locals explicit in the `specialize` method, rather than have parts of it execute "in disguise" as "binding interpretation". It's not quite that simple since a binding recipe for a single parameter can have multiple VMStores for instance if a struct is decomposed into multiple values. It can be done by pulling the binding loops up to the `specialize` method, and have if statements for VMStore and VMLoad, like this: for (Binding binding : callingSequence.argumentBindings(i)) { if (binding instanceof Binding.VMStore vms && callingSequence.forDowncall()) { emitSetOutput(vms.type()); } else if (binding instanceof Binding.VMLoad && callingSequence.forUpcall()) { emitGetInput(); } else { doBinding(binding); } } And for returns: for (Binding binding : callingSequence.returnBindings()) { if (binding instanceof Binding.VMLoad vml && callingSequence.forDowncall()) { if (!callingSequence.needsReturnBuffer()) { emitRestoreReturnValue(vml.type()); } else { emitReturnBufferLoad(vml); } } else if (binding instanceof Binding.VMStore vms && callingSequence.forUpcall()) { if (!callingSequence.needsReturnBuffer()) { emitSaveReturnValue(vms.type()); } else { emitReturnBufferStore(vms); } } else { doBinding(binding); } } But, maybe that's better? ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From jvernee at openjdk.java.net Wed May 18 15:09:08 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 18 May 2022 15:09:08 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: <5-HktPHZPp7wH-7WdGkE6DnPqqAeG7It7Qp2e571aus=.b858f1b8-37a3-44be-a75e-3fb722d05573@github.com> References: <_V3vkhcEtDHkPVK-nFLMiNPP-4zuL6-oh6lktwpFnb8=.bb53c336-e10d-4008-a346-43764e77efcf@github.com> <5-HktPHZPp7wH-7WdGkE6DnPqqAeG7It7Qp2e571aus=.b858f1b8-37a3-44be-a75e-3fb722d05573@github.com> Message-ID: On Wed, 18 May 2022 14:51:02 GMT, Jorn Vernee wrote: >> I wasn't suggesting to add more bindings. I was more suggesting to filter out the load/store from the set of bindings (since these are virtualized anyways) that are passed to `doBindings`. Then, before executing a set of bindings, (if we are in downcall mode) we load the corresponding input local var. After executing bindings (if we are in upcall mode) we store result in corresponding var. >> >> E.g. make the logic that load locals and store locals explicit in the `specialize` method, rather than have parts of it execute "in disguise" as "binding interpretation". > > It's not quite that simple since a binding recipe for a single parameter can have multiple VMStores for instance if a struct is decomposed into multiple values. > > It can be done by pulling the binding loops up to the `specialize` method, and have if statements for VMStore and VMLoad, like this: > > for (Binding binding : callingSequence.argumentBindings(i)) { > if (binding instanceof Binding.VMStore vms && callingSequence.forDowncall()) { > emitSetOutput(vms.type()); > } else if (binding instanceof Binding.VMLoad && callingSequence.forUpcall()) { > emitGetInput(); > } else { > doBinding(binding); > } > } > > And for returns: > > for (Binding binding : callingSequence.returnBindings()) { > if (binding instanceof Binding.VMLoad vml && callingSequence.forDowncall()) { > if (!callingSequence.needsReturnBuffer()) { > emitRestoreReturnValue(vml.type()); > } else { > emitReturnBufferLoad(vml); > } > } else if (binding instanceof Binding.VMStore vms && callingSequence.forUpcall()) { > if (!callingSequence.needsReturnBuffer()) { > emitSaveReturnValue(vms.type()); > } else { > emitReturnBufferStore(vms); > } > } else { > doBinding(binding); > } > } > > But, maybe that's better? I think someone might look at this and think "why aren't these bindings handled by `doBinding`"? ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From wetmore at openjdk.java.net Wed May 18 15:15:56 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 18 May 2022 15:15:56 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. Looked at - java.base/.../sun/security - jdk.crypto.* - test/*/com/sun/crypto/provider - test/*/java/lang/SecurityManager - test/*/java/security - test/*/krb5 - test/*/jarsigner and those look fine. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8768 From shade at openjdk.java.net Wed May 18 15:22:50 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 18 May 2022 15:22:50 GMT Subject: RFR: 8286944: Loom: Common ContinuationEntry cookie handling In-Reply-To: <3A1mwN4h3ZuTYYUl9bnXs7uEw32KNX3mmDU0XeGSPn0=.236ce636-4201-4d96-bf30-89256374c8cc@github.com> References: <3A1mwN4h3ZuTYYUl9bnXs7uEw32KNX3mmDU0XeGSPn0=.236ce636-4201-4d96-bf30-89256374c8cc@github.com> Message-ID: On Wed, 18 May 2022 09:46:43 GMT, Aleksey Shipilev wrote: > Platform-specific code injects the cookie to the head of ContinuationEntry. The value for this cookie is hard-coded in platform-specific code, which is fragile. It would be better to common the cookie handling a bit to ease porting. In fact, I have spent an hour trying to debug a thing where I mistyped a cookie value in x86_32 code, hence my interest. > > Additional testing: > - [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual` > - [x] Linux AArch64 fastdebug, `java/lang/Thread/virtual` I retested both x86_64 and AArch64 with new testgroups, and the tests are passing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8762 From shade at openjdk.java.net Wed May 18 15:22:50 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 18 May 2022 15:22:50 GMT Subject: RFR: 8286944: Loom: Common ContinuationEntry cookie handling In-Reply-To: References: <3A1mwN4h3ZuTYYUl9bnXs7uEw32KNX3mmDU0XeGSPn0=.236ce636-4201-4d96-bf30-89256374c8cc@github.com> Message-ID: On Wed, 18 May 2022 15:18:52 GMT, Aleksey Shipilev wrote: >> Platform-specific code injects the cookie to the head of ContinuationEntry. The value for this cookie is hard-coded in platform-specific code, which is fragile. It would be better to common the cookie handling a bit to ease porting. In fact, I have spent an hour trying to debug a thing where I mistyped a cookie value in x86_32 code, hence my interest. >> >> Additional testing: >> - [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual` >> - [x] Linux AArch64 fastdebug, `java/lang/Thread/virtual` > > I retested both x86_64 and AArch64 with new testgroups, and the tests are passing. > We were thinking of renaming the ContinuationEntry class because it's not an entry but more of an anchor. Your suggestions are welcome @shipilev since it appears that you're doing a lot of porting work. We'll wait until things settle down though (maybe in JDK 20). I don't care about the naming at this point :) Maybe later, indeed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8762 From mcimadamore at openjdk.java.net Wed May 18 15:36:55 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 18 May 2022 15:36:55 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v5] In-Reply-To: References: Message-ID: On Wed, 18 May 2022 11:27:24 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well. >> >> Thanks, >> Jorn >> >> Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux. > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 118 commits: > > - Merge branch 'JEP-19-ASM' of https://github.com/JornVernee/jdk into JEP-19-ASM > - Merge branch 'pr/7959' into JEP-19-ASM > - Merge branch 'master' into JEP-19-VM-IMPL2 > - ifdef NOT_PRODUCT -> ifndef PRODUCT > - Missing ASSERT -> NOT_PRODUCT > - Cleanup UL usage > - Fix failure with SPEC disabled (accidentally dropped change) > - indentation > - fix space > - Merge branch 'master' into JEP-19-ASM > - ... and 108 more: https://git.openjdk.java.net/jdk/compare/81e4bdbe...ce5c677a Looks good! ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8685 From mcimadamore at openjdk.java.net Wed May 18 15:36:57 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 18 May 2022 15:36:57 GMT Subject: RFR: 8286669: Replace MethodHandle specialization with ASM in mainline [v3] In-Reply-To: References: <_V3vkhcEtDHkPVK-nFLMiNPP-4zuL6-oh6lktwpFnb8=.bb53c336-e10d-4008-a346-43764e77efcf@github.com> <5-HktPHZPp7wH-7WdGkE6DnPqqAeG7It7Qp2e571aus=.b858f1b8-37a3-44be-a75e-3fb722d05573@github.com> Message-ID: On Wed, 18 May 2022 15:05:26 GMT, Jorn Vernee wrote: >> It's not quite that simple since a binding recipe for a single parameter can have multiple VMStores for instance if a struct is decomposed into multiple values. >> >> It can be done by pulling the binding loops up to the `specialize` method, and have if statements for VMStore and VMLoad, like this: >> >> for (Binding binding : callingSequence.argumentBindings(i)) { >> if (binding instanceof Binding.VMStore vms && callingSequence.forDowncall()) { >> emitSetOutput(vms.type()); >> } else if (binding instanceof Binding.VMLoad && callingSequence.forUpcall()) { >> emitGetInput(); >> } else { >> doBinding(binding); >> } >> } >> >> And for returns: >> >> for (Binding binding : callingSequence.returnBindings()) { >> if (binding instanceof Binding.VMLoad vml && callingSequence.forDowncall()) { >> if (!callingSequence.needsReturnBuffer()) { >> emitRestoreReturnValue(vml.type()); >> } else { >> emitReturnBufferLoad(vml); >> } >> } else if (binding instanceof Binding.VMStore vms && callingSequence.forUpcall()) { >> if (!callingSequence.needsReturnBuffer()) { >> emitSaveReturnValue(vms.type()); >> } else { >> emitReturnBufferStore(vms); >> } >> } else { >> doBinding(binding); >> } >> } >> >> But, maybe that's better? > > I think someone might look at this and think "why aren't these bindings handled by `doBinding`"? Let's leave it as is for the time being. I guess what I'm trying to get at is to try and make the code more explicit - but that is hard, given the constraints. ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From duke at openjdk.java.net Wed May 18 15:51:22 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Wed, 18 May 2022 15:51:22 GMT Subject: RFR: 8286182: C2: crash with SIGFPE when executing compiled code Message-ID: This patch backs out the changes made by [JDK-8285390](https://bugs.openjdk.java.net/browse/JDK-8285390) and [JDK-8284742](https://bugs.openjdk.java.net/browse/JDK-8284742) since there are failures due to div nodes floating above its validity checks. Thanks. ------------- Commit messages: - Revert "8284742: x86: Handle integral division overflow during parsing" - Revert "8285390: PPC64: Handle integral division overflow during parsing" Changes: https://git.openjdk.java.net/jdk/pull/8774/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8774&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286182 Stats: 967 lines in 25 files changed: 364 ins; 476 del; 127 mod Patch: https://git.openjdk.java.net/jdk/pull/8774.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8774/head:pull/8774 PR: https://git.openjdk.java.net/jdk/pull/8774 From jvernee at openjdk.java.net Wed May 18 16:06:01 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 18 May 2022 16:06:01 GMT Subject: Integrated: 8286669: Replace MethodHandle specialization with ASM in mainline In-Reply-To: References: Message-ID: On Thu, 12 May 2022 17:17:37 GMT, Jorn Vernee wrote: > Hi, > > This PR brings over commits from the panama-foreign repo. These commits mostly pertain to the switch to ASM and away from MethodHandle combinators for the binding recipe specialization. But, there is one more commit which adds freeing of downcall stubs, since those changes were mostly Java as well. > > Thanks, > Jorn > > Testing: `run-test-jdk_foreign` with `-Dgenerator.sample.factor=-1` on Windows and Linux. This pull request has now been integrated. Changeset: ee45a0ac Author: Jorn Vernee URL: https://git.openjdk.java.net/jdk/commit/ee45a0ac63613312b4f17dcd55e8defa94c34669 Stats: 2142 lines in 24 files changed: 1357 ins; 660 del; 125 mod 8286669: Replace MethodHandle specialization with ASM in mainline Co-authored-by: Jorn Vernee Co-authored-by: Maurizio Cimadamore Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk/pull/8685 From naoto at openjdk.java.net Wed May 18 16:18:58 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 18 May 2022 16:18:58 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: <4eXpe5pmBsvw8u6fJlzd9BWsnY74LiyjTqQhQ88uxoc=.6182985a-f751-4d55-b9d0-bc605d7636da@github.com> On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. LGTM for i18n changes. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8768 From mdoerr at openjdk.java.net Wed May 18 16:21:44 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 18 May 2022 16:21:44 GMT Subject: RFR: 8286182: C2: crash with SIGFPE when executing compiled code In-Reply-To: References: Message-ID: <67WWMvwBqtJvlgMWW7KaYrropJ0uvwHUwW0WbcTWmJ0=.5798663a-31fc-4945-8243-17e989e1c2fd@github.com> On Wed, 18 May 2022 15:44:10 GMT, Quan Anh Mai wrote: > This patch backs out the changes made by [JDK-8285390](https://bugs.openjdk.java.net/browse/JDK-8285390) and [JDK-8284742](https://bugs.openjdk.java.net/browse/JDK-8284742) since there are failures due to div nodes floating above its validity checks. > > Thanks. LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8774 From shade at openjdk.java.net Wed May 18 16:26:49 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 18 May 2022 16:26:49 GMT Subject: RFR: 8286897: Loom: Cleanup x86_64 StubGenerator [v3] In-Reply-To: References: <1CsFzv8wOJwBF2f7wET15LwMZoY-mX2wKXq5bGibrzM=.cd19bdbf-1a84-4dd0-beb4-a3d60763854e@github.com> Message-ID: On Wed, 18 May 2022 14:34:10 GMT, Vladimir Kozlov wrote: > Good. Thanks! Any more comments/testing, anyone? I would like to integrate it soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/8755 From rpressler at openjdk.java.net Wed May 18 16:26:49 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Wed, 18 May 2022 16:26:49 GMT Subject: RFR: 8286897: Loom: Cleanup x86_64 StubGenerator [v3] In-Reply-To: References: <1CsFzv8wOJwBF2f7wET15LwMZoY-mX2wKXq5bGibrzM=.cd19bdbf-1a84-4dd0-beb4-a3d60763854e@github.com> Message-ID: On Wed, 18 May 2022 06:05:50 GMT, Aleksey Shipilev wrote: >> During x86_32 porting, I ended up rewriting the copy of x86_64 StubGenerator significantly to make it more streamlined. The original x86_64 StubGenerator should enjoy the similar streamlining, since it would likely to be the template for many other architectures. >> >> There should be no behavior changes, except one small one. For some weird reason, the `__ movptr(c_rarg1, rsp);` in `generate_cont_doYield` used to be much earlier, between `start` and `the_pc`. I don't believe that's part of the frame setup. It looks like a copy-paste glitch from `generate_throw_exception`. So I just moved it here. No tests complain about this move. >> >> The rest of the changes themselves should speak for themselves, but here is a brief list: >> - no need for `assert_asm` macros, instead do the inline checks, like the rest of Hotspot and Loom code >> - `_masm` and `masm` shadowing can just use whatever is currently defined as `__` >> - more strong cohesion between `post_call_nop`, its associated PC and its oopmap >> - consistently use `call_VM_leaf` that only takes the number of arguments, as we are doing argument pushes ourselves anyway; >> - for many moves, it is easier to use `ptr` flavors (e.g. `testq` -> `testptr`) to ease copy-pasting to other arches; >> - `generate_cont_thaw` should just do the `enabled()` check and carry the `StubCodeMark`, like other stubs do; >> - inline comments are reflowed to block-like comments, matching the usual style of stub code; >> - labels are prefixed with `L_` for clarity (used in some places in Hotspot); >> - `jfr_prolog` and `jfr_epilog` are used only once and do not carry their weight; >> - `continuation_*` are documented a bit better; >> >> Additional testing: >> - [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual` >> - [x] Linux x86_64 fastdebug, `serviceability/jvmti` >> - [x] Linux x86_64 fastdebug, `runtime/vthread` >> - [x] Linux x86_64 fastdebug, `tier1` >> - [x] Linux x86_64 fastdebug, `tier2` >> - [x] Linux x86_64 fastdebug, `tier3` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback You generally need to test `jdk/internal/vm/Continuation/` for all continuation-related stuff, but those are in tier1, I think. ------------- PR: https://git.openjdk.java.net/jdk/pull/8755 From kvn at openjdk.java.net Wed May 18 16:31:42 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 18 May 2022 16:31:42 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Mon, 16 May 2022 15:52:22 GMT, olivergillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. I got regression when I did not load my system - I run spec with `-bt 8`. I will do rerun with full load. My system is slightly different: 8260L CPU @ 2.40GHz. ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From iris at openjdk.java.net Wed May 18 16:59:50 2022 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 18 May 2022 16:59:50 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From iklam at openjdk.java.net Wed May 18 17:01:38 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 18 May 2022 17:01:38 GMT Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate [v3] In-Reply-To: References: Message-ID: > I added two new template functions to reduce the boilerplate code when walking the entries in a ResourceHashtable > > - `template void ResourceHashtable::iterate(F f)` > - `template void ResourceHashtable::iterate_all(F f)` > > I also modified a couple of places in systemDictionaryShared.cpp to use the new functionality. > > Testing with tiers 1-4. Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: - Fixed typo in comment (it loader -> its loader) - Better naming of variables. E.g., (F f) -> (Function function), as suggested by @@stefank ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8761/files - new: https://git.openjdk.java.net/jdk/pull/8761/files/97cf613a..f3ca12ad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8761&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8761&range=01-02 Stats: 31 lines in 4 files changed: 0 ins; 2 del; 29 mod Patch: https://git.openjdk.java.net/jdk/pull/8761.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8761/head:pull/8761 PR: https://git.openjdk.java.net/jdk/pull/8761 From shade at openjdk.java.net Wed May 18 17:22:02 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 18 May 2022 17:22:02 GMT Subject: RFR: 8286897: Loom: Cleanup x86_64 StubGenerator [v3] In-Reply-To: References: <1CsFzv8wOJwBF2f7wET15LwMZoY-mX2wKXq5bGibrzM=.cd19bdbf-1a84-4dd0-beb4-a3d60763854e@github.com> Message-ID: On Wed, 18 May 2022 16:23:37 GMT, Ron Pressler wrote: > You generally need to test `jdk/internal/vm/Continuation/` for all continuation-related stuff, but those are in tier1, I think. I did test groups from #8765 on Linux x86_64, and they still pass. ------------- PR: https://git.openjdk.java.net/jdk/pull/8755 From jvernee at openjdk.java.net Wed May 18 17:24:44 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 18 May 2022 17:24:44 GMT Subject: RFR: 8286825: Linker naming cleanup Message-ID: This patch is a batch naming cleanup for the foreign linker implementation. The naming changes are as follows: - ProgrammableInvoker -> DowncallLinker - ProgrammableUpcallHandler -> UpcallLinker - 'native invoker' -> 'downcall stub' - 'optimzed entry blob' -> 'upcall stub' - OptimizedEntryBlob -> UpcallStub - optimized_entry_frame -> upcall_stub_frame Then renaming of some hotspot files: - universalNativeInvoker* -> downcallLinker* - universalUpcallHandler* -> upcallLinker* - foreign_globals* -> foreignGlobals* (to match existing convention) Method, field, and other variable names are also adjusted accordingly. ------------- Commit messages: - 8275648: Linker naming bikeshed Changes: https://git.openjdk.java.net/jdk/pull/8777/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8777&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286825 Stats: 2397 lines in 84 files changed: 1086 ins; 1090 del; 221 mod Patch: https://git.openjdk.java.net/jdk/pull/8777.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8777/head:pull/8777 PR: https://git.openjdk.java.net/jdk/pull/8777 From zgu at openjdk.java.net Wed May 18 18:30:41 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 18 May 2022 18:30:41 GMT Subject: Integrated: 8286814: Shenandoah: RedefineRunningMethods.java test failed with Loom In-Reply-To: References: Message-ID: On Tue, 17 May 2022 19:02:54 GMT, Zhengyu Gu wrote: > Please review this patch that fixed failed tests. > > To determine if a barrier is needed for newly allocated `stackChunkOop`, it needs to consider current GC phases, as TAMS and update watermark are specific to corresponding GC phase. > > Test: > > - [x] tier1 with `--enable-preview -XX:+UseShenandoahGC` on Linux x86_64 > - [x] tier2 with `--enable-preview -XX:+UseShenandoahGC` on Linux x86_64 > - [ ] GHA This pull request has now been integrated. Changeset: cd5bfe7b Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/cd5bfe7b97d581a7c7fdb39df72bb22bfaed4f50 Stats: 18 lines in 2 files changed: 10 ins; 0 del; 8 mod 8286814: Shenandoah: RedefineRunningMethods.java test failed with Loom Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/8757 From simonis at openjdk.java.net Wed May 18 18:39:36 2022 From: simonis at openjdk.java.net (Volker Simonis) Date: Wed, 18 May 2022 18:39:36 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <7e-IJESlulr9lwDP65526zzB2JTJlPOO6iYhrrNwt0Y=.936bff79-3380-47c7-8838-307d291cd918@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> <7e-IJESlulr9lwDP65526zzB2JTJlPOO6iYhrrNwt0Y=.936bff79-3380-47c7-8838-307d291cd918@github.com> Message-ID: On Wed, 18 May 2022 13:08:54 GMT, olivergillespie wrote: >> The current code already does this for 'older' Skylake processors, >> namely those with _stepping < 5. My testing indicates this is a >> problem for later processors in this family too, so I have removed the >> max stepping condition. >> >> The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. >> >> A general description of the overall issue is given at >> https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. >> >> According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, >> stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, >> and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using >> -XX:UseAVX=3, along with a corresponding performance reduction. >> >> I first saw this issue in a real production workload, where the main AVX3 instructions >> being executed were those generated for various flavours of disjoint_arraycopy. >> >> I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. >> >> >> java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ >> --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ >> -jar SPECjvm2008.jar -ikv -ict xml.transform >> >> >> Before the change, or with -XX:UseAVX=3: >> >> >> Valid run! >> Score on xml.transform: 776.00 ops/m >> >> >> After the change, or with -XX:UseAVX=2: >> >> >> Valid run! >> Score on xml.transform: 894.07 ops/m >> >> >> So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively >> affected by this change, but I contend that this is still the right move given the stark >> difference in this benchmark combined with the fact that use of AVX3 instructions can >> affect *all* processes/code on the host due to the downclocking, and the fact that this >> effect is very hard to root-cause, for example CPU profiles look very similar before and >> after since all code is equally slowed. > > Below are my complete SPECjvm2008 results, running on an AWS EC2 m4.4xl host (CPU details also shared below), with warmup time of 120s and 1 iteration of 240s per benchmark. My results are somewhat noisy, in part due to running on virtualized hardware. > > There are a range of both regressions and improvements after my change, roughly equal in count and magnitudes. Do keep in mind that any regressions (where UseAVX=2 is slower) are local to that operation, but improvements (where UseAVX=2 is faster) can often be felt by the whole machine - avoiding 15% downclocking is worth a lot more than 15% speedup in one code path. On this basis, I think UseAVX=2 is the right default for this hardware. > > @vnkozlov - I don't see a significant regression in crypto.aes on my runs, could you please share more info about your test and hardware? > > > cpu family : 6 > model : 85 > model name : Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz > stepping : 7 > microcode : 0x5003103 > > > Note for the `Change` column: a positive % means the UseAVX=2 run is faster/better (higher ops/m) compared to the UseAVX=3 baseline/default behaviour. Negative means it was slower. > > | | UseAVX=3 (ops/m) | UseAVX=2 (ops/m) | Change | > |-----------------------------|------------------|------------------|--------| > | startup.helloworld | 217 | 190 | -12% | > | startup.compiler.compiler | 218 | 205 | -6% | > | startup.compiler.sunflow | 218 | 221 | +1% | > | startup.compress | 42 | 42 | +1% | > | startup.crypto.aes | 18 | 18 | -1% | > | startup.crypto.rsa | 99 | 94 | -5% | > | startup.crypto.signverify | 80 | 77 | -5% | > | startup.mpegaudio | 29 | 28 | -4% | > | startup.scimark.fft | 67 | 69 | +3% | > | startup.scimark.lu | 90 | 75 | -17% | > | startup.scimark.monte_carlo | 17 | 17 | +1% | > | startup.scimark.sor | 32 | 35 | +9% | > | startup.scimark.sparse | 42 | 42 | +0% | > | startup.serial | 31 | 32 | +2% | > | startup.sunflow | 37 | 34 | -9% | > | startup.xml.transform | 35 | 35 | -1% | > | startup.xml.validation | 47 | 50 | +7% | > | compress | 576 | 568 | -1% | > | crypto.aes | 202 | 200 | -1% | > | crypto.rsa | 4065 | 4049 | -0% | > | crypto.signverify | 2033 | 1964 | -3% | > | derby | 1391 | 1411 | +1% | > | mpegaudio | 324 | 363 | +12% | > | scimark.fft.large | 274 | 271 | -1% | > | scimark.lu.large | 73 | 73 | -0% | > | scimark.sor.large | 160 | 154 | -4% | > | scimark.sparse.large | 155 | 129 | -17% | > | scimark.fft.small | 1340 | 1421 | +6% | > | scimark.lu.small | 1967 | 2467 | +25% | > | scimark.sor.small | 700 | 679 | -3% | > | scimark.sparse.small | 544 | 492 | -10% | > | scimark.monte_carlo | 729 | 700 | -4% | > | serial | 477 | 466 | -2% | > | sunflow | 208 | 219 | +5% | > | xml.transform | 778 | 894 | +15% | > | xml.validation | 1610 | 1926 | +20% | @olivergillespie I think these benchmarks should be done on bare metal machines. As you have correctly observed, usage of AVX3 can impact the whole CPU. How can you make sure that other applications running in parallel to yours on the same virtualized hardware don't influence your results by using AVX3 themselves? Also, I think you should run any sub-benchmark in isolation to make sure that the CPU has recovered after potential down-clocking because of a previous sub-benchmark which heavily used AVX3. It might also be helpful to run a tool like [i7z](https://github.com/ajaiantilal/i7z) in parallel to your benchmarks which displays the clock speed of all CPUs (there might be better tools but this should at least give you an idea about what's going on). Ideally, you should have an additional column for every result which displays the average CPU speed during the benchmark run. ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From dchuyko at openjdk.java.net Wed May 18 19:13:21 2022 From: dchuyko at openjdk.java.net (Dmitry Chuyko) Date: Wed, 18 May 2022 19:13:21 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions Message-ID: On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. ------------- Commit messages: - Merge branch 'openjdk:master' into JDK-8282322 - hardlse feature Changes: https://git.openjdk.java.net/jdk/pull/8779/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8779&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282322 Stats: 194 lines in 5 files changed: 193 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8779.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8779/head:pull/8779 PR: https://git.openjdk.java.net/jdk/pull/8779 From gziemski at openjdk.java.net Wed May 18 21:33:57 2022 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 18 May 2022 21:33:57 GMT Subject: RFR: 8284273: Early crashes in os::print_context on AArch64 Message-ID: Our error reporting mechanism can crash again, while reporting the original crash, because we try to access a possibly bogus memory location, for example while printing a location of memory referred by a CPU register. In such case, we skip over the already reported section (including the one where the secondary crash has occurred). This is possible, because we section the error reporting code into sections, called "steps", with a state that retains the information about the last attempted step. Here, we are concerned with two particular steps: "printing register info" and "printing registers, top of stack, instructions near pc". In those two steps we report 4 distinct chunks of info: 1. registers' raw values (safe) 2. registers' decoded content (risky) 3. memory around the "sp" (risky) 4. memory around the "pc" (risky) The issue here is that on some platforms (Linux aarch64) a single "step" contains 2, 3 and 4, all "risky" sections, so if we crash early in the step, we skip the rest of it and end up never reporting the later sections, ex: STEP("printing register info") print_register_info 1. registers' raw values (safe) STEP("printing registers, top of stack, instructions near pc") print_context 2. registers' decoded content (risky) 3. memory around the "sp" (risky) 4. memory around the "pc" (risky) Other platforms (Linux x64) have a single "step" containing 1, 3 and 4, and another one containing just 2, so that we always get to report section 3, ex: STEP("printing register info") print_register_info 2. registers' decoded content (risky) STEP("printing registers, top of stack, instructions near pc") print_context 1. registers' raw values (safe) 3. memory around the "sp" (risky) 4. memory around the "pc" (risky) This fix proposes to rearrange the STEPS, so that the less risky sections come first and to split the STEP with 3 sections into 2 STEPS, like so: STEP("printing registers") print_context 1. registers' raw values (safe) STEP("printing register info") print_register_info 2. registers' decoded content (risky) STEP("printing top of stack, instructions near pc") print_tos_pc 3. memory around the "sp" (risky) 4. memory around the "pc" (risky) ------------- Commit messages: - move risky sections into separate STEPs Changes: https://git.openjdk.java.net/jdk/pull/8736/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8736&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284273 Stats: 124 lines in 15 files changed: 95 ins; 11 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/8736.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8736/head:pull/8736 PR: https://git.openjdk.java.net/jdk/pull/8736 From gziemski at openjdk.java.net Wed May 18 21:38:33 2022 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 18 May 2022 21:38:33 GMT Subject: RFR: 8284273: Early crashes in os::print_context on AArch64 In-Reply-To: References: Message-ID: On Mon, 16 May 2022 21:58:56 GMT, Gerard Ziemski wrote: > Our error reporting mechanism can crash again, while reporting the original crash, because we try to access a possibly bogus memory location, for example while printing a location of memory referred by a CPU register. In such case, we skip over the already reported section (including the one where the secondary crash has occurred). > > This is possible, because we section the error reporting code into sections, called "steps", with a state that retains the information about the last attempted step. > > Here, we are concerned with two particular steps: "printing register info" and "printing registers, top of stack, instructions near pc". In those two steps we report 4 distinct chunks of info: > > 1. registers' raw values (safe) > 2. registers' decoded content (risky) > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) > > The issue here is that on some platforms (Linux aarch64) a single "step" contains 2, 3 and 4, all "risky" sections, so if we crash early in the step, we skip the rest of it and end up never reporting the later sections, ex: > > > STEP("printing register info") > print_register_info > 1. registers' raw values (safe) > > STEP("printing registers, top of stack, instructions near pc") > print_context > 2. registers' decoded content (risky) > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) > > > Other platforms (Linux x64) have a single "step" containing 1, 3 and 4, and another one containing just 2, so that we always get to report section 3, ex: > > > STEP("printing register info") > print_register_info > 2. registers' decoded content (risky) > > STEP("printing registers, top of stack, instructions near pc") > print_context > 1. registers' raw values (safe) > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) > > > This fix proposes to rearrange the STEPS, so that the less risky sections come first and to split the STEP with 3 sections into 2 STEPS, like so: > > > STEP("printing registers") > print_context > 1. registers' raw values (safe) > > STEP("printing register info") > print_register_info > 2. registers' decoded content (risky) > > STEP("printing top of stack, instructions near pc") > print_tos_pc > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) Does anyone understand why the `Pre-submit tests - Linux x86 - Test (tier1)` check is failing with _Unable to find any artifacts for the associated workflow_ ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8736 From vlivanov at openjdk.java.net Wed May 18 23:25:42 2022 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 18 May 2022 23:25:42 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v6] In-Reply-To: References: <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com> Message-ID: <-lS_36hGarJvCL26lgWyXJd-e2SuLD9g1wWL5PuoLXI=.5ddb3b74-493f-41df-8544-8a963c66fc5d@github.com> On Fri, 13 May 2022 08:24:21 GMT, Jatin Bhateja wrote: > LUT should be generated only if UsePopCountInsturction is false Should there be `!UsePopCountInsturction` check then? > restrict the scope of flag to only scalar popcount operation Interesting. But AArch64 code does cover vector cases which just adds confusion. ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From vlivanov at openjdk.java.net Wed May 18 23:39:53 2022 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 18 May 2022 23:39:53 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v3] In-Reply-To: References: <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com> Message-ID: On Fri, 13 May 2022 08:24:24 GMT, Jatin Bhateja wrote: >> src/hotspot/share/opto/c2compiler.cpp line 521: >> >>> 519: if (!Matcher::match_rule_supported(Op_SignumF)) return false; >>> 520: break; >>> 521: case vmIntrinsics::_VectorComExp: >> >> Why `_VectorComExp` intrinsic is special? Other vector intrinsics are handled later and in a different manner. >> >> What about `ExpandV` case? > > It was an attempt to facilitate in-lining of these APIs over targets which do not intrinsify them. I agree its not a generic fix since three APIs are piggybacking on same entry point and without the knowledge of opcode it will be inappropriate to take any call at this place, lazy intrinsification gives opportunity for some of the predications to concertize as compilation happens under closed world assumptions. Still not clear why the code is shaped the way it is. `Matcher::match_rule_supported_vector()` already checks that there are relevant matching rules. The checks require both `CompressM` and `CompressV` to be present to enable the intrinsic. Is it important? Also, it doesn't take `EnableVectorSupport` into account while all other vector intrinsics respect it. >> src/hotspot/share/opto/compile.cpp line 3416: >> >>> 3414: >>> 3415: case Op_ReverseBytesV: >>> 3416: case Op_ReverseV: { >> >> Can you elaborate, please, why it is performed so late in the optimization phase (at the very end during graph reshaping) and not during GVN? > > Its more of a chicken-egg problem here, for masked reverse operation, Reverse IR node is followed by a Blend Node, thus in such a case doing an eager Identity transform in Reverse::Identity will not work, also deferring this to blend may also not work since it could be a non-masked reverse operation, we could have handled it as a special case in inline_vector_nary_operation, but handling such special case in final graph reshaping looked more appropriate. > > https://github.com/openjdk/panama-vector/pull/182#discussion_r845678080 Do you mean it's important to apply the transformation at the right node (pick the right node as the root) and it is hard to make a decision during GVN? ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From duke at openjdk.java.net Thu May 19 00:23:42 2022 From: duke at openjdk.java.net (duke) Date: Thu, 19 May 2022 00:23:42 GMT Subject: Withdrawn: 8283488: AArch64: Improve stack trace accuracy in hs log In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 07:23:34 GMT, Denghui Dong wrote: > Hi team, > > Could I have a review of this patch? > > The native stack trace in hs log is not accurate sometime since we cannot get the accurate `sender sp`, and `sp` is the key to walk stack for compiled frames. > > > frame os::get_sender_for_C_frame(frame* fr) { > return frame(fr->link(), fr->link(), fr->sender_pc()); > } > > > JDK-8277948[1] solved the problem but the premise is that PreserveFramePointer needs to be enabled. > > For x86 platform, we can get the `sender sp` by `fp + 2`, but it does not hold in Aarch64. > > According to "Procedure Call Standard for the Arm? 64-bit Architecture (AArch64)[2]", section "6.2.3 The Frame Pointer" describes that the location of the frame record within a stack frame is not specified. Hence, I cannot get the `sender sp` by adding a constant to `fp`. > > By the way, I found that in the executable I compiled on mac m1, like x86, the frame record is always at the bottom of the stack, but I didn't find a standard specification to prove it. If we can guarantee that this is the case, we can simplify the solution on the mac > > This patch deduces the `sender sp` by decoding the native instructions, this solution is applicable to both Mac and Linux I think. > > At present, I found that there are mainly three patterns as follows: > > > a) > stp x29, x30, [sp, #-N]! > mov x29, sp > => sender sp = fp + N > > b) > sub sp, sp, #N1 > stp x29, x30, [sp, #N2] > add x29, sp, #N2 > => sender sp = fp + (N1 - N2) > > c) > stp Xt1, Xt2, [sp, #-N1]! ; Xt1 is not x29, Xt2 is not x30 > stp x29, x30, [sp, #N2] > add x29, sp, #N2 > => sender sp = fp + (N1 - N2) > > > In addition, special treatment is required for two cases, you can refer to the comments in the code. > > To reduce the impact, deducing the `sender sp` is occurred only when a VM error is reported. > > I'm not sure if this solution is acceptable as it is a bit tricky, any input is appreciated. > > Worth mentioning, the stack trace may still not be accurate sometimes even if this patch is applied. One of the reasons is that `os::is_first_C_frame` will check the `sender fp`. Since `fp` is used as a general register in JIT(When PreserveFramePointer is diabled), it is usually not a reasonable `fp` value in the case of `jit code -> c code`, we may consider modifying the implementation of `os::is_first_C_frame` to apply this case. > > [1] https://bugs.openjdk.java.net/browse/JDK-8277948 > [2] https://github.com/ARM-software/abi-aa/blob/320a56971fdcba282b7001cf4b84abb4fd993131/aapcs64/aapcs64.rst#the-frame-pointer > > Thanks, > Denghui This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7900 From thartmann at openjdk.java.net Thu May 19 06:10:41 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 19 May 2022 06:10:41 GMT Subject: RFR: 8286182: C2: crash with SIGFPE when executing compiled code In-Reply-To: References: Message-ID: <4iJsDLmfjCyFoMXZnwR5H73_CCwokPNfZHLL82XIvtI=.b184d1b7-bdbf-4d7e-87d1-1b888c2675e8@github.com> On Wed, 18 May 2022 15:44:10 GMT, Quan Anh Mai wrote: > This patch backs out the changes made by [JDK-8285390](https://bugs.openjdk.java.net/browse/JDK-8285390) and [JDK-8284742](https://bugs.openjdk.java.net/browse/JDK-8284742) since there are failures due to div nodes floating above their validity checks. > > Thanks. Looks good to me too but the backout should adhere to the process defined here: https://openjdk.java.net/guide/#backing-out-a-change I would suggest "Alternative 2" of 3. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8774 From xxinliu at amazon.com Thu May 19 06:14:59 2022 From: xxinliu at amazon.com (Liu, Xin) Date: Wed, 18 May 2022 23:14:59 -0700 Subject: Mismatched ciMethodData in replay file. Message-ID: <5cd7f04c-c9ad-bbaa-6cba-0616ca9cae9d@amazon.com> hi, I get a weird replay, which was generated by 17.0.3+6-LTS. I don't see relevant code have changed since then, so I think it is still applicable to the tip of HotSpot. A customer shared the replay file with(https://github.com/corretto/corretto-17/issues/57#issuecomment-1130042063) and I am trying to reproduce his failure. it is written from VMError::report_and_die(). One obstacle is that weird entries of ciMethodData. eg. line 14130, It declares that there will 2 non-null oops followed(see '2' after tag 'oops'. however, one only is recorded. ciMethodData kotlin/coroutines/jvm/internal/ContinuationImpl (Lkotlin/coroutines/Continuation;)V 2 21538 orig 80 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 data 26 0x40007 0x402 0x70 0x4e9c 0x70005 0x4d55 0x0 0x7f6a5841c3c0 0xa3 0x7f6a5841c470 0xa4 0xc0003 0x4e9c 0x18 0x110002 0x529e 0x0 0x0 0x0 0x0 0x0 0x0 0x9 0x2 0x6 0x0 oops 2 7 com/example/ProductAttRouter$withRequestLoggingContext$1 methods 0 Another mismatched entry is at line 14203. it says there are 11 oops but only 6 are there. Those mismatched entries leave uninitialized elements of rec->_classes and eventually crash ciReplay::initialize(). Have you seen them before? I can patch up hotspot to handle this mismatch, but I wonder how that happens? ciMethodData::dump_replay_data() iterates _data 2 rounds. The 1st round counts them and second round dumps them. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/ci/ciMethodData.cpp#L728 Is that possible that the underlying data get updated on the fly? This case is kotlin coroutine. I am not sure whether it is same threading environment as classic Java. thanks, --lx From chagedorn at openjdk.java.net Thu May 19 06:58:53 2022 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Thu, 19 May 2022 06:58:53 GMT Subject: RFR: 8286182: C2: crash with SIGFPE when executing compiled code In-Reply-To: References: Message-ID: On Wed, 18 May 2022 15:44:10 GMT, Quan Anh Mai wrote: > This patch backs out the changes made by [JDK-8285390](https://bugs.openjdk.java.net/browse/JDK-8285390) and [JDK-8284742](https://bugs.openjdk.java.net/browse/JDK-8284742) since there are failures due to div nodes floating above their validity checks. > > Thanks. Backout looks good except that you did not remove the test `test/hotspot/jtreg/compiler/integerArithmetic/TestDivision.java` which you've added here: https://github.com/openjdk/jdk/commit/b4a85cdae14eee895a0de2f26a2ffdd62b72bebc#diff-4daba70b215edefe9fd70b24f1e1052a51effdd48a1809e2ce5a06bc21a755c5 It's just a correctness test, so it would be okay to leave it in. But I guess it's better to backout everything. ------------- Changes requested by chagedorn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8774 From stefank at openjdk.java.net Thu May 19 07:31:48 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 19 May 2022 07:31:48 GMT Subject: RFR: 8284273: Early crashes in os::print_context on AArch64 In-Reply-To: References: Message-ID: On Mon, 16 May 2022 21:58:56 GMT, Gerard Ziemski wrote: > Our error reporting mechanism can crash again, while reporting the original crash, because we try to access a possibly bogus memory location, for example while printing a location of memory referred by a CPU register. In such case, we skip over the already reported section (including the one where the secondary crash has occurred). > > This is possible, because we section the error reporting code into sections, called "steps", with a state that retains the information about the last attempted step. > > Here, we are concerned with two particular steps: "printing register info" and "printing registers, top of stack, instructions near pc". In those two steps we report 4 distinct chunks of info: > > 1. registers' raw values (safe) > 2. registers' decoded content (risky) > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) > > The issue here is that on some platforms (Linux aarch64) a single "step" contains 2, 3 and 4, all "risky" sections, so if we crash early in the step, we skip the rest of it and end up never reporting the later sections, ex: > > > STEP("printing register info") > print_register_info > 1. registers' raw values (safe) > > STEP("printing registers, top of stack, instructions near pc") > print_context > 2. registers' decoded content (risky) > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) > > > Other platforms (Linux x64) have a single "step" containing 1, 3 and 4, and another one containing just 2, so that we always get to report section 3, ex: > > > STEP("printing register info") > print_register_info > 2. registers' decoded content (risky) > > STEP("printing registers, top of stack, instructions near pc") > print_context > 1. registers' raw values (safe) > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) > > > This fix proposes to rearrange the STEPS, so that the less risky sections come first and to split the STEP with 3 sections into 2 STEPS, like so: > > > STEP("printing registers") > print_context > 1. registers' raw values (safe) > > STEP("printing register info") > print_register_info > 2. registers' decoded content (risky) > > STEP("printing top of stack, instructions near pc") > print_tos_pc > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) I think this is good. I also think that this could benefit from some renaming: * print_context => print_registers - Because that's the only thing it does. All other context printing has moved to print_tos_pc. * print_register_info => print_registers_detailed (alt. print_registers_locations) ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8736 From aph at openjdk.java.net Thu May 19 07:38:43 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 May 2022 07:38:43 GMT Subject: RFR: 8284273: Early crashes in os::print_context on AArch64 In-Reply-To: References: Message-ID: On Mon, 16 May 2022 21:58:56 GMT, Gerard Ziemski wrote: > Here, we are concerned with two particular steps: "printing register info" and "printing registers, top of stack, instructions near pc". In those two steps we report 4 distinct chunks of info: > > 1. registers' raw values (safe) > > 2. registers' decoded content (risky) > > 3. memory around the "sp" (risky) > > 4. memory around the "pc" (risky) > > > The issue here is that on some platforms (Linux aarch64) a single "step" contains 2, 3 and 4, all "risky" sections, so if we crash early in the step, we skip the rest of it and end up never reporting the later sections, ex: I like this, but I'm curious about something. Couldn't we use `Safefetch` to handle the risky sections? Then we could carry on printing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8736 From aph at openjdk.java.net Thu May 19 07:43:43 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 May 2022 07:43:43 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote: > On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. > > New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. > > Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: > > * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. > * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with > --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse > > Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64_lse.S line 57: > 55: .globl aarch64_atomic_xchg_4_default_impl > 56: .align 5 > 57: prfm pstl1strm, [x0] Do we need these `prfm` with LSE instructions? ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From aph at openjdk.java.net Thu May 19 08:02:48 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 May 2022 08:02:48 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote: > On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. > > New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. > > Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: > > * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. > * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with > --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse > > Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. This looks reasonable enough, but I take it that this would create an OpenJDK build that would not run on AArch64 systems without LSE instructions. Might it not be a better idea to build with outline-atomics, and use them in OpenJDK? That would also solve your problem, and we wouldn't have AArch64 Linux OpenJDK binaries which don't work on all systems. Note that atomic_bsd_aarch64.hpp already does this. I'm also concerned about code rot with options like this one. atomic_linux_aarch64_lse.S would not be tested in any standard configuration. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From kevinw at openjdk.java.net Thu May 19 08:43:45 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 08:43:45 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. src/jdk.sctp/share/classes/com/sun/nio/sctp/ShutdownNotification.java line 28: > 26: > 27: /** > 28: * Notification emitted when a peers shutdowns the association. Maybe: "...when a peer shuts down an association." (could be "shuts down the association" if there is only ever one, but using "an" looks safe) ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From aph at openjdk.java.net Thu May 19 08:47:42 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 May 2022 08:47:42 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Thu, 19 May 2022 07:59:56 GMT, Andrew Haley wrote: > This looks reasonable enough, but I take it that this would create an OpenJDK build that would not run on AArch64 systems without LSE instructions. Forget that, we already do so with extra-cflags. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From ngasson at openjdk.java.net Thu May 19 08:47:42 2022 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 19 May 2022 08:47:42 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote: > On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. > > New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. > > Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: > > * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. > * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with > --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse > > Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. What's the advantage of defining the new hardlse VM feature over using the existing `__ARM_FEATURE_ATOMICS` preprocessor symbol? Both GCC and Clang will define that with an appropriate `-march` value, which you're passing to configure anyway. You could then conditionally emit the LSE instructions in atomic_linux_aarch64.S based on that. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From shade at openjdk.java.net Thu May 19 08:48:53 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 19 May 2022 08:48:53 GMT Subject: RFR: 8286897: Loom: Cleanup x86_64 StubGenerator [v3] In-Reply-To: References: <1CsFzv8wOJwBF2f7wET15LwMZoY-mX2wKXq5bGibrzM=.cd19bdbf-1a84-4dd0-beb4-a3d60763854e@github.com> Message-ID: On Wed, 18 May 2022 06:05:50 GMT, Aleksey Shipilev wrote: >> During x86_32 porting, I ended up rewriting the copy of x86_64 StubGenerator significantly to make it more streamlined. The original x86_64 StubGenerator should enjoy the similar streamlining, since it would likely to be the template for many other architectures. >> >> There should be no behavior changes, except one small one. For some weird reason, the `__ movptr(c_rarg1, rsp);` in `generate_cont_doYield` used to be much earlier, between `start` and `the_pc`. I don't believe that's part of the frame setup. It looks like a copy-paste glitch from `generate_throw_exception`. So I just moved it here. No tests complain about this move. >> >> The rest of the changes themselves should speak for themselves, but here is a brief list: >> - no need for `assert_asm` macros, instead do the inline checks, like the rest of Hotspot and Loom code >> - `_masm` and `masm` shadowing can just use whatever is currently defined as `__` >> - more strong cohesion between `post_call_nop`, its associated PC and its oopmap >> - consistently use `call_VM_leaf` that only takes the number of arguments, as we are doing argument pushes ourselves anyway; >> - for many moves, it is easier to use `ptr` flavors (e.g. `testq` -> `testptr`) to ease copy-pasting to other arches; >> - `generate_cont_thaw` should just do the `enabled()` check and carry the `StubCodeMark`, like other stubs do; >> - inline comments are reflowed to block-like comments, matching the usual style of stub code; >> - labels are prefixed with `L_` for clarity (used in some places in Hotspot); >> - `jfr_prolog` and `jfr_epilog` are used only once and do not carry their weight; >> - `continuation_*` are documented a bit better; >> >> Additional testing: >> - [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual` >> - [x] Linux x86_64 fastdebug, `serviceability/jvmti` >> - [x] Linux x86_64 fastdebug, `runtime/vthread` >> - [x] Linux x86_64 fastdebug, `tier1` >> - [x] Linux x86_64 fastdebug, `tier2` >> - [x] Linux x86_64 fastdebug, `tier3` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback I am integrating now to provide cleaner base for porting. ------------- PR: https://git.openjdk.java.net/jdk/pull/8755 From shade at openjdk.java.net Thu May 19 08:48:55 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 19 May 2022 08:48:55 GMT Subject: Integrated: 8286897: Loom: Cleanup x86_64 StubGenerator In-Reply-To: <1CsFzv8wOJwBF2f7wET15LwMZoY-mX2wKXq5bGibrzM=.cd19bdbf-1a84-4dd0-beb4-a3d60763854e@github.com> References: <1CsFzv8wOJwBF2f7wET15LwMZoY-mX2wKXq5bGibrzM=.cd19bdbf-1a84-4dd0-beb4-a3d60763854e@github.com> Message-ID: On Tue, 17 May 2022 16:39:55 GMT, Aleksey Shipilev wrote: > During x86_32 porting, I ended up rewriting the copy of x86_64 StubGenerator significantly to make it more streamlined. The original x86_64 StubGenerator should enjoy the similar streamlining, since it would likely to be the template for many other architectures. > > There should be no behavior changes, except one small one. For some weird reason, the `__ movptr(c_rarg1, rsp);` in `generate_cont_doYield` used to be much earlier, between `start` and `the_pc`. I don't believe that's part of the frame setup. It looks like a copy-paste glitch from `generate_throw_exception`. So I just moved it here. No tests complain about this move. > > The rest of the changes themselves should speak for themselves, but here is a brief list: > - no need for `assert_asm` macros, instead do the inline checks, like the rest of Hotspot and Loom code > - `_masm` and `masm` shadowing can just use whatever is currently defined as `__` > - more strong cohesion between `post_call_nop`, its associated PC and its oopmap > - consistently use `call_VM_leaf` that only takes the number of arguments, as we are doing argument pushes ourselves anyway; > - for many moves, it is easier to use `ptr` flavors (e.g. `testq` -> `testptr`) to ease copy-pasting to other arches; > - `generate_cont_thaw` should just do the `enabled()` check and carry the `StubCodeMark`, like other stubs do; > - inline comments are reflowed to block-like comments, matching the usual style of stub code; > - labels are prefixed with `L_` for clarity (used in some places in Hotspot); > - `jfr_prolog` and `jfr_epilog` are used only once and do not carry their weight; > - `continuation_*` are documented a bit better; > > Additional testing: > - [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual` > - [x] Linux x86_64 fastdebug, `serviceability/jvmti` > - [x] Linux x86_64 fastdebug, `runtime/vthread` > - [x] Linux x86_64 fastdebug, `tier1` > - [x] Linux x86_64 fastdebug, `tier2` > - [x] Linux x86_64 fastdebug, `tier3` This pull request has now been integrated. Changeset: 47500b24 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/47500b2429c8e09f322ec3ff95ff09293db26a9a Stats: 255 lines in 3 files changed: 104 ins; 69 del; 82 mod 8286897: Loom: Cleanup x86_64 StubGenerator Reviewed-by: rpressler, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/8755 From kevinw at openjdk.java.net Thu May 19 08:50:49 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 08:50:49 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. src/jdk.jdi/share/classes/com/sun/jdi/ClassType.java line 348: > 346: > 347: /** > 348: * Returns the single non-abstract {@link Method} visible from I would think "Returns a single ..." because the implementation returns the first match it finds, from possibly many. ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From aph at openjdk.java.net Thu May 19 08:54:56 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 May 2022 08:54:56 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote: > On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. > > New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. > > Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: > > * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. > * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with > --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse > > Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. There is another way to achieve what you want, which is less disruptive and I believe more useful. I just did this: `cp src/hotspot/os_cpu/bsd_aarch64/atomic_bsd_aarch64.hpp src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp` and built OpenJDK with your configury, and it achieves exactly what you want: a HotSpot that uses LSE throughout. If you, therefore, add an option to build with host compiler's atomics, just like BSD does, you'll get what you need with almost no code changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From aph at openjdk.java.net Thu May 19 08:54:59 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 May 2022 08:54:59 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Thu, 19 May 2022 08:43:55 GMT, Nick Gasson wrote: > What's the advantage of defining the new hardlse VM feature over using the existing `__ARM_FEATURE_ATOMICS` preprocessor symbol? Both GCC and Clang will define that with an appropriate `-march` value, which you're passing to configure anyway. You could then conditionally emit the LSE instructions in atomic_linux_aarch64.S based on that. That's not a bad idea either. In fact, maybe I prefer it to my own suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From njian at openjdk.java.net Thu May 19 08:57:07 2022 From: njian at openjdk.java.net (Ningsheng Jian) Date: Thu, 19 May 2022 08:57:07 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v6] In-Reply-To: <-lS_36hGarJvCL26lgWyXJd-e2SuLD9g1wWL5PuoLXI=.5ddb3b74-493f-41df-8544-8a963c66fc5d@github.com> References: <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com> <-lS_36hGarJvCL26lgWyXJd-e2SuLD9g1wWL5PuoLXI=.5ddb3b74-493f-41df-8544-8a963c66fc5d@github.com> Message-ID: On Wed, 18 May 2022 23:22:42 GMT, Vladimir Ivanov wrote: > Interesting. But AArch64 code does cover vector cases which just adds confusion. `UsePopCountInsturction` is always true in AArch64. @XiaohongGong removed the `predicate` in aarch64 rules, and I think we can even remove the option check in match_rule_supported(). ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From kevinw at openjdk.java.net Thu May 19 09:02:49 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 09:02:49 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. src/hotspot/share/opto/graphKit.cpp line 3626: > 3624: // The optional arguments are for specialized use by intrinsics: > 3625: // - If 'extra_slow_test' if not null is an extra condition for the slow-path. > 3626: // - If 'return_size_val', report the total object size to the caller. "reports the total" ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From xgong at openjdk.java.net Thu May 19 09:06:17 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 19 May 2022 09:06:17 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v6] In-Reply-To: References: <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com> <-lS_36hGarJvCL26lgWyXJd-e2SuLD9g1wWL5PuoLXI=.5ddb3b74-493f-41df-8544-8a963c66fc5d@github.com> Message-ID: On Thu, 19 May 2022 08:53:31 GMT, Ningsheng Jian wrote: >>> LUT should be generated only if UsePopCountInsturction is false >> >> Should there be `!UsePopCountInsturction` check then? >> >>> restrict the scope of flag to only scalar popcount operation >> >> Interesting. But AArch64 code does cover vector cases which just adds confusion. > >> Interesting. But AArch64 code does cover vector cases which just adds confusion. > > `UsePopCountInsturction` is always true in AArch64. @XiaohongGong removed the `predicate` in aarch64 rules, and I think we can even remove the option check in match_rule_supported(). Ok , I will remove the check for it. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From kevinw at openjdk.java.net Thu May 19 09:09:50 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 09:09:50 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. src/hotspot/share/interpreter/bytecodeUtils.cpp line 186: > 184: static const int _max_cause_detail = 5; > 185: > 186: // Merges the stack the given bci with the given stack. If there "...the stack at the given bci..." ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From kevinw at openjdk.java.net Thu May 19 09:27:55 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 09:27:55 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: <02e6mwqZ3ihNyJb4lBK-5WeIGMfiLMj3I8LpJPv4i8o=.3c56077b-54f0-4c4e-b031-5a000b9ea887@github.com> On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. src/hotspot/share/cds/filemap.cpp line 1914: > 1912: > 1913: // the current value of the pointers to be patched must be within this > 1914: // range (i.e., must be between the requested base address, and the of the current archive). "the of the" ? Maybe "..and the address of the current archive", or maybe it was a typo for "and that of the current archive". ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From kevinw at openjdk.java.net Thu May 19 09:35:42 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 09:35:42 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com> On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 84: > 82: > 83: /** > 84: * Create a Zip file that will result in an Zip64 Extra (EXT) header "result in a Zip64..." test/jdk/sun/security/tools/jarsigner/OldSig.java line 32: > 30: /* > 31: * See also PreserveRawManifestEntryAndDigest.java for tests with arbitrarily > 32: * formatted individual sections in addition the main attributes tested "in addition to the..." ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From shade at openjdk.java.net Thu May 19 09:36:47 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 19 May 2022 09:36:47 GMT Subject: RFR: 8286944: Loom: Common ContinuationEntry cookie handling In-Reply-To: <3A1mwN4h3ZuTYYUl9bnXs7uEw32KNX3mmDU0XeGSPn0=.236ce636-4201-4d96-bf30-89256374c8cc@github.com> References: <3A1mwN4h3ZuTYYUl9bnXs7uEw32KNX3mmDU0XeGSPn0=.236ce636-4201-4d96-bf30-89256374c8cc@github.com> Message-ID: <1eaJPhJ_GApLEP05in2rA3S09gN5IhqS4u9PEDlL8AI=.e3a2abca-31c6-4ef4-a085-47e46844fdce@github.com> On Wed, 18 May 2022 09:46:43 GMT, Aleksey Shipilev wrote: > Platform-specific code injects the cookie to the head of ContinuationEntry. The value for this cookie is hard-coded in platform-specific code, which is fragile. It would be better to common the cookie handling a bit to ease porting. In fact, I have spent an hour trying to debug a thing where I mistyped a cookie value in x86_32 code, hence my interest. > > Additional testing: > - [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual` > - [x] Linux AArch64 fastdebug, `java/lang/Thread/virtual` Thanks for reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/8762 From shade at openjdk.java.net Thu May 19 09:38:46 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 19 May 2022 09:38:46 GMT Subject: Integrated: 8286944: Loom: Common ContinuationEntry cookie handling In-Reply-To: <3A1mwN4h3ZuTYYUl9bnXs7uEw32KNX3mmDU0XeGSPn0=.236ce636-4201-4d96-bf30-89256374c8cc@github.com> References: <3A1mwN4h3ZuTYYUl9bnXs7uEw32KNX3mmDU0XeGSPn0=.236ce636-4201-4d96-bf30-89256374c8cc@github.com> Message-ID: <7bLaLES5ThnCSeOqq2rdV5d_75VF5i0OrelqEVLfx2s=.9f446c64-c052-41d8-99b6-0c6790a2b06a@github.com> On Wed, 18 May 2022 09:46:43 GMT, Aleksey Shipilev wrote: > Platform-specific code injects the cookie to the head of ContinuationEntry. The value for this cookie is hard-coded in platform-specific code, which is fragile. It would be better to common the cookie handling a bit to ease porting. In fact, I have spent an hour trying to debug a thing where I mistyped a cookie value in x86_32 code, hence my interest. > > Additional testing: > - [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual` > - [x] Linux AArch64 fastdebug, `java/lang/Thread/virtual` This pull request has now been integrated. Changeset: 6e386669 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/6e386669e3832cdf412bc6d485aa358e8811483f Stats: 12 lines in 3 files changed: 8 ins; 1 del; 3 mod 8286944: Loom: Common ContinuationEntry cookie handling Reviewed-by: rbackman, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/8762 From kevinw at openjdk.java.net Thu May 19 09:41:57 2022 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 19 May 2022 09:41:57 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. OK. I started with serviceability but then went through everything as it's hard to record what you have/haven't seen in these long reviews. test/jdk/java/net/InterfaceAddress/Equals.java line 81: > 79: /** > 80: * Returns an InterfaceAddress instance with its fields set the values > 81: * specificed. probably a typo for "set to the values specified." ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.java.net/jdk/pull/8768 From shade at openjdk.java.net Thu May 19 09:49:54 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 19 May 2022 09:49:54 GMT Subject: RFR: 8286956: Loom: Define test groups for development/porting use In-Reply-To: References: Message-ID: On Wed, 18 May 2022 11:10:58 GMT, Aleksey Shipilev wrote: > It would be beneficial to bring over the Loom-specific test groups from the loom repo to aid development/porting work. > > https://github.com/openjdk/loom/blob/fibers/test/jdk/TEST.groups#L97-L108 > https://github.com/openjdk/loom/blob/6f42923b3342e41d95b262733205283068802b40/test/hotspot/jtreg/TEST.groups#L111-L125 > > I had to drop `jdk/incubator/concurrent` from JDK definition, because there are no tests in that folder and tests break. > > Additional testing: > - [x] Linux x86_64 fastdebug `hotspot_loom jdk_loom` > - [x] Linux AArch64 fastdebug `hotspot_loom jdk_loom` Thanks! Any other comments? I'd like Loom porters to have it sooner. ------------- PR: https://git.openjdk.java.net/jdk/pull/8765 From dchuyko at openjdk.java.net Thu May 19 10:08:40 2022 From: dchuyko at openjdk.java.net (Dmitry Chuyko) Date: Thu, 19 May 2022 10:08:40 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote: > On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. > > New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. > > Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: > > * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. > * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with > --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse > > Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. Thanks a lot for the great comments. Both suggestions make sense to me. The resulting code can be driven by the compiler flags in the configuration. As I see it: 1. To have a single compile time implementation based on __atomic_add_fetch intrinsics (no .S file at all). 2. In generated part wrap put 'if (UseLSE)' blocks under '#ifdef __ARM_FEATURE_ATOMICS'. Some concerns: 1. It should work at least for Clang and GCC but still will require checking all os-cpu/compiler variants. 2. Windows-aarch64 is the most worrisome. 3. The way of configuration is different for different compilers, not a problem though if we need an optimized build or to make rr work. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From duke at openjdk.java.net Thu May 19 12:25:57 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Thu, 19 May 2022 12:25:57 GMT Subject: RFR: 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call [v2] In-Reply-To: References: Message-ID: <21-CzRj31QLh2NakpUtbdmVaM0S8Wa2HZkyB0z1tXK8=.14b957e0-7cd2-45ca-8356-c7aa6e461d18@github.com> On Thu, 5 May 2022 22:49:43 GMT, Evgeny Astigeevich wrote: >> `MacroAssembler::trampoline_call` is for generating calls of targets which are inside CodeCache and can have relocInfo types: `runtime_call_type`, `opt_virtual_call_type`, `static_call_type` or `virtual_call_type`. >> This PR updates the description of the function and adds additional asserts. >> Tested a fastdebug build: >> - `gtest`: Passed >> - `tier1`: Passed > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Fix assert message Hi Andrew, JFYI > However, I do not think that any current user of trampoline_call() uses the insts_mark for anything, and it could usefully be removed as part of a cleanup. I have removed this. There were assert crashes in fastdebug because trampoline_call must be connected with CompiledStaticCall::emit_to_interp_stub to have correct relocInfo records. I fixed this. > BTW, we have a new trampoline_call1: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp#L1101. This is a surprise from the project Loom. I'll try to handle it as well. I am currently removing `trampoline_call1`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From stuefe at openjdk.java.net Thu May 19 13:57:49 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 19 May 2022 13:57:49 GMT Subject: RFR: 8284273: Early crashes in os::print_context on AArch64 In-Reply-To: References: Message-ID: On Mon, 16 May 2022 21:58:56 GMT, Gerard Ziemski wrote: > Our error reporting mechanism can crash again, while reporting the original crash, because we try to access a possibly bogus memory location, for example while printing a location of memory referred by a CPU register. In such case, we skip over the already reported section (including the one where the secondary crash has occurred). > > This is possible, because we section the error reporting code into sections, called "steps", with a state that retains the information about the last attempted step. > > Here, we are concerned with two particular steps: "printing register info" and "printing registers, top of stack, instructions near pc". In those two steps we report 4 distinct chunks of info: > > 1. registers' raw values (safe) > 2. registers' decoded content (risky) > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) > > The issue here is that on some platforms (Linux aarch64) a single "step" contains 2, 3 and 4, all "risky" sections, so if we crash early in the step, we skip the rest of it and end up never reporting the later sections, ex: > > > STEP("printing register info") > print_register_info > 1. registers' raw values (safe) > > STEP("printing registers, top of stack, instructions near pc") > print_context > 2. registers' decoded content (risky) > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) > > > Other platforms (Linux x64) have a single "step" containing 1, 3 and 4, and another one containing just 2, so that we always get to report section 3, ex: > > > STEP("printing register info") > print_register_info > 2. registers' decoded content (risky) > > STEP("printing registers, top of stack, instructions near pc") > print_context > 1. registers' raw values (safe) > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) > > > This fix proposes to rearrange the STEPS, so that the less risky sections come first and to split the STEP with 3 sections into 2 STEPS, like so: > > > STEP("printing registers") > print_context > 1. registers' raw values (safe) > > STEP("printing register info") > print_register_info > 2. registers' decoded content (risky) > > STEP("printing top of stack, instructions near pc") > print_tos_pc > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) Hi Gerard, I like this, thank you for choosing this route for the patch. My only nit would be that `os::print_tos_pc` isn't terribly clear, I would prefer a longer but more descriptive name. As Andrew wrote, a follow-up could be to harden print_location and similar places by using SafeFetch. Cheers, Thomas src/hotspot/share/utilities/vmError.cpp line 896: > 894: ResourceMark rm(_thread); > 895: os::print_register_info(st, _context); > 896: st->cr(); Unrelated to your patch, but it would be nice if we could get rid of RA usage here, since RA may malloc and malloc is not signal safe. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8736 From stuefe at openjdk.java.net Thu May 19 13:57:49 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 19 May 2022 13:57:49 GMT Subject: RFR: 8284273: Early crashes in os::print_context on AArch64 In-Reply-To: References: Message-ID: <9goDzX-O9xQQngKYZ-tAgz0NuYCtG7ToCYP5nuc51vc=.1c49236e-3a74-4db9-ad35-5ddab8b3b947@github.com> On Thu, 19 May 2022 07:35:16 GMT, Andrew Haley wrote: > I like this, but I'm curious about something. Couldn't we use `Safefetch` to handle the risky sections? Then we could carry on printing. Yes, and we should. But splitting larger steps into smaller ones makes sense too, since code tends to bitrot and one never can be sure to cover all places with SafeFetch. ------------- PR: https://git.openjdk.java.net/jdk/pull/8736 From tsteele at openjdk.java.net Thu May 19 14:15:23 2022 From: tsteele at openjdk.java.net (Tyler Steele) Date: Thu, 19 May 2022 14:15:23 GMT Subject: RFR: 8286891: thread_local causes undefined symbol error with XL C Message-ID: When using XLClang++ to compile a `thread_local` struct with a destructor, a compiler bug is exposed that results in a missing constructor and a linker error. Adding the missing constructor solves this issue. CHnges - Builds on AIX (previously broken) ------------- Commit messages: - XL C compiler bug workaround Changes: https://git.openjdk.java.net/jdk/pull/8754/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8754&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286891 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8754.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8754/head:pull/8754 PR: https://git.openjdk.java.net/jdk/pull/8754 From tsteele at openjdk.java.net Thu May 19 14:15:24 2022 From: tsteele at openjdk.java.net (Tyler Steele) Date: Thu, 19 May 2022 14:15:24 GMT Subject: RFR: 8286891: thread_local causes undefined symbol error with XL C In-Reply-To: References: Message-ID: On Tue, 17 May 2022 15:56:28 GMT, Tyler Steele wrote: > When using XLClang++ to compile a `thread_local` struct with a destructor, a compiler bug is exposed that results in a missing constructor and a linker error. > > Adding the missing constructor solves this issue. > CHnges > - Builds on AIX (previously broken) @MBaesken fyi ------------- PR: https://git.openjdk.java.net/jdk/pull/8754 From mdoerr at openjdk.java.net Thu May 19 14:31:07 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 19 May 2022 14:31:07 GMT Subject: RFR: 8286891: thread_local causes undefined symbol error with XL C In-Reply-To: References: Message-ID: On Tue, 17 May 2022 15:56:28 GMT, Tyler Steele wrote: > When using XLClang++ to compile a `thread_local` struct with a destructor, a compiler bug is exposed that results in a missing constructor and a linker error. > > Adding the missing constructor solves this issue. > CHnges > - Builds on AIX (previously broken) `#` should usually be at the beginning of the line. Please also add a comment why this is needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8754 From gziemski at openjdk.java.net Thu May 19 14:33:51 2022 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 19 May 2022 14:33:51 GMT Subject: RFR: 8284273: Early crashes in os::print_context on AArch64 In-Reply-To: References: Message-ID: On Mon, 16 May 2022 21:58:56 GMT, Gerard Ziemski wrote: > Our error reporting mechanism can crash again, while reporting the original crash, because we try to access a possibly bogus memory location, for example while printing a location of memory referred by a CPU register. In such case, we skip over the already reported section (including the one where the secondary crash has occurred). > > This is possible, because we section the error reporting code into sections, called "steps", with a state that retains the information about the last attempted step. > > Here, we are concerned with two particular steps: "printing register info" and "printing registers, top of stack, instructions near pc". In those two steps we report 4 distinct chunks of info: > > 1. registers' raw values (safe) > 2. registers' decoded content (risky) > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) > > The issue here is that on some platforms (Linux aarch64) a single "step" contains 2, 3 and 4, all "risky" sections, so if we crash early in the step, we skip the rest of it and end up never reporting the later sections, ex: > > > STEP("printing register info") > print_register_info > 1. registers' raw values (safe) > > STEP("printing registers, top of stack, instructions near pc") > print_context > 2. registers' decoded content (risky) > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) > > > Other platforms (Linux x64) have a single "step" containing 1, 3 and 4, and another one containing just 2, so that we always get to report section 3, ex: > > > STEP("printing register info") > print_register_info > 2. registers' decoded content (risky) > > STEP("printing registers, top of stack, instructions near pc") > print_context > 1. registers' raw values (safe) > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) > > > This fix proposes to rearrange the STEPS, so that the less risky sections come first and to split the STEP with 3 sections into 2 STEPS, like so: > > > STEP("printing registers") > print_context > 1. registers' raw values (safe) > > STEP("printing register info") > print_register_info > 2. registers' decoded content (risky) > > STEP("printing top of stack, instructions near pc") > print_tos_pc > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) Thank you Andrew, Stefan, Thomas for the feedback! ------------- PR: https://git.openjdk.java.net/jdk/pull/8736 From gziemski at openjdk.java.net Thu May 19 14:33:50 2022 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 19 May 2022 14:33:50 GMT Subject: RFR: 8284273: Early crashes in os::print_context on AArch64 In-Reply-To: <9goDzX-O9xQQngKYZ-tAgz0NuYCtG7ToCYP5nuc51vc=.1c49236e-3a74-4db9-ad35-5ddab8b3b947@github.com> References: <9goDzX-O9xQQngKYZ-tAgz0NuYCtG7ToCYP5nuc51vc=.1c49236e-3a74-4db9-ad35-5ddab8b3b947@github.com> Message-ID: On Thu, 19 May 2022 13:54:32 GMT, Thomas Stuefe wrote: > > I like this, but I'm curious about something. Couldn't we use `Safefetch` to handle the risky sections? Then we could carry on printing. > > Yes, and we should. But splitting larger steps into smaller ones makes sense too, since code tends to bitrot and one never can be sure to cover all places with SafeFetch. Thank you Thomas for chiming in. Thomas mentioned using `Safefetch` in his pre-review of https://github.com/openjdk/jdk/pull/8571 but I thought it would be better to leave that for a follow-up as there are a few issues of interest here. I understand that this fix doesn't solve everything, but it's a step in the right direction. There will most certainly be more work in this area. ------------- PR: https://git.openjdk.java.net/jdk/pull/8736 From aph at openjdk.java.net Thu May 19 14:39:54 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 May 2022 14:39:54 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote: > On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. > > New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. > > Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: > > * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. > * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with > --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse > > Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. I literally just tried this: .text #ifdef __ARM_FEATURE_ATOMICS .globl aarch64_atomic_fetch_add_8_default_impl .align 5 aarch64_atomic_fetch_add_8_default_impl: prfm pstl1strm, [x0] 0: ldaddal x1, x2, [x0] dmb ish mov x0, x2 with the obvious `#else` and `#endif` around the non-LSE part and $ objdump -d /home/aph/theRealAph-jdk/build/linux-aarch64-server-slowdebug/hotspot/variant-server/libjvm/objs/atomic_linux_aarch64.o | head -40 ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From aph at openjdk.java.net Thu May 19 14:39:56 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 May 2022 14:39:56 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Thu, 19 May 2022 10:05:41 GMT, Dmitry Chuyko wrote: > Some concerns: > > 1. It should work at least for Clang and GCC but still will require checking all os-cpu/compiler variants. Really, no. Don't think that way. Just do Linux for now, and throw it over the wall for Windows people. > 3. The way of configuration is different for different compilers, not a problem though if we need an optimized build or to make rr work. See above. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From aph at openjdk.java.net Thu May 19 14:53:49 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 May 2022 14:53:49 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote: > On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. > > New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. > > Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: > > * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. > * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with > --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse > > Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64_lse.S line 30: > 28: aarch64_atomic_fetch_add_8_default_impl: > 29: prfm pstl1strm, [x0] > 30: 0: ldaddal x1, x2, [x0] Suggestion: ldaddal x1, x2, [x0] You don't need the `0:`label. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From aph at openjdk.java.net Thu May 19 14:57:55 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 May 2022 14:57:55 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Thu, 19 May 2022 14:36:28 GMT, Andrew Haley wrote: > > Some concerns: > > ``` > > 1. It should work at least for Clang and GCC but still will require checking all os-cpu/compiler variants. Non-Linux systems don't use this stuff at all, so don't worry about it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From xuelei at openjdk.java.net Thu May 19 14:58:48 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 19 May 2022 14:58:48 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. The security/crypto parts look good to me. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8768 From xuelei at openjdk.java.net Thu May 19 14:58:49 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 19 May 2022 14:58:49 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com> References: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com> Message-ID: On Thu, 19 May 2022 09:31:07 GMT, Kevin Walls wrote: >> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? >> >> Also, I fixed a couple of spelling mistakes. > > test/jdk/sun/security/tools/jarsigner/OldSig.java line 32: > >> 30: /* >> 31: * See also PreserveRawManifestEntryAndDigest.java for tests with arbitrarily >> 32: * formatted individual sections in addition the main attributes tested > > "in addition to the..." +1. ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From duke at openjdk.java.net Thu May 19 15:29:29 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Thu, 19 May 2022 15:29:29 GMT Subject: RFR: 8286182: C2: crash with SIGFPE when executing compiled code [v2] In-Reply-To: References: Message-ID: > This patch backs out the changes made by [JDK-8285390](https://bugs.openjdk.java.net/browse/JDK-8285390) and [JDK-8284742](https://bugs.openjdk.java.net/browse/JDK-8284742) since there are failures due to div nodes floating above their validity checks. > > Thanks. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: Remove added test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8774/files - new: https://git.openjdk.java.net/jdk/pull/8774/files/bf963e6b..1e2f12d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8774&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8774&range=00-01 Stats: 99 lines in 1 file changed: 0 ins; 99 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8774.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8774/head:pull/8774 PR: https://git.openjdk.java.net/jdk/pull/8774 From jbhateja at openjdk.java.net Thu May 19 15:37:29 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 19 May 2022 15:37:29 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v3] In-Reply-To: References: <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com> Message-ID: On Wed, 18 May 2022 23:28:22 GMT, Vladimir Ivanov wrote: >> Its more of a chicken-egg problem here, for masked reverse operation, Reverse IR node is followed by a Blend Node, thus in such a case doing an eager Identity transform in Reverse::Identity will not work, also deferring this to blend may also not work since it could be a non-masked reverse operation, we could have handled it as a special case in inline_vector_nary_operation, but handling such special case in final graph reshaping looked more appropriate. >> >> https://github.com/openjdk/panama-vector/pull/182#discussion_r845678080 > > Do you mean it's important to apply the transformation at the right node (pick the right node as the root) and it is hard to make a decision during GVN? Yes, that what I meant. ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From jbhateja at openjdk.java.net Thu May 19 15:41:19 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 19 May 2022 15:41:19 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v3] In-Reply-To: References: <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com> Message-ID: On Wed, 18 May 2022 23:35:54 GMT, Vladimir Ivanov wrote: >> It was an attempt to facilitate in-lining of these APIs over targets which do not intrinsify them. I agree its not a generic fix since three APIs are piggybacking on same entry point and without the knowledge of opcode it will be inappropriate to take any call at this place, lazy intrinsification gives opportunity for some of the predications to concertize as compilation happens under closed world assumptions. > > Still not clear why the code is shaped the way it is. > > `Matcher::match_rule_supported_vector()` already checks that there are relevant matching rules. > > The checks require both `CompressM` and `CompressV` to be present to enable the intrinsic. Is it important? > > Also, it doesn't take `EnableVectorSupport` into account while all other vector intrinsics respect it. Yes, the code was modified to accommodate your comments. https://github.com/openjdk/jdk/pull/8425/files#diff-a9dd7e411772c1ee37b54c5ab868a01fe82af905758350f0ba1c370f422c3fe6R718 ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From duke at openjdk.java.net Thu May 19 16:02:50 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Thu, 19 May 2022 16:02:50 GMT Subject: RFR: 8286182: [BACKOUT] x86: Handle integral division overflow during parsing [v2] In-Reply-To: References: Message-ID: <-aUyz0xzTc007JIqF5ofVTUBynH6Q32BR3OD9T7qP28=.2e6a1b38-d36a-4d54-a570-03806a4cc5cb@github.com> On Thu, 19 May 2022 15:29:29 GMT, Quan Anh Mai wrote: >> This patch backs out the changes made by [JDK-8285390](https://bugs.openjdk.java.net/browse/JDK-8285390) and [JDK-8284742](https://bugs.openjdk.java.net/browse/JDK-8284742) since there are failures due to div nodes floating above their validity checks. >> >> Thanks. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > Remove added test I have backed out also the division test and created JBS issues as instructed in the developer guide. Hope I have done it correctly. Thanks a lot for your reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/8774 From gziemski at openjdk.java.net Thu May 19 16:20:55 2022 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 19 May 2022 16:20:55 GMT Subject: RFR: 8284273: Early crashes in os::print_context on AArch64 In-Reply-To: References: Message-ID: On Mon, 16 May 2022 21:58:56 GMT, Gerard Ziemski wrote: > Our error reporting mechanism can crash again, while reporting the original crash, because we try to access a possibly bogus memory location, for example while printing a location of memory referred by a CPU register. In such case, we skip over the already reported section (including the one where the secondary crash has occurred). > > This is possible, because we section the error reporting code into sections, called "steps", with a state that retains the information about the last attempted step. > > Here, we are concerned with two particular steps: "printing register info" and "printing registers, top of stack, instructions near pc". In those two steps we report 4 distinct chunks of info: > > 1. registers' raw values (safe) > 2. registers' decoded content (risky) > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) > > The issue here is that on some platforms (Linux aarch64) a single "step" contains 2, 3 and 4, all "risky" sections, so if we crash early in the step, we skip the rest of it and end up never reporting the later sections, ex: > > > STEP("printing register info") > print_register_info > 1. registers' raw values (safe) > > STEP("printing registers, top of stack, instructions near pc") > print_context > 2. registers' decoded content (risky) > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) > > > Other platforms (Linux x64) have a single "step" containing 1, 3 and 4, and another one containing just 2, so that we always get to report section 3, ex: > > > STEP("printing register info") > print_register_info > 2. registers' decoded content (risky) > > STEP("printing registers, top of stack, instructions near pc") > print_context > 1. registers' raw values (safe) > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) > > > This fix proposes to rearrange the STEPS, so that the less risky sections come first and to split the STEP with 3 sections into 2 STEPS, like so: > > > STEP("printing registers") > print_context > 1. registers' raw values (safe) > > STEP("printing register info") > print_register_info > 2. registers' decoded content (risky) > > STEP("printing top of stack, instructions near pc") > print_tos_pc > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) Filed https://bugs.openjdk.java.net/browse/JDK-8287037 to track the follow up. ------------- PR: https://git.openjdk.java.net/jdk/pull/8736 From gziemski at openjdk.java.net Thu May 19 16:23:56 2022 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 19 May 2022 16:23:56 GMT Subject: Integrated: 8284273: Early crashes in os::print_context on AArch64 In-Reply-To: References: Message-ID: On Mon, 16 May 2022 21:58:56 GMT, Gerard Ziemski wrote: > Our error reporting mechanism can crash again, while reporting the original crash, because we try to access a possibly bogus memory location, for example while printing a location of memory referred by a CPU register. In such case, we skip over the already reported section (including the one where the secondary crash has occurred). > > This is possible, because we section the error reporting code into sections, called "steps", with a state that retains the information about the last attempted step. > > Here, we are concerned with two particular steps: "printing register info" and "printing registers, top of stack, instructions near pc". In those two steps we report 4 distinct chunks of info: > > 1. registers' raw values (safe) > 2. registers' decoded content (risky) > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) > > The issue here is that on some platforms (Linux aarch64) a single "step" contains 2, 3 and 4, all "risky" sections, so if we crash early in the step, we skip the rest of it and end up never reporting the later sections, ex: > > > STEP("printing register info") > print_register_info > 1. registers' raw values (safe) > > STEP("printing registers, top of stack, instructions near pc") > print_context > 2. registers' decoded content (risky) > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) > > > Other platforms (Linux x64) have a single "step" containing 1, 3 and 4, and another one containing just 2, so that we always get to report section 3, ex: > > > STEP("printing register info") > print_register_info > 2. registers' decoded content (risky) > > STEP("printing registers, top of stack, instructions near pc") > print_context > 1. registers' raw values (safe) > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) > > > This fix proposes to rearrange the STEPS, so that the less risky sections come first and to split the STEP with 3 sections into 2 STEPS, like so: > > > STEP("printing registers") > print_context > 1. registers' raw values (safe) > > STEP("printing register info") > print_register_info > 2. registers' decoded content (risky) > > STEP("printing top of stack, instructions near pc") > print_tos_pc > 3. memory around the "sp" (risky) > 4. memory around the "pc" (risky) This pull request has now been integrated. Changeset: 83cec4b6 Author: Gerard Ziemski URL: https://git.openjdk.java.net/jdk/commit/83cec4b6cc25b9b0db751bbe873444259cdcb21c Stats: 124 lines in 15 files changed: 95 ins; 11 del; 18 mod 8284273: Early crashes in os::print_context on AArch64 Reviewed-by: stefank, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/8736 From duke at openjdk.java.net Thu May 19 16:46:32 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Thu, 19 May 2022 16:46:32 GMT Subject: RFR: 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call [v3] In-Reply-To: References: Message-ID: > `MacroAssembler::trampoline_call` is for generating calls of targets which are inside CodeCache and can have relocInfo types: `runtime_call_type`, `opt_virtual_call_type`, `static_call_type` or `virtual_call_type`. > This PR updates the description of the function and adds additional asserts. > Tested a fastdebug build: > - `gtest`: Passed > - `tier1`: Passed Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Describe call types; Fix API - Merge branch 'master' into JDK-8286058 - Merge branch 'master' into JDK-8286058 - Fix assert message - 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call ------------- Changes: https://git.openjdk.java.net/jdk/pull/8564/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8564&range=02 Stats: 80 lines in 5 files changed: 50 ins; 8 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/8564.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8564/head:pull/8564 PR: https://git.openjdk.java.net/jdk/pull/8564 From aph at openjdk.java.net Thu May 19 16:46:35 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 19 May 2022 16:46:35 GMT Subject: RFR: 8272791: java -XX:BlockZeroingLowLimit=1 crashes after 8270947 [v2] In-Reply-To: References: Message-ID: > This is an assertion failure caused by setting `BlockZeroingLowLimit` < `wordSize`. > > I believe there was some confusion when writing this code about whether `BlockZeroingLowLimit` should be in words or bytes, and it makes no sense for it to be less than a single word. If anyone ever tried to use a parameter < 8, it triggers an assertion. > > This patch does two things. Firstly, it corrects a `guarantee` which erroneously used `zero_words_block_size` rather than `wordSize`. The value of both of these is 8, so it doesn't change anything in the generated code. Secondly, it clips the `BlockZeroingLowLimit` so that it doesn't trigger the assertion. > > Perhaps it would be better to change the lower limit to 8 instead of this silent correction. There is no backward compatibility issue here, because any attempt to set `BlockZeroingLowLimit` < 8 in the past would have exited the VM with an error, so I don't believe a CSR is warranted if we do change the allowable range. > > So, which should it be? Change the lower limit of the range of the `BlockZeroingLowLimit` system flag, or allow 1 still to be used and silently fix it? Opinions welcome. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Better ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8756/files - new: https://git.openjdk.java.net/jdk/pull/8756/files/a7983205..f6984247 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8756&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8756&range=00-01 Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8756.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8756/head:pull/8756 PR: https://git.openjdk.java.net/jdk/pull/8756 From kbarrett at openjdk.java.net Thu May 19 16:47:57 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 19 May 2022 16:47:57 GMT Subject: RFR: 8286262: Windows: Cleanup deprecation warning suppression In-Reply-To: References: Message-ID: On Tue, 17 May 2022 06:30:03 GMT, David Holmes wrote: > Sorry Kim I'm having trouble seeing what change corresponds to (1) ?? The change to CompileJvm.gmk, removing 4996 (deprecation warnings) from the list of disabled warnings. > Also the PR talks only about hotspot, but you're changing the JDK flags as well. ?? I forgot to mention that in addition to reformatting the JDK flags a little bit to be consistent with the JVM flags changes, I also changed -D_CRT_SECURE_NO_DEPRECATE => -D_CRT_SECURE_NO_WARNINGS. Both are (still) supported and have the same meaning, but the latter is the more "modern" (circa VS2005-ish?) spelling. ------------- PR: https://git.openjdk.java.net/jdk/pull/8718 From shade at openjdk.java.net Thu May 19 16:54:41 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 19 May 2022 16:54:41 GMT Subject: RFR: 8272791: java -XX:BlockZeroingLowLimit=1 crashes after 8270947 [v2] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 16:46:35 GMT, Andrew Haley wrote: >> This is an assertion failure caused by setting `BlockZeroingLowLimit` < `wordSize`. >> >> I believe there was some confusion when writing this code about whether `BlockZeroingLowLimit` should be in words or bytes, and it makes no sense for it to be less than a single word. If anyone ever tried to use a parameter < 8, it triggers an assertion. >> >> This patch does two things. Firstly, it corrects a `guarantee` which erroneously used `zero_words_block_size` rather than `wordSize`. The value of both of these is 8, so it doesn't change anything in the generated code. Secondly, it clips the `BlockZeroingLowLimit` so that it doesn't trigger the assertion. >> >> Perhaps it would be better to change the lower limit to 8 instead of this silent correction. There is no backward compatibility issue here, because any attempt to set `BlockZeroingLowLimit` < 8 in the past would have exited the VM with an error, so I don't believe a CSR is warranted if we do change the allowable range. >> >> So, which should it be? Change the lower limit of the range of the `BlockZeroingLowLimit` system flag, or allow 1 still to be used and silently fix it? Opinions welcome. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Better Marked as reviewed by shade (Reviewer). src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4858: > 4856: address MacroAssembler::zero_words(Register base, uint64_t cnt) > 4857: { > 4858: guarantee(wordSize <= BlockZeroingLowLimit, Surely, this `guarantee` would now never fire? Maybe we should demote it to `assert` to protect from accidental range error. There is no need to pay the price in release bits, I think. ------------- PR: https://git.openjdk.java.net/jdk/pull/8756 From duke at openjdk.java.net Thu May 19 17:05:49 2022 From: duke at openjdk.java.net (olivergillespie) Date: Thu, 19 May 2022 17:05:49 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: <3ZBL_1dq9wlTmiNc_bH-ZJcNSgO6TZGeDEi1ZoPZhP0=.f183a5e9-57e5-4d3e-a94b-f03158400075@github.com> On Mon, 16 May 2022 15:52:22 GMT, olivergillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. I just ran into this again on a different machine, on this one it downclocks from 3.6GHz to 3.1GHz. cpu family : 6 model : 85 model name : Intel(R) Xeon(R) Platinum 8275CL CPU @ 3.00GHz stepping : 7 @vnkozlov I tried with 1, 2, 4, 8 and 16 benchmark threads, all showed no regression on crypto.aes. Did you manage to re-run it? ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From sviswanathan at openjdk.java.net Thu May 19 17:55:55 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 19 May 2022 17:55:55 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Mon, 16 May 2022 15:52:22 GMT, olivergillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. >From what I understand, only the core which is executing 512 bit vector instructions will observe this lower frequency and not the entire processor. It is doing double the work per clock during that time so overall we should come out ok. @olivergillespie As Volker mentioned, the SPECjvm2008 data that you shared was all over the place. You would agree that we cannot globally change something based on that. In addition, SPECjvm2008 has lot of run-to-run variation in general due to various reasons (e.g. data locality if the threads are spread across multiple socket). Please take that into account as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From shade at openjdk.java.net Thu May 19 18:01:11 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 19 May 2022 18:01:11 GMT Subject: RFR: 8287044: Loom: Incorrect StackChunk::pc accessors Message-ID: <-Rpu2W3YyBXsY0TWY0M5h9HLsHmBxsR6WGkT5jNs0ZA=.5a5b98f2-90a1-4a6f-b16c-18de0c2c1724@github.com> The injected field is defined as: macro(jdk_internal_vm_StackChunk, pc, intptr_signature, false) \ ...yet it is read and written as "long", which silently overwrites adjacent fields in `StackChunk` on 32-bit platforms. This is a blocker for any 32-bit support. There are plenty of other `intptr` injected fields in other classes (e.g. `Class::array_klass`), and they are properly accessed by "address" accessors. Additional testing: - [x] Linux x86_64 fastdebug, prospective `jdk_loom hotspot_loom` - [ ] Linux AArch64 fastdebug, prospective `jdk_loom hotspot_loom` - [x] Linux x86_32 fastdebug experimental port is not broken here anymore ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/8792/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8792&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287044 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8792.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8792/head:pull/8792 PR: https://git.openjdk.java.net/jdk/pull/8792 From duke at openjdk.java.net Thu May 19 18:20:00 2022 From: duke at openjdk.java.net (olivergillespie) Date: Thu, 19 May 2022 18:20:00 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Mon, 16 May 2022 15:52:22 GMT, olivergillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. Thanks for the comments. > From what I understand, only the core which is executing 512 bit vector instructions will observe this lower frequency and not the entire processor. Yes, but in a typical multithreaded java service (say a web app), many threads end up using these instructions via common operations like StringBuilder, plus the threads are not pinned to cores. This in practice can mean all cores occasionally hit AVX3 instructions. The slowdown on these processors does not only last while the instruction is executing, it persists far beyond that, and so even a few short uses of AVX3 can end up perma-throttling all CPUs. >From https://lemire.me/blog/2018/09/07/avx-512-when-and-how-to-use-these-new-instructions/ > Downclocking, when it happens, is per core and for a short time after you have used particular instructions (e.g., ~2ms). 2 milliseconds is a huge amount of time to run at the lower frequency. Each core only needs to hit these instructions once every 2 milliseconds to have permanent throttling, and that's what I see on my applications. More info: https://blog.cloudflare.com/on-the-dangers-of-intels-frequency-scaling/ I'm not an expert on the mechanics of this, only that I observe this same behaviour in every real-world JDK17 application I've looked at which run on Cascade Lake (4 so far); namely 15% global slowdown with very little AVX3 usage. The AVX3 speedup definitely doesn't make up for it, because when I disable AVX3 my application's performance improves significantly (reduced latency, increased throughput). Do you know what measurements were used to justify the original exception or model 85 stepping <5? I could re-run those tests to compare to my hardware. Is there any other bechmark or measurement which you'd like to see which might justify this change? Maybe we can look at the change in this way: are model 85 stepping 5,6,7 affected by the same issue that the earlier steppings are, which are already excluded from AVX3 by default? It was evidently decided that the issue was severe enough for those CPUs to have AVX3 disabled by default, I merely find that 3 later models also suffer severely from this issue and should receive the same treatment. ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From rpressler at openjdk.java.net Thu May 19 18:43:49 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Thu, 19 May 2022 18:43:49 GMT Subject: RFR: 8287044: Loom: Incorrect StackChunk::pc accessors In-Reply-To: <-Rpu2W3YyBXsY0TWY0M5h9HLsHmBxsR6WGkT5jNs0ZA=.5a5b98f2-90a1-4a6f-b16c-18de0c2c1724@github.com> References: <-Rpu2W3YyBXsY0TWY0M5h9HLsHmBxsR6WGkT5jNs0ZA=.5a5b98f2-90a1-4a6f-b16c-18de0c2c1724@github.com> Message-ID: On Thu, 19 May 2022 17:53:12 GMT, Aleksey Shipilev wrote: > The injected field is defined as: > > > macro(jdk_internal_vm_StackChunk, pc, intptr_signature, false) \ > > > ...yet it is read and written as "long", which silently overwrites adjacent fields in `StackChunk` on 32-bit platforms. This is a blocker for any 32-bit support. There are plenty of other `intptr` injected fields in other classes (e.g. `Class::array_klass`), and they are properly accessed by "address" accessors. > > Additional testing: > - [x] Linux x86_64 fastdebug, prospective `jdk_loom hotspot_loom` > - [x] Linux AArch64 fastdebug, prospective `jdk_loom hotspot_loom` > - [x] Linux x86_32 fastdebug experimental port is not broken here anymore Very good. Thank you! ------------- Marked as reviewed by rpressler (Author). PR: https://git.openjdk.java.net/jdk/pull/8792 From aivanov at openjdk.java.net Thu May 19 18:54:04 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 19 May 2022 18:54:04 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base [v2] In-Reply-To: References: Message-ID: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision: - ...set to the values... - ...will result in a Zip64 Extra (EXT) header - ...in addition to the main attributes... - ...and the address of the current archive - Merges the stack at the given bci... - Returns a single ... - ...when a peer shuts down an association. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8768/files - new: https://git.openjdk.java.net/jdk/pull/8768/files/c7e73658..0669cdc1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=00-01 Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8768.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768 PR: https://git.openjdk.java.net/jdk/pull/8768 From aivanov at openjdk.java.net Thu May 19 18:59:57 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 19 May 2022 18:59:57 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base [v2] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 08:47:47 GMT, Kevin Walls wrote: >> Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision: >> >> - ...set to the values... >> - ...will result in a Zip64 Extra (EXT) header >> - ...in addition to the main attributes... >> - ...and the address of the current archive >> - Merges the stack at the given bci... >> - Returns a single ... >> - ...when a peer shuts down an association. > > src/jdk.jdi/share/classes/com/sun/jdi/ClassType.java line 348: > >> 346: >> 347: /** >> 348: * Returns the single non-abstract {@link Method} visible from > > I would think "Returns a single ..." because the implementation returns the first match it finds, from possibly many. I've accepted it, yet I'm still unsure whether ?a? or ?the?? ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From aivanov at openjdk.java.net Thu May 19 19:06:56 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 19 May 2022 19:06:56 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base [v2] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 09:38:40 GMT, Kevin Walls wrote: >> Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision: >> >> - ...set to the values... >> - ...will result in a Zip64 Extra (EXT) header >> - ...in addition to the main attributes... >> - ...and the address of the current archive >> - Merges the stack at the given bci... >> - Returns a single ... >> - ...when a peer shuts down an association. > > OK. I started with serviceability but then went through everything as it's hard to record what you have/haven't seen in these long reviews. Thank you @kevinjwalls for your suggestions. I've incorporated them. ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From duke at openjdk.java.net Thu May 19 19:15:52 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Thu, 19 May 2022 19:15:52 GMT Subject: Integrated: 8286182: [BACKOUT] x86: Handle integral division overflow during parsing In-Reply-To: References: Message-ID: On Wed, 18 May 2022 15:44:10 GMT, Quan Anh Mai wrote: > This patch backs out the changes made by [JDK-8285390](https://bugs.openjdk.java.net/browse/JDK-8285390) and [JDK-8284742](https://bugs.openjdk.java.net/browse/JDK-8284742) since there are failures due to div nodes floating above their validity checks. > > Thanks. This pull request has now been integrated. Changeset: 079312c8 Author: Quan Anh Mai Committer: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/079312c835a75e2ed5329d061583add5ac9fa2e0 Stats: 1065 lines in 25 files changed: 364 ins; 575 del; 126 mod 8286182: [BACKOUT] x86: Handle integral division overflow during parsing 8287035: [BACKOUT] PPC64: Handle integral division overflow during parsing Reviewed-by: mdoerr, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/8774 From kvn at openjdk.java.net Thu May 19 19:22:51 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 19 May 2022 19:22:51 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: <7VKNTH1Uq3CDIs8iJqIqtq9ebPOpBclbiWKj9eV2Og8=.e3ae9615-d192-4f80-81d3-546a270ff3f8@github.com> On Wed, 18 May 2022 16:28:42 GMT, Vladimir Kozlov wrote: >> The current code already does this for 'older' Skylake processors, >> namely those with _stepping < 5. My testing indicates this is a >> problem for later processors in this family too, so I have removed the >> max stepping condition. >> >> The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. >> >> A general description of the overall issue is given at >> https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. >> >> According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, >> stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, >> and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using >> -XX:UseAVX=3, along with a corresponding performance reduction. >> >> I first saw this issue in a real production workload, where the main AVX3 instructions >> being executed were those generated for various flavours of disjoint_arraycopy. >> >> I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. >> >> >> java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ >> --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ >> -jar SPECjvm2008.jar -ikv -ict xml.transform >> >> >> Before the change, or with -XX:UseAVX=3: >> >> >> Valid run! >> Score on xml.transform: 776.00 ops/m >> >> >> After the change, or with -XX:UseAVX=2: >> >> >> Valid run! >> Score on xml.transform: 894.07 ops/m >> >> >> So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively >> affected by this change, but I contend that this is still the right move given the stark >> difference in this benchmark combined with the fact that use of AVX3 instructions can >> affect *all* processes/code on the host due to the downclocking, and the fact that this >> effect is very hard to root-cause, for example CPU profiles look very similar before and >> after since all code is equally slowed. > > I got regression when I did not load my system - I run spec with `-bt 8`. I will do rerun with full load. My system is slightly different: 8260L CPU @ 2.40GHz. > @vnkozlov I tried with 1, 2, 4, 8 and 16 benchmark threads, all showed no regression on crypto.aes. Did you manage to re-run it? I rerun it but it did not get this regression. So it is indeed non-stable. I think @simonis is right that we need to run each sub-benchmarks separately. I am currently running with different `-bt` and results are jumping. I am on bare-bone machine. I will try to run with increased iterations and separate sub-benchmarks. Based on your comment, you are using JDK 17. Which particular version you have? I am running with latest JDK 19 which may also affects difference. ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From jbhateja at openjdk.java.net Thu May 19 21:11:41 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 19 May 2022 21:11:41 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v7] In-Reply-To: References: Message-ID: > Hi All, > > Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) > > Following is the brief summary of changes:- > > 1) Extends the scope of existing lanewise API for following new vector operations. > - VectorOperations.BIT_COUNT: counts the number of one-bits > - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits > - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits > - VectorOperations.REVERSE: reversing the order of bits > - VectorOperations.REVERSE_BYTES: reversing the order of bytes > - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. > > 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. > - Vector.compress > - Vector.expand > - VectorMask.compress > > 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. > - Vector.fromMemorySegment > - Vector.intoMemorySegment > > 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. > > > Patch has been regressed over AARCH64 and X86 targets different AVX levels. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - 8284960: Changes to enable jdk.incubator.vector to be treated as preview participant. Code re-organization related to Reverse/ReverseByte IR transforms. - 8284960: Adding --enable-preview in vectorAPI benchmarks. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - 8284960: Review comments resolution. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - 8284960: Correcting a typo. - 8284960: Integrating changes from panama-vector (Add @since 19 tags). - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/9f562ef7...311f3233 ------------- Changes: https://git.openjdk.java.net/jdk/pull/8425/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=06 Stats: 38049 lines in 228 files changed: 16683 ins; 16923 del; 4443 mod Patch: https://git.openjdk.java.net/jdk/pull/8425.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425 PR: https://git.openjdk.java.net/jdk/pull/8425 From jbhateja at openjdk.java.net Thu May 19 21:14:18 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 19 May 2022 21:14:18 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v3] In-Reply-To: References: <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com> Message-ID: On Thu, 19 May 2022 15:33:49 GMT, Jatin Bhateja wrote: >> Do you mean it's important to apply the transformation at the right node (pick the right node as the root) and it is hard to make a decision during GVN? > > Yes, that what I meant, but with recently added Node::Flag_is_predicated_using_blend it could be possible to move this transformation ahead into idealization routines of reverse/reverse bytes IR nodes. Addressed this after internally discussing with Sandhya. Moved the transforms from final graph re-shaping back to vector intrinsic routines. ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From psandoz at openjdk.java.net Thu May 19 21:23:22 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 19 May 2022 21:23:22 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v7] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 21:11:41 GMT, Jatin Bhateja wrote: >> Hi All, >> >> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) >> >> Following is the brief summary of changes:- >> >> 1) Extends the scope of existing lanewise API for following new vector operations. >> - VectorOperations.BIT_COUNT: counts the number of one-bits >> - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits >> - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits >> - VectorOperations.REVERSE: reversing the order of bits >> - VectorOperations.REVERSE_BYTES: reversing the order of bytes >> - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. >> >> 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. >> - Vector.compress >> - Vector.expand >> - VectorMask.compress >> >> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. >> - Vector.fromMemorySegment >> - Vector.intoMemorySegment >> >> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. >> >> >> Patch has been regressed over AARCH64 and X86 targets different AVX levels. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - 8284960: Changes to enable jdk.incubator.vector to be treated as preview participant. Code re-organization related to Reverse/ReverseByte IR transforms. > - 8284960: Adding --enable-preview in vectorAPI benchmarks. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - 8284960: Review comments resolution. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - 8284960: Correcting a typo. > - 8284960: Integrating changes from panama-vector (Add @since 19 tags). > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/9f562ef7...311f3233 src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java line 50: > 48: import java.util.Set; > 49: > 50: import static com.sun.tools.javac.code.Flags.PREVIEW_API; Suggestion: Redundant import (sorry i should have checked before i sent you updates to this area) ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From psandoz at openjdk.java.net Thu May 19 23:51:27 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 19 May 2022 23:51:27 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v7] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 21:11:41 GMT, Jatin Bhateja wrote: >> Hi All, >> >> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) >> >> Following is the brief summary of changes:- >> >> 1) Extends the scope of existing lanewise API for following new vector operations. >> - VectorOperations.BIT_COUNT: counts the number of one-bits >> - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits >> - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits >> - VectorOperations.REVERSE: reversing the order of bits >> - VectorOperations.REVERSE_BYTES: reversing the order of bytes >> - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. >> >> 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. >> - Vector.compress >> - Vector.expand >> - VectorMask.compress >> >> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. >> - Vector.fromMemorySegment >> - Vector.intoMemorySegment >> >> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. >> >> >> Patch has been regressed over AARCH64 and X86 targets different AVX levels. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - 8284960: Changes to enable jdk.incubator.vector to be treated as preview participant. Code re-organization related to Reverse/ReverseByte IR transforms. > - 8284960: Adding --enable-preview in vectorAPI benchmarks. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - 8284960: Review comments resolution. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - 8284960: Correcting a typo. > - 8284960: Integrating changes from panama-vector (Add @since 19 tags). > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/9f562ef7...311f3233 src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java line 132: > 130: * @return true if {@code s} is participating in the preview of {@code previewSymbol} > 131: */ > 132: public boolean isPreviewParticipating(Symbol s, Symbol previewSymbol) { Some feedback from a colleague: Suggestion: /** * Returns true if {@code s} is deemed to participate in the preview of {@code previewSymbol}, and * therefore no warnings or errors will be produced. * * @param s the symbol depending on the preview symbol * @param previewSymbol the preview symbol marked with @Preview * @return true if {@code s} is participating in the preview of {@code previewSymbol} */ public boolean participatesInPreview(Symbol s, Symbol previewSymbol) { ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From kvn at openjdk.java.net Fri May 20 05:23:42 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 20 May 2022 05:23:42 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Mon, 16 May 2022 15:52:22 GMT, olivergillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. I reproduced my regression (and your improvement) running on 1/4 of total threads on machine: SEPCjvm2008_avx2_vs_avx512_qrtr But when I use all threads (loading system) picture is different (except mpegaudio): SEPCjvm2008_avx2_vs_avx512_full ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From kvn at openjdk.java.net Fri May 20 05:32:56 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 20 May 2022 05:32:56 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Mon, 16 May 2022 15:52:22 GMT, olivergillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. I think I spent enough time on this already. Performance tracking is "rabbit hole" :( As I said before, results are mixed comparing to running on Skylake where results were all positive. Even running on more recent Intel's CPUs I see some mixed results. Yes, AVXV512 is not for all applications. I agree with your observations. Even so, I can't support this change. For such cases we have official solution by providing ability to choose instructions set with `UseAVX` flag. ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From tobias.hartmann at oracle.com Fri May 20 05:57:00 2022 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 20 May 2022 07:57:00 +0200 Subject: Mismatched ciMethodData in replay file. In-Reply-To: <5cd7f04c-c9ad-bbaa-6cba-0616ca9cae9d@amazon.com> References: <5cd7f04c-c9ad-bbaa-6cba-0616ca9cae9d@amazon.com> Message-ID: <3d19401f-6dfe-ca7a-18b5-377a71ced1ce@oracle.com> Hi, Thanks for reporting this, I see that you now file https://bugs.openjdk.java.net/browse/JDK-8287046. Best regards, Tobias On 19.05.22 08:14, Liu, Xin wrote: > hi, > > I get a weird replay, which was generated by 17.0.3+6-LTS. I don't see > relevant code have changed since then, so I think it is still applicable > to the tip of HotSpot. > > A customer shared the replay file > with(https://github.com/corretto/corretto-17/issues/57#issuecomment-1130042063) > and I am trying to reproduce his failure. it is written from > VMError::report_and_die(). > > One obstacle is that weird entries of ciMethodData. eg. line > 14130, It declares that there will 2 non-null oops followed(see '2' > after tag 'oops'. however, one only is recorded. > > ciMethodData kotlin/coroutines/jvm/internal/ContinuationImpl > (Lkotlin/coroutines/Continuation;)V 2 21538 orig 80 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 data > 26 0x40007 0x402 0x70 0x4e9c 0x70005 0x4d55 0x0 0x7f6a5841c3c0 0xa3 > 0x7f6a5841c470 0xa4 0xc0003 0x4e9c 0x18 0x110002 0x529e 0x0 0x0 0x0 0x0 > 0x0 0x0 0x9 0x2 0x6 0x0 oops 2 7 > com/example/ProductAttRouter$withRequestLoggingContext$1 methods 0 > > Another mismatched entry is at line 14203. it says there are 11 > oops but only 6 are there. > > Those mismatched entries leave uninitialized elements of rec->_classes > and eventually crash ciReplay::initialize(). Have you seen them before? > I can patch up hotspot to handle this mismatch, but I wonder how that > happens? > > ciMethodData::dump_replay_data() iterates > _data 2 rounds. The 1st round counts them and second round dumps them. > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/ci/ciMethodData.cpp#L728 > > Is that possible that the underlying data get updated on the fly? This > case is kotlin coroutine. I am not > sure whether it is same threading environment as classic Java. > > thanks, > --lx > From aph at openjdk.java.net Fri May 20 06:28:45 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 20 May 2022 06:28:45 GMT Subject: RFR: 8272791: java -XX:BlockZeroingLowLimit=1 crashes after 8270947 [v2] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 16:51:14 GMT, Aleksey Shipilev wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> Better > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4858: > >> 4856: address MacroAssembler::zero_words(Register base, uint64_t cnt) >> 4857: { >> 4858: guarantee(wordSize <= BlockZeroingLowLimit, > > Surely, this `guarantee` would now never fire? Maybe we should demote it to `assert` to protect from accidental range error. There is no need to pay the price in release bits, I think. True. ------------- PR: https://git.openjdk.java.net/jdk/pull/8756 From ihse at openjdk.java.net Fri May 20 08:39:49 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 20 May 2022 08:39:49 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Wed, 18 May 2022 19:05:03 GMT, Dmitry Chuyko wrote: > On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. > > New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. > > Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: > > * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. > * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with > --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse > > Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. Configure files need a bit more work. make/autoconf/jvm-features.m4 line 47: > 45: ifdef([custom_jvm_features_valid], custom_jvm_features_valid) \ > 46: \ > 47: cds compiler1 compiler2 dtrace epsilongc g1gc hardlse jfr jni-check \ The feature should be named `hard-lse` to match the `HARD_LSE` define in Hotspot code. (Also, it improves readability.) make/autoconf/jvm-features.m4 line 442: > 440: JVM_FEATURES_VARIANT_FILTER="link-time-opt opt-size" > 441: fi > 442: # Filter out hardlse feature by default You should not set up a PLATFORM filter in `JVM_FEATURES_PREPARE_VARIANT`. In fact, you will need a `JVM_FEATURES_CHECK_HARD_LSE`, which verifies that it can only be enabled on aarch64. See e.g. `JVM_FEATURES_CHECK_JVMCI` foor inspiration on how to write this and where to call it. I suggest you set up `JVM_FEATURES_PLATFORM_FILTER` in that function as well. ------------- Changes requested by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8779 From chagedorn at openjdk.java.net Fri May 20 09:37:09 2022 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Fri, 20 May 2022 09:37:09 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v8] In-Reply-To: References: Message-ID: On Fri, 8 Apr 2022 11:11:29 GMT, Christian Hagedorn wrote: >> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method: >> >> Stack: [0x00007f6e01739000,0x00007f6e0183a000], sp=0x00007f6e01838110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f >> >> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method. >> >> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)): >> >> Stack: [0x00007f34fca18000,0x00007f34fcb19000], sp=0x00007f34fcb17110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 (c1_Compilation.cpp:607) >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec (c1_Compiler.cpp:250) >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 (compileBroker.cpp:2291) >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df (compileBroker.cpp:1966) >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 (compilerThread.cpp:59) >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d (thread.cpp:1297) >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 (thread.cpp:1280) >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 (thread.cpp:358) >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f (os_linux.cpp:705) >> >> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. >> >> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf >> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. >> >> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability. >> >> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. >> >> **Testing:** >> Apart from manual testing, I've added two kinds of tests: >> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers. >> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename. >> >> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation. >> >> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number. >> >> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user). >> >> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`! >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits: > > - Merge branch 'master' into JDK-8242181 > - Fix build, add GCC flag gdwarf-4 to exclude DWARF 5, add assertions > - Apply remaining review comments from Thomas Stuefe > - Change load_dwarf_file with DwarfFilePath and DebugInfo > - Revert renaming on Windows > - Merge branch 'master' into JDK-8242181 > - Updating some comments > - Cleanup loading dwarf file and add summary > - Review comments of first pass by Thomas except dwarf file loading > - Merge branch 'master' into JDK-8242181 > - ... and 50 more: https://git.openjdk.java.net/jdk/compare/60281810...229f1b90 I've filed [JDK-8287021](https://bugs.openjdk.java.net/browse/JDK-8287021) to later add support for DWARF 5. To bring up again some general points that are left to decide upon/fix: - UL: If not used, we might want to introduce a special flag like `-XX:TraceDwarf={1,2,3}` to enable/disable different log levels. I'm fine with both approaches. I think we should keep some kind of logging around, especially when later adding DWARF 5 support. > We see test errors on Linux ppcle and x64 in gtests: > > ``` > [ RUN ] os_linux.decoder_get_source_info_valid_vm > /sapmnt/sapjvm_work/openjdk/nb/linuxppc64le/jdk-dev/test/hotspot/gtest/runtime/test_os_linux.cpp:442: Failure > Value of: Decoder::get_source_info(valid_function_pointer, buf, sizeof(buf), &line) > Actual: false > Expected: true > [ FAILED ] os_linux.decoder_get_source_info_valid_vm (93 ms) > [ RUN ] os_linux.decoder_get_source_info_valid_truncated_vm > /sapmnt/sapjvm_work/openjdk/nb/linuxppc64le/jdk-dev/test/hotspot/gtest/runtime/test_os_linux.cpp:454: Failure > Value of: Decoder::get_source_info(valid_function_pointer, buf, 7, &line) > Actual: false > Expected: true > ``` > > We also see Problems in runtime/ErrorHandling and in jfr/jvm/TestDumpOnCrash. Mostly, these tests now have much longer runtimes (about factor 2). With TestDumpOnCrash, both the error file writer and the test itself timeouted on some of our slower machines. @tstuefe: Is this still an issue with the latest commit which added `-gdwarf-4`? I'm currently running some testing with a merge of latest JDK which is looking good so far. ------------- PR: https://git.openjdk.java.net/jdk/pull/7126 From chagedorn at openjdk.java.net Fri May 20 09:37:03 2022 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Fri, 20 May 2022 09:37:03 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v9] In-Reply-To: References: Message-ID: > When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method: > > Stack: [0x00007f6e01739000,0x00007f6e0183a000], sp=0x00007f6e01838110, free space=1020k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 > V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec > V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 > V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df > V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 > V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d > V [libjvm.so+0x12091c9] JavaThread::run()+0x167 > V [libjvm.so+0x1206ada] Thread::call_run()+0x180 > V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f > > This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method. > > This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)): > > Stack: [0x00007f34fca18000,0x00007f34fcb19000], sp=0x00007f34fcb17110, free space=1020k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 (c1_Compilation.cpp:607) > V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec (c1_Compiler.cpp:250) > V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 (compileBroker.cpp:2291) > V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df (compileBroker.cpp:1966) > V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 (compilerThread.cpp:59) > V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d (thread.cpp:1297) > V [libjvm.so+0x12091c9] JavaThread::run()+0x167 (thread.cpp:1280) > V [libjvm.so+0x1206ada] Thread::call_run()+0x180 (thread.cpp:358) > V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f (os_linux.cpp:705) > > For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. > > The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf > I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. > > The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability. > > Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. > > **Testing:** > Apart from manual testing, I've added two kinds of tests: > - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers. > - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename. > > On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation. > > To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number. > > I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user). > > Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`! > > Thanks, > Christian Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits: - Merge branch 'master' into JDK-8242181 - Merge branch 'master' into JDK-8242181 - Fix build, add GCC flag gdwarf-4 to exclude DWARF 5, add assertions - Apply remaining review comments from Thomas Stuefe - Change load_dwarf_file with DwarfFilePath and DebugInfo - Revert renaming on Windows - Merge branch 'master' into JDK-8242181 - Updating some comments - Cleanup loading dwarf file and add summary - Review comments of first pass by Thomas except dwarf file loading - ... and 51 more: https://git.openjdk.java.net/jdk/compare/69ff86a3...5e105465 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7126/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7126&range=08 Stats: 2703 lines in 18 files changed: 2606 ins; 41 del; 56 mod Patch: https://git.openjdk.java.net/jdk/pull/7126.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7126/head:pull/7126 PR: https://git.openjdk.java.net/jdk/pull/7126 From jbhateja at openjdk.java.net Fri May 20 09:51:24 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 20 May 2022 09:51:24 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v8] In-Reply-To: References: Message-ID: <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com> > Hi All, > > Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) > > Following is the brief summary of changes:- > > 1) Extends the scope of existing lanewise API for following new vector operations. > - VectorOperations.BIT_COUNT: counts the number of one-bits > - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits > - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits > - VectorOperations.REVERSE: reversing the order of bits > - VectorOperations.REVERSE_BYTES: reversing the order of bytes > - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. > > 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. > - Vector.compress > - Vector.expand > - VectorMask.compress > > 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. > - Vector.fromMemorySegment > - Vector.intoMemorySegment > > 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. > > > Patch has been regressed over AARCH64 and X86 targets different AVX levels. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8284960: Integrating incremental patches. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8425/files - new: https://git.openjdk.java.net/jdk/pull/8425/files/311f3233..17a0e38c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=06-07 Stats: 32 lines in 7 files changed: 0 ins; 26 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8425.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425 PR: https://git.openjdk.java.net/jdk/pull/8425 From jbhateja at openjdk.java.net Fri May 20 09:51:27 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 20 May 2022 09:51:27 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v7] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 21:19:49 GMT, Paul Sandoz wrote: >> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 >> - 8284960: Changes to enable jdk.incubator.vector to be treated as preview participant. Code re-organization related to Reverse/ReverseByte IR transforms. >> - 8284960: Adding --enable-preview in vectorAPI benchmarks. >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 >> - 8284960: Review comments resolution. >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 >> - 8284960: Correcting a typo. >> - 8284960: Integrating changes from panama-vector (Add @since 19 tags). >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 >> - ... and 6 more: https://git.openjdk.java.net/jdk/compare/9f562ef7...311f3233 > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java line 50: > >> 48: import java.util.Set; >> 49: >> 50: import static com.sun.tools.javac.code.Flags.PREVIEW_API; > > Suggestion: > > > Redundant import (sorry i should have checked before i sent you updates to this area) Merged > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java line 132: > >> 130: * @return true if {@code s} is participating in the preview of {@code previewSymbol} >> 131: */ >> 132: public boolean isPreviewParticipating(Symbol s, Symbol previewSymbol) { > > Some feedback from a colleague: > Suggestion: > > /** > * Returns true if {@code s} is deemed to participate in the preview of {@code previewSymbol}, and > * therefore no warnings or errors will be produced. > * > * @param s the symbol depending on the preview symbol > * @param previewSymbol the preview symbol marked with @Preview > * @return true if {@code s} is participating in the preview of {@code previewSymbol} > */ > public boolean participatesInPreview(Symbol s, Symbol previewSymbol) { Merged. ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From duke at openjdk.java.net Fri May 20 09:55:57 2022 From: duke at openjdk.java.net (olivergillespie) Date: Fri, 20 May 2022 09:55:57 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Mon, 16 May 2022 15:52:22 GMT, olivergillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. Thanks for running the tests and sharing the results! > Based on your comment, you are using JDK 17. Which particular version you have? My tests were run on the latest JDK19 tip build, but my real applications where I have observed the problems are using 17.0.3.6. I agree that results are mixed (though the biggest changes are in favour of AVX2), so given that we know for sure that AVX512 affects other processes and other code, mixed results is definitely not a good enough reason to *enable* AVX512 on these CPUs. I don't believe we would ever decide to *enable* AVX512 based on these results, hence my suggested change - don't enable AVX512 on these CPUs. There is no benefit on average to having AVX512 enabled on these models, yet it comes with huge downsides, so I think the risk profile leans heavily in favour of not enabling it by default for these models. ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From mcimadamore at openjdk.java.net Fri May 20 10:37:20 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 20 May 2022 10:37:20 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v8] In-Reply-To: <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com> References: <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com> Message-ID: On Fri, 20 May 2022 09:51:24 GMT, Jatin Bhateja wrote: >> Hi All, >> >> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) >> >> Following is the brief summary of changes:- >> >> 1) Extends the scope of existing lanewise API for following new vector operations. >> - VectorOperations.BIT_COUNT: counts the number of one-bits >> - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits >> - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits >> - VectorOperations.REVERSE: reversing the order of bits >> - VectorOperations.REVERSE_BYTES: reversing the order of bytes >> - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. >> >> 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. >> - Vector.compress >> - Vector.expand >> - VectorMask.compress >> >> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. >> - Vector.fromMemorySegment >> - Vector.intoMemorySegment >> >> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. >> >> >> Patch has been regressed over AARCH64 and X86 targets different AVX levels. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8284960: Integrating incremental patches. Javac changes look good ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8425 From mcimadamore at openjdk.java.net Fri May 20 10:42:54 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 20 May 2022 10:42:54 GMT Subject: RFR: 8286825: Linker naming cleanup In-Reply-To: References: Message-ID: <9jnTsMW4B2W18WOMSTF3-GzAUXng1DumM3X3RiYKZiU=.d4824b31-20e3-42ad-9143-2984db5f22fe@github.com> On Wed, 18 May 2022 16:54:06 GMT, Jorn Vernee wrote: > This patch is a batch naming cleanup for the foreign linker implementation. > > The naming changes are as follows: > > - ProgrammableInvoker -> DowncallLinker > - ProgrammableUpcallHandler -> UpcallLinker > - 'native invoker' -> 'downcall stub' > - 'optimzed entry blob' -> 'upcall stub' > - OptimizedEntryBlob -> UpcallStub > - optimized_entry_frame -> upcall_stub_frame > > Then renaming of some hotspot files: > > - universalNativeInvoker* -> downcallLinker* > - universalUpcallHandler* -> upcallLinker* > - foreign_globals* -> foreignGlobals* (to match existing convention) > > Method, field, and other variable names are also adjusted accordingly. Looks good - I spotted a potential issue in the risc-v port src/hotspot/cpu/riscv/upcallLinker_riscv.cpp line 30: > 28: #include "utilities/debug.hpp" > 29: > 30: address UpcallLinker::generate_optimized_upcall_stub(jobject receiver, Method* entry, Hasn't "generated_optimized_upcall_stub" changed too? src/hotspot/cpu/riscv/upcallLinker_riscv.cpp line 38: > 36: ShouldNotCallThis(); > 37: return nullptr; > 38: } Missing newline (this was here before) ------------- PR: https://git.openjdk.java.net/jdk/pull/8777 From jvernee at openjdk.java.net Fri May 20 10:42:55 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 20 May 2022 10:42:55 GMT Subject: RFR: 8286825: Linker naming cleanup In-Reply-To: <9jnTsMW4B2W18WOMSTF3-GzAUXng1DumM3X3RiYKZiU=.d4824b31-20e3-42ad-9143-2984db5f22fe@github.com> References: <9jnTsMW4B2W18WOMSTF3-GzAUXng1DumM3X3RiYKZiU=.d4824b31-20e3-42ad-9143-2984db5f22fe@github.com> Message-ID: On Fri, 20 May 2022 10:36:17 GMT, Maurizio Cimadamore wrote: >> This patch is a batch naming cleanup for the foreign linker implementation. >> >> The naming changes are as follows: >> >> - ProgrammableInvoker -> DowncallLinker >> - ProgrammableUpcallHandler -> UpcallLinker >> - 'native invoker' -> 'downcall stub' >> - 'optimzed entry blob' -> 'upcall stub' >> - OptimizedEntryBlob -> UpcallStub >> - optimized_entry_frame -> upcall_stub_frame >> >> Then renaming of some hotspot files: >> >> - universalNativeInvoker* -> downcallLinker* >> - universalUpcallHandler* -> upcallLinker* >> - foreign_globals* -> foreignGlobals* (to match existing convention) >> >> Method, field, and other variable names are also adjusted accordingly. > > src/hotspot/cpu/riscv/upcallLinker_riscv.cpp line 30: > >> 28: #include "utilities/debug.hpp" >> 29: >> 30: address UpcallLinker::generate_optimized_upcall_stub(jobject receiver, Method* entry, > > Hasn't "generated_optimized_upcall_stub" changed too? Right, I missed that one. Good catch! ------------- PR: https://git.openjdk.java.net/jdk/pull/8777 From jvernee at openjdk.java.net Fri May 20 10:57:44 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 20 May 2022 10:57:44 GMT Subject: RFR: 8286825: Linker naming cleanup [v2] In-Reply-To: References: Message-ID: > This patch is a batch naming cleanup for the foreign linker implementation. > > The naming changes are as follows: > > - ProgrammableInvoker -> DowncallLinker > - ProgrammableUpcallHandler -> UpcallLinker > - 'native invoker' -> 'downcall stub' > - 'optimzed entry blob' -> 'upcall stub' > - OptimizedEntryBlob -> UpcallStub > - optimized_entry_frame -> upcall_stub_frame > > Then renaming of some hotspot files: > > - universalNativeInvoker* -> downcallLinker* > - universalUpcallHandler* -> upcallLinker* > - foreign_globals* -> foreignGlobals* (to match existing convention) > > Method, field, and other variable names are also adjusted accordingly. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Comments + cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8777/files - new: https://git.openjdk.java.net/jdk/pull/8777/files/7b0e3a88..b362a822 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8777&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8777&range=00-01 Stats: 14 lines in 3 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/8777.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8777/head:pull/8777 PR: https://git.openjdk.java.net/jdk/pull/8777 From jvernee at openjdk.java.net Fri May 20 10:57:44 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 20 May 2022 10:57:44 GMT Subject: RFR: 8286825: Linker naming cleanup In-Reply-To: References: Message-ID: <0wbzj-LtCrnhvjjNAE9Qgqn1LI0EwmYL-x3T7jlKVVU=.7f373475-6368-4056-abe6-a1f161314324@github.com> On Wed, 18 May 2022 16:54:06 GMT, Jorn Vernee wrote: > This patch is a batch naming cleanup for the foreign linker implementation. > > The naming changes are as follows: > > - ProgrammableInvoker -> DowncallLinker > - ProgrammableUpcallHandler -> UpcallLinker > - 'native invoker' -> 'downcall stub' > - 'optimzed entry blob' -> 'upcall stub' > - OptimizedEntryBlob -> UpcallStub > - optimized_entry_frame -> upcall_stub_frame > > Then renaming of some hotspot files: > > - universalNativeInvoker* -> downcallLinker* > - universalUpcallHandler* -> upcallLinker* > - foreign_globals* -> foreignGlobals* (to match existing convention) > > Method, field, and other variable names are also adjusted accordingly. Addressed now. I also noticed some names in strings that weren't updated yet. Updated those as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/8777 From mcimadamore at openjdk.java.net Fri May 20 11:09:55 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 20 May 2022 11:09:55 GMT Subject: RFR: 8286825: Linker naming cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 10:57:44 GMT, Jorn Vernee wrote: >> This patch is a batch naming cleanup for the foreign linker implementation. >> >> The naming changes are as follows: >> >> - ProgrammableInvoker -> DowncallLinker >> - ProgrammableUpcallHandler -> UpcallLinker >> - 'native invoker' -> 'downcall stub' >> - 'optimzed entry blob' -> 'upcall stub' >> - OptimizedEntryBlob -> UpcallStub >> - optimized_entry_frame -> upcall_stub_frame >> >> Then renaming of some hotspot files: >> >> - universalNativeInvoker* -> downcallLinker* >> - universalUpcallHandler* -> upcallLinker* >> - foreign_globals* -> foreignGlobals* (to match existing convention) >> >> Method, field, and other variable names are also adjusted accordingly. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Comments + cleanup Marked as reviewed by mcimadamore (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8777 From jlahoda at openjdk.java.net Fri May 20 11:13:39 2022 From: jlahoda at openjdk.java.net (Jan Lahoda) Date: Fri, 20 May 2022 11:13:39 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v8] In-Reply-To: <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com> References: <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com> Message-ID: On Fri, 20 May 2022 09:51:24 GMT, Jatin Bhateja wrote: >> Hi All, >> >> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) >> >> Following is the brief summary of changes:- >> >> 1) Extends the scope of existing lanewise API for following new vector operations. >> - VectorOperations.BIT_COUNT: counts the number of one-bits >> - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits >> - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits >> - VectorOperations.REVERSE: reversing the order of bits >> - VectorOperations.REVERSE_BYTES: reversing the order of bytes >> - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. >> >> 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. >> - Vector.compress >> - Vector.expand >> - VectorMask.compress >> >> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. >> - Vector.fromMemorySegment >> - Vector.intoMemorySegment >> >> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. >> >> >> Patch has been regressed over AARCH64 and X86 targets different AVX levels. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8284960: Integrating incremental patches. The javac changes look OK to me. ------------- Marked as reviewed by jlahoda (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8425 From simonis at openjdk.java.net Fri May 20 11:55:52 2022 From: simonis at openjdk.java.net (Volker Simonis) Date: Fri, 20 May 2022 11:55:52 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Fri, 20 May 2022 05:30:54 GMT, Vladimir Kozlov wrote: >> The current code already does this for 'older' Skylake processors, >> namely those with _stepping < 5. My testing indicates this is a >> problem for later processors in this family too, so I have removed the >> max stepping condition. >> >> The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. >> >> A general description of the overall issue is given at >> https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. >> >> According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, >> stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, >> and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using >> -XX:UseAVX=3, along with a corresponding performance reduction. >> >> I first saw this issue in a real production workload, where the main AVX3 instructions >> being executed were those generated for various flavours of disjoint_arraycopy. >> >> I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. >> >> >> java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ >> --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ >> -jar SPECjvm2008.jar -ikv -ict xml.transform >> >> >> Before the change, or with -XX:UseAVX=3: >> >> >> Valid run! >> Score on xml.transform: 776.00 ops/m >> >> >> After the change, or with -XX:UseAVX=2: >> >> >> Valid run! >> Score on xml.transform: 894.07 ops/m >> >> >> So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively >> affected by this change, but I contend that this is still the right move given the stark >> difference in this benchmark combined with the fact that use of AVX3 instructions can >> affect *all* processes/code on the host due to the downclocking, and the fact that this >> effect is very hard to root-cause, for example CPU profiles look very similar before and >> after since all code is equally slowed. > > I think I spent enough time on this already. Performance tracking is "rabbit hole" :( > > As I said before, results are mixed comparing to running on Skylake where results were all positive. > Even running on more recent Intel's CPUs I see some mixed results. > > Yes, AVXV512 is not for all applications. I agree with your observations. Even so, I can't support this change. > For such cases we have official solution by providing ability to choose instructions set with `UseAVX` flag. @vnkozlov I think I agree with @olivergillespie. Looking at the graphs you've posted, AVX2 seems superior to AVX3 even if only 1/4 of the threads are used but clearly if the machine is fully loaded. As @olivergillespie said, it would be hard to justify enabling AVX3 on these CPUs today, given these results. I would argue we should disable it by default and as you said, let the few use cases which benefit from it like AES on non-loaded machines, enable it manually with `-XX:+UseAVX=3`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From stuefe at openjdk.java.net Fri May 20 12:53:59 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 20 May 2022 12:53:59 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v6] In-Reply-To: <9x5FYsa0AqHsi17CtUxu5WikmQ9SVrwtF4tdRj7EqoI=.f535f7b3-08a3-46a0-9854-6113f97885d0@github.com> References: <9x5FYsa0AqHsi17CtUxu5WikmQ9SVrwtF4tdRj7EqoI=.f535f7b3-08a3-46a0-9854-6113f97885d0@github.com> Message-ID: <5pMOwxwTtJ8HQPn_VfhzrwLRUxPoTKyvbvMPmJaQXD8=.1d98f182-bef6-4c32-a285-f35c2839a600@github.com> On Sat, 2 Apr 2022 05:54:16 GMT, Thomas Stuefe wrote: >> Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits: >> >> - Apply remaining review comments from Thomas Stuefe >> - Change load_dwarf_file with DwarfFilePath and DebugInfo >> - Revert renaming on Windows >> - Merge branch 'master' into JDK-8242181 >> - Updating some comments >> - Cleanup loading dwarf file and add summary >> - Review comments of first pass by Thomas except dwarf file loading >> - Merge branch 'master' into JDK-8242181 >> - Make dwarf tag NOT_PRODUCT >> - Change log_* to log_develop_* and log_warning to log_develop_info >> - ... and 48 more: https://git.openjdk.java.net/jdk/compare/c2c0cb2a...06489da2 > > Hi Christian, I won't have time to look at this closely again until end of next week. At first glance it looks a lot better now, thanks for taking my suggestions. > >> Should we generally use assertions inside this error reporting code? For now, I've just went with bailouts without any assertions to avoid a corrupted stack/hs_err_file. > > Assertions will be handled like secondary crashes and show up as "error occurred during error reporting" with, I believe, file/line of the assertion. If that makes sense, that's fine. It helps finding bugs in stack printing code, and if you would crash anyway if you continue, an assertion is ok I think. > > Cheers, Thomas > @tstuefe: Is this still an issue with the latest commit which added -gdwarf-4? Issues seem to have disappeared. I'll schedule some more tests next week to be sure. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/7126 From duke at openjdk.java.net Fri May 20 14:19:17 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Fri, 20 May 2022 14:19:17 GMT Subject: RFR: 8284849: Add deoptimization to unified logging Message-ID: This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important). An example output looks like this: [1.346s][info][deoptimization] Deoptimization start { [1.346s][info][deoptimization] compileId = 407 [1.346s][info][deoptimization] compiler = c2 [1.346s][info][deoptimization] method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26 [1.346s][info][deoptimization] instruction = ifne [1.346s][info][deoptimization] reason = unstable_if [1.346s][info][deoptimization] action = reinterpret [1.346s][info][deoptimization] } Deoptimization end ------------- Commit messages: - Move logLevel include - Add UL logging of deoptimization event Changes: https://git.openjdk.java.net/jdk/pull/8812/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284849 Stats: 17 lines in 2 files changed: 17 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8812.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8812/head:pull/8812 PR: https://git.openjdk.java.net/jdk/pull/8812 From chagedorn at openjdk.java.net Fri May 20 14:57:27 2022 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Fri, 20 May 2022 14:57:27 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v9] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 09:37:03 GMT, Christian Hagedorn wrote: >> When printing the native stack trace on Linux (mostly done for hs_err files), it only prints the method with its parameters and a relative offset in the method: >> >> Stack: [0x00007f6e01739000,0x00007f6e0183a000], sp=0x00007f6e01838110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f >> >> This makes it sometimes difficult to see where exactly the methods were called from and sometimes almost impossible when there are multiple invocations of the same method within one method. >> >> This patch improves this by providing source information (filename + line number) to the native stack traces on Linux similar to what's already done on Windows (see [JDK-8185712](https://bugs.openjdk.java.net/browse/JDK-8185712)): >> >> Stack: [0x00007f34fca18000,0x00007f34fcb19000], sp=0x00007f34fcb17110, free space=1020k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x620d86] Compilation::~Compilation()+0x64 (c1_Compilation.cpp:607) >> V [libjvm.so+0x624b92] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0xec (c1_Compiler.cpp:250) >> V [libjvm.so+0x8303ef] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x899 (compileBroker.cpp:2291) >> V [libjvm.so+0x82f067] CompileBroker::compiler_thread_loop()+0x3df (compileBroker.cpp:1966) >> V [libjvm.so+0x84f0d1] CompilerThread::thread_entry(JavaThread*, JavaThread*)+0x69 (compilerThread.cpp:59) >> V [libjvm.so+0x1209329] JavaThread::thread_main_inner()+0x15d (thread.cpp:1297) >> V [libjvm.so+0x12091c9] JavaThread::run()+0x167 (thread.cpp:1280) >> V [libjvm.so+0x1206ada] Thread::call_run()+0x180 (thread.cpp:358) >> V [libjvm.so+0x1012e55] thread_native_entry(Thread*)+0x18f (os_linux.cpp:705) >> >> For Linux, we need to parse the debug symbols which are generated by GCC in DWARF - a standardized debugging format. This patch adds support for DWARF 4, the default of GCC 10.x, for 32 and 64 bit architectures (tested with x86_32, x86_64 and AArch64). DWARF 5 is not supported as it was still experimental and not generated for HotSpot. However, newer GCC version may soon generate DWARF 5 by default in which case this parser either needs to be extended or the build of HotSpot configured to only emit DWARF 4. >> >> The code follows the parsing steps described in the official DWARF 4 spec: https://dwarfstd.org/doc/DWARF4.pdf >> I added references to the corresponding sections throughout the code. However, I tried to explain the steps from the DWARF spec directly in the code (method names, comments etc.). This allows to follow the code without the need to actually deep dive into the spec. >> >> The comments at the `Dwarf` class in the `elf.hpp` file explain in more detail how a DWARF file is structured and how the parsing algorithm works to get to the filename and line number information. There are more class comments throughout the `elf.hpp` file about how different DWARF sections are structured and how the parsing algorithm needs to fetch the required information. Therefore, I will not repeat the exact workings of the algorithm here but refer to the code comments. I've tried to add as much information as possible to improve the readability. >> >> Generally, I've tried to stay away from adding any assertions as this code is almost always executed when already processing a VM error. Instead, the DWARF parser aims to just exit gracefully and possibly omit source information for a stack frame instead of risking to stop writing the hs_err file when an assertion would have failed. To debug failures, `-Xlog:dwarf` can be used with `info`, `debug` or `trace` which provides logging messages throughout parsing. >> >> **Testing:** >> Apart from manual testing, I've added two kinds of tests: >> - A JTreg test: Spawns new VMs to let them crash in various ways. The test reads the created hs_err files to check if the DWARF parsing could correctly find the filename and line number. For normal HotSpot files, I could not check against hardcoded filenames and line numbers as they are subject to change (especially line number can quickly become different). I therefore just added some sanity checks in the form of "found a non-empty file" and "found a non-zero line number". On top of that, I added tests that let the VM crash in custom C files (which will not change). This enables an additional verification of hardcoded filenames and line numbers. >> - Gtests: Directly calling the `get_source()` method which initiates DWARF parsing. Tested some special cases, for example, having a buffer that is not big enough to store the filename. >> >> On top of that, there are also existing JTreg tests that call `-XX:NativeMemoryTracking=detail` which will print a native stack trace with the new source information. These tests were also run as part of the standard tier testing and can be considered as sanity tests for this implementation. >> >> To make tests work in our infrastructure or if some other setups want to have debug symbols at different locations, I've added support for an additional `_JVM_DWARF_PATH` environment variable. This variable can specify a path from which the DWARF symbol file should be read by the parser if the default locations do not contain debug symbols (required some `make` changes). This is similar to what's done on Windows with `_NT_SYMBOL_PATH`. The JTreg test, however, also works if there are no symbols available. In that case, the test just skips all the assertion checks for the filename and line number. >> >> I haven't run any specific performance testing as this new code is mainly executed when an error will exit the VM and only if symbol files are available (which is normally not the case when using Java release builds as a user). >> >> Special thanks to @tschatzl for giving me some pointers to start based on his knowledge from a DWARF 2 parser he once wrote in Pascal and for discussing approaches on how to retrieve the source information and to @erikj79 for providing help for the changes required for `make`! >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits: > > - Merge branch 'master' into JDK-8242181 > - Merge branch 'master' into JDK-8242181 > - Fix build, add GCC flag gdwarf-4 to exclude DWARF 5, add assertions > - Apply remaining review comments from Thomas Stuefe > - Change load_dwarf_file with DwarfFilePath and DebugInfo > - Revert renaming on Windows > - Merge branch 'master' into JDK-8242181 > - Updating some comments > - Cleanup loading dwarf file and add summary > - Review comments of first pass by Thomas except dwarf file loading > - ... and 51 more: https://git.openjdk.java.net/jdk/compare/69ff86a3...5e105465 Thanks Thomas for doing the testing! ------------- PR: https://git.openjdk.java.net/jdk/pull/7126 From ngasson at openjdk.java.net Fri May 20 15:58:38 2022 From: ngasson at openjdk.java.net (Nick Gasson) Date: Fri, 20 May 2022 15:58:38 GMT Subject: RFR: 8286711: AArch64: serviceability agent tests fail with PAC enabled Message-ID: When the VM is run with `-XX:UseBranchProtection=pac-ret` on a supported CPU, the upper bits of the saved link register contain a "pointer authentication code" which must be checked and removed by a special instruction before a function returns. The serviceability agent is unaware of this and so sees garbled PC values when walking the stack. This patch just masks out the PAC bits from the sender PC after reading it from the stack frame. ------------- Commit messages: - 8286711: AArch64: serviceability agent tests fail with PAC enabled Changes: https://git.openjdk.java.net/jdk/pull/8814/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8814&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286711 Stats: 43 lines in 5 files changed: 35 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8814.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8814/head:pull/8814 PR: https://git.openjdk.java.net/jdk/pull/8814 From duke at openjdk.java.net Fri May 20 16:35:41 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Fri, 20 May 2022 16:35:41 GMT Subject: RFR: 8280481: Duplicated static stubs in NMethod Stub Code section Message-ID: <9N1GcHDRvyX1bnPrRcyw96zWIgrrAm4mfrzp8dQ-BBk=.6d55c5fd-7d05-4058-99b6-7d40a92450bf@github.com> Calls of Java methods have stubs to the interpreter for the cases when an invoked Java method is not compiled. Calls of static Java methods and final Java methods have statically bound information about a callee during compilation. Such calls can share stubs to the interpreter. Each stub to the interpreter has a relocation record (accessed via `relocInfo`) which provides an address of the stub and an address of its owner. `relocInfo` has an offset which is an offset from the previously know relocatable address. The address of a stub is calculated as the address provided by the previous `relocInfo` plus the offset. Each Java call has: - A relocation for a call site. - A relocation for a stub to the interpreter. - A stub to the interpreter. - If far jumps are used (arm64 case): - A trampoline relocation. - A trampoline. We cannot avoid creating relocations. They are needed to support patching call sites and stubs. One approach to create shared stubs to keep track of created stubs. If the needed stub exist we use its address and create only needed relocation information. The `relocInfo` for a created stub will have a positive offset. As relocations for different stubs can be created after that, a relocation for a shared stub will have a negative offset relative to the address provided by the previous relocation: reloc1 ---> 0x0: stub1 reloc2 ---> 0x4: stub2 (reloc2.addr = reloc1.addr + reloc2.offset = 0x0 + 4) reloc3 ---> 0x0: stub1 (reloc3.addr = reloc2.addr + reloc3.offset = 0x4 - 4) According to [relocInfo.hpp](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/code/relocInfo.hpp#L237): // [About Offsets] Relative offsets are supplied to this module as // positive byte offsets, but they may be internally stored scaled // and/or negated, depending on what is most compact for the target // system. Since the object pointed to by the offset typically // precedes the relocation address, it is profitable to store // these negative offsets as positive numbers, but this decision // is internal to the relocation information abstractions. However, `CodeSection` does not support negative offsets. It [assumes](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/asm/codeBuffer.hpp#L195) addresses relocations pointing at grow upward: class CodeSection { ... private: ... address _locs_point; // last relocated position (grows upward) ... void set_locs_point(address pc) { assert(pc >= locs_point(), "relocation addr may not decrease"); assert(allocates2(pc), "relocation addr must be in this section"); _locs_point = pc; } Negative offsets reduce the offset range by half. This can cause the increase of filler records, the empty `relocInfo` records to reduce offset values. Also negative offsets are only needed for `static_stub_type`, but other 13 types don?t need them. This PR implements another approach: postponed creation of stubs. First we collect requests for creating shared stubs. Then we have the finalisation phase, where shared stubs are created in `CodeBuffer`. This approach does not need negative offsets. Supported platforms are x86, x86_64 and aarch64. **Results from [Renaissance 0.14.0](https://github.com/renaissance-benchmarks/renaissance/releases/tag/v0.14.0)** Note: 'Nmethods with shared stubs' is the total number of nmethods counted during benchmark's run. 'Final # of nmethods' is a number of nmethods in CodeCache when JVM exited. - AArch64 +------------------+-------------+----------------------------+---------------------+ | Benchmark | Saved bytes | Nmethods with shared stubs | Final # of nmethods | +------------------+-------------+----------------------------+---------------------+ | dotty | 820544 | 4592 | 18872 | | dec-tree | 405280 | 2580 | 22335 | | naive-bayes | 392384 | 2586 | 21184 | | log-regression | 362208 | 2450 | 20325 | | als | 306048 | 2226 | 18161 | | finagle-chirper | 262304 | 2087 | 12675 | | movie-lens | 250112 | 1937 | 13617 | | gauss-mix | 173792 | 1262 | 10304 | | finagle-http | 164320 | 1392 | 11269 | | page-rank | 155424 | 1175 | 10330 | | chi-square | 140384 | 1028 | 9480 | | akka-uct | 115136 | 541 | 3941 | | reactors | 43264 | 335 | 2503 | | scala-stm-bench7 | 42656 | 326 | 3310 | | philosophers | 36576 | 256 | 2902 | | scala-doku | 35008 | 231 | 2695 | | rx-scrabble | 32416 | 273 | 2789 | | future-genetic | 29408 | 260 | 2339 | | scrabble | 27968 | 225 | 2477 | | par-mnemonics | 19584 | 168 | 1689 | | fj-kmeans | 19296 | 156 | 1647 | | scala-kmeans | 18080 | 140 | 1629 | | mnemonics | 17408 | 143 | 1512 | +------------------+-------------+----------------------------+---------------------+ - X86_64 +------------------+-------------+----------------------------+---------------------+ | Benchmark | Saved bytes | Nmethods with shared stubs | Final # of nmethods | +------------------+-------------+----------------------------+---------------------+ | dotty | 337065 | 4403 | 19135 | | dec-tree | 183045 | 2559 | 22071 | | naive-bayes | 176460 | 2450 | 19782 | | log-regression | 162555 | 2410 | 20648 | | als | 121275 | 1980 | 17179 | | movie-lens | 111915 | 1842 | 13020 | | finagle-chirper | 106350 | 1947 | 12726 | | gauss-mix | 81975 | 1251 | 10474 | | finagle-http | 80895 | 1523 | 12294 | | page-rank | 68940 | 1146 | 10124 | | chi-square | 62130 | 974 | 9315 | | akka-uct | 50220 | 555 | 4263 | | reactors | 23385 | 371 | 2544 | | philosophers | 17625 | 259 | 2865 | | scala-stm-bench7 | 17235 | 295 | 3230 | | scala-doku | 15600 | 214 | 2698 | | rx-scrabble | 14190 | 262 | 2770 | | future-genetic | 13155 | 253 | 2318 | | scrabble | 12300 | 217 | 2352 | | fj-kmeans | 8985 | 157 | 1616 | | par-mnemonics | 8535 | 155 | 1684 | | scala-kmeans | 8250 | 138 | 1624 | | mnemonics | 7485 | 134 | 1522 | +------------------+-------------+----------------------------+---------------------+ **Testing: fastdebug and release builds for x86, x86_64 and aarch64** - `tier1`...`tier4`: Passed - `hotspot/jtreg/compiler/sharedstubs`: Passed ------------- Commit messages: - Use call offset instead of caller pc - Simplify test - Fix x86 build failures - Remove UseSharedStubs and clarify shared stub use cases - Make SharedStubToInterpRequest ResourceObj and set initial size of SharedStubToInterpRequests to 8 - Update copyright year and add Unimplemented guards - Set UseSharedStubs to true for X86 - Set UseSharedStubs to true for AArch64 - Fix x86 build failure - Fix memory leak found by gtest - ... and 9 more: https://git.openjdk.java.net/jdk/compare/4587337e...a249f7da Changes: https://git.openjdk.java.net/jdk/pull/8816/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8816&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280481 Stats: 491 lines in 22 files changed: 458 ins; 5 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/8816.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8816/head:pull/8816 PR: https://git.openjdk.java.net/jdk/pull/8816 From shade at openjdk.java.net Fri May 20 16:40:26 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 20 May 2022 16:40:26 GMT Subject: RFR: 8287071: Loom: Cleanup x86_64 gen_continuation_enter Message-ID: During x86_32 porting, I ended up rewriting the copy of x86_64 gen_continuation_enter significantly to make it more streamlined. The original x86_64 gen_continuation_enter should enjoy the similar streamlining, since it would likely to be the template for many other architectures. There might be more things to do, I would not know until x86_32 fully works. Therefore, you might treat this PR as work in progress. You might want to take a look meanwhile. Brief tour of changes: - Check the incoming registers explicitly - Pass explicit argument registers to `fill_continuation_entry` - Use the usual `NativeCall` alignment code to produce a patchable call - Check that static stub is emitted, fail hard otherwise - Handle register shuffling for `exception_handler_for_return_address` the similar way we do it in `StubGenerator` Additional testing: - [x] Linux x86_64 fastdebug, prospective `jdk_loom hotspot_loom` ------------- Commit messages: - Revert test groups - Fix Changes: https://git.openjdk.java.net/jdk/pull/8802/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8802&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287071 Stats: 99 lines in 2 files changed: 43 ins; 13 del; 43 mod Patch: https://git.openjdk.java.net/jdk/pull/8802.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8802/head:pull/8802 PR: https://git.openjdk.java.net/jdk/pull/8802 From jvernee at openjdk.java.net Fri May 20 16:43:42 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Fri, 20 May 2022 16:43:42 GMT Subject: RFR: 8284849: Add deoptimization to unified logging In-Reply-To: References: Message-ID: On Fri, 20 May 2022 14:12:30 GMT, Johan Sj?l?n wrote: > This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important). > > An example output looks like this: > > > [1.346s][info][deoptimization] Deoptimization start { > [1.346s][info][deoptimization] compileId = 407 > [1.346s][info][deoptimization] compiler = c2 > [1.346s][info][deoptimization] method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26 > [1.346s][info][deoptimization] instruction = ifne > [1.346s][info][deoptimization] reason = unstable_if > [1.346s][info][deoptimization] action = reinterpret > [1.346s][info][deoptimization] } Deoptimization end Thanks for looking at this! I suggest trying to match the style of the `-Xlog:jit+compilation=debug` messages, since deoptimization is like the dual of compilation. And trying to keep the output on a single line, Rather than printing the compiler name, I think printing the compilation level is more useful, as well as including some info about whether it was an osr compilation maybe. The `jit+compilation` log messages do the latter by printing an extra `%`. Maybe something like: @ -> The instruction and line number could also be incorporated somewhere, but the compilation messages don't have them either. They seem fine to leave out I think. Also, I noticed that `jit+compilation` has the `debug` level, so maybe this log message should be under the `debug` level as well, instead of `info`. I don't know if there is any guidance on that somewhere. src/hotspot/share/runtime/deoptimization.cpp line 1935: > 1933: JFR_ONLY(post_deoptimization_event(nm, trap_method(), trap_bci, trap_bc, reason, action);) > 1934: > 1935: if(Log(deoptimization)::is_info()) { I don't see this pattern used for checking whether a log tag is enabled used elsewhere. Won't this only print when the log level is exactly `info`? The pattern I see used elsewhere is: LogTarget(Info, ) lt; if (lt.is_enabled()) { ... } ------------- PR: https://git.openjdk.java.net/jdk/pull/8812 From duke at openjdk.java.net Fri May 20 19:10:59 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Fri, 20 May 2022 19:10:59 GMT Subject: RFR: 8284849: Add deoptimization to unified logging In-Reply-To: References: Message-ID: <9R1trLE21iHR17zvAadP9x5MF1A2oAAj5jqAB6tRYuQ=.3e22ce7d-e80b-452f-bac6-91f4241a8c57@github.com> On Fri, 20 May 2022 16:38:55 GMT, Jorn Vernee wrote: >> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important). >> >> An example output looks like this: >> >> >> [1.346s][info][deoptimization] Deoptimization start { >> [1.346s][info][deoptimization] compileId = 407 >> [1.346s][info][deoptimization] compiler = c2 >> [1.346s][info][deoptimization] method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26 >> [1.346s][info][deoptimization] instruction = ifne >> [1.346s][info][deoptimization] reason = unstable_if >> [1.346s][info][deoptimization] action = reinterpret >> [1.346s][info][deoptimization] } Deoptimization end > > src/hotspot/share/runtime/deoptimization.cpp line 1935: > >> 1933: JFR_ONLY(post_deoptimization_event(nm, trap_method(), trap_bci, trap_bc, reason, action);) >> 1934: >> 1935: if(Log(deoptimization)::is_info()) { > > I don't see this pattern used for checking whether a log tag is enabled used elsewhere. Won't this only print when the log level is exactly `info`? > > The pattern I see used elsewhere is: > > > LogTarget(Info, ) lt; > if (lt.is_enabled()) { > ... > } This does the same thing. `is_enabled` calls `is_level` internally. I did it this way so that we have a temporary value instead of cluttering the outer scope. ------------- PR: https://git.openjdk.java.net/jdk/pull/8812 From lmesnik at openjdk.java.net Fri May 20 20:09:59 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Fri, 20 May 2022 20:09:59 GMT Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled [v2] In-Reply-To: References: Message-ID: > The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview. > > It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: 2nd v ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8589/files - new: https://git.openjdk.java.net/jdk/pull/8589/files/3e0c6ee6..726e7dcc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8589&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8589&range=00-01 Stats: 14 lines in 3 files changed: 5 ins; 5 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8589.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8589/head:pull/8589 PR: https://git.openjdk.java.net/jdk/pull/8589 From lmesnik at openjdk.java.net Fri May 20 20:14:59 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Fri, 20 May 2022 20:14:59 GMT Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled [v2] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 20:09:59 GMT, Leonid Mesnik wrote: >> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview. >> >> It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > 2nd v After discussion with @sspitsyn and more testing, I realized that it is not enough to disable EA with some capabilities. The IterateHeap requires a capability which is enabled by default. Moreover, code might be compiled before the agent requests any caps. So the new proposed fix is to apply EscapeBarriers for platform threads only. For virtual threads, the behavior is the same as before JDK-8227745. This should be fixed by https://bugs.openjdk.java.net/browse/JDK-8264699 The fix has been pushed into loom repo already and it is a backport: https://github.com/openjdk/loom/commit/6520b71a62baf64d214ff94c9291bfc513dfbe51 ------------- PR: https://git.openjdk.java.net/jdk/pull/8589 From kvn at openjdk.java.net Fri May 20 20:20:56 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 20 May 2022 20:20:56 GMT Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled [v2] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 20:09:59 GMT, Leonid Mesnik wrote: >> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview. >> >> It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > 2nd v Update is good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8589 From kvn at openjdk.java.net Fri May 20 22:56:45 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 20 May 2022 22:56:45 GMT Subject: RFR: 8272791: java -XX:BlockZeroingLowLimit=1 crashes after 8270947 [v2] In-Reply-To: References: Message-ID: <2qkTt4Kk1RH5d8JuLpvIplagG0-ZwAih-WlUmbAPPz8=.abca6aaa-1f0c-4034-a508-676573fae6b0@github.com> On Thu, 19 May 2022 16:46:35 GMT, Andrew Haley wrote: >> This is an assertion failure caused by setting `BlockZeroingLowLimit` < `wordSize`. >> >> I believe there was some confusion when writing this code about whether `BlockZeroingLowLimit` should be in words or bytes, and it makes no sense for it to be less than a single word. If anyone ever tried to use a parameter < 8, it triggers an assertion. >> >> This patch does two things. Firstly, it corrects a `guarantee` which erroneously used `zero_words_block_size` rather than `wordSize`. The value of both of these is 8, so it doesn't change anything in the generated code. Secondly, it clips the `BlockZeroingLowLimit` so that it doesn't trigger the assertion. >> >> Perhaps it would be better to change the lower limit to 8 instead of this silent correction. There is no backward compatibility issue here, because any attempt to set `BlockZeroingLowLimit` < 8 in the past would have exited the VM with an error, so I don't believe a CSR is warranted if we do change the allowable range. >> >> So, which should it be? Change the lower limit of the range of the `BlockZeroingLowLimit` system flag, or allow 1 still to be used and silently fix it? Opinions welcome. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Better Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8756 From sspitsyn at openjdk.java.net Sat May 21 02:39:40 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Sat, 21 May 2022 02:39:40 GMT Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled [v2] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 20:09:59 GMT, Leonid Mesnik wrote: >> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview. >> >> It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > 2nd v Hi Leonid, Thank you a lot for taking care about this! Looks good to me (according to our private agreement). My understanding is that this changeset fixes a test regression. Could you, please, list this test being fixed in the bug report? Also, you said there was a related bug/rfe filed to fully disable EA when continuations and related JVMTI capabilities are enabled. Could you, please, link this bug/rfe to current bug? Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8589 From lmesnik at openjdk.java.net Sat May 21 04:03:57 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Sat, 21 May 2022 04:03:57 GMT Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled [v2] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 20:09:59 GMT, Leonid Mesnik wrote: >> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview. >> >> It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > 2nd v This change fixes regression of platform threads behavior with --enabled-preview enabled. However, the info for virtual threads might be incorrect if EA is enabled. The issue [JDK-8264699](https://bugs.openjdk.java.net/browse/JDK-8264699) Re-examine deopt of frames to allow EA be enabled with JVMTI agents should cover it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8589 From lmesnik at openjdk.java.net Sat May 21 04:08:34 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Sat, 21 May 2022 04:08:34 GMT Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled [v2] In-Reply-To: References: Message-ID: <7x6MdIPrpfZWybpyJ1rm6A5CTmlog2dB9IUvZbVUl1U=.5cc393e9-9456-4c0e-a01b-f086ebd1cd70@github.com> On Fri, 20 May 2022 20:09:59 GMT, Leonid Mesnik wrote: >> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview. >> >> It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > 2nd v Affected tests are: serviceability/jvmti/Heap/IterateHeapWithEscapeAnalysisEnabled.java com/sun/jdi/EATests.java#id0 The pass in jdk/jdk because --enable-preview is not enabled but failed before fix in fibers branch where --enable-preview is enabled by default. The should pass with --enabled-preview after fix. The are removed from problemlist in fibers branch in the fix: https://github.com/openjdk/loom/commit/6520b71a62baf64d214ff94c9291bfc513dfbe51 ------------- PR: https://git.openjdk.java.net/jdk/pull/8589 From rrich at openjdk.java.net Sat May 21 12:17:56 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Sat, 21 May 2022 12:17:56 GMT Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled [v2] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 20:09:59 GMT, Leonid Mesnik wrote: >> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview. >> >> It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > 2nd v Hi Leonid, if EscapeAnalysis is not disabled, then local objects cannot be read per JVMTI if they are scalarized in compiled frames on the heap, right? This would be a problem I'd think. Thanks, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/8589 From ysuenaga at openjdk.java.net Sat May 21 13:11:45 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sat, 21 May 2022 13:11:45 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v7] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 13:32:42 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > revert changes for memnode.cpp and type.cpp In case of stringop-overflow errors (bytecodeAssembler.cpp, classFileParser.cpp, symbolTable.cpp) noted that offset of `Array::_data` might be [-2147483648, -1]. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From lmesnik at openjdk.java.net Sat May 21 16:12:50 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Sat, 21 May 2022 16:12:50 GMT Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled [v2] In-Reply-To: References: Message-ID: On Sat, 21 May 2022 12:14:11 GMT, Richard Reingruber wrote: > Hi Leonid, if EscapeAnalysis is not disabled, then local objects cannot be read per JVMTI if they are scalarized in compiled frames on the heap, right? This would be a problem I'd think. Thanks, Richard. Yes, the fix restores correct behavior for platform threads if --enable-preview is on. The [JDK-8285739](https://bugs.openjdk.java.net/browse/JDK-8285739) should fix this for virtual threads. And as test serviceability/jvmti/Heap/IterateHeapWithEscapeAnalysisEnabled.java demonstrates there are might be methods which compiled with EA before JVMTI agent require capabilities. I incorrectly tested my previous fix, it really doesn't pass serviceability/jvmti/Heap/IterateHeapWithEscapeAnalysisEnabled.java test with --enable-preview. ------------- PR: https://git.openjdk.java.net/jdk/pull/8589 From kvn at openjdk.java.net Sat May 21 16:24:47 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Sat, 21 May 2022 16:24:47 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: <_dBsdBgrBsVJpJDjL3011rFuIBmKThg5kL2dU4GNDKk=.47b4e7c8-6032-4954-a16d-59c5aeac0516@github.com> On Mon, 16 May 2022 15:52:22 GMT, olivergillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. I did standalone runs of sub-benchmarks several times to get best results. Some of them show 2 sets of results: fast and slow. `crypto.aes` and `crypto.rsa` one of them. I suspect it is caused by difference in code generation (slightly different profiling and inlining) and nothing to do with AVX setting. I did see (termal?/turbo boost?) effects if I run benchmarks without pause between them. So I kept system idle for about 10 min between runs. I did not re-run benchmarks if difference was < 3%. We need to look what is going on with `mpegaudio` and `scimark.lu.small`. And also test with Parallel GC. SEPCjvm2008_avx2_vs_avx512_qrtr_separate ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From kbarrett at openjdk.java.net Sun May 22 03:18:48 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 22 May 2022 03:18:48 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 12:38:55 GMT, Yasumasa Suenaga wrote: >> src/hotspot/share/classfile/classFileParser.cpp line 5970: >> >>> 5968: PRAGMA_STRINGOP_OVERFLOW_IGNORED >>> 5969: _cp->symbol_at_put(hidden_index, _class_name); >>> 5970: PRAGMA_DIAG_POP >> >> I don't understand these warning suppressions for symbol_at_put (here and elsewhere). I don't see any stringops here. What is the compiler complaining about? (There's no mention of classfile stuff in the review cover message.) > > Like the others, it is caused by `Array::at_put()`. > > > In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/annotations.hpp:28, > from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/instanceKlass.hpp:29, > from /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/javaClasses.hpp:30, > from /home/ysuenaga/github-forked/jdk/src/hotspot/share/precompiled/precompiled.hpp:35: > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::symbol_at_put(int, Symbol*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:362:15, > inlined from 'void ClassFileParser::mangle_hidden_class_name(InstanceKlass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/classFileParser.cpp:5966:21: `Array::_data` is a pseudo flexible array member. "Pseudo" because C++ doesn't have flexible array members. The compiler is completely justified in complaining about the apparently out-of-bounds accesses. There is a "well-known" (though moderately ugly) approach to doing flexible array members in C++. Something like this: T* data() { return reinterpret_cast( reinterpret_cast(this) + data_offset()); } where `data_offset()` is new and private: static size_t data_offset() { return offset_of(Array, _data); } Use `data()` everywhere instead of using `_data` directly. There are other places in HotSpot that use this kind of approach. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Sun May 22 05:03:57 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 22 May 2022 05:03:57 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Tue, 17 May 2022 12:43:02 GMT, Yasumasa Suenaga wrote: >> src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp line 103: >> >>> 101: PRAGMA_STRINGOP_OVERFLOW_IGNORED >>> 102: *dest = op(bits, *dest); >>> 103: PRAGMA_DIAG_POP >> >> I see no stringop here. I'm still trying to understand what the compiler is complaining about. > > I guess GCC cannot understand `assert(dest != NULL` immediately preceding it. > > > In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp:33, > from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:30, > from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:30: > In function 'void set_form(jbyte, jbyte*) [with jbyte (* op)(jbyte, jbyte) = traceid_or]', > inlined from 'void set(jbyte, jbyte*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:129:23, > inlined from 'static void JfrTraceIdBits::store(jbyte, const T*) [with T = Klass]' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:135:6, > inlined from 'static void JfrTraceId::tag_as_jdk_jfr_event(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:106:3, > inlined from 'static void JdkJfrEvent::tag_as(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:176:35: I don't think this warning has anything to do with that NULL check. But I'm still not understanding what it is warning about. The "region of size 0" part of the warning message seems important, but I'm not (yet?) seeing how it could be coming up with that. The code involved here is pretty contorted... ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Sun May 22 08:40:28 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sun, 22 May 2022 08:40:28 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v8] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga 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 remote-tracking branch 'upstream/master' into gcc12-warnings - Use getter function to access "_data" - Revert changes for bytecodeAssembler.cpp, classFileParser.cpp, symbolTable.cpp - revert changes for memnode.cpp and type.cpp - Add assert to check the range of BasicType - Merge remote-tracking branch 'upstream/master' into HEAD - Revert change for java.c , parse_manifest.c , LinuxPackage.c - Calculate char offset before realloc() - Use return value from JLI_Snprintf - Avoid pragma error in before GCC 12 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/c156bcc5...042c1c70 ------------- Changes: https://git.openjdk.java.net/jdk/pull/8646/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=07 Stats: 42 lines in 7 files changed: 26 ins; 1 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Sun May 22 08:40:28 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sun, 22 May 2022 08:40:28 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Sun, 22 May 2022 03:15:20 GMT, Kim Barrett wrote: >> Like the others, it is caused by `Array::at_put()`. >> >> >> In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/annotations.hpp:28, >> from /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/instanceKlass.hpp:29, >> from /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/javaClasses.hpp:30, >> from /home/ysuenaga/github-forked/jdk/src/hotspot/share/precompiled/precompiled.hpp:35: >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::symbol_at_put(int, Symbol*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:362:15, >> inlined from 'void ClassFileParser::mangle_hidden_class_name(InstanceKlass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/classFileParser.cpp:5966:21: > > `Array::_data` is a pseudo flexible array member. "Pseudo" because C++ > doesn't have flexible array members. The compiler is completely justified in > complaining about the apparently out-of-bounds accesses. > > There is a "well-known" (though moderately ugly) approach to doing flexible > array members in C++. Something like this: > > > T* data() { > return reinterpret_cast( > reinterpret_cast(this) + data_offset()); > } > > > where `data_offset()` is new and private: > > > static size_t data_offset() { > return offset_of(Array, _data); > } > > > Use `data()` everywhere instead of using `_data` directly. > > There are other places in HotSpot that use this kind of approach. Thanks @kimbarrett for your advice! Warnings from array.hpp have gone with your suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Sun May 22 08:48:47 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sun, 22 May 2022 08:48:47 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Sun, 22 May 2022 05:00:21 GMT, Kim Barrett wrote: >> I guess GCC cannot understand `assert(dest != NULL` immediately preceding it. >> >> >> In file included from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp:33, >> from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:30, >> from /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:30: >> In function 'void set_form(jbyte, jbyte*) [with jbyte (* op)(jbyte, jbyte) = traceid_or]', >> inlined from 'void set(jbyte, jbyte*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:129:23, >> inlined from 'static void JfrTraceIdBits::store(jbyte, const T*) [with T = Klass]' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp:135:6, >> inlined from 'static void JfrTraceId::tag_as_jdk_jfr_event(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp:106:3, >> inlined from 'static void JdkJfrEvent::tag_as(const Klass*)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/jfr/support/jfrJdkJfrEvent.cpp:176:35: > > I don't think this warning has anything to do with that NULL check. But I'm > still not understanding what it is warning about. The "region of size 0" part > of the warning message seems important, but I'm not (yet?) seeing how it could > be coming up with that. The code involved here is pretty contorted... It might be GCC bug... https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 This issue is for integer literal, but [Comment 29](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c29) mentions address calculation (e.g. `NULL + offset`) - it is similar the problem in jfrTraceIdBits.inline.hp because `dest` comes from `low_addr()` (`addr + low_offset`). ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Sun May 22 16:44:58 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 22 May 2022 16:44:58 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: <3CBxbI5futoRYrvWQY5-0hUsWNb8fsZWF2goyqFOgY0=.0328a1d2-126e-4f5f-a6d7-ba638499eefd@github.com> On Sun, 22 May 2022 08:35:54 GMT, Yasumasa Suenaga wrote: >> `Array::_data` is a pseudo flexible array member. "Pseudo" because C++ >> doesn't have flexible array members. The compiler is completely justified in >> complaining about the apparently out-of-bounds accesses. >> >> There is a "well-known" (though moderately ugly) approach to doing flexible >> array members in C++. Something like this: >> >> >> T* data() { >> return reinterpret_cast( >> reinterpret_cast(this) + data_offset()); >> } >> >> >> where `data_offset()` is new and private: >> >> >> static size_t data_offset() { >> return offset_of(Array, _data); >> } >> >> >> Use `data()` everywhere instead of using `_data` directly. >> >> There are other places in HotSpot that use this kind of approach. > > Thanks @kimbarrett for your advice! Warnings from array.hpp have gone with your suggestion. Good. I see you found and used the existing `base_offset_in_bytes` (which I'd overlooked), rather than using my suggested `data_offset`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Sun May 22 16:48:42 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 22 May 2022 16:48:42 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: On Sun, 22 May 2022 08:45:48 GMT, Yasumasa Suenaga wrote: >> I don't think this warning has anything to do with that NULL check. But I'm >> still not understanding what it is warning about. The "region of size 0" part >> of the warning message seems important, but I'm not (yet?) seeing how it could >> be coming up with that. The code involved here is pretty contorted... > > It might be GCC bug... > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 > > This issue is for integer literal, but [Comment 29](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c29) mentions address calculation (e.g. `NULL + offset`) - it is similar the problem in jfrTraceIdBits.inline.hp because `dest` comes from `low_addr()` (`addr + low_offset`). I don't see the similarity. That gcc bug is about literals used as addresses, which get treated (suggested inappropriately) as NULL+offset, with NULL+offset being a cause of warnings. I don't see that happening in our case. That is, in our `addr + low_offset`, `addr` doesn't seem to be either a literal or NULL that I can see. It's hard for me to investigate this any further just by perusing the code, so I'm in the process of getting set up to build with gcc12.x. That will let me do some experiments. It may take me a few days to get to that point though. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From coleenp at openjdk.java.net Mon May 23 01:37:47 2022 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 23 May 2022 01:37:47 GMT Subject: RFR: 8287044: Loom: Incorrect StackChunk::pc accessors In-Reply-To: <-Rpu2W3YyBXsY0TWY0M5h9HLsHmBxsR6WGkT5jNs0ZA=.5a5b98f2-90a1-4a6f-b16c-18de0c2c1724@github.com> References: <-Rpu2W3YyBXsY0TWY0M5h9HLsHmBxsR6WGkT5jNs0ZA=.5a5b98f2-90a1-4a6f-b16c-18de0c2c1724@github.com> Message-ID: On Thu, 19 May 2022 17:53:12 GMT, Aleksey Shipilev wrote: > The injected field is defined as: > > > macro(jdk_internal_vm_StackChunk, pc, intptr_signature, false) \ > > > ...yet it is read and written as "long", which silently overwrites adjacent fields in `StackChunk` on 32-bit platforms. This is a blocker for any 32-bit support. There are plenty of other `intptr` injected fields in other classes (e.g. `Class::array_klass`), and they are properly accessed by "address" accessors. > > Additional testing: > - [x] Linux x86_64 fastdebug, prospective `jdk_loom hotspot_loom` > - [x] Linux AArch64 fastdebug, prospective `jdk_loom hotspot_loom` > - [x] Linux x86_32 fastdebug experimental port is not broken here anymore Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8792 From dholmes at openjdk.java.net Mon May 23 02:17:48 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 23 May 2022 02:17:48 GMT Subject: RFR: 8286711: AArch64: serviceability agent tests fail with PAC enabled In-Reply-To: References: Message-ID: <1ztZlywZcqdvzY9foCeL_jsW9V59Rono5AeGiCoNH3g=.4d00dada-c27c-48ce-a95c-7647472e47bc@github.com> On Fri, 20 May 2022 15:52:04 GMT, Nick Gasson wrote: > When the VM is run with `-XX:UseBranchProtection=pac-ret` on a supported CPU, the upper bits of the saved link register contain a "pointer authentication code" which must be checked and removed by a special instruction before a function returns. The serviceability agent is unaware of this and so sees garbled PC values when walking the stack. This patch just masks out the PAC bits from the sender PC after reading it from the stack frame. That all seems reasonable to me. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8814 From dholmes at openjdk.java.net Mon May 23 02:51:46 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 23 May 2022 02:51:46 GMT Subject: RFR: 8286891: thread_local causes undefined symbol error with XL C In-Reply-To: References: Message-ID: On Tue, 17 May 2022 15:56:28 GMT, Tyler Steele wrote: > When using XLClang++ to compile a `thread_local` struct with a destructor, a compiler bug is exposed that results in a missing constructor and a linker error. > > Adding the missing constructor solves this issue. > > Changes > - Builds on AIX (previously broken) src/hotspot/share/prims/universalUpcallHandler.cpp line 51: > 49: #ifdef _AIX > 50: UpcallContext() {} > 51: #endif I'd prefer for this to not be AIX specific. Adding an explicit empty constructor seems harmless enough - with a comment of course e.g. UpCallContext() {} // Explicit constructor to avoid potential xlc compiler bug @JornVernee what do you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/8754 From shade at openjdk.java.net Mon May 23 05:43:04 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 May 2022 05:43:04 GMT Subject: RFR: 8287044: Loom: Incorrect StackChunk::pc accessors In-Reply-To: <-Rpu2W3YyBXsY0TWY0M5h9HLsHmBxsR6WGkT5jNs0ZA=.5a5b98f2-90a1-4a6f-b16c-18de0c2c1724@github.com> References: <-Rpu2W3YyBXsY0TWY0M5h9HLsHmBxsR6WGkT5jNs0ZA=.5a5b98f2-90a1-4a6f-b16c-18de0c2c1724@github.com> Message-ID: <7auc2F0WifisJ0bjUZDS6sHoGCrC0fcaFRsDXxOTH4g=.d8644ae7-98f7-4429-a8a5-e6d9e8e29db9@github.com> On Thu, 19 May 2022 17:53:12 GMT, Aleksey Shipilev wrote: > The injected field is defined as: > > > macro(jdk_internal_vm_StackChunk, pc, intptr_signature, false) \ > > > ...yet it is read and written as "long", which silently overwrites adjacent fields in `StackChunk` on 32-bit platforms. This is a blocker for any 32-bit support. There are plenty of other `intptr` injected fields in other classes (e.g. `Class::array_klass`), and they are properly accessed by "address" accessors. > > Additional testing: > - [x] Linux x86_64 fastdebug, prospective `jdk_loom hotspot_loom` > - [x] Linux AArch64 fastdebug, prospective `jdk_loom hotspot_loom` > - [x] Linux x86_32 fastdebug experimental port is not broken here anymore Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8792 From shade at openjdk.java.net Mon May 23 05:43:05 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 May 2022 05:43:05 GMT Subject: Integrated: 8287044: Loom: Incorrect StackChunk::pc accessors In-Reply-To: <-Rpu2W3YyBXsY0TWY0M5h9HLsHmBxsR6WGkT5jNs0ZA=.5a5b98f2-90a1-4a6f-b16c-18de0c2c1724@github.com> References: <-Rpu2W3YyBXsY0TWY0M5h9HLsHmBxsR6WGkT5jNs0ZA=.5a5b98f2-90a1-4a6f-b16c-18de0c2c1724@github.com> Message-ID: <5C1tFb2JPJ6uxhnmjQiJ5BNvnNAY7ZpzaoswOzqxSGw=.52e9288b-7175-4d21-8264-4c9cdbac2fdc@github.com> On Thu, 19 May 2022 17:53:12 GMT, Aleksey Shipilev wrote: > The injected field is defined as: > > > macro(jdk_internal_vm_StackChunk, pc, intptr_signature, false) \ > > > ...yet it is read and written as "long", which silently overwrites adjacent fields in `StackChunk` on 32-bit platforms. This is a blocker for any 32-bit support. There are plenty of other `intptr` injected fields in other classes (e.g. `Class::array_klass`), and they are properly accessed by "address" accessors. > > Additional testing: > - [x] Linux x86_64 fastdebug, prospective `jdk_loom hotspot_loom` > - [x] Linux AArch64 fastdebug, prospective `jdk_loom hotspot_loom` > - [x] Linux x86_32 fastdebug experimental port is not broken here anymore This pull request has now been integrated. Changeset: 9008cfad Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/9008cfad45346af570a765335846b0b4fe9af4b6 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod 8287044: Loom: Incorrect StackChunk::pc accessors Reviewed-by: rpressler, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/8792 From shade at openjdk.java.net Mon May 23 05:47:48 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 May 2022 05:47:48 GMT Subject: RFR: 8286956: Loom: Define test groups for development/porting use In-Reply-To: References: Message-ID: On Wed, 18 May 2022 11:10:58 GMT, Aleksey Shipilev wrote: > It would be beneficial to bring over the Loom-specific test groups from the loom repo to aid development/porting work. > > https://github.com/openjdk/loom/blob/fibers/test/jdk/TEST.groups#L97-L108 > https://github.com/openjdk/loom/blob/6f42923b3342e41d95b262733205283068802b40/test/hotspot/jtreg/TEST.groups#L111-L125 > > I had to drop `jdk/incubator/concurrent` from JDK definition, because there are no tests in that folder and tests break. > > Additional testing: > - [x] Linux x86_64 fastdebug `hotspot_loom jdk_loom` > - [x] Linux AArch64 fastdebug `hotspot_loom jdk_loom` Anyone? ------------- PR: https://git.openjdk.java.net/jdk/pull/8765 From rehn at openjdk.java.net Mon May 23 06:08:43 2022 From: rehn at openjdk.java.net (Robbin Ehn) Date: Mon, 23 May 2022 06:08:43 GMT Subject: RFR: 8286825: Linker naming cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 10:57:44 GMT, Jorn Vernee wrote: >> This patch is a batch naming cleanup for the foreign linker implementation. >> >> The naming changes are as follows: >> >> - ProgrammableInvoker -> DowncallLinker >> - ProgrammableUpcallHandler -> UpcallLinker >> - 'native invoker' -> 'downcall stub' >> - 'optimzed entry blob' -> 'upcall stub' >> - OptimizedEntryBlob -> UpcallStub >> - optimized_entry_frame -> upcall_stub_frame >> >> Then renaming of some hotspot files: >> >> - universalNativeInvoker* -> downcallLinker* >> - universalUpcallHandler* -> upcallLinker* >> - foreign_globals* -> foreignGlobals* (to match existing convention) >> >> Method, field, and other variable names are also adjusted accordingly. >> >> Testing: Tier 1-4 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Comments + cleanup Note that some find downcall/upcall unintuitive. We may need revisit this. Thanks ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8777 From dholmes at openjdk.java.net Mon May 23 06:41:40 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 23 May 2022 06:41:40 GMT Subject: RFR: 8286262: Windows: Cleanup deprecation warning suppression In-Reply-To: References: Message-ID: On Sun, 15 May 2022 20:50:25 GMT, Kim Barrett wrote: > Please review this cleanup of deprecation warning suppression when building > for Windows. > > This change consists of several parts. > > (1) Remove the global deprecation warning suppression when building HotSpot > for Windows. > > (2) Add macro definitions requesting suppression of selected sets of > deprecation warnings when building HotSpot for Windows. > > (3) Remove unnecessary forwarding macros for various POSIX functions in > globalDefinitions_visCPP.hpp. These were provided to avoid deprecation > warnings (that were previously also being suppressed by the global request). > They are now covered by the new macros provided by change (2) above. > > An alternative to item (3) is to not define _CRT_NONSTDC_NO_DEPRECATE (in item > (2)) and either retain the forwarding macros or define os:: wrapper functions > for all of the affected functions. We might eventually do the latter because > of other reasons for avoiding some of these functions, but the approach being > taken here is simpler. > > For documentation of _CRT_NONSTDC_NO_DEPRECATE, see: > https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility > https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4996 > > Similarly for _CRT_SECURE_NO_WARNINGS. > > Perhaps similarly for _WINSOCK_DEPRECATED_NO_WARNINGS (though I didn't find > any documentation for the latter). But it might be better to not supress the > warnings and instead use the alternatives (JDK-8286781). > > Testing: > mach5 tier1 All seems quite reasonable. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8718 From mbaesken at openjdk.java.net Mon May 23 06:47:43 2022 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Mon, 23 May 2022 06:47:43 GMT Subject: RFR: 8286891: thread_local causes undefined symbol error with XL C In-Reply-To: References: Message-ID: On Tue, 17 May 2022 15:56:28 GMT, Tyler Steele wrote: > When using XLClang++ to compile a `thread_local` struct with a destructor, a compiler bug is exposed that results in a missing constructor and a linker error. > > Adding the missing constructor solves this issue. > > Changes > - Builds on AIX (previously broken) Please adjust the copyright year. Otherwise looks good to me. ------------- Marked as reviewed by mbaesken (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8754 From dholmes at openjdk.java.net Mon May 23 07:28:54 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 23 May 2022 07:28:54 GMT Subject: RFR: 8284849: Add deoptimization to unified logging In-Reply-To: <9R1trLE21iHR17zvAadP9x5MF1A2oAAj5jqAB6tRYuQ=.3e22ce7d-e80b-452f-bac6-91f4241a8c57@github.com> References: <9R1trLE21iHR17zvAadP9x5MF1A2oAAj5jqAB6tRYuQ=.3e22ce7d-e80b-452f-bac6-91f4241a8c57@github.com> Message-ID: On Fri, 20 May 2022 19:06:55 GMT, Johan Sj?l?n wrote: >> src/hotspot/share/runtime/deoptimization.cpp line 1935: >> >>> 1933: JFR_ONLY(post_deoptimization_event(nm, trap_method(), trap_bci, trap_bc, reason, action);) >>> 1934: >>> 1935: if(Log(deoptimization)::is_info()) { >> >> I don't see this pattern used for checking whether a log tag is enabled used elsewhere. Won't this only print when the log level is exactly `info`? >> >> The pattern I see used elsewhere is: >> >> >> LogTarget(Info, ) lt; >> if (lt.is_enabled()) { >> ... >> } > > This does the same thing. `is_enabled` calls `is_level` internally. I did it this way so that we have a temporary value instead of cluttering the outer scope. Using a `LogMessage` instead of a `LogTarget` is very rarely used in the codebase. I have no idea what the pros and cons of each are, nor can I find any guidance on which to use when. ------------- PR: https://git.openjdk.java.net/jdk/pull/8812 From dholmes at openjdk.java.net Mon May 23 07:28:55 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 23 May 2022 07:28:55 GMT Subject: RFR: 8284849: Add deoptimization to unified logging In-Reply-To: References: <9R1trLE21iHR17zvAadP9x5MF1A2oAAj5jqAB6tRYuQ=.3e22ce7d-e80b-452f-bac6-91f4241a8c57@github.com> Message-ID: On Mon, 23 May 2022 07:22:06 GMT, David Holmes wrote: >> This does the same thing. `is_enabled` calls `is_level` internally. I did it this way so that we have a temporary value instead of cluttering the outer scope. > > Using a `LogMessage` instead of a `LogTarget` is very rarely used in the codebase. I have no idea what the pros and cons of each are, nor can I find any guidance on which to use when. Also style nit: space after if please. ------------- PR: https://git.openjdk.java.net/jdk/pull/8812 From dholmes at openjdk.java.net Mon May 23 07:28:58 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 23 May 2022 07:28:58 GMT Subject: RFR: 8284849: Add deoptimization to unified logging In-Reply-To: References: Message-ID: On Fri, 20 May 2022 14:12:30 GMT, Johan Sj?l?n wrote: > This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important). > > An example output looks like this: > > > [1.346s][info][deoptimization] Deoptimization start { > [1.346s][info][deoptimization] compileId = 407 > [1.346s][info][deoptimization] compiler = c2 > [1.346s][info][deoptimization] method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26 > [1.346s][info][deoptimization] instruction = ifne > [1.346s][info][deoptimization] reason = unstable_if > [1.346s][info][deoptimization] action = reinterpret > [1.346s][info][deoptimization] } Deoptimization end src/hotspot/share/runtime/deoptimization.cpp line 1937: > 1935: if(Log(deoptimization)::is_info()) { > 1936: LogMessage(deoptimization) lm; > 1937: auto tm = trap_method(); Not sure use if C++11 type inference is a permitted use - I can't find it n the style guide. src/hotspot/share/runtime/deoptimization.cpp line 1938: > 1936: LogMessage(deoptimization) lm; > 1937: auto tm = trap_method(); > 1938: lm.info("Deoptimization start {"); Do we use this brace style for other log messages? I'm not really seeing the need for a start/end delimiter here. ------------- PR: https://git.openjdk.java.net/jdk/pull/8812 From duke at openjdk.java.net Mon May 23 08:35:53 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Mon, 23 May 2022 08:35:53 GMT Subject: RFR: 8284849: Add deoptimization to unified logging In-Reply-To: References: Message-ID: On Mon, 23 May 2022 07:22:10 GMT, David Holmes wrote: >> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important). >> >> An example output looks like this: >> >> >> [1.346s][info][deoptimization] Deoptimization start { >> [1.346s][info][deoptimization] compileId = 407 >> [1.346s][info][deoptimization] compiler = c2 >> [1.346s][info][deoptimization] method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26 >> [1.346s][info][deoptimization] instruction = ifne >> [1.346s][info][deoptimization] reason = unstable_if >> [1.346s][info][deoptimization] action = reinterpret >> [1.346s][info][deoptimization] } Deoptimization end > > src/hotspot/share/runtime/deoptimization.cpp line 1937: > >> 1935: if(Log(deoptimization)::is_info()) { >> 1936: LogMessage(deoptimization) lm; >> 1937: auto tm = trap_method(); > > Not sure use if C++11 type inference is a permitted use - I can't find it n the style guide. `LogMessage` ensures that messages are kept in order in the final output, but this is not needed if we're logging on one line as Jorn has suggested. I'm also removing the type inference. ------------- PR: https://git.openjdk.java.net/jdk/pull/8812 From tschatzl at openjdk.java.net Mon May 23 08:53:31 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 23 May 2022 08:53:31 GMT Subject: RFR: 8287138: Make VerifyOption an enum class Message-ID: Hi all, please review this change that make the `VerifyOption` enum an enum class as suggested in the review for [JDK-8189669](https://bugs.openjdk.java.net/browse/JDK-8189669). Testing: local compilation, gha Thanks, Thomas ------------- Commit messages: - 8287138: Make VerifyOption an enum class Changes: https://git.openjdk.java.net/jdk/pull/8832/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8832&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287138 Stats: 28 lines in 8 files changed: 3 ins; 0 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/8832.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8832/head:pull/8832 PR: https://git.openjdk.java.net/jdk/pull/8832 From jvernee at openjdk.java.net Mon May 23 09:24:55 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 23 May 2022 09:24:55 GMT Subject: RFR: 8286891: thread_local causes undefined symbol error with XL C In-Reply-To: References: Message-ID: On Mon, 23 May 2022 02:48:51 GMT, David Holmes wrote: >> When using XLClang++ to compile a `thread_local` struct with a destructor, a compiler bug is exposed that results in a missing constructor and a linker error. >> >> Adding the missing constructor solves this issue. >> >> Changes >> - Builds on AIX (previously broken) > > src/hotspot/share/prims/universalUpcallHandler.cpp line 51: > >> 49: #ifdef _AIX >> 50: UpcallContext() {} >> 51: #endif > > I'd prefer for this to not be AIX specific. Adding an explicit empty constructor seems harmless enough - with a comment of course e.g. > > UpCallContext() {} // Explicit constructor to avoid potential xlc compiler bug > > @JornVernee what do you think? Yeah, that seems better to me as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/8754 From mdoerr at openjdk.java.net Mon May 23 09:24:56 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 23 May 2022 09:24:56 GMT Subject: RFR: 8286891: thread_local causes undefined symbol error with XL C In-Reply-To: References: Message-ID: <2rSL-OYXjIp9Yz_Z4Qbdxlra2Bt-AsVgLnz0M_cHR9c=.caf441f5-5f51-4b97-8826-025708168e71@github.com> On Mon, 23 May 2022 09:21:21 GMT, Jorn Vernee wrote: >> src/hotspot/share/prims/universalUpcallHandler.cpp line 51: >> >>> 49: #ifdef _AIX >>> 50: UpcallContext() {} >>> 51: #endif >> >> I'd prefer for this to not be AIX specific. Adding an explicit empty constructor seems harmless enough - with a comment of course e.g. >> >> UpCallContext() {} // Explicit constructor to avoid potential xlc compiler bug >> >> @JornVernee what do you think? > > Yeah, that seems better to me as well. +1 ------------- PR: https://git.openjdk.java.net/jdk/pull/8754 From stefank at openjdk.java.net Mon May 23 09:26:57 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 23 May 2022 09:26:57 GMT Subject: RFR: 8287138: Make VerifyOption an enum class In-Reply-To: References: Message-ID: On Mon, 23 May 2022 08:45:12 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that make the `VerifyOption` enum an enum class as suggested in the review for [JDK-8189669](https://bugs.openjdk.java.net/browse/JDK-8189669). > > Testing: local compilation, gha > > Thanks, > Thomas Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8832 From kbarrett at openjdk.java.net Mon May 23 09:26:58 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 23 May 2022 09:26:58 GMT Subject: RFR: 8287138: Make VerifyOption an enum class In-Reply-To: References: Message-ID: On Mon, 23 May 2022 08:45:12 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that make the `VerifyOption` enum an enum class as suggested in the review for [JDK-8189669](https://bugs.openjdk.java.net/browse/JDK-8189669). > > Testing: local compilation, gha > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8832 From jvernee at openjdk.java.net Mon May 23 09:52:49 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 23 May 2022 09:52:49 GMT Subject: RFR: 8286825: Linker naming cleanup [v2] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 10:57:44 GMT, Jorn Vernee wrote: >> This patch is a batch naming cleanup for the foreign linker implementation. >> >> The naming changes are as follows: >> >> - ProgrammableInvoker -> DowncallLinker >> - ProgrammableUpcallHandler -> UpcallLinker >> - 'native invoker' -> 'downcall stub' >> - 'optimzed entry blob' -> 'upcall stub' >> - OptimizedEntryBlob -> UpcallStub >> - optimized_entry_frame -> upcall_stub_frame >> >> Then renaming of some hotspot files: >> >> - universalNativeInvoker* -> downcallLinker* >> - universalUpcallHandler* -> upcallLinker* >> - foreign_globals* -> foreignGlobals* (to match existing convention) >> >> Method, field, and other variable names are also adjusted accordingly. >> >> Testing: Tier 1-4 > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > Comments + cleanup Thanks. The down/upcall terminology is the one we use in the public Java API as well, so using that everywhere seems the most consistent. I'm fine with revisiting. ------------- PR: https://git.openjdk.java.net/jdk/pull/8777 From jvernee at openjdk.java.net Mon May 23 10:06:44 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 23 May 2022 10:06:44 GMT Subject: Integrated: 8286825: Linker naming cleanup In-Reply-To: References: Message-ID: <63AOhjcTxGFhNJBpD3xHUQE3TfcaEeT38u5I8bXAg-8=.bab2b4d0-20db-4f3d-956c-64db99e6247b@github.com> On Wed, 18 May 2022 16:54:06 GMT, Jorn Vernee wrote: > This patch is a batch naming cleanup for the foreign linker implementation. > > The naming changes are as follows: > > - ProgrammableInvoker -> DowncallLinker > - ProgrammableUpcallHandler -> UpcallLinker > - 'native invoker' -> 'downcall stub' > - 'optimzed entry blob' -> 'upcall stub' > - OptimizedEntryBlob -> UpcallStub > - optimized_entry_frame -> upcall_stub_frame > > Then renaming of some hotspot files: > > - universalNativeInvoker* -> downcallLinker* > - universalUpcallHandler* -> upcallLinker* > - foreign_globals* -> foreignGlobals* (to match existing convention) > > Method, field, and other variable names are also adjusted accordingly. > > Testing: Tier 1-4 This pull request has now been integrated. Changeset: 7becf13e Author: Jorn Vernee URL: https://git.openjdk.java.net/jdk/commit/7becf13e61ba2c43837e4b48775fdaf73bc1d79e Stats: 3181 lines in 85 files changed: 1487 ins; 1491 del; 203 mod 8286825: Linker naming cleanup Reviewed-by: mcimadamore, rehn ------------- PR: https://git.openjdk.java.net/jdk/pull/8777 From rrich at openjdk.java.net Mon May 23 10:24:03 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 23 May 2022 10:24:03 GMT Subject: RFR: 8285739: disable EA when both JVMTI and Preview are enabled [v2] In-Reply-To: References: Message-ID: On Sat, 21 May 2022 16:09:17 GMT, Leonid Mesnik wrote: > > Hi Leonid, if EscapeAnalysis is not disabled, then local objects cannot be read per JVMTI if they are scalarized in compiled frames on the heap, right? This would be a problem I'd think. Thanks, Richard. > > Yes, the fix restores correct behavior for platform threads if --enable-preview is on. The [JDK-8285739](https://bugs.openjdk.java.net/browse/JDK-8285739) should fix this for virtual threads. Could it be that you mean [JDK-8264699](https://bugs.openjdk.java.net/browse/JDK-8264699)? I'm ok with this version of your fix. I'd suggest to change title/synopsis of the bug report to better match it though. ------------- PR: https://git.openjdk.java.net/jdk/pull/8589 From zgu at openjdk.java.net Mon May 23 12:45:32 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 23 May 2022 12:45:32 GMT Subject: RFR: 8286956: Loom: Define test groups for development/porting use In-Reply-To: References: Message-ID: <7CXFt1mPrcAvaizJvSxqzEnQfMTGZrH2n6w3_JjEC44=.ae250594-6438-4e84-9d02-21f160d5f560@github.com> On Wed, 18 May 2022 11:10:58 GMT, Aleksey Shipilev wrote: > It would be beneficial to bring over the Loom-specific test groups from the loom repo to aid development/porting work. > > https://github.com/openjdk/loom/blob/fibers/test/jdk/TEST.groups#L97-L108 > https://github.com/openjdk/loom/blob/6f42923b3342e41d95b262733205283068802b40/test/hotspot/jtreg/TEST.groups#L111-L125 > > I had to drop `jdk/incubator/concurrent` from JDK definition, because there are no tests in that folder and tests break. > > Additional testing: > - [x] Linux x86_64 fastdebug `hotspot_loom jdk_loom` > - [x] Linux AArch64 fastdebug `hotspot_loom jdk_loom` This will help fixing the breakage of Shenandoah + Loom. ------------- Marked as reviewed by zgu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8765 From lmesnik at openjdk.java.net Mon May 23 14:46:37 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 23 May 2022 14:46:37 GMT Subject: RFR: 8285739: disable EscapeBarrier deopt for virtual threads [v2] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 10:20:39 GMT, Richard Reingruber wrote: > Could it be that you mean [JDK-8264699](https://bugs.openjdk.java.net/browse/JDK-8264699)? > Yes, you are right. > I'm ok with this version of your fix. I'd suggest to change title/synopsis of the bug report to better match it though. Thank you. I've renamed the summary ------------- PR: https://git.openjdk.java.net/jdk/pull/8589 From lmesnik at openjdk.java.net Mon May 23 14:55:43 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 23 May 2022 14:55:43 GMT Subject: Integrated: 8285739: disable EscapeBarrier deopt for virtual threads In-Reply-To: References: Message-ID: <3VVI_adm7AMY5DpfsJMpt2pQvI8VxO6Roh6oSAphmMc=.36ec6726-8923-4b8e-b753-cc67b0896986@github.com> On Mon, 9 May 2022 01:36:39 GMT, Leonid Mesnik wrote: > The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI capabilities are enabled and --enable-preview. > > It restores the same behavior as it was before https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents" is implemented when Continuations are enabled. This pull request has now been integrated. Changeset: 940e94f1 Author: Leonid Mesnik URL: https://git.openjdk.java.net/jdk/commit/940e94f194e2abab8006e67dbb82cab5f16e3a17 Stats: 6 lines in 2 files changed: 5 ins; 0 del; 1 mod 8285739: disable EscapeBarrier deopt for virtual threads Reviewed-by: kvn, rrich, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/8589 From shade at openjdk.java.net Mon May 23 15:13:05 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 May 2022 15:13:05 GMT Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom integration Message-ID: [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner. Additional testing: - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot) - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot) - [x] Linux x86_32 fastdebug `tier3` (clean now) - [ ] GHA run ------------- Commit messages: - Updates - Revert test groups - Fix 2 - Fix Changes: https://git.openjdk.java.net/jdk/pull/8843/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8843&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287137 Stats: 276 lines in 3 files changed: 276 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8843.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8843/head:pull/8843 PR: https://git.openjdk.java.net/jdk/pull/8843 From alanb at openjdk.java.net Mon May 23 15:15:09 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 23 May 2022 15:15:09 GMT Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom integration In-Reply-To: References: Message-ID: On Mon, 23 May 2022 12:28:30 GMT, Aleksey Shipilev wrote: > [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner. > > Additional testing: > - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot) > - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot) > - [x] Linux x86_32 fastdebug `tier3` (clean now) > - [ ] GHA run test/jdk/ProblemList.txt line 894: > 892: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectionAndMapModifyStreamTest.java 8286642 generic-i586 > 893: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorExample.java 8286642 generic-i586 > 894: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorToUnmodListTest.java 8286642 generic-i586 I'm surprised that the stream tests are included as they don't run with --enable-preview. ------------- PR: https://git.openjdk.java.net/jdk/pull/8843 From shade at openjdk.java.net Mon May 23 15:21:41 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 May 2022 15:21:41 GMT Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom integration In-Reply-To: References: Message-ID: On Mon, 23 May 2022 15:13:02 GMT, Alan Bateman wrote: >> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner. >> >> Additional testing: >> - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot) >> - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot) >> - [x] Linux x86_32 fastdebug `tier3` (clean now) >> - [ ] GHA run > > test/jdk/ProblemList.txt line 894: > >> 892: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectionAndMapModifyStreamTest.java 8286642 generic-i586 >> 893: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorExample.java 8286642 generic-i586 >> 894: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorToUnmodListTest.java 8286642 generic-i586 > > I'm surprised that the stream tests are included as they don't run with --enable-preview. Those tests *do* run with preview enabled: https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/stream/test/TEST.properties#L10-L11 -- and I know that because I basically copy-pasted all jtreg failures that lead to `Unimplemented()` in x86_32 code. ------------- PR: https://git.openjdk.java.net/jdk/pull/8843 From prr at openjdk.java.net Mon May 23 15:28:56 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 23 May 2022 15:28:56 GMT Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom integration In-Reply-To: References: Message-ID: On Mon, 23 May 2022 12:28:30 GMT, Aleksey Shipilev wrote: > [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner. > > Additional testing: > - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot) > - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot) > - [x] Linux x86_32 fastdebug `tier3` (clean now) > - [ ] GHA run I agree this is better than disabling the entire GHA ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8843 From shade at openjdk.java.net Mon May 23 15:39:40 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 May 2022 15:39:40 GMT Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom integration In-Reply-To: References: Message-ID: On Mon, 23 May 2022 15:34:11 GMT, Alan Bateman wrote: >> Those tests *do* run with preview enabled: https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/stream/test/TEST.properties#L10-L11 -- and I know that because I basically copy-pasted all jtreg failures that lead to `Unimplemented()` in x86_32 code. > > Okay, so the issue is SpliteratorTest uses preview APIs and having the configuration in TEST.properties means that all the streams tests are run with this option. Yes, `TEST.properties` is way too broad. I'd keep the current patch as is, instead of trying to fix that one. I suspect there is some funky TestNG/othervm interaction going... ------------- PR: https://git.openjdk.java.net/jdk/pull/8843 From alanb at openjdk.java.net Mon May 23 15:39:40 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 23 May 2022 15:39:40 GMT Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom integration In-Reply-To: References: Message-ID: On Mon, 23 May 2022 15:18:10 GMT, Aleksey Shipilev wrote: >> test/jdk/ProblemList.txt line 894: >> >>> 892: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectionAndMapModifyStreamTest.java 8286642 generic-i586 >>> 893: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorExample.java 8286642 generic-i586 >>> 894: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorToUnmodListTest.java 8286642 generic-i586 >> >> I'm surprised that the stream tests are included as they don't run with --enable-preview. > > Those tests *do* run with preview enabled: https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/stream/test/TEST.properties#L10-L11 -- and I know that because I basically copy-pasted all jtreg failures that lead to `Unimplemented()` in x86_32 code. Okay, so the issue is SpliteratorTest uses preview APIs and having the configuration in TEST.properties means that all the streams tests are run with this option. ------------- PR: https://git.openjdk.java.net/jdk/pull/8843 From dchuyko at openjdk.java.net Mon May 23 15:47:55 2022 From: dchuyko at openjdk.java.net (Dmitry Chuyko) Date: Mon, 23 May 2022 15:47:55 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions In-Reply-To: References: Message-ID: On Fri, 20 May 2022 08:36:28 GMT, Magnus Ihse Bursie wrote: >> On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. >> >> New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. >> >> New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. >> >> Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: >> >> * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. >> * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with >> --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse >> >> Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. > > make/autoconf/jvm-features.m4 line 442: > >> 440: JVM_FEATURES_VARIANT_FILTER="link-time-opt opt-size" >> 441: fi >> 442: # Filter out hardlse feature by default > > You should not set up a PLATFORM filter in `JVM_FEATURES_PREPARE_VARIANT`. > > In fact, you will need a `JVM_FEATURES_CHECK_HARD_LSE`, which verifies that it can only be enabled on aarch64. See e.g. `JVM_FEATURES_CHECK_JVMCI` foor inspiration on how to write this and where to call it. I suggest you set up `JVM_FEATURES_PLATFORM_FILTER` in that function as well. Magnus, thank you for the comments. I'm taking a direction suggested by Andrew and Nick -- linux-aarch64 only solution without build configuration feature, determined by actual compiler flags. Will update the PR shortly after some final testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From dchuyko at openjdk.java.net Mon May 23 16:05:16 2022 From: dchuyko at openjdk.java.net (Dmitry Chuyko) Date: Mon, 23 May 2022 16:05:16 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions [v2] In-Reply-To: References: Message-ID: > On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. > > New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. > > Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: > > * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. > * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with > --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse > > Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. Dmitry Chuyko has updated the pull request incrementally with two additional commits since the last revision: - Use LSE in linux-aarch64 asm code if __ARM_FEATURE_ATOMICS is on - Revert "hardlse feature" This reverts commit c5da85d3282bb995f69639f8f592cc94560916c5. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8779/files - new: https://git.openjdk.java.net/jdk/pull/8779/files/87b3cbb9..1287cce3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8779&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8779&range=00-01 Stats: 277 lines in 6 files changed: 74 ins; 190 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/8779.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8779/head:pull/8779 PR: https://git.openjdk.java.net/jdk/pull/8779 From dchuyko at openjdk.java.net Mon May 23 16:12:34 2022 From: dchuyko at openjdk.java.net (Dmitry Chuyko) Date: Mon, 23 May 2022 16:12:34 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions [v3] In-Reply-To: References: Message-ID: > On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. > > New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. > > New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. > > Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: > > * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. > * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with > --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse > > Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. Dmitry Chuyko 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: - Merge branch 'openjdk:master' into JDK-8282322 - Use LSE in linux-aarch64 asm code if __ARM_FEATURE_ATOMICS is on - Revert "hardlse feature" This reverts commit c5da85d3282bb995f69639f8f592cc94560916c5. - Merge branch 'openjdk:master' into JDK-8282322 - hardlse feature ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8779/files - new: https://git.openjdk.java.net/jdk/pull/8779/files/1287cce3..f7c8378a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8779&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8779&range=01-02 Stats: 8571 lines in 343 files changed: 4112 ins; 3026 del; 1433 mod Patch: https://git.openjdk.java.net/jdk/pull/8779.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8779/head:pull/8779 PR: https://git.openjdk.java.net/jdk/pull/8779 From dchuyko at openjdk.java.net Mon May 23 16:12:34 2022 From: dchuyko at openjdk.java.net (Dmitry Chuyko) Date: Mon, 23 May 2022 16:12:34 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions [v2] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 16:05:16 GMT, Dmitry Chuyko wrote: >> On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. >> >> New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. >> >> New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. >> >> Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: >> >> * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. >> * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with >> --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse >> >> Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. > > Dmitry Chuyko has updated the pull request incrementally with two additional commits since the last revision: > > - Use LSE in linux-aarch64 asm code if __ARM_FEATURE_ATOMICS is on > - Revert "hardlse feature" > > This reverts commit c5da85d3282bb995f69639f8f592cc94560916c5. New variant turns on using LSE atomics statically when __ARM_FEATURE_ATOMICS compiler feature is on. Prefetch is left only to non-LSE case, the kernel seems to do the same. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From shade at openjdk.java.net Mon May 23 16:18:36 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 May 2022 16:18:36 GMT Subject: RFR: 8286956: Loom: Define test groups for development/porting use In-Reply-To: References: Message-ID: On Wed, 18 May 2022 11:10:58 GMT, Aleksey Shipilev wrote: > It would be beneficial to bring over the Loom-specific test groups from the loom repo to aid development/porting work. > > https://github.com/openjdk/loom/blob/fibers/test/jdk/TEST.groups#L97-L108 > https://github.com/openjdk/loom/blob/6f42923b3342e41d95b262733205283068802b40/test/hotspot/jtreg/TEST.groups#L111-L125 > > I had to drop `jdk/incubator/concurrent` from JDK definition, because there are no tests in that folder and tests break. > > Additional testing: > - [x] Linux x86_64 fastdebug `hotspot_loom jdk_loom` > - [x] Linux AArch64 fastdebug `hotspot_loom jdk_loom` All right, thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/8765 From shade at openjdk.java.net Mon May 23 16:20:50 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 May 2022 16:20:50 GMT Subject: Integrated: 8286956: Loom: Define test groups for development/porting use In-Reply-To: References: Message-ID: On Wed, 18 May 2022 11:10:58 GMT, Aleksey Shipilev wrote: > It would be beneficial to bring over the Loom-specific test groups from the loom repo to aid development/porting work. > > https://github.com/openjdk/loom/blob/fibers/test/jdk/TEST.groups#L97-L108 > https://github.com/openjdk/loom/blob/6f42923b3342e41d95b262733205283068802b40/test/hotspot/jtreg/TEST.groups#L111-L125 > > I had to drop `jdk/incubator/concurrent` from JDK definition, because there are no tests in that folder and tests break. > > Additional testing: > - [x] Linux x86_64 fastdebug `hotspot_loom jdk_loom` > - [x] Linux AArch64 fastdebug `hotspot_loom jdk_loom` This pull request has now been integrated. Changeset: ac274c4c Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/ac274c4ca67555742065dc850823e924361f2ff7 Stats: 28 lines in 2 files changed: 28 ins; 0 del; 0 mod 8286956: Loom: Define test groups for development/porting use Reviewed-by: alanb, zgu ------------- PR: https://git.openjdk.java.net/jdk/pull/8765 From jbhateja at openjdk.java.net Mon May 23 16:28:23 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 23 May 2022 16:28:23 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v3] In-Reply-To: References: <15GChtdthFmu9Cup-Ykj5NBvAanOC8QOJsnhH9g20KY=.f35eba31-15f9-40e8-95ce-a54049792840@github.com> Message-ID: On Thu, 12 May 2022 23:56:49 GMT, Vladimir Ivanov wrote: >> Jatin Bhateja 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' of http://github.com/openjdk/jdk into JDK-8284960 >> - 8284960: Correcting a typo. >> - 8284960: Integrating changes from panama-vector (Add @since 19 tags). >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 >> - 8284960: AARCH64 backend changes. >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 >> - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3fa1c404...b021e082 > > Overall, looks good. > > Some minor questions/suggestions follow. Hi @iwanowww , your comments have been addressed. kindly let me know if you have other comments on x86 side changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From mcimadamore at openjdk.java.net Mon May 23 16:50:50 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 23 May 2022 16:50:50 GMT Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom integration In-Reply-To: References: Message-ID: On Mon, 23 May 2022 15:36:01 GMT, Aleksey Shipilev wrote: >> Okay, so the issue is SpliteratorTest uses preview APIs and having the configuration in TEST.properties means that all the streams tests are run with this option. > > Yes, `TEST.properties` is way too broad. I'd keep the current patch as is, instead of trying to fix that one. I suspect there is some funky TestNG/othervm interaction going... These specific stream tests are odd, in the sense that they live in a test root that is TestNG and they are only "imported" into jtreg. The toplevel TEST.properties file gets only once chance to set the correct parameters, for all tests. I've tried adding more local flags, nearer to the test, w/o success. I'm obviously happy to do it another way. I have tried adding a jtreg header in that test, but that doesn't fix the problem - because _all_ the tests are passed to testng at once, which compiles them and runs them. So either the flag is present when that happens, or it is ignored. ------------- PR: https://git.openjdk.java.net/jdk/pull/8843 From aph at openjdk.java.net Mon May 23 16:56:00 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 23 May 2022 16:56:00 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions [v3] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 16:12:34 GMT, Dmitry Chuyko wrote: >> On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. >> >> New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. >> >> New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. >> >> Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: >> >> * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. >> * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with >> --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse >> >> Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. > > Dmitry Chuyko 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: > > - Merge branch 'openjdk:master' into JDK-8282322 > - Use LSE in linux-aarch64 asm code if __ARM_FEATURE_ATOMICS is on > - Revert "hardlse feature" > > This reverts commit c5da85d3282bb995f69639f8f592cc94560916c5. > - Merge branch 'openjdk:master' into JDK-8282322 > - hardlse feature src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S line 291: > 289: #endif > 290: 1: mov x0, x3 > 291: ret Oh gosh, I find all those `#if`s really hard to read. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From iklam at openjdk.java.net Mon May 23 17:13:36 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 23 May 2022 17:13:36 GMT Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate [v4] In-Reply-To: References: Message-ID: > I added two new template functions to reduce the boilerplate code when walking the entries in a ResourceHashtable > > - `template void ResourceHashtable::iterate(F f)` > - `template void ResourceHashtable::iterate_all(F f)` > > I also modified a couple of places in systemDictionaryShared.cpp to use the new functionality. > > Testing with tiers 1-4. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: some clean up suggested by @stefank ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8761/files - new: https://git.openjdk.java.net/jdk/pull/8761/files/f3ca12ad..8c53c418 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8761&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8761&range=02-03 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8761.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8761/head:pull/8761 PR: https://git.openjdk.java.net/jdk/pull/8761 From shade at openjdk.java.net Mon May 23 17:16:28 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 May 2022 17:16:28 GMT Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom integration [v2] In-Reply-To: References: Message-ID: > [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner. > > Additional testing: > - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot) > - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot) > - [x] Linux x86_32 fastdebug `tier3` (clean now) > - [ ] GHA run Aleksey Shipilev 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: - Fix the tests in release JDKs - Merge branch 'master' into JDK-8287137-problemlist-x86_32 - Updates - Revert test groups - Fix 2 - Fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8843/files - new: https://git.openjdk.java.net/jdk/pull/8843/files/ba5c631e..5a0cd8fe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8843&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8843&range=00-01 Stats: 4568 lines in 145 files changed: 2586 ins; 1656 del; 326 mod Patch: https://git.openjdk.java.net/jdk/pull/8843.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8843/head:pull/8843 PR: https://git.openjdk.java.net/jdk/pull/8843 From kvn at openjdk.java.net Mon May 23 18:20:54 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 23 May 2022 18:20:54 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Mon, 16 May 2022 15:52:22 GMT, olivergillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. These results seems promising but we should not base our decision only on this. We need some time to analyze these results and look on other benchmarks. Thank you for patience. ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From shade at openjdk.java.net Mon May 23 18:25:23 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 May 2022 18:25:23 GMT Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom integration [v3] In-Reply-To: References: Message-ID: > [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner. > > Additional testing: > - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot) > - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot) > - [x] Linux x86_32 fastdebug `tier3` (clean now) > - [ ] GHA run Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Another release test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8843/files - new: https://git.openjdk.java.net/jdk/pull/8843/files/5a0cd8fe..e223e211 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8843&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8843&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8843.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8843/head:pull/8843 PR: https://git.openjdk.java.net/jdk/pull/8843 From aivanov at openjdk.java.net Mon May 23 20:06:57 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 23 May 2022 20:06:57 GMT Subject: RFR: 8284191: Replace usages of 'a the' in hotspot and java.base [v3] In-Reply-To: References: Message-ID: <3E93xe0v68L9AHsT3c5D58_5OdaSDEGtdg5ih7TTkfk=.45bed80f-be56-49e8-9dfb-a7fa70b9ea23@github.com> > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: Update copyright to 2022 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8768/files - new: https://git.openjdk.java.net/jdk/pull/8768/files/0669cdc1..fa2caaec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=01-02 Stats: 102 lines in 102 files changed: 0 ins; 0 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/8768.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768 PR: https://git.openjdk.java.net/jdk/pull/8768 From vlivanov at openjdk.java.net Mon May 23 22:09:27 2022 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 23 May 2022 22:09:27 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v8] In-Reply-To: <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com> References: <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com> Message-ID: On Fri, 20 May 2022 09:51:24 GMT, Jatin Bhateja wrote: >> Hi All, >> >> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) >> >> Following is the brief summary of changes:- >> >> 1) Extends the scope of existing lanewise API for following new vector operations. >> - VectorOperations.BIT_COUNT: counts the number of one-bits >> - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits >> - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits >> - VectorOperations.REVERSE: reversing the order of bits >> - VectorOperations.REVERSE_BYTES: reversing the order of bytes >> - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. >> >> 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. >> - Vector.compress >> - Vector.expand >> - VectorMask.compress >> >> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. >> - Vector.fromMemorySegment >> - Vector.intoMemorySegment >> >> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. >> >> >> Patch has been regressed over AARCH64 and X86 targets different AVX levels. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8284960: Integrating incremental patches. Looks good! ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8425 From kbarrett at openjdk.java.net Mon May 23 22:50:46 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 23 May 2022 22:50:46 GMT Subject: RFR: 8286262: Windows: Cleanup deprecation warning suppression [v2] In-Reply-To: References: Message-ID: > Please review this cleanup of deprecation warning suppression when building > for Windows. > > This change consists of several parts. > > (1) Remove the global deprecation warning suppression when building HotSpot > for Windows. > > (2) Add macro definitions requesting suppression of selected sets of > deprecation warnings when building HotSpot for Windows. > > (3) Remove unnecessary forwarding macros for various POSIX functions in > globalDefinitions_visCPP.hpp. These were provided to avoid deprecation > warnings (that were previously also being suppressed by the global request). > They are now covered by the new macros provided by change (2) above. > > An alternative to item (3) is to not define _CRT_NONSTDC_NO_DEPRECATE (in item > (2)) and either retain the forwarding macros or define os:: wrapper functions > for all of the affected functions. We might eventually do the latter because > of other reasons for avoiding some of these functions, but the approach being > taken here is simpler. > > For documentation of _CRT_NONSTDC_NO_DEPRECATE, see: > https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility > https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4996 > > Similarly for _CRT_SECURE_NO_WARNINGS. > > Perhaps similarly for _WINSOCK_DEPRECATED_NO_WARNINGS (though I didn't find > any documentation for the latter). But it might be better to not supress the > warnings and instead use the alternatives (JDK-8286781). > > 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 two additional commits since the last revision: - Merge branch 'master' into no-deprecate - cleanup Windows deprecation warning suppression ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8718/files - new: https://git.openjdk.java.net/jdk/pull/8718/files/dd39fb83..cbee140c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8718&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8718&range=00-01 Stats: 27751 lines in 853 files changed: 14074 ins; 9711 del; 3966 mod Patch: https://git.openjdk.java.net/jdk/pull/8718.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8718/head:pull/8718 PR: https://git.openjdk.java.net/jdk/pull/8718 From kbarrett at openjdk.java.net Mon May 23 22:50:47 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 23 May 2022 22:50:47 GMT Subject: RFR: 8286262: Windows: Cleanup deprecation warning suppression In-Reply-To: References: Message-ID: On Tue, 17 May 2022 06:30:03 GMT, David Holmes wrote: >> Please review this cleanup of deprecation warning suppression when building >> for Windows. >> >> This change consists of several parts. >> >> (1) Remove the global deprecation warning suppression when building HotSpot >> for Windows. >> >> (2) Add macro definitions requesting suppression of selected sets of >> deprecation warnings when building HotSpot for Windows. >> >> (3) Remove unnecessary forwarding macros for various POSIX functions in >> globalDefinitions_visCPP.hpp. These were provided to avoid deprecation >> warnings (that were previously also being suppressed by the global request). >> They are now covered by the new macros provided by change (2) above. >> >> An alternative to item (3) is to not define _CRT_NONSTDC_NO_DEPRECATE (in item >> (2)) and either retain the forwarding macros or define os:: wrapper functions >> for all of the affected functions. We might eventually do the latter because >> of other reasons for avoiding some of these functions, but the approach being >> taken here is simpler. >> >> For documentation of _CRT_NONSTDC_NO_DEPRECATE, see: >> https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility >> https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4996 >> >> Similarly for _CRT_SECURE_NO_WARNINGS. >> >> Perhaps similarly for _WINSOCK_DEPRECATED_NO_WARNINGS (though I didn't find >> any documentation for the latter). But it might be better to not supress the >> warnings and instead use the alternatives (JDK-8286781). >> >> Testing: >> mach5 tier1 > > Sorry Kim I'm having trouble seeing what change corresponds to (1) ?? > > Also the PR talks only about hotspot, but you're changing the JDK flags as well. ?? Thanks @dholmes-ora and @magicus for reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/8718 From kbarrett at openjdk.java.net Mon May 23 22:50:47 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 23 May 2022 22:50:47 GMT Subject: Integrated: 8286262: Windows: Cleanup deprecation warning suppression In-Reply-To: References: Message-ID: On Sun, 15 May 2022 20:50:25 GMT, Kim Barrett wrote: > Please review this cleanup of deprecation warning suppression when building > for Windows. > > This change consists of several parts. > > (1) Remove the global deprecation warning suppression when building HotSpot > for Windows. > > (2) Add macro definitions requesting suppression of selected sets of > deprecation warnings when building HotSpot for Windows. > > (3) Remove unnecessary forwarding macros for various POSIX functions in > globalDefinitions_visCPP.hpp. These were provided to avoid deprecation > warnings (that were previously also being suppressed by the global request). > They are now covered by the new macros provided by change (2) above. > > An alternative to item (3) is to not define _CRT_NONSTDC_NO_DEPRECATE (in item > (2)) and either retain the forwarding macros or define os:: wrapper functions > for all of the affected functions. We might eventually do the latter because > of other reasons for avoiding some of these functions, but the approach being > taken here is simpler. > > For documentation of _CRT_NONSTDC_NO_DEPRECATE, see: > https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility > https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4996 > > Similarly for _CRT_SECURE_NO_WARNINGS. > > Perhaps similarly for _WINSOCK_DEPRECATED_NO_WARNINGS (though I didn't find > any documentation for the latter). But it might be better to not supress the > warnings and instead use the alternatives (JDK-8286781). > > Testing: > mach5 tier1 This pull request has now been integrated. Changeset: 782ae380 Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/782ae3801c63945ed977782fe15e8e911f7f9656 Stats: 21 lines in 4 files changed: 2 ins; 13 del; 6 mod 8286262: Windows: Cleanup deprecation warning suppression Reviewed-by: ihse, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/8718 From kvn at openjdk.java.net Mon May 23 23:11:36 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 23 May 2022 23:11:36 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v8] In-Reply-To: <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com> References: <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com> Message-ID: On Fri, 20 May 2022 09:51:24 GMT, Jatin Bhateja wrote: >> Hi All, >> >> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) >> >> Following is the brief summary of changes:- >> >> 1) Extends the scope of existing lanewise API for following new vector operations. >> - VectorOperations.BIT_COUNT: counts the number of one-bits >> - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits >> - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits >> - VectorOperations.REVERSE: reversing the order of bits >> - VectorOperations.REVERSE_BYTES: reversing the order of bytes >> - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. >> >> 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. >> - Vector.compress >> - Vector.expand >> - VectorMask.compress >> >> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. >> - Vector.fromMemorySegment >> - Vector.intoMemorySegment >> >> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. >> >> >> Patch has been regressed over AARCH64 and X86 targets different AVX levels. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8284960: Integrating incremental patches. src/hotspot/cpu/x86/assembler_x86.cpp line 7934: > 7932: > 7933: void Assembler::evplzcntd(XMMRegister dst, KRegister mask, XMMRegister src, bool merge, int vector_len) { > 7934: assert(VM_Version::supports_avx512cd() && (vector_len == AVX_512bit || VM_Version::supports_avx512vl()), ""); Please, split assert as in other instructions - it will help to understand failure better. src/hotspot/cpu/x86/assembler_x86.cpp line 7946: > 7944: > 7945: void Assembler::evplzcntq(XMMRegister dst, KRegister mask, XMMRegister src, bool merge, int vector_len) { > 7946: assert(VM_Version::supports_avx512cd() && (vector_len == AVX_512bit || VM_Version::supports_avx512vl()), ""); Split assert. src/hotspot/cpu/x86/assembler_x86.cpp line 8173: > 8171: > 8172: void Assembler::vinsertf32x4(XMMRegister dst, XMMRegister nds, XMMRegister src, uint8_t imm8) { > 8173: assert(VM_Version::supports_evex(), ""); Hmm, did we never trigger this wrong assert because the use was guarded by correct check? src/hotspot/cpu/x86/assembler_x86.cpp line 11720: > 11718: > 11719: void Assembler::evpcompressb(XMMRegister dst, KRegister mask, XMMRegister src, bool merge, int vector_len) { > 11720: assert(VM_Version::supports_avx512_vbmi2() && (vector_len == AVX_512bit || VM_Version::supports_avx512vl()), ""); Split assert in this and following new instructions. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4455: > 4453: break; > 4454: default: > 4455: fatal("Unsupported type"); Print wrong type: `fatal("Unsupported type : %s", type2name(type));` Below too. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4561: > 4559: case 4 : evpbroadcastd(dst, rtmp, vec_enc); break; > 4560: case 8 : evpbroadcastq(dst, rtmp, vec_enc); break; > 4561: default : ShouldNotReachHere(); break; `ShouldNotReachHere` does not give any information in case of failure. Use `fatal()` which prints wrong `lane_size`. Same below. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4666: > 4664: break; > 4665: default: > 4666: ShouldNotReachHere(); Use `fatal()`. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4693: > 4691: break; > 4692: default: > 4693: ShouldNotReachHere(); Use `fatal()`. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4732: > 4730: vector_reverse_byte(bt, dst, xtmp2, rtmp, vec_enc); > 4731: > 4732: } else if(!VM_Version::supports_avx512vlbw() && vec_enc == Assembler::AVX_512bit) { No need to check `!VM_Version::supports_avx512vlbw()`. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4759: > 4757: vpandn(xtmp2, xtmp2, xtmp1, vec_enc); > 4758: vpsrlq(xtmp2, xtmp2, 1, vec_enc); > 4759: vporq(xtmp1, dst, xtmp2, vec_enc); All 3 code snippets are the same except constants. Also similar code in `vector_reverse_byte64` for `short` type. Consider factoring out it into separate method. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4819: > 4817: break; > 4818: default: > 4819: fatal("Unsupported type"); Print wring type. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4846: > 4844: break; > 4845: default: > 4846: fatal("Unsupported type"); Print wring type. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4892: > 4890: break; > 4891: default: > 4892: ShouldNotReachHere(); Use `fatal` and print type. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5018: > 5016: break; > 5017: default: > 5018: ShouldNotReachHere(); Use fatal and print type. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5037: > 5035: break; > 5036: default: > 5037: ShouldNotReachHere(); Use fatal and print type. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 5056: > 5054: break; > 5055: default: > 5056: ShouldNotReachHere(); Use fatal and print type. src/hotspot/cpu/x86/x86.ad line 8879: > 8877: // special handling should be removed. > 8878: if (bt == T_LONG && rbt == T_INT) { > 8879: if (VM_Version::supports_avx512vl()) { Predicate say `!VM_Version::supports_avx512vl()` src/hotspot/share/opto/node.hpp line 1006: > 1004: > 1005: // The node is a CountedLoopEnd with a mask annotation so as to emit a restore context > 1006: bool has_vector_mask_set() const { return (_flags & Flag_has_vector_mask_set) != 0; } I don't see use of this flag. src/hotspot/share/opto/vectorIntrinsics.cpp line 86: > 84: if ((mask_use_type & VecMaskUseLoad) != 0) { > 85: if (!Matcher::match_rule_supported_vector(Op_VectorLoadMask, num_elem, elem_bt) || > 86: !Matcher::match_rule_supported_vector(Op_LoadVector, num_elem, T_BOOLEAN)) { Add comment explaining new check. In follow ing places too. src/hotspot/share/runtime/vmStructs.cpp line 1779: > 1777: declare_c2_type(CMoveVDNode, VectorNode) \ > 1778: declare_c2_type(CompressVNode, VectorNode) \ > 1779: declare_c2_type(ExpandVNode, VectorNode) \ Not all new nodes listed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From duke at openjdk.java.net Tue May 24 00:36:49 2022 From: duke at openjdk.java.net (olivergillespie) Date: Tue, 24 May 2022 00:36:49 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Mon, 16 May 2022 15:52:22 GMT, olivergillespie wrote: > The current code already does this for 'older' Skylake processors, > namely those with _stepping < 5. My testing indicates this is a > problem for later processors in this family too, so I have removed the > max stepping condition. > > The original exclusion was added in https://bugs.openjdk.java.net/browse/JDK-8221092. > > A general description of the overall issue is given at > https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Downclocking. > > According to https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#CPUID, > stepping values 5..7 indicate Cascade Lake. I have tested on a CPU with stepping=7, > and I see CPU frequency reduction from 3.1GHz down to 2.7GHz (~23%) when using > -XX:UseAVX=3, along with a corresponding performance reduction. > > I first saw this issue in a real production workload, where the main AVX3 instructions > being executed were those generated for various flavours of disjoint_arraycopy. > > I can reproduce a similar effect using SPECjvm2008's xml.transform benchmark. > > > java --add-opens=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED \ > --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED \ > -jar SPECjvm2008.jar -ikv -ict xml.transform > > > Before the change, or with -XX:UseAVX=3: > > > Valid run! > Score on xml.transform: 776.00 ops/m > > > After the change, or with -XX:UseAVX=2: > > > Valid run! > Score on xml.transform: 894.07 ops/m > > > So, a 15% improvement in this benchmark. It's possible some benchmarks will be negatively > affected by this change, but I contend that this is still the right move given the stark > difference in this benchmark combined with the fact that use of AVX3 instructions can > affect *all* processes/code on the host due to the downclocking, and the fact that this > effect is very hard to root-cause, for example CPU profiles look very similar before and > after since all code is equally slowed. Thanks for all the help so far. Is there anything I can help with? ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From kvn at openjdk.java.net Tue May 24 00:56:55 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 24 May 2022 00:56:55 GMT Subject: RFR: 8286823: Default to UseAVX=2 on all Skylake/Cascade Lake CPUs In-Reply-To: References: <1Fomn9fzLHJHZyTX3zz40lfUccP-ch2A0rcEQ38vYd0=.e217c63b-c475-47be-a2c2-cb2239022a61@github.com> Message-ID: On Tue, 24 May 2022 00:33:22 GMT, olivergillespie wrote: > Thanks for all the help so far. Is there anything I can help with? Thank you for offering help. We just need time to run different benchmarks we use for performance testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8731 From sspitsyn at openjdk.java.net Tue May 24 05:52:25 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 24 May 2022 05:52:25 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect Message-ID: It was a typo when the original CLEARING_MASK was initially introduced: // Mask to clear normal event bits. const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; // Avoid cleaning extension event bits. jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits(); ``` The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below: ` const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;` Let me provide some background to understand how this mask is used. Normal JVMTI event types are numbered from 50 to 88. There are two constants: JVMTI_MIN_EVENT_TYPE_VAL = 50 JVMTI_MAX_EVENT_TYPE_VAL = 88 The extension event types are numbered from 47 to 49. There are also two constants: EXT_MIN_EVENT_TYPE_VAL = 47 EXT_MAX_EVENT_TYPE_VAL = 49 There are also two additional constants: TOTAL_MIN_EVENT_TYPE_VAL = 47 TOTAL_MAX_EVENT_TYPE_VAL = 88 The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged. Testing: I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage. ------------- Commit messages: - 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect Changes: https://git.openjdk.java.net/jdk/pull/8860/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8860&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286490 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8860.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8860/head:pull/8860 PR: https://git.openjdk.java.net/jdk/pull/8860 From shade at openjdk.java.net Tue May 24 07:05:49 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 24 May 2022 07:05:49 GMT Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom integration [v3] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 18:25:23 GMT, Aleksey Shipilev wrote: >> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner. >> >> Additional testing: >> - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot) >> - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot) >> - [x] Linux x86_32 fastdebug `tier3` (clean now) >> - [x] GHA run > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Another release test GHA run completes fine on x86_32. There are unrelated Windows x86_64 failures in javac land, to be handled separately. Please approve, @AlanBateman, @mcimadamore and others? ------------- PR: https://git.openjdk.java.net/jdk/pull/8843 From jbachorik at openjdk.java.net Tue May 24 07:22:56 2022 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Tue, 24 May 2022 07:22:56 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect In-Reply-To: References: Message-ID: On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn wrote: > It was a typo when the original CLEARING_MASK was initially introduced: > > > // Mask to clear normal event bits. > const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; > // Avoid cleaning extension event bits. > jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits(); > > ``` > > The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below: > ` const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;` > > Let me provide some background to understand how this mask is used. > > Normal JVMTI event types are numbered from 50 to 88. There are two constants: > > JVMTI_MIN_EVENT_TYPE_VAL = 50 > JVMTI_MAX_EVENT_TYPE_VAL = 88 > > The extension event types are numbered from 47 to 49. There are also two constants: > > EXT_MIN_EVENT_TYPE_VAL = 47 > EXT_MAX_EVENT_TYPE_VAL = 49 > > > There are also two additional constants: > > TOTAL_MIN_EVENT_TYPE_VAL = 47 > TOTAL_MAX_EVENT_TYPE_VAL = 88 > > > The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged. > > Testing: > I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage. Good catch! LGTM! ------------- Marked as reviewed by jbachorik (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8860 From aph at openjdk.java.net Tue May 24 06:59:05 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 24 May 2022 06:59:05 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions [v3] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 16:52:25 GMT, Andrew Haley wrote: >> Dmitry Chuyko 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: >> >> - Merge branch 'openjdk:master' into JDK-8282322 >> - Use LSE in linux-aarch64 asm code if __ARM_FEATURE_ATOMICS is on >> - Revert "hardlse feature" >> >> This reverts commit c5da85d3282bb995f69639f8f592cc94560916c5. >> - Merge branch 'openjdk:master' into JDK-8282322 >> - hardlse feature > > src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S line 291: > >> 289: #endif >> 290: 1: mov x0, x3 >> 291: ret > > Oh gosh, I find all those `#if`s really hard to read. I'm withdrawing that comment. Patch is OK. Sorry for the noise. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From aph at openjdk.java.net Tue May 24 06:59:03 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 24 May 2022 06:59:03 GMT Subject: RFR: 8282322: AArch64: Provide a means to eliminate all STREX family of instructions [v3] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 16:12:34 GMT, Dmitry Chuyko wrote: >> On AArch64 it is sometimes convenient to have LSE atomics right from the start. Currently they are enabled after feature detection and RR reverse debugger works incorrectly. >> >> New build configuration feature 'hardlse' is added. If it is enabled for aarch64 type of build, then statically compiled stubs replace the initial pessimistic implementation and dynamically generated replacements (when LSE support is detected). The feature works for builds of all debug levels. >> >> New file atomic_linux_aarch64_lse.S is derived from atomic_linux_aarch64.S and inherits its copyright. This alternative static implementation corresponds to the dynamically generated code. >> >> Note, this configuration part is necessary but not sufficient to fully avoid strex instructions for practical purposes. Other parts are: >> >> * Run on the OS built without strex family instructions. E.g. Amazon Linux 2022. >> * Compile with outline atomics enabled and the configuration flag enabled. E.g. configure with >> --with-extra-cflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-cxxflags='-march=armv8.3-a+crc+crypto -moutline-atomics' --with-extra-ldflags='-Wl,--allow-multiple-definition' --with-jvm-features=hardlse >> >> Testing: tier1, tier2 on linux-aarch64 release builds with feature off and feature on. > > Dmitry Chuyko 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: > > - Merge branch 'openjdk:master' into JDK-8282322 > - Use LSE in linux-aarch64 asm code if __ARM_FEATURE_ATOMICS is on > - Revert "hardlse feature" > > This reverts commit c5da85d3282bb995f69639f8f592cc94560916c5. > - Merge branch 'openjdk:master' into JDK-8282322 > - hardlse feature src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 257: > 255: // Forcibly enable runtime LSE support > 256: FLAG_SET_DEFAULT(UseLSE, true); > 257: #else I don't believe this block does anything useful, and it disables `-XX:-UseLSE` for testing. src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S line 25: > 23: > 24: .text > 25: Don't delete this blank line. ------------- PR: https://git.openjdk.java.net/jdk/pull/8779 From mcimadamore at openjdk.java.net Tue May 24 08:10:37 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 24 May 2022 08:10:37 GMT Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom integration [v3] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 18:25:23 GMT, Aleksey Shipilev wrote: >> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner. >> >> Additional testing: >> - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot) >> - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot) >> - [x] Linux x86_32 fastdebug `tier3` (clean now) >> - [x] GHA run > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Another release test Marked as reviewed by mcimadamore (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8843 From tschatzl at openjdk.java.net Tue May 24 08:29:04 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 24 May 2022 08:29:04 GMT Subject: RFR: 8287138: Make VerifyOption an enum class In-Reply-To: References: Message-ID: On Mon, 23 May 2022 09:24:43 GMT, Kim Barrett wrote: >> Hi all, >> >> please review this change that make the `VerifyOption` enum an enum class as suggested in the review for [JDK-8189669](https://bugs.openjdk.java.net/browse/JDK-8189669). >> >> Testing: local compilation, gha >> >> Thanks, >> Thomas > > Looks good. Thanks @kimbarrett @stefank for your reviews ------------- PR: https://git.openjdk.java.net/jdk/pull/8832 From tschatzl at openjdk.java.net Tue May 24 08:29:06 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 24 May 2022 08:29:06 GMT Subject: Integrated: 8287138: Make VerifyOption an enum class In-Reply-To: References: Message-ID: On Mon, 23 May 2022 08:45:12 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that make the `VerifyOption` enum an enum class as suggested in the review for [JDK-8189669](https://bugs.openjdk.java.net/browse/JDK-8189669). > > Testing: local compilation, gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 4042dba3 Author: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/4042dba3d00f15edf4dd80c121dbb459a6855412 Stats: 28 lines in 8 files changed: 3 ins; 0 del; 25 mod 8287138: Make VerifyOption an enum class Reviewed-by: stefank, kbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/8832 From eosterlund at openjdk.java.net Tue May 24 09:18:47 2022 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 24 May 2022 09:18:47 GMT Subject: RFR: 8286376: Wrong condition for using non-immediate oops on AArch64 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 11:12:32 GMT, Erik ?sterlund wrote: > With the introduction of loom, nmethod entry barriers were added for all GCs. So far, the use of nmethod entry barriers has implied that nmethod oops are patched in the instruction stream. That is no longer the case. A condition was added to make sure we still get non-immediate oops on AArch64 for collectors that use nmethod entry barriers, and support immediate oops. However, the condition was messed up, so we instead end up doing the wrong thing. We should do the right thing. Thanks Stuart and Tobias for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/8593 From eosterlund at openjdk.java.net Tue May 24 09:18:47 2022 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 24 May 2022 09:18:47 GMT Subject: Integrated: 8286376: Wrong condition for using non-immediate oops on AArch64 In-Reply-To: References: Message-ID: On Mon, 9 May 2022 11:12:32 GMT, Erik ?sterlund wrote: > With the introduction of loom, nmethod entry barriers were added for all GCs. So far, the use of nmethod entry barriers has implied that nmethod oops are patched in the instruction stream. That is no longer the case. A condition was added to make sure we still get non-immediate oops on AArch64 for collectors that use nmethod entry barriers, and support immediate oops. However, the condition was messed up, so we instead end up doing the wrong thing. We should do the right thing. This pull request has now been integrated. Changeset: bd361bc0 Author: Erik ?sterlund URL: https://git.openjdk.java.net/jdk/commit/bd361bc077e58da173e752392147b8d08055dc37 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8286376: Wrong condition for using non-immediate oops on AArch64 Reviewed-by: aph, thartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/8593 From alanb at openjdk.java.net Tue May 24 09:46:34 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 24 May 2022 09:46:34 GMT Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom integration [v3] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 07:01:52 GMT, Aleksey Shipilev wrote: > Please approve, @AlanBateman, @mcimadamore and others? Okay with me. ------------- PR: https://git.openjdk.java.net/jdk/pull/8843 From aivanov at openjdk.java.net Tue May 24 11:28:50 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 24 May 2022 11:28:50 GMT Subject: Integrated: 8284191: Replace usages of 'a the' in hotspot and java.base In-Reply-To: References: Message-ID: On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov wrote: > Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the? > > Also, I fixed a couple of spelling mistakes. This pull request has now been integrated. Changeset: e0d361ce Author: Alexey Ivanov URL: https://git.openjdk.java.net/jdk/commit/e0d361cea91d3dd1450aece73f660b4abb7ce5fa Stats: 303 lines in 162 files changed: 0 ins; 11 del; 292 mod 8284191: Replace usages of 'a the' in hotspot and java.base Reviewed-by: lancea, wetmore, naoto, iris, kevinw, xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/8768 From stefank at openjdk.java.net Tue May 24 12:33:51 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 24 May 2022 12:33:51 GMT Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate [v4] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 17:13:36 GMT, Ioi Lam wrote: >> I added two new template functions to reduce the boilerplate code when walking the entries in a ResourceHashtable >> >> - `template void ResourceHashtable::iterate(F f)` >> - `template void ResourceHashtable::iterate_all(F f)` >> >> I also modified a couple of places in systemDictionaryShared.cpp to use the new functionality. >> >> Testing with tiers 1-4. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > some clean up suggested by @stefank src/hotspot/share/classfile/systemDictionaryShared.cpp line 672: > 670: SystemDictionaryShared::check_for_exclusion(k, &info); > 671: }; > 672: _dumptime_table->iterate_all(check_for_exclusion); Can't this be changed to just: `_dumptime_table->iterate_all(SystemDictionaryShared::check_for_exclusion);` or maybe even: `_dumptime_table->iterate_all(check_for_exclusion);` ------------- PR: https://git.openjdk.java.net/jdk/pull/8761 From stefank at openjdk.java.net Tue May 24 12:37:47 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 24 May 2022 12:37:47 GMT Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate [v4] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 17:13:36 GMT, Ioi Lam wrote: >> I added two new template functions to reduce the boilerplate code when walking the entries in a ResourceHashtable >> >> - `template void ResourceHashtable::iterate(F f)` >> - `template void ResourceHashtable::iterate_all(F f)` >> >> I also modified a couple of places in systemDictionaryShared.cpp to use the new functionality. >> >> Testing with tiers 1-4. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > some clean up suggested by @stefank src/hotspot/share/utilities/resourceHash.hpp line 210: > 208: }; > 209: iterate(function); > 210: } Do you still have any usages of this? I'm a bit surprised that the compiler don't complain about not being able to disambiguate calls to this vs the new lambda enabled function. ------------- PR: https://git.openjdk.java.net/jdk/pull/8761 From duke at openjdk.java.net Tue May 24 14:03:38 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Tue, 24 May 2022 14:03:38 GMT Subject: RFR: 8284849: Add deoptimization to unified logging In-Reply-To: References: Message-ID: On Fri, 20 May 2022 16:40:05 GMT, Jorn Vernee wrote: > Thanks for looking at this! > > I suggest trying to match the style of the `-Xlog:jit+compilation=debug` messages, since deoptimization is like the dual of compilation. And trying to keep the output on a single line (less output makes it easier to sift through lengthy logs). > > Rather than printing the compiler name, I think printing the compilation level is more useful, as well as including some info about whether it was an osr compilation maybe. The `jit+compilation` log messages do the latter by printing an extra `%`. > > Maybe something like: > > ``` > @ -> > ``` > > The instruction and line number could also be incorporated somewhere, but the compilation messages don't have them either. They seem fine to leave out I think. (not all class files have useful line numbers, and the bci should be enough to find the bytecode source of the deopt, and from that the instruction). I'm not sure whether we can know if something was an OCR compilation or not. This is how jit+compilation does it: // CompileTask::print_compilation void CompileTask::print(outputStream* st, const char* msg, bool short_form, bool cr) { bool is_osr_method = osr_bci() != InvocationEntryBci; print_impl(st, is_unloaded() ? NULL : method(), compile_id(), comp_level(), is_osr_method, osr_bci(), is_blocking(), msg, short_form, cr, _time_queued, _time_started); } I don't think we have a `CompileTask` to look at. Other than that, I'm completely up for changing this to a single log line with a similar format to the one you suggested. > > Also, I noticed that `jit+compilation` has the `debug` level, so maybe this log message should be under the `debug` level as well, instead of `info`. I don't know if there is any guidance on that somewhere. There's some guidance in the JEP, basically `debug` is allowed to be a bit more computationally intensive than `info`. I think it sounds good to move it to `info`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8812 From shade at openjdk.java.net Tue May 24 14:14:09 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 24 May 2022 14:14:09 GMT Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom integration [v3] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 18:25:23 GMT, Aleksey Shipilev wrote: >> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner. >> >> Additional testing: >> - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot) >> - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot) >> - [x] Linux x86_32 fastdebug `tier3` (clean now) >> - [x] GHA run > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Another release test Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/8843 From shade at openjdk.java.net Tue May 24 14:14:11 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 24 May 2022 14:14:11 GMT Subject: Integrated: 8287137: Problemlist failing x86_32 tests after Loom integration In-Reply-To: References: Message-ID: On Mon, 23 May 2022 12:28:30 GMT, Aleksey Shipilev wrote: > [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner. > > Additional testing: > - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot) > - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot) > - [x] Linux x86_32 fastdebug `tier3` (clean now) > - [x] GHA run This pull request has now been integrated. Changeset: 0a82c4eb Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/0a82c4ebc3748f6dfbbcd72e4421fbe0ea89e0b0 Stats: 279 lines in 3 files changed: 279 ins; 0 del; 0 mod 8287137: Problemlist failing x86_32 tests after Loom integration Reviewed-by: prr, mcimadamore ------------- PR: https://git.openjdk.java.net/jdk/pull/8843 From jvernee at openjdk.java.net Tue May 24 14:21:50 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 24 May 2022 14:21:50 GMT Subject: RFR: 8284849: Add deoptimization to unified logging In-Reply-To: References: Message-ID: On Tue, 24 May 2022 14:00:10 GMT, Johan Sj?l?n wrote: > I'm not sure whether we can know if something was an OCR compilation or not. `CompiledMethod` has the function `is_osr_method` which I think can be used for that. The code in question seems to be dealing with a `CompiledMethod*` already (https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/deoptimization.cpp#L1876) ------------- PR: https://git.openjdk.java.net/jdk/pull/8812 From tsteele at openjdk.java.net Tue May 24 14:32:53 2022 From: tsteele at openjdk.java.net (Tyler Steele) Date: Tue, 24 May 2022 14:32:53 GMT Subject: RFR: 8286891: thread_local causes undefined symbol error with XL C [v2] In-Reply-To: References: Message-ID: > When using XLClang++ to compile a `thread_local` struct with a destructor, a compiler bug is exposed that results in a missing constructor and a linker error. > > Adding the missing constructor solves this issue. > > Changes > - Builds on AIX (previously broken) Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: Remove AIX-specific macro ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8754/files - new: https://git.openjdk.java.net/jdk/pull/8754/files/06073958..5dd93583 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8754&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8754&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8754.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8754/head:pull/8754 PR: https://git.openjdk.java.net/jdk/pull/8754 From tsteele at openjdk.java.net Tue May 24 14:32:55 2022 From: tsteele at openjdk.java.net (Tyler Steele) Date: Tue, 24 May 2022 14:32:55 GMT Subject: RFR: 8286891: thread_local causes undefined symbol error with XL C [v2] In-Reply-To: <2rSL-OYXjIp9Yz_Z4Qbdxlra2Bt-AsVgLnz0M_cHR9c=.caf441f5-5f51-4b97-8826-025708168e71@github.com> References: <2rSL-OYXjIp9Yz_Z4Qbdxlra2Bt-AsVgLnz0M_cHR9c=.caf441f5-5f51-4b97-8826-025708168e71@github.com> Message-ID: On Mon, 23 May 2022 09:22:52 GMT, Martin Doerr wrote: >> Yeah, that seems better to me as well. > > +1 Thanks for the feedback. I have made this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/8754 From tsteele at openjdk.java.net Tue May 24 14:51:38 2022 From: tsteele at openjdk.java.net (Tyler Steele) Date: Tue, 24 May 2022 14:51:38 GMT Subject: RFR: 8286891: thread_local causes undefined symbol error with XL C [v3] In-Reply-To: References: Message-ID: > When using XLClang++ to compile a `thread_local` struct with a destructor, a compiler bug is exposed that results in a missing constructor and a linker error. > > Adding the missing constructor solves this issue. > > Changes > - Builds on AIX (previously broken) Tyler Steele 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 thread_local-build-break - Update compiler year - Remove AIX-specific macro - XL C compiler bug workaround ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8754/files - new: https://git.openjdk.java.net/jdk/pull/8754/files/5dd93583..3c096adc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8754&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8754&range=01-02 Stats: 24604 lines in 776 files changed: 12702 ins; 8574 del; 3328 mod Patch: https://git.openjdk.java.net/jdk/pull/8754.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8754/head:pull/8754 PR: https://git.openjdk.java.net/jdk/pull/8754 From jvernee at openjdk.java.net Tue May 24 14:51:38 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 24 May 2022 14:51:38 GMT Subject: RFR: 8286891: thread_local causes undefined symbol error with XL C [v2] In-Reply-To: References: Message-ID: <49pHOzIlenklmuXqBziuytfpM5_zeNA--ba6CBRAk2w=.74474896-d1ec-4cee-a0f7-b3287289e735@github.com> On Tue, 24 May 2022 14:32:53 GMT, Tyler Steele wrote: >> When using XLClang++ to compile a `thread_local` struct with a destructor, a compiler bug is exposed that results in a missing constructor and a linker error. >> >> Adding the missing constructor solves this issue. >> >> Changes >> - Builds on AIX (previously broken) > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Remove AIX-specific macro Marked as reviewed by jvernee (Reviewer). This looks good to me, but please note that this file was recently renamed to `upcallLinker.cpp` as well, so you might want to merge master into your PR branch before integrating to make sure the change is applied to the right file. ------------- PR: https://git.openjdk.java.net/jdk/pull/8754 From mdoerr at openjdk.java.net Tue May 24 15:12:04 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 24 May 2022 15:12:04 GMT Subject: RFR: 8286891: thread_local causes undefined symbol error with XL C [v3] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 14:51:38 GMT, Tyler Steele wrote: >> When using XLClang++ to compile a `thread_local` struct with a destructor, a compiler bug is exposed that results in a missing constructor and a linker error. >> >> Adding the missing constructor solves this issue. >> >> Changes >> - Builds on AIX (previously broken) > > Tyler Steele 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 thread_local-build-break > - Update compiler year > - Remove AIX-specific macro > - XL C compiler bug workaround Thanks for the update! ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8754 From tschatzl at openjdk.java.net Tue May 24 16:11:36 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 24 May 2022 16:11:36 GMT Subject: RFR: 8287215: Add method to scan bitmap backwards Message-ID: Hi all, can I have reviews for this change that adds a method to scan bitmaps backwards? This functionality is necessary for upcoming change to remove on of the mark bitmaps [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708). As such this is only an addition of that functionality with no reference (apart from the gtest) from Hotspot itself. Testing: gtest Thanks, Thomas ------------- Commit messages: - 8287215: Add method to scan bitmap backwards Changes: https://git.openjdk.java.net/jdk/pull/8869/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8869&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287215 Stats: 241 lines in 4 files changed: 229 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/8869.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8869/head:pull/8869 PR: https://git.openjdk.java.net/jdk/pull/8869 From iklam at openjdk.java.net Tue May 24 16:21:10 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 24 May 2022 16:21:10 GMT Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate [v4] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 12:33:59 GMT, Stefan Karlsson wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> some clean up suggested by @stefank > > src/hotspot/share/utilities/resourceHash.hpp line 210: > >> 208: }; >> 209: iterate(function); >> 210: } > > Do you still have any usages of this? I'm a bit surprised that the compiler don't complain about not being able to disambiguate calls to this vs the new lambda enabled function. This is still needed as there are many places that use the old style iteration. Also, when the body of the iteration is complex, it might be more readable to do it as a separate class. E.g., here in systemDictionaryShared.cpp: UnregisteredClassesDuplicationChecker dup_checker; _dumptime_table->iterate(&dup_checker); I think there's no ambiguity because `iter->do_entry()` cannot be substituted with the other template, and `function(node->_key, node->_value)` in the other template cannot be substituted here. So by SFINAE the C++ compiler can pick the correct template. ------------- PR: https://git.openjdk.java.net/jdk/pull/8761 From iklam at openjdk.java.net Tue May 24 16:25:04 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 24 May 2022 16:25:04 GMT Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate [v4] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 12:29:32 GMT, Stefan Karlsson wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> some clean up suggested by @stefank > > src/hotspot/share/classfile/systemDictionaryShared.cpp line 672: > >> 670: SystemDictionaryShared::check_for_exclusion(k, &info); >> 671: }; >> 672: _dumptime_table->iterate_all(check_for_exclusion); > > Can't this be changed to just: > `_dumptime_table->iterate_all(SystemDictionaryShared::check_for_exclusion);` > > or maybe even: > `_dumptime_table->iterate_all(check_for_exclusion);` The second parameter to `SystemDictionaryShared::check_for_exclusion()` is a `DumpTimeClassInfo*` because NULL is allowed. However, the iterator requires a `DumpTimeClassInfo&`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8761 From tsteele at openjdk.java.net Tue May 24 16:29:08 2022 From: tsteele at openjdk.java.net (Tyler Steele) Date: Tue, 24 May 2022 16:29:08 GMT Subject: Integrated: 8286891: thread_local causes undefined symbol error with XL C In-Reply-To: References: Message-ID: On Tue, 17 May 2022 15:56:28 GMT, Tyler Steele wrote: > When using XLClang++ to compile a `thread_local` struct with a destructor, a compiler bug is exposed that results in a missing constructor and a linker error. > > Adding the missing constructor solves this issue. > > Changes > - Builds on AIX (previously broken) This pull request has now been integrated. Changeset: 25080e0c Author: Tyler Steele Committer: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/25080e0c3ac75ea2b9f04fcbca37b96c46ea3473 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8286891: thread_local causes undefined symbol error with XL C Reviewed-by: mdoerr, mbaesken, jvernee ------------- PR: https://git.openjdk.java.net/jdk/pull/8754 From duke at openjdk.java.net Tue May 24 16:48:54 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Tue, 24 May 2022 16:48:54 GMT Subject: RFR: 8286058: AArch64: clarify types of calls [v3] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 16:46:32 GMT, Evgeny Astigeevich wrote: >> The PR clarifies the types of calls AArch64 OpenJDK uses. It cleans up far_call, far_jump and trampoline_call. It removes trampoline_call1 because its use cases are now supported by trampoline_call. >> Tested a fastdebug build: >> - `gtest`: Passed >> - `tier1`...`tier3`: Passed > > Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Describe call types; Fix API > - Merge branch 'master' into JDK-8286058 > - Merge branch 'master' into JDK-8286058 > - Fix assert message > - 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call Hi Andrew, The final version is here. Could you please review it? ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From sspitsyn at openjdk.java.net Tue May 24 17:01:54 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 24 May 2022 17:01:54 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect In-Reply-To: References: Message-ID: On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn wrote: > It was a typo when the original CLEARING_MASK was initially introduced: > > > // Mask to clear normal event bits. > const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; > // Avoid cleaning extension event bits. > jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits(); > > ``` > > The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below: > ` const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;` > > Let me provide some background to understand how this mask is used. > > Normal JVMTI event types are numbered from 50 to 88. There are two constants: > > JVMTI_MIN_EVENT_TYPE_VAL = 50 > JVMTI_MAX_EVENT_TYPE_VAL = 88 > > The extension event types are numbered from 47 to 49. There are also two constants: > > EXT_MIN_EVENT_TYPE_VAL = 47 > EXT_MAX_EVENT_TYPE_VAL = 49 > > > There are also two additional constants: > > TOTAL_MIN_EVENT_TYPE_VAL = 47 > TOTAL_MAX_EVENT_TYPE_VAL = 88 > > > The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged. > > Testing: > I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage. Thank you for review, Jaroslav! ------------- PR: https://git.openjdk.java.net/jdk/pull/8860 From zgu at openjdk.java.net Tue May 24 17:35:32 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 24 May 2022 17:35:32 GMT Subject: RFR: 8287249: Zero: Missing BarrierSetNMethod::arm() method Message-ID: <46UK-M-b9lAWEVhCW_fW7W77HW4oJEyZw0Y6HRi51gw=.b5a5a515-bbd7-479e-b813-148837103704@github.com> Please review this trivial patch that adds missing method in Zero ------------- Commit messages: - 8287249: Zero: Missing BarrierSetNMethod::arm() method Changes: https://git.openjdk.java.net/jdk/pull/8873/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8873&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287249 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8873.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8873/head:pull/8873 PR: https://git.openjdk.java.net/jdk/pull/8873 From shade at openjdk.java.net Tue May 24 17:40:24 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 24 May 2022 17:40:24 GMT Subject: RFR: 8287249: Zero: Missing BarrierSetNMethod::arm() method In-Reply-To: <46UK-M-b9lAWEVhCW_fW7W77HW4oJEyZw0Y6HRi51gw=.b5a5a515-bbd7-479e-b813-148837103704@github.com> References: <46UK-M-b9lAWEVhCW_fW7W77HW4oJEyZw0Y6HRi51gw=.b5a5a515-bbd7-479e-b813-148837103704@github.com> Message-ID: On Tue, 24 May 2022 17:25:58 GMT, Zhengyu Gu wrote: > Please review this trivial patch that adds missing method in Zero Looks fine and trivial. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8873 From tschatzl at openjdk.java.net Tue May 24 17:59:50 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 24 May 2022 17:59:50 GMT Subject: RFR: 8287215: Add method to scan bitmap backwards [v2] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that adds a method to scan bitmaps backwards? This functionality is necessary for upcoming change to remove on of the mark bitmaps [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708). > > As such this is only an addition of that functionality with no reference (apart from the gtest) from Hotspot itself. > > Testing: gtest > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Fix documentation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8869/files - new: https://git.openjdk.java.net/jdk/pull/8869/files/84780076..03586c59 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8869&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8869&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8869.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8869/head:pull/8869 PR: https://git.openjdk.java.net/jdk/pull/8869 From zgu at openjdk.java.net Tue May 24 18:11:55 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 24 May 2022 18:11:55 GMT Subject: RFR: 8287249: Zero: Missing BarrierSetNMethod::arm() method In-Reply-To: References: <46UK-M-b9lAWEVhCW_fW7W77HW4oJEyZw0Y6HRi51gw=.b5a5a515-bbd7-479e-b813-148837103704@github.com> Message-ID: On Tue, 24 May 2022 17:36:23 GMT, Aleksey Shipilev wrote: >> Please review this trivial patch that adds missing method in Zero > > Looks fine and trivial. Thanks, @shipilev ------------- PR: https://git.openjdk.java.net/jdk/pull/8873 From zgu at openjdk.java.net Tue May 24 18:15:55 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 24 May 2022 18:15:55 GMT Subject: Integrated: 8287249: Zero: Missing BarrierSetNMethod::arm() method In-Reply-To: <46UK-M-b9lAWEVhCW_fW7W77HW4oJEyZw0Y6HRi51gw=.b5a5a515-bbd7-479e-b813-148837103704@github.com> References: <46UK-M-b9lAWEVhCW_fW7W77HW4oJEyZw0Y6HRi51gw=.b5a5a515-bbd7-479e-b813-148837103704@github.com> Message-ID: On Tue, 24 May 2022 17:25:58 GMT, Zhengyu Gu wrote: > Please review this trivial patch that adds missing method in Zero This pull request has now been integrated. Changeset: 194bc08a Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/194bc08a899d699b34d3d896001af8c642758b1d Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8287249: Zero: Missing BarrierSetNMethod::arm() method Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/8873 From cjplummer at openjdk.java.net Tue May 24 19:25:56 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 24 May 2022 19:25:56 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect In-Reply-To: References: Message-ID: On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn wrote: > It was a typo when the original CLEARING_MASK was initially introduced: > > > // Mask to clear normal event bits. > const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; > // Avoid cleaning extension event bits. > jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits(); > > ``` > > The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below: > ` const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;` > > Let me provide some background to understand how this mask is used. > > Normal JVMTI event types are numbered from 50 to 88. There are two constants: > > JVMTI_MIN_EVENT_TYPE_VAL = 50 > JVMTI_MAX_EVENT_TYPE_VAL = 88 > > The extension event types are numbered from 47 to 49. There are also two constants: > > EXT_MIN_EVENT_TYPE_VAL = 47 > EXT_MAX_EVENT_TYPE_VAL = 49 > > > There are also two additional constants: > > TOTAL_MIN_EVENT_TYPE_VAL = 47 > TOTAL_MAX_EVENT_TYPE_VAL = 88 > > > The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged. > > Testing: > I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage. Is there a reason no tests are failing as a result of this? It's unclear how this bug is exposed to JVMTI clients. ------------- PR: https://git.openjdk.java.net/jdk/pull/8860 From cjplummer at openjdk.java.net Tue May 24 19:44:50 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 24 May 2022 19:44:50 GMT Subject: RFR: 8286711: AArch64: serviceability agent tests fail with PAC enabled In-Reply-To: References: Message-ID: On Fri, 20 May 2022 15:52:04 GMT, Nick Gasson wrote: > When the VM is run with `-XX:UseBranchProtection=pac-ret` on a supported CPU, the upper bits of the saved link register contain a "pointer authentication code" which must be checked and removed by a special instruction before a function returns. The serviceability agent is unaware of this and so sees garbled PC values when walking the stack. This patch just masks out the PAC bits from the sender PC after reading it from the stack frame. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8814 From sspitsyn at openjdk.java.net Tue May 24 20:43:02 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 24 May 2022 20:43:02 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect In-Reply-To: References: Message-ID: On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn wrote: > It was a typo when the original CLEARING_MASK was initially introduced: > > > // Mask to clear normal event bits. > const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; > // Avoid cleaning extension event bits. > jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits(); > > ``` > > The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below: > ` const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;` > > Let me provide some background to understand how this mask is used. > > Normal JVMTI event types are numbered from 50 to 88. There are two constants: > > JVMTI_MIN_EVENT_TYPE_VAL = 50 > JVMTI_MAX_EVENT_TYPE_VAL = 88 > > The extension event types are numbered from 47 to 49. There are also two constants: > > EXT_MIN_EVENT_TYPE_VAL = 47 > EXT_MAX_EVENT_TYPE_VAL = 49 > > > There are also two additional constants: > > TOTAL_MIN_EVENT_TYPE_VAL = 47 > TOTAL_MAX_EVENT_TYPE_VAL = 88 > > > The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged. > > Testing: > I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage. The extension events are not much used in the tests. There was only one extension event inn pre-jdk19 which is ClassUnload. This event was implemented to prove the event extension mechanism is working but it is is not really used anywhere except in our testing. Two new extension events were introduced to support testing of virtual threads: - VirtualThreadMount - VirtualThreadUnmount This particular issue depends on the order the extension events and normal JVMTI events are enabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/8860 From cjplummer at openjdk.java.net Tue May 24 20:48:58 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 24 May 2022 20:48:58 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect In-Reply-To: References: Message-ID: On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn wrote: > It was a typo when the original CLEARING_MASK was initially introduced: > > > // Mask to clear normal event bits. > const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; > // Avoid cleaning extension event bits. > jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits(); > > ``` > > The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below: > ` const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;` > > Let me provide some background to understand how this mask is used. > > Normal JVMTI event types are numbered from 50 to 88. There are two constants: > > JVMTI_MIN_EVENT_TYPE_VAL = 50 > JVMTI_MAX_EVENT_TYPE_VAL = 88 > > The extension event types are numbered from 47 to 49. There are also two constants: > > EXT_MIN_EVENT_TYPE_VAL = 47 > EXT_MAX_EVENT_TYPE_VAL = 49 > > > There are also two additional constants: > > TOTAL_MIN_EVENT_TYPE_VAL = 47 > TOTAL_MAX_EVENT_TYPE_VAL = 88 > > > The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged. > > Testing: > I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage. What would it take to write a test that fails due to this bug? ------------- PR: https://git.openjdk.java.net/jdk/pull/8860 From sspitsyn at openjdk.java.net Tue May 24 20:59:55 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 24 May 2022 20:59:55 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect In-Reply-To: References: Message-ID: On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn wrote: > It was a typo when the original CLEARING_MASK was initially introduced: > > > // Mask to clear normal event bits. > const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; > // Avoid cleaning extension event bits. > jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits(); > > ``` > > The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below: > ` const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;` > > Let me provide some background to understand how this mask is used. > > Normal JVMTI event types are numbered from 50 to 88. There are two constants: > > JVMTI_MIN_EVENT_TYPE_VAL = 50 > JVMTI_MAX_EVENT_TYPE_VAL = 88 > > The extension event types are numbered from 47 to 49. There are also two constants: > > EXT_MIN_EVENT_TYPE_VAL = 47 > EXT_MAX_EVENT_TYPE_VAL = 49 > > > There are also two additional constants: > > TOTAL_MIN_EVENT_TYPE_VAL = 47 > TOTAL_MAX_EVENT_TYPE_VAL = 88 > > > The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged. > > Testing: > I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage. One (I do not remember what was the exact test) of the new serviceability/jvmti/vthread tests was failing initially. It was a motivation to add this `CLEARING_MASK`. I'm puzzled why it did not fail because of this typo. Will try to find out. I doubt that it was problem-listed because I normally run all the serviceability/jvmti/vthread tests in the repo-loom. ------------- PR: https://git.openjdk.java.net/jdk/pull/8860 From dholmes at openjdk.java.net Tue May 24 21:13:59 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 24 May 2022 21:13:59 GMT Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom integration [v3] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 18:25:23 GMT, Aleksey Shipilev wrote: >> [JDK-8284161](https://bugs.openjdk.java.net/browse/JDK-8284161) broke a lot of x86_32 code. The x86_32 porting is done under [JDK-8286642](https://bugs.openjdk.java.net/browse/JDK-8286642). Meanwhile, we can problemlist the failing tests to get cleaner runs for other patches. This should also make GHA runs cleaner. >> >> Additional testing: >> - [x] Linux x86_32 fastdebug `tier1` (some unrelated failures in hotspot) >> - [x] Linux x86_32 fastdebug `tier2` (some unrelated failures in hotspot) >> - [x] Linux x86_32 fastdebug `tier3` (clean now) >> - [x] GHA run > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Another release test There is a mistake in this changeset. The JDK ProblemList already contained: `java/nio/channels/FileChannel/LargeMapTest.java 8286980 windows-all` and this change then added: `java/nio/channels/FileChannel/LargeMapTest.java 8286642 generic-i586` which appears to have negated the first entry. ------------- PR: https://git.openjdk.java.net/jdk/pull/8843 From lmesnik at openjdk.java.net Tue May 24 21:37:56 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 24 May 2022 21:37:56 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect In-Reply-To: References: Message-ID: On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn wrote: > It was a typo when the original CLEARING_MASK was initially introduced: > > > // Mask to clear normal event bits. > const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; > // Avoid cleaning extension event bits. > jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits(); > > ``` > > The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below: > ` const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;` > > Let me provide some background to understand how this mask is used. > > Normal JVMTI event types are numbered from 50 to 88. There are two constants: > > JVMTI_MIN_EVENT_TYPE_VAL = 50 > JVMTI_MAX_EVENT_TYPE_VAL = 88 > > The extension event types are numbered from 47 to 49. There are also two constants: > > EXT_MIN_EVENT_TYPE_VAL = 47 > EXT_MAX_EVENT_TYPE_VAL = 49 > > > There are also two additional constants: > > TOTAL_MIN_EVENT_TYPE_VAL = 47 > TOTAL_MAX_EVENT_TYPE_VAL = 88 > > > The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged. > > Testing: > I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8860 From sspitsyn at openjdk.java.net Tue May 24 21:47:54 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 24 May 2022 21:47:54 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect [v2] In-Reply-To: References: Message-ID: <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com> > It was a typo when the original CLEARING_MASK was initially introduced: > > > // Mask to clear normal event bits. > const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; > // Avoid cleaning extension event bits. > jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits(); > > ``` > > The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below: > ` const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;` > > Let me provide some background to understand how this mask is used. > > Normal JVMTI event types are numbered from 50 to 88. There are two constants: > > JVMTI_MIN_EVENT_TYPE_VAL = 50 > JVMTI_MAX_EVENT_TYPE_VAL = 88 > > The extension event types are numbered from 47 to 49. There are also two constants: > > EXT_MIN_EVENT_TYPE_VAL = 47 > EXT_MAX_EVENT_TYPE_VAL = 49 > > > There are also two additional constants: > > TOTAL_MIN_EVENT_TYPE_VAL = 47 > TOTAL_MAX_EVENT_TYPE_VAL = 88 > > > The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged. > > Testing: > I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: add extra test coverage for JVMTI extension events: VirtualThreadMount/VirtualThreadUnmount ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8860/files - new: https://git.openjdk.java.net/jdk/pull/8860/files/d77b8dcb..6361d85b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8860&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8860&range=00-01 Stats: 35 lines in 2 files changed: 31 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8860.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8860/head:pull/8860 PR: https://git.openjdk.java.net/jdk/pull/8860 From sspitsyn at openjdk.java.net Tue May 24 21:53:00 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 24 May 2022 21:53:00 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect [v2] In-Reply-To: <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com> References: <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com> Message-ID: On Tue, 24 May 2022 21:47:54 GMT, Serguei Spitsyn wrote: >> It was a typo when the original CLEARING_MASK was initially introduced: >> >> >> // Mask to clear normal event bits. >> const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; >> // Avoid cleaning extension event bits. >> jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits(); >> >> ``` >> >> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below: >> ` const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;` >> >> Let me provide some background to understand how this mask is used. >> >> Normal JVMTI event types are numbered from 50 to 88. There are two constants: >> >> JVMTI_MIN_EVENT_TYPE_VAL = 50 >> JVMTI_MAX_EVENT_TYPE_VAL = 88 >> >> The extension event types are numbered from 47 to 49. There are also two constants: >> >> EXT_MIN_EVENT_TYPE_VAL = 47 >> EXT_MAX_EVENT_TYPE_VAL = 49 >> >> >> There are also two additional constants: >> >> TOTAL_MIN_EVENT_TYPE_VAL = 47 >> TOTAL_MAX_EVENT_TYPE_VAL = 88 >> >> >> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged. >> >> Testing: >> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > add extra test coverage for JVMTI extension events: VirtualThreadMount/VirtualThreadUnmount Leonid, thank you for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/8860 From sspitsyn at openjdk.java.net Tue May 24 21:52:57 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 24 May 2022 21:52:57 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect In-Reply-To: References: Message-ID: On Tue, 24 May 2022 20:45:09 GMT, Chris Plummer wrote: >> It was a typo when the original CLEARING_MASK was initially introduced: >> >> >> // Mask to clear normal event bits. >> const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; >> // Avoid cleaning extension event bits. >> jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits(); >> >> ``` >> >> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below: >> ` const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;` >> >> Let me provide some background to understand how this mask is used. >> >> Normal JVMTI event types are numbered from 50 to 88. There are two constants: >> >> JVMTI_MIN_EVENT_TYPE_VAL = 50 >> JVMTI_MAX_EVENT_TYPE_VAL = 88 >> >> The extension event types are numbered from 47 to 49. There are also two constants: >> >> EXT_MIN_EVENT_TYPE_VAL = 47 >> EXT_MAX_EVENT_TYPE_VAL = 49 >> >> >> There are also two additional constants: >> >> TOTAL_MIN_EVENT_TYPE_VAL = 47 >> TOTAL_MAX_EVENT_TYPE_VAL = 88 >> >> >> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged. >> >> Testing: >> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage. > > What would it take to write a test that fails due to this bug? @plummercj I've updated the serviceability/jvmti/vthreadVThreadTest to provide test coverage for this issue. The updated test is failed without this fix and is passed with it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8860 From cjplummer at openjdk.java.net Tue May 24 22:04:03 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 24 May 2022 22:04:03 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect [v2] In-Reply-To: <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com> References: <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com> Message-ID: On Tue, 24 May 2022 21:47:54 GMT, Serguei Spitsyn wrote: >> It was a typo when the original CLEARING_MASK was initially introduced: >> >> >> // Mask to clear normal event bits. >> const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; >> // Avoid cleaning extension event bits. >> jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits(); >> >> ``` >> >> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below: >> ` const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;` >> >> Let me provide some background to understand how this mask is used. >> >> Normal JVMTI event types are numbered from 50 to 88. There are two constants: >> >> JVMTI_MIN_EVENT_TYPE_VAL = 50 >> JVMTI_MAX_EVENT_TYPE_VAL = 88 >> >> The extension event types are numbered from 47 to 49. There are also two constants: >> >> EXT_MIN_EVENT_TYPE_VAL = 47 >> EXT_MAX_EVENT_TYPE_VAL = 49 >> >> >> There are also two additional constants: >> >> TOTAL_MIN_EVENT_TYPE_VAL = 47 >> TOTAL_MAX_EVENT_TYPE_VAL = 88 >> >> >> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged. >> >> Testing: >> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > add extra test coverage for JVMTI extension events: VirtualThreadMount/VirtualThreadUnmount test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTest/libVThreadTest.cpp line 625: > 623: } > 624: > 625: err = jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_VIRTUAL_THREAD_END, NULL); Why does the ordering matter for these 4 SetEventNotificationMode() calls? ------------- PR: https://git.openjdk.java.net/jdk/pull/8860 From amenkov at openjdk.java.net Tue May 24 22:26:01 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 24 May 2022 22:26:01 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect [v2] In-Reply-To: <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com> References: <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com> Message-ID: On Tue, 24 May 2022 21:47:54 GMT, Serguei Spitsyn wrote: >> It was a typo when the original CLEARING_MASK was initially introduced: >> >> >> // Mask to clear normal event bits. >> const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; >> // Avoid cleaning extension event bits. >> jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits(); >> >> ``` >> >> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below: >> ` const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;` >> >> Let me provide some background to understand how this mask is used. >> >> Normal JVMTI event types are numbered from 50 to 88. There are two constants: >> >> JVMTI_MIN_EVENT_TYPE_VAL = 50 >> JVMTI_MAX_EVENT_TYPE_VAL = 88 >> >> The extension event types are numbered from 47 to 49. There are also two constants: >> >> EXT_MIN_EVENT_TYPE_VAL = 47 >> EXT_MAX_EVENT_TYPE_VAL = 49 >> >> >> There are also two additional constants: >> >> TOTAL_MIN_EVENT_TYPE_VAL = 47 >> TOTAL_MAX_EVENT_TYPE_VAL = 88 >> >> >> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged. >> >> Testing: >> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > add extra test coverage for JVMTI extension events: VirtualThreadMount/VirtualThreadUnmount src/hotspot/share/prims/jvmtiEventController.cpp line 775: > 773: env->set_event_callbacks(callbacks, size_of_callbacks); > 774: // Mask to clear normal event bits. > 775: const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; I don't follow how this works.. Should it be "<<" instead of ">>" ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8860 From amenkov at openjdk.java.net Tue May 24 22:34:54 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 24 May 2022 22:34:54 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect [v2] In-Reply-To: References: <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com> Message-ID: <3Oxe_GC9Wuh4kk6WjkZeZ6FvXpg8c5S5GVOE1sMhCk0=.e8243417-8d19-493c-9dc4-9a1aeb1bfbf5@github.com> On Tue, 24 May 2022 22:23:59 GMT, Alex Menkov wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> add extra test coverage for JVMTI extension events: VirtualThreadMount/VirtualThreadUnmount > > src/hotspot/share/prims/jvmtiEventController.cpp line 775: > >> 773: env->set_event_callbacks(callbacks, size_of_callbacks); >> 774: // Mask to clear normal event bits. >> 775: const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; > > I don't follow how this works.. > Should it be "<<" instead of ">>" ? Maybe it would be clearer to turn off the bits when there are no events: jlong enabled_bits = env->env_event_enable()->_event_callback_enabled.get_bits(); for (int ei = JVMTI_MIN_EVENT_TYPE_VAL; ei <= JVMTI_MAX_EVENT_TYPE_VAL; ++ei) { jvmtiEvent evt_t = (jvmtiEvent)ei; if (!env->has_callback(evt_t)) { // clear the bit if there is no callback enabled_bits &= ~JvmtiEventEnabled::bit_for(evt_t); } } ------------- PR: https://git.openjdk.java.net/jdk/pull/8860 From sspitsyn at openjdk.java.net Tue May 24 23:00:56 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 24 May 2022 23:00:56 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect [v2] In-Reply-To: References: <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com> Message-ID: On Tue, 24 May 2022 22:00:01 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> add extra test coverage for JVMTI extension events: VirtualThreadMount/VirtualThreadUnmount > > test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTest/libVThreadTest.cpp line 625: > >> 623: } >> 624: >> 625: err = jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_VIRTUAL_THREAD_END, NULL); > > Why does the ordering matter for these 4 SetEventNotificationMode() calls? You are right. This order does not matter. What matters is the order of calls to SetExtensionEventCallback and SetEventCallbacks. It is important to call SetExtensionEventCallback first in order to reproduce the issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/8860 From sspitsyn at openjdk.java.net Tue May 24 23:05:41 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 24 May 2022 23:05:41 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect [v3] In-Reply-To: References: Message-ID: > It was a typo when the original CLEARING_MASK was initially introduced: > > > // Mask to clear normal event bits. > const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; > // Avoid cleaning extension event bits. > jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits(); > > ``` > > The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below: > ` const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;` > > Let me provide some background to understand how this mask is used. > > Normal JVMTI event types are numbered from 50 to 88. There are two constants: > > JVMTI_MIN_EVENT_TYPE_VAL = 50 > JVMTI_MAX_EVENT_TYPE_VAL = 88 > > The extension event types are numbered from 47 to 49. There are also two constants: > > EXT_MIN_EVENT_TYPE_VAL = 47 > EXT_MAX_EVENT_TYPE_VAL = 49 > > > There are also two additional constants: > > TOTAL_MIN_EVENT_TYPE_VAL = 47 > TOTAL_MAX_EVENT_TYPE_VAL = 88 > > > The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged. > > Testing: > I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: roll back changes that are not needed to reproduce JVMTI problem with CLEARING_MASK ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8860/files - new: https://git.openjdk.java.net/jdk/pull/8860/files/6361d85b..f4ec32ef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8860&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8860&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8860.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8860/head:pull/8860 PR: https://git.openjdk.java.net/jdk/pull/8860 From sspitsyn at openjdk.java.net Tue May 24 23:34:53 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 24 May 2022 23:34:53 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect [v2] In-Reply-To: <3Oxe_GC9Wuh4kk6WjkZeZ6FvXpg8c5S5GVOE1sMhCk0=.e8243417-8d19-493c-9dc4-9a1aeb1bfbf5@github.com> References: <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com> <3Oxe_GC9Wuh4kk6WjkZeZ6FvXpg8c5S5GVOE1sMhCk0=.e8243417-8d19-493c-9dc4-9a1aeb1bfbf5@github.com> Message-ID: On Tue, 24 May 2022 22:31:16 GMT, Alex Menkov wrote: >> src/hotspot/share/prims/jvmtiEventController.cpp line 775: >> >>> 773: env->set_event_callbacks(callbacks, size_of_callbacks); >>> 774: // Mask to clear normal event bits. >>> 775: const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; >> >> I don't follow how this works.. >> Should it be "<<" instead of ">>" ? > > Maybe it would be clearer to turn off the bits when there are no events: > > jlong enabled_bits = env->env_event_enable()->_event_callback_enabled.get_bits(); > for (int ei = JVMTI_MIN_EVENT_TYPE_VAL; ei <= JVMTI_MAX_EVENT_TYPE_VAL; ++ei) { > jvmtiEvent evt_t = (jvmtiEvent)ei; > if (!env->has_callback(evt_t)) { > // clear the bit if there is no callback > enabled_bits &= ~JvmtiEventEnabled::bit_for(evt_t); > } > } Thanks, Alex! You are right - fixed. I was stupid enough to confuse the direction. Minimal tracing helps in such cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/8860 From sspitsyn at openjdk.java.net Tue May 24 23:39:56 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 24 May 2022 23:39:56 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect [v4] In-Reply-To: References: Message-ID: <4cfAXWCngz4N3LTF-rDkfhmPAU8DH9m9_fV2KY6nC9k=.79e1fc47-764d-4306-b3eb-5a09359759a9@github.com> > It was a typo when the original CLEARING_MASK was initially introduced: > > > // Mask to clear normal event bits. > const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; > // Avoid cleaning extension event bits. > jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits(); > > ``` > > The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below: > ` const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;` > > Let me provide some background to understand how this mask is used. > > Normal JVMTI event types are numbered from 50 to 88. There are two constants: > > JVMTI_MIN_EVENT_TYPE_VAL = 50 > JVMTI_MAX_EVENT_TYPE_VAL = 88 > > The extension event types are numbered from 47 to 49. There are also two constants: > > EXT_MIN_EVENT_TYPE_VAL = 47 > EXT_MAX_EVENT_TYPE_VAL = 49 > > > There are also two additional constants: > > TOTAL_MIN_EVENT_TYPE_VAL = 47 > TOTAL_MAX_EVENT_TYPE_VAL = 88 > > > The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged. > > Testing: > I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: replaced right shift with left shift in CLEARING_MASK setting ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8860/files - new: https://git.openjdk.java.net/jdk/pull/8860/files/f4ec32ef..0c80ef4a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8860&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8860&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8860.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8860/head:pull/8860 PR: https://git.openjdk.java.net/jdk/pull/8860 From sspitsyn at openjdk.java.net Tue May 24 23:52:01 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 24 May 2022 23:52:01 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect [v2] In-Reply-To: References: <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com> <3Oxe_GC9Wuh4kk6WjkZeZ6FvXpg8c5S5GVOE1sMhCk0=.e8243417-8d19-493c-9dc4-9a1aeb1bfbf5@github.com> Message-ID: On Tue, 24 May 2022 23:31:36 GMT, Serguei Spitsyn wrote: >> Maybe it would be clearer to turn off the bits when there are no events: >> >> jlong enabled_bits = env->env_event_enable()->_event_callback_enabled.get_bits(); >> for (int ei = JVMTI_MIN_EVENT_TYPE_VAL; ei <= JVMTI_MAX_EVENT_TYPE_VAL; ++ei) { >> jvmtiEvent evt_t = (jvmtiEvent)ei; >> if (!env->has_callback(evt_t)) { >> // clear the bit if there is no callback >> enabled_bits &= ~JvmtiEventEnabled::bit_for(evt_t); >> } >> } > > Thanks, Alex! You are right - fixed. > I was stupid enough to confuse the direction. Minimal tracing helps in such cases. Clearing event bits to make it more readable looks like a good idea. What about the following? : jlong enabled_bits = env->env_event_enable()->_event_callback_enabled.get_bits(); for (int ei = JVMTI_MIN_EVENT_TYPE_VAL; ei <= JVMTI_MAX_EVENT_TYPE_VAL; ++ei) { jvmtiEvent evt_t = (jvmtiEvent)ei; if (env->has_callback(evt_t)) { // set the bit if there is a callback enabled_bits |= JvmtiEventEnabled::bit_for(evt_t); } else { // clear the bit if there is no callback enabled_bits &= ~JvmtiEventEnabled::bit_for(evt_t); } } ------------- PR: https://git.openjdk.java.net/jdk/pull/8860 From sspitsyn at openjdk.java.net Wed May 25 00:20:48 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 25 May 2022 00:20:48 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect [v5] In-Reply-To: References: Message-ID: > It was a typo when the original CLEARING_MASK was initially introduced: > > > // Mask to clear normal event bits. > const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; > // Avoid cleaning extension event bits. > jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits(); > > ``` > > The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below: > ` const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;` > > Let me provide some background to understand how this mask is used. > > Normal JVMTI event types are numbered from 50 to 88. There are two constants: > > JVMTI_MIN_EVENT_TYPE_VAL = 50 > JVMTI_MAX_EVENT_TYPE_VAL = 88 > > The extension event types are numbered from 47 to 49. There are also two constants: > > EXT_MIN_EVENT_TYPE_VAL = 47 > EXT_MAX_EVENT_TYPE_VAL = 49 > > > There are also two additional constants: > > TOTAL_MIN_EVENT_TYPE_VAL = 47 > TOTAL_MAX_EVENT_TYPE_VAL = 88 > > > The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged. > > Testing: > I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: get rid of CLEARING_MASK in JVMTI set_event_callbacks ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8860/files - new: https://git.openjdk.java.net/jdk/pull/8860/files/0c80ef4a..9a899ddd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8860&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8860&range=03-04 Stats: 9 lines in 1 file changed: 4 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8860.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8860/head:pull/8860 PR: https://git.openjdk.java.net/jdk/pull/8860 From sspitsyn at openjdk.java.net Wed May 25 00:24:52 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 25 May 2022 00:24:52 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect [v2] In-Reply-To: References: <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com> <3Oxe_GC9Wuh4kk6WjkZeZ6FvXpg8c5S5GVOE1sMhCk0=.e8243417-8d19-493c-9dc4-9a1aeb1bfbf5@github.com> Message-ID: On Tue, 24 May 2022 23:49:41 GMT, Serguei Spitsyn wrote: >> Thanks, Alex! You are right - fixed. >> I was stupid enough to confuse the direction. Minimal tracing helps in such cases. > > Clearing event bits to make it more readable looks like a good idea. > What about the following? : > > jlong enabled_bits = env->env_event_enable()->_event_callback_enabled.get_bits(); > for (int ei = JVMTI_MIN_EVENT_TYPE_VAL; ei <= JVMTI_MAX_EVENT_TYPE_VAL; ++ei) { > jvmtiEvent evt_t = (jvmtiEvent)ei; > jlong bit_for = JvmtiEventEnabled::bit_for(evt_t); > if (env->has_callback(evt_t)) { > enabled_bits |= bit_for; > } else { > enabled_bits &= ~bit_for; > } > } Alex, I've removed the CLEARING_MASK and implemented your suggestion which makes the code more clear. ------------- PR: https://git.openjdk.java.net/jdk/pull/8860 From amenkov at openjdk.java.net Wed May 25 00:44:56 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 25 May 2022 00:44:56 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect [v5] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 00:20:48 GMT, Serguei Spitsyn wrote: >> It was a typo when the original CLEARING_MASK was initially introduced: >> >> >> // Mask to clear normal event bits. >> const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; >> // Avoid cleaning extension event bits. >> jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits(); >> >> ``` >> >> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below: >> ` const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;` >> >> Let me provide some background to understand how this mask is used. >> >> Normal JVMTI event types are numbered from 50 to 88. There are two constants: >> >> JVMTI_MIN_EVENT_TYPE_VAL = 50 >> JVMTI_MAX_EVENT_TYPE_VAL = 88 >> >> The extension event types are numbered from 47 to 49. There are also two constants: >> >> EXT_MIN_EVENT_TYPE_VAL = 47 >> EXT_MAX_EVENT_TYPE_VAL = 49 >> >> >> There are also two additional constants: >> >> TOTAL_MIN_EVENT_TYPE_VAL = 47 >> TOTAL_MAX_EVENT_TYPE_VAL = 88 >> >> >> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged. >> >> Testing: >> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > get rid of CLEARING_MASK in JVMTI set_event_callbacks Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8860 From amenkov at openjdk.java.net Wed May 25 00:44:58 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 25 May 2022 00:44:58 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect [v2] In-Reply-To: References: <1BmnSQP6qUU3ojexHuBeTGYaJwAffZ7-1SLQ7KhPo-Y=.b41739c8-c205-4948-9553-c5ef2c6ac628@github.com> <3Oxe_GC9Wuh4kk6WjkZeZ6FvXpg8c5S5GVOE1sMhCk0=.e8243417-8d19-493c-9dc4-9a1aeb1bfbf5@github.com> Message-ID: On Wed, 25 May 2022 00:21:28 GMT, Serguei Spitsyn wrote: >> Clearing event bits to make it more readable looks like a good idea. >> What about the following? : >> >> jlong enabled_bits = env->env_event_enable()->_event_callback_enabled.get_bits(); >> for (int ei = JVMTI_MIN_EVENT_TYPE_VAL; ei <= JVMTI_MAX_EVENT_TYPE_VAL; ++ei) { >> jvmtiEvent evt_t = (jvmtiEvent)ei; >> jlong bit_for = JvmtiEventEnabled::bit_for(evt_t); >> if (env->has_callback(evt_t)) { >> enabled_bits |= bit_for; >> } else { >> enabled_bits &= ~bit_for; >> } >> } > > Alex, I've removed the CLEARING_MASK and implemented your suggestion which makes the code more clear. Thank you. It looks much clearer to me now. ------------- PR: https://git.openjdk.java.net/jdk/pull/8860 From sspitsyn at openjdk.java.net Wed May 25 00:50:56 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 25 May 2022 00:50:56 GMT Subject: RFR: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect [v5] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 00:20:48 GMT, Serguei Spitsyn wrote: >> It was a typo when the original CLEARING_MASK was initially introduced: >> >> >> // Mask to clear normal event bits. >> const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; >> // Avoid cleaning extension event bits. >> jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits(); >> >> ``` >> >> The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below: >> ` const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;` >> >> Let me provide some background to understand how this mask is used. >> >> Normal JVMTI event types are numbered from 50 to 88. There are two constants: >> >> JVMTI_MIN_EVENT_TYPE_VAL = 50 >> JVMTI_MAX_EVENT_TYPE_VAL = 88 >> >> The extension event types are numbered from 47 to 49. There are also two constants: >> >> EXT_MIN_EVENT_TYPE_VAL = 47 >> EXT_MAX_EVENT_TYPE_VAL = 49 >> >> >> There are also two additional constants: >> >> TOTAL_MIN_EVENT_TYPE_VAL = 47 >> TOTAL_MAX_EVENT_TYPE_VAL = 88 >> >> >> The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged. >> >> Testing: >> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > get rid of CLEARING_MASK in JVMTI set_event_callbacks Thank you for review and good comments, Alex! ------------- PR: https://git.openjdk.java.net/jdk/pull/8860 From kbarrett at openjdk.java.net Wed May 25 01:54:56 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 25 May 2022 01:54:56 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v5] In-Reply-To: References: Message-ID: <2Fd9HKYBsrWvMvJoKwAL2tN010yXbzMGA15Vz1e9aRU=.80246fcf-ba7e-4ec7-aea3-ec2aa011e863@github.com> On Sun, 22 May 2022 16:45:11 GMT, Kim Barrett wrote: >> It might be GCC bug... >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 >> >> This issue is for integer literal, but [Comment 29](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578#c29) mentions address calculation (e.g. `NULL + offset`) - it is similar the problem in jfrTraceIdBits.inline.hp because `dest` comes from `low_addr()` (`addr + low_offset`). > > I don't see the similarity. That gcc bug is about literals used as addresses, > which get treated (suggested inappropriately) as NULL+offset, with NULL+offset > being a cause of warnings. I don't see that happening in our case. That is, > in our `addr + low_offset`, `addr` doesn't seem to be either a literal or NULL > that I can see. > > It's hard for me to investigate this any further just by perusing the code, so > I'm in the process of getting set up to build with gcc12.x. That will let me > do some experiments. It may take me a few days to get to that point though. I spent some time looking into this one. I agree there is a false positive here, and there doesn't seem to be a better solution than suppressing the warning. I would prefer the change below, rather than what's proposed. Also eliminate the changes to utilities/compilerWarnings files. This is a very gcc-specific issue; there's no reason to generalize the solution. The reason for relocating the suppression is to be able to describe the issue in more detail in a context where that description makes sense. template inline void JfrTraceIdBits::store(jbyte bits, const T* ptr) { assert(ptr != NULL, "invariant"); // gcc12 warns "writing 1 byte into a region of size 0" when T == Klass. // The warning seems to be a false positive. And there is no warning for // other types that use the same mechanisms. The warning also sometimes // goes away with minor code perturbations, such as replacing function calls // with equivalent code directly inlined. PRAGMA_DIAG_PUSH PRAGMA_DISABLE_GCC_WARNING("-Wstringop-overflow") set(bits, traceid_tag_byte(ptr)); PRAGMA_DIAG_POP } ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Wed May 25 01:54:55 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 25 May 2022 01:54:55 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v8] In-Reply-To: References: Message-ID: On Sun, 22 May 2022 08:40:28 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga 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 remote-tracking branch 'upstream/master' into gcc12-warnings > - Use getter function to access "_data" > - Revert changes for bytecodeAssembler.cpp, classFileParser.cpp, symbolTable.cpp > - revert changes for memnode.cpp and type.cpp > - Add assert to check the range of BasicType > - Merge remote-tracking branch 'upstream/master' into HEAD > - Revert change for java.c , parse_manifest.c , LinuxPackage.c > - Calculate char offset before realloc() > - Use return value from JLI_Snprintf > - Avoid pragma error in before GCC 12 > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/c156bcc5...042c1c70 Changes requested by kbarrett (Reviewer). src/hotspot/share/oops/array.hpp line 102: > 100: // standard operations > 101: int length() const { return _length; } > 102: T* data() const { return reinterpret_cast(reinterpret_cast(this) + base_offset_in_bytes()); } Adding the const-qualifier to the `data()` function and then implicitly casting it away (by casting through intptr_t) is wrong. Either don't const-qualify (and leave it to some future use that needs such to address appropriately), or have two functions. Also, the line length is excessive. So this: T* data() { return reinterpret_cast( reinterpret_cast(this) + base_offset_in_bytes()); } and optionally add this: const T* data() const { return reinterpret_cast( reinterpret_cast(this) + base_offset_in_bytes()); } ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From shade at openjdk.java.net Wed May 25 05:41:36 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 25 May 2022 05:41:36 GMT Subject: RFR: 8287137: Problemlist failing x86_32 tests after Loom integration [v3] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 21:10:29 GMT, David Holmes wrote: > Just FYI. There is a mistake in this changeset. The JDK ProblemList already contained: > > `java/nio/channels/FileChannel/LargeMapTest.java 8286980 windows-all` > > and this change then added: > > `java/nio/channels/FileChannel/LargeMapTest.java 8286642 generic-i586` > > which appears to have negated the first entry. Whoops, sorry. It seems not to be a problem since [JDK-8287263](https://bugs.openjdk.java.net/browse/JDK-8287263) committed a few hours ago removed the `windows-all` entry and fixed the test. I checked other ProblemLists, and there are no other double entries. ------------- PR: https://git.openjdk.java.net/jdk/pull/8843 From jbhateja at openjdk.java.net Wed May 25 05:50:23 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 25 May 2022 05:50:23 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v9] In-Reply-To: References: Message-ID: > Hi All, > > Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) > > Following is the brief summary of changes:- > > 1) Extends the scope of existing lanewise API for following new vector operations. > - VectorOperations.BIT_COUNT: counts the number of one-bits > - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits > - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits > - VectorOperations.REVERSE: reversing the order of bits > - VectorOperations.REVERSE_BYTES: reversing the order of bytes > - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. > > 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. > - Vector.compress > - Vector.expand > - VectorMask.compress > > 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. > - Vector.fromMemorySegment > - Vector.intoMemorySegment > > 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. > > > Patch has been regressed over AARCH64 and X86 targets different AVX levels. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8284960: Review comments resolved. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8425/files - new: https://git.openjdk.java.net/jdk/pull/8425/files/17a0e38c..a2c9673d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=07-08 Stats: 110 lines in 7 files changed: 42 ins; 31 del; 37 mod Patch: https://git.openjdk.java.net/jdk/pull/8425.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425 PR: https://git.openjdk.java.net/jdk/pull/8425 From sspitsyn at openjdk.java.net Wed May 25 06:27:10 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 25 May 2022 06:27:10 GMT Subject: Integrated: 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect In-Reply-To: References: Message-ID: On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn wrote: > It was a typo when the original CLEARING_MASK was initially introduced: > > > // Mask to clear normal event bits. > const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L; > // Avoid cleaning extension event bits. > jlong enabled_bits = CLEARING_MASK & env->env_event_enable()->_event_callback_enabled.get_bits(); > > ``` > > The first TOTAL_MIN_EVENT_TYPE_VAL has to be JVMTI_MIN_EVENT_TYPE_VAL as below: > ` const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_TYPE_VAL - TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;` > > Let me provide some background to understand how this mask is used. > > Normal JVMTI event types are numbered from 50 to 88. There are two constants: > > JVMTI_MIN_EVENT_TYPE_VAL = 50 > JVMTI_MAX_EVENT_TYPE_VAL = 88 > > The extension event types are numbered from 47 to 49. There are also two constants: > > EXT_MIN_EVENT_TYPE_VAL = 47 > EXT_MAX_EVENT_TYPE_VAL = 49 > > > There are also two additional constants: > > TOTAL_MIN_EVENT_TYPE_VAL = 47 > TOTAL_MAX_EVENT_TYPE_VAL = 88 > > > The `enabled_bits` are shifted left by 47, so that the 0-bit in `enabled_bits` is for first extension event type. And the first normal JVMTI event type is numbered 3 in the `enabled_bits` bit mask. The `CLEARING_MASK` is used to clear only normal JVMTI event types but keep the extension event bits (0-2) unchanged. > > Testing: > I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti tests including those added in Loom for virtual thread coverage. This pull request has now been integrated. Changeset: a0cccb54 Author: Serguei Spitsyn URL: https://git.openjdk.java.net/jdk/commit/a0cccb54791d954bf08da5aac9b9794e370617c8 Stats: 40 lines in 3 files changed: 35 ins; 4 del; 1 mod 8286490: JvmtiEventControllerPrivate::set_event_callbacks CLEARING_MASK computation is incorrect Reviewed-by: jbachorik, lmesnik, amenkov ------------- PR: https://git.openjdk.java.net/jdk/pull/8860 From jbhateja at openjdk.java.net Wed May 25 06:29:23 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 25 May 2022 06:29:23 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v10] In-Reply-To: References: Message-ID: > Hi All, > > Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) > > Following is the brief summary of changes:- > > 1) Extends the scope of existing lanewise API for following new vector operations. > - VectorOperations.BIT_COUNT: counts the number of one-bits > - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits > - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits > - VectorOperations.REVERSE: reversing the order of bits > - VectorOperations.REVERSE_BYTES: reversing the order of bytes > - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. > > 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. > - Vector.compress > - Vector.expand > - VectorMask.compress > > 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. > - Vector.fromMemorySegment > - Vector.intoMemorySegment > > 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. > > > Patch has been regressed over AARCH64 and X86 targets different AVX levels. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - 8284960: Post merge cleanups. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - 8284960: Review comments resolved. - 8284960: Integrating incremental patches. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - 8284960: Changes to enable jdk.incubator.vector to be treated as preview participant. Code re-organization related to Reverse/ReverseByte IR transforms. - 8284960: Adding --enable-preview in vectorAPI benchmarks. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - 8284960: Review comments resolution. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/742644e2...0f6e1584 ------------- Changes: https://git.openjdk.java.net/jdk/pull/8425/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8425&range=09 Stats: 38021 lines in 228 files changed: 16652 ins; 16924 del; 4445 mod Patch: https://git.openjdk.java.net/jdk/pull/8425.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8425/head:pull/8425 PR: https://git.openjdk.java.net/jdk/pull/8425 From jbhateja at openjdk.java.net Wed May 25 06:29:24 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 25 May 2022 06:29:24 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v8] In-Reply-To: References: <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com> Message-ID: <4u_PL8-QxIYVBgJ23LTdoPWZrTKh70K-beMYXOXZgQQ=.a650a280-dc75-46cd-8449-00c38ddd91ea@github.com> On Mon, 23 May 2022 22:17:40 GMT, Vladimir Kozlov wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8284960: Integrating incremental patches. > > src/hotspot/cpu/x86/assembler_x86.cpp line 8173: > >> 8171: >> 8172: void Assembler::vinsertf32x4(XMMRegister dst, XMMRegister nds, XMMRegister src, uint8_t imm8) { >> 8173: assert(VM_Version::supports_evex(), ""); > > Hmm, did we never trigger this wrong assert because the use was guarded by correct check? Yes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From stefank at openjdk.java.net Wed May 25 06:31:05 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 25 May 2022 06:31:05 GMT Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate [v4] In-Reply-To: References: Message-ID: On Mon, 23 May 2022 17:13:36 GMT, Ioi Lam wrote: >> I added two new template functions to reduce the boilerplate code when walking the entries in a ResourceHashtable >> >> - `template void ResourceHashtable::iterate(F f)` >> - `template void ResourceHashtable::iterate_all(F f)` >> >> I also modified a couple of places in systemDictionaryShared.cpp to use the new functionality. >> >> Testing with tiers 1-4. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > some clean up suggested by @stefank Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8761 From stefank at openjdk.java.net Wed May 25 06:31:09 2022 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 25 May 2022 06:31:09 GMT Subject: RFR: 8276789: Support C++ lambda in ResourceHashtable::iterate [v4] In-Reply-To: References: Message-ID: On Tue, 24 May 2022 16:21:18 GMT, Ioi Lam wrote: >> src/hotspot/share/classfile/systemDictionaryShared.cpp line 672: >> >>> 670: SystemDictionaryShared::check_for_exclusion(k, &info); >>> 671: }; >>> 672: _dumptime_table->iterate_all(check_for_exclusion); >> >> Can't this be changed to just: >> `_dumptime_table->iterate_all(SystemDictionaryShared::check_for_exclusion);` >> >> or maybe even: >> `_dumptime_table->iterate_all(check_for_exclusion);` > > The second parameter to `SystemDictionaryShared::check_for_exclusion()` is a `DumpTimeClassInfo*` because NULL is allowed. However, the iterator requires a `DumpTimeClassInfo&`. OK >> src/hotspot/share/utilities/resourceHash.hpp line 210: >> >>> 208: }; >>> 209: iterate(function); >>> 210: } >> >> Do you still have any usages of this? I'm a bit surprised that the compiler don't complain about not being able to disambiguate calls to this vs the new lambda enabled function. > > This is still needed as there are many places that use the old style iteration. Also, when the body of the iteration is complex, it might be more readable to do it as a separate class. E.g., here in systemDictionaryShared.cpp: > > > UnregisteredClassesDuplicationChecker dup_checker; > _dumptime_table->iterate(&dup_checker); > > > I think there's no ambiguity because `iter->do_entry()` cannot be substituted with the other template, and `function(node->_key, node->_value)` in the other template cannot be substituted here. So by SFINAE the C++ compiler can pick the correct template. Interesting. I got problems when I converted BitMap to support both closures and lambdas. The problem might have been that the iterate function took an specific closure class, and didn't use a template. ------------- PR: https://git.openjdk.java.net/jdk/pull/8761 From jbhateja at openjdk.java.net Wed May 25 06:32:19 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 25 May 2022 06:32:19 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v9] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 05:50:23 GMT, Jatin Bhateja wrote: >> Hi All, >> >> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) >> >> Following is the brief summary of changes:- >> >> 1) Extends the scope of existing lanewise API for following new vector operations. >> - VectorOperations.BIT_COUNT: counts the number of one-bits >> - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits >> - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits >> - VectorOperations.REVERSE: reversing the order of bits >> - VectorOperations.REVERSE_BYTES: reversing the order of bytes >> - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. >> >> 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. >> - Vector.compress >> - Vector.expand >> - VectorMask.compress >> >> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. >> - Vector.fromMemorySegment >> - Vector.intoMemorySegment >> >> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. >> >> >> Patch has been regressed over AARCH64 and X86 targets different AVX levels. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8284960: Review comments resolved. Hi @vnkozlov , Your comments have been addressed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From sspitsyn at openjdk.java.net Wed May 25 07:31:11 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 25 May 2022 07:31:11 GMT Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context Message-ID: A part of this issue was contributed with the following changeset: commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2 Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)> Date: Mon Nov 8 14:45:04 2021 +0000 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes Reviewed-by: coleenp, sspitsyn, dholmes, rehn The following change in `src/hotspot/share/runtime/thread.cpp` added new assert: bool JavaThread::java_suspend() { - ThreadsListHandle tlh; - if (!tlh.includes(this)) { - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this)); - return false; - } + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true), + "missing ThreadsListHandle in calling context."); return this->handshake_state()->suspend(); } This new assert misses a check for target thread as being current `JavaThread`. Also, the JVMTI SuspendThread is protected with TLH: JvmtiEnv::SuspendThread(jthread thread) { JavaThread* current = JavaThread::current(); ThreadsListHandle tlh(current); <= TLS defined here!!! oop thread_oop = NULL; { JvmtiVTMSTransitionDisabler disabler(true); However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH. The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below: @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) { jvmtiError JvmtiEnv::SuspendThread(jthread thread) { JavaThread* current = JavaThread::current(); - ThreadsListHandle tlh(current); jvmtiError err; JavaThread* java_thread = NULL; oop thread_oop = NULL; { JvmtiVTMSTransitionDisabler disabler(true); + ThreadsListHandle tlh(current); err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop); if (err != JVMTI_ERROR_NONE) { This problem exist in all JVMTI Suspend functions: `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`. ------------- Commit messages: - 8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context Changes: https://git.openjdk.java.net/jdk/pull/8878/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8878&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286960 Stats: 17 lines in 2 files changed: 8 ins; 7 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8878.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8878/head:pull/8878 PR: https://git.openjdk.java.net/jdk/pull/8878 From aph at openjdk.java.net Wed May 25 07:32:09 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 25 May 2022 07:32:09 GMT Subject: RFR: 8286058: AArch64: clarify types of calls [v3] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 16:46:32 GMT, Evgeny Astigeevich wrote: >> The PR clarifies the types of calls AArch64 OpenJDK uses. It cleans up far_call, far_jump and trampoline_call. It removes trampoline_call1 because its use cases are now supported by trampoline_call. >> Tested a fastdebug build: >> - `gtest`: Passed >> - `tier1`...`tier3`: Passed > > Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Describe call types; Fix API > - Merge branch 'master' into JDK-8286058 > - Merge branch 'master' into JDK-8286058 > - Fix assert message > - 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 632: > 630: CompileTask* task = ciEnv::current()->task(); > 631: > 632: // We need to be at phase output when we check the size of emitted code. Suggestion: // We need to be in the output phase when we check the size of emitted code. src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1122: > 1120: // > 1121: // - far call: adrp reg, pc_relative_offset; add; bl reg > 1122: // This is longer and slower than a direct call. The offset has Suggestion: // This is longer than a direct call. The offset has I wouldn't be so definite as to say it's slower. Let's stay with longer. src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1125: > 1123: // the range +/-4GB. As the code cache size is limited to 4GB, > 1124: // far calls can reach anywhere in the code cache. If the sematic of > 1125: // the call is not needed, a far jump 'b reg' can be used instead. Suggestion: // far calls can reach anywhere in the code cache. If a jump is // needed rather than a call, a far jump 'b reg' can be used instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From aph at openjdk.java.net Wed May 25 07:38:46 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 25 May 2022 07:38:46 GMT Subject: RFR: 8286058: AArch64: clarify types of calls [v3] In-Reply-To: References: Message-ID: On Thu, 19 May 2022 16:46:32 GMT, Evgeny Astigeevich wrote: >> The PR clarifies the types of calls AArch64 OpenJDK uses. It cleans up far_call, far_jump and trampoline_call. It removes trampoline_call1 because its use cases are now supported by trampoline_call. >> Tested a fastdebug build: >> - `gtest`: Passed >> - `tier1`...`tier3`: Passed > > Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Describe call types; Fix API > - Merge branch 'master' into JDK-8286058 > - Merge branch 'master' into JDK-8286058 > - Fix assert message > - 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1144: > 1142: // > 1143: // A link-time optimization can be applied to a trampoline call when the generated > 1144: // code is moved to the code cache. A trampoline call is replaced with by a direct call. Suggestion: // If the destination is in range when the generated code is moved to the code cache, // 'bl trampoline' is replaced with `bl destination` and the trampoline is not used. src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1145: > 1143: // A link-time optimization can be applied to a trampoline call when the generated > 1144: // code is moved to the code cache. A trampoline call is replaced with by a direct call. > 1145: // The optimization does not remove the trampoline from the stub section. Suggestion: // The optimization does not remove the trampoline from the stub section. // This is necessary because the trampoline may well be redirected later when // code is patched, and the new destination may not be reachable by a simple BR // instruction. src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1149: > 1147: // - indirect call: move reg, address; blr reg > 1148: // This too can reach anywhere in the address space, but it cannot be > 1149: // patch while code is running, so it must be used at a safepoint. Suggestion: // patched while code is running, so it must be used at a safepoint. // This form of call is most suitable for targets at fixed addresses, whick // will never be patched. src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1171: > 1169: } > 1170: > 1171: // Emit a direct call/jump if the entry address is always in range, Suggestion: // Emit a direct call/jump if the entry address will always in be range, ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From aph at openjdk.java.net Wed May 25 07:43:52 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 25 May 2022 07:43:52 GMT Subject: RFR: 8286058: AArch64: clarify types of calls [v3] In-Reply-To: References: Message-ID: <_E2RO_9h2cwZvW_jQpW1-yD38Vw5bybixJIxRBvFAeI=.d6ae68ac-f431-4341-864b-cc2f29e30668@github.com> On Tue, 24 May 2022 16:45:20 GMT, Evgeny Astigeevich wrote: > Hi Andrew, > > The final version is here. Could you please review it? It might be a good idea to handle the code changes in another patch later. I don't think we should push minor code changes at this point before JDK 19 rampdown, and this is a doc patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From aph-open at littlepinkcloud.com Wed May 25 08:02:03 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Wed, 25 May 2022 09:02:03 +0100 Subject: Porters: are you ready for 8284161: Implementation of Virtual Threads (Preview) ? Message-ID: I've been trying to contact porters, but I can't get any reply on porters-dev. Are you aware aware that the commit for 8284161 https://github.com/openjdk/jdk/pull/8166 will require changes to your port? Will you be able to fix it in time for JDK 19? You don't have to implement virtual threads: it may only be necessary to stub some things out, but there may be other issues as well. Please check, and please shout out if you don't expect to get your port working in time for JDK 19. -- 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 Wed May 25 08:36:53 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 25 May 2022 08:36:53 GMT Subject: RFR: 8272791: java -XX:BlockZeroingLowLimit=1 crashes after 8270947 [v3] In-Reply-To: References: Message-ID: > This is an assertion failure caused by setting `BlockZeroingLowLimit` < `wordSize`. > > I believe there was some confusion when writing this code about whether `BlockZeroingLowLimit` should be in words or bytes, and it makes no sense for it to be less than a single word. If anyone ever tried to use a parameter < 8, it triggers an assertion. > > This patch does two things. Firstly, it corrects a `guarantee` which erroneously used `zero_words_block_size` rather than `wordSize`. The value of both of these is 8, so it doesn't change anything in the generated code. Secondly, it clips the `BlockZeroingLowLimit` so that it doesn't trigger the assertion. > > Perhaps it would be better to change the lower limit to 8 instead of this silent correction. There is no backward compatibility issue here, because any attempt to set `BlockZeroingLowLimit` < 8 in the past would have exited the VM with an error, so I don't believe a CSR is warranted if we do change the allowable range. > > So, which should it be? Change the lower limit of the range of the `BlockZeroingLowLimit` system flag, or allow 1 still to be used and silently fix it? Opinions welcome. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Better ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8756/files - new: https://git.openjdk.java.net/jdk/pull/8756/files/f6984247..79f5097a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8756&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8756&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8756.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8756/head:pull/8756 PR: https://git.openjdk.java.net/jdk/pull/8756 From shade at openjdk.java.net Wed May 25 08:36:54 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 25 May 2022 08:36:54 GMT Subject: RFR: 8272791: java -XX:BlockZeroingLowLimit=1 crashes after 8270947 [v3] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 08:33:20 GMT, Andrew Haley wrote: >> This is an assertion failure caused by setting `BlockZeroingLowLimit` < `wordSize`. >> >> I believe there was some confusion when writing this code about whether `BlockZeroingLowLimit` should be in words or bytes, and it makes no sense for it to be less than a single word. If anyone ever tried to use a parameter < 8, it triggers an assertion. >> >> This patch does two things. Firstly, it corrects a `guarantee` which erroneously used `zero_words_block_size` rather than `wordSize`. The value of both of these is 8, so it doesn't change anything in the generated code. Secondly, it clips the `BlockZeroingLowLimit` so that it doesn't trigger the assertion. >> >> Perhaps it would be better to change the lower limit to 8 instead of this silent correction. There is no backward compatibility issue here, because any attempt to set `BlockZeroingLowLimit` < 8 in the past would have exited the VM with an error, so I don't believe a CSR is warranted if we do change the allowable range. >> >> So, which should it be? Change the lower limit of the range of the `BlockZeroingLowLimit` system flag, or allow 1 still to be used and silently fix it? Opinions welcome. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Better Still good. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8756 From aph at openjdk.java.net Wed May 25 09:07:05 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 25 May 2022 09:07:05 GMT Subject: Integrated: 8272791: java -XX:BlockZeroingLowLimit=1 crashes after 8270947 In-Reply-To: References: Message-ID: On Tue, 17 May 2022 18:08:58 GMT, Andrew Haley wrote: > This is an assertion failure caused by setting `BlockZeroingLowLimit` < `wordSize`. > > I believe there was some confusion when writing this code about whether `BlockZeroingLowLimit` should be in words or bytes, and it makes no sense for it to be less than a single word. If anyone ever tried to use a parameter < 8, it triggers an assertion. > > This patch does two things. Firstly, it corrects a `guarantee` which erroneously used `zero_words_block_size` rather than `wordSize`. The value of both of these is 8, so it doesn't change anything in the generated code. Secondly, it clips the `BlockZeroingLowLimit` so that it doesn't trigger the assertion. > > Perhaps it would be better to change the lower limit to 8 instead of this silent correction. There is no backward compatibility issue here, because any attempt to set `BlockZeroingLowLimit` < 8 in the past would have exited the VM with an error, so I don't believe a CSR is warranted if we do change the allowable range. > > So, which should it be? Change the lower limit of the range of the `BlockZeroingLowLimit` system flag, or allow 1 still to be used and silently fix it? Opinions welcome. This pull request has now been integrated. Changeset: e17118aa Author: Andrew Haley URL: https://git.openjdk.java.net/jdk/commit/e17118aa8afb14dfca049f19fd98a1483b2b5c1b Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8272791: java -XX:BlockZeroingLowLimit=1 crashes after 8270947 Reviewed-by: shade, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/8756 From stuefe at openjdk.java.net Wed May 25 09:09:13 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 25 May 2022 09:09:13 GMT Subject: RFR: 8242181: [Linux] Show source information when printing native stack traces in hs_err files [v9] In-Reply-To: References: Message-ID: On Fri, 20 May 2022 14:54:39 GMT, Christian Hagedorn wrote: > Thanks Thomas for doing the testing! Hi Christian, I can see no problems on ppcle attributable to your test. However, I may overlook something since tests are still failing all over the place because of loom. I see test errors in TestDwarf on ppcle and x64, however. On x64: ----------System.out:(52/5198)---------- Command line: [/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/bin/java -cp /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes/runtime/ErrorHandling/TestDwarf.d:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/hotspot/jtreg/runtime/ErrorHandling:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/hotspot/jtreg:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/classes/test/lib:/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/grmpf/testdata/jtreg/jtreg_test_19/test/lib:/net/sapmnt.sapjvm_work/openjdk/tools/jtreg-6+2/lib/javatest.jar:/net/sapmnt.sapjvm_work/openjdk/tools/jtreg-6+2/lib/jtreg.jar -Xmx768m -Djava.awt.headless=true -Djava.util.prefs.userRoot=/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotsp ot_tier1_work/tmp -Djava.io.tmpdir=/priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/tmp -Dtest.getfreeport.max.tries=40 -ea -esa -Xlog:dwarf=info -XX:-CreateCoredumpOnCrash -Xcomp -XX:CICrashAt=1 --version ] [2022-05-24T18:37:00.974121691Z] Gathering output for process 44490 [2022-05-24T18:37:02.872100892Z] Waiting for completion for process 44490 [2022-05-24T18:37:02.872338192Z] Waiting for completion finished for process 44490 Output and diagnostic info for process 44490 was saved into 'pid-44490-output.log' [2022-05-24T18:37:02.889455876Z] Waiting for completion for process 44490 [2022-05-24T18:37:02.889604189Z] Waiting for completion finished for process 44490 # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/c1_Compilation.cpp:616 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/sapmnt/sapjvm_work/openjdk/nb/linuxx86_64/jdk-dev/src/hotspot/share/c1/c1_Compilation.cpp:616), pid=44490, tid=44505 # assert(CICrashAt < 0 || (uintx)_env->compile_id() != (uintx)CICrashAt) failed: just as planned # # JRE version: OpenJDK Runtime Environment (19.0) (fastdebug build 19-internal-adhoc.openjdk.jdk-dev) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 19-internal-adhoc.openjdk.jdk-dev, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x73ca34] Compilation::~Compilation()+0x84 # # CreateCoredumpOnCrash turned off, no core file dumped # # An error report file with more information is saved as: # /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/scratch/hs_err_pid44490.log [1.835s][info][dwarf] Open DWARF file: /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.debuginfo [1.842s][info][dwarf] Failed to parse the line number program header correctly. [1.842s][info][dwarf] Failed to process the line number program correctly. [1.842s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x0074176a [1.843s][info][dwarf] Failed to parse the line number program header correctly. [1.843s][info][dwarf] Failed to process the line number program correctly. [1.843s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x00a05011 [1.845s][info][dwarf] Failed to parse the line number program header correctly. [1.845s][info][dwarf] Failed to process the line number program correctly. [1.845s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x00a05b78 [1.849s][info][dwarf] Failed to parse the line number program header correctly. [1.849s][info][dwarf] Failed to process the line number program correctly. [1.849s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x018d49d3 [1.852s][info][dwarf] Failed to parse the line number program header correctly. [1.852s][info][dwarf] Failed to process the line number program correctly. [1.852s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x018de546 [1.855s][info][dwarf] Failed to parse the line number program header correctly. [1.855s][info][dwarf] Failed to process the line number program correctly. [1.855s][info][dwarf] Failed to retrieve file and line number information for /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/sapjvm_19/lib/server/libjvm.so at offset: 0x014d86e9 # # Compiler replay data is saved as: # /priv/jvmtests/output_openjdk19_dev_dbgU_linuxx86_64/jtreg_hotspot_tier1_work/JTwork/scratch/replay_pid44490.log # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # hs_err_file: hs_err_pid44490.log ----------System.err:(15/1242)---------- java.lang.RuntimeException: Could not find filename or line number in "V [libjvm.so+0x74176a] Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1aa": expected true, was false at jdk.test.lib.Asserts.fail(Asserts.java:594) at jdk.test.lib.Asserts.assertTrue(Asserts.java:486) at TestDwarf.runAndCheck(TestDwarf.java:163) at TestDwarf.test(TestDwarf.java:99) at TestDwarf.main(TestDwarf.java:90) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:1585) ------------- PR: https://git.openjdk.java.net/jdk/pull/7126 From ysuenaga at openjdk.java.net Wed May 25 09:16:43 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 25 May 2022 09:16:43 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v9] In-Reply-To: References: Message-ID: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: - Change Array::data() implementation - Avoid stringop-overflow warning in jfrTraceIdBits.inline.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/042c1c70..17cda224 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=07-08 Stats: 39 lines in 4 files changed: 18 ins; 18 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From zmiao at openjdk.java.net Wed May 25 09:17:30 2022 From: zmiao at openjdk.java.net (Zhuojun Miao) Date: Wed, 25 May 2022 09:17:30 GMT Subject: RFR: JDK-8287288: Fix some typos in C1 Message-ID: This is a trivial patch to fix some typos in C1. e.g. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/c1/c1_LIRGenerator.cpp#L1190 ------------- Commit messages: - JDK-8287288: Fix some typos in C1 Changes: https://git.openjdk.java.net/jdk/pull/8880/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8880&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287288 Stats: 14 lines in 6 files changed: 0 ins; 3 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/8880.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8880/head:pull/8880 PR: https://git.openjdk.java.net/jdk/pull/8880 From ysuenaga at openjdk.java.net Wed May 25 09:16:45 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 25 May 2022 09:16:45 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v8] In-Reply-To: References: Message-ID: <9kogffvvtXsQPgsozHqM-4XQlGBFZv8JVURdlpX0W4s=.68aa1f9e-4abd-405a-accf-e931090623ea@github.com> On Wed, 25 May 2022 01:50:57 GMT, Kim Barrett wrote: >> Yasumasa Suenaga 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 remote-tracking branch 'upstream/master' into gcc12-warnings >> - Use getter function to access "_data" >> - Revert changes for bytecodeAssembler.cpp, classFileParser.cpp, symbolTable.cpp >> - revert changes for memnode.cpp and type.cpp >> - Add assert to check the range of BasicType >> - Merge remote-tracking branch 'upstream/master' into HEAD >> - Revert change for java.c , parse_manifest.c , LinuxPackage.c >> - Calculate char offset before realloc() >> - Use return value from JLI_Snprintf >> - Avoid pragma error in before GCC 12 >> - ... and 1 more: https://git.openjdk.java.net/jdk/compare/c156bcc5...042c1c70 > > src/hotspot/share/oops/array.hpp line 102: > >> 100: // standard operations >> 101: int length() const { return _length; } >> 102: T* data() const { return reinterpret_cast(reinterpret_cast(this) + base_offset_in_bytes()); } > > Adding the const-qualifier to the `data()` function and then implicitly > casting it away (by casting through intptr_t) is wrong. Either don't > const-qualify (and leave it to some future use that needs such to address > appropriately), or have two functions. Also, the line length is excessive. > So this: > > > T* data() { > return reinterpret_cast( > reinterpret_cast(this) + base_offset_in_bytes()); > } > > and optionally add this: > > const T* data() const { > return reinterpret_cast( > reinterpret_cast(this) + base_offset_in_bytes()); > } Thanks a lot @kimbarrett ! I updated around stringop-overflow warning in jfrTraceIdBits.inline.hpp , and added two `data()` in `Array` class. They works fine on my GCC 12 on Fedora 36. Could you review again? ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From aph at openjdk.java.net Wed May 25 09:49:00 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 25 May 2022 09:49:00 GMT Subject: RFR: 8286058: AArch64: clarify types of calls [v3] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 07:35:32 GMT, Andrew Haley wrote: >> Evgeny Astigeevich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - Describe call types; Fix API >> - Merge branch 'master' into JDK-8286058 >> - Merge branch 'master' into JDK-8286058 >> - Fix assert message >> - 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 1149: > >> 1147: // - indirect call: move reg, address; blr reg >> 1148: // This too can reach anywhere in the address space, but it cannot be >> 1149: // patch while code is running, so it must be used at a safepoint. > > Suggestion: > > // patched while code is running, so it must be used at a safepoint. > // This form of call is most suitable for targets at fixed addresses, whick > // will never be patched. Suggest: // // The patching we do conforms to the "Concurrent modification and // execution of instructions" section of the Arm Architectural // Reference Manual, which only allows B, BL, BRK, HVC, ISB, NOP, SMC, // or SVC instructions to be modified while another thread is // executing them. // // To patch a trampoline call when the BL can't reach, we first modify // the 64-bit destination address in the trampoline, then modify the // BL to point to the trampoline, then flush the instruction cache to // broadcast the change to all executing threads. See // NativeCall::set_destination_mt_safe for the details. // // There is a benign race in that the other thread might observe the // modified BL before it observes the modified 64-bit destination // address. That does not matter because the target method has been // invalidated, so there will be a trap at its start. ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From tschatzl at openjdk.java.net Wed May 25 10:11:51 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 25 May 2022 10:11:51 GMT Subject: RFR: 8287215: Add method to scan bitmap backwards [v3] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that adds a method to scan bitmaps backwards? This functionality is necessary for upcoming change to remove on of the mark bitmaps [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708). > > As such this is only an addition of that functionality with no reference (apart from the gtest) from Hotspot itself. > > Testing: gtest > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Minor simplification ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8869/files - new: https://git.openjdk.java.net/jdk/pull/8869/files/03586c59..721d2eb4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8869&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8869&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8869.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8869/head:pull/8869 PR: https://git.openjdk.java.net/jdk/pull/8869 From aph at openjdk.java.net Wed May 25 11:06:03 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 25 May 2022 11:06:03 GMT Subject: RFR: JDK-8287288: Fix some typos in C1 In-Reply-To: References: Message-ID: On Wed, 25 May 2022 09:11:23 GMT, Zhuojun Miao wrote: > This is a trivial patch to fix some typos in C1. > e.g. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/c1/c1_LIRGenerator.cpp#L1190 Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8880 From rrich at openjdk.java.net Wed May 25 11:07:24 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 25 May 2022 11:07:24 GMT Subject: RFR: 8287205: generate_cont_thaw generates dead code after jump to exception handler Message-ID: This fix avoids generating unreachable instructions after the jump to the exception handler in `generate_cont_thaw()` Testing: jtreg:test/hotspot/jtreg:hotspot_loom jtreg:test/jdk:jdk_loom On linux x86_64 and aarch64. On aarch64 the test `jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java` had a timeout. The aaarch64 machine I used is very slow. This might have caused the timeout. ------------- Commit messages: - Merge branch 'master' into 8287205_remove_dead_code_from_generate_cont_thaw - Remove dead code from generate_cont_thaw Changes: https://git.openjdk.java.net/jdk/pull/8863/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8863&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287205 Stats: 16 lines in 2 files changed: 8 ins; 8 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8863.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8863/head:pull/8863 PR: https://git.openjdk.java.net/jdk/pull/8863 From shade at openjdk.java.net Wed May 25 11:07:24 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 25 May 2022 11:07:24 GMT Subject: RFR: 8287205: generate_cont_thaw generates dead code after jump to exception handler In-Reply-To: References: Message-ID: On Tue, 24 May 2022 07:33:02 GMT, Richard Reingruber wrote: > This fix avoids generating unreachable instructions after the jump to the exception handler in `generate_cont_thaw()` > > Testing: > > jtreg:test/hotspot/jtreg:hotspot_loom > jtreg:test/jdk:jdk_loom > > On linux x86_64 and aarch64. > > On aarch64 the test `jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java` had a timeout. The aaarch64 machine I used is very slow. This might have caused the timeout. I think this is still `hotspot-compiler`. I also suggest to pull from master and run `make test TEST="hotspot_loom jdk_loom"`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8863 From rrich at openjdk.java.net Wed May 25 11:07:25 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 25 May 2022 11:07:25 GMT Subject: RFR: 8287205: generate_cont_thaw generates dead code after jump to exception handler In-Reply-To: References: Message-ID: On Tue, 24 May 2022 14:15:03 GMT, Aleksey Shipilev wrote: > I think this is still `hotspot-compiler` Ok. I will revert to `hotspot-compiler` > I also suggest to pull from master and run `make test TEST="hotspot_loom jdk_loom"`. Will do. I'll await our nightly tests before marking this pr as ready for review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8863 From shade at openjdk.java.net Wed May 25 11:11:55 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 25 May 2022 11:11:55 GMT Subject: RFR: 8287205: generate_cont_thaw generates dead code after jump to exception handler In-Reply-To: References: Message-ID: On Tue, 24 May 2022 07:33:02 GMT, Richard Reingruber wrote: > This fix avoids generating unreachable instructions after the jump to the exception handler in `generate_cont_thaw()` > > Testing: > > jtreg:test/hotspot/jtreg:hotspot_loom > jtreg:test/jdk:jdk_loom > > On linux x86_64 and aarch64. > > On aarch64 the test `jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java` had a timeout. The aaarch64 machine I used is very slow. This might have caused the timeout. Looks fine to me. I missed this while refactoring x86_64 generate_cont_thaw :) ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8863 From dholmes at openjdk.java.net Wed May 25 11:50:43 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 25 May 2022 11:50:43 GMT Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context In-Reply-To: References: Message-ID: <-MO7BkySm4ODXdSellmykES0wwX9h4Ka143TajbNXHY=.6cb3e8e1-15f6-4e2a-970b-cc3ead63f560@github.com> On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote: > A part of this issue was contributed with the following changeset: > > commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2 > Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)> > Date: Mon Nov 8 14:45:04 2021 +0000 > > 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes > Reviewed-by: coleenp, sspitsyn, dholmes, rehn > > The following change in `src/hotspot/share/runtime/thread.cpp` added new assert: > > bool JavaThread::java_suspend() { > - ThreadsListHandle tlh; > - if (!tlh.includes(this)) { > - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this)); > - return false; > - } > + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true), > + "missing ThreadsListHandle in calling context."); > return this->handshake_state()->suspend(); > } > > This new assert misses a check for target thread as being current `JavaThread`. > > Also, the JVMTI SuspendThread is protected with TLH: > > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > ThreadsListHandle tlh(current); <= TLS defined here!!! > > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > > > However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH. > The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below: > > > @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) { > jvmtiError > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > - ThreadsListHandle tlh(current); > > jvmtiError err; > JavaThread* java_thread = NULL; > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > + ThreadsListHandle tlh(current); > > err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop); > if (err != JVMTI_ERROR_NONE) { > > > > This problem exist in all JVMTI Suspend functions: > `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`. These changes look good to me - as per our discussion in JBS issue. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8878 From dholmes at openjdk.java.net Wed May 25 11:55:50 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 25 May 2022 11:55:50 GMT Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context In-Reply-To: References: Message-ID: On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote: > A part of this issue was contributed with the following changeset: > > commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2 > Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)> > Date: Mon Nov 8 14:45:04 2021 +0000 > > 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes > Reviewed-by: coleenp, sspitsyn, dholmes, rehn > > The following change in `src/hotspot/share/runtime/thread.cpp` added new assert: > > bool JavaThread::java_suspend() { > - ThreadsListHandle tlh; > - if (!tlh.includes(this)) { > - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this)); > - return false; > - } > + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true), > + "missing ThreadsListHandle in calling context."); > return this->handshake_state()->suspend(); > } > > This new assert misses a check for target thread as being current `JavaThread`. > > Also, the JVMTI SuspendThread is protected with TLH: > > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > ThreadsListHandle tlh(current); <= TLS defined here!!! > > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > > > However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH. > The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below: > > > @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) { > jvmtiError > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > - ThreadsListHandle tlh(current); > > jvmtiError err; > JavaThread* java_thread = NULL; > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > + ThreadsListHandle tlh(current); > > err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop); > if (err != JVMTI_ERROR_NONE) { > > > > This problem exist in all JVMTI Suspend functions: > `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`. One query though - don't we have a self-suspension test that would have triggered the guarantee failure? If we don't then we should (obviously the resume will be a bit racy). ------------- PR: https://git.openjdk.java.net/jdk/pull/8878 From dholmes at openjdk.java.net Wed May 25 12:07:44 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 25 May 2022 12:07:44 GMT Subject: RFR: JDK-8287288: Fix some typos in C1 In-Reply-To: References: Message-ID: On Wed, 25 May 2022 09:11:23 GMT, Zhuojun Miao wrote: > This is a trivial patch to fix some typos in C1. > e.g. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/c1/c1_LIRGenerator.cpp#L1190 These cleanups all look good except for one. I think that bit diagram needs checking. Thanks. David src/hotspot/share/c1/c1_LIR.hpp line 203: > 201: // data opr-type opr-kind > 202: // +-----------+----------+-------+ > 203: // [max........|6 5 4 3|2 1 0] I don't think your change is right. The code below indicates there are 3 bits for kind. So I think the original should actually look like this: // data opr-type opr-kind // +--------------+-------+--------+--+ // [max...........|7 6 5 4| 3 2 1 | 0] ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8880 From jnordstrom at openjdk.java.net Wed May 25 12:39:34 2022 From: jnordstrom at openjdk.java.net (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=) Date: Wed, 25 May 2022 12:39:34 GMT Subject: RFR: 8286707: JFR: Don't commit JFR internal jdk.JavaMonitorWait events Message-ID: Changed the JFR chunk rotation lock object to specific internal class. This allows that specific Object.wait() event to be skipped, thus not adding JFR internal noise to recordings. # Testing - jdk_jfr ------------- Commit messages: - 8286707: JFR: Don't commit JFR internal jdk.JavaMonitorWait events - 8286707: JFR: Don't commit JFR internal jdk.JavaMonitorWait events - 8286707: JFR: Don't commit JFR internal jdk.JavaMonitorWait events - 8286707: JFR: Don't commit JFR internal jdk.JavaMonitorWait events Changes: https://git.openjdk.java.net/jdk/pull/8883/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8883&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286707 Stats: 51 lines in 3 files changed: 41 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/8883.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8883/head:pull/8883 PR: https://git.openjdk.java.net/jdk/pull/8883 From jnordstrom at openjdk.java.net Wed May 25 12:48:00 2022 From: jnordstrom at openjdk.java.net (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=) Date: Wed, 25 May 2022 12:48:00 GMT Subject: RFR: 8286707: JFR: Don't commit JFR internal jdk.JavaMonitorWait events In-Reply-To: References: Message-ID: On Wed, 25 May 2022 12:24:03 GMT, Joakim Nordstr?m wrote: > Changed the JFR chunk rotation lock object to specific internal class. This allows that specific Object.wait() event to be skipped, thus not adding JFR internal noise to recordings. > > # Testing > - jdk_jfr src/jdk.jfr/share/classes/jdk/jfr/internal/FileDeltaChangeLockObject.java line 32: > 30: * to Object.wait() on this object will not generate a JFR event. > 31: */ > 32: class FileDeltaChangeLockObject {} Or would a more general lock object be preferred? I couldn't find any more explicitly JFR related monitors in use. ------------- PR: https://git.openjdk.java.net/jdk/pull/8883 From alanb at openjdk.java.net Wed May 25 12:48:44 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 25 May 2022 12:48:44 GMT Subject: RFR: 8287205: generate_cont_thaw generates dead code after jump to exception handler In-Reply-To: References: Message-ID: On Tue, 24 May 2022 07:33:02 GMT, Richard Reingruber wrote: > On aarch64 the test `jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java` had a timeout. The aaarch64 machine I used is very slow. This might have caused the timeout. There's an issue with that test, it's tracked by JDK-8287200. Leonid has a PR open to fix it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8863 From kvn at openjdk.java.net Wed May 25 16:28:27 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 25 May 2022 16:28:27 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v9] In-Reply-To: References: Message-ID: <7J9iS711pZ787GWlBS6vmDen-X_YVULXxkR-cPRuYQs=.467502a6-5dd2-40dd-9393-9d685c24e1a1@github.com> On Wed, 25 May 2022 06:29:06 GMT, Jatin Bhateja wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8284960: Review comments resolved. > > Hi @vnkozlov , Your comments have been addressed. @jatin-bhateja something wrong with merge. `vpadd()` is removed. It was added by #8778 and still is used in `x86.ad`. ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From sspitsyn at openjdk.java.net Wed May 25 16:34:58 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 25 May 2022 16:34:58 GMT Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context In-Reply-To: References: Message-ID: On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote: > A part of this issue was contributed with the following changeset: > > commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2 > Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)> > Date: Mon Nov 8 14:45:04 2021 +0000 > > 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes > Reviewed-by: coleenp, sspitsyn, dholmes, rehn > > The following change in `src/hotspot/share/runtime/thread.cpp` added new assert: > > bool JavaThread::java_suspend() { > - ThreadsListHandle tlh; > - if (!tlh.includes(this)) { > - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this)); > - return false; > - } > + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true), > + "missing ThreadsListHandle in calling context."); > return this->handshake_state()->suspend(); > } > > This new assert misses a check for target thread as being current `JavaThread`. > > Also, the JVMTI SuspendThread is protected with TLH: > > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > ThreadsListHandle tlh(current); <= TLS defined here!!! > > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > > > However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH. > The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below: > > > @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) { > jvmtiError > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > - ThreadsListHandle tlh(current); > > jvmtiError err; > JavaThread* java_thread = NULL; > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > + ThreadsListHandle tlh(current); > > err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop); > if (err != JVMTI_ERROR_NONE) { > > > > This problem exist in all JVMTI Suspend functions: > `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`. The test `serviceability/jvmti/vthread/SelfSuspendDisablerTest` is triggering this guarantee. But it needs this update in the `SuspendThread` in order to do it. # Internal Error (/scratch/sspitsyn/loom5/open/src/hotspot/share/runtime/thread.cpp:1781), pid=31157, tid=31182 # guarantee(Thread::is_JavaThread_protected_by_TLH( this)) failed: missing ThreadsListHandle in calling context. # # JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-05-19-0744187.sspitsyn...) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-05-19-0744187.sspitsyn..., mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x1a41724] JavaThread::java_suspend()+0xa4 . . . . . --------------- S U M M A R Y ------------ Command Line: -Dtest.vm.opts=-XX:+CreateCoredumpOnCrash --enable-preview -Djava.util.concurrent.ForkJoinPool.common.parallelism=1 -XX:-VerifyContinuations -XX:+CheckUnhandledOops -Xcheck:jni -Dmain.wrapper=Virtual -Dtest.tool.vm.opts=-J-XX:+CreateCoredumpOnCrash -J--enable-preview -J-Djava.util.concurrent.ForkJoinPool.common.parallelism=1 -J-XX:-VerifyContinuations -J-XX:+CheckUnhandledOops -J-Xcheck:jni -J-Dmain.wrapper=Virtual -Dtest.compiler.opts= -Dtest.java.opts= -Dtest.jdk=/scratch/sspitsyn/loom5/build/linux-x64-debug/images/jdk -Dcompile.jdk=/scratch/sspitsyn/loom5/build/linux-x64-debug/images/jdk -Dtest.timeout.factor=1.0 -Dtest.nativepath=/scratch/sspitsyn/loom5/build/linux-x64-debug/images/test/hotspot/jtreg/native -Dtest.root=/scratch/sspitsyn/loom5/open/test/hotspot/jtreg -Dtest.name=serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.java -Dtest.file=/scratch/sspitsyn/loom5/open/test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerT est/SelfSuspendDisablerTest.java -Dtest.src=/scratch/sspitsyn/loom5/open/test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest -Dtest.src.path=/scratch/sspitsyn/loom5/open/test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest:/scratch/sspitsyn/loom5/open/test/lib -Dtest.classes=/scratch/sspitsyn/tst/loom5/JTwork/classes/serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.d -Dtest.class.path=/scratch/sspitsyn/tst/loom5/JTwork/classes/serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.d:/scratch/sspitsyn/tst/loom5/JTwork/classes/test/lib -XX:+CreateCoredumpOnCrash --enable-preview -Djava.util.concurrent.ForkJoinPool.common.parallelism=1 -XX:-VerifyContinuations -XX:+CheckUnhandledOops -Xcheck:jni -Dmain.wrapper=Virtual -Djava.library.path=/scratch/sspitsyn/loom5/build/linux-x64-debug/images/test/hotspot/jtreg/native --enable-preview -agentlib:SelfSuspendDisablerTest com.sun.javatest.regtest.agent.Ma inWrapper /scratch/sspitsyn/tst/loom5/JTwork/serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.d/main.1.jta Host: hotspot-oraclelinux-01, Intel(R) Xeon(R) Platinum 8167M CPU @ 2.00GHz, 32 cores, 235G, Oracle Linux Server release 7.8 Time: Wed May 25 16:23:30 2022 GMT elapsed time: 0.322123 seconds (0d 0h 0m 0s) --------------- T H R E A D --------------- Current thread (0x00007f3440022920): JavaThread "Thread-1" [_thread_in_vm, id=31182, stack(0x00007f348afee000,0x00007f348b0ef000)] Stack: [0x00007f348afee000,0x00007f348b0ef000], sp=0x00007f348b0ed620, free space=1021k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1a41724] JavaThread::java_suspend()+0xa4 V [libjvm.so+0x1315989] JvmtiEnvBase::suspend_thread(oop, JavaThread*, bool, int*)+0x379 V [libjvm.so+0x12fba6a] JvmtiEnv::SuspendThread(_jobject*)+0x1ba V [libjvm.so+0x12a42df] jvmti_SuspendThread+0x17f C [libSelfSuspendDisablerTest.so+0x21a8] Java_SelfSuspendDisablerTest_selfSuspend+0x38 j SelfSuspendDisablerTest.selfSuspend()V+0 j SelfSuspendDisablerTest.lambda$main$0()V+0 j SelfSuspendDisablerTest$$Lambda$1+0x0000000801001200.run()V+0 j java.lang.Thread.run()V+13 java.base at 19-internal v ~StubRoutines::call_stub 0x00007f34f6db9d47 V [libjvm.so+0xfba465] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x505 V [libjvm.so+0xfbacf4] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x4b4 V [libjvm.so+0xfbb167] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x77 V [libjvm.so+0x113d20b] thread_entry(JavaThread*, JavaThread*)+0x12b V [libjvm.so+0x1a40b7a] JavaThread::thread_main_inner()+0x21a V [libjvm.so+0x1a4e430] Thread::call_run()+0x100 V [libjvm.so+0x16fc2b4] thread_native_entry(Thread*)+0x104 David, thank you for review and help with analysis of this problem! ------------- PR: https://git.openjdk.java.net/jdk/pull/8878 From duke at openjdk.java.net Wed May 25 20:35:42 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Wed, 25 May 2022 20:35:42 GMT Subject: RFR: 8286058: AArch64: clarify types of calls [v3] In-Reply-To: <_E2RO_9h2cwZvW_jQpW1-yD38Vw5bybixJIxRBvFAeI=.d6ae68ac-f431-4341-864b-cc2f29e30668@github.com> References: <_E2RO_9h2cwZvW_jQpW1-yD38Vw5bybixJIxRBvFAeI=.d6ae68ac-f431-4341-864b-cc2f29e30668@github.com> Message-ID: On Wed, 25 May 2022 07:40:20 GMT, Andrew Haley wrote: > > Hi Andrew, > > The final version is here. Could you please review it? > > It might be a good idea to handle the code changes in another patch later. I don't think we should push minor code changes at this point before JDK 19 rampdown, and this is a doc patch. Completely agree. I'll move them into separate PRs: - Remove `trampoline_call1` - Remove the `cbuf` argument from far_call/far_jump/trampoline_call. ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From pchilanomate at openjdk.java.net Wed May 25 20:44:43 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Wed, 25 May 2022 20:44:43 GMT Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context In-Reply-To: References: Message-ID: On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote: > A part of this issue was contributed with the following changeset: > > commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2 > Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)> > Date: Mon Nov 8 14:45:04 2021 +0000 > > 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes > Reviewed-by: coleenp, sspitsyn, dholmes, rehn > > The following change in `src/hotspot/share/runtime/thread.cpp` added new assert: > > bool JavaThread::java_suspend() { > - ThreadsListHandle tlh; > - if (!tlh.includes(this)) { > - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this)); > - return false; > - } > + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true), > + "missing ThreadsListHandle in calling context."); > return this->handshake_state()->suspend(); > } > > This new assert misses a check for target thread as being current `JavaThread`. > > Also, the JVMTI SuspendThread is protected with TLH: > > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > ThreadsListHandle tlh(current); <= TLS defined here!!! > > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > > > However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH. > The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below: > > > @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) { > jvmtiError > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > - ThreadsListHandle tlh(current); > > jvmtiError err; > JavaThread* java_thread = NULL; > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > + ThreadsListHandle tlh(current); > > err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop); > if (err != JVMTI_ERROR_NONE) { > > > > This problem exist in all JVMTI Suspend functions: > `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`. LGTM. ------------- Marked as reviewed by pchilanomate (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8878 From sspitsyn at openjdk.java.net Wed May 25 21:10:40 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 25 May 2022 21:10:40 GMT Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context In-Reply-To: References: Message-ID: On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote: > A part of this issue was contributed with the following changeset: > > commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2 > Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)> > Date: Mon Nov 8 14:45:04 2021 +0000 > > 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes > Reviewed-by: coleenp, sspitsyn, dholmes, rehn > > The following change in `src/hotspot/share/runtime/thread.cpp` added new assert: > > bool JavaThread::java_suspend() { > - ThreadsListHandle tlh; > - if (!tlh.includes(this)) { > - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this)); > - return false; > - } > + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true), > + "missing ThreadsListHandle in calling context."); > return this->handshake_state()->suspend(); > } > > This new assert misses a check for target thread as being current `JavaThread`. > > Also, the JVMTI SuspendThread is protected with TLH: > > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > ThreadsListHandle tlh(current); <= TLS defined here!!! > > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > > > However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH. > The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below: > > > @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) { > jvmtiError > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > - ThreadsListHandle tlh(current); > > jvmtiError err; > JavaThread* java_thread = NULL; > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > + ThreadsListHandle tlh(current); > > err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop); > if (err != JVMTI_ERROR_NONE) { > > > > This problem exist in all JVMTI Suspend functions: > `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`. Thank you for quick review, Patricio! ------------- PR: https://git.openjdk.java.net/jdk/pull/8878 From amenkov at openjdk.java.net Wed May 25 23:13:39 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 25 May 2022 23:13:39 GMT Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context In-Reply-To: References: Message-ID: On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote: > A part of this issue was contributed with the following changeset: > > commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2 > Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)> > Date: Mon Nov 8 14:45:04 2021 +0000 > > 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes > Reviewed-by: coleenp, sspitsyn, dholmes, rehn > > The following change in `src/hotspot/share/runtime/thread.cpp` added new assert: > > bool JavaThread::java_suspend() { > - ThreadsListHandle tlh; > - if (!tlh.includes(this)) { > - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this)); > - return false; > - } > + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true), > + "missing ThreadsListHandle in calling context."); > return this->handshake_state()->suspend(); > } > > This new assert misses a check for target thread as being current `JavaThread`. > > Also, the JVMTI SuspendThread is protected with TLH: > > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > ThreadsListHandle tlh(current); <= TLS defined here!!! > > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > > > However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH. > The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below: > > > @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) { > jvmtiError > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > - ThreadsListHandle tlh(current); > > jvmtiError err; > JavaThread* java_thread = NULL; > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > + ThreadsListHandle tlh(current); > > err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop); > if (err != JVMTI_ERROR_NONE) { > > > > This problem exist in all JVMTI Suspend functions: > `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8878 From sspitsyn at openjdk.java.net Thu May 26 00:32:35 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 26 May 2022 00:32:35 GMT Subject: Integrated: 8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context In-Reply-To: References: Message-ID: On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote: > A part of this issue was contributed with the following changeset: > > commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2 > Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)> > Date: Mon Nov 8 14:45:04 2021 +0000 > > 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes > Reviewed-by: coleenp, sspitsyn, dholmes, rehn > > The following change in `src/hotspot/share/runtime/thread.cpp` added new assert: > > bool JavaThread::java_suspend() { > - ThreadsListHandle tlh; > - if (!tlh.includes(this)) { > - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this)); > - return false; > - } > + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true), > + "missing ThreadsListHandle in calling context."); > return this->handshake_state()->suspend(); > } > > This new assert misses a check for target thread as being current `JavaThread`. > > Also, the JVMTI SuspendThread is protected with TLH: > > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > ThreadsListHandle tlh(current); <= TLS defined here!!! > > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > > > However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH. > The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below: > > > @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) { > jvmtiError > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > - ThreadsListHandle tlh(current); > > jvmtiError err; > JavaThread* java_thread = NULL; > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > + ThreadsListHandle tlh(current); > > err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop); > if (err != JVMTI_ERROR_NONE) { > > > > This problem exist in all JVMTI Suspend functions: > `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`. This pull request has now been integrated. Changeset: 94811c0d Author: Serguei Spitsyn URL: https://git.openjdk.java.net/jdk/commit/94811c0dc7c20b0e7cb2649fe8da5061ce3d6246 Stats: 17 lines in 2 files changed: 8 ins; 7 del; 2 mod 8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context Reviewed-by: dholmes, pchilanomate, amenkov ------------- PR: https://git.openjdk.java.net/jdk/pull/8878 From sspitsyn at openjdk.java.net Thu May 26 00:32:35 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 26 May 2022 00:32:35 GMT Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context In-Reply-To: References: Message-ID: <_NLTWJj7sPUvNFhPYopIRG1H1UtUy6MxlNVeDanfCqo=.20b541f6-a65c-40df-b138-c9a65f7afc12@github.com> On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote: > A part of this issue was contributed with the following changeset: > > commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2 > Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)> > Date: Mon Nov 8 14:45:04 2021 +0000 > > 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes > Reviewed-by: coleenp, sspitsyn, dholmes, rehn > > The following change in `src/hotspot/share/runtime/thread.cpp` added new assert: > > bool JavaThread::java_suspend() { > - ThreadsListHandle tlh; > - if (!tlh.includes(this)) { > - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this)); > - return false; > - } > + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true), > + "missing ThreadsListHandle in calling context."); > return this->handshake_state()->suspend(); > } > > This new assert misses a check for target thread as being current `JavaThread`. > > Also, the JVMTI SuspendThread is protected with TLH: > > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > ThreadsListHandle tlh(current); <= TLS defined here!!! > > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > > > However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH. > The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below: > > > @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) { > jvmtiError > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > - ThreadsListHandle tlh(current); > > jvmtiError err; > JavaThread* java_thread = NULL; > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > + ThreadsListHandle tlh(current); > > err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop); > if (err != JVMTI_ERROR_NONE) { > > > > This problem exist in all JVMTI Suspend functions: > `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`. Thank you for review, Alex! ------------- PR: https://git.openjdk.java.net/jdk/pull/8878 From zmiao at openjdk.java.net Thu May 26 02:18:41 2022 From: zmiao at openjdk.java.net (Zhuojun Miao) Date: Thu, 26 May 2022 02:18:41 GMT Subject: RFR: JDK-8287288: Fix some typos in C1 In-Reply-To: References: Message-ID: <4aStkDt-jXraLpwGg7SrudAS_S7WDQq0Pz62dRt9MEo=.38b77871-4a77-4af0-ac09-f44df6ff475f@github.com> On Wed, 25 May 2022 12:02:37 GMT, David Holmes wrote: >> This is a trivial patch to fix some typos in C1. >> e.g. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/c1/c1_LIRGenerator.cpp#L1190 > > src/hotspot/share/c1/c1_LIR.hpp line 203: > >> 201: // data opr-type opr-kind >> 202: // +-----------+----------+-------+ >> 203: // [max........|6 5 4 3|2 1 0] > > I don't think your change is right. The code below indicates there are 3 bits for kind. So I think the original should actually look like this: > > > // data opr-type opr-kind > // +--------------+-------+--------+--+ > // [max...........|7 6 5 4| 3 2 1 | 0] According to the definitions of `Opr_kind` and `kind_mask` below, it can be seen that `opr-kind` uses the lowest 3 bits, and if the lowest bit is 0, it means that this is a pointer. ------------- PR: https://git.openjdk.java.net/jdk/pull/8880 From dholmes at openjdk.java.net Thu May 26 02:30:49 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 26 May 2022 02:30:49 GMT Subject: RFR: 8286707: JFR: Don't commit JFR internal jdk.JavaMonitorWait events In-Reply-To: References: Message-ID: On Wed, 25 May 2022 12:24:03 GMT, Joakim Nordstr?m wrote: > Changed the JFR chunk rotation lock object to specific internal class. This allows that specific Object.wait() event to be skipped, thus not adding JFR internal noise to recordings. > > # Testing > - jdk_jfr I think any filtering should be handled internally to JFR not in the ObjectMonitor code. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8883 From dholmes at openjdk.java.net Thu May 26 02:36:43 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 26 May 2022 02:36:43 GMT Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context In-Reply-To: References: Message-ID: On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote: > A part of this issue was contributed with the following changeset: > > commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2 > Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)> > Date: Mon Nov 8 14:45:04 2021 +0000 > > 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes > Reviewed-by: coleenp, sspitsyn, dholmes, rehn > > The following change in `src/hotspot/share/runtime/thread.cpp` added new assert: > > bool JavaThread::java_suspend() { > - ThreadsListHandle tlh; > - if (!tlh.includes(this)) { > - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this)); > - return false; > - } > + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true), > + "missing ThreadsListHandle in calling context."); > return this->handshake_state()->suspend(); > } > > This new assert misses a check for target thread as being current `JavaThread`. > > Also, the JVMTI SuspendThread is protected with TLH: > > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > ThreadsListHandle tlh(current); <= TLS defined here!!! > > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > > > However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH. > The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below: > > > @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) { > jvmtiError > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > - ThreadsListHandle tlh(current); > > jvmtiError err; > JavaThread* java_thread = NULL; > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > + ThreadsListHandle tlh(current); > > err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop); > if (err != JVMTI_ERROR_NONE) { > > > > This problem exist in all JVMTI Suspend functions: > `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`. I was expecting there to be an existing non-vthread-related test for self-suspension. That seems to be a hole in our test coverage. ------------- PR: https://git.openjdk.java.net/jdk/pull/8878 From dholmes at openjdk.java.net Thu May 26 02:52:37 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 26 May 2022 02:52:37 GMT Subject: RFR: JDK-8287288: Fix some typos in C1 In-Reply-To: References: Message-ID: On Wed, 25 May 2022 09:11:23 GMT, Zhuojun Miao wrote: > This is a trivial patch to fix some typos in C1. > e.g. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/c1/c1_LIRGenerator.cpp#L1190 Adding hotspot-compiler-dev to see if anyone there would like to chime in. ------------- PR: https://git.openjdk.java.net/jdk/pull/8880 From dholmes at openjdk.java.net Thu May 26 02:52:40 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 26 May 2022 02:52:40 GMT Subject: RFR: JDK-8287288: Fix some typos in C1 In-Reply-To: <4aStkDt-jXraLpwGg7SrudAS_S7WDQq0Pz62dRt9MEo=.38b77871-4a77-4af0-ac09-f44df6ff475f@github.com> References: <4aStkDt-jXraLpwGg7SrudAS_S7WDQq0Pz62dRt9MEo=.38b77871-4a77-4af0-ac09-f44df6ff475f@github.com> Message-ID: On Thu, 26 May 2022 02:15:08 GMT, Zhuojun Miao wrote: >> src/hotspot/share/c1/c1_LIR.hpp line 203: >> >>> 201: // data opr-type opr-kind >>> 202: // +-----------+----------+-------+ >>> 203: // [max........|6 5 4 3|2 1 0] >> >> I don't think your change is right. The code below indicates there are 3 bits for kind. So I think the original should actually look like this: >> >> >> // data opr-type opr-kind >> // +--------------+-------+--------+--+ >> // [max...........|7 6 5 4| 3 2 1 | 0] > > According to the definitions of `Opr_kind` and `kind_mask` below, it can be seen that `opr-kind` uses the lowest 3 bits, and if the lowest bit is 0, it means that this is a pointer. I was reading: enum OprBits { pointer_bits = 1 , kind_bits = 3 , type_bits = 4 , size_bits = 2 , destroys_bits = 1 as a bitfield description so 1 pointer bit followed by 3 kind bits, followed by 4 type bits etc. But I agree the later mask value only does a shift of 3 not 4. Also the code indicates there are a lot more non-data bits before we get to the data so the diagram is incomplete in other ways. ------------- PR: https://git.openjdk.java.net/jdk/pull/8880 From zmiao at openjdk.java.net Thu May 26 03:39:41 2022 From: zmiao at openjdk.java.net (Zhuojun Miao) Date: Thu, 26 May 2022 03:39:41 GMT Subject: RFR: JDK-8287288: Fix some typos in C1 In-Reply-To: References: <4aStkDt-jXraLpwGg7SrudAS_S7WDQq0Pz62dRt9MEo=.38b77871-4a77-4af0-ac09-f44df6ff475f@github.com> Message-ID: On Thu, 26 May 2022 02:47:54 GMT, David Holmes wrote: >> According to the definitions of `Opr_kind` and `kind_mask` below, it can be seen that `opr-kind` uses the lowest 3 bits, and if the lowest bit is 0, it means that this is a pointer. > > I was reading: > > enum OprBits { > pointer_bits = 1 > , kind_bits = 3 > , type_bits = 4 > , size_bits = 2 > , destroys_bits = 1 > > as a bitfield description so 1 pointer bit followed by 3 kind bits, followed by 4 type bits etc. But I agree the later mask value only does a shift of 3 not 4. > > Also the code indicates there are a lot more non-data bits before we get to the data so the diagram is incomplete in other ways. I don't think `pointer_bits` should be added to `non_data_bits`: , non_data_bits = pointer_bits + kind_bits + type_bits + size_bits + destroys_bits + virtual_bits + is_xmm_bits + last_use_bits + is_fpu_stack_offset_bits , data_bits = BitsPerInt - non_data_bits , reg_bits = data_bits / 2 // for two registers in one value encoding ------------- PR: https://git.openjdk.java.net/jdk/pull/8880 From kbarrett at openjdk.java.net Thu May 26 04:03:54 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 26 May 2022 04:03:54 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v9] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 09:16:43 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: > > - Change Array::data() implementation > - Avoid stringop-overflow warning in jfrTraceIdBits.inline.hpp Mostly good, but I missed a problem with an earlier part of the change. Sorry I didn't notice sooner. src/java.base/unix/native/libjli/java_md_common.c line 133: > 131: > 132: snprintf_result = JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); > 133: if ((snprintf_result < 0) && (snprintf_result >= (int)sizeof(name))) { That should be `||` rather than `&&`. src/java.base/unix/native/libjli/java_md_common.c line 135: > 133: if ((snprintf_result < 0) && (snprintf_result >= (int)sizeof(name))) { > 134: return 0; > 135: } Pre-existing: It seems odd that this returns `0` above and below, rather than returning `NULL`. I think there are one or two other places in this file that are similarly using literal `0` for a null pointer, though others are using `NULL`. Something to report and clean up separately from this change. ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8646 From jbhateja at openjdk.java.net Thu May 26 06:22:09 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 26 May 2022 06:22:09 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v8] In-Reply-To: <4u_PL8-QxIYVBgJ23LTdoPWZrTKh70K-beMYXOXZgQQ=.a650a280-dc75-46cd-8449-00c38ddd91ea@github.com> References: <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com> <4u_PL8-QxIYVBgJ23LTdoPWZrTKh70K-beMYXOXZgQQ=.a650a280-dc75-46cd-8449-00c38ddd91ea@github.com> Message-ID: On Wed, 25 May 2022 06:25:53 GMT, Jatin Bhateja wrote: >> src/hotspot/cpu/x86/assembler_x86.cpp line 8173: >> >>> 8171: >>> 8172: void Assembler::vinsertf32x4(XMMRegister dst, XMMRegister nds, XMMRegister src, uint8_t imm8) { >>> 8173: assert(VM_Version::supports_evex(), ""); >> >> Hmm, did we never trigger this wrong assert because the use was guarded by correct check? > > Yes. > @jatin-bhateja something wrong with merge. `vpadd()` is removed. It was added by #8778 and still is used in `x86.ad`. Hi @vnkozlov , after integration of PR 8778 there were there were two copies of vpadd with same signature, so removed one of them. ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From sspitsyn at openjdk.java.net Thu May 26 07:01:35 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 26 May 2022 07:01:35 GMT Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context In-Reply-To: References: Message-ID: On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote: > A part of this issue was contributed with the following changeset: > > commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2 > Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)> > Date: Mon Nov 8 14:45:04 2021 +0000 > > 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes > Reviewed-by: coleenp, sspitsyn, dholmes, rehn > > The following change in `src/hotspot/share/runtime/thread.cpp` added new assert: > > bool JavaThread::java_suspend() { > - ThreadsListHandle tlh; > - if (!tlh.includes(this)) { > - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this)); > - return false; > - } > + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true), > + "missing ThreadsListHandle in calling context."); > return this->handshake_state()->suspend(); > } > > This new assert misses a check for target thread as being current `JavaThread`. > > Also, the JVMTI SuspendThread is protected with TLH: > > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > ThreadsListHandle tlh(current); <= TLS defined here!!! > > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > > > However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH. > The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below: > > > @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) { > jvmtiError > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > - ThreadsListHandle tlh(current); > > jvmtiError err; > JavaThread* java_thread = NULL; > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > + ThreadsListHandle tlh(current); > > err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop); > if (err != JVMTI_ERROR_NONE) { > > > > This problem exist in all JVMTI Suspend functions: > `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`. This nsk.jvmti test is also failing with the guarantee for current platform thread: `test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002` # Internal Error (/scratch/sspitsyn/loom5/open/src/hotspot/share/runtime/thread.cpp:1781), pid=7458, tid=7506 # guarantee(Thread::is_JavaThread_protected_by_TLH( this)) failed: missing ThreadsListHandle in calling context. # # JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-05-19-0744187.sspitsyn...) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-05-19-0744187.sspitsyn..., mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x1a41814] JavaThread::java_suspend()+0xa4 . . . . . . . . . . . . . . . . --------------- T H R E A D --------------- Current thread (0x000014b91001d0f0): JavaThread "Thread-1" [_thread_in_vm, id=7506, stack(0x000014b92bafa000,0x000014b92bbfb000)] Stack: [0x000014b92bafa000,0x000014b92bbfb000], sp=0x000014b92bbf8ef0, free space=1019k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1a41814] JavaThread::java_suspend()+0xa4 V [libjvm.so+0x1315a79] JvmtiEnvBase::suspend_thread(oop, JavaThread*, bool, int*)+0x379 V [libjvm.so+0x12fb9ca] JvmtiEnv::SuspendThread(_jobject*)+0x1ba V [libjvm.so+0x12a42df] jvmti_SuspendThread+0x17f C [libhs202t002.so+0xc0a7] callbackMethodExit.part.0+0x107 V [libjvm.so+0x1336887] JvmtiExport::post_method_exit_inner(JavaThread*, methodHandle&, JvmtiThreadState*, bool, frame, jvalue&) [clone .part.0]+0x307 V [libjvm.so+0x133ac71] JvmtiExport::notice_unwind_due_to_exception(JavaThread*, Method*, unsigned char*, oop, bool)+0x531 V [libjvm.so+0xfad21a] InterpreterRuntime::exception_handler_for_exception(JavaThread*, oopDesc*)+0xb9a j nsk.jvmti.scenarios.hotswap.HS202.hs202t002.MyThread.display()V+19 j nsk.jvmti.scenarios.hotswap.HS202.hs202t002.MyThread.playWithThis()V+1 j nsk.jvmti.scenarios.hotswap.HS202.hs202t002.MyThread.run()V+1 v ~StubRoutines::call_stub 0x000014b98fa09d47 V [libjvm.so+0xfba465] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x505 V [libjvm.so+0xfbacf4] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x4b4 V [libjvm.so+0xfbb167] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x77 V [libjvm.so+0x113d20b] thread_entry(JavaThread*, JavaThread*)+0x12b V [libjvm.so+0x1a40c6a] JavaThread::thread_main_inner()+0x21a V [libjvm.so+0x1a4e520] Thread::call_run()+0x100 V [libjvm.so+0x16fc3a4] thread_native_entry(Thread*)+0x104 ------------- PR: https://git.openjdk.java.net/jdk/pull/8878 From duke at openjdk.java.net Thu May 26 07:37:29 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Thu, 26 May 2022 07:37:29 GMT Subject: RFR: 8286058: AArch64: clarify types of calls [v4] In-Reply-To: References: Message-ID: > The PR clarifies the types of calls AArch64 OpenJDK uses. It cleans up far_call, far_jump and trampoline_call. It removes trampoline_call1 because its use cases are now supported by trampoline_call. > Tested a fastdebug build: > - `gtest`: Passed > - `tier1`...`tier3`: Passed Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: Update comments; Remove code changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8564/files - new: https://git.openjdk.java.net/jdk/pull/8564/files/56c354f3..0f1fb9bc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8564&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8564&range=02-03 Stats: 64 lines in 5 files changed: 31 ins; 8 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/8564.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8564/head:pull/8564 PR: https://git.openjdk.java.net/jdk/pull/8564 From aph at openjdk.java.net Thu May 26 07:42:43 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 26 May 2022 07:42:43 GMT Subject: RFR: 8286058: AArch64: clarify types of calls [v4] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 07:37:29 GMT, Evgeny Astigeevich wrote: >> The PR clarifies the types of calls AArch64 OpenJDK uses. It cleans up far_call, far_jump and trampoline_call. It removes trampoline_call1 because its use cases are now supported by trampoline_call. >> Tested a fastdebug build: >> - `gtest`: Passed >> - `tier1`...`tier3`: Passed > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Update comments; Remove code changes Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From dholmes at openjdk.java.net Thu May 26 07:45:28 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 26 May 2022 07:45:28 GMT Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context In-Reply-To: References: Message-ID: On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote: > A part of this issue was contributed with the following changeset: > > commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2 > Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)> > Date: Mon Nov 8 14:45:04 2021 +0000 > > 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes > Reviewed-by: coleenp, sspitsyn, dholmes, rehn > > The following change in `src/hotspot/share/runtime/thread.cpp` added new assert: > > bool JavaThread::java_suspend() { > - ThreadsListHandle tlh; > - if (!tlh.includes(this)) { > - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this)); > - return false; > - } > + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true), > + "missing ThreadsListHandle in calling context."); > return this->handshake_state()->suspend(); > } > > This new assert misses a check for target thread as being current `JavaThread`. > > Also, the JVMTI SuspendThread is protected with TLH: > > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > ThreadsListHandle tlh(current); <= TLS defined here!!! > > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > > > However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH. > The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below: > > > @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) { > jvmtiError > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > - ThreadsListHandle tlh(current); > > jvmtiError err; > JavaThread* java_thread = NULL; > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > + ThreadsListHandle tlh(current); > > err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop); > if (err != JVMTI_ERROR_NONE) { > > > > This problem exist in all JVMTI Suspend functions: > `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`. Ah I see. Hmmm it might be argued (when Dan gets back) that the TLH was in fact intended/expected to cover the current thread - even though the current thread never needs such protection. ------------- PR: https://git.openjdk.java.net/jdk/pull/8878 From ysuenaga at openjdk.java.net Thu May 26 10:55:28 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 26 May 2022 10:55:28 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v10] In-Reply-To: References: Message-ID: <9Xq3-0C-RsJcSC5lIBQDed1XZii_KAXG7CwnuU7fb-o=.c413603e-8ccd-427f-9b33-8e168cffcfd3@github.com> > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Fix comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8646/files - new: https://git.openjdk.java.net/jdk/pull/8646/files/17cda224..851279ae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8646&range=08-09 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8646.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8646/head:pull/8646 PR: https://git.openjdk.java.net/jdk/pull/8646 From ysuenaga at openjdk.java.net Thu May 26 10:55:29 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 26 May 2022 10:55:29 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v9] In-Reply-To: References: Message-ID: <4B8Ib70PFV8uvUPrVUSiLk5560QAhHhUkJFpyyzUmRk=.c1f7b721-e51a-4e24-b8b3-a896bff7e1b4@github.com> On Thu, 26 May 2022 03:48:31 GMT, Kim Barrett wrote: >> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision: >> >> - Change Array::data() implementation >> - Avoid stringop-overflow warning in jfrTraceIdBits.inline.hpp > > src/java.base/unix/native/libjli/java_md_common.c line 133: > >> 131: >> 132: snprintf_result = JLI_Snprintf(name, sizeof(name), "%s%c%s", indir, FILE_SEPARATOR, cmd); >> 133: if ((snprintf_result < 0) && (snprintf_result >= (int)sizeof(name))) { > > That should be `||` rather than `&&`. Good catch! I fixed it in new commit. > src/java.base/unix/native/libjli/java_md_common.c line 135: > >> 133: if ((snprintf_result < 0) && (snprintf_result >= (int)sizeof(name))) { >> 134: return 0; >> 135: } > > Pre-existing: It seems odd that this returns `0` above and below, rather than returning `NULL`. I think there are one or two other places in this file that are similarly using literal `0` for a null pointer, though others are using `NULL`. Something to report and clean up separately from this change. I was wondering about that too. I use `NULL` at L134, and have filed it as [JDK-8287363](https://bugs.openjdk.java.net/browse/JDK-8287363). I will work for it after this issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kbarrett at openjdk.java.net Thu May 26 18:18:41 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 26 May 2022 18:18:41 GMT Subject: RFR: 8286562: GCC 12 reports some compiler warnings [v10] In-Reply-To: <9Xq3-0C-RsJcSC5lIBQDed1XZii_KAXG7CwnuU7fb-o=.c413603e-8ccd-427f-9b33-8e168cffcfd3@github.com> References: <9Xq3-0C-RsJcSC5lIBQDed1XZii_KAXG7CwnuU7fb-o=.c413603e-8ccd-427f-9b33-8e168cffcfd3@github.com> Message-ID: On Thu, 26 May 2022 10:55:28 GMT, Yasumasa Suenaga wrote: >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From kvn at openjdk.java.net Thu May 26 21:04:14 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 26 May 2022 21:04:14 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v10] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 06:29:23 GMT, Jatin Bhateja wrote: >> Hi All, >> >> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) >> >> Following is the brief summary of changes:- >> >> 1) Extends the scope of existing lanewise API for following new vector operations. >> - VectorOperations.BIT_COUNT: counts the number of one-bits >> - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits >> - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits >> - VectorOperations.REVERSE: reversing the order of bits >> - VectorOperations.REVERSE_BYTES: reversing the order of bytes >> - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. >> >> 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. >> - Vector.compress >> - Vector.expand >> - VectorMask.compress >> >> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. >> - Vector.fromMemorySegment >> - Vector.intoMemorySegment >> >> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. >> >> >> Patch has been regressed over AARCH64 and X86 targets different AVX levels. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - 8284960: Post merge cleanups. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - 8284960: Review comments resolved. > - 8284960: Integrating incremental patches. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - 8284960: Changes to enable jdk.incubator.vector to be treated as preview participant. Code re-organization related to Reverse/ReverseByte IR transforms. > - 8284960: Adding --enable-preview in vectorAPI benchmarks. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - 8284960: Review comments resolution. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - ... and 10 more: https://git.openjdk.java.net/jdk/compare/742644e2...0f6e1584 Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8425 From kvn at openjdk.java.net Thu May 26 21:04:15 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 26 May 2022 21:04:15 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v8] In-Reply-To: References: <-gYfiftVAdAUo-yZv2Y04HhoT7JT5lDcjDjCZ0UvSVc=.aa9d454d-3d6a-458a-997e-9a83951a8fa6@github.com> <4u_PL8-QxIYVBgJ23LTdoPWZrTKh70K-beMYXOXZgQQ=.a650a280-dc75-46cd-8449-00c38ddd91ea@github.com> Message-ID: On Thu, 26 May 2022 06:19:40 GMT, Jatin Bhateja wrote: >> Yes. > >> @jatin-bhateja something wrong with merge. `vpadd()` is removed. It was added by #8778 and still is used in `x86.ad`. > > Hi @vnkozlov , after integration of PR 8778 there were there were two copies of vpadd with same signature, so removed one of them. Okay. Got it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From dlong at openjdk.java.net Thu May 26 22:12:27 2022 From: dlong at openjdk.java.net (Dean Long) Date: Thu, 26 May 2022 22:12:27 GMT Subject: RFR: JDK-8287288: Fix some typos in C1 In-Reply-To: References: Message-ID: On Wed, 25 May 2022 09:11:23 GMT, Zhuojun Miao wrote: > This is a trivial patch to fix some typos in C1. > e.g. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/c1/c1_LIRGenerator.cpp#L1190 I don't think the non_data_bits issue should be addressed as part of this typo fix. Please file a separate bug for that. ------------- Marked as reviewed by dlong (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8880 From dlong at openjdk.java.net Thu May 26 22:12:27 2022 From: dlong at openjdk.java.net (Dean Long) Date: Thu, 26 May 2022 22:12:27 GMT Subject: RFR: JDK-8287288: Fix some typos in C1 In-Reply-To: References: <4aStkDt-jXraLpwGg7SrudAS_S7WDQq0Pz62dRt9MEo=.38b77871-4a77-4af0-ac09-f44df6ff475f@github.com> Message-ID: On Thu, 26 May 2022 03:36:11 GMT, Zhuojun Miao wrote: >> I was reading: >> >> enum OprBits { >> pointer_bits = 1 >> , kind_bits = 3 >> , type_bits = 4 >> , size_bits = 2 >> , destroys_bits = 1 >> >> as a bitfield description so 1 pointer bit followed by 3 kind bits, followed by 4 type bits etc. But I agree the later mask value only does a shift of 3 not 4. >> >> Also the code indicates there are a lot more non-data bits before we get to the data so the diagram is incomplete in other ways. > > I don't think `pointer_bits` should be added to `non_data_bits`: > > > , non_data_bits = pointer_bits + kind_bits + type_bits + size_bits + destroys_bits + virtual_bits > + is_xmm_bits + last_use_bits + is_fpu_stack_offset_bits > , data_bits = BitsPerInt - non_data_bits > , reg_bits = data_bits / 2 // for two registers in one value encoding I agree. This was changed as part of JDK-8261235. @chhagedorn, I think there must be a different issue with vreg_max in JDK-8261235. I wounder if it should be using reg_bits instead of data_bits. ------------- PR: https://git.openjdk.java.net/jdk/pull/8880 From duke at openjdk.java.net Thu May 26 22:41:33 2022 From: duke at openjdk.java.net (duke) Date: Thu, 26 May 2022 22:41:33 GMT Subject: Withdrawn: 8283726: x86 intrinsics for compare method in Integer and Long In-Reply-To: References: Message-ID: On Sun, 27 Mar 2022 06:15:34 GMT, Srinivas Vamsi Parasa wrote: > Implements x86 intrinsics for compare() method in java.lang.Integer and java.lang.Long. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7975 From dlong at openjdk.java.net Thu May 26 23:07:33 2022 From: dlong at openjdk.java.net (Dean Long) Date: Thu, 26 May 2022 23:07:33 GMT Subject: RFR: JDK-8287288: Fix some typos in C1 In-Reply-To: References: Message-ID: On Wed, 25 May 2022 09:11:23 GMT, Zhuojun Miao wrote: > This is a trivial patch to fix some typos in C1. > e.g. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/c1/c1_LIRGenerator.cpp#L1190 I filed JDK-8287396 for the non_data_bits issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/8880 From kvn at openjdk.java.net Thu May 26 23:55:31 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 26 May 2022 23:55:31 GMT Subject: RFR: 8286058: AArch64: clarify types of calls [v4] In-Reply-To: References: Message-ID: On Thu, 26 May 2022 07:37:29 GMT, Evgeny Astigeevich wrote: >> The PR clarifies the types of calls AArch64 OpenJDK uses. It cleans up far_call, far_jump and trampoline_call. It removes trampoline_call1 because its use cases are now supported by trampoline_call. >> Tested a fastdebug build: >> - `gtest`: Passed >> - `tier1`...`tier3`: Passed > > Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: > > Update comments; Remove code changes Looks good and understandable. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8564 From duke at openjdk.java.net Fri May 27 00:19:40 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Fri, 27 May 2022 00:19:40 GMT Subject: RFR: 8286058: AArch64: clarify types of calls [v3] In-Reply-To: References: <_E2RO_9h2cwZvW_jQpW1-yD38Vw5bybixJIxRBvFAeI=.d6ae68ac-f431-4341-864b-cc2f29e30668@github.com> Message-ID: On Wed, 25 May 2022 20:32:33 GMT, Evgeny Astigeevich wrote: > * Remove `trampoline_call1` https://bugs.openjdk.java.net/browse/JDK-8287393 > * Remove the `cbuf` argument from far_call/far_jump/trampoline_call. https://bugs.openjdk.java.net/browse/JDK-8287394 ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From duke at openjdk.java.net Fri May 27 00:19:42 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Fri, 27 May 2022 00:19:42 GMT Subject: RFR: 8286058: AArch64: clarify types of calls [v2] In-Reply-To: References: Message-ID: On Fri, 6 May 2022 01:20:18 GMT, Vladimir Kozlov wrote: >> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix assert message > > I will run tests too to make sure we don't hit asserts. @vnkozlov, @theRealAph Thank you for reviewing. Could you sponsor it? ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From duke at openjdk.java.net Fri May 27 00:38:40 2022 From: duke at openjdk.java.net (Evgeny Astigeevich) Date: Fri, 27 May 2022 00:38:40 GMT Subject: Integrated: 8286058: AArch64: clarify types of calls In-Reply-To: References: Message-ID: On Thu, 5 May 2022 20:36:17 GMT, Evgeny Astigeevich wrote: > The PR clarifies the types of calls AArch64 OpenJDK uses. It cleans up far_call, far_jump and trampoline_call. It removes trampoline_call1 because its use cases are now supported by trampoline_call. > Tested a fastdebug build: > - `gtest`: Passed > - `tier1`...`tier3`: Passed This pull request has now been integrated. Changeset: 140419fe Author: Evgeny Astigeevich Committer: Vladimir Kozlov URL: https://git.openjdk.java.net/jdk/commit/140419fe0e8b7ff18f8a71c98e5c7372dfa3781e Stats: 78 lines in 1 file changed: 68 ins; 3 del; 7 mod 8286058: AArch64: clarify types of calls Reviewed-by: kvn, aph ------------- PR: https://git.openjdk.java.net/jdk/pull/8564 From kbarrett at openjdk.java.net Fri May 27 02:39:28 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 27 May 2022 02:39:28 GMT Subject: RFR: 8287215: Add method to scan bitmap backwards [v3] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 10:11:51 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that adds a method to scan bitmaps backwards? This functionality is necessary for upcoming change to remove on of the mark bitmaps [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708). >> >> As such this is only an addition of that functionality with no reference (apart from the gtest) from Hotspot itself. >> >> Testing: gtest >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Minor simplification Changes requested by kbarrett (Reviewer). src/hotspot/share/utilities/bitMap.hpp line 327: > 325: static constexpr idx_t NotFound = ~(idx_t)0; > 326: // Find the index of the first bit set scanning from r_index (inclusive) to > 327: // l_index (inclusive) backwards. I don't think r_index should be inclusive. I think that's surprising (such ranges are usually half-open, and always so elsewhere in this class). (It caught me by surprise; I failed to notice that in the doc and was quite confused when reviewing the implementation until I realized what was going on.) I also think it makes these operations harder to use. Having a closed range forces the caller to deal with the unrepresentable empty range explicitly. A common use-case for such searches is to iterate over the bits; the inclusive r_index makes that more awkward for the caller. Obviously this affects everything else in this change, so I haven't looked at the code very much yet. src/hotspot/share/utilities/bitMap.hpp line 328: > 326: // Find the index of the first bit set scanning from r_index (inclusive) to > 327: // l_index (inclusive) backwards. > 328: // Returns that index or NotFound if there is no such bit in the range. I think that, for consistency, it might be good for the forward search to also return NotFound when appropriate. That's something that should be done as a followup though, I think. src/hotspot/share/utilities/bitMap.inline.hpp line 236: > 234: verify_range(l_index, r_index); > 235: assert(!aligned_left || is_aligned(l_index, BitsPerWord), "l_index not aligned"); > 236: assert(sizeof(intptr_t) == sizeof(bm_word_t), "must be for the high bit check"); This assert of size equality should be a static assert. Also, I'd prefer it was close to the place that "uses" the information. src/hotspot/share/utilities/bitMap.inline.hpp line 249: > 247: // The return value of l_index when no bit is found is BitMap::NotFound. > 248: > 249: if (l_index <= r_index) { This condition is always true if the `verify_range` precondition is met. This is an artifact of making `r_index` inclusive rather than exclusive. ------------- PR: https://git.openjdk.java.net/jdk/pull/8869 From zmiao at openjdk.java.net Fri May 27 06:13:35 2022 From: zmiao at openjdk.java.net (Zhuojun Miao) Date: Fri, 27 May 2022 06:13:35 GMT Subject: RFR: JDK-8287288: Fix some typos in C1 [v2] In-Reply-To: References: Message-ID: > This is a trivial patch to fix some typos in C1. > e.g. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/c1/c1_LIRGenerator.cpp#L1190 Zhuojun Miao 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 two additional commits since the last revision: - Complete the diagram with other non-data bits - JDK-8287288: Fix some typos in C1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8880/files - new: https://git.openjdk.java.net/jdk/pull/8880/files/dc7e9dd7..2e385bcb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8880&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8880&range=00-01 Stats: 3834 lines in 120 files changed: 3154 ins; 248 del; 432 mod Patch: https://git.openjdk.java.net/jdk/pull/8880.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8880/head:pull/8880 PR: https://git.openjdk.java.net/jdk/pull/8880 From dholmes at openjdk.java.net Fri May 27 06:59:42 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 27 May 2022 06:59:42 GMT Subject: RFR: JDK-8287288: Fix some typos in C1 [v2] In-Reply-To: References: Message-ID: <4gS045MAg0SY1UDFBb1DpCqrRSCpjEyQl25H0MPpEMs=.fd950026-0d72-4f71-9dd0-5de0a6dc199a@github.com> On Fri, 27 May 2022 06:13:35 GMT, Zhuojun Miao wrote: >> This is a trivial patch to fix some typos in C1. >> e.g. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/c1/c1_LIRGenerator.cpp#L1190 > > Zhuojun Miao 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 two additional commits since the last revision: > > - Complete the diagram with other non-data bits > - JDK-8287288: Fix some typos in C1 I'm okay with this as-is as we risk going too far for a "typo" cleanup. Thanks. @miaozhuojun please do not force-push to an active PR as it destroys the context for previous review comments. You can simply merge and push the merge changeset to the PR, it will all be flattened to a single commit when integrated. Thank you. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8880 From shade at openjdk.java.net Fri May 27 08:50:28 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 27 May 2022 08:50:28 GMT Subject: RFR: 8287071: Loom: Cleanup x86_64 gen_continuation_enter [v2] In-Reply-To: References: Message-ID: > During x86_32 porting, I ended up rewriting the copy of x86_64 gen_continuation_enter significantly to make it more streamlined. The original x86_64 gen_continuation_enter should enjoy the similar streamlining, since it would likely to be the template for many other architectures. > > There might be more things to do, I would not know until x86_32 fully works. I am pretty sure current thing is self-sufficient. > > Brief tour of changes: > - Check the incoming registers explicitly > - Pass explicit argument registers to `fill_continuation_entry` > - Use the usual `NativeCall` alignment code to produce a patchable call > - Check that static stub is emitted, fail hard otherwise > - Handle register shuffling for `exception_handler_for_return_address` the similar way we do it in `StubGenerator` > > Additional testing: > - [x] Linux x86_64 fastdebug, prospective `jdk_loom hotspot_loom` Aleksey Shipilev 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-8287071-loom-x86-64-gen-cont-enter - Revert test groups - Fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8802/files - new: https://git.openjdk.java.net/jdk/pull/8802/files/a4095aa5..a46b7b3d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8802&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8802&range=00-01 Stats: 40391 lines in 791 files changed: 9875 ins; 27972 del; 2544 mod Patch: https://git.openjdk.java.net/jdk/pull/8802.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8802/head:pull/8802 PR: https://git.openjdk.java.net/jdk/pull/8802 From zmiao at openjdk.java.net Fri May 27 08:52:41 2022 From: zmiao at openjdk.java.net (Zhuojun Miao) Date: Fri, 27 May 2022 08:52:41 GMT Subject: RFR: JDK-8287288: Fix some typos in C1 [v2] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 11:02:59 GMT, Andrew Haley wrote: >> Zhuojun Miao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: >> >> - Complete the diagram with other non-data bits >> - JDK-8287288: Fix some typos in C1 > > Marked as reviewed by aph (Reviewer). Thanks @theRealAph @dholmes-ora and @dean-long for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/8880 From mdoerr at openjdk.java.net Fri May 27 11:18:07 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 27 May 2022 11:18:07 GMT Subject: RFR: 8287433: [PPC64] g1_write_barrier_pre needs extension for Loom Message-ID: Loom uses `c2i_entry_barrier` which needs to preserve more registers than currently implemented `g1_write_barrier_pre`. See JBS for details. ------------- Commit messages: - 8287433: [PPC64] g1_write_barrier_pre needs extension for Loom Changes: https://git.openjdk.java.net/jdk/pull/8918/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8918&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287433 Stats: 21 lines in 1 file changed: 16 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8918.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8918/head:pull/8918 PR: https://git.openjdk.java.net/jdk/pull/8918 From duke at openjdk.java.net Fri May 27 12:20:43 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Fri, 27 May 2022 12:20:43 GMT Subject: RFR: 8284849: Add deoptimization to unified logging [v2] In-Reply-To: References: Message-ID: > This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important). > > An example output looks like this: > > > [1.346s][info][deoptimization] Deoptimization start { > [1.346s][info][deoptimization] compileId = 407 > [1.346s][info][deoptimization] compiler = c2 > [1.346s][info][deoptimization] method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26 > [1.346s][info][deoptimization] instruction = ifne > [1.346s][info][deoptimization] reason = unstable_if > [1.346s][info][deoptimization] action = reinterpret > [1.346s][info][deoptimization] } Deoptimization end Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: Change log to single line ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8812/files - new: https://git.openjdk.java.net/jdk/pull/8812/files/d1b5c5f7..af6ab81e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8812&range=00-01 Stats: 25 lines in 1 file changed: 7 ins; 5 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/8812.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8812/head:pull/8812 PR: https://git.openjdk.java.net/jdk/pull/8812 From duke at openjdk.java.net Fri May 27 12:20:44 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Fri, 27 May 2022 12:20:44 GMT Subject: RFR: 8284849: Add deoptimization to unified logging In-Reply-To: References: Message-ID: On Fri, 20 May 2022 14:12:30 GMT, Johan Sj?l?n wrote: > This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important). > > An example output looks like this: > > > [1.346s][info][deoptimization] Deoptimization start { > [1.346s][info][deoptimization] compileId = 407 > [1.346s][info][deoptimization] compiler = c2 > [1.346s][info][deoptimization] method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26 > [1.346s][info][deoptimization] instruction = ifne > [1.346s][info][deoptimization] reason = unstable_if > [1.346s][info][deoptimization] action = reinterpret > [1.346s][info][deoptimization] } Deoptimization end I changed the log to one line and moved out all repeatedly used values into variables. I limited all of these to a scope to not pollute the function scope unnecessarily. I use `comp_level` directly instead of translating into a string (didn't find a function for it), are levels as ints sufficient? ------------- PR: https://git.openjdk.java.net/jdk/pull/8812 From sspitsyn at openjdk.java.net Fri May 27 12:25:53 2022 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 27 May 2022 12:25:53 GMT Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context In-Reply-To: References: Message-ID: On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote: > A part of this issue was contributed with the following changeset: > > commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2 > Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)> > Date: Mon Nov 8 14:45:04 2021 +0000 > > 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes > Reviewed-by: coleenp, sspitsyn, dholmes, rehn > > The following change in `src/hotspot/share/runtime/thread.cpp` added new assert: > > bool JavaThread::java_suspend() { > - ThreadsListHandle tlh; > - if (!tlh.includes(this)) { > - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this)); > - return false; > - } > + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true), > + "missing ThreadsListHandle in calling context."); > return this->handshake_state()->suspend(); > } > > This new assert misses a check for target thread as being current `JavaThread`. > > Also, the JVMTI SuspendThread is protected with TLH: > > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > ThreadsListHandle tlh(current); <= TLS defined here!!! > > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > > > However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH. > The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below: > > > @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) { > jvmtiError > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > - ThreadsListHandle tlh(current); > > jvmtiError err; > JavaThread* java_thread = NULL; > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > + ThreadsListHandle tlh(current); > > err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop); > if (err != JVMTI_ERROR_NONE) { > > > > This problem exist in all JVMTI Suspend functions: > `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`. Requiring protection of current thread with TLH makes it ugly for cases of self suspend as a nested extra TLH is required to protect current thread. The issue with self suspends is that having a jvmtiVTMSTransitionDisabler in its context is not allowed as it would cause deadlocks. Not requiring TLH for protection of current thread makes TLH congruent with jvmtiVTMSTransitionDisabler. ------------- PR: https://git.openjdk.java.net/jdk/pull/8878 From zgu at openjdk.java.net Fri May 27 23:21:57 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 27 May 2022 23:21:57 GMT Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support Message-ID: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com> Please review the patch that fixes Loom support in Shenandoah GC. - stackChunkOop is a special oop that contains stack metadata, we need to utilize nmethod entry barrier to mark, evacuate and update stack metadata. - During evacuation and reference updating phase, we can not guarantee all metadata in stackChunkOop is deeply good, so I force it to take slow path for the correctness, will try to optimize it later in separate CR. - Shenandoah uses similar way to arm and disarm nmethod as the new mechanism introduced in JDK-8284161. We may want to migrate to it in followup CR. Test: - [x] tier1 with ShenandoahGC (Linux x86_64 and Windows x64) - [x] tier2 with Shenandoah GC (Linux x86_64 and Windows x64) - [x] hotspot_gc_shenandoah on Linux x86_32 - [x] tier1 with ShenandoahGC + Loom (Linux x86_64 and Windows x64) - [x] tier2 with ShenandoahGC + Loom (Linux x86_64 and Windows x64) ------------- Commit messages: - Fix comment - Fix comment - Cleanup - Fix - Simplify - Fix requires_barriers - fix - Fix stw mark - cleanup and update copyright years - cleanup - ... and 14 more: https://git.openjdk.java.net/jdk/compare/6cc4bb11...7db9c0b8 Changes: https://git.openjdk.java.net/jdk/pull/8924/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8924&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286829 Stats: 110 lines in 14 files changed: 75 ins; 7 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/8924.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8924/head:pull/8924 PR: https://git.openjdk.java.net/jdk/pull/8924 From ysuenaga at openjdk.java.net Sat May 28 02:12:43 2022 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Sat, 28 May 2022 02:12:43 GMT Subject: Integrated: 8286562: GCC 12 reports some compiler warnings In-Reply-To: References: Message-ID: On Wed, 11 May 2022 05:58:31 GMT, Yasumasa Suenaga wrote: > I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. > As you can see, the warnings spreads several areas. Let me know if I should separate them by area. > > * -Wstringop-overflow > * src/hotspot/share/oops/array.hpp > * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp > > In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', > inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, > inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, > inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: This pull request has now been integrated. Changeset: 410a25d5 Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/410a25d59a11b6a627bbb0a2c405c2c2be19f464 Stats: 41 lines in 5 files changed: 26 ins; 1 del; 14 mod 8286562: GCC 12 reports some compiler warnings Reviewed-by: ihse, kbarrett, prr ------------- PR: https://git.openjdk.java.net/jdk/pull/8646 From david.holmes at oracle.com Sat May 28 05:44:41 2022 From: david.holmes at oracle.com (David Holmes) Date: Sat, 28 May 2022 15:44:41 +1000 Subject: Integrated: 8286562: GCC 12 reports some compiler warnings In-Reply-To: References: Message-ID: The new assertion in src/hotspot/share/utilities/globalDefinitions.hpp inline const char* type2name(BasicType t) { assert((uint)t < T_CONFLICT + 1, "invalid type"); return type2name_tab[t]; } is failing with test compiler/jvmci/errors/TestInvalidDebugInfo.java I have filed: https://bugs.openjdk.java.net/browse/JDK-8287491 The test will probably need ProblemListing as it is causing major noise in our CI. David On 28/05/2022 12:12 pm, Yasumasa Suenaga wrote: > On Wed, 11 May 2022 05:58:31 GMT, Yasumasa Suenaga wrote: > >> I saw some compiler warnings when I tried to build OpenJDK with GCC 12.0.1 on Fedora 36. >> As you can see, the warnings spreads several areas. Let me know if I should separate them by area. >> >> * -Wstringop-overflow >> * src/hotspot/share/oops/array.hpp >> * src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp >> >> In member function 'void Array::at_put(int, const T&) [with T = unsigned char]', >> inlined from 'void ConstantPool::tag_at_put(int, jbyte)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:126:64, >> inlined from 'void ConstantPool::method_at_put(int, int, int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/oops/constantPool.hpp:380:15, >> inlined from 'ConstantPool* BytecodeConstantPool::create_constant_pool(JavaThread*) const' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/classfile/bytecodeAssembler.cpp:85:26: > > This pull request has now been integrated. > > Changeset: 410a25d5 > Author: Yasumasa Suenaga > URL: https://git.openjdk.java.net/jdk/commit/410a25d59a11b6a627bbb0a2c405c2c2be19f464 > Stats: 41 lines in 5 files changed: 26 ins; 1 del; 14 mod > > 8286562: GCC 12 reports some compiler warnings > > Reviewed-by: ihse, kbarrett, prr > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/8646 From dholmes at openjdk.java.net Sat May 28 06:16:02 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 28 May 2022 06:16:02 GMT Subject: Integrated: 8287492: ProblemList compiler/jvmci/errors/TestInvalidDebugInfo.java Message-ID: Please review so we can cleanup the noise in our CI. Thanks. ------------- Commit messages: - 8287492: ProblemList compiler/jvmci/errors/TestInvalidDebugInfo.java Changes: https://git.openjdk.java.net/jdk/pull/8932/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8932&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287492 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8932.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8932/head:pull/8932 PR: https://git.openjdk.java.net/jdk/pull/8932 From mikael at openjdk.java.net Sat May 28 06:16:02 2022 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Sat, 28 May 2022 06:16:02 GMT Subject: Integrated: 8287492: ProblemList compiler/jvmci/errors/TestInvalidDebugInfo.java In-Reply-To: References: Message-ID: On Sat, 28 May 2022 06:03:36 GMT, David Holmes wrote: > Please review so we can cleanup the noise in our CI. > > Thanks. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8932 From kvn at openjdk.java.net Sat May 28 06:16:03 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Sat, 28 May 2022 06:16:03 GMT Subject: Integrated: 8287492: ProblemList compiler/jvmci/errors/TestInvalidDebugInfo.java In-Reply-To: References: Message-ID: On Sat, 28 May 2022 06:03:36 GMT, David Holmes wrote: > Please review so we can cleanup the noise in our CI. > > Thanks. Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8932 From dholmes at openjdk.java.net Sat May 28 06:16:04 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 28 May 2022 06:16:04 GMT Subject: Integrated: 8287492: ProblemList compiler/jvmci/errors/TestInvalidDebugInfo.java In-Reply-To: References: Message-ID: On Sat, 28 May 2022 06:03:36 GMT, David Holmes wrote: > Please review so we can cleanup the noise in our CI. > > Thanks. This pull request has now been integrated. Changeset: 2c461acf Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/2c461acfebd28fe5ef62805cbb004f91a3b18f08 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8287492: ProblemList compiler/jvmci/errors/TestInvalidDebugInfo.java Reviewed-by: mikael, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/8932 From shade at openjdk.java.net Mon May 30 07:13:44 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 30 May 2022 07:13:44 GMT Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support In-Reply-To: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com> References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com> Message-ID: On Fri, 27 May 2022 14:52:19 GMT, Zhengyu Gu wrote: > Please review the patch that fixes Loom support in Shenandoah GC. > > - stackChunkOop is a special oop that contains stack metadata, we need to utilize nmethod entry barrier to mark, evacuate and update stack metadata. > - During evacuation and reference updating phase, we can not guarantee all metadata in stackChunkOop is deeply good, so I force it to take slow path for the correctness, will try to optimize it later in separate CR. > - Shenandoah uses similar way to arm and disarm nmethod as the new mechanism introduced in JDK-8284161. We may want to migrate to it in followup CR. > > Test: > - [x] tier1 with ShenandoahGC (Linux x86_64 and Windows x64) > - [x] tier2 with Shenandoah GC (Linux x86_64 and Windows x64) > - [x] hotspot_gc_shenandoah on Linux x86_32 > - [x] tier1 with ShenandoahGC + Loom (Linux x86_64 and Windows x64) > - [x] tier2 with ShenandoahGC + Loom (Linux x86_64 and Windows x64) src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 529: > 527: heap->set_concurrent_mark_in_progress(true); > 528: > 529: _mark.start_mark(); Style: call `start_mark()` here maybe? Matches the use of `end_mark()` elsewhere. src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp line 73: > 71: if (obj->is_instance()) { > 72: // Case 1: Normal oop, process as usual. > 73: if (ContinuationGCSupport::relativize_stack_chunk(obj)) { Ooof, this is very hot code path. Is there any way to do this without injecting the code here? ------------- PR: https://git.openjdk.java.net/jdk/pull/8924 From chagedorn at openjdk.java.net Mon May 30 07:53:43 2022 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 30 May 2022 07:53:43 GMT Subject: RFR: JDK-8287288: Fix some typos in C1 [v2] In-Reply-To: References: Message-ID: On Fri, 27 May 2022 06:13:35 GMT, Zhuojun Miao wrote: >> This is a trivial patch to fix some typos in C1. >> e.g. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/c1/c1_LIRGenerator.cpp#L1190 > > Zhuojun Miao 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 two additional commits since the last revision: > > - Complete the diagram with other non-data bits > - JDK-8287288: Fix some typos in C1 Marked as reviewed by chagedorn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8880 From zmiao at openjdk.java.net Mon May 30 07:56:44 2022 From: zmiao at openjdk.java.net (Zhuojun Miao) Date: Mon, 30 May 2022 07:56:44 GMT Subject: Integrated: JDK-8287288: Fix some typos in C1 In-Reply-To: References: Message-ID: On Wed, 25 May 2022 09:11:23 GMT, Zhuojun Miao wrote: > This is a trivial patch to fix some typos in C1. > e.g. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/c1/c1_LIRGenerator.cpp#L1190 This pull request has now been integrated. Changeset: 1b9987cb Author: Zhuojun Miao Committer: Christian Hagedorn URL: https://git.openjdk.java.net/jdk/commit/1b9987cb08611a98e6351876aa7da4e56d4a5d2e Stats: 16 lines in 6 files changed: 0 ins; 3 del; 13 mod 8287288: Fix some typos in C1 Reviewed-by: aph, dholmes, dlong, chagedorn ------------- PR: https://git.openjdk.java.net/jdk/pull/8880 From rrich at openjdk.java.net Mon May 30 08:05:46 2022 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 30 May 2022 08:05:46 GMT Subject: RFR: 8287433: [PPC64] g1_write_barrier_pre needs extension for Loom In-Reply-To: References: Message-ID: <3gqMEKUVjPEZlqFkCenzy64F-pry1HJQIqX4PxF_tZQ=.aa1658dd-84b8-4106-93eb-1d3b94daa69f@github.com> On Fri, 27 May 2022 11:10:28 GMT, Martin Doerr wrote: > Loom uses `c2i_entry_barrier` which needs to preserve more registers than currently implemented in `g1_write_barrier_pre`. See JBS for details. Hi Martin, this looks good, thanks! I've applied the change on the [ppc loom port (WIP)](https://github.com/reinrich/loom/tree/ppc_port_with_8287433). My [BasicExp](https://github.com/reinrich/loom/blob/a3eb91a6198d8f05e61663723051f0611df55f1c/test/jdk/jdk/internal/vm/Continuation/BasicExp.java) tests work now with g1. Cheers, Richard. ------------- Marked as reviewed by rrich (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8918 From ngasson at openjdk.java.net Mon May 30 08:15:01 2022 From: ngasson at openjdk.java.net (Nick Gasson) Date: Mon, 30 May 2022 08:15:01 GMT Subject: Integrated: 8286711: AArch64: serviceability agent tests fail with PAC enabled In-Reply-To: References: Message-ID: <-eeVQRlZT7jphXBlNqJPz5BY04hnfa5aefYveelwIIU=.c9c0faf5-78ee-4372-9288-e850a6b6483a@github.com> On Fri, 20 May 2022 15:52:04 GMT, Nick Gasson wrote: > When the VM is run with `-XX:UseBranchProtection=pac-ret` on a supported CPU, the upper bits of the saved link register contain a "pointer authentication code" which must be checked and removed by a special instruction before a function returns. The serviceability agent is unaware of this and so sees garbled PC values when walking the stack. This patch just masks out the PAC bits from the sender PC after reading it from the stack frame. This pull request has now been integrated. Changeset: d8331737 Author: Nick Gasson URL: https://git.openjdk.java.net/jdk/commit/d8331737ad09fb989c492bdfe3868a7ae66e32af Stats: 43 lines in 5 files changed: 35 ins; 2 del; 6 mod 8286711: AArch64: serviceability agent tests fail with PAC enabled Reviewed-by: dholmes, cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/8814 From stuefe at openjdk.java.net Mon May 30 08:43:27 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 30 May 2022 08:43:27 GMT Subject: RFR: 8287433: [PPC64] g1_write_barrier_pre needs extension for Loom In-Reply-To: References: Message-ID: On Fri, 27 May 2022 11:10:28 GMT, Martin Doerr wrote: > Loom uses `c2i_entry_barrier` which needs to preserve more registers than currently implemented in `g1_write_barrier_pre`. See JBS for details. Looks good to my non-ppcish eyes. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8918 From mdoerr at openjdk.java.net Mon May 30 09:02:47 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 30 May 2022 09:02:47 GMT Subject: RFR: 8287433: [PPC64] g1_write_barrier_pre needs extension for Loom In-Reply-To: References: Message-ID: On Fri, 27 May 2022 11:10:28 GMT, Martin Doerr wrote: > Loom uses `c2i_entry_barrier` which needs to preserve more registers than currently implemented in `g1_write_barrier_pre`. See JBS for details. Thank you for testing and for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/8918 From mdoerr at openjdk.java.net Mon May 30 09:02:48 2022 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 30 May 2022 09:02:48 GMT Subject: Integrated: 8287433: [PPC64] g1_write_barrier_pre needs extension for Loom In-Reply-To: References: Message-ID: On Fri, 27 May 2022 11:10:28 GMT, Martin Doerr wrote: > Loom uses `c2i_entry_barrier` which needs to preserve more registers than currently implemented in `g1_write_barrier_pre`. See JBS for details. This pull request has now been integrated. Changeset: eb8d067b Author: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/eb8d067b56287a201ca102299e6b756417e5cf1b Stats: 21 lines in 1 file changed: 16 ins; 0 del; 5 mod 8287433: [PPC64] g1_write_barrier_pre needs extension for Loom Reviewed-by: rrich, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/8918 From tschatzl at openjdk.java.net Mon May 30 09:14:25 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 30 May 2022 09:14:25 GMT Subject: RFR: 8287215: Add method to scan bitmap backwards [v3] In-Reply-To: References: Message-ID: On Fri, 27 May 2022 02:32:47 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor simplification > > src/hotspot/share/utilities/bitMap.hpp line 327: > >> 325: static constexpr idx_t NotFound = ~(idx_t)0; >> 326: // Find the index of the first bit set scanning from r_index (inclusive) to >> 327: // l_index (inclusive) backwards. > > I don't think r_index should be inclusive. I think that's surprising (such > ranges are usually half-open, and always so elsewhere in this class). (It > caught me by surprise; I failed to notice that in the doc and was quite > confused when reviewing the implementation until I realized what was going > on.) I also think it makes these operations harder to use. Having a closed > range forces the caller to deal with the unrepresentable empty range > explicitly. A common use-case for such searches is to iterate over the bits; > the inclusive r_index makes that more awkward for the caller. Obviously this > affects everything else in this change, so I haven't looked at the code very > much yet. I see your point, and I'm not against that change. In ZGC code the equivalent method also seems `r_index`-inclusive. @stefank , any opinions? > src/hotspot/share/utilities/bitMap.hpp line 328: > >> 326: // Find the index of the first bit set scanning from r_index (inclusive) to >> 327: // l_index (inclusive) backwards. >> 328: // Returns that index or NotFound if there is no such bit in the range. > > I think that, for consistency, it might be good for the forward search to also > return NotFound when appropriate. That's something that should be done as a > followup though, I think. I agree that this should not be done here - this will cause quite a few additional changes I think. ------------- PR: https://git.openjdk.java.net/jdk/pull/8869 From tschatzl at openjdk.java.net Mon May 30 09:19:25 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 30 May 2022 09:19:25 GMT Subject: RFR: 8287215: Add method to scan bitmap backwards [v4] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that adds a method to scan bitmaps backwards? This functionality is necessary for upcoming change to remove on of the mark bitmaps [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708). > > As such this is only an addition of that functionality with no reference (apart from the gtest) from Hotspot itself. > > Testing: gtest > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Make r_index exclusive ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8869/files - new: https://git.openjdk.java.net/jdk/pull/8869/files/721d2eb4..6382a48a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8869&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8869&range=02-03 Stats: 13 lines in 3 files changed: 5 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8869.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8869/head:pull/8869 PR: https://git.openjdk.java.net/jdk/pull/8869 From tschatzl at openjdk.java.net Mon May 30 09:30:22 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 30 May 2022 09:30:22 GMT Subject: RFR: 8287215: Add method to scan bitmap backwards [v4] In-Reply-To: References: Message-ID: On Mon, 30 May 2022 09:19:25 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that adds a method to scan bitmaps backwards? This functionality is necessary for upcoming change to remove on of the mark bitmaps [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708). >> >> As such this is only an addition of that functionality with no reference (apart from the gtest) from Hotspot itself. >> >> Testing: gtest >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Make r_index exclusive The last commit makes `r_index` exclusive; it can be reverted easily. ------------- PR: https://git.openjdk.java.net/jdk/pull/8869 From rpressler at openjdk.java.net Mon May 30 11:31:10 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Mon, 30 May 2022 11:31:10 GMT Subject: RFR: 8287233: Crash in Continuation.enterSpecial: stop: tried to execute native method as non-native Message-ID: Please review this fix to a continuation-related crash that happens due to a race between the linking and generation of Continuation.enterSpecial. Passes Loom tiers 1-5. ------------- Commit messages: - Revert "Move ContinuationEntry::set_enter_nmethod to set_code to be called under a lock" - Properly initialized Continuation.enterSpecial entry points - Move ContinuationEntry::set_enter_nmethod to set_code to be called under a lock Changes: https://git.openjdk.java.net/jdk/pull/8926/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8926&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287233 Stats: 24 lines in 2 files changed: 14 ins; 3 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8926.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8926/head:pull/8926 PR: https://git.openjdk.java.net/jdk/pull/8926 From kbarrett at openjdk.java.net Mon May 30 12:23:47 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 30 May 2022 12:23:47 GMT Subject: RFR: 8287215: Add method to scan bitmap backwards [v4] In-Reply-To: References: Message-ID: On Mon, 30 May 2022 09:19:25 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that adds a method to scan bitmaps backwards? This functionality is necessary for upcoming change to remove on of the mark bitmaps [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708). >> >> As such this is only an addition of that functionality with no reference (apart from the gtest) from Hotspot itself. >> >> Testing: gtest >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Make r_index exclusive Changes requested by kbarrett (Reviewer). src/hotspot/share/utilities/bitMap.inline.hpp line 233: > 231: template > 232: inline BitMap::idx_t BitMap::get_prev_bit_impl(idx_t l_index, idx_t r_index) const { > 233: STATIC_ASSERT(flip == find_ones_flip || flip == find_zeros_flip); We have `static_assert` now, which requires a message but gives easier to understand errors. src/hotspot/share/utilities/bitMap.inline.hpp line 246: > 244: // an operation when returning results. > 245: > 246: // The return value of l_index when no bit is found is BitMap::NotFound. The mention of `l_index` here seems wrong - maybe an incomplete edit? src/hotspot/share/utilities/bitMap.inline.hpp line 254: > 252: bm_word_t cword = (map(index) ^ flip) << (BitsPerWord - 1 - bit_in_word(r_index)); > 253: > 254: STATIC_ASSERT(sizeof(intptr_t) == sizeof(bm_word_t)); Another place that should be `static_assert`. src/hotspot/share/utilities/bitMap.inline.hpp line 270: > 268: return result; > 269: } > 270: // Result is beyond range bound. Maybe add "return NotFound" for consistency with later comment? src/hotspot/share/utilities/bitMap.inline.hpp line 274: > 272: // Flipped and shifted first word is zero. Word search through > 273: // aligned down l_index for a non-zero flipped word. > 274: idx_t limit = to_words_align_down(l_index); // Minuscule savings when aligned. The comment about a "minuscule savings" is copied from the forward search, but is only relevant there, not here. It's about using `aligned_right` (in the forward search case) to decide whether we can use the cheaper `to_words_align_down` or need to use the (slightly) more expensive `to_words_align_up`. There's nothing like that here, as can be seen by there being no conditional on alignment src/hotspot/share/utilities/bitMap.inline.hpp line 278: > 276: cword = map(index) ^ flip; > 277: if (cword != 0) { > 278: idx_t result = bit_index(index + 1) - count_leading_zeros(cword) - 1; I think this calculation would be clearer as bit_index(index) + (BitsPerWord - 1) - count_leading_zeros(cword) getting the position of the last bit in the current word directly and counting backward from there. It's ultimately the same calculation, but I found the suggested alternative more obvious and easier to reason about. For example, can `bit_index(index + 1)` overflow? It can't, but I had to think about it. ------------- PR: https://git.openjdk.java.net/jdk/pull/8869 From shade at openjdk.java.net Mon May 30 12:31:25 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 30 May 2022 12:31:25 GMT Subject: RFR: 8287071: Loom: Cleanup x86_64 gen_continuation_enter [v3] In-Reply-To: References: Message-ID: <5Mtw3xX2QbDuQId2hd5xxNRNLau0a8Qs0Q3Kbw4FL-Y=.fb2807ef-8a83-4836-b189-f8584b862cee@github.com> > During x86_32 porting, I ended up rewriting the copy of x86_64 gen_continuation_enter significantly to make it more streamlined. The original x86_64 gen_continuation_enter should enjoy the similar streamlining, since it would likely to be the template for many other architectures. > > There might be more things to do, I would not know until x86_32 fully works. I am pretty sure current thing is self-sufficient. > > Brief tour of changes: > - Check the incoming registers explicitly > - Pass explicit argument registers to `fill_continuation_entry` > - Use the usual `NativeCall` alignment code to produce a patchable call > - Check that static stub is emitted, fail hard otherwise > - Handle register shuffling for `exception_handler_for_return_address` the similar way we do it in `StubGenerator` > > Additional testing: > - [x] Linux x86_64 fastdebug, prospective `jdk_loom hotspot_loom` Aleksey Shipilev 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: - Harmonize exception handler invocation - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter - Revert test groups - Fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8802/files - new: https://git.openjdk.java.net/jdk/pull/8802/files/a46b7b3d..a485bafd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8802&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8802&range=01-02 Stats: 2932 lines in 90 files changed: 1655 ins; 639 del; 638 mod Patch: https://git.openjdk.java.net/jdk/pull/8802.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8802/head:pull/8802 PR: https://git.openjdk.java.net/jdk/pull/8802 From tschatzl at openjdk.java.net Mon May 30 13:31:30 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 30 May 2022 13:31:30 GMT Subject: RFR: 8287215: Add method to scan bitmap backwards [v4] In-Reply-To: References: Message-ID: On Mon, 30 May 2022 11:36:38 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> Make r_index exclusive > > src/hotspot/share/utilities/bitMap.inline.hpp line 233: > >> 231: template >> 232: inline BitMap::idx_t BitMap::get_prev_bit_impl(idx_t l_index, idx_t r_index) const { >> 233: STATIC_ASSERT(flip == find_ones_flip || flip == find_zeros_flip); > > We have `static_assert` now, which requires a message but gives easier to understand errors. Fixed, but I'm not sure it is better now. > src/hotspot/share/utilities/bitMap.inline.hpp line 270: > >> 268: return result; >> 269: } >> 270: // Result is beyond range bound. > > Maybe add "return NotFound" for consistency with later comment? I added a comment that this intentionally falls through to the outer `return NotFound`. > src/hotspot/share/utilities/bitMap.inline.hpp line 278: > >> 276: cword = map(index) ^ flip; >> 277: if (cword != 0) { >> 278: idx_t result = bit_index(index + 1) - count_leading_zeros(cword) - 1; > > I think this calculation would be clearer as > > bit_index(index) + (BitsPerWord - 1) - count_leading_zeros(cword) > > getting the position of the last bit in the current word directly and counting backward from there. > > It's ultimately the same calculation, but I found the suggested alternative more obvious and easier to reason about. For example, can `bit_index(index + 1)` overflow? It can't, but I had to think about it. Either is fine. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8869 From tschatzl at openjdk.java.net Mon May 30 13:31:29 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 30 May 2022 13:31:29 GMT Subject: RFR: 8287215: Add method to scan bitmap backwards [v5] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that adds a method to scan bitmaps backwards? This functionality is necessary for upcoming change to remove on of the mark bitmaps [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708). > > As such this is only an addition of that functionality with no reference (apart from the gtest) from Hotspot itself. > > Testing: gtest > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: kbarrett review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8869/files - new: https://git.openjdk.java.net/jdk/pull/8869/files/6382a48a..556defe2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8869&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8869&range=03-04 Stats: 11 lines in 1 file changed: 2 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/8869.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8869/head:pull/8869 PR: https://git.openjdk.java.net/jdk/pull/8869 From kbarrett at openjdk.java.net Mon May 30 13:55:49 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 30 May 2022 13:55:49 GMT Subject: RFR: 8287215: Add method to scan bitmap backwards [v5] In-Reply-To: References: Message-ID: On Mon, 30 May 2022 13:31:29 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that adds a method to scan bitmaps backwards? This functionality is necessary for upcoming change to remove on of the mark bitmaps [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708). >> >> As such this is only an addition of that functionality with no reference (apart from the gtest) from Hotspot itself. >> >> Testing: gtest >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > kbarrett review Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8869 From shade at openjdk.java.net Mon May 30 15:54:46 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 30 May 2022 15:54:46 GMT Subject: RFR: 8287071: Loom: Cleanup x86_64 gen_continuation_enter [v3] In-Reply-To: <5Mtw3xX2QbDuQId2hd5xxNRNLau0a8Qs0Q3Kbw4FL-Y=.fb2807ef-8a83-4836-b189-f8584b862cee@github.com> References: <5Mtw3xX2QbDuQId2hd5xxNRNLau0a8Qs0Q3Kbw4FL-Y=.fb2807ef-8a83-4836-b189-f8584b862cee@github.com> Message-ID: On Mon, 30 May 2022 12:31:25 GMT, Aleksey Shipilev wrote: >> During x86_32 porting, I ended up rewriting the copy of x86_64 gen_continuation_enter significantly to make it more streamlined. The original x86_64 gen_continuation_enter should enjoy the similar streamlining, since it would likely to be the template for many other architectures. >> >> There might be more things to do, I would not know until x86_32 fully works. I am pretty sure current thing is self-sufficient. >> >> Brief tour of changes: >> - Check the incoming registers explicitly >> - Pass explicit argument registers to `fill_continuation_entry` >> - Use the usual `NativeCall` alignment code to produce a patchable call >> - Check that static stub is emitted, fail hard otherwise >> - Handle register shuffling for `exception_handler_for_return_address` the similar way we do it in `StubGenerator` >> >> Additional testing: >> - [x] Linux x86_64 fastdebug, prospective `jdk_loom hotspot_loom` > > Aleksey Shipilev 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: > > - Harmonize exception handler invocation > - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter > - Merge branch 'master' into JDK-8287071-loom-x86-64-gen-cont-enter > - Revert test groups > - Fix Still open for review. Windows test failures are known and handled separately. ------------- PR: https://git.openjdk.java.net/jdk/pull/8802 From dholmes at openjdk.java.net Tue May 31 01:50:35 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 31 May 2022 01:50:35 GMT Subject: RFR: 8287233: Crash in Continuation.enterSpecial: stop: tried to execute native method as non-native In-Reply-To: References: Message-ID: On Fri, 27 May 2022 15:53:25 GMT, Ron Pressler wrote: > Please review this fix to a continuation-related crash that happens due to a race between the linking and generation of Continuation.enterSpecial. > > Passes Loom tiers 1-5. I have one suggested change below, but in general enforcing strict storestore ordering seems to address the issue observed. Thanks. src/hotspot/share/oops/method.cpp line 1335: > 1333: // This must come last, as it is what's tested in LinkResolver::resolve_static_call > 1334: mh->_from_interpreted_entry = mh->get_i2c_entry(); > 1335: OrderAccess::storestore(); Technically this needs a release-store to pair with the load-acquire. But what subsequent store is this final store being ordered with? If there is none then it would suffice for this sequence to be just: mh->_i2i_entry = mh->get_i2c_entry(); // This must come last, as it is what's tested in LinkResolver::resolve_static_call Atomic::release_store(&mh->_from_interpreted_entry , mh->get_i2c_entry()); ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8926 From fjiang at openjdk.java.net Tue May 31 08:06:19 2022 From: fjiang at openjdk.java.net (Feilong Jiang) Date: Tue, 31 May 2022 08:06:19 GMT Subject: RFR: 8287552: riscv: Fix comment typo in li64 Message-ID: In riscv, 'imm[31:28]? should be 'imm[31:20]' for '0x7ff' in the following two places: src/hotspot/cpu/riscv/assembler_riscv.cpp: void Assembler::li64(Register Rd, int64_t imm) { // Load upper 32 bits. upper = imm[63:32], but if imm[31] == 1 or // (imm[31:28] == 0x7ff && imm[19] == 1), upper = imm[63:32] + 1. int64_t lower = imm & 0xffffffff; src/hotspot/cpu/riscv/macroAssembler_riscv.cpp: // Load upper 32 bits. Upper = target[63:32], but if target[31] = 1 or (target[31:28] == 0x7ff && target[19] == 1), // upper = target[63:32] + 1. This patch also unifies the immediate type in `movptr_with_offset` to `int64_t`. Hotspot tier1 test on QEMU passed without new failures. ------------- Commit messages: - fix typo Changes: https://git.openjdk.java.net/jdk/pull/8950/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8950&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287552 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8950.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8950/head:pull/8950 PR: https://git.openjdk.java.net/jdk/pull/8950 From duke at openjdk.java.net Tue May 31 09:03:49 2022 From: duke at openjdk.java.net (ldaxr) Date: Tue, 31 May 2022 09:03:49 GMT Subject: RFR: 8287550: Improve stack bang sp update granularity Message-ID: Align sp to page boundary when set to growth watermark in interpreter. The performance tests for a JMH case are shown below. [stack_bang_sp_align.csv](https://github.com/openjdk/jdk/files/8803249/stack_bang_sp_align.csv) ------------- Commit messages: - Enhance interpreter stack bang Changes: https://git.openjdk.java.net/jdk/pull/8951/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8951&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287550 Stats: 7 lines in 2 files changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8951.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8951/head:pull/8951 PR: https://git.openjdk.java.net/jdk/pull/8951 From shade at openjdk.java.net Tue May 31 10:34:29 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 31 May 2022 10:34:29 GMT Subject: RFR: 8287520: Shrink x86_32 problemlists after JDK-8287437 In-Reply-To: References: Message-ID: On Mon, 30 May 2022 13:20:17 GMT, Aleksey Shipilev wrote: > [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137) added a bunch of tests into problemlist. Those lists basically exclude every test that runs with --enable-preview. [JDK-8287437](https://bugs.openjdk.java.net/browse/JDK-8287437) makes it better: it only disables Loom parts, even with --enable-preview. This allows testing x86_32 on other preview features and avoids accidental bug slippage in non-Loom code paths. We can and should shrink the problem lists now. > > Additional testing: > - [x] Removed tests with Linux x86_32 fastdebug; mostly pass, some non-Loom failures > - [x] Linux x86_32 fastdebug `tier1` > - [ ] GHA run Open for reviews. The test failures on Windows x64 are known and are solved separately. ------------- PR: https://git.openjdk.java.net/jdk/pull/8946 From alanb at openjdk.java.net Tue May 31 11:43:14 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 31 May 2022 11:43:14 GMT Subject: RFR: 8287496: Alternative virtual thread implementation that maps to OS thread Message-ID: This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means: 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI) The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled. ------------- Commit messages: - Continuation clinit should fail if no continuations support - Fix merge issue with test - Change VMContinuations to be experimental option, ensure JNI GetEnv returns EVERSION - Update - Expend test coverage - Merge - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/8939/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8939&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287496 Stats: 742 lines in 71 files changed: 570 ins; 53 del; 119 mod Patch: https://git.openjdk.java.net/jdk/pull/8939.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8939/head:pull/8939 PR: https://git.openjdk.java.net/jdk/pull/8939 From duke at openjdk.java.net Tue May 31 11:43:15 2022 From: duke at openjdk.java.net (ExE Boss) Date: Tue, 31 May 2022 11:43:15 GMT Subject: RFR: 8287496: Alternative virtual thread implementation that maps to OS thread In-Reply-To: References: Message-ID: <7FdpvW58T55cnXD59rW5-71p7ENg2Q7BNfW5djYTGuU=.0fda930a-6b25-4be3-b329-945b9734d6d7@github.com> On Sun, 29 May 2022 14:46:39 GMT, Alan Bateman wrote: > This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means: > > 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) > 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI) > > The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled. Since?the?package `jdk.internal.access` is?exported[^1] to?the?`java.management`?module, this?can?use `MethodHandle`s obtained?using the?trusted?lookup. [^1]: https://github.com/openjdk/jdk/blob/73ba7fdce838ba8a2c227a972c176311e6cc0b41/src/java.base/share/classes/module-info.java#L151-L154 src/java.management/share/classes/java/lang/management/ThreadInfo.java line 971: > 969: throw new InternalError(e); > 970: } > 971: } Suggestion: private static boolean isVirtual(Thread thread) { try { return (boolean) IS_VIRTUAL.invokeExact(thread); } catch (Error | RuntimeException e) { throw e; } catch (Throwable t) { throw new InternalError(t); } } private static final MethodHandle IS_VIRTUAL; static { final JavaLangInvokeAccess JLIA = SharedSecrets.getJavaLangInvokeAccess(); try { MethodHandle m = JLIA.findVirtual(Thread.class, "isVirtual", MethodType.methodType(boolean.class)); assert m != null; IS_VIRTUAL = m; } catch (Exception e) { throw new InternalError(e); } } src/java.management/share/classes/sun/management/ThreadImpl.java line 661: > 659: > 660: private static final Method THREAD_IS_VIRTUAL = threadIsVirtual(); > 661: private static final Field THREADINFO_VIRTUAL = threadInfoVirtual(); Suggestion: private static boolean isVirtual(Thread thread) { try { return (boolean) THREAD_IS_VIRTUAL.invokeExact(thread); } catch (Error | RuntimeException e) { throw e; } catch (Throwable t) { throw new InternalError(t); } } /** * Returns true if the given ThreadInfo is for a virutal thread. */ private static boolean isVirtual(ThreadInfo threadInfo) { try { return (boolean) THREADINFO_VIRTUAL.invokeExact(threadInfo); } catch (Error | RuntimeException e) { throw e; } catch (Throwable t) { throw new InternalError(t); } } private static final JavaLangInvokeAccess JLIA = SharedSecrets.getJavaLangInvokeAccess(); private static MethodHandle threadIsVirtual() { try { MethodHandle m = JLIA.findVirtual(Thread.class, "isVirtual", MethodType.methodType(boolean.class)); assert m != null; return m; } catch (Exception e) { throw new InternalError(e); } } @SuppressWarnings("removal") private static MethodHandle threadInfoVirtual() { PrivilegedExceptionAction pa = () -> ThreadInfo.class.getDeclaredField("virtual"); try { return JLIA.unreflectField(AccessController.doPrivileged(pa), false); } catch (Exception e) { throw new InternalError(e); } } private static final MethodHandle THREAD_IS_VIRTUAL = threadIsVirtual(); private static final MethodHandle THREADINFO_VIRTUAL = threadInfoVirtual(); ------------- PR: https://git.openjdk.java.net/jdk/pull/8939 From alanb at openjdk.java.net Tue May 31 11:43:15 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 31 May 2022 11:43:15 GMT Subject: RFR: 8287496: Alternative virtual thread implementation that maps to OS thread In-Reply-To: References: Message-ID: On Sun, 29 May 2022 14:46:39 GMT, Alan Bateman wrote: > This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means: > > 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) > 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI) > > The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled. > Since?the?package `jdk.internal.access` is?exported[1](#user-content-fn-1-97aea7d7960164849e591e42b91fb5c4) to?the?`java.management`?module, this?can?use `MethodHandle`s obtained?using the?trusted?lookup. That export is for another reason, and probably should be re-examined so that java.base doesn't need to export this package to java.management. In any case, we expect there will be compiler support soon to allow java.management be compiled with code that makes use of preview APIs in java.base. That will at least us reference Thread::isVirtual from code. ------------- PR: https://git.openjdk.java.net/jdk/pull/8939 From alanb at openjdk.java.net Tue May 31 11:47:48 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 31 May 2022 11:47:48 GMT Subject: RFR: 8287520: Shrink x86_32 problemlists after JDK-8287437 In-Reply-To: References: Message-ID: On Mon, 30 May 2022 13:20:17 GMT, Aleksey Shipilev wrote: > [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137) added a bunch of tests into problemlist. Those lists basically exclude every test that runs with --enable-preview. [JDK-8287437](https://bugs.openjdk.java.net/browse/JDK-8287437) makes it better: it only disables Loom parts, even with --enable-preview. This allows testing x86_32 on other preview features and avoids accidental bug slippage in non-Loom code paths. We can and should shrink the problem lists now. > > Additional testing: > - [x] Removed tests with Linux x86_32 fastdebug; mostly pass, some non-Loom failures > - [x] Linux x86_32 fastdebug `tier1` > - [ ] GHA run This looks okay. If we get PR8939 in then it should be possible to do more clear out of the exclude lists. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8946 From zgu at openjdk.java.net Tue May 31 13:18:29 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 31 May 2022 13:18:29 GMT Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v2] In-Reply-To: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com> References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com> Message-ID: > Please review the patch that fixes Loom support in Shenandoah GC. > > - stackChunkOop is a special oop that contains stack metadata, we need to utilize nmethod entry barrier to mark, evacuate and update stack metadata. > - During evacuation and reference updating phase, we can not guarantee all metadata in stackChunkOop is deeply good, so I force it to take slow path for the correctness, will try to optimize it later in separate CR. > - Shenandoah uses similar way to arm and disarm nmethod as the new mechanism introduced in JDK-8284161. We may want to migrate to it in followup CR. > > Test: > - [x] tier1 with ShenandoahGC (Linux x86_64 and Windows x64) > - [x] tier2 with Shenandoah GC (Linux x86_64 and Windows x64) > - [x] hotspot_gc_shenandoah on Linux x86_32 > - [x] tier1 with ShenandoahGC + Loom (Linux x86_64 and Windows x64) > - [x] tier2 with ShenandoahGC + Loom (Linux x86_64 and Windows x64) Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Aleksey's comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8924/files - new: https://git.openjdk.java.net/jdk/pull/8924/files/7db9c0b8..b86b51b1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8924&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8924&range=00-01 Stats: 7 lines in 2 files changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8924.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8924/head:pull/8924 PR: https://git.openjdk.java.net/jdk/pull/8924 From zgu at openjdk.java.net Tue May 31 13:18:30 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 31 May 2022 13:18:30 GMT Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v2] In-Reply-To: References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com> Message-ID: On Mon, 30 May 2022 07:06:29 GMT, Aleksey Shipilev wrote: >> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: >> >> Aleksey's comment > > src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 529: > >> 527: heap->set_concurrent_mark_in_progress(true); >> 528: >> 529: _mark.start_mark(); > > Style: call `start_mark()` here maybe? Matches the use of `end_mark()` elsewhere. Okay. I am award of asymmetry, but not sure this is better. ------------- PR: https://git.openjdk.java.net/jdk/pull/8924 From aph at openjdk.java.net Tue May 31 13:43:09 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 31 May 2022 13:43:09 GMT Subject: RFR: 8287567: AArch64: Implement post-call NOPs Message-ID: Post-call NOPs (introduced with Loom virtual threads) are not implemented in the AArch64 port. Given that these are a significant optimization on x86, we should have them on AArch64 too. I looked at a variety of possible instruction sequences, and ended up with `nop; movk zr, lo; movk zr, hi`. `movk` is typically one of the fastest AArch64 instructions, so it should be suitable. It's not possible to patch the `movk` instructions concurrently with this code executing, but as far as I can tell the offsets in post-call NOPs are only ever patched while the code is being installed. ------------- Commit messages: - 8287567: AArch64: Implement post-call NOPs - Merge branch 'master' of https://github.com/openjdk/jdk into new-master - Merge https://github.com/openjdk/jdk into new-master - Revert "8287091: aarch64 : guarantee(val < (1ULL << nbits)) failed: Field too big for insn" - 8287091: aarch64 : guarantee(val < (1ULL << nbits)) failed: Field too big for insn Changes: https://git.openjdk.java.net/jdk/pull/8955/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8955&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287567 Stats: 46 lines in 5 files changed: 42 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8955.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8955/head:pull/8955 PR: https://git.openjdk.java.net/jdk/pull/8955 From shade at openjdk.java.net Tue May 31 14:03:42 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 31 May 2022 14:03:42 GMT Subject: RFR: 8287520: Shrink x86_32 problemlists after JDK-8287437 In-Reply-To: References: Message-ID: On Tue, 31 May 2022 11:44:27 GMT, Alan Bateman wrote: >> [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137) added a bunch of tests into problemlist. Those lists basically exclude every test that runs with --enable-preview. [JDK-8287437](https://bugs.openjdk.java.net/browse/JDK-8287437) makes it better: it only disables Loom parts, even with --enable-preview. This allows testing x86_32 on other preview features and avoids accidental bug slippage in non-Loom code paths. We can and should shrink the problem lists now. >> >> Additional testing: >> - [x] Removed tests with Linux x86_32 fastdebug; mostly pass, some non-Loom failures >> - [x] Linux x86_32 fastdebug `tier1` >> - [x] GHA run > > This looks okay. If we get PR8939 in then it should be possible to do more clear out of the exclude lists. Thank you, @AlanBateman. Any other comments? I plan to integrate it soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/8946 From adinn at openjdk.java.net Tue May 31 15:18:46 2022 From: adinn at openjdk.java.net (Andrew Dinn) Date: Tue, 31 May 2022 15:18:46 GMT Subject: RFR: 8287567: AArch64: Implement post-call NOPs In-Reply-To: References: Message-ID: On Tue, 31 May 2022 13:34:24 GMT, Andrew Haley wrote: > Post-call NOPs (introduced with Loom virtual threads) are not implemented in the AArch64 port. Given that these are a significant optimization on x86, we should have them on AArch64 too. > > I looked at a variety of possible instruction sequences, and ended up with `nop; movk zr, lo; movk zr, hi`. `movk` is typically one of the fastest AArch64 instructions, so it should be suitable. It's not possible to patch the `movk` instructions concurrently with this code executing, but as far as I can tell the offsets in post-call NOPs are only ever patched while the code is being installed. Looks good. ------------- Marked as reviewed by adinn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8955 From alanb at openjdk.java.net Tue May 31 15:39:39 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 31 May 2022 15:39:39 GMT Subject: RFR: 8287496: Alternative virtual thread implementation that maps to OS thread [v2] In-Reply-To: References: Message-ID: <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com> > This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means: > > 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) > 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI) > > The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Allowing linking without intrinsic stub, contributed-by: rehn ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8939/files - new: https://git.openjdk.java.net/jdk/pull/8939/files/7989708b..126e38b6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8939&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8939&range=00-01 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8939.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8939/head:pull/8939 PR: https://git.openjdk.java.net/jdk/pull/8939 From rpressler at openjdk.java.net Tue May 31 15:45:30 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Tue, 31 May 2022 15:45:30 GMT Subject: RFR: 8287233: Crash in Continuation.enterSpecial: stop: tried to execute native method as non-native [v2] In-Reply-To: References: Message-ID: > Please review this fix to a continuation-related crash that happens due to a race between the linking and generation of Continuation.enterSpecial. > > Passes Loom tiers 1-5. Ron Pressler has updated the pull request incrementally with one additional commit since the last revision: Change memory barriers ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8926/files - new: https://git.openjdk.java.net/jdk/pull/8926/files/5b55ac78..ddf2293f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8926&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8926&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8926.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8926/head:pull/8926 PR: https://git.openjdk.java.net/jdk/pull/8926 From rpressler at openjdk.java.net Tue May 31 15:45:31 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Tue, 31 May 2022 15:45:31 GMT Subject: RFR: 8287233: Crash in Continuation.enterSpecial: stop: tried to execute native method as non-native [v2] In-Reply-To: References: Message-ID: On Tue, 31 May 2022 01:21:29 GMT, David Holmes wrote: >> Ron Pressler has updated the pull request incrementally with one additional commit since the last revision: >> >> Change memory barriers > > src/hotspot/share/oops/method.cpp line 1335: > >> 1333: // This must come last, as it is what's tested in LinkResolver::resolve_static_call >> 1334: mh->_from_interpreted_entry = mh->get_i2c_entry(); >> 1335: OrderAccess::storestore(); > > Technically this needs a release-store to pair with the load-acquire. > > But what subsequent store is this final store being ordered with? If there is none then it would suffice for this sequence to be just: > > mh->_i2i_entry = mh->get_i2c_entry(); > // This must come last, as it is what's tested in LinkResolver::resolve_static_call > Atomic::release_store(&mh->_from_interpreted_entry , mh->get_i2c_entry()); Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/8926 From adinn at openjdk.java.net Tue May 31 15:59:49 2022 From: adinn at openjdk.java.net (Andrew Dinn) Date: Tue, 31 May 2022 15:59:49 GMT Subject: RFR: 8287567: AArch64: Implement post-call NOPs In-Reply-To: References: Message-ID: On Tue, 31 May 2022 13:34:24 GMT, Andrew Haley wrote: > Post-call NOPs (introduced with Loom virtual threads) are not implemented in the AArch64 port. Given that these are a significant optimization on x86, we should have them on AArch64 too. > > I looked at a variety of possible instruction sequences, and ended up with `nop; movk zr, lo; movk zr, hi`. `movk` is typically one of the fastest AArch64 instructions, so it should be suitable. It's not possible to patch the `movk` instructions concurrently with this code executing, but as far as I can tell the offsets in post-call NOPs are only ever patched while the code is being installed. @theRealAph Do you have any info on how much of a difference post call NOPs make to AArch64? Was there a benchmark used to justify their use in x86_64 that could tell us what the benefit is? ------------- PR: https://git.openjdk.java.net/jdk/pull/8955 From jbhateja at openjdk.java.net Tue May 31 16:04:55 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 31 May 2022 16:04:55 GMT Subject: RFR: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) [v10] In-Reply-To: References: Message-ID: On Wed, 25 May 2022 06:29:23 GMT, Jatin Bhateja wrote: >> Hi All, >> >> Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) >> >> Following is the brief summary of changes:- >> >> 1) Extends the scope of existing lanewise API for following new vector operations. >> - VectorOperations.BIT_COUNT: counts the number of one-bits >> - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits >> - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits >> - VectorOperations.REVERSE: reversing the order of bits >> - VectorOperations.REVERSE_BYTES: reversing the order of bytes >> - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. >> >> 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. >> - Vector.compress >> - Vector.expand >> - VectorMask.compress >> >> 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. >> - Vector.fromMemorySegment >> - Vector.intoMemorySegment >> >> 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. >> >> >> Patch has been regressed over AARCH64 and X86 targets different AVX levels. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - 8284960: Post merge cleanups. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - 8284960: Review comments resolved. > - 8284960: Integrating incremental patches. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - 8284960: Changes to enable jdk.incubator.vector to be treated as preview participant. Code re-organization related to Reverse/ReverseByte IR transforms. > - 8284960: Adding --enable-preview in vectorAPI benchmarks. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - 8284960: Review comments resolution. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8284960 > - ... and 10 more: https://git.openjdk.java.net/jdk/compare/742644e2...0f6e1584 Thanks reviewers for your comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From jbhateja at openjdk.java.net Tue May 31 16:04:58 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 31 May 2022 16:04:58 GMT Subject: Integrated: 8284960: Integration of JEP 426: Vector API (Fourth Incubator) In-Reply-To: References: Message-ID: On Wed, 27 Apr 2022 11:03:48 GMT, Jatin Bhateja wrote: > Hi All, > > Patch adds the planned support for new vector operations and APIs targeted for [JEP 426: Vector API (Fourth Incubator).](https://bugs.openjdk.java.net/browse/JDK-8280173) > > Following is the brief summary of changes:- > > 1) Extends the scope of existing lanewise API for following new vector operations. > - VectorOperations.BIT_COUNT: counts the number of one-bits > - VectorOperations.LEADING_ZEROS_COUNT: counts the number of leading zero bits > - VectorOperations.TRAILING_ZEROS_COUNT: counts the number of trailing zero bits > - VectorOperations.REVERSE: reversing the order of bits > - VectorOperations.REVERSE_BYTES: reversing the order of bytes > - compress and expand bits: Semantics are based on Hacker's Delight section 7-4 Compress, or Generalized Extract. > > 2) Adds following new APIs to perform cross lane vector compress and expansion operations under the influence of a mask. > - Vector.compress > - Vector.expand > - VectorMask.compress > > 3) Adds predicated and non-predicated versions of following new APIs to load and store the contents of vector from foreign MemorySegments. > - Vector.fromMemorySegment > - Vector.intoMemorySegment > > 4) C2 Compiler IR enhancements and optimized X86 and AARCH64 backend support for each newly added operation. > > > Patch has been regressed over AARCH64 and X86 targets different AVX levels. > > Kindly review and share your feedback. > > Best Regards, > Jatin This pull request has now been integrated. Changeset: 6f6486e9 Author: Jatin Bhateja URL: https://git.openjdk.java.net/jdk/commit/6f6486e97743eadfb20b4175e1b4b2b05b59a17a Stats: 38021 lines in 228 files changed: 16652 ins; 16924 del; 4445 mod 8284960: Integration of JEP 426: Vector API (Fourth Incubator) Co-authored-by: Jatin Bhateja Co-authored-by: Paul Sandoz Co-authored-by: Sandhya Viswanathan Co-authored-by: Smita Kamath Co-authored-by: Joshua Zhu Co-authored-by: Xiaohong Gong Co-authored-by: John R Rose Co-authored-by: Eric Liu Co-authored-by: Ningsheng Jian Reviewed-by: ngasson, vlivanov, mcimadamore, jlahoda, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/8425 From rpressler at openjdk.java.net Tue May 31 16:15:42 2022 From: rpressler at openjdk.java.net (Ron Pressler) Date: Tue, 31 May 2022 16:15:42 GMT Subject: RFR: 8287567: AArch64: Implement post-call NOPs In-Reply-To: References: Message-ID: <5xD7fuSPpX7oyfFw4A5Arxhdeemzv-14S3HfWEK2vs4=.72e4bed9-a494-401a-af79-2bbfd3a59abd@github.com> On Tue, 31 May 2022 13:34:24 GMT, Andrew Haley wrote: > Post-call NOPs (introduced with Loom virtual threads) are not implemented in the AArch64 port. Given that these are a significant optimization on x86, we should have them on AArch64 too. > > I looked at a variety of possible instruction sequences, and ended up with `nop; movk zr, lo; movk zr, hi`. `movk` is typically one of the fastest AArch64 instructions, so it should be suitable. It's not possible to patch the `movk` instructions concurrently with this code executing, but as far as I can tell the offsets in post-call NOPs are only ever patched while the code is being installed. The NOPs make a big difference for various stack walking operations, and while we did see some negative effects, they're probably very minor. However, because they're only generated in JDK 19 if preview is enabled, we can perform a deeper performance analysis later. ------------- PR: https://git.openjdk.java.net/jdk/pull/8955 From bulasevich at openjdk.java.net Tue May 31 16:58:42 2022 From: bulasevich at openjdk.java.net (Boris Ulasevich) Date: Tue, 31 May 2022 16:58:42 GMT Subject: RFR: 8287496: Alternative virtual thread implementation that maps to OS thread [v2] In-Reply-To: <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com> References: <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com> Message-ID: On Tue, 31 May 2022 15:39:39 GMT, Alan Bateman wrote: >> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means: >> >> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) >> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI) >> >> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Allowing linking without intrinsic stub, contributed-by: rehn I expected this change to fix the broken ARM32 port, but it doesn't work. # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (templateInterpreterGenerator_arm.cpp:732), pid=27345, tid=27346 # Error: Unimplemented() # # JRE version: (19.0) (build ) # Java VM: OpenJDK Server VM (19-commit6f6486e9-adhoc.re.jdk, mixed mode, g1 gc, linux-arm) # Problematic frame: # V [libjvm.so+0xa14fe0] TemplateInterpreterGenerator::generate_Continuation_doYield_entry()+0x2c ------------- PR: https://git.openjdk.java.net/jdk/pull/8939 From jvernee at openjdk.java.net Tue May 31 17:02:49 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Tue, 31 May 2022 17:02:49 GMT Subject: RFR: 8284849: Add deoptimization to unified logging [v2] In-Reply-To: References: Message-ID: On Fri, 27 May 2022 12:20:43 GMT, Johan Sj?l?n wrote: >> This PR adds a new "deoptimization" tag and a new log message on the info level mimicking JFR's deoptimization event. In the future this tag will be used to add trace level information, hopefully replacing TraceDeoptimization. JFR's event also captures the stacktrace, which this does not (happy to add this if considered important). >> >> An example output looks like this: >> >> >> [1.346s][info][deoptimization] Deoptimization start { >> [1.346s][info][deoptimization] compileId = 407 >> [1.346s][info][deoptimization] compiler = c2 >> [1.346s][info][deoptimization] method:lineno:bci = java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(I)Z:176:26 >> [1.346s][info][deoptimization] instruction = ifne >> [1.346s][info][deoptimization] reason = unstable_if >> [1.346s][info][deoptimization] action = reinterpret >> [1.346s][info][deoptimization] } Deoptimization end > > Johan Sj?l?n has updated the pull request incrementally with one additional commit since the last revision: > > Change log to single line I think this looks good overall. 1 comment inline src/hotspot/share/runtime/deoptimization.cpp line 1939: > 1937: const char* reason_action = Deoptimization::trap_action_name(action); > 1938: JFR_ONLY(post_deoptimization_event(nm, tm, trap_bci, trap_bc, reason, action);) > 1939: if (Log(deoptimization)::is_info()) { I don't think this `if` is needed now? The `log_debug` macro already seems to check whether the tag is enabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/8812 From shade at openjdk.java.net Tue May 31 17:07:43 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 31 May 2022 17:07:43 GMT Subject: RFR: 8287496: Alternative virtual thread implementation that maps to OS thread [v2] In-Reply-To: References: <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com> Message-ID: On Tue, 31 May 2022 16:54:41 GMT, Boris Ulasevich wrote: > I expected this change to fix the broken ARM32 port, but it doesn't work. It would not fix ARM32, because the interpreter stubs need to be predicated on `Continuations::enabled()`. Also, as my ARM32 experiments show (https://github.com/openjdk/jdk/pull/8634/files#diff-027490ce3f4a92be9b489d9d2e54c7baaea87b7489399b198543c79f1ce1e2e3R4208-R4216) -- there is a breakage somewhere in C2 as well, which this patch would not seem to resolve as well. So, this is a stepping stone for *some* support, but it does not resolve porting situation fully. ------------- PR: https://git.openjdk.java.net/jdk/pull/8939 From shade at openjdk.java.net Tue May 31 17:10:33 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 31 May 2022 17:10:33 GMT Subject: RFR: 8287520: Shrink x86_32 problemlists after JDK-8287437 [v2] In-Reply-To: References: Message-ID: > [JDK-8287137](https://bugs.openjdk.java.net/browse/JDK-8287137) added a bunch of tests into problemlist. Those lists basically exclude every test that runs with --enable-preview. [JDK-8287437](https://bugs.openjdk.java.net/browse/JDK-8287437) makes it better: it only disables Loom parts, even with --enable-preview. This allows testing x86_32 on other preview features and avoids accidental bug slippage in non-Loom code paths. We can and should shrink the problem lists now. > > Additional testing: > - [x] Removed tests with Linux x86_32 fastdebug; mostly pass, some non-Loom failures > - [x] Linux x86_32 fastdebug `tier1` > - [x] GHA run Aleksey Shipilev 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-8287520-loom-x86-32-shrink - Keep GetEventWriter on problemlist - Fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8946/files - new: https://git.openjdk.java.net/jdk/pull/8946/files/7c90ead6..a3c3db2b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8946&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8946&range=00-01 Stats: 38619 lines in 252 files changed: 17091 ins; 16971 del; 4557 mod Patch: https://git.openjdk.java.net/jdk/pull/8946.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8946/head:pull/8946 PR: https://git.openjdk.java.net/jdk/pull/8946 From alanb at openjdk.java.net Tue May 31 17:10:45 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 31 May 2022 17:10:45 GMT Subject: RFR: 8287496: Alternative virtual thread implementation that maps to OS thread [v2] In-Reply-To: References: <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com> Message-ID: On Tue, 31 May 2022 17:03:54 GMT, Aleksey Shipilev wrote: > I expected this change to fix the broken ARM32 port, but it doesn't work. There is work required to get the arm32 port working again, currently tracked as JDK-828636 but there may be further issues beyond that. ------------- PR: https://git.openjdk.java.net/jdk/pull/8939 From pchilanomate at openjdk.java.net Tue May 31 17:19:43 2022 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Tue, 31 May 2022 17:19:43 GMT Subject: RFR: 8287233: Crash in Continuation.enterSpecial: stop: tried to execute native method as non-native [v2] In-Reply-To: References: Message-ID: On Tue, 31 May 2022 15:45:30 GMT, Ron Pressler wrote: >> Please review this fix to a continuation-related crash that happens due to a race between the linking and generation of Continuation.enterSpecial. >> >> Passes Loom tiers 1-5. > > Ron Pressler has updated the pull request incrementally with one additional commit since the last revision: > > Change memory barriers LGTM. ------------- Marked as reviewed by pchilanomate (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8926 From zgu at openjdk.java.net Tue May 31 17:45:34 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 31 May 2022 17:45:34 GMT Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3] In-Reply-To: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com> References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com> Message-ID: > Please review the patch that fixes Loom support in Shenandoah GC. > > - stackChunkOop is a special oop that contains stack metadata, we need to utilize nmethod entry barrier to mark, evacuate and update stack metadata. > - During evacuation and reference updating phase, we can not guarantee all metadata in stackChunkOop is deeply good, so I force it to take slow path for the correctness, will try to optimize it later in separate CR. > - Shenandoah uses similar way to arm and disarm nmethod as the new mechanism introduced in JDK-8284161. We may want to migrate to it in followup CR. > > Test: > - [x] tier1 with ShenandoahGC (Linux x86_64 and Windows x64) > - [x] tier2 with Shenandoah GC (Linux x86_64 and Windows x64) > - [x] hotspot_gc_shenandoah on Linux x86_32 > - [x] tier1 with ShenandoahGC + Loom (Linux x86_64 and Windows x64) > - [x] tier2 with ShenandoahGC + Loom (Linux x86_64 and Windows x64) Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision: - Fix - NMethod::heal_nmethod() does not need to handle ref-update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8924/files - new: https://git.openjdk.java.net/jdk/pull/8924/files/b86b51b1..ed84a9e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8924&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8924&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8924.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8924/head:pull/8924 PR: https://git.openjdk.java.net/jdk/pull/8924 From rehn at openjdk.java.net Tue May 31 17:47:46 2022 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 31 May 2022 17:47:46 GMT Subject: RFR: 8287496: Alternative virtual thread implementation that maps to OS thread [v2] In-Reply-To: <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com> References: <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com> Message-ID: On Tue, 31 May 2022 15:39:39 GMT, Alan Bateman wrote: >> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means: >> >> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) >> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI) >> >> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Allowing linking without intrinsic stub, contributed-by: rehn Looks good, tested zero, thanks! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8939 From mchung at openjdk.java.net Tue May 31 23:48:34 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 31 May 2022 23:48:34 GMT Subject: RFR: 8287496: Alternative virtual thread implementation that maps to OS thread [v2] In-Reply-To: <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com> References: <88ga2R8ljHJta4VTpfa1cRDqASUDrzVxMl8tjsV_BqU=.28a6b886-d9f5-448a-a5c2-35fc03d79ea9@github.com> Message-ID: On Tue, 31 May 2022 15:39:39 GMT, Alan Bateman wrote: >> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means: >> >> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) >> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI) >> >> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Allowing linking without intrinsic stub, contributed-by: rehn Looks okay to me. src/java.management/share/classes/sun/management/ThreadImpl.java line 586: > 584: > 585: /** > 586: * Returns the ThreadInfo objects from the given array that coresspond to platform typo: coresspond -> correspond src/java.management/share/classes/sun/management/Util.java line 92: > 90: > 91: /** > 92: * Returns true if the given Thread is a virutal thread. typo: virutal -> virtual this typo appears in other comments too. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8939