From fyang at openjdk.org Fri Nov 1 01:10:11 2024 From: fyang at openjdk.org (Fei Yang) Date: Fri, 1 Nov 2024 01:10:11 GMT Subject: RFR: 8343242: RISC-V: Refactor materialization of literal address [v2] In-Reply-To: References: Message-ID: > Hi, please consider this refactoring work. > > Currently, we have both `la(address)` and `la(Address)`. They both accept and materialize literal address. > While `la(Address)` always emit a movptr sequence, `la(address)` is a bit complex: it checks whether the target is > reachable from anywhere within the code cache (`is_32bit_offset_from_codecache`) and emits pc-relative auipc+addi > pair or movptr sequence. This makes it not that obvious at places where we want a more accurate estimation about > the size of code emitted like when we prepare code stubs like C2SafepointPollStub or C2EntryBarrierStub (See: https://github.com/openjdk/jdk/pull/21732). > > I would suggest we keep `la(address)` simple and let it only emit auipc+addi pair, which will be consistent with the > `RISC-V Assembly Programmer's Handbook`. I think It's more reasonable to move the distance check to `la(Address)`. > Furthermore, I would also suggest that we make the distance check simpler. The approach taken here is to only check > whether the target is inside the code cache. This way we will be more certain about code emitted with `la(Address)` > as well. This will help keep the risk of this change low as all `la(Address)` callsites with literal address outside of code > cache won't be affected. And I don't think the original distance check from code cache will benefit us much more. > Eyeballed all `la(Address)` callsites, I think we are fine. > > Benefits: > 1. We have a simpler `la(address)` which is kind of spec compatible; > 2. We are consistent in target distance check when doing `j(Address)`, `la(Address)`, `ld/st(Address)` and `rt_call`; > 3. We don't need explicit use of `relocate` with lambda for most of the places; > > Note that there are several places where we want explicit `movptr` sequence: > 1. In `SignatureHandlerGenerator::generate()` where the emitted code is simply copied without relocation [1]; > 2. In `movoop` and `mov_metadata` where we want patching afterwards; > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/interpreterRuntime.cpp#L1313 > > Testing on linux-riscv64: > - [x] hotspot:tier1 (fastdebug) > - [x] tier1-tier3, hotspot:tier4 (release) > - [x] specjbb2015, dacapo, renaissance (release) Fei Yang 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 remote-tracking branch 'upstream/master' into JDK-8343242 - 8343242: RISC-V: Refactor materialization of literal address ------------- Changes: https://git.openjdk.org/jdk/pull/21777/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21777&range=01 Stats: 161 lines in 14 files changed: 28 ins; 87 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/21777.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21777/head:pull/21777 PR: https://git.openjdk.org/jdk/pull/21777 From fyang at openjdk.org Fri Nov 1 01:22:31 2024 From: fyang at openjdk.org (Fei Yang) Date: Fri, 1 Nov 2024 01:22:31 GMT Subject: RFR: 8343242: RISC-V: Refactor materialization of literal address In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 10:18:24 GMT, Robbin Ehn wrote: > Did you run any micro benchmarks? Maybe skynet just to check VTs. And did you do any measurement on code cache size? No obvious change witnessed on Skynet JMH with this change. Let me know if there are others we might want a try. > And did you do any measurement on code cache size? Good suggestion. I just tried dacapo and renaissance with `-XX:+PrintCodeCache -XX:-TieredCompilation` and compared the `max_used` of code cache. I didn't see a big difference with this change either. > I can't find anything that would matter, but I'll look a bit more. Thanks. I merged master. Take your time! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21777#issuecomment-2451116516 From dholmes at openjdk.org Fri Nov 1 01:59:50 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 1 Nov 2024 01:59:50 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v25] In-Reply-To: <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com> References: <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com> Message-ID: On Thu, 31 Oct 2024 21:50:50 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision: > > - add comment to ThreadService::find_deadlocks_at_safepoint > - Remove assignments in preempt_kind enum Marked as reviewed by dholmes (Reviewer). src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889: > 887: return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller); > 888: } else { > 889: // frame can't be freezed. Most likely the call_stub or upcall_stub Suggestion: // Frame can't be frozen. Most likely the call_stub or upcall_stub src/hotspot/share/services/threadService.cpp line 467: > 465: if (waitingToLockMonitor->has_owner()) { > 466: currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor); > 467: // If currentThread is nullptr we would like to know if the owner Suggestion: // If currentThread is null we would like to know if the owner src/hotspot/share/services/threadService.cpp line 474: > 472: // vthread we never record this as a deadlock. Note: unless there > 473: // is a bug in the VM, or a thread exits without releasing monitors > 474: // acquired through JNI, nullptr should imply unmounted vthread owner. Suggestion: // acquired through JNI, null should imply an unmounted vthread owner. ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2409348761 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825344054 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825344940 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825345446 From heidinga at openjdk.org Fri Nov 1 03:57:34 2024 From: heidinga at openjdk.org (Dan Heidinga) Date: Fri, 1 Nov 2024 03:57:34 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v6] In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 02:23:24 GMT, Ioi Lam wrote: >> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). >> >> ---- >> Note: this is a combined PR of the following individual PRs >> - https://github.com/openjdk/jdk/pull/20516 >> - https://github.com/openjdk/jdk/pull/20517 >> - https://github.com/openjdk/jdk/pull/20843 >> - https://github.com/openjdk/jdk/pull/20958 >> - https://github.com/openjdk/jdk/pull/20959 >> - https://github.com/openjdk/jdk/pull/21049 >> - https://github.com/openjdk/jdk/pull/21143 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed whitespace; fixed minimal build src/hotspot/share/cds/aotClassInitializer.cpp line 348: > 346: } > 347: JavaValue result(T_VOID); > 348: JavaCalls::call_static(&result, ik, Based on the discussions in JDK-8342283, do we need a memory fence after the call to runtimeSetup? I think we do to be consistent with the non-AOTCache run as there is a fence after `` (when this code would normally run) due to the initialization lock. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1825400292 From dholmes at openjdk.org Fri Nov 1 05:28:45 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 1 Nov 2024 05:28:45 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4] In-Reply-To: References: Message-ID: <4m-EzgWHGUYq1eDTqNIM0vkI66Ff4YYeA5AuJO64hfU=.5f1b2fd0-bb61-456f-be46-18cbe4f7bb6d@github.com> On Thu, 31 Oct 2024 13:19:09 GMT, Johannes Bechberger wrote: >> Why? Large chunks of platform specific code should be in platform specific files. That is the way hotspot sources are arranged. > > Can we postpone this change to a later stage? This would possibly invalidate lot's of GitHub comments. I see the point of the change, but I think there are currently more pressing things. A follow up RFE to move the code will be okay. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1825440468 From dholmes at openjdk.org Fri Nov 1 05:28:46 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 1 Nov 2024 05:28:46 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4] In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 06:37:45 GMT, Johannes Bechberger wrote: >> Of course you are racing with the execution of those other threads either way. In contrast if you do this at a safepoint you know the exact state of each thread and will know, for example, that the timer was created before the thread could terminate. > > Is this really an issue? And if so, how would I implement this? Whether the racing is an issue only you can answer. My concern is that using the `Threads_lock` is bad and unnecessary - if you want a stable set of threads then you just need a `ThreadsListIterator`. Otherwise you'd implement with a safepoint VM operation that you submit to the VMThread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1825440196 From jwaters at openjdk.org Fri Nov 1 05:32:40 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 1 Nov 2024 05:32:40 GMT Subject: RFR: 8316930: HotSpot should use noexcept instead of throw() [v5] In-Reply-To: <9k00GYxtEiNBgrtIsIYJUIdwwPjynEm6aONdchZreP4=.0ad54916-180e-4317-8385-e339595a340a@github.com> References: <9k00GYxtEiNBgrtIsIYJUIdwwPjynEm6aONdchZreP4=.0ad54916-180e-4317-8385-e339595a340a@github.com> Message-ID: <9ZHn3DaWbLJeaV1q1T8GrLaN50XHCJI9SeKst5LIpVY=.a6784b1d-1c79-418b-9778-ec51b1ff29d3@github.com> On Tue, 6 Feb 2024 07:04:00 GMT, Julian Waters wrote: >> throw() has been deprecated since C++11 alongside dynamic exception specifications, we should replace all instances of it with noexcept to prepare HotSpot for later versions of C++ > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'openjdk:master' into noexcept > - Merge branch 'openjdk:master' into noexcept > - Typo in GensrcAdlc.gmk > - Merge branch 'openjdk:master' into noexcept > - Merge branch 'master' into noexcept > - ic in compiledIC.hpp > - Revert compiledIC.cpp > - Revert compiledIC.hpp > - Partially Revert parse.hpp > - Merge branch 'master' into noexcept > - ... and 4 more: https://git.openjdk.org/jdk/compare/9ee9f288...b73a6882 You're high Skara, go home ------------- PR Comment: https://git.openjdk.org/jdk/pull/15910#issuecomment-2451319876 From dholmes at openjdk.org Fri Nov 1 05:34:39 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 1 Nov 2024 05:34:39 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4] In-Reply-To: References: <4UKrYUWVTFaWJOZ1vWneEnYodZs3leVoHyb8DWj0zec=.aa2eca4b-a49b-4c8d-bc16-62f81c3e38a4@github.com> Message-ID: On Thu, 31 Oct 2024 10:03:40 GMT, Johannes Bechberger wrote: >> But this doesn't check whether the state could be something new an unsupported. > > I changed it to your recommendation. Consistency with existing code may take precedence here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1825442494 From dholmes at openjdk.org Fri Nov 1 05:41:37 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 1 Nov 2024 05:41:37 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4] In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 10:03:18 GMT, Johannes Bechberger wrote: >> Should I instead name it `non_java`? > > I renamed it. Consistency with existing code may take precedence here. I can take up this naming quirk afterwards. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1825445376 From dholmes at openjdk.org Fri Nov 1 05:41:37 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 1 Nov 2024 05:41:37 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4] In-Reply-To: References: Message-ID: <-k9gN8T-aRDOQpt-N5J8r3kamSTMmO6KuFvWyD6l0mM=.1ddd6144-883c-4747-815d-55f475631fa6@github.com> On Thu, 31 Oct 2024 06:41:13 GMT, Johannes Bechberger wrote: >> DST changes are not reflected in the low-level clocks, they come from higher-level API's that format times and account for TZ. >> >> The clock underpinning `javaTimeMillis` can still jump due to NTP adjustments and so a monotonic clock source is preferable. > > So this issue is now resolved? Yes using nanoTime resolves any concerns. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1825445502 From dholmes at openjdk.org Fri Nov 1 05:41:38 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 1 Nov 2024 05:41:38 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4] In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 18:10:52 GMT, Johannes Bechberger wrote: >> src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 56: >> >>> 54: } >>> 55: assert(current_thread->in_asgct(), "invariant"); >>> 56: assert(jt != current_thread || current_thread->in_asgct(), "invariant"); >> >> The second clause of the second assert is redundant given the first assert. > > The second assert is redundant. Good point :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1825445850 From dlong at openjdk.org Fri Nov 1 07:17:48 2024 From: dlong at openjdk.org (Dean Long) Date: Fri, 1 Nov 2024 07:17:48 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v12] In-Reply-To: References: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com> Message-ID: On Thu, 31 Oct 2024 16:27:05 GMT, Patricio Chilano Mateo wrote: >> OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed? I also think we should fix the aarch64 c2 stub to just store last_Java_pc like you suggest. Adjusting the stack like this has in the past caused other problems, in particular making it hard to obtain safe stack traces during asynchronous profiling. >> >> It's still unclear to me exactly how we resume after preemption. It looks like we resume at last_Java_pc with rsp set based on last_Java_sp, which is why it needs to be adjusted. If that's the case, an alternative simplification for aarch64 is to set a different last_Java_pc that is preemption-friendly that skips the stack adjustment. In your example, last_Java_pc would be set to 0xffffdfdba5e4. I think it is a reasonable requirement that preemption can return to last_Java_pc/last_Java_sp without adjustments. > >> OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed? >> > It's not a bug, it's just that the code from the runtime stub only cares about the actual rsp, not last_Java_sp. We are returning to the pc right after the call so we need to adjust rsp to what the runtime stub expects. Both alternatives will work, either changing the runtime stub to set last pc and not push those two extra words, or your suggestion of just setting the last pc to the instruction after the adjustment. Either way it requires to change the c2 code though which I'm not familiar with. But if you can provide a patch I'm happy to apply it and we can remove this `possibly_adjust_frame()` method. It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes. Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825498409 From attila at openjdk.org Fri Nov 1 09:19:12 2024 From: attila at openjdk.org (Attila Szegedi) Date: Fri, 1 Nov 2024 09:19:12 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6] In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits: > > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Modify three RMI tests to work without the security manager: > - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java > - test/jdk/java/rmi/registry/readTest/CodebaseTest.java > - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java > Also remove them from the problem list. > - Remove two obsolete RMI tests: > - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java > - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java > Adjust two tests to run without the Security Manager: > - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java > - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java > Remove all of these tests from the problem list. > - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows. > - Added API Notes to ProtectionDomain clarifying that the current policy always > grants no permissions. A few other small changes to Policy and PD. > - Merge branch 'master' into jep486 > - JAXP tests: organize imports of a few tests > - Improve description of Executors.privilegedThreadFactory > - rename TestAppletLoggerContext.java as suggested in util test review > - clientlibs: Javadoc cleanup > - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b `jdk.dynalink` changes look good. ------------- Marked as reviewed by attila (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2409755977 From rehn at openjdk.org Fri Nov 1 10:52:27 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 1 Nov 2024 10:52:27 GMT Subject: RFR: 8343242: RISC-V: Refactor materialization of literal address [v2] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 01:10:11 GMT, Fei Yang wrote: >> Hi, please consider this refactoring work. >> >> Currently, we have both `la(address)` and `la(Address)`. They both accept and materialize literal address. >> While `la(Address)` always emit a movptr sequence, `la(address)` is a bit complex: it checks whether the target is >> reachable from anywhere within the code cache (`is_32bit_offset_from_codecache`) and emits pc-relative auipc+addi >> pair or movptr sequence. This makes it not that obvious at places where we want a more accurate estimation about >> the size of code emitted like when we prepare code stubs like C2SafepointPollStub or C2EntryBarrierStub (See: https://github.com/openjdk/jdk/pull/21732). >> >> I would suggest we keep `la(address)` simple and let it only emit auipc+addi pair, which will be consistent with the >> `RISC-V Assembly Programmer's Handbook`. I think It's more reasonable to move the distance check to `la(Address)`. >> Furthermore, I would also suggest that we make the distance check simpler. The approach taken here is to only check >> whether the target is inside the code cache. This way we will be more certain about code emitted with `la(Address)` >> as well. This will help keep the risk of this change low as all `la(Address)` callsites with literal address outside of code >> cache won't be affected. And I don't think the original distance check from code cache will benefit us much more. >> Eyeballed all `la(Address)` callsites, I think we are fine. >> >> Benefits: >> 1. We have a simpler `la(address)` which is kind of spec compatible; >> 2. We are consistent in target distance check when doing `j(Address)`, `la(Address)`, `ld/st(Address)` and `rt_call`; >> 3. We don't need explicit use of `relocate` with lambda for most of the places; >> >> Note that there are several places where we want explicit `movptr` sequence: >> 1. In `SignatureHandlerGenerator::generate()` where the emitted code is simply copied without relocation [1]; >> 2. In `movoop` and `mov_metadata` where we want patching afterwards; >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/interpreterRuntime.cpp#L1313 >> >> Testing on linux-riscv64: >> - [x] hotspot:tier1 (fastdebug) >> - [x] tier1-tier3, hotspot:tier4 (release) >> - [x] specjbb2015, dacapo, renaissance (release) > > Fei Yang 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 remote-tracking branch 'upstream/master' into JDK-8343242 > - 8343242: RISC-V: Refactor materialization of literal address Looks good, thanks! ------------- Marked as reviewed by rehn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21777#pullrequestreview-2409869937 From kevinw at openjdk.org Fri Nov 1 12:15:33 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 1 Nov 2024 12:15:33 GMT Subject: RFR: 8204681: Option to include timestamp in hprof filename [v2] In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 15:42:57 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8204681](https://bugs.openjdk.org/browse/JDK-8204681) enabling support for timestamp expansion in filenames specified in `-XX:HeapDumpPath` using `%t`. >> >> As mentioned in this comments for this issue, this is somewhat related to [8334492](https://bugs.openjdk.org/browse/JDK-8334492) where we enabled support for `%p` for filenames specified in jcmd. >> >> With this patch, I propose: >> - Expanding the utility function `Arguments::copy_expand_pid` to `Arguments::copy_expand_arguments` to deal with `%p` expansions for pid and `%t` expansions for timestamps. >> - Leveraging the above utility function to enable argument expansion for both heap dump filenames and jcmd output commands. >> - Though the linked JBS issue only relates to heap dumps generated in case of OOM, I think we can edit it to more broadly support filename expansion to support `%t` for jcmd as well. >> >> Testing: >> - [x] Added test cases pass with all platforms (verified with a GHA job). >> - [x] Tier 1 passes with GHA. >> >> Looking forward to hearing your thoughts! >> >> Thanks, >> Sonia > > Sonia Zaldana Calles 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 'openjdk:master' into JDK-8204681 > - 8204681: Option to include timestamp in hprof filename Thanks Sonia -- Regarding timestamp format: UL style got you a timestamp like: 2024-10-31T15:14:39.344-0400 make_log_name() would give: YYYY-MM-DD_HH-MM-SS Precision vs filename length? The .001 of a second accuracy might not be that meaningful on a file name. I was liking the make_log_name() style above, but it's not really critical which. But what does Unified Logging do when you log to a file? file=filename uses %p and %t for pid and STARTUP timestamp. Hmm.... For usage like heapdumps where you may want multiple, current time is much more useful than startup time. But hey, it's another vote for the use of %t for timestamp in a filename, and a UnifiedLogging log to a file does not give you control over exactly how you want the timestamp in the filename. You get what you get. (The events logged in the file are what matter I suppose (and I agree)). So what timestamp do you get? java -Xlog:gc*:file%t.out -version creates file2024-11-01_12-01-10.out ..so that looks like the simpler version, like make_log_name() mentioned earlier. No milliseconds or time offsets. I would do that, and forget multi-character patterns unless somebody really wants/needs it. 8-) ------ On changing Arguments::copy_expand_pid to Arguments::copy_expand_arguments There are a few users, listed below. I can't see any problem by starting to respect a new % token, but there is always a chance as I think Thomas was suggesting. If anybody is concerned, we should keep Arguments::copy_expand_pid, and add a new function to do timestamps additionally. ------ Arguments::copy_expand_pid I find usage by: perfMemory.cpp: perdata file is not normally going to have %t in it but -XX:PerfDataSaveFile= could set it. Users would be really unwise to add specify %t here! Maybe that means there should still be Arguments::copy_expand_pid which ONLY does %p expansion. diagnosticArgument.cpp uses it, good, that's what we want. vmError.cpp: next_OnError_command uses it. Having timestamp support in -XX:OnError command strings in addition to %p could be really useful. Small chance of a clash with existing commands/scripts. vmError.cpp: expand_and_open / prepare_log_file / VMError::report_and_die calls: prepare_log_file(ErrorFile, "hs_err_pid%p.log",... OK, being able to specify a timestamp in hs_err could be very useful. Also the compiler replay data file would be affected (again not bad). Also called by JVMCI::fatal_log() meaning -XX:JVMCINativeLibraryErrorFile= could set a filename using %p and now %t. jfrEmergencyDump.cpp: create_emergency_dump_path() uses it, with these patterns, which are not configurable, so not a problem: 44 static const char vm_error_filename_fmt[] = "hs_err_pid%p.jfr"; 45 static const char vm_oom_filename_fmt[] = "hs_oom_pid%p.jfr"; 46 static const char vm_soe_filename_fmt[] = "hs_soe_pid%p.jfr"; The changes look generally useful. A release note and maybe other doc updates will be needed (which is fine). If the impact looks too much, keeping Arguments::copy_expand_pid and creating Arguments::copy_expand_arguments which optionally does timestamp expansion, will mean the other changes (hs_err, replay, etc..) can be made separately. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20568#issuecomment-2451776538 From dholmes at openjdk.org Fri Nov 1 12:50:28 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 1 Nov 2024 12:50:28 GMT Subject: RFR: 8343218: Disable allocating interface and abstract classes in non-class metaspace [v2] In-Reply-To: References: <7Z-FvvKjDqia20mBFSRgN-od2FEM89D2U3VfyC--BJk=.4438af6e-cc45-40d2-8533-7bd359cebba8@github.com> <1xurMyjTB2XPkn57XaTDNUGXaTY614wIdQv1KfV-FpA=.4a31bef2-a80f-4749-95e9-ff41952f2a52@github.com> Message-ID: On Thu, 31 Oct 2024 18:31:35 GMT, Coleen Phillimore wrote: >> src/hotspot/share/oops/instanceKlass.cpp line 460: >> >>> 458: // are the only ones that require compression and allocation in the limited class metaspace >>> 459: // region. But ... there are C2 dependencies that all klasses are allocated to the class metaspace, so >>> 460: // always use the class metaspace until JDK-NNNNNNN is resolved. >> >> JDK-NNNNNN was supposed to be replaced by an actual bug number. :) > > I was wondering where the NNNN came from. I do not want to put the number in the code, and there may be a performance problem that I'm working on. I may or may not push this. The c2 problem will be addressed with an assert and I'll look through c1 and see if there may be a similar problem. I'm left wondering what this is supposed to do. We made changes, then we are disabling them until something is fixed but we are not saying what something that is. ??? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21769#discussion_r1825780949 From coleenp at openjdk.org Fri Nov 1 13:08:28 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 1 Nov 2024 13:08:28 GMT Subject: RFR: 8343218: Disable allocating interface and abstract classes in non-class metaspace [v2] In-Reply-To: References: <7Z-FvvKjDqia20mBFSRgN-od2FEM89D2U3VfyC--BJk=.4438af6e-cc45-40d2-8533-7bd359cebba8@github.com> <1xurMyjTB2XPkn57XaTDNUGXaTY614wIdQv1KfV-FpA=.4a31bef2-a80f-4749-95e9-ff41952f2a52@github.com> Message-ID: On Fri, 1 Nov 2024 12:47:28 GMT, David Holmes wrote: >> I was wondering where the NNNN came from. I do not want to put the number in the code, and there may be a performance problem that I'm working on. I may or may not push this. The c2 problem will be addressed with an assert and I'll look through c1 and see if there may be a similar problem. > > I'm left wondering what this is supposed to do. We made changes, then we are disabling them until something is fixed but we are not saying what something that is. ??? Given that it's a subtask of the bug that we want to fix, it's pretty easy to see with git blame. Like with all changes, we don't put bug numbers in. But the bug will be fixed soon so I'm closing this as WNF. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21769#discussion_r1825797352 From mgronlun at openjdk.org Fri Nov 1 13:24:38 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 1 Nov 2024 13:24:38 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4] In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 19:34:23 GMT, Johannes Bechberger wrote: >> This is the code for the [JEP draft: CPU Time based profiling for JFR]. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove min_valid_free_size_bytes src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 44: > 42: #include "signals_posix.hpp" > 43: > 44: const int64_t AUTOADAPT_INTERVAL_MS = 100; static src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 738: > 736: } > 737: > 738: const int SIG = SIGPROF; static src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 809: > 807: > 808: > 809: int64_t compute_sampling_period(double rate) { static src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 854: > 852: static bool _showed_warning = false; > 853: > 854: void warn() { static ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1825811189 PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1825812025 PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1825812255 PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1825812447 From mgronlun at openjdk.org Fri Nov 1 14:26:40 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 1 Nov 2024 14:26:40 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4] In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 19:34:23 GMT, Johannes Bechberger wrote: >> This is the code for the [JEP draft: CPU Time based profiling for JFR]. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Remove min_valid_free_size_bytes src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 116: > 114: return false; > 115: } > 116: const traceid mid = JfrTraceId::load(frame._method); This is JfrTraceId::load() barrier code: inline traceid JfrTraceIdLoadBarrier::load(const Klass* klass, const Method* method) { assert(klass != nullptr, "invariant"); assert(method != nullptr, "invariant"); if (should_tag(method)) { SET_METHOD_AND_CLASS_USED_THIS_EPOCH(klass); SET_METHOD_FLAG_USED_THIS_EPOCH(method); assert(METHOD_AND_CLASS_USED_THIS_EPOCH(klass), "invariant"); assert(METHOD_FLAG_USED_THIS_EPOCH(method), "invariant"); enqueue(klass); JfrTraceIdEpoch::set_changed_tag_state(); } return (METHOD_ID(klass, method)); } What happens if the sampler crashes at one of these routines? 1. Sets bits in the Klass, but not in the Method, and does not enqueue? 2. Set bits in the Klass and Method, but does not enqueue? 3. Sets bits in Klass, Method and enqueues, but does not notify? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1825879231 From jbachorik at openjdk.org Fri Nov 1 15:03:39 2024 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Fri, 1 Nov 2024 15:03:39 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4] In-Reply-To: References: Message-ID: <5-9nPi84vF3f3oCCJqV4y7sU5bvigJY2RAI7mngMS-4=.f48a03d5-0acb-4c28-97d0-d2131355b323@github.com> On Thu, 31 Oct 2024 13:28:24 GMT, Markus Gr?nlund wrote: >Stack: [0x0000fffb01f6c000,0x0000fffb0216a000], sp=0x0000fffb021683a0, free space=2032k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) J 8439 c2 jdk.internal.org.objectweb.asm.SymbolTable.addConstantUtf8(Ljava/lang/String;)I java.base at 24-internal (98 bytes) @ 0x0000ffff68300b4c [0x0000ffff68300d00+0xfffffffffffffe4c] V [libjvm.so+0x816bd8] JFRRecordSampledThreadCallback::call()+0x18 (jfrCPUTimeThreadSampler.cpp:550) Am I reading this right that the callback does upcall to Java where it modifies bytecode via ASM? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2452022681 From aboldtch at openjdk.org Fri Nov 1 15:26:56 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 1 Nov 2024 15:26:56 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v25] In-Reply-To: <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com> References: <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com> Message-ID: On Thu, 31 Oct 2024 21:50:50 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision: > > - add comment to ThreadService::find_deadlocks_at_safepoint > - Remove assignments in preempt_kind enum src/hotspot/share/oops/stackChunkOop.cpp line 445: > 443: > 444: void stackChunkOopDesc::transfer_lockstack(oop* dst) { > 445: const bool requires_gc_barriers = is_gc_mode() || requires_barriers(); Given how careful we are in `Thaw` to not call `requires_barriers()` twice and use `_barriers` instead it would probably be nicer to pass in `_barriers` as a bool. There is only one other place we do the extra call and it is in `fix_thawed_frame`, but that only happens after we are committed to the slow path, so it might be nice for completeness, but should be negligible for performance. Here however we might still be in our new "medium" path where we could still do a fast thaw. src/hotspot/share/oops/stackChunkOop.cpp line 460: > 458: } else { > 459: oop value = *reinterpret_cast(at); > 460: HeapAccess<>::oop_store(reinterpret_cast(at), nullptr); Using HeapAccess when `!requires_gc_barriers` is wrong. This would crash with ZGC when/if we fix the flags race and changed `relativize_chunk_concurrently` to only be conditioned `requires_barriers() / _barriers` (and allowing the retry_fast_path "medium" path). So either use `*reinterpret_cast(at) = nullptr;` or do what my initial suggestion with `clear_lockstack` did, just omit the clearing. Before we requires_barriers(), we are allowed to reuse the stackChuncks, so trying to clean them up seems fruitless. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825949756 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825942254 From jbechberger at openjdk.org Fri Nov 1 15:44:43 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Fri, 1 Nov 2024 15:44:43 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 14:22:47 GMT, Markus Gr?nlund wrote: >> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove min_valid_free_size_bytes > > src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 116: > >> 114: return false; >> 115: } >> 116: const traceid mid = JfrTraceId::load(frame._method); > > This is JfrTraceId::load() barrier code: > > inline traceid JfrTraceIdLoadBarrier::load(const Klass* klass, const Method* method) { > assert(klass != nullptr, "invariant"); > assert(method != nullptr, "invariant"); > if (should_tag(method)) { > SET_METHOD_AND_CLASS_USED_THIS_EPOCH(klass); > SET_METHOD_FLAG_USED_THIS_EPOCH(method); > assert(METHOD_AND_CLASS_USED_THIS_EPOCH(klass), "invariant"); > assert(METHOD_FLAG_USED_THIS_EPOCH(method), "invariant"); > enqueue(klass); > JfrTraceIdEpoch::set_changed_tag_state(); > } > return (METHOD_ID(klass, method)); > } > > What happens if the sampler crashes at one of these routines? > > 1. Sets bits in the Klass, but not in the Method, and does not enqueue? > 2. Set bits in the Klass and Method, but does not enqueue? > 3. Sets bits in Klass, Method and enqueues, but does not notify? That's a really good point. FYI: Today is a bank holiday in Germany, so I don't work on the PR today, but it'll be my main focus in the following weeks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1825971924 From ihse at openjdk.org Fri Nov 1 15:46:56 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 1 Nov 2024 15:46:56 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v16] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: No need to check for LP64 inside a #ifdef _WINDOWS anymore ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/0fff0971..fe8ba082 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=14-15 Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Fri Nov 1 15:46:57 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 1 Nov 2024 15:46:57 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v15] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 30 Oct 2024 19:53:27 GMT, Vladimir Kozlov wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Error in os_windows.cpp for unknown cpu > > `grep -i win32 -r src/hotspot/share/` shows several places missed in these changes @vnkozlov > There is useless code in src/hotspot/cpu//x86/interpreterRT_x86_32.cpp which is guarded by #ifdef AMD64 which is false for 32-bit. Yes; this has been discussed above. Aleksey opened https://bugs.openjdk.org/browse/JDK-8343167 to solve that separately, since it is not Windows 32-bit specific. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452093887 From ihse at openjdk.org Fri Nov 1 15:55:39 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 1 Nov 2024 15:55:39 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v15] In-Reply-To: <76biejW3S4MlZgDqNgarB8X1Fg_r1nnquUs5YvpeyYU=.663fe887-f273-4159-bb7f-89fad204eb28@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <76biejW3S4MlZgDqNgarB8X1Fg_r1nnquUs5YvpeyYU=.663fe887-f273-4159-bb7f-89fad204eb28@github.com> Message-ID: On Wed, 30 Oct 2024 19:37:47 GMT, Vladimir Kozlov wrote: > Bug in macroAssembler_x86.cpp - should be _WINDOWS So what does that mean? That the code is currently broken and is incorrectly included on Windows? If so, it should be fixed in a separate PR. Or is it just a stylistic issue, that both `_WINDOWS` and `WINDOWS` are defined when building hotspot on Windows, but the rule is to stick to `_WINDOWS`? If so, I can sneak in a fix for it here, even if it is not really part of the x86 removal. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452112264 From ihse at openjdk.org Fri Nov 1 16:04:55 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 1 Nov 2024 16:04:55 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v15] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 30 Oct 2024 19:53:27 GMT, Vladimir Kozlov wrote: > `grep -i win32 -r src/hotspot/share/` shows several places missed in these changes I'm actually not sure which places you refer to here. Can you be more specific? (Note that, oddly enough, `_WIN32` is still defined on 64-bit Windows, Microsoft considers "win32" to be the general name of the Windows API.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452127151 From ihse at openjdk.org Fri Nov 1 16:04:55 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 1 Nov 2024 16:04:55 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers - Remove windows-32-bit code in CompilerConfig::ergo_initialize ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/fe8ba082..68d6fe5a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=15-16 Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Fri Nov 1 16:11:31 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 1 Nov 2024 16:11:31 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v8] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: <0SV1CZsC4-4qlECRdXAsTtfA4SFMOizXH2pZqYggJtM=.d69355b4-ac64-4a9a-836e-957085f04b09@github.com> On Tue, 29 Oct 2024 20:43:16 GMT, Magnus Ihse Bursie wrote: >> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. >> >> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. >> >> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix bug in filtering out -Wl,--exclude-libs,ALL I finally noticed that you are testing a precompiled HelloWorld class, and I have been running with a source file argument to have java compile it on the fly. When I try using a pre-compiled HelloWorld, the linux port works for me too. @jianglizhou Can you please verify if you can run this with a .java file directly? To be clear: this works fine on my mac with this PR, and (as I said), I'm pretty certain it used to work at least at some point during development on this PR. ihse at sthihse:/localhome/git/jdk-ALT$ cat > HelloWorld.java public class HelloWorld { public static void main(String[] args) { System.out.println("Hello, world!"); } } ihse at sthihse:/localhome/git/jdk-ALT$ javac HelloWorld.java ihse at sthihse:/localhome/git/jdk-ALT$ ./build/linux-x64/images/static-jdk/bin/java HelloWorld Hello, world! ihse at sthihse:/localhome/git/jdk-ALT$ ./build/linux-x64/images/static-jdk/bin/java HelloWorld.java Error: Unable to load main class com.sun.tools.javac.launcher.SourceLauncher in module jdk.compiler Caused by: java.lang.UnsatisfiedLinkError: no jimage in system library path: /localhome/git/jdk-ALT/build/linux-x64/images/static-jdk/bin Runtime.exit(1) logging failed: Could not initialize class jdk.internal.module.SystemModuleFinders$SystemImage ihse at sthihse:/localhome/git/jdk-ALT$ ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2452139764 From ihse at openjdk.org Fri Nov 1 16:15:31 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 1 Nov 2024 16:15:31 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v8] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Tue, 29 Oct 2024 20:43:16 GMT, Magnus Ihse Bursie wrote: >> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. >> >> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. >> >> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix bug in filtering out -Wl,--exclude-libs,ALL My (private) criteria here have been to get a fix to the build system that can run "hello world" -- I realize that the initial implementation of a static java launcher is likely to have additional bugs that needs fixing before it can pass a similar set of JTreg tests as the normal launcher (let alone the JCK). So running HelloWorld.class perhaps *technically* passes this barrier, but I think that if not the source code launching works, then it is almost as bad as if not HelloWorld.class works, so I would still consider that an integration blocker for this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2452144818 From ihse at openjdk.org Fri Nov 1 16:25:59 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 1 Nov 2024 16:25:59 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v9] In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). Magnus Ihse Bursie 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 'master' into static-jdk-image - Fix bug in filtering out -Wl,--exclude-libs,ALL - Don't hardcode server variant - Setup LDFLAGS_STATIC_JDK - Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check - Add lookup asserts - Remove superfluous SRC. - Merge branch 'master' into static-jdk-image - Makefile changes needed for static-launcher and static-jdk-image targets - Incorporate changes from leyden/hermetic-java-runtime that allows running a static launcher ------------- Changes: https://git.openjdk.org/jdk/pull/20837/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=08 Stats: 447 lines in 26 files changed: 367 ins; 5 del; 75 mod Patch: https://git.openjdk.org/jdk/pull/20837.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837 PR: https://git.openjdk.org/jdk/pull/20837 From ihse at openjdk.org Fri Nov 1 16:33:30 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 1 Nov 2024 16:33:30 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v7] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: <0q-xhL4V8lDNxWwXXhgHM-iMXuwd1bRbKxbZgLiL-MU=.c1c22ded-60ec-442c-85fb-4155c417b930@github.com> On Wed, 23 Oct 2024 08:23:34 GMT, Johan Vos wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't hardcode server variant > > I tried to build/run this on Linux as well (since I'm using parts of this PR in https://github.com/openjdk/mobile/pull/30) and I noticed that the executable doesn't start (even with --version): > > images/static-jdk/bin/java --version > Error: Failed , because images/static-jdk/bin/java: undefined symbol: JNI_CreateJavaVM > > The `JNI_CreateJavaVM` symbol seems to be local only: > > nm images/static-jdk/bin/java |grep JNI_CreateJ > 0000000000e22430 t JNI_CreateJavaVM > > Hence calling it with `dlsym` won't work. And indeed, that is how it is called from `./java.base/unix/native/libjli/java_md.c ` `(LoadJavaVM)` > > dlsym(libjvm, "JNI_CreateJavaVM"); > > > I noticed that the launcher is created using `-Wl,--export-dynamic ... -Wl,--whole-archive ... libjvm.a` > I checked `libjvm.a` and as expected, that contains a global symbol for JNI_CreateJavaVM: > > nm libjvm.a |grep JNI_CreateJavaVM > 0000000000000000 T JNI_CreateJavaVM > > If I remove the `-Wl,--export-dynamic` from the link options, the resulting executable has a global symbol for JNI_createJavaVM. However, in that case `dlsym` will clearly not work because the symbol is not added to the symbol table. > > This is maybe a stupid question, but I wonder though why `dlsym` is used here? > When doing this for iOS, I directly use the symbols (instead of searching for them using `dlsym`). We know for sure that this symbol is in the executable, as it is statically linked into it. @johanvos There is indeed no reason to use dlsym for a static build. Unfortunately, the code related to looking up symbols in JDK-internal libraries is still not up to par. It is scattered among several places, and each place is doing its own implementation. I was thinking that cleaning this up could be done as a follow-up, later on, but maybe it is necessary to take the bull by the horns and address all those places in this PR as well. Many of them are already touched by this PR anyway... ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2452177592 From ihse at openjdk.org Fri Nov 1 17:14:34 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 1 Nov 2024 17:14:34 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v9] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Fri, 1 Nov 2024 16:25:59 GMT, Magnus Ihse Bursie wrote: >> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. >> >> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. >> >> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). > > Magnus Ihse Bursie 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 'master' into static-jdk-image > - Fix bug in filtering out -Wl,--exclude-libs,ALL > - Don't hardcode server variant > - Setup LDFLAGS_STATIC_JDK > - Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check > - Add lookup asserts > - Remove superfluous SRC. > - Merge branch 'master' into static-jdk-image > - Makefile changes needed for static-launcher and static-jdk-image targets > - Incorporate changes from leyden/hermetic-java-runtime that allows running a static launcher I'm still not sure how or why this goes wrong on Linux (or why it manages to work on macOS!), but at least with this patch I get it to work on Linux: diff --git a/src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java b/src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java index 0e3b178c32b..54db79e6527 100644 --- a/src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java +++ b/src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java @@ -40,7 +40,7 @@ class NativeImageBuffer { new java.security.PrivilegedAction() { @SuppressWarnings("restricted") public Void run() { - System.loadLibrary("jimage"); + jdk.internal.loader.BootLoader.loadLibrary("jimage"); return null; } }); The problem here is that this file is also compiled as part of the jrtfs.jar, where `BootLoader` is not available, so I also had to do diff --git a/make/Main.gmk b/make/Main.gmk index 9fc5490a1ef..606dd215e72 100644 --- a/make/Main.gmk +++ b/make/Main.gmk @@ -1000,7 +1000,7 @@ else # When creating the BUILDJDK, we don't need to add hashes to java.base, thus # we don't need to depend on all other jmods ifneq ($(CREATING_BUILDJDK), true) - java.base-jmod: jrtfs-jar $(addsuffix -jmod, $(filter-out java.base, $(sort \ + java.base-jmod: $(addsuffix -jmod, $(filter-out java.base, $(sort \ $(foreach m, $(filter-out $(call FindAllUpgradeableModules), $(JMOD_MODULES)), \ $m $(call FindTransitiveDepsForModules, $m) \ )))) to be able to compile this. But this seems to be the wrong approach. `System.loadLibrary("jimage")` should be able to figure out that an internal, statically-linked, library is being requested. Or at least, I guess that is a reasonable approach? I searched for `System.loadLibrary` and we're doing that a lot to connect to our internal native libraries. (One alternative approach would have been that the JDK should have a separate way to load its own internal libraries, that is not exposed to user code. I was honestly a bit surprised to find out that this is not the case.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2452258062 From coleenp at openjdk.org Fri Nov 1 17:27:33 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 1 Nov 2024 17:27:33 GMT Subject: RFR: 8343218: Disable allocating interface and abstract classes in non-class metaspace [v2] In-Reply-To: <7Z-FvvKjDqia20mBFSRgN-od2FEM89D2U3VfyC--BJk=.4438af6e-cc45-40d2-8533-7bd359cebba8@github.com> References: <7Z-FvvKjDqia20mBFSRgN-od2FEM89D2U3VfyC--BJk=.4438af6e-cc45-40d2-8533-7bd359cebba8@github.com> Message-ID: On Wed, 30 Oct 2024 12:03:43 GMT, Coleen Phillimore wrote: >> Change the code to allocate all Klasses to class-metaspace until c2 dependencies are understood and fixed, and more urgent need arises when compressing klass pointers to smaller numbers of bits. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/oops/instanceKlass.cpp > > Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> I don't see any evidence of c1 unsafely assuming that a Klass pointer can be encoded and decoded. Since the parent CR for this bug is being fixed to add asserts for safety in C2 [JDK-8343206](https://bugs.openjdk.org/browse/JDK-8343206), I'm closing this as WNF. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21769#issuecomment-2452277358 From coleenp at openjdk.org Fri Nov 1 17:27:35 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 1 Nov 2024 17:27:35 GMT Subject: Withdrawn: 8343218: Disable allocating interface and abstract classes in non-class metaspace In-Reply-To: References: Message-ID: On Tue, 29 Oct 2024 17:15:44 GMT, Coleen Phillimore wrote: > Change the code to allocate all Klasses to class-metaspace until c2 dependencies are understood and fixed, and more urgent need arises when compressing klass pointers to smaller numbers of bits. > Tested with tier1-4. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/21769 From kvn at openjdk.org Fri Nov 1 17:55:41 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 1 Nov 2024 17:55:41 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v15] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <76biejW3S4MlZgDqNgarB8X1Fg_r1nnquUs5YvpeyYU=.663fe887-f273-4159-bb7f-89fad204eb28@github.com> Message-ID: On Fri, 1 Nov 2024 15:52:50 GMT, Magnus Ihse Bursie wrote: > > Bug in macroAssembler_x86.cpp - should be _WINDOWS > > So what does that mean? That the code is currently broken and is incorrectly included on Windows? If so, it should be fixed in a separate PR. Or is it just a stylistic issue, that both `_WINDOWS` and `WINDOWS` are defined when building hotspot on Windows, but the rule is to stick to `_WINDOWS`? If so, I can sneak in a fix for it here, even if it is not really part of the x86 removal. I think `WINDOWS` is not defined in our build macros. I filed https://bugs.openjdk.org/browse/JDK-8343452 to fix it and backport. > > `grep -i win32 -r src/hotspot/share/` shows several places missed in these changes > > I'm actually not sure which places you refer to here. Can you be more specific? > > (Note that, oddly enough, `_WIN32` is still defined on 64-bit Windows, Microsoft considers "win32" to be the general name of the Windows API.) % grep -i win32 -r src/hotspot/share/ src/hotspot/share//c1/c1_Compiler.cpp: // compilation seems to be too expensive (at least on Intel win32). src/hotspot/share//runtime/globals.hpp: "Using high time resolution (for Win32 only)") \ src/hotspot/share//runtime/globals.hpp: "Bypass Win32 file system criteria checks (Windows Only)") \ src/hotspot/share//runtime/globals.hpp: "Unguard page and retry on no-execute fault (Win32 only) " \ src/hotspot/share//runtime/javaCalls.cpp: // This is used for e.g. Win32 structured exception handlers. src/hotspot/share//runtime/safefetch.hpp:#ifdef _WIN32 src/hotspot/share//runtime/os.hpp: class win32; src/hotspot/share//runtime/vmStructs.cpp: /* unsigned short on Win32 */ \ src/hotspot/share//runtime/vmStructs.cpp: // Win32, we can put this back in. src/hotspot/share//runtime/park.cpp:// Native TLS (Win32/Linux/Solaris) can only be initialized or src/hotspot/share//runtime/sharedRuntimeTrans.cpp:// by roughly 15% on both Win32/x86 and Solaris/SPARC. src/hotspot/share//runtime/sharedRuntimeTrans.cpp:#ifdef WIN32 src/hotspot/share//runtime/sharedRuntimeTrans.cpp:#ifdef WIN32 src/hotspot/share//prims/jvmti.xml: example, in the Java 2 SDK a CTRL-Break on Win32 and a CTRL-\ on Linux src/hotspot/share//prims/jni.cpp:#if defined(_WIN32) && !defined(USE_VECTORED_EXCEPTION_HANDLING) src/hotspot/share//prims/jni.cpp:#if defined(_WIN32) && !defined(USE_VECTORED_EXCEPTION_HANDLING) src/hotspot/share//prims/jni.cpp:#if defined(_WIN32) && !defined(USE_VECTORED_EXCEPTION_HANDLING) src/hotspot/share//prims/jni.cpp:#if defined(_WIN32) && !defined(USE_VECTORED_EXCEPTION_HANDLING) src/hotspot/share//prims/jni.cpp:#if defined(_WIN32) && !defined(USE_VECTORED_EXCEPTION_HANDLING) src/hotspot/share//classfile/javaClasses.cpp:#if defined(_WIN32) && !defined(_WIN64) src/hotspot/share//classfile/compactHashtable.cpp:#ifndef O_BINARY // if defined (Win32) use binary files. src/hotspot/share//cds/filemap.cpp:#ifndef O_BINARY // if defined (Win32) use binary files. src/hotspot/share//utilities/vmError.cpp:#ifndef _WIN32 src/hotspot/share//adlc/adlc.hpp:#ifdef _WIN32 src/hotspot/share//adlc/adlc.hpp:#endif // _WIN32 src/hotspot/share//adlc/main.cpp:#if !defined(_WIN32) || defined(_WIN64) src/hotspot/share//compiler/disassembler.cpp:#ifdef _WIN32 ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452318589 PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452322471 From kvn at openjdk.org Fri Nov 1 18:04:44 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 1 Nov 2024 18:04:44 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize 1. There is use of `WIN32` instead of `_WIN32`. 2. There are comments referencing `Win32` which we need to rename to `Windows` to avoid confusion. 3. There is `class os::win32` in `os_windows.hpp` which is batter to rename to avoid confusion. Could be done in separate RFE. 4. "Note that, oddly enough, _WIN32 is still defined on 64-bit Windows". If it is really true, I would still suggest to use our variable `_WINDOWS` for that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452335968 From kvn at openjdk.org Fri Nov 1 18:13:58 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 1 Nov 2024 18:13:58 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize Okay, I am confuse about `_WIN32` vs `WIN32`. You are saying that "_WIN32 is still defined on 64-bit Windows" but you are removing code guarded by `#ifdef _WIN32` And our make files defines `WIN32` for all Windows OSs: https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L470 ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452349567 From pchilanomate at openjdk.org Fri Nov 1 18:19:20 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 1 Nov 2024 18:19:20 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v26] In-Reply-To: References: Message-ID: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits: - Fix comments for David - Add comment in X509TrustManagerImpl.java - Remove oop clearing in transfer_lockstack + pass _barriers as argument - Merge branch 'master' into JDK-8338383 - add comment to ThreadService::find_deadlocks_at_safepoint - Remove assignments in preempt_kind enum - Remove redundant assert in ObjectMonitor::VThreadEpilog - Comment in FreezeBase::recurse_freeze + renames in continuation.hpp - Explicitly pass tmp register to inc/dec_held_monitor_count + use static const in clobber_nonvolatile_registers - Use frame::sender_sp_offset in continuationFreezeThaw_riscv.inline.hpp - ... and 51 more: https://git.openjdk.org/jdk/compare/751a914b...113fb3d3 ------------- Changes: https://git.openjdk.org/jdk/pull/21565/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=25 Stats: 9506 lines in 242 files changed: 6936 ins; 1424 del; 1146 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From pchilanomate at openjdk.org Fri Nov 1 18:19:21 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 1 Nov 2024 18:19:21 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v25] In-Reply-To: References: <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com> Message-ID: On Fri, 1 Nov 2024 15:21:50 GMT, Axel Boldt-Christmas wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision: >> >> - add comment to ThreadService::find_deadlocks_at_safepoint >> - Remove assignments in preempt_kind enum > > src/hotspot/share/oops/stackChunkOop.cpp line 445: > >> 443: >> 444: void stackChunkOopDesc::transfer_lockstack(oop* dst) { >> 445: const bool requires_gc_barriers = is_gc_mode() || requires_barriers(); > > Given how careful we are in `Thaw` to not call `requires_barriers()` twice and use `_barriers` instead it would probably be nicer to pass in `_barriers` as a bool. > > There is only one other place we do the extra call and it is in `fix_thawed_frame`, but that only happens after we are committed to the slow path, so it might be nice for completeness, but should be negligible for performance. Here however we might still be in our new "medium" path where we could still do a fast thaw. Good, passed as argument now. > src/hotspot/share/oops/stackChunkOop.cpp line 460: > >> 458: } else { >> 459: oop value = *reinterpret_cast(at); >> 460: HeapAccess<>::oop_store(reinterpret_cast(at), nullptr); > > Using HeapAccess when `!requires_gc_barriers` is wrong. This would crash with ZGC when/if we fix the flags race and changed `relativize_chunk_concurrently` to only be conditioned `requires_barriers() / _barriers` (and allowing the retry_fast_path "medium" path). > So either use `*reinterpret_cast(at) = nullptr;` or do what my initial suggestion with `clear_lockstack` did, just omit the clearing. Before we requires_barriers(), we are allowed to reuse the stackChuncks, so trying to clean them up seems fruitless. Ok, I just omitted clearing the oop. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826149674 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826148888 From pchilanomate at openjdk.org Fri Nov 1 18:24:52 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 1 Nov 2024 18:24:52 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v25] In-Reply-To: References: <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com> Message-ID: On Fri, 1 Nov 2024 01:53:01 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision: >> >> - add comment to ThreadService::find_deadlocks_at_safepoint >> - Remove assignments in preempt_kind enum > > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889: > >> 887: return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller); >> 888: } else { >> 889: // frame can't be freezed. Most likely the call_stub or upcall_stub > > Suggestion: > > // Frame can't be frozen. Most likely the call_stub or upcall_stub Fixed. > src/hotspot/share/services/threadService.cpp line 467: > >> 465: if (waitingToLockMonitor->has_owner()) { >> 466: currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor); >> 467: // If currentThread is nullptr we would like to know if the owner > > Suggestion: > > // If currentThread is null we would like to know if the owner Fixed. > src/hotspot/share/services/threadService.cpp line 474: > >> 472: // vthread we never record this as a deadlock. Note: unless there >> 473: // is a bug in the VM, or a thread exits without releasing monitors >> 474: // acquired through JNI, nullptr should imply unmounted vthread owner. > > Suggestion: > > // acquired through JNI, null should imply an unmounted vthread owner. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826154797 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826155159 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826155815 From pchilanomate at openjdk.org Fri Nov 1 18:24:53 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 1 Nov 2024 18:24:53 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v22] In-Reply-To: References: <0C6Y-BWqBlPx6UG8W9NS6TsDuAEmZya4dqtY8E8ymX4=.c45ec952-7387-4ce8-aa5a-f294347f0555@github.com> Message-ID: On Thu, 31 Oct 2024 20:28:06 GMT, Alan Bateman wrote: >> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 57: >> >>> 55: static { >>> 56: try { >>> 57: MethodHandles.lookup().ensureInitialized(AnchorCertificates.class); >> >> Why is this needed? A comment would help. > > That's probably a good idea. It?s caused by pinning due to the sun.security.util.AnchorCertificates?s class initializer, some of the http client tests are running into this. Once monitors are out of the way then class initializers, both executing, and waiting for, will be a priority. Added comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826153929 From pchilanomate at openjdk.org Fri Nov 1 18:29:49 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 1 Nov 2024 18:29:49 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v7] In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 09:19:48 GMT, Alan Bateman wrote: >> Thanks for the explanation but that needs to be documented somewhere. > > The comment in afterYield has been expanded in the loom repo, we may be able to bring that update in. Brought the comment from the loom repo. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826160691 From prr at openjdk.org Fri Nov 1 18:46:57 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 1 Nov 2024 18:46:57 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: <5uPCX6VhNrAelasUotfss6G7iKyAHcyz7Fq2WiB8oZI=.db06929c-b219-4969-853f-9f68549723b3@github.com> On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize make/modules/jdk.accessibility/Lib.gmk line 57: > 55: TARGETS += $(BUILD_LIBJAVAACCESSBRIDGE) > 56: > 57: ############################################################################## Most of the desktop related changes are related to Assistive Technologies I don't think we currently provide a 32-bit windowsaccessbridge.dll in the 64 bit JDK, but I'd like to be sure I am not forgetting something. The point being windowsaccessbridge.dll is not loaded by the JDK, but by an AT, so traditionally we provided both 32 and 64 bit versions because we don't control that AT. So I would like Alex Zuev to review these changes. For whatever reason his git hub handle doesn't seem to be found. I think it is something like @azuev-java ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1826177047 From pchilanomate at openjdk.org Fri Nov 1 18:47:23 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 1 Nov 2024 18:47:23 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v27] In-Reply-To: References: Message-ID: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Revert fixes after 8343132 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21565/files - new: https://git.openjdk.org/jdk/pull/21565/files/113fb3d3..33eb6388 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=25-26 Stats: 22 lines in 3 files changed: 0 ins; 17 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From aivanov at openjdk.org Fri Nov 1 19:17:12 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 1 Nov 2024 19:17:12 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6] In-Reply-To: References: Message-ID: <5_m66jOr6E-qHq5r9AHGX-Yb5IKCT_VbHGmq_Yh8v34=.172e81bb-9281-4364-a8cb-3696c5ef4b36@github.com> On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits: > > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Modify three RMI tests to work without the security manager: > - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java > - test/jdk/java/rmi/registry/readTest/CodebaseTest.java > - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java > Also remove them from the problem list. > - Remove two obsolete RMI tests: > - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java > - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java > Adjust two tests to run without the Security Manager: > - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java > - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java > Remove all of these tests from the problem list. > - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows. > - Added API Notes to ProtectionDomain clarifying that the current policy always > grants no permissions. A few other small changes to Policy and PD. > - Merge branch 'master' into jep486 > - JAXP tests: organize imports of a few tests > - Improve description of Executors.privilegedThreadFactory > - rename TestAppletLoggerContext.java as suggested in util test review > - clientlibs: Javadoc cleanup > - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b I looked through the updates to `java.desktop` module and to tests under `java/awt`, `javax/sound`, `javax/swing`. Looks good. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2410517684 From aivanov at openjdk.org Fri Nov 1 19:17:12 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 1 Nov 2024 19:17:12 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3] In-Reply-To: References: Message-ID: On Thu, 24 Oct 2024 20:57:50 GMT, Sean Mullan wrote: >> @honkar-jdk I'm inclined to leave it as because it's not the only method which doesn't have a blank line between `@param` and `@throw` in this file. >> >> If it's worth taking care of, we may submit another bug to address it later. > > This does not need to be handled in this PR. In the majority of changes, we have really tried hard to avoid making unrelated changes, but sometimes a few snuck in, like moving package imports or perhaps fixing a typo here and there that was not specific to JEP 486. My opinion is that unless it is something that _really_ should be done as part of a more general technical debt or code cleanup exercise, then it is ok to let a few of these in and they don't have to be reverted. > > Can we add a blank line here? It's present in the methods above. > > > > Although there are other places below where it's missing; _so not worth worrying_. > > ? it's not the only method which doesn't have a blank line between `@param` and `@throw` in this file. > > If it's worth taking care of, we may submit another bug to address it later. I've submitted [JDK-8343448](https://bugs.openjdk.org/browse/JDK-8343448): _Improve formatting of docs in java.awt.Desktop_. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826079117 From aivanov at openjdk.org Fri Nov 1 19:17:12 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 1 Nov 2024 19:17:12 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3] In-Reply-To: <9rJh272Zem3qiduMHS7u3Jx1zkOjtQknwHnp-TkHq-I=.9e7b31e3-df12-4990-81e5-4e88f136b65a@github.com> References: <9rJh272Zem3qiduMHS7u3Jx1zkOjtQknwHnp-TkHq-I=.9e7b31e3-df12-4990-81e5-4e88f136b65a@github.com> Message-ID: On Mon, 28 Oct 2024 14:08:46 GMT, Sean Mullan wrote: >> src/java.desktop/share/classes/java/awt/Font.java line 1612: >> >>> 1610: * obtained. The {@code String} value of this property is then >>> 1611: * interpreted as a {@code Font} object according to the >>> 1612: * specification of {@code Font.decode(String)} >> >> Suggestion: >> >> * specification of {@code Font.decode(String)}. >> >> Period is missing. > > Not part of this change, can be fixed later as a follow-on cleanup. I've submitted [JDK-8343446](https://bugs.openjdk.org/browse/JDK-8343446): _Add missing periods in docs for java.awt.Font_. >> src/java.desktop/share/classes/java/awt/Font.java line 1780: >> >>> 1778: *

>>> 1779: * The property value should be one of the forms accepted by >>> 1780: * {@code Font.decode(String)} >> >> Suggestion: >> >> * {@code Font.decode(String)}. >> >> Period is missing. > > Not part of this change, can be fixed later as a follow-on cleanup. Deferred to [JDK-8343446](https://bugs.openjdk.org/browse/JDK-8343446). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826080609 PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826081342 From aivanov at openjdk.org Fri Nov 1 19:17:12 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 1 Nov 2024 19:17:12 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3] In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 18:07:26 GMT, Harshitha Onkar wrote: >> I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used. >> But I don't see a problem with keeping the rest of the test. > > Test updated in sandbox - https://github.com/openjdk/jdk-sandbox/commit/9eb275c4aaf9a88127c5c33e0bf7ca35125f29ea > I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used. But I don't see a problem with keeping the rest of the test. @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`? The [`MultiUIDefaults` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java) is used in `UIManager`: https://github.com/openjdk/jdk/blob/c82ad845e101bf5d97c0744377d68002907d4a0e/src/java.desktop/share/classes/javax/swing/UIManager.java#L198 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826141057 From pchilanomate at openjdk.org Fri Nov 1 19:37:14 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 1 Nov 2024 19:37:14 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28] In-Reply-To: References: Message-ID: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Use lazySubmitRunContinuation when blocking ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21565/files - new: https://git.openjdk.org/jdk/pull/21565/files/33eb6388..52c26642 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=26-27 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From aivanov at openjdk.org Fri Nov 1 19:43:18 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 1 Nov 2024 19:43:18 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6] In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits: > > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Modify three RMI tests to work without the security manager: > - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java > - test/jdk/java/rmi/registry/readTest/CodebaseTest.java > - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java > Also remove them from the problem list. > - Remove two obsolete RMI tests: > - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java > - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java > Adjust two tests to run without the Security Manager: > - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java > - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java > Remove all of these tests from the problem list. > - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows. > - Added API Notes to ProtectionDomain clarifying that the current policy always > grants no permissions. A few other small changes to Policy and PD. > - Merge branch 'master' into jep486 > - JAXP tests: organize imports of a few tests > - Improve description of Executors.privilegedThreadFactory > - rename TestAppletLoggerContext.java as suggested in util test review > - clientlibs: Javadoc cleanup > - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b test/jdk/javax/sound/midi/Soundbanks/EmptySoundBankTest.java line 1: > 1: /* I wonder if we should add an Oracle copyright to the update test file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826228675 From aivanov at openjdk.org Fri Nov 1 19:43:18 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 1 Nov 2024 19:43:18 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3] In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 14:35:57 GMT, Sean Mullan wrote: >> That and possibly rename the test because now it does not have anything to do with the SecurityException. Now we only check that providing an empty file causes the InvalidMidiDataException so EmptySoundBankTest or something to that extent would be a better name. > > Fixed in https://github.com/openjdk/jdk/pull/21498/commits/934e1c28f783b32c43e6977f0e1ba6e1c68f810f Thank you for clarification. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826225216 From dlong at openjdk.org Fri Nov 1 20:11:50 2024 From: dlong at openjdk.org (Dean Long) Date: Fri, 1 Nov 2024 20:11:50 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v12] In-Reply-To: References: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com> Message-ID: On Fri, 1 Nov 2024 07:14:35 GMT, Dean Long wrote: >>> OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed? >>> >> It's not a bug, it's just that the code from the runtime stub only cares about the actual rsp, not last_Java_sp. We are returning to the pc right after the call so we need to adjust rsp to what the runtime stub expects. Both alternatives will work, either changing the runtime stub to set last pc and not push those two extra words, or your suggestion of just setting the last pc to the instruction after the adjustment. Either way it requires to change the c2 code though which I'm not familiar with. But if you can provide a patch I'm happy to apply it and we can remove this `possibly_adjust_frame()` method. > > It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes. Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative. Here's my suggested C2 change: diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad index d9c77a2f529..1e99db191ae 100644 --- a/src/hotspot/cpu/aarch64/aarch64.ad +++ b/src/hotspot/cpu/aarch64/aarch64.ad @@ -3692,14 +3692,13 @@ encode %{ __ post_call_nop(); } else { Label retaddr; + // Make the anchor frame walkable __ adr(rscratch2, retaddr); + __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset())); __ lea(rscratch1, RuntimeAddress(entry)); - // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc() - __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize))); __ blr(rscratch1); __ bind(retaddr); __ post_call_nop(); - __ add(sp, sp, 2 * wordSize); } if (Compile::current()->max_vector_size() > 0) { __ reinitialize_ptrue(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826252551 From dlong at openjdk.org Fri Nov 1 20:30:51 2024 From: dlong at openjdk.org (Dean Long) Date: Fri, 1 Nov 2024 20:30:51 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Use lazySubmitRunContinuation when blocking Marked as reviewed by dlong (Reviewer). I finished looking at this, and it looks good. Nice work! ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2410825883 PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2452534349 From aivanov at openjdk.org Fri Nov 1 20:31:37 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 1 Nov 2024 20:31:37 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6] In-Reply-To: References: Message-ID: On Tue, 29 Oct 2024 12:56:25 GMT, Sean Mullan wrote: >> test/jdk/javax/xml/crypto/dsig/keyinfo/KeyInfo/Marshal.java line 30: >> >>> 28: * @modules java.xml.crypto/org.jcp.xml.dsig.internal.dom >>> 29: * @compile -XDignore.symbol.file Marshal.java >>> 30: * @run main/othervm/java.security.policy==test.policy Marshal >> >> With this change, the test now only compiles but doesn't run the test. It could be a bug in jtreg since it is supposed to default to running the test as "run main " when there is no @run tag. In any case, the @compile line is no longer necessary, so I will remove that, and then the test will be run again. >> >> Also, missing a copyright update, will fix. > > Fixed in https://github.com/openjdk/jdk/pull/21498/commits/548eb9e2eb3f586bbb620d5357fe3e5665aeb505 > With this change, the test now only compiles but doesn't run the test. It could be a bug in jtreg since it is supposed to default to running the test as "run main " when there is no @run tag. In any case, the @compile line is no longer necessary, so I will remove that, and then the test will be run again. I guess it's the intended behaviour, jtreg implies `@run` if there are no other commands; you have to provide `@run` explicitly if there are `@compile` or `@build` tags. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826256418 From fbredberg at openjdk.org Fri Nov 1 20:59:49 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Fri, 1 Nov 2024 20:59:49 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Use lazySubmitRunContinuation when blocking I'm done reviewing this piece of good-looking code, and I really enjoyed it. Thanks! ------------- Marked as reviewed by fbredberg (Committer). PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2410872086 From kbarrett at openjdk.org Fri Nov 1 22:10:40 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 1 Nov 2024 22:10:40 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: <0AP1wOF-MdqLdSNofINZ2JTL4nnIdVFRsZpZ1LT7oHY=.e1bb41e9-b0f4-4157-9d78-d5b819c5c1d9@github.com> On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize Looks good, subject to addressing @vnkozlov comments. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2410940653 From jiangli at openjdk.org Fri Nov 1 22:27:30 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 1 Nov 2024 22:27:30 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v8] In-Reply-To: <0SV1CZsC4-4qlECRdXAsTtfA4SFMOizXH2pZqYggJtM=.d69355b4-ac64-4a9a-836e-957085f04b09@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> <0SV1CZsC4-4qlECRdXAsTtfA4SFMOizXH2pZqYggJtM=.d69355b4-ac64-4a9a-836e-957085f04b09@github.com> Message-ID: <-KTe_Kv55w9u0xR8YeEEHDYvYCv3YCUzc9EBac6jL4c=.13b8e842-a9e0-451e-b8c9-6519d9932d57@github.com> On Fri, 1 Nov 2024 16:09:20 GMT, Magnus Ihse Bursie wrote: > I finally noticed that you are testing a precompiled HelloWorld class, and I have been running with a source file argument to have java compile it on the fly. > > When I try using a pre-compiled HelloWorld, the linux port works for me too. > > @jianglizhou Can you please verify if you can run this with a .java file directly? To be clear: this works fine on my mac with this PR, and (as I said), I'm pretty certain it used to work at least at some point during development on this PR. > > ``` > ihse at sthihse:/localhome/git/jdk-ALT$ cat > HelloWorld.java > public class HelloWorld { > public static void main(String[] args) { > System.out.println("Hello, world!"); > } > } > ihse at sthihse:/localhome/git/jdk-ALT$ javac HelloWorld.java > ihse at sthihse:/localhome/git/jdk-ALT$ ./build/linux-x64/images/static-jdk/bin/java HelloWorld > Hello, world! > ihse at sthihse:/localhome/git/jdk-ALT$ ./build/linux-x64/images/static-jdk/bin/java HelloWorld.java > Error: Unable to load main class com.sun.tools.javac.launcher.SourceLauncher in module jdk.compiler > Caused by: java.lang.UnsatisfiedLinkError: no jimage in system library path: /localhome/git/jdk-ALT/build/linux-x64/images/static-jdk/bin > Runtime.exit(1) logging failed: Could not initialize class jdk.internal.module.SystemModuleFinders$SystemImage > ihse at sthihse:/localhome/git/jdk-ALT$ > ``` I can reproduce the issue with running a `.java` directly using static-jdk/bin/java built from your branch. The issue does not exist with the `bin/javastatic` built from https://github.com/openjdk/leyden/tree/hermetic-java-runtime (I just tested). I have a hunch of where is problem might be. I'll do some debugging. $ bin/java /usr/local/google/home/jianglizhou/tests/HelloWorld.java Error: Unable to load main class com.sun.tools.javac.launcher.SourceLauncher in module jdk.compiler Caused by: java.lang.UnsatisfiedLinkError: no jimage in system library path: /usr/local/google/home/jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/images/static-jdk/bin Runtime.exit(1) logging failed: Could not initialize class jdk.internal.module.SystemModuleFinders$SystemImage ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2452668656 From jiangli at openjdk.org Sat Nov 2 01:08:40 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Sat, 2 Nov 2024 01:08:40 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v8] In-Reply-To: <-KTe_Kv55w9u0xR8YeEEHDYvYCv3YCUzc9EBac6jL4c=.13b8e842-a9e0-451e-b8c9-6519d9932d57@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> <0SV1CZsC4-4qlECRdXAsTtfA4SFMOizXH2pZqYggJtM=.d69355b4-ac64-4a9a-836e-957085f04b09@github.com> <-KTe_Kv55w9u0xR8YeEEHDYvYCv3YCUzc9EBac6jL4c=.13b8e842-a9e0-451e-b8c9-6519d9932d57@github.com> Message-ID: On Fri, 1 Nov 2024 22:24:28 GMT, Jiangli Zhou wrote: > > I finally noticed that you are testing a precompiled HelloWorld class, and I have been running with a source file argument to have java compile it on the fly. > > When I try using a pre-compiled HelloWorld, the linux port works for me too. > > @jianglizhou Can you please verify if you can run this with a .java file directly? To be clear: this works fine on my mac with this PR, and (as I said), I'm pretty certain it used to work at least at some point during development on this PR. > > ``` > > ihse at sthihse:/localhome/git/jdk-ALT$ cat > HelloWorld.java > > public class HelloWorld { > > public static void main(String[] args) { > > System.out.println("Hello, world!"); > > } > > } > > ihse at sthihse:/localhome/git/jdk-ALT$ javac HelloWorld.java > > ihse at sthihse:/localhome/git/jdk-ALT$ ./build/linux-x64/images/static-jdk/bin/java HelloWorld > > Hello, world! > > ihse at sthihse:/localhome/git/jdk-ALT$ ./build/linux-x64/images/static-jdk/bin/java HelloWorld.java > > Error: Unable to load main class com.sun.tools.javac.launcher.SourceLauncher in module jdk.compiler > > Caused by: java.lang.UnsatisfiedLinkError: no jimage in system library path: /localhome/git/jdk-ALT/build/linux-x64/images/static-jdk/bin > > Runtime.exit(1) logging failed: Could not initialize class jdk.internal.module.SystemModuleFinders$SystemImage > > ihse at sthihse:/localhome/git/jdk-ALT$ > > ``` > > I can reproduce the issue with running a `.java` directly using static-jdk/bin/java built from your branch. The issue does not exist with the `bin/javastatic` built from https://github.com/openjdk/leyden/tree/hermetic-java-runtime (I just tested). I have a hunch of where is problem might be. I'll do some debugging. > > ``` > $ bin/java /usr/local/google/home/jianglizhou/tests/HelloWorld.java > Error: Unable to load main class com.sun.tools.javac.launcher.SourceLauncher in module jdk.compiler > Caused by: java.lang.UnsatisfiedLinkError: no jimage in system library path: /usr/local/google/home/jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/images/static-jdk/bin > Runtime.exit(1) logging failed: Could not initialize class jdk.internal.module.SystemModuleFinders$SystemImage > ``` Ok, I've found the cause. It's because `/static-jdk/bin` instead of `/static-jdk/lib` is set as the `_sun_boot_library_path` by `Arguments::set_dll_dir()`, during `os::init_system_properties_values()`. The path is retrieved via `StaticProperty.sunBootLibraryPath()` and used by `ClassLoader.loadLibrary()` to locate `jimage`. Hence the failure. Looking at why it only fails with running with `.java` but not with `.class`, a quick looks shows me that the following call path is only taken when running with `.java`: at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2410) at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:927) at java.base/java.lang.System.loadLibrary(System.java:2078) at java.base/jdk.internal.jimage.NativeImageBuffer$1.run(NativeImageBuffer.java:43) at java.base/jdk.internal.jimage.NativeImageBuffer$1.run(NativeImageBuffer.java:40) at java.base/java.security.AccessController.doPrivileged(AccessController.java:319) at java.base/jdk.internal.jimage.NativeImageBuffer.(NativeImageBuffer.java:39) at java.base/jdk.internal.jimage.BasicImageReader.(BasicImageReader.java:97) at java.base/jdk.internal.jimage.ImageReader$SharedImageReader.(ImageReader.java:229) at java.base/jdk.internal.jimage.ImageReader$SharedImageReader.open(ImageReader.java:243) at java.base/jdk.internal.jimage.ImageReader.open(ImageReader.java:67) at java.base/jdk.internal.jimage.ImageReader.open(ImageReader.java:71) at java.base/jdk.internal.jimage.ImageReaderFactory$1.apply(ImageReaderFactory.java:70) at java.base/jdk.internal.jimage.ImageReaderFactory$1.apply(ImageReaderFactory.java:67) at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1714) at java.base/jdk.internal.jimage.ImageReaderFactory.get(ImageReaderFactory.java:61) at java.base/jdk.internal.jimage.ImageReaderFactory.getImageReader(ImageReaderFactory.java:85) at java.base/jdk.internal.module.SystemModuleFinders$SystemImage.(SystemModuleFinders.java:385) at java.base/jdk.internal.module.SystemModuleFinders$SystemModuleReader.findImageLocation(SystemModuleFinders.java:429) at java.base/jdk.internal.module.SystemModuleFinders$SystemModuleReader.read(SystemModuleFinders.java:483) at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:809) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:741) at java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:621) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:640) at java.base/java.lang.Class.forName(Class.java:673) at java.base/java.lang.Class.forName(Class.java:648) at java.base/sun.launcher.LauncherHelper.loadModuleMainClass(LauncherHelper.java:798) at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:733) I'm going to look into a fix and update in this comment thread. While investigating, I also just found there a new issue in https://github.com/openjdk/leyden/tree/hermetic-java-runtime. Let's focus on resolving the `.java` run issue with your PR to make progress first. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2452777288 From fyang at openjdk.org Sat Nov 2 02:44:55 2024 From: fyang at openjdk.org (Fei Yang) Date: Sat, 2 Nov 2024 02:44:55 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v9] In-Reply-To: References: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com> <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com> Message-ID: On Thu, 31 Oct 2024 20:02:31 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273: >> >>> 271: ? frame_sp + fsize - frame::sender_sp_offset >>> 272: // we need to re-read fp because it may be an oop and we might have fixed the frame. >>> 273: : *(intptr_t**)(hf.sp() - 2); >> >> Suggestion: >> >> : *(intptr_t**)(hf.sp() - frame::sender_sp_offset); > > Changed. Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826453713 From fjiang at openjdk.org Sat Nov 2 04:00:35 2024 From: fjiang at openjdk.org (Feilong Jiang) Date: Sat, 2 Nov 2024 04:00:35 GMT Subject: RFR: 8343242: RISC-V: Refactor materialization of literal address [v2] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 01:10:11 GMT, Fei Yang wrote: >> Hi, please consider this refactoring work. >> >> Currently, we have both `la(address)` and `la(Address)`. They both accept and materialize literal address. >> While `la(Address)` always emit a movptr sequence, `la(address)` is a bit complex: it checks whether the target is >> reachable from anywhere within the code cache (`is_32bit_offset_from_codecache`) and emits pc-relative auipc+addi >> pair or movptr sequence. This makes it not that obvious at places where we want a more accurate estimation about >> the size of code emitted like when we prepare code stubs like C2SafepointPollStub or C2EntryBarrierStub (See: https://github.com/openjdk/jdk/pull/21732). >> >> I would suggest we keep `la(address)` simple and let it only emit auipc+addi pair, which will be consistent with the >> `RISC-V Assembly Programmer's Handbook`. I think It's more reasonable to move the distance check to `la(Address)`. >> Furthermore, I would also suggest that we make the distance check simpler. The approach taken here is to only check >> whether the target is inside the code cache. This way we will be more certain about code emitted with `la(Address)` >> as well. This will help keep the risk of this change low as all `la(Address)` callsites with literal address outside of code >> cache won't be affected. And I don't think the original distance check from code cache will benefit us much more. >> Eyeballed all `la(Address)` callsites, I think we are fine. >> >> Benefits: >> 1. We have a simpler `la(address)` which is kind of spec compatible; >> 2. We are consistent in target distance check when doing `j(Address)`, `la(Address)`, `ld/st(Address)` and `rt_call`; >> 3. We don't need explicit use of `relocate` with lambda for most of the places; >> >> Note that there are several places where we want explicit `movptr` sequence: >> 1. In `SignatureHandlerGenerator::generate()` where the emitted code is simply copied without relocation [1]; >> 2. In `movoop` and `mov_metadata` where we want patching afterwards; >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/interpreterRuntime.cpp#L1313 >> >> Testing on linux-riscv64: >> - [x] hotspot:tier1 (fastdebug) >> - [x] tier1-tier3, hotspot:tier4 (release) >> - [x] specjbb2015, dacapo, renaissance (release) > > Fei Yang 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 remote-tracking branch 'upstream/master' into JDK-8343242 > - 8343242: RISC-V: Refactor materialization of literal address It looks much cleaner now. Thank you! ------------- Marked as reviewed by fjiang (Committer). PR Review: https://git.openjdk.org/jdk/pull/21777#pullrequestreview-2411148918 From karianna at openjdk.org Sat Nov 2 04:04:35 2024 From: karianna at openjdk.org (Martijn Verburg) Date: Sat, 2 Nov 2024 04:04:35 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 01:17:01 GMT, Julian Waters wrote: > Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely Passing onto Microsoft's VM Engineering manager @brianjstafford - he'll find someone to take a look and advise. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2452847174 From sspitsyn at openjdk.org Sat Nov 2 04:53:56 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 2 Nov 2024 04:53:56 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Use lazySubmitRunContinuation when blocking src/hotspot/share/runtime/objectMonitor.cpp line 537: > 535: } > 536: } > 537: Just a question. It is not clear from scratch why the `Continuation::try_preempt()` is called before the `VThreadMonitorEnter()`. It would be nice to add a comment explaining it. It can be also good to explain how it works together in this order. Even a surface explanation of a general idea would be very helpful. A part of this already explained in the comment at lines 515-517. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826492850 From kizune at openjdk.org Sat Nov 2 07:53:44 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Sat, 2 Nov 2024 07:53:44 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <5uPCX6VhNrAelasUotfss6G7iKyAHcyz7Fq2WiB8oZI=.db06929c-b219-4969-853f-9f68549723b3@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> <5uPCX6VhNrAelasUotfss6G7iKyAHcyz7Fq2WiB8oZI=.db06929c-b219-4969-853f-9f68549723b3@github.com> Message-ID: On Fri, 1 Nov 2024 18:44:02 GMT, Phil Race wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers >> - Remove windows-32-bit code in CompilerConfig::ergo_initialize > > make/modules/jdk.accessibility/Lib.gmk line 57: > >> 55: TARGETS += $(BUILD_LIBJAVAACCESSBRIDGE) >> 56: >> 57: ############################################################################## > > Most of the desktop related changes are related to Assistive Technologies > I don't think we currently provide a 32-bit windowsaccessbridge.dll in the 64 bit JDK, but I'd like to be sure I am not forgetting something. > The point being windowsaccessbridge.dll is not loaded by the JDK, but by an AT, so traditionally we provided both 32 and 64 bit versions because we don't control that AT. > > So I would like Alex Zuev to review these changes. For whatever reason his git hub handle doesn't seem to be found. I think it is something like @azuev-java We built 32-bit dll in order to provide access to the accessibility interfaces for the legacy 32-bit software that can not load the 32-bit code. We abandoned this practice since at least Java 11 and we had no complaints about it ever since. All the relevant accessibility software we are aware of have 64-bit executable and only support 32-bit operating systems with the legacy versions that are not recommended to use with modern OSes. I do not see any problem in abandoning 32-bit code in windowsaccessbridge.dll. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1826520980 From gziemski at openjdk.org Sat Nov 2 14:48:01 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Sat, 2 Nov 2024 14:48:01 GMT Subject: RFR: 8328944: NMT reports "unknown" memory Message-ID: We use mtNone value in several functions default parameters, which may show up in NMT reports. We address this, by removing the default value and forcing, where possible, for the callers to declare NMT tag that reflects the usage. Eventually the goal would be not to use mtNone anywhere, but we are not there quite yet. TODO: update copyrights. Testing: undergoing MARCH5 tier1-5 ... ------------- Commit messages: - do not allow default parameter for mtNone Changes: https://git.openjdk.org/jdk/pull/21843/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21843&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8328944 Stats: 193 lines in 47 files changed: 23 ins; 1 del; 169 mod Patch: https://git.openjdk.org/jdk/pull/21843.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21843/head:pull/21843 PR: https://git.openjdk.org/jdk/pull/21843 From duke at openjdk.org Sat Nov 2 22:42:07 2024 From: duke at openjdk.org (ExE Boss) Date: Sat, 2 Nov 2024 22:42:07 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6] In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits: > > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Modify three RMI tests to work without the security manager: > - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java > - test/jdk/java/rmi/registry/readTest/CodebaseTest.java > - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java > Also remove them from the problem list. > - Remove two obsolete RMI tests: > - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java > - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java > Adjust two tests to run without the Security Manager: > - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java > - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java > Remove all of these tests from the problem list. > - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows. > - Added API Notes to ProtectionDomain clarifying that the current policy always > grants no permissions. A few other small changes to Policy and PD. > - Merge branch 'master' into jep486 > - JAXP tests: organize imports of a few tests > - Improve description of Executors.privilegedThreadFactory > - rename TestAppletLoggerContext.java as suggested in util test review > - clientlibs: Javadoc cleanup > - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b src/java.base/share/classes/java/lang/System.java line 1364: > 1362: *
> 1363: * It is the responsibility of the provider of > 1364: * the concrete {@code LoggerFinder} implementation to ensure that This is?still a?part of?the?paragraph related to?the?security?manager. src/java.base/share/classes/java/lang/System.java line 2338: > 2336: * Invoked by VM. Phase 3 is the final system initialization: > 2337: * 1. eagerly initialize bootstrap method factories that might interact > 2338: * negatively with custom security managers and custom class loaders They?might?still interact?negatively with?custom class?loaders?though. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826864120 PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826863295 From fyang at openjdk.org Sun Nov 3 02:51:11 2024 From: fyang at openjdk.org (Fei Yang) Date: Sun, 3 Nov 2024 02:51:11 GMT Subject: RFR: 8343471: RISC-V: compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java fails after JDK-8334999 Message-ID: Hi, please review this small change. The test expects a message like `warning: AES instructions are not available on this CPU` for all cpu platforms without AES support. After https://bugs.openjdk.org/browse/JDK-8334999, we report this `warning: AES intrinsics require Zvkn extension (not available on this CPU)` on RISC-V platforms where `Zvkn` extension is not available. Patch fixes this message making it consistent with other CPU platforms. Same test passes with this fix. ------------- Commit messages: - 8343471: RISC-V: compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java fails after JDK-8334999 Changes: https://git.openjdk.org/jdk/pull/21847/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21847&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343471 Stats: 19 lines in 1 file changed: 9 ins; 5 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21847.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21847/head:pull/21847 PR: https://git.openjdk.org/jdk/pull/21847 From jiangli at openjdk.org Sun Nov 3 05:08:34 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Sun, 3 Nov 2024 05:08:34 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v8] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> <0SV1CZsC4-4qlECRdXAsTtfA4SFMOizXH2pZqYggJtM=.d69355b4-ac64-4a9a-836e-957085f04b09@github.com> <-KTe_Kv55w9u0xR8YeEEHDYvYCv3YCUzc9EBac6jL4c=.13b8e842-a9e0-451e-b8c9-6519d9932d57@github.com> Message-ID: On Sat, 2 Nov 2024 01:05:27 GMT, Jiangli Zhou wrote: > > > I finally noticed that you are testing a precompiled HelloWorld class, and I have been running with a source file argument to have java compile it on the fly. > > > When I try using a pre-compiled HelloWorld, the linux port works for me too. > > > @jianglizhou Can you please verify if you can run this with a .java file directly? To be clear: this works fine on my mac with this PR, and (as I said), I'm pretty certain it used to work at least at some point during development on this PR. > > > ``` > > > ihse at sthihse:/localhome/git/jdk-ALT$ cat > HelloWorld.java > > > public class HelloWorld { > > > public static void main(String[] args) { > > > System.out.println("Hello, world!"); > > > } > > > } > > > ihse at sthihse:/localhome/git/jdk-ALT$ javac HelloWorld.java > > > ihse at sthihse:/localhome/git/jdk-ALT$ ./build/linux-x64/images/static-jdk/bin/java HelloWorld > > > Hello, world! > > > ihse at sthihse:/localhome/git/jdk-ALT$ ./build/linux-x64/images/static-jdk/bin/java HelloWorld.java > > > Error: Unable to load main class com.sun.tools.javac.launcher.SourceLauncher in module jdk.compiler > > > Caused by: java.lang.UnsatisfiedLinkError: no jimage in system library path: /localhome/git/jdk-ALT/build/linux-x64/images/static-jdk/bin > > > Runtime.exit(1) logging failed: Could not initialize class jdk.internal.module.SystemModuleFinders$SystemImage > > > ihse at sthihse:/localhome/git/jdk-ALT$ > > > ``` > > > > > > I can reproduce the issue with running a `.java` directly using static-jdk/bin/java built from your branch. The issue does not exist with the `bin/javastatic` built from https://github.com/openjdk/leyden/tree/hermetic-java-runtime (I just tested). I have a hunch of where is problem might be. I'll do some debugging. > > ``` > > $ bin/java /usr/local/google/home/jianglizhou/tests/HelloWorld.java > > Error: Unable to load main class com.sun.tools.javac.launcher.SourceLauncher in module jdk.compiler > > Caused by: java.lang.UnsatisfiedLinkError: no jimage in system library path: /usr/local/google/home/jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/images/static-jdk/bin > > Runtime.exit(1) logging failed: Could not initialize class jdk.internal.module.SystemModuleFinders$SystemImage > > ``` > > Ok, I've found the cause. It's because `/static-jdk/bin` instead of `/static-jdk/lib` is set as the `_sun_boot_library_path` by `Arguments::set_dll_dir()`, during `os::init_system_properties_values()`. The path is retrieved via `StaticProperty.sunBootLibraryPath()` and used by `ClassLoader.loadLibrary()` to locate `jimage`. Hence the failure. > > Looking at why it only fails with running with `.java` but not with `.class`, a quick looks shows me that the following call path is only taken when running with `.java`: > > ``` > at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2410) > at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:927) > at java.base/java.lang.System.loadLibrary(System.java:2078) > at java.base/jdk.internal.jimage.NativeImageBuffer$1.run(NativeImageBuffer.java:43) > at java.base/jdk.internal.jimage.NativeImageBuffer$1.run(NativeImageBuffer.java:40) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:319) > at java.base/jdk.internal.jimage.NativeImageBuffer.(NativeImageBuffer.java:39) > at java.base/jdk.internal.jimage.BasicImageReader.(BasicImageReader.java:97) > at java.base/jdk.internal.jimage.ImageReader$SharedImageReader.(ImageReader.java:229) > at java.base/jdk.internal.jimage.ImageReader$SharedImageReader.open(ImageReader.java:243) > at java.base/jdk.internal.jimage.ImageReader.open(ImageReader.java:67) > at java.base/jdk.internal.jimage.ImageReader.open(ImageReader.java:71) > at java.base/jdk.internal.jimage.ImageReaderFactory$1.apply(ImageReaderFactory.java:70) > at java.base/jdk.internal.jimage.ImageReaderFactory$1.apply(ImageReaderFactory.java:67) > at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1714) > at java.base/jdk.internal.jimage.ImageReaderFactory.get(ImageReaderFactory.java:61) > at java.base/jdk.internal.jimage.ImageReaderFactory.getImageReader(ImageReaderFactory.java:85) > at java.base/jdk.internal.module.SystemModuleFinders$SystemImage.(SystemModuleFinders.java:385) > at java.base/jdk.internal.module.SystemModuleFinders$SystemModuleReader.findImageLocation(SystemModuleFinders.java:429) > at java.base/jdk.internal.module.SystemModuleFinders$SystemModuleReader.read(SystemModuleFinders.java:483) > at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:809) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:741) > at java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:621) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:640) > at java.base/java.lang.Class.forName(Class.java:673) > at java.base/java.lang.Class.forName(Class.java:648) > at java.base/sun.launcher.LauncherHelper.loadModuleMainClass(LauncherHelper.java:798) > at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:733) > ``` > > I'm going to look into a fix and update in this comment thread. > > While investigating, I also just found there a new issue in https://github.com/openjdk/leyden/tree/hermetic-java-runtime. Let's focus on resolving the `.java` run issue with your PR to make progress first. With further debugging I found the problem is actually due to failing to load `jimage` as a **built-in** native library. And, that's because `DEF_STATIC_JNI_OnLoad` is missing from jimage.cpp, see change in https://github.com/openjdk/leyden/blob/3cfd92bfcc6e54377fc2cd4004c926db6aa5e16e/src/java.base/share/native/libjimage/jimage.cpp#L44. I'm going to create a bug to fix the missing `DEF_STATIC_JNI_OnLoad` in the mainline now. With your PR, `libjimage.so` is statically linked into `static-jdk/bin/java`. As a result there is no `lib/libjimage.so`. So the `_sun_boot_library_path` issue that I pointed out earlier is not the direct cause of the failure. I don't think we need to address that in your PR. We can fix it later. I think we would need to decide what is the `dll_dir` with the static JDK support and hermetic support. While debugging the issue, I found debugging symbols do not work for `static-jdk/bin/java`. There is no `static-jdk/bin/java.debuginfo`. I do see there's a `./support/static-native/launcher/java.debuginfo`. Please fix the debugging symbol issue in your PR. Reading symbols from images/static-jdk/bin/java... (No debugging symbols found in images/static-jdk/bin/java) (gdb) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2453298940 From alanb at openjdk.org Sun Nov 3 07:01:07 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 3 Nov 2024 07:01:07 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6] In-Reply-To: References: Message-ID: On Sat, 2 Nov 2024 22:18:09 GMT, ExE Boss wrote: >> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits: >> >> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 >> - Modify three RMI tests to work without the security manager: >> - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java >> - test/jdk/java/rmi/registry/readTest/CodebaseTest.java >> - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java >> Also remove them from the problem list. >> - Remove two obsolete RMI tests: >> - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java >> - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java >> Adjust two tests to run without the Security Manager: >> - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java >> - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java >> Remove all of these tests from the problem list. >> - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows. >> - Added API Notes to ProtectionDomain clarifying that the current policy always >> grants no permissions. A few other small changes to Policy and PD. >> - Merge branch 'master' into jep486 >> - JAXP tests: organize imports of a few tests >> - Improve description of Executors.privilegedThreadFactory >> - rename TestAppletLoggerContext.java as suggested in util test review >> - clientlibs: Javadoc cleanup >> - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b > > src/java.base/share/classes/java/lang/System.java line 2338: > >> 2336: * Invoked by VM. Phase 3 is the final system initialization: >> 2337: * 1. eagerly initialize bootstrap method factories that might interact >> 2338: * negatively with custom security managers and custom class loaders > > They?might?still interact?negatively with?custom class?loaders?though. The context here is custom a security manager doing string concatenation, this has required StringConcatFactory be eagerly initialized or security managers set on the command line to have been compiled with -XDstringConcat=inline. I think your question is about overriding the system class loader and whether its initialisation can use string concatenation reliably. That's a good thing to add a test for. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826916876 From dfuchs at openjdk.org Sun Nov 3 11:28:10 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Sun, 3 Nov 2024 11:28:10 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6] In-Reply-To: References: Message-ID: <0j1uUkVMlrLOxFPmXYzvHcDe9I3a34Fbfjh4hBK2BL0=.13667c44-1516-4784-823e-7216e886512c@github.com> On Sat, 2 Nov 2024 22:25:06 GMT, ExE Boss wrote: >> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits: >> >> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 >> - Modify three RMI tests to work without the security manager: >> - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java >> - test/jdk/java/rmi/registry/readTest/CodebaseTest.java >> - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java >> Also remove them from the problem list. >> - Remove two obsolete RMI tests: >> - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java >> - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java >> Adjust two tests to run without the Security Manager: >> - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java >> - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java >> Remove all of these tests from the problem list. >> - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows. >> - Added API Notes to ProtectionDomain clarifying that the current policy always >> grants no permissions. A few other small changes to Policy and PD. >> - Merge branch 'master' into jep486 >> - JAXP tests: organize imports of a few tests >> - Improve description of Executors.privilegedThreadFactory >> - rename TestAppletLoggerContext.java as suggested in util test review >> - clientlibs: Javadoc cleanup >> - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b > > src/java.base/share/classes/java/lang/System.java line 1364: > >> 1362: *
>> 1363: * It is the responsibility of the provider of >> 1364: * the concrete {@code LoggerFinder} implementation to ensure that > > This is?still a?part of?the?paragraph related to?the?security?manager. Right - this paragraph - lines 1620-1625 (old file) / 1362-1367 (new file) is no longer relevant and should be removed too. Thanks for spotting that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826959976 From alanb at openjdk.org Sun Nov 3 12:36:12 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 3 Nov 2024 12:36:12 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6] In-Reply-To: <0j1uUkVMlrLOxFPmXYzvHcDe9I3a34Fbfjh4hBK2BL0=.13667c44-1516-4784-823e-7216e886512c@github.com> References: <0j1uUkVMlrLOxFPmXYzvHcDe9I3a34Fbfjh4hBK2BL0=.13667c44-1516-4784-823e-7216e886512c@github.com> Message-ID: On Sun, 3 Nov 2024 11:25:13 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/java/lang/System.java line 1364: >> >>> 1362: *
>>> 1363: * It is the responsibility of the provider of >>> 1364: * the concrete {@code LoggerFinder} implementation to ensure that >> >> This is?still a?part of?the?paragraph related to?the?security?manager. > > Right - this paragraph - lines 1620-1625 (old file) / 1362-1367 (new file) is no longer relevant and should be removed too. Thanks for spotting that. Removed in jep486 branch in sandbox so will get picked up when PR is refreshed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826972198 From jiangli at openjdk.org Sun Nov 3 20:26:33 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Sun, 3 Nov 2024 20:26:33 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v9] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Fri, 1 Nov 2024 16:25:59 GMT, Magnus Ihse Bursie wrote: >> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. >> >> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. >> >> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). > > Magnus Ihse Bursie 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 'master' into static-jdk-image > - Fix bug in filtering out -Wl,--exclude-libs,ALL > - Don't hardcode server variant > - Setup LDFLAGS_STATIC_JDK > - Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check > - Add lookup asserts > - Remove superfluous SRC. > - Merge branch 'master' into static-jdk-image > - Makefile changes needed for static-launcher and static-jdk-image targets > - Incorporate changes from leyden/hermetic-java-runtime that allows running a static launcher https://github.com/openjdk/jdk/pull/21861 for adding DEF_STATIC_JNI_OnLoad in libjimage and libsaproc native libraries. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2453565591 From dholmes at openjdk.org Mon Nov 4 01:27:38 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 4 Nov 2024 01:27:38 GMT Subject: RFR: 8328944: NMT reports "unknown" memory In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 20:44:50 GMT, Gerard Ziemski wrote: > We use mtNone value in several functions default parameters, which may show up in NMT reports. > > We address this, by removing the default value and forcing, where possible, for the callers to declare NMT tag that reflects the usage. > > Eventually the goal would be not to use mtNone anywhere, but we are not there quite yet. > > TODO: update copyrights. > > Testing: undergoing MARCH5 tier1-5 ... Seems okay in principle, but you will need someone familiar with each modified area to confirm that the chosen tags are appropriate - I'm unsure about the use of `mtClass` versus `mtClassShared` for example. ------------- PR Review: https://git.openjdk.org/jdk/pull/21843#pullrequestreview-2412003334 From fyang at openjdk.org Mon Nov 4 01:42:41 2024 From: fyang at openjdk.org (Fei Yang) Date: Mon, 4 Nov 2024 01:42:41 GMT Subject: RFR: 8343242: RISC-V: Refactor materialization of literal address In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 10:18:24 GMT, Robbin Ehn wrote: >> Hi, please consider this refactoring work. >> >> Currently, we have both `la(address)` and `la(Address)`. They both accept and materialize literal address. >> While `la(Address)` always emit a movptr sequence, `la(address)` is a bit complex: it checks whether the target is >> reachable from anywhere within the code cache (`is_32bit_offset_from_codecache`) and emits pc-relative auipc+addi >> pair or movptr sequence. This makes it not that obvious at places where we want a more accurate estimation about >> the size of code emitted like when we prepare code stubs like C2SafepointPollStub or C2EntryBarrierStub (See: https://github.com/openjdk/jdk/pull/21732). >> >> I would suggest we keep `la(address)` simple and let it only emit auipc+addi pair, which will be consistent with the >> `RISC-V Assembly Programmer's Handbook`. I think It's more reasonable to move the distance check to `la(Address)`. >> Furthermore, I would also suggest that we make the distance check simpler. The approach taken here is to only check >> whether the target is inside the code cache. This way we will be more certain about code emitted with `la(Address)` >> as well. This will help keep the risk of this change low as all `la(Address)` callsites with literal address outside of code >> cache won't be affected. And I don't think the original distance check from code cache will benefit us much more. >> Eyeballed all `la(Address)` callsites, I think we are fine. >> >> Benefits: >> 1. We have a simpler `la(address)` which is kind of spec compatible; >> 2. We are consistent in target distance check when doing `j(Address)`, `la(Address)`, `ld/st(Address)` and `rt_call`; >> 3. We don't need explicit use of `relocate` with lambda for most of the places; >> >> Note that there are several places where we want explicit `movptr` sequence: >> 1. In `SignatureHandlerGenerator::generate()` where the emitted code is simply copied without relocation [1]; >> 2. In `movoop` and `mov_metadata` where we want patching afterwards; >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/interpreterRuntime.cpp#L1313 >> >> Testing on linux-riscv64: >> - [x] hotspot:tier1 (fastdebug) >> - [x] tier1-tier3, hotspot:tier4 (release) >> - [x] specjbb2015, dacapo, renaissance (release) > > Did you run any micro benchmarks? Maybe skynet just to check VTs. > And did you do any measurement on code cache size? > > I can't find anything that would matter, but I'll look a bit more. @robehn @feilongjiang : Thanks for the review! I also tried NetBeans and Eclipse. Both IDEs work fine with this change. Let's move on. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21777#issuecomment-2453688709 From fyang at openjdk.org Mon Nov 4 01:42:42 2024 From: fyang at openjdk.org (Fei Yang) Date: Mon, 4 Nov 2024 01:42:42 GMT Subject: Integrated: 8343242: RISC-V: Refactor materialization of literal address In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 00:28:16 GMT, Fei Yang wrote: > Hi, please consider this refactoring work. > > Currently, we have both `la(address)` and `la(Address)`. They both accept and materialize literal address. > While `la(Address)` always emit a movptr sequence, `la(address)` is a bit complex: it checks whether the target is > reachable from anywhere within the code cache (`is_32bit_offset_from_codecache`) and emits pc-relative auipc+addi > pair or movptr sequence. This makes it not that obvious at places where we want a more accurate estimation about > the size of code emitted like when we prepare code stubs like C2SafepointPollStub or C2EntryBarrierStub (See: https://github.com/openjdk/jdk/pull/21732). > > I would suggest we keep `la(address)` simple and let it only emit auipc+addi pair, which will be consistent with the > `RISC-V Assembly Programmer's Handbook`. I think It's more reasonable to move the distance check to `la(Address)`. > Furthermore, I would also suggest that we make the distance check simpler. The approach taken here is to only check > whether the target is inside the code cache. This way we will be more certain about code emitted with `la(Address)` > as well. This will help keep the risk of this change low as all `la(Address)` callsites with literal address outside of code > cache won't be affected. And I don't think the original distance check from code cache will benefit us much more. > Eyeballed all `la(Address)` callsites, I think we are fine. > > Benefits: > 1. We have a simpler `la(address)` which is kind of spec compatible; > 2. We are consistent in target distance check when doing `j(Address)`, `la(Address)`, `ld/st(Address)` and `rt_call`; > 3. We don't need explicit use of `relocate` with lambda for most of the places; > > Note that there are several places where we want explicit `movptr` sequence: > 1. In `SignatureHandlerGenerator::generate()` where the emitted code is simply copied without relocation [1]; > 2. In `movoop` and `mov_metadata` where we want patching afterwards; > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/interpreterRuntime.cpp#L1313 > > Testing on linux-riscv64: > - [x] hotspot:tier1 (fastdebug) > - [x] tier1-tier3, hotspot:tier4 (release) > - [x] specjbb2015, dacapo, renaissance (release) This pull request has now been integrated. Changeset: 37a3398b Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/37a3398b5879e0ee79891e97791cd1d6e99ab5d9 Stats: 161 lines in 14 files changed: 28 ins; 87 del; 46 mod 8343242: RISC-V: Refactor materialization of literal address Reviewed-by: rehn, fjiang ------------- PR: https://git.openjdk.org/jdk/pull/21777 From dholmes at openjdk.org Mon Nov 4 02:18:55 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 4 Nov 2024 02:18:55 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Use lazySubmitRunContinuation when blocking src/hotspot/share/classfile/javaClasses.cpp line 2107: > 2105: > 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) { > 2107: return vthread->long_field(_timeout_offset); Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ?? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827128518 From dholmes at openjdk.org Mon Nov 4 02:37:40 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 4 Nov 2024 02:37:40 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize Changes requested by dholmes (Reviewer). src/hotspot/share/adlc/adlc.hpp line 43: > 41: > 42: /* Make sure that we have the intptr_t and uintptr_t definitions */ > 43: #ifdef _WIN32 As this is a synonym for `_WINDOWS` it is not obvious this deletion is correct. ------------- PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2412031267 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827135809 From fyang at openjdk.org Mon Nov 4 03:02:06 2024 From: fyang at openjdk.org (Fei Yang) Date: Mon, 4 Nov 2024 03:02:06 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call Message-ID: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> Hi, please review this cleanup change. The old trampoline call on linux-riscv64 is disabled by default after: https://bugs.openjdk.org/browse/JDK-8332689. And the new solution (load target address from stub and call) has been baked in jdk master for quite some time. This propose to remove the related logic of the old trampoline call so that the code will be cleaner and easier to maintain. As we are still using `trampoline_stub_Relocation` for the stub, I kept using the original `emit_trampoline_stub` name. Testing on linux-riscv64: - [x] tier1-tier3 (release) - [x] hotspot:tier1 (fastdebug) ------------- Commit messages: - Improve - Code comment - Merge remote-tracking branch 'upstream/master' into JDK-8343430 - 8343430: RISC-V: Remove old trampoline call Changes: https://git.openjdk.org/jdk/pull/21822/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21822&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343430 Stats: 591 lines in 10 files changed: 7 ins; 535 del; 49 mod Patch: https://git.openjdk.org/jdk/pull/21822.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21822/head:pull/21822 PR: https://git.openjdk.org/jdk/pull/21822 From syan at openjdk.org Mon Nov 4 03:04:27 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 4 Nov 2024 03:04:27 GMT Subject: RFR: 8343471: RISC-V: compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java fails after JDK-8334999 In-Reply-To: References: Message-ID: <0kbTYsLzbimfWgJLujNBa3NStR5jCD6RYJem7nha9OQ=.b0fa4a76-7329-491e-8566-a33b9698c1aa@github.com> On Sat, 2 Nov 2024 09:22:31 GMT, Fei Yang wrote: > Hi, please review this small change. > > The test expects a message like `warning: AES instructions are not available on this CPU` for all cpu platforms without AES support. After https://bugs.openjdk.org/browse/JDK-8334999, we report this `warning: AES intrinsics require Zvkn extension (not available on this CPU)` on RISC-V platforms where `Zvkn` extension is not available. Patch fixes this message making it consistent with other CPU platforms. Same test passes with this fix. /LGTM ------------- Marked as reviewed by syan (Committer). PR Review: https://git.openjdk.org/jdk/pull/21847#pullrequestreview-2412044383 From iklam at openjdk.org Mon Nov 4 03:10:38 2024 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 4 Nov 2024 03:10:38 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v6] In-Reply-To: References: Message-ID: <8IyBT_SVLgsOjXogoorL6m3SmYK8OVzJDpRv-MH4MaA=.7f7f50c3-db38-4418-9381-9f915bb07470@github.com> On Fri, 1 Nov 2024 03:54:24 GMT, Dan Heidinga wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed whitespace; fixed minimal build > > src/hotspot/share/cds/aotClassInitializer.cpp line 348: > >> 346: } >> 347: JavaValue result(T_VOID); >> 348: JavaCalls::call_static(&result, ik, > > Based on the discussions in JDK-8342283, do we need a memory fence after the call to runtimeSetup? > > I think we do to be consistent with the non-AOTCache run as there is a fence after `` (when this code would normally run) due to the initialization lock. I think this is already done: `runtimeSetup()` is called inside `InstanceKlass::call_class_initializer()`. When that returns, we will proceed to `InstanceKlass::set_initialization_state_and_notify()` which will perform the memory fencing. https://github.com/iklam/jdk/blob/6eebd18fc2820ffb179d431f179fc6af6d1be247/src/hotspot/share/oops/instanceKlass.cpp#L1276-L1300 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1827146321 From iklam at openjdk.org Mon Nov 4 03:15:25 2024 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 4 Nov 2024 03:15:25 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v7] In-Reply-To: References: Message-ID: > This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). > > ---- > Note: this is a combined PR of the following individual PRs > - https://github.com/openjdk/jdk/pull/20516 > - https://github.com/openjdk/jdk/pull/20517 > - https://github.com/openjdk/jdk/pull/20843 > - https://github.com/openjdk/jdk/pull/20958 > - https://github.com/openjdk/jdk/pull/20959 > - https://github.com/openjdk/jdk/pull/21049 > - https://github.com/openjdk/jdk/pull/21143 Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 172 commits: - fixed merge - Merge branch 'master' into jep-483-candidate - 8343493: Perform module checks during MetaspaceShared::map_archives() - reverted changes in modules.cpp to make it easy to merge with mainline - Fixed whitespace; fixed minimal build - Fixed 8343245: AOT cache creation crashes with "assert(HeapShared::is_archivable_hidden_klass(ik)) failed: sanity" - fixed comments - @ashu-mehra comment - renamed function to SystemDictionaryShared::should_be_excluded(); added comments and asserts; make sure the class is indeed checked - Backed out 58233cc20fa22abfd711bb59aafb78e20fabc195 - @ashu-mehra comment - rename/comment AOTClassLinker::add_new_candidate() and added asserts for thread safety - ... and 162 more: https://git.openjdk.org/jdk/compare/29882bfe...935dcc68 ------------- Changes: https://git.openjdk.org/jdk/pull/21642/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=06 Stats: 7256 lines in 105 files changed: 6408 ins; 519 del; 329 mod Patch: https://git.openjdk.org/jdk/pull/21642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642 PR: https://git.openjdk.org/jdk/pull/21642 From fyang at openjdk.org Mon Nov 4 04:12:37 2024 From: fyang at openjdk.org (Fei Yang) Date: Mon, 4 Nov 2024 04:12:37 GMT Subject: RFR: 8343502: RISC-V: SIGBUS in updateBytesCRC32 after JDK-8339738 Message-ID: Hi, please review this small change. JDK-8339738 adds vectorization for crc32 intrinsic, which does `vle32.v` from the input byte buffer and calculates the checksum. But the input byte buffer could be misaligned (not 4-byte aligned). This leads to SIGBUS on hardware platforms like `BPI-F3` board where misaligned vector loads are not supported. Similar issue is there for scalar version as well, which could mean performance issue on other hardwares. Patch fixes this issue by adding a small alignment processing on entry for both scalar and vector version. This also fixes another potential issue in tail handling, where we do a single `lwu` for both versions to load the remaining bytes from the input byte buffer and extract each byte from the loaded 32-bit value. Since we only have less than 4 bytes remaining, this `lwu` would exceed the buffer limit, which I think is not safe. Patch fixes this issue by doing three separate `lbu` instead. Testing on `BPI-F3` with RVV 1.0 extension: - [x] test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java - [x] test/jdk/java/util/zip/TestCRC32.java - [x] SPECjbb2015 No obvious impact witnessed on `micro:java.util.TestCRC32`: Before: Benchmark (count) Mode Cnt Score Error Units TestCRC32.testCRC32Update 64 thrpt 12 4778.903 ? 1.793 ops/ms TestCRC32.testCRC32Update 128 thrpt 12 2655.639 ? 2.958 ops/ms TestCRC32.testCRC32Update 256 thrpt 12 1430.997 ? 0.970 ops/ms TestCRC32.testCRC32Update 512 thrpt 12 965.785 ? 1.840 ops/ms TestCRC32.testCRC32Update 2048 thrpt 12 303.056 ? 0.620 ops/ms TestCRC32.testCRC32Update 16384 thrpt 12 40.601 ? 0.220 ops/ms TestCRC32.testCRC32Update 65536 thrpt 12 9.575 ? 0.045 ops/ms TestCRC32C.testCRC32CUpdate 64 thrpt 12 3923.698 ? 23.209 ops/ms TestCRC32C.testCRC32CUpdate 128 thrpt 12 2514.616 ? 22.991 ops/ms TestCRC32C.testCRC32CUpdate 256 thrpt 12 1477.223 ? 2.319 ops/ms TestCRC32C.testCRC32CUpdate 512 thrpt 12 806.179 ? 1.961 ops/ms TestCRC32C.testCRC32CUpdate 2048 thrpt 12 216.396 ? 0.172 ops/ms TestCRC32C.testCRC32CUpdate 16384 thrpt 12 27.526 ? 0.049 ops/ms TestCRC32C.testCRC32CUpdate 65536 thrpt 12 6.530 ? 0.041 ops/ms After: Benchmark (count) Mode Cnt Score Error Units TestCRC32.testCRC32Update 64 thrpt 12 4731.084 ? 7.612 ops/ms TestCRC32.testCRC32Update 128 thrpt 12 2749.235 ? 7.726 ops/ms TestCRC32.testCRC32Update 256 thrpt 12 1454.230 ? 9.459 ops/ms TestCRC32.testCRC32Update 512 thrpt 12 965.216 ? 0.214 ops/ms TestCRC32.testCRC32Update 2048 thrpt 12 300.504 ? 3.952 ops/ms TestCRC32.testCRC32Update 16384 thrpt 12 40.811 ? 0.095 ops/ms TestCRC32.testCRC32Update 65536 thrpt 12 9.574 ? 0.111 ops/ms TestCRC32C.testCRC32CUpdate 64 thrpt 12 3918.445 ? 36.326 ops/ms TestCRC32C.testCRC32CUpdate 128 thrpt 12 2518.877 ? 5.954 ops/ms TestCRC32C.testCRC32CUpdate 256 thrpt 12 1469.317 ? 6.587 ops/ms TestCRC32C.testCRC32CUpdate 512 thrpt 12 802.025 ? 5.356 ops/ms TestCRC32C.testCRC32CUpdate 2048 thrpt 12 216.142 ? 0.546 ops/ms TestCRC32C.testCRC32CUpdate 16384 thrpt 12 27.492 ? 0.095 ops/ms TestCRC32C.testCRC32CUpdate 65536 thrpt 12 6.556 ? 0.020 ops/ms ------------- Commit messages: - 8343502: RISC-V: SIGBUS in updateBytesCRC32 after JDK-8339738 Changes: https://git.openjdk.org/jdk/pull/21863/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21863&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343502 Stats: 31 lines in 1 file changed: 21 ins; 3 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/21863.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21863/head:pull/21863 PR: https://git.openjdk.org/jdk/pull/21863 From alanb at openjdk.org Mon Nov 4 05:54:54 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 4 Nov 2024 05:54:54 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28] In-Reply-To: References: Message-ID: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.2ca0fc7a-49b5-47eb-8cc2-56757cafb96e@github.com> On Mon, 4 Nov 2024 02:12:40 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> Use lazySubmitRunContinuation when blocking > > src/hotspot/share/classfile/javaClasses.cpp line 2107: > >> 2105: >> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) { >> 2107: return vthread->long_field(_timeout_offset); > > Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ?? It was initially parkTimeout and waitTimeout but it doesn't require two fields as you can't be waiting in Object.wait(timeout) and LockSupport.parkNanos at the same time. So the field was renamed, the accessors here should probably be renamed too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827219720 From dholmes at openjdk.org Mon Nov 4 07:05:44 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 4 Nov 2024 07:05:44 GMT Subject: RFR: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf Message-ID: This is mostly an audit of the callers of `Exceptions::fthrow` to ensure unbounded strings can't appear. There is a code change in DiagnosticCmd parsing to extend the string length limit already used in part of that code. Testing: - tier 1-3 (sanity) Thanks ------------- Commit messages: - 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf Changes: https://git.openjdk.org/jdk/pull/21867/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21867&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339134 Stats: 50 lines in 9 files changed: 44 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21867/head:pull/21867 PR: https://git.openjdk.org/jdk/pull/21867 From aboldtch at openjdk.org Mon Nov 4 07:23:51 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 4 Nov 2024 07:23:51 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Use lazySubmitRunContinuation when blocking src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62: > 60: NATIVE(2, "Native frame or on stack"), > 61: MONITOR(3, "Monitor held"), > 62: CRITICAL_SECTION(4, "In critical section"); Is there a reason that the `reasonCode` values does not match the `freeze_result` reason values used in `pinnedReason(int reason)` to create one of these? I cannot see that it is used either. Only seem to be read for JFR VirtualThreadPinned Event which only uses the string. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827276764 From alanb at openjdk.org Mon Nov 4 08:02:57 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 4 Nov 2024 08:02:57 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 07:21:19 GMT, Axel Boldt-Christmas wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> Use lazySubmitRunContinuation when blocking > > src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62: > >> 60: NATIVE(2, "Native frame or on stack"), >> 61: MONITOR(3, "Monitor held"), >> 62: CRITICAL_SECTION(4, "In critical section"); > > Is there a reason that the `reasonCode` values does not match the `freeze_result` reason values used in `pinnedReason(int reason)` to create one of these? > > I cannot see that it is used either. Only seem to be read for JFR VirtualThreadPinned Event which only uses the string. That's a good question as they should match. Not noticed as it's not currently used. As it happens, this has been reverted in the loom repo as part of improving this code and fixing another issue. Related is the freeze_result enum has new members, e.g. freeze_unsupported for LM_LEGACY, that don't have a mapping to a Pinned, need to check if we could trip over that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827316145 From stuefe at openjdk.org Mon Nov 4 08:36:42 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 4 Nov 2024 08:36:42 GMT Subject: RFR: 8328944: NMT reports "unknown" memory In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 20:44:50 GMT, Gerard Ziemski wrote: > We use mtNone value in several functions default parameters, which may show up in NMT reports. > > We address this, by removing the default value and forcing, where possible, for the callers to declare NMT tag that reflects the usage. > > Eventually the goal would be not to use mtNone anywhere, but we are not there quite yet. > > TODO: update copyrights. > > Testing: undergoing MARCH5 tier1-5 ... Had a cursory look. The direction is okay. Some general comments: 1) We have two cases: a) where today we report mtNone and b) where today we report a tag other than mtNone, but the tag was set after the initial reservation For the latter case, if the case is simple (the reservation was for a single thing, and its purpose was clear at reservation) there must have existed a subsequent NMT registration, which you should then remove since it should not be necessary anymore. I will point them out if I stumble over them, but may miss a bunch. 2) About > Eventually the goal would be not to use mtNone anywhere, but we are not there quite yet. I think this is neither realistic nor desirable. mtNone means "don't know yet; will do later". This is perfectly valid for cases where - you allocate something on behalf of someone else; obviously, you don't know what he intends to do with it - when you reserve a range that is later shared by multiple tags. If we move to more fine granular tags, or something like hierarchical tags, the latter point will become more important. Therefore, mtNone has its place. src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp line 72: > 70: assert(immediate > 0 && Assembler::operand_valid_for_logical_immediate(/*is32*/false, immediate), > 71: "Invalid immediate %d " UINT64_FORMAT, index, immediate); > 72: result = os::attempt_reserve_memory_at((char*)immediate, size, false, mtMetaspace); mtMetaspace is wrong. There is no right tag apart from mtNone, since this address range is a combination of mtClass+mtClassShared, depending on how class space is configured. mtNone signals "will be set later", which is the correct course here IHMO. The tag is set later, see metaspace.cpp and metaspaceShared.cpp src/hotspot/os/bsd/gc/z/zPhysicalMemoryBacking_bsd.cpp line 82: > 80: > 81: // Reserve address space for backing memory > 82: _base = (uintptr_t)os::reserve_memory(max_capacity, false, mtGC); This is Java heap. src/hotspot/share/cds/archiveBuilder.cpp line 330: > 328: size_t buffer_size = estimate_archive_size(); > 329: ReservedSpace rs(buffer_size, MetaspaceShared::core_region_alignment(), > 330: os::vm_page_size(), nullptr, mtMetaspace); This is not Metaspace. Possibly mtClassShared, though that one is reserved for the runtime mapping of the CDS archive; this is the dumptime image. mtInternal would be the best fit, IMHO. src/hotspot/share/cds/metaspaceShared.cpp line 1387: > 1385: total_space_rs = ReservedSpace(total_range_size, base_address_alignment, > 1386: os::vm_page_size(), (char*)base_address, mtClass); > 1387: } else { All the changes here in `MetaspaceShared::reserve_address_space_for_archives` are unnecessary; we tag the address region already. No need to do this multiple times, and in every case branch. The ReservedSpace objects here are not used for much and mostly ephemeral anyway - they are only used to reserve memory here, but after that have not much meaning, and apart from the class space rs don't even survive the invocation. src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 249: > 247: _bitmap_bytes_per_slice, bitmap_page_size); > 248: > 249: ReservedSpace bitmap(_bitmap_size, bitmap_page_size, mtGC); remove nmt registration below? src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 269: > 267: > 268: if (ShenandoahVerify) { > 269: ReservedSpace verify_bitmap(_bitmap_size, bitmap_page_size, mtGC); remove nmt registration below? src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 288: > 286: > 287: ReservedSpace aux_bitmap(_bitmap_size, aux_bitmap_page_size, mtGC); > 288: os::trace_page_sizes_for_requested_size("Aux Bitmap", remove nmt registration below? src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 306: > 304: > 305: ReservedSpace region_storage(region_storage_size, region_page_size, mtGC); > 306: os::trace_page_sizes_for_requested_size("Region Storage", remove nmt registration below? src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 340: > 338: > 339: if (_collection_set == nullptr) { > 340: cset_rs = ReservedSpace(cset_size, cset_align, os::vm_page_size(), nullptr, mtGC); remove NMT registration in ShenandoahCollectionSet? src/hotspot/share/jfr/recorder/storage/jfrVirtualMemory.cpp line 107: > 105: _rs = ReservedSpace(reservation_size_request_bytes, > 106: os::vm_allocation_granularity(), os::vm_page_size(), > 107: nullptr, mtTracing); remove NMT registraton? src/hotspot/share/memory/heap.cpp line 231: > 229: // reserve space for _segmap > 230: ReservedSpace seg_rs(reserved_segments_size, mtCode); > 231: if (!_segmap.initialize(seg_rs, committed_segments_size)) { remove NMT registration src/hotspot/share/memory/metaspace.cpp line 605: > 603: assert(is_aligned(result, Metaspace::reserve_alignment()), "Alignment too small for metaspace"); > 604: rs = ReservedSpace::space_for_range(result, size, Metaspace::reserve_alignment(), > 605: os::vm_page_size(), false, false, mtMetaspace); Please revert to mtNone; same reason as given in metaspaceShared.cpp. You can add a comment that tags are adjusted afterward, when the distribution of mtClass and mtClassShared is clear. src/hotspot/share/memory/metaspace.cpp line 746: > 744: } > 745: rs = ReservedSpace(size, Metaspace::reserve_alignment(), > 746: os::vm_page_size() /* large */, (char*)base, mtMetaspace); mtClass, but actually not needed, since we set mtClass below. Again, not necessary to do this for every branch individually we take here when reserving class space memory. src/hotspot/share/memory/metaspace.cpp line 775: > 773: > 774: // Mark metaspace as such > 775: MemTracker::record_virtual_memory_tag((address)rs.base(), mtMetaspace); No, please revert. mtClass is correct here. src/hotspot/share/memory/metaspace/testHelpers.cpp line 82: > 80: // have reserve limit -> non-expandable context > 81: _rs = ReservedSpace(reserve_limit * BytesPerWord, Metaspace::reserve_alignment(), > 82: os::vm_page_size(), nullptr, MemTag::mtMetaspace); Give this mtTest src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp line 258: > 256: ReservedSpace rs(word_size * BytesPerWord, > 257: Settings::virtual_space_node_reserve_alignment_words() * BytesPerWord, > 258: os::vm_page_size(), nullptr, mtMetaspace); remove tracking below. This is actually wrong, and only works out of accident correctly, since this constructor just happens to be called for mtMetaspace; more correct would be to hand in the tag. This is on my plate, there is a JBS issue somewhere. src/hotspot/share/memory/virtualspace.hpp line 50: > 48: // ReservedSpace > 49: ReservedSpace(char* base, size_t size, size_t alignment, > 50: size_t page_size, bool special, bool executable, MemTag mem_tag); The growth in complexity is unfortunate. src/hotspot/share/memory/virtualspace.hpp line 67: > 65: > 66: void reserve(size_t size, size_t alignment, size_t page_size, > 67: char* requested_address, bool executable, MemTag mem_tag); Why do the instance methods get MemTag? Why is MemTag not stored as a (const) attribute of ReservedSpace? But then, we would have double accounting - we'd store the tag both in NMT and in ReservedSpace instances. If we change them post-reservation, we would need to change both. Sigh. So we pass in MemTag just for the ReservedSpace to pass it into os::reserve_memory. Seeing how often ReservedSpace is used in situations where the tag is not clear at reservation time, I wonder whether we are not better off letting the user of ReservedSpace register the NMT tag post reservation like they do today. src/hotspot/share/nmt/memReporter.cpp line 83: > 81: if (mem_tag != mtNone) { > 82: out->print("(%s" SIZE_FORMAT "%s type=%u", alloc_type, > 83: amount_in_current_scale(amount), scale, (unsigned)mem_tag); No, please revert. src/hotspot/share/nmt/memReporter.cpp line 252: > 250: // report malloc'd memory > 251: if (amount_in_current_scale(MAX2(malloc_memory->malloc_size(), pk_malloc)) > 0) { > 252: print_malloc(malloc_memory->malloc_counter(), mtNMT); Please revert, the original was correct. print_malloc is used for both summary and detail reports; for summary, we pass in mtNone deliberately since the report happens under a common tag. src/hotspot/share/nmt/virtualMemoryTracker.cpp line 364: > 362: // thread does not detach from VM before exits, and leads to > 363: // leak JavaThread object > 364: if ((reserved_rgn->mem_tag() == mtThreadStack) && (reserved_rgn->mem_tag() == mem_tag)) { Please explain the changes in this function, especially the changed conditions. The added conditions for tag equality seem wrong to me. src/hotspot/share/runtime/safepointMechanism.cpp line 61: > 59: const size_t page_size = os::vm_page_size(); > 60: const size_t allocation_size = 2 * page_size; > 61: char* polling_page = os::reserve_memory(allocation_size, false, mtSafepoint); remove registration src/hotspot/share/utilities/debug.cpp line 712: > 710: > 711: void initialize_assert_poison() { > 712: char* page = os::reserve_memory(os::vm_page_size(), false, mtInternal); remove registration test/hotspot/jtreg/runtime/NMT/MallocRoundingReportTest.java line 60: > 58: NMTTestUtils.runJcmdSummaryReportAndCheckOutput( > 59: "Test (reserved=" + numKB + "KB, committed=" + numKB + "KB)", > 60: "(malloc=" + numKB + "KB type=12 #1) (at peak)" Again, this is wrong. The memory had not been reserved for NMT usage, so it should not be tagged with mtNMT (12) test/hotspot/jtreg/runtime/NMT/MallocRoundingReportTest.java line 68: > 66: NMTTestUtils.runJcmdSummaryReportAndCheckOutput( > 67: "Test (reserved=0KB, committed=0KB)", > 68: "(malloc=0KB type=12) (peak=" + numKB + "KB #1)" ditto ------------- PR Review: https://git.openjdk.org/jdk/pull/21843#pullrequestreview-2412301432 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827274229 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827277342 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827280468 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827292469 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827310565 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827310673 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827310815 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827310928 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827312298 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827312806 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827312951 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827314192 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827314524 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827314999 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827316399 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827318234 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827329282 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827323214 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827334776 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827339410 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827348792 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827361075 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827361821 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827363362 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1827363506 From dholmes at openjdk.org Mon Nov 4 09:02:10 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 4 Nov 2024 09:02:10 GMT Subject: RFR: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf [v2] In-Reply-To: References: Message-ID: > This is mostly an audit of the callers of `Exceptions::fthrow` to ensure unbounded strings can't appear. > > There is a code change in DiagnosticCmd parsing to extend the string length limit already used in part of that code. > > Testing: > - tier 1-3 (sanity) > > Thanks David Holmes has updated the pull request incrementally with one additional commit since the last revision: Restore previous behaviour for zero length strings ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21867/files - new: https://git.openjdk.org/jdk/pull/21867/files/4ffe35d5..f0e285da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21867&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21867&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21867/head:pull/21867 PR: https://git.openjdk.org/jdk/pull/21867 From kbarrett at openjdk.org Mon Nov 4 09:03:42 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 4 Nov 2024 09:03:42 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Mon, 4 Nov 2024 02:34:13 GMT, David Holmes wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers >> - Remove windows-32-bit code in CompilerConfig::ergo_initialize > > src/hotspot/share/adlc/adlc.hpp line 43: > >> 41: >> 42: /* Make sure that we have the intptr_t and uintptr_t definitions */ >> 43: #ifdef _WIN32 > > As this is a synonym for `_WINDOWS` it is not obvious this deletion is correct. The deletion is apparently working, else we'd be getting build failures. So while there are some potential issues and opportunities for further cleanup in this file, I think they ought to be addressed separately from this PR. See new https://bugs.openjdk.org/browse/JDK-8343530. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827395928 From dholmes at openjdk.org Mon Nov 4 09:13:43 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 4 Nov 2024 09:13:43 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Mon, 4 Nov 2024 09:00:59 GMT, Kim Barrett wrote: >> src/hotspot/share/adlc/adlc.hpp line 43: >> >>> 41: >>> 42: /* Make sure that we have the intptr_t and uintptr_t definitions */ >>> 43: #ifdef _WIN32 >> >> As this is a synonym for `_WINDOWS` it is not obvious this deletion is correct. > > The deletion is apparently working, else we'd be getting build failures. So > while there are some potential issues and opportunities for further cleanup in > this file, I think they ought to be addressed separately from this PR. See > new https://bugs.openjdk.org/browse/JDK-8343530. There is a difference between "working" and not causing a build failure. I suspect none of that code is actually needed these days, but I'm not sure. As deleting the entire section goes beyond deleting 32-bit code, I would expect it to be partially restored in this PR and then cleaned up in a later PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827408129 From stuefe at openjdk.org Mon Nov 4 09:24:58 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 4 Nov 2024 09:24:58 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize Can we get rid of `JNICALL` too, please? Or would that change be too big? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2454188077 From stefank at openjdk.org Mon Nov 4 09:26:55 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 4 Nov 2024 09:26:55 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v16] In-Reply-To: References: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com> Message-ID: On Wed, 30 Oct 2024 23:14:53 GMT, Patricio Chilano Mateo wrote: >> This might confuse the change for JEP 450 since with CompactObjectHeaders there's no klass_gap, so depending on which change goes first, there will be conditional code here. Good question though, it looks like we only ever want to copy the payload of the object. > > If I recall correctly this was a bug where one of the stackChunk fields was allocated in that gap, but since we didn't zeroed it out it would start with some invalid value. I guess the reason why we are not hitting this today is because one of the fields we do initialize (sp/bottom/size) is being allocated there, but with the new fields I added to stackChunk that is not the case anymore. This code in `StackChunkAllocator::initialize` mimics the clearing code in: void MemAllocator::mem_clear(HeapWord* mem) const { assert(mem != nullptr, "cannot initialize null object"); const size_t hs = oopDesc::header_size(); assert(_word_size >= hs, "unexpected object size"); oopDesc::set_klass_gap(mem, 0); Copy::fill_to_aligned_words(mem + hs, _word_size - hs); } but with a limited amount of clearing at the end of the object, IIRC. So, this looks like a good fix. With JEP 450 we have added an assert to set_klass_gap and changed the code in `mem_clear` to be: if (oopDesc::has_klass_gap()) { oopDesc::set_klass_gap(mem, 0); } So, unchanged, this code will start to assert when the to projects merge. Maybe it would be nice to make a small/trivial upstream PR to add this code to both `MemAllocator::mem_clear` and `StackChunkAllocator::initialize`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827424227 From alanb at openjdk.org Mon Nov 4 09:31:41 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 4 Nov 2024 09:31:41 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Mon, 4 Nov 2024 09:21:52 GMT, Thomas Stuefe wrote: > Can we get rid of `JNICALL` too, please? > > Or would that change be too big? There's >1000 in java.base, lots more elsewhere, so it would be a lot of files and would hide the core changes. So maybe for a follow-up PR that does the one thing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2454201348 From stuefe at openjdk.org Mon Nov 4 09:44:42 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 4 Nov 2024 09:44:42 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize This is a very nice reduction in complexity. As I wrote before, removing windows 32-bit removes the need for calling convention definition, so I think we could get rid of JNICALL in addition to anything stdcall/fastcall related. I had a close look at hotspot os and os_cpu changes, cursory glances at other places, all looked fine. ------------- PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2412592195 From duke at openjdk.org Mon Nov 4 09:47:35 2024 From: duke at openjdk.org (Mikhail Ablakatov) Date: Mon, 4 Nov 2024 09:47:35 GMT Subject: RFR: 8341194: [REDO] Implement C2 VectorizedHashCode on AArch64 [v2] In-Reply-To: References: <6kiSAoE5qRiNSR1ClKm_REyMlocquVxQkRoeVARczLc=.b548a5ff-7f25-41bd-873f-c9e6f470d295@github.com> Message-ID: On Tue, 8 Oct 2024 09:42:15 GMT, Andrew Haley wrote: >> Agreed. Would be nice to have an established mechanism for this though. I think we could do better than a macro but it should do as well. > >> Agreed. Would be nice to have an established mechanism for this though. I think we could do better than a macro but it should do as well. > > I'm not sure we could do _much_ better. A great advantage of using a macro is that it enforces consistent naming across the stub and the inlined code. Hi @theRealAph , could you re-review this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21286#discussion_r1827451617 From stuefe at openjdk.org Mon Nov 4 09:47:41 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 4 Nov 2024 09:47:41 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: <7TqkESttaCcs6m24LxWAp2Z5xoOARCTJfvH6GBMA5vw=.4076d8a2-48b9-4368-a5c8-3b48a09716dc@github.com> On Mon, 4 Nov 2024 09:28:50 GMT, Alan Bateman wrote: > > Can we get rid of `JNICALL` too, please? > > Or would that change be too big? > > There's >1000 in java.base, lots more elsewhere, so it would be a lot of files and would hide the core changes. So maybe for a follow-up PR that does the one thing. Yeah. I count >8000 places in total... Maybe just define JNICALL to be empty in jni_md.h for now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2454234501 From kbarrett at openjdk.org Mon Nov 4 10:01:45 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 4 Nov 2024 10:01:45 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Mon, 4 Nov 2024 09:11:16 GMT, David Holmes wrote: >> The deletion is apparently working, else we'd be getting build failures. So >> while there are some potential issues and opportunities for further cleanup in >> this file, I think they ought to be addressed separately from this PR. See >> new https://bugs.openjdk.org/browse/JDK-8343530. > > There is a difference between "working" and not causing a build failure. I suspect none of that code is actually needed these days, but I'm not sure. As deleting the entire section goes beyond deleting 32-bit code, I would expect it to be partially restored in this PR and then cleaned up in a later PR. "using namespace std;" in a header is generally a bad idea. It brings all kinds of stuff into scope, potentially leading to name conflicts down the road. And seems like a strange thing to do only for windows. Removal of the strdup macro is covered by the NONSTDC macros added at build time. It's not a 32bit cleanup either, and you suggested it. Removal of [u]intptr_t definitions will cause a build failure if it results in them being undefined. And getting an incorrect definition from elsewhere seems implausible. I claim this all just isn't needed anymore and can be removed in this PR, just as you suggested for the strdup macro. The 64bit definitions could be added back in this PR (to be removed later by JDK-8343530), but that just seems like useless churn. So I'm happy with the current removal of the entire chunk. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827469354 From rehn at openjdk.org Mon Nov 4 10:54:29 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 4 Nov 2024 10:54:29 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call In-Reply-To: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> Message-ID: <0v8wPT8CHhDLI9XW1f7AuTZVpwquw6fwME_GwD3A1SU=.f7e67985-d46e-4b48-b590-00034bb6af18@github.com> On Fri, 1 Nov 2024 12:08:58 GMT, Fei Yang wrote: > Hi, please consider this cleanup change. > > The old trampoline call on linux-riscv64 is disabled by default after: https://bugs.openjdk.org/browse/JDK-8332689. > And the new solution (load target address from stub and call) has been baked in jdk master for quite some time. > This propose to remove the old trampoline call related logic so that the code will be cleaner and easier to maintain. > As we are still using `trampoline_stub_Relocation` for the stub, I kept using the original `emit_trampoline_stub` name. > > Testing on linux-riscv64: > - [x] tier1-tier3 (release) > - [x] hotspot:tier1 (fastdebug) Can we change the name to something like address or far address stub? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21822#issuecomment-2454392816 From fyang at openjdk.org Mon Nov 4 11:07:29 2024 From: fyang at openjdk.org (Fei Yang) Date: Mon, 4 Nov 2024 11:07:29 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call In-Reply-To: <0v8wPT8CHhDLI9XW1f7AuTZVpwquw6fwME_GwD3A1SU=.f7e67985-d46e-4b48-b590-00034bb6af18@github.com> References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> <0v8wPT8CHhDLI9XW1f7AuTZVpwquw6fwME_GwD3A1SU=.f7e67985-d46e-4b48-b590-00034bb6af18@github.com> Message-ID: On Mon, 4 Nov 2024 10:51:58 GMT, Robbin Ehn wrote: > Can we change the name to something like address or far address stub? > > I think this comment, `Emit a trampoline stub for a call to a target` would be much easier to understand what really happens, if we say address stub. Hmm ... How about names like `reloc_call_address_stub` and `max_reloc_call_stub_size`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21822#issuecomment-2454408587 From rehn at openjdk.org Mon Nov 4 11:07:29 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 4 Nov 2024 11:07:29 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call In-Reply-To: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> Message-ID: On Fri, 1 Nov 2024 12:08:58 GMT, Fei Yang wrote: > Hi, please consider this cleanup change. > > The old trampoline call on linux-riscv64 is disabled by default after: https://bugs.openjdk.org/browse/JDK-8332689. > And the new solution (load target address from stub and call) has been baked in jdk master for quite some time. > This propose to remove the old trampoline call related logic so that the code will be cleaner and easier to maintain. > As we are still using `trampoline_stub_Relocation` for the stub, I kept using the original `emit_trampoline_stub` name. > > Testing on linux-riscv64: > - [x] tier1-tier3 (release) > - [x] hotspot:tier1 (fastdebug) Yea, reloc_call_address_stub, sounds nice. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21822#issuecomment-2454418829 From shade at openjdk.org Mon Nov 4 11:52:28 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 4 Nov 2024 11:52:28 GMT Subject: RFR: 8343167: Unnecessary define checks in InterpreterRuntime after JDK-8199809 In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 19:36:42 GMT, Aleksey Shipilev wrote: > [JDK-8199809](https://bugs.openjdk.org/browse/JDK-8199809) left a few unnecessary things in InterpreterRuntime::SignatureHandlerGenerator::SignatureHandlerGenerator. In `interpreterRT_x86_64.cpp`: no need for `AMD64` checks. In `interpreterRT_x86_32.cpp`: no need for `AMD64` and `WIN64` checks. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `make bootcycle-images` > - [x] Linux x86_32 server fastdebug, `make bootcycle-images` > - [x] GHA Still waiting for @coleenp's ack :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/21747#issuecomment-2454508390 From jbechberger at openjdk.org Mon Nov 4 12:02:32 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Mon, 4 Nov 2024 12:02:32 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v5] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision: - Tag methods and classes in the signal handler This should be valid, as the tagging only uses atomic boolean bit operations. This should prevent the methods and classes from being unloaded before they are written out by JFR. - Half size of JfrAsyncStackFrame Encode line=-1 in the type and remove the Klass pointer, reducing the size of the JfrAsyncStackFrame class from 32 to 16 bytes. Effectively halving the memory required for the queue. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/ddec72bc..1e0dbaea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=03-04 Stats: 38 lines in 2 files changed: 25 ins; 2 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From roland at openjdk.org Mon Nov 4 12:25:42 2024 From: roland at openjdk.org (Roland Westrelin) Date: Mon, 4 Nov 2024 12:25:42 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) [v4] In-Reply-To: References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> Message-ID: On Thu, 17 Oct 2024 10:10:56 GMT, Galder Zamarre?o wrote: >> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance. >> >> Currently vectorization does not kick in for loops containing either of these calls because of the following error: >> >> >> VLoop::check_preconditions: failed: control flow in loop not allowed >> >> >> The control flow is due to the java implementation for these methods, e.g. >> >> >> public static long max(long a, long b) { >> return (a >= b) ? a : b; >> } >> >> >> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively. >> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization. >> E.g. >> >> >> SuperWord::transform_loop: >> Loop: N518/N126 counted [int,int),+4 (1025 iters) main has_sfpt strip_mined >> 518 CountedLoop === 518 246 126 [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21) >> >> >> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1): >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java >> 1 1 0 0 >> ============================== >> TEST SUCCESS >> >> long min 1155 >> long max 1173 >> >> >> After the patch, on darwin/aarch64 (M1): >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java >> 1 1 0 0 >> ============================== >> TEST SUCCESS >> >> long min 1042 >> long max 1042 >> >> >> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes. >> Therefore, it still relies on the macro expansion to transform those into CMoveL. >> >> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results: >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PA... > > Galder Zamarre?o 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 30 additional commits since the last revision: > > - Use same default size as in other vector reduction benchmarks > - Renamed benchmark class > - Double/Float tests only when avx enabled > - Make state class non-final > - Restore previous benchmark iterations and default param size > - Add clipping range benchmark that uses min/max > - Encapsulate benchmark state within an inner class > - Avoid creating result array in benchmark method > - Merge branch 'master' into topic.intrinsify-max-min-long > - Revert "Implement cmovL as a jump+mov branch" > > This reverts commit 1522e26bf66c47b780ebd0d0d0c4f78a4c564e44. > - ... and 20 more: https://git.openjdk.org/jdk/compare/b7ec22c4...0a8718e1 Looks good to me. ------------- Marked as reviewed by roland (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20098#pullrequestreview-2412925659 From fyang at openjdk.org Mon Nov 4 12:25:49 2024 From: fyang at openjdk.org (Fei Yang) Date: Mon, 4 Nov 2024 12:25:49 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v2] In-Reply-To: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> Message-ID: <2sK69C2o504u42d9Dq30fbwmKfwdT0Mn3OGTtxDJX9g=.9affa3a6-7cc2-476b-b19e-6775bf5f8912@github.com> > Hi, please consider this cleanup change. > > The old trampoline call on linux-riscv64 is disabled by default after: https://bugs.openjdk.org/browse/JDK-8332689. > And the new solution (load target address from stub and call) has been baked in jdk master for quite some time. > This propose to remove the old trampoline call related logic so that the code will be cleaner and easier to maintain. > As we are still using `trampoline_stub_Relocation` for the stub, I kept using the original `emit_trampoline_stub` name. > > Testing on linux-riscv64: > - [x] tier1-tier3 (release) > - [x] hotspot:tier1 (fastdebug) Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21822/files - new: https://git.openjdk.org/jdk/pull/21822/files/37f1c85c..714bf040 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21822&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21822&range=00-01 Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/21822.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21822/head:pull/21822 PR: https://git.openjdk.org/jdk/pull/21822 From fyang at openjdk.org Mon Nov 4 12:25:49 2024 From: fyang at openjdk.org (Fei Yang) Date: Mon, 4 Nov 2024 12:25:49 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call In-Reply-To: References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> Message-ID: <7W5s2uIBIJtvOmuP1FqfoDE9xJhFn41CMdxR-_9AyHs=.95318a95-f574-49ec-ab40-a9e72ab1873a@github.com> On Mon, 4 Nov 2024 11:04:25 GMT, Robbin Ehn wrote: > Yea, reloc_call_address_stub, sounds nice. OK. I have renamed it accordingly. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21822#issuecomment-2454579241 From aph at openjdk.org Mon Nov 4 13:13:32 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 4 Nov 2024 13:13:32 GMT Subject: RFR: 8341194: [REDO] Implement C2 VectorizedHashCode on AArch64 [v2] In-Reply-To: <1et13399iAB7nE79C_UCtljStqiP46OnP120XjbuyC4=.427dd552-ef34-450e-b67f-e5d752fd8dbb@github.com> References: <1et13399iAB7nE79C_UCtljStqiP46OnP120XjbuyC4=.427dd552-ef34-450e-b67f-e5d752fd8dbb@github.com> Message-ID: On Tue, 8 Oct 2024 09:47:47 GMT, Mikhail Ablakatov wrote: >> Fix and redo [JDK-8322770](https://bugs.openjdk.org/browse/JDK-8322770) which got backed out in [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197) due to test failures / jlink failure. Initial PR: https://github.com/openjdk/jdk/pull/18487. >> >> Compared to the initial PR, this one eliminates a mismatch between the `arrays_hashcode()` template and stub. The template defined v0-v7 & v12-v17 as TEMP registers but the stub used v8-v9 which were not on the list. Changing v8-v9 in the stub to v12-v13 eliminates this mismatch. Other changes in aarch64.ad is just a cleanup as some registers on the list were not used by the stub at all anymore. >> >> Following the discussion on [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197), we've added a `make bootcycle-images` step to our local CI pipeline to verify that the issue is fixed. > > Mikhail Ablakatov has updated the pull request incrementally with one additional commit since the last revision: > > Ensure that the inline code and the stub use the same registers Still good. ------------- Marked as reviewed by aph (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21286#pullrequestreview-2413025116 From jsjolen at openjdk.org Mon Nov 4 13:15:29 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 4 Nov 2024 13:15:29 GMT Subject: RFR: 8328944: NMT reports "unknown" memory In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 08:34:00 GMT, Thomas Stuefe wrote: > > Eventually the goal would be not to use mtNone anywhere, but we are not there quite yet. > > I think this is neither realistic nor desirable. mtNone means "don't know yet; will do later". This is perfectly valid for cases where > > * you allocate something on behalf of someone else; obviously, you don't know what he intends to do with it > > * when you reserve a range that is later shared by multiple tags. > > > If we move to more fine granular tags, or something like hierarchical tags, the latter point will become more important. Therefore, mtNone has its place. It seems to me like the first case isn't a case at all, as that someone else can always give you a tag for the memory. With more granular or hierarchical tags, the case for `mtNone` seems even rarer. We can then always have a top-level tag for the category: `mtCardTable <: mtGC`. Now I'm just thinking out loud: `mtNone` could be renamed to `mtAny` in the case that we do have hierarchical tags, as to represent `top` in a partially ordered set. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21843#issuecomment-2454684099 From mli at openjdk.org Mon Nov 4 13:20:30 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 4 Nov 2024 13:20:30 GMT Subject: RFR: 8343502: RISC-V: SIGBUS in updateBytesCRC32 after JDK-8339738 In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 03:48:48 GMT, Fei Yang wrote: > Hi, please review this small change. > > [JDK-8339738](https://bugs.openjdk.org/browse/JDK-8339738) adds vectorization for crc32 intrinsic, which does `vle32.v` from the input byte buffer and calculates the checksum. But the input byte buffer could be misaligned (not 4-byte aligned). This leads to SIGBUS on hardware platforms like `BPI-F3` board where misaligned vector loads are not supported. Similar issue is there for scalar version as well, which could mean performance issue on other hardwares. Patch fixes this issue by adding a small alignment processing on entry for both scalar and vector version. > > This also fixes another potential issue in tail handling, where we do a single `lwu` for both versions to load the remaining bytes from the input byte buffer and extract each byte from the loaded 32-bit value. Since we only have less than 4 bytes remaining, this `lwu` would exceed the buffer limit, which I think is not safe. Patch fixes this issue by doing three separate `lbu` instead. > > Testing on `BPI-F3` with RVV 1.0 extension: > - [x] test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java > - [x] test/jdk/java/util/zip/TestCRC32.java > - [x] SPECjbb2015 > > No obvious impact witnessed on `micro:java.util.TestCRC32`: > > > Before: > Benchmark (count) Mode Cnt Score Error Units > TestCRC32.testCRC32Update 64 thrpt 12 4778.903 ? 1.793 ops/ms > TestCRC32.testCRC32Update 128 thrpt 12 2655.639 ? 2.958 ops/ms > TestCRC32.testCRC32Update 256 thrpt 12 1430.997 ? 0.970 ops/ms > TestCRC32.testCRC32Update 512 thrpt 12 965.785 ? 1.840 ops/ms > TestCRC32.testCRC32Update 2048 thrpt 12 303.056 ? 0.620 ops/ms > TestCRC32.testCRC32Update 16384 thrpt 12 40.601 ? 0.220 ops/ms > TestCRC32.testCRC32Update 65536 thrpt 12 9.575 ? 0.045 ops/ms > TestCRC32C.testCRC32CUpdate 64 thrpt 12 3923.698 ? 23.209 ops/ms > TestCRC32C.testCRC32CUpdate 128 thrpt 12 2514.616 ? 22.991 ops/ms > TestCRC32C.testCRC32CUpdate 256 thrpt 12 1477.223 ? 2.319 ops/ms > TestCRC32C.testCRC32CUpdate 512 thrpt 12 806.179 ? 1.961 ops/ms > TestCRC32C.testCRC32CUpdate 2048 thrpt 12 216.396 ? 0.172 ops/ms > TestCRC32C.testCRC32CUpdate 16384 thrpt 12 27.526 ? 0.049 ops/ms > TestCRC32C.testCRC32CUpdate 65536 thrpt 12 6.530 ? 0.041 ops/ms > > After: > Benchmark (count) Mode Cnt Score Error Units > TestCRC32.testCRC32Update 64 ... Thanks for catching and fix. Just one minor comment about the tail processing. src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1649: > 1647: > 1648: subw(len, len, 1); > 1649: lbu(tmp1, Address(buf)); I guess after the alignment prelogue added in this pr, the previous tail implementation should be fine now. As in the case of both java heap and native heap, the tail of passed-in buf can not cross the boundary of pages. ------------- PR Review: https://git.openjdk.org/jdk/pull/21863#pullrequestreview-2413039664 PR Review Comment: https://git.openjdk.org/jdk/pull/21863#discussion_r1827716303 From coleenp at openjdk.org Mon Nov 4 13:21:28 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 4 Nov 2024 13:21:28 GMT Subject: RFR: 8343167: Unnecessary define checks in InterpreterRuntime after JDK-8199809 In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 19:36:42 GMT, Aleksey Shipilev wrote: > [JDK-8199809](https://bugs.openjdk.org/browse/JDK-8199809) left a few unnecessary things in InterpreterRuntime::SignatureHandlerGenerator::SignatureHandlerGenerator. In `interpreterRT_x86_64.cpp`: no need for `AMD64` checks. In `interpreterRT_x86_32.cpp`: no need for `AMD64` and `WIN64` checks. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `make bootcycle-images` > - [x] Linux x86_32 server fastdebug, `make bootcycle-images` > - [x] GHA Sorry I didn't see this. This looks fine. Hopefully the _32 file can get removed soon. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21747#pullrequestreview-2413046086 From mli at openjdk.org Mon Nov 4 13:27:28 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 4 Nov 2024 13:27:28 GMT Subject: RFR: 8343502: RISC-V: SIGBUS in updateBytesCRC32 after JDK-8339738 In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 03:48:48 GMT, Fei Yang wrote: > Hi, please review this small change. > > [JDK-8339738](https://bugs.openjdk.org/browse/JDK-8339738) adds vectorization for crc32 intrinsic, which does `vle32.v` from the input byte buffer and calculates the checksum. But the input byte buffer could be misaligned (not 4-byte aligned). This leads to SIGBUS on hardware platforms like `BPI-F3` board where misaligned vector loads are not supported. Similar issue is there for scalar version as well, which could mean performance issue on other hardwares. Patch fixes this issue by adding a small alignment processing on entry for both scalar and vector version. > > This also fixes another potential issue in tail handling, where we do a single `lwu` for both versions to load the remaining bytes from the input byte buffer and extract each byte from the loaded 32-bit value. Since we only have less than 4 bytes remaining, this `lwu` would exceed the buffer limit, which I think is not safe. Patch fixes this issue by doing three separate `lbu` instead. > > Testing on `BPI-F3` with RVV 1.0 extension: > - [x] test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java > - [x] test/jdk/java/util/zip/TestCRC32.java > - [x] SPECjbb2015 > > No obvious impact witnessed on `micro:java.util.TestCRC32`: > > > Before: > Benchmark (count) Mode Cnt Score Error Units > TestCRC32.testCRC32Update 64 thrpt 12 4778.903 ? 1.793 ops/ms > TestCRC32.testCRC32Update 128 thrpt 12 2655.639 ? 2.958 ops/ms > TestCRC32.testCRC32Update 256 thrpt 12 1430.997 ? 0.970 ops/ms > TestCRC32.testCRC32Update 512 thrpt 12 965.785 ? 1.840 ops/ms > TestCRC32.testCRC32Update 2048 thrpt 12 303.056 ? 0.620 ops/ms > TestCRC32.testCRC32Update 16384 thrpt 12 40.601 ? 0.220 ops/ms > TestCRC32.testCRC32Update 65536 thrpt 12 9.575 ? 0.045 ops/ms > TestCRC32C.testCRC32CUpdate 64 thrpt 12 3923.698 ? 23.209 ops/ms > TestCRC32C.testCRC32CUpdate 128 thrpt 12 2514.616 ? 22.991 ops/ms > TestCRC32C.testCRC32CUpdate 256 thrpt 12 1477.223 ? 2.319 ops/ms > TestCRC32C.testCRC32CUpdate 512 thrpt 12 806.179 ? 1.961 ops/ms > TestCRC32C.testCRC32CUpdate 2048 thrpt 12 216.396 ? 0.172 ops/ms > TestCRC32C.testCRC32CUpdate 16384 thrpt 12 27.526 ? 0.049 ops/ms > TestCRC32C.testCRC32CUpdate 65536 thrpt 12 6.530 ? 0.041 ops/ms > > After: > Benchmark (count) Mode Cnt Score Error Units > TestCRC32.testCRC32Update 64 ... Does the non-alignment data cause any similar issue with other intrinsics? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21863#issuecomment-2454710709 From stuefe at openjdk.org Mon Nov 4 13:33:31 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 4 Nov 2024 13:33:31 GMT Subject: RFR: 8328944: NMT reports "unknown" memory In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 13:12:52 GMT, Johan Sj?len wrote: > > > Eventually the goal would be not to use mtNone anywhere, but we are not there quite yet. > > > > > > I think this is neither realistic nor desirable. mtNone means "don't know yet; will do later". This is perfectly valid for cases where > > ``` > > * you allocate something on behalf of someone else; obviously, you don't know what he intends to do with it > > > > * when you reserve a range that is later shared by multiple tags. > > ``` > > > > > > > > > > > > > > > > > > > > > > > > If we move to more fine granular tags, or something like hierarchical tags, the latter point will become more important. Therefore, mtNone has its place. > > It seems to me like the first case isn't a case at all, as that someone else can always give you a tag for the memory. The requirement of having to funnel MemTags through call chains makes the code brittle and inflexible to work with. You need to modify every single call frame to marshall that tag through to the eventual place where it gets tracked. Apart from that hassle, you may not even know. An allocator can allocate a range en-block and hand it out piecemeal to different users. Currently, that whole range is then tagged as belonging to the allocator, which is a bit useless tbh. E.g. the full class space range is tagged as mtClass. Every ResourceArea chunk is tagged as RA. That is very coarse-granular, and there is no way to have finer-grained tagging. I often wished for that at customer sites. Bottomline, allocation operations on the system level don't necessarily map 1:1 to NMT semantic tagging. We should not hard-code this requirement into NMT. It limits the future usefulness of NMT, and/or limits how we allow ourselves to allocate memory (which should always take the most efficient route and not be limited by what NMT can or can't do). > With more granular or hierarchical tags, the case for `mtNone` seems even rarer. We can then always have a top-level tag for the category: `mtCardTable <: mtGC`. > > Now I'm just thinking out loud: `mtNone` could be renamed to `mtAny` in the case that we do have hierarchical tags, as to represent `top` in a partially ordered set. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21843#issuecomment-2454725202 From rehn at openjdk.org Mon Nov 4 13:37:31 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 4 Nov 2024 13:37:31 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v2] In-Reply-To: <2sK69C2o504u42d9Dq30fbwmKfwdT0Mn3OGTtxDJX9g=.9affa3a6-7cc2-476b-b19e-6775bf5f8912@github.com> References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> <2sK69C2o504u42d9Dq30fbwmKfwdT0Mn3OGTtxDJX9g=.9affa3a6-7cc2-476b-b19e-6775bf5f8912@github.com> Message-ID: On Mon, 4 Nov 2024 12:25:49 GMT, Fei Yang wrote: >> Hi, please consider this cleanup change. >> >> The old trampoline call on linux-riscv64 is disabled by default after: https://bugs.openjdk.org/browse/JDK-8332689. >> And the new solution (load target address from stub and call) has been baked in jdk master for quite some time. >> This propose to remove the old trampoline call related logic so that the code will be cleaner and easier to maintain. >> As we are still using `trampoline_stub_Relocation` for the stub, I kept using the original `emit_trampoline_stub` name. >> >> Testing on linux-riscv64: >> - [x] tier1-tier3 (release) >> - [x] hotspot:tier1 (fastdebug) > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Comment Thanks! I think there are some more places to fix naming. src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.hpp line 70: > 68: // call stub: CompiledDirectCall::to_interp_stub_size() + > 69: // CompiledDirectCall::to_trampoline_stub_size() > 70: _call_stub_size = 11 * MacroAssembler::instruction_size + MacroAssembler::NativeFarCall::trampoline_size, I think this should call_address_stub also? src/hotspot/cpu/riscv/compiledIC_riscv.cpp line 73: > 71: int CompiledDirectCall::to_trampoline_stub_size() { > 72: // We count size of target address and an additional alignment nop. > 73: // Trampoline stubs are always word aligned. Call address stub? src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 1597: > 1595: > 1596: enum NativeFarCall { > 1597: trampoline_size = 1 * instruction_size + wordSize, Call address stub size? ------------- PR Review: https://git.openjdk.org/jdk/pull/21822#pullrequestreview-2413075762 PR Review Comment: https://git.openjdk.org/jdk/pull/21822#discussion_r1827738318 PR Review Comment: https://git.openjdk.org/jdk/pull/21822#discussion_r1827739171 PR Review Comment: https://git.openjdk.org/jdk/pull/21822#discussion_r1827740543 From stefank at openjdk.org Mon Nov 4 13:44:46 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 4 Nov 2024 13:44:46 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v5] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Mon, 21 Oct 2024 21:16:50 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 492 commits: > > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - Merge > - 8342560: GenShen: Fix confusing method name > > Reviewed-by: ysr > - 8342564: GenShen: Only reference young/old generation names in generational mode > > Reviewed-by: xpeng, ysr > - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - 8342214: GenShen: Reduce code duplication in shFreeSet with iterator abstraction > > Reviewed-by: kdnilsen, ysr > - 8342239: GenShen: Revert changes in adaptive heuristic to avoid overflow on 32 bit > > Reviewed-by: ysr > - 8342278: GenShen: Move non-generational mode test out of generational test configuration > > Reviewed-by: ysr > - 8342255: GenShen: Remove unnecessary enum initial values > > Reviewed-by: ysr > - ... and 482 more: https://git.openjdk.org/jdk/compare/71583222...2a2aa408 The changes to the shared code is minimal and looks good. ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2413104483 From fbredberg at openjdk.org Mon Nov 4 14:00:55 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Mon, 4 Nov 2024 14:00:55 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v9] In-Reply-To: References: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com> <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com> Message-ID: On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang wrote: >> Changed. > > Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? > > (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd) As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case. Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827720269 From mli at openjdk.org Mon Nov 4 14:11:30 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 4 Nov 2024 14:11:30 GMT Subject: RFR: 8343471: RISC-V: compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java fails after JDK-8334999 In-Reply-To: References: Message-ID: On Sat, 2 Nov 2024 09:22:31 GMT, Fei Yang wrote: > Hi, please review this small change. > > The test expects a message like `warning: AES instructions are not available on this CPU` for all cpu platforms without AES support. After https://bugs.openjdk.org/browse/JDK-8334999, we report this `warning: AES intrinsics require Zvkn extension (not available on this CPU)` on RISC-V platforms where `Zvkn` extension is not available. Patch fixes this message making it consistent with other CPU platforms. Same test passes with this fix. Looks good. ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21847#pullrequestreview-2413170316 From mbaesken at openjdk.org Mon Nov 4 14:16:43 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 4 Nov 2024 14:16:43 GMT Subject: RFR: 8342893: Highlight special values in hserr file printing Message-ID: There are some special values indicating memory corruption or problematic states. Those should be highlighted / pointed out in some way when printing parts of the hserr / hsinfo file (like register values or locations), ------------- Commit messages: - do checks in debug - JDK-8342893 Changes: https://git.openjdk.org/jdk/pull/21811/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21811&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342893 Stats: 229 lines in 10 files changed: 53 ins; 73 del; 103 mod Patch: https://git.openjdk.org/jdk/pull/21811.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21811/head:pull/21811 PR: https://git.openjdk.org/jdk/pull/21811 From heidinga at openjdk.org Mon Nov 4 14:23:33 2024 From: heidinga at openjdk.org (Dan Heidinga) Date: Mon, 4 Nov 2024 14:23:33 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v6] In-Reply-To: <8IyBT_SVLgsOjXogoorL6m3SmYK8OVzJDpRv-MH4MaA=.7f7f50c3-db38-4418-9381-9f915bb07470@github.com> References: <8IyBT_SVLgsOjXogoorL6m3SmYK8OVzJDpRv-MH4MaA=.7f7f50c3-db38-4418-9381-9f915bb07470@github.com> Message-ID: On Mon, 4 Nov 2024 03:08:02 GMT, Ioi Lam wrote: >> src/hotspot/share/cds/aotClassInitializer.cpp line 348: >> >>> 346: } >>> 347: JavaValue result(T_VOID); >>> 348: JavaCalls::call_static(&result, ik, >> >> Based on the discussions in JDK-8342283, do we need a memory fence after the call to runtimeSetup? >> >> I think we do to be consistent with the non-AOTCache run as there is a fence after `` (when this code would normally run) due to the initialization lock. > > I think this is already done: > > `runtimeSetup()` is called inside `InstanceKlass::call_class_initializer()`. When that returns, we will proceed to `InstanceKlass::set_initialization_state_and_notify()` which will perform the memory fencing. > > https://github.com/iklam/jdk/blob/6eebd18fc2820ffb179d431f179fc6af6d1be247/src/hotspot/share/oops/instanceKlass.cpp#L1276-L1300 I think you're right about the memory fencing being covered there but reading that code shows another potential issue - what if the `runtimeSetup()` call throws an exception? If I read `InstanceKlass::call_class_initializer()` correctly, an exception from `runtimeSetup()` will lead to marking the class as failing initialization (`initialization_error`) which will be an unexpected outcome as there may be instances of the class in the AOTCache that aren't produced by paths through the `` method. Classes are able to create an instance in `` and escape it to other code and then fail initialization. The instances are left in an odd state where after the `` the instance methods can be called but static fields and static methods can't be accessed. `runtimeSetup()` expands on this corner case which I think is OK for current "crawl" stage of our "crawl-walk-run" approach as its analogous to the existing `` behaviour. It may need refining in the future to abort the VM or do something else (?) in the case of failed `runtimeSetup` calls ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1827813351 From aboldtch at openjdk.org Mon Nov 4 14:28:45 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 4 Nov 2024 14:28:45 GMT Subject: RFR: 8340422: ZGC: TestAllocateHeapAt.java should not run with transparent hugepages [v3] In-Reply-To: <7DtNgJ7IORWdKXdZwQsKuWLDG8uZJmGLAQaoFbGcg9I=.95486530-8384-4f65-b0a4-8793139078dd@github.com> References: <7DtNgJ7IORWdKXdZwQsKuWLDG8uZJmGLAQaoFbGcg9I=.95486530-8384-4f65-b0a4-8793139078dd@github.com> Message-ID: > Similarly to [JDK-8340146](https://bugs.openjdk.org/browse/JDK-8340146) / #21127 does not work well with transparent hugepages. > > Because a machine may be configured in such a way that UseTransperetHugePages option gets ignored, the test driver must also check if it will be. As such I extracted the `test/hotspot/jtreg/runtime/os/HugePageConfiguration.java` utility into shared test library. > > On none linux machines the `vm.opt.final.UseTransparentHugePages` will be null, but the test checks `os.family == "linux"` first. I have not observed an issue with the JTREG filter on none linux machines. But will double check that it does not cause an issue. Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8340422 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8340422 - 8340422: ZGC: TestAllocateHeapAt.java should not run with transparent hugepages ------------- Changes: https://git.openjdk.org/jdk/pull/21129/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21129&range=02 Stats: 33 lines in 6 files changed: 30 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/21129.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21129/head:pull/21129 PR: https://git.openjdk.org/jdk/pull/21129 From shade at openjdk.org Mon Nov 4 14:39:36 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 4 Nov 2024 14:39:36 GMT Subject: RFR: 8343167: Unnecessary define checks in InterpreterRuntime after JDK-8199809 In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 19:36:42 GMT, Aleksey Shipilev wrote: > [JDK-8199809](https://bugs.openjdk.org/browse/JDK-8199809) left a few unnecessary things in InterpreterRuntime::SignatureHandlerGenerator::SignatureHandlerGenerator. In `interpreterRT_x86_64.cpp`: no need for `AMD64` checks. In `interpreterRT_x86_32.cpp`: no need for `AMD64` and `WIN64` checks. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `make bootcycle-images` > - [x] Linux x86_32 server fastdebug, `make bootcycle-images` > - [x] GHA Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21747#issuecomment-2454882551 From shade at openjdk.org Mon Nov 4 14:39:36 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 4 Nov 2024 14:39:36 GMT Subject: Integrated: 8343167: Unnecessary define checks in InterpreterRuntime after JDK-8199809 In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 19:36:42 GMT, Aleksey Shipilev wrote: > [JDK-8199809](https://bugs.openjdk.org/browse/JDK-8199809) left a few unnecessary things in InterpreterRuntime::SignatureHandlerGenerator::SignatureHandlerGenerator. In `interpreterRT_x86_64.cpp`: no need for `AMD64` checks. In `interpreterRT_x86_32.cpp`: no need for `AMD64` and `WIN64` checks. > > Additional testing: > - [x] Linux x86_64 server fastdebug, `make bootcycle-images` > - [x] Linux x86_32 server fastdebug, `make bootcycle-images` > - [x] GHA This pull request has now been integrated. Changeset: b74652b5 Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/b74652b5f4424419b36888514730ac7550f42a6b Stats: 12 lines in 2 files changed: 0 ins; 12 del; 0 mod 8343167: Unnecessary define checks in InterpreterRuntime after JDK-8199809 Reviewed-by: phh, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/21747 From mli at openjdk.org Mon Nov 4 14:51:29 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 4 Nov 2024 14:51:29 GMT Subject: RFR: 8343502: RISC-V: SIGBUS in updateBytesCRC32 after JDK-8339738 In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 03:48:48 GMT, Fei Yang wrote: > Hi, please review this small change. > > [JDK-8339738](https://bugs.openjdk.org/browse/JDK-8339738) adds vectorization for crc32 intrinsic, which does `vle32.v` from the input byte buffer and calculates the checksum. But the input byte buffer could be misaligned (not 4-byte aligned). This leads to SIGBUS on hardware platforms like `BPI-F3` board where misaligned vector loads are not supported. Similar issue is there for scalar version as well, which could mean performance issue on other hardwares. Patch fixes this issue by adding a small alignment processing on entry for both scalar and vector version. > > This also fixes another potential issue in tail handling, where we do a single `lwu` for both versions to load the remaining bytes from the input byte buffer and extract each byte from the loaded 32-bit value. Since we only have less than 4 bytes remaining, this `lwu` would exceed the buffer limit, which I think is not safe. Patch fixes this issue by doing three separate `lbu` instead. > > Testing on `BPI-F3` with RVV 1.0 extension: > - [x] test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java > - [x] test/jdk/java/util/zip/TestCRC32.java > - [x] SPECjbb2015 > > No obvious impact witnessed on `micro:java.util.TestCRC32`: > > > Before: > Benchmark (count) Mode Cnt Score Error Units > TestCRC32.testCRC32Update 64 thrpt 12 4778.903 ? 1.793 ops/ms > TestCRC32.testCRC32Update 128 thrpt 12 2655.639 ? 2.958 ops/ms > TestCRC32.testCRC32Update 256 thrpt 12 1430.997 ? 0.970 ops/ms > TestCRC32.testCRC32Update 512 thrpt 12 965.785 ? 1.840 ops/ms > TestCRC32.testCRC32Update 2048 thrpt 12 303.056 ? 0.620 ops/ms > TestCRC32.testCRC32Update 16384 thrpt 12 40.601 ? 0.220 ops/ms > TestCRC32.testCRC32Update 65536 thrpt 12 9.575 ? 0.045 ops/ms > TestCRC32C.testCRC32CUpdate 64 thrpt 12 3923.698 ? 23.209 ops/ms > TestCRC32C.testCRC32CUpdate 128 thrpt 12 2514.616 ? 22.991 ops/ms > TestCRC32C.testCRC32CUpdate 256 thrpt 12 1477.223 ? 2.319 ops/ms > TestCRC32C.testCRC32CUpdate 512 thrpt 12 806.179 ? 1.961 ops/ms > TestCRC32C.testCRC32CUpdate 2048 thrpt 12 216.396 ? 0.172 ops/ms > TestCRC32C.testCRC32CUpdate 16384 thrpt 12 27.526 ? 0.049 ops/ms > TestCRC32C.testCRC32CUpdate 65536 thrpt 12 6.530 ? 0.041 ops/ms > > After: > Benchmark (count) Mode Cnt Score Error Units > TestCRC32.testCRC32Update 64 ... I misred the performance data, the performance data looks good, so I'm fine with patch. Also verified the performance data in my environment. ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21863#pullrequestreview-2413276184 From coleenp at openjdk.org Mon Nov 4 15:32:32 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 4 Nov 2024 15:32:32 GMT Subject: RFR: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf [v2] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 09:02:10 GMT, David Holmes wrote: >> This is mostly an audit of the callers of `Exceptions::fthrow` to ensure unbounded strings can't appear. >> >> There is a code change in DiagnosticCmd parsing to extend the string length limit already used in part of that code. >> >> Testing: >> - tier 1-3 (sanity) >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Restore previous behaviour for zero length strings src/hotspot/share/utilities/exceptions.cpp line 264: > 262: // will be within reasonable limits - specifically we will never hit the INT_MAX limit > 263: // of os::vsnprintf when it tries to report how big a buffer is needed. Even so we > 264: // further limit the formatted output to 1024 characters. If we're chopping off the message at 1024 characters, why do we have to audit the callers? Is it because vsnprintf will overflow before truncating the message? Seems like it could be easy to add a caller that breaks this. There's no way to check here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21867#discussion_r1827926037 From ihse at openjdk.org Mon Nov 4 16:11:44 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 16:11:44 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> <5uPCX6VhNrAelasUotfss6G7iKyAHcyz7Fq2WiB8oZI=.db06929c-b219-4969-853f-9f68549723b3@github.com> Message-ID: On Sat, 2 Nov 2024 07:51:20 GMT, Alexander Zuev wrote: >> make/modules/jdk.accessibility/Lib.gmk line 57: >> >>> 55: TARGETS += $(BUILD_LIBJAVAACCESSBRIDGE) >>> 56: >>> 57: ############################################################################## >> >> Most of the desktop related changes are related to Assistive Technologies >> I don't think we currently provide a 32-bit windowsaccessbridge.dll in the 64 bit JDK, but I'd like to be sure I am not forgetting something. >> The point being windowsaccessbridge.dll is not loaded by the JDK, but by an AT, so traditionally we provided both 32 and 64 bit versions because we don't control that AT. >> >> So I would like Alex Zuev to review these changes. For whatever reason his git hub handle doesn't seem to be found. I think it is something like @azuev-java > > We built 32-bit dll in order to provide access to the accessibility interfaces for the legacy 32-bit software that can not load the 32-bit code. We abandoned this practice since at least Java 11 and we had no complaints about it ever since. All the relevant accessibility software we are aware of have 64-bit executable and only support 32-bit operating systems with the legacy versions that are not recommended to use with modern OSes. I do not see any problem in abandoning 32-bit code in windowsaccessbridge.dll. @azuev-java Thanks! I have one more question for you: To avoid risking breaking any compatibility, the file generated from the source code in `windowsaccessbridge` is still compiled into a file called `windowsaccessbridge-64.dll`. This is a bit unusual, and requires a quirk in the build system -- normally we assume there is a 1-to-1 relationship between the directory containing the native library source code, and the generated `.dll` file. Is this file exposed to external parties, that rely on a specific name? Or is it just used internally by the JDK, so we could rename it to `windowsaccessbridge.dll`, and just update our reference to it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827989703 From ihse at openjdk.org Mon Nov 4 16:42:26 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 16:42:26 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v20] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Remove __stdcall notation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/d89bc561..fbd91ad0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=18-19 Stats: 119 lines in 13 files changed: 0 ins; 1 del; 118 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From jsikstro at openjdk.org Mon Nov 4 16:23:37 2024 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Mon, 4 Nov 2024 16:23:37 GMT Subject: RFR: 8340422: ZGC: TestAllocateHeapAt.java should not run with transparent hugepages [v3] In-Reply-To: References: <7DtNgJ7IORWdKXdZwQsKuWLDG8uZJmGLAQaoFbGcg9I=.95486530-8384-4f65-b0a4-8793139078dd@github.com> Message-ID: On Mon, 4 Nov 2024 14:28:45 GMT, Axel Boldt-Christmas wrote: >> Similarly to [JDK-8340146](https://bugs.openjdk.org/browse/JDK-8340146) / #21127 does not work well with transparent hugepages. >> >> Because a machine may be configured in such a way that UseTransperetHugePages option gets ignored, the test driver must also check if it will be. As such I extracted the `test/hotspot/jtreg/runtime/os/HugePageConfiguration.java` utility into shared test library. >> >> On none linux machines the `vm.opt.final.UseTransparentHugePages` will be null, but the test checks `os.family == "linux"` first. I have not observed an issue with the JTREG filter on none linux machines. But will double check that it does not cause an issue. > > Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8340422 > - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8340422 > - 8340422: ZGC: TestAllocateHeapAt.java should not run with transparent hugepages Looks good! ------------- Marked as reviewed by jsikstro (Committer). PR Review: https://git.openjdk.org/jdk/pull/21129#pullrequestreview-2413518470 From kvn at openjdk.org Mon Nov 4 16:45:37 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 4 Nov 2024 16:45:37 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v30] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> Message-ID: On Mon, 21 Oct 2024 14:49:47 GMT, Andrew Haley wrote: >> This patch expands the use of a hash table for secondary superclasses >> to the interpreter, C1, and runtime. It also adds a C2 implementation >> of hashed lookup in cases where the superclass isn't known at compile >> time. >> >> HotSpot shared runtime >> ---------------------- >> >> Building hashed secondary tables is now unconditional. It takes very >> little time, and now that the shared runtime always has the tables, it >> might as well take advantage of them. The shared code is easier to >> follow now, I think. >> >> There might be a performance issue with x86-64 in that we build >> HotSpot for a default x86-64 target that does not support popcount. >> This means that HotSpot C++ runtime on x86 always uses a software >> emulation for popcount, even though the vast majority of machines made >> for the past 20 years can do popcount in a single instruction. It >> wouldn't be terribly hard to do something about that. >> >> Having said that, the software popcount is really not bad. >> >> x86 >> --- >> >> x86 is rather tricky, because we still support >> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as >> well as 32- and 64-bit ports. There's some further complication in >> that only `RCX` can be used as a shift count, so there's some register >> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp >> rather gnarly, with multiple levels of conditionals at compile time >> and runtime. >> >> AArch64 >> ------- >> >> AArch64 is considerably more straightforward. We always have a >> popcount instruction and (thankfully) no 32-bit code to worry about. >> >> Generally >> --------- >> >> I would dearly love simply to rip out the "old" secondary supers cache >> support, but I've left it in just in case someone has a performance >> regression. >> >> The versions of `MacroAssembler::lookup_secondary_supers_table` that >> work with variable superclasses don't take a fixed set of temp >> registers, and neither do they call out to to a slow path subroutine. >> Instead, the slow patch is expanded inline. >> >> I don't think this is necessarily bad. Apart from the very rare cases >> where C2 can't determine the superclass to search for at compile time, >> this code is only used for generating stubs, and it seemed to me >> ridiculous to have stubs calling other stubs. >> >> I've followed the guidance from @iwanowww not to obsess too much about >> the performance of C1-compiled secondary supers lookups, and to prefer >> simplicity over absolute performance. Nonetheless, this i... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Correct comment Re-approved after comment update. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19989#pullrequestreview-2413578670 From ihse at openjdk.org Mon Nov 4 16:53:48 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 16:53:48 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <7TqkESttaCcs6m24LxWAp2Z5xoOARCTJfvH6GBMA5vw=.4076d8a2-48b9-4368-a5c8-3b48a09716dc@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> <7TqkESttaCcs6m24LxWAp2Z5xoOARCTJfvH6GBMA5vw=.4076d8a2-48b9-4368-a5c8-3b48a09716dc@github.com> Message-ID: On Mon, 4 Nov 2024 09:45:05 GMT, Thomas Stuefe wrote: >>> Can we get rid of `JNICALL` too, please? >>> >>> Or would that change be too big? >> >> There's >1000 in java.base, lots more elsewhere, so it would be a lot of files and would hide the core changes. So maybe for a follow-up PR that does the one thing. > >> > Can we get rid of `JNICALL` too, please? >> > Or would that change be too big? >> >> There's >1000 in java.base, lots more elsewhere, so it would be a lot of files and would hide the core changes. So maybe for a follow-up PR that does the one thing. > > Yeah. I count >8000 places in total... > > Maybe just define JNICALL to be empty in jni_md.h for now. @tstuefe Your comment reminded me of another important cleanup, to remove `__stdcall` (and `_stdcall`, an accepted but not recommended variant) from the code base. This only has meaning on 32-bit Windows. Furthermore, when searching for this, I found additional code that is looking for symbol names of "__stdcall format", i.e. `@`. This is not needed anymore. I'll delete it where I find it, but there might be other places that I'm missing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455215002 From ihse at openjdk.org Mon Nov 4 16:23:06 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 16:23:06 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v18] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Restore code in adlc.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/68d6fe5a..c6dce38d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=16-17 Stats: 27 lines in 1 file changed: 27 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Mon Nov 4 16:23:06 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 16:23:06 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v18] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Mon, 4 Nov 2024 09:58:49 GMT, Kim Barrett wrote: >> There is a difference between "working" and not causing a build failure. I suspect none of that code is actually needed these days, but I'm not sure. As deleting the entire section goes beyond deleting 32-bit code, I would expect it to be partially restored in this PR and then cleaned up in a later PR. > > "using namespace std;" in a header is generally a bad idea. It brings all > kinds of stuff into scope, potentially leading to name conflicts down the > road. And seems like a strange thing to do only for windows. > > Removal of the strdup macro is covered by the NONSTDC macros added at build > time. It's not a 32bit cleanup either, and you suggested it. > > Removal of [u]intptr_t definitions will cause a build failure if it results in > them being undefined. And getting an incorrect definition from elsewhere seems > implausible. I claim this all just isn't needed anymore and can be removed in > this PR, just as you suggested for the strdup macro. The 64bit definitions > could be added back in this PR (to be removed later by JDK-8343530), but that > just seems like useless churn. > > So I'm happy with the current removal of the entire chunk. It was already quite tangential to the 32-bit windows removal effort. I've restored the original code (with the exception of the 32-bit Windows part) in this PR, so we don't have to argue about that. Let's remove this as a separate effort, presumably as part of JDK-8343530. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1828003651 From ihse at openjdk.org Mon Nov 4 16:23:06 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 16:23:06 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <7TqkESttaCcs6m24LxWAp2Z5xoOARCTJfvH6GBMA5vw=.4076d8a2-48b9-4368-a5c8-3b48a09716dc@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> <7TqkESttaCcs6m24LxWAp2Z5xoOARCTJfvH6GBMA5vw=.4076d8a2-48b9-4368-a5c8-3b48a09716dc@github.com> Message-ID: On Mon, 4 Nov 2024 09:45:05 GMT, Thomas Stuefe wrote: > Can we get rid of `JNICALL` too, please? That we can never do, since it is part of jni.h which are imported in likely millions of JNI projects. But we can replace it with an empty define. And we can document it as not needed anymore, and start removing it from our own call sites. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455142166 From ihse at openjdk.org Mon Nov 4 16:28:14 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 16:28:14 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v19] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Make JNICALL an empty define on all platforms ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/c6dce38d..d89bc561 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=17-18 Stats: 7 lines in 3 files changed: 2 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Mon Nov 4 15:45:36 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 15:45:36 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v8] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> <0SV1CZsC4-4qlECRdXAsTtfA4SFMOizXH2pZqYggJtM=.d69355b4-ac64-4a9a-836e-957085f04b09@github.com> <-KTe_Kv55w9u0xR8YeEEHDYvYCv3YCUzc9EBac6jL4c=.13b8e842-a9e0-451e-b8c9-6519d9932d57@github.com> Message-ID: On Sun, 3 Nov 2024 05:06:04 GMT, Jiangli Zhou wrote: > Please fix the debugging symbol issue in your PR. That is a request with most likely a whole other magnitude of difficulty. Our handling of debug symbols and all its intricacies is tightly coupled to the existing dynamic linking process. I suggest handling that as a follow-up PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2455052907 From ihse at openjdk.org Mon Nov 4 15:45:35 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 15:45:35 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v9] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Sun, 3 Nov 2024 20:23:32 GMT, Jiangli Zhou wrote: >> Magnus Ihse Bursie 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 'master' into static-jdk-image >> - Fix bug in filtering out -Wl,--exclude-libs,ALL >> - Don't hardcode server variant >> - Setup LDFLAGS_STATIC_JDK >> - Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check >> - Add lookup asserts >> - Remove superfluous SRC. >> - Merge branch 'master' into static-jdk-image >> - Makefile changes needed for static-launcher and static-jdk-image targets >> - Incorporate changes from leyden/hermetic-java-runtime that allows running a static launcher > > https://github.com/openjdk/jdk/pull/21861 for adding DEF_STATIC_JNI_OnLoad in libjimage and libsaproc native libraries. @jianglizhou I'm trying to follow your comments here... Am I correct in understanding that you are saying that the missing DEF_STATIC_JNI_OnLoad is not, in fact, the problem that causes .java files to not load? Because I tried applying your patch from #21861, and it did not help. > I think we would need to decide what is the `dll_dir` with the static JDK support and hermetic support. Do you mean that this the core issue related to the .java launching failure? I also find it curious that it does work on macOS, but not on Linux. This indicates, to me, that there is some difference in platform-dependent code that is different between Linux and mac, and there is not much such code in this PR. So maybe it is some pre-existing difference in code that provokes this difference in behavior. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2455046552 From kvn at openjdk.org Mon Nov 4 17:04:43 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 4 Nov 2024 17:04:43 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: <983rSW6uDF8scEsxAYntO_WksMrncX4VHtz4IH4HDpQ=.ada7fe61-1778-4f5f-bbf5-81d95bf59c2c@github.com> On Mon, 4 Nov 2024 16:04:12 GMT, Magnus Ihse Bursie wrote: > With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that? Yes, I completely agree to do such clean up in separate RFE. Please, file one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455239110 From ihse at openjdk.org Mon Nov 4 17:11:42 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 17:11:42 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <983rSW6uDF8scEsxAYntO_WksMrncX4VHtz4IH4HDpQ=.ada7fe61-1778-4f5f-bbf5-81d95bf59c2c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> <983rSW6uDF8scEsxAYntO_WksMrncX4VHtz4IH4HDpQ=.ada7fe61-1778-4f5f-bbf5-81d95bf59c2c@github.com> Message-ID: <2rYz-9j1EvPFwZilHh5ac_zn6TJX9fZRacU4Bl9k9u0=.21cd45d6-873f-404b-ac9b-c66b071eb631@github.com> On Mon, 4 Nov 2024 17:01:33 GMT, Vladimir Kozlov wrote: > > With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that? > > Yes, I completely agree to do such clean up in separate RFE. Please, file one. Good. I filed https://bugs.openjdk.org/browse/JDK-8343553. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455256779 From kvn at openjdk.org Mon Nov 4 17:20:04 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 4 Nov 2024 17:20:04 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <2rYz-9j1EvPFwZilHh5ac_zn6TJX9fZRacU4Bl9k9u0=.21cd45d6-873f-404b-ac9b-c66b071eb631@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> <983rSW6uDF8scEsxAYntO_WksMrncX4VHtz4IH4HDpQ=.ada7fe61-1778-4f5f-bbf5-81d95bf59c2c@github.com> <2rYz-9j1EvPFwZilHh5ac_zn6TJX9fZRacU4Bl9k9u0=.21cd45d6-873f-404b-ac9b-c66b071eb631@github.com> Message-ID: On Mon, 4 Nov 2024 17:08:40 GMT, Magnus Ihse Bursie wrote: >>> With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that? >> >> Yes, I completely agree to do such clean up in separate RFE. Please, file one. > >> > With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that? >> >> Yes, I completely agree to do such clean up in separate RFE. Please, file one. > > Good. I filed https://bugs.openjdk.org/browse/JDK-8343553. @magicus Back to my question about https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L470 ? I see only few uses of `#ifdef WIN32` in HotSpot which can be replaced with `#ifdef _WINDOWS`: src/hotspot/share/runtime/sharedRuntimeTrans.cpp:#ifdef WIN32 src/hotspot/share/runtime/sharedRuntimeTrans.cpp:#ifdef WIN32 Note, there are a lot more usages of `WIN32` in JDK libraries native code which we may consider renaming later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455274589 From ihse at openjdk.org Mon Nov 4 16:06:41 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 16:06:41 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Fri, 1 Nov 2024 18:11:13 GMT, Vladimir Kozlov wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers >> - Remove windows-32-bit code in CompilerConfig::ergo_initialize > > Okay, I am confuse about `_WIN32` vs `WIN32`. > > You are saying that "_WIN32 is still defined on 64-bit Windows" but you are removing code guarded by `#ifdef _WIN32` > And our make files defines `WIN32` for all Windows OSs: https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L470 @vnkozlov > * There is use of `WIN32` instead of `_WIN32`. > > * There are comments referencing `Win32` which we need to rename to `Windows` to avoid confusion. > > * There is `class os::win32` in `os_windows.hpp` which is batter to rename to avoid confusion. Could be done in separate RFE. > > * "Note that, oddly enough, _WIN32 is still defined on 64-bit Windows". If it is really true, I would still suggest to use our variable `_WINDOWS` for that. Ok. Let's start with being on the same page about the meaning of "win32". This is what Microsoft has to say about it: "The Win32 API (also called the Windows API) is the native platform for Windows apps. [T]he same functions are generally supported on 32-bit and 64-bit Windows." https://learn.microsoft.com/en-us/windows/win32/apiindex/api-index-portal#win32-windows-api I'd say that they are the authoritative source on the subject. :-) So technically there is nothing **wrong** with stuff targeting Windows being called "win32", even if we only support 64-bit Windows going forward. With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that? I will, however, do an additional round of checking all the grep hits on "win32" left to double-and-triple check that they indeed are not 32-bit specific. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455104589 From ihse at openjdk.org Mon Nov 4 17:31:00 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 17:31:00 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v21] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <4KQSjDq_ocYrb8cb81S57U_DtDcuRNcyUfeoQz4a6As=.11d47b0f-381e-4159-85e5-6f95ce742619@github.com> > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Replace WIN32 with _WINDOWS in sharedRuntimeTrans.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/fbd91ad0..dccf1a1d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=19-20 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Mon Nov 4 17:31:00 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 17:31:00 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> <983rSW6uDF8scEsxAYntO_WksMrncX4VHtz4IH4HDpQ=.ada7fe61-1778-4f5f-bbf5-81d95bf59c2c@github.com> <2rYz-9j1EvPFwZilHh5ac_zn6TJX9fZRacU4Bl9k9u0=.21cd45d6-873f-404b-ac9b-c66b071eb631@github.com> Message-ID: <5af9UbiLlBKx6KCuroe94EZxYiD0d9jqmt6TSgYp4XM=.e1b42d0c-4d70-46c6-9e00-bc3e102bf9ec@github.com> On Mon, 4 Nov 2024 17:16:49 GMT, Vladimir Kozlov wrote: >>> > With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that? >>> >>> Yes, I completely agree to do such clean up in separate RFE. Please, file one. >> >> Good. I filed https://bugs.openjdk.org/browse/JDK-8343553. > > @magicus > Back to my question about https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L470 ? > > I see only few uses of `#ifdef WIN32` in HotSpot which can be replaced with `#ifdef _WINDOWS`: > > src/hotspot/share/runtime/sharedRuntimeTrans.cpp:#ifdef WIN32 > src/hotspot/share/runtime/sharedRuntimeTrans.cpp:#ifdef WIN32 > > > Note, there are a lot more usages of `WIN32` in JDK libraries native code which we may consider renaming later. @vnkozlov I have now looked at all ~1800 case-independent hits of "win32" in the `src` directory. All of them is referring to the general Windows API, and not any 32-bit specific code, as far as I can tell from the filename and local context. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455296938 From mbaesken at openjdk.org Mon Nov 4 15:10:49 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 4 Nov 2024 15:10:49 GMT Subject: RFR: 8342893: Highlight special values in hserr file printing [v2] In-Reply-To: References: Message-ID: > There are some special values indicating memory corruption or problematic states. Those should be highlighted / pointed out in some way when printing parts of the hserr / hsinfo file (like register values or locations), Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: compile error on Linux x86 and arm 32bit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21811/files - new: https://git.openjdk.org/jdk/pull/21811/files/a6344199..2ef76ddf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21811&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21811&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/21811.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21811/head:pull/21811 PR: https://git.openjdk.org/jdk/pull/21811 From kvn at openjdk.org Mon Nov 4 17:49:43 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 4 Nov 2024 17:49:43 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v21] In-Reply-To: <4KQSjDq_ocYrb8cb81S57U_DtDcuRNcyUfeoQz4a6As=.11d47b0f-381e-4159-85e5-6f95ce742619@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <4KQSjDq_ocYrb8cb81S57U_DtDcuRNcyUfeoQz4a6As=.11d47b0f-381e-4159-85e5-6f95ce742619@github.com> Message-ID: On Mon, 4 Nov 2024 17:31:00 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Replace WIN32 with _WINDOWS in sharedRuntimeTrans.cpp HotSpot VM changes are good for me. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2413705033 From duke at openjdk.org Mon Nov 4 18:00:39 2024 From: duke at openjdk.org (duke) Date: Mon, 4 Nov 2024 18:00:39 GMT Subject: RFR: 8341194: [REDO] Implement C2 VectorizedHashCode on AArch64 [v2] In-Reply-To: <1et13399iAB7nE79C_UCtljStqiP46OnP120XjbuyC4=.427dd552-ef34-450e-b67f-e5d752fd8dbb@github.com> References: <1et13399iAB7nE79C_UCtljStqiP46OnP120XjbuyC4=.427dd552-ef34-450e-b67f-e5d752fd8dbb@github.com> Message-ID: On Tue, 8 Oct 2024 09:47:47 GMT, Mikhail Ablakatov wrote: >> Fix and redo [JDK-8322770](https://bugs.openjdk.org/browse/JDK-8322770) which got backed out in [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197) due to test failures / jlink failure. Initial PR: https://github.com/openjdk/jdk/pull/18487. >> >> Compared to the initial PR, this one eliminates a mismatch between the `arrays_hashcode()` template and stub. The template defined v0-v7 & v12-v17 as TEMP registers but the stub used v8-v9 which were not on the list. Changing v8-v9 in the stub to v12-v13 eliminates this mismatch. Other changes in aarch64.ad is just a cleanup as some registers on the list were not used by the stub at all anymore. >> >> Following the discussion on [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197), we've added a `make bootcycle-images` step to our local CI pipeline to verify that the issue is fixed. > > Mikhail Ablakatov has updated the pull request incrementally with one additional commit since the last revision: > > Ensure that the inline code and the stub use the same registers @mikabl-arm Your change (at version 9c6ad7a59b3144766a888e136dc4084f2b8e83fd) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21286#issuecomment-2455362830 From pchilanomate at openjdk.org Mon Nov 4 18:18:23 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 4 Nov 2024 18:18:23 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v29] In-Reply-To: References: Message-ID: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision: - Update comment block in objectMonitor.cpp - Fix issue with unmounted virtual thread when dumping heap - Remove ThawBase::possibly_adjust_frame() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21565/files - new: https://git.openjdk.org/jdk/pull/21565/files/52c26642..11396312 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=27-28 Stats: 349 lines in 14 files changed: 219 ins; 101 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From pchilanomate at openjdk.org Mon Nov 4 18:21:56 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 4 Nov 2024 18:21:56 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v12] In-Reply-To: References: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com> Message-ID: On Fri, 1 Nov 2024 20:08:51 GMT, Dean Long wrote: >> It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes. Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative. > > Here's my suggested C2 change: > > diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad > index d9c77a2f529..1e99db191ae 100644 > --- a/src/hotspot/cpu/aarch64/aarch64.ad > +++ b/src/hotspot/cpu/aarch64/aarch64.ad > @@ -3692,14 +3692,13 @@ encode %{ > __ post_call_nop(); > } else { > Label retaddr; > + // Make the anchor frame walkable > __ adr(rscratch2, retaddr); > + __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset())); > __ lea(rscratch1, RuntimeAddress(entry)); > - // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc() > - __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize))); > __ blr(rscratch1); > __ bind(retaddr); > __ post_call_nop(); > - __ add(sp, sp, 2 * wordSize); > } > if (Compile::current()->max_vector_size() > 0) { > __ reinitialize_ptrue(); Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code. @RealFYang I made the equivalent change for riscv, could you verify it's okay? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828186069 From pchilanomate at openjdk.org Mon Nov 4 18:21:57 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 4 Nov 2024 18:21:57 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v16] In-Reply-To: <5p5ZR8m0OB0ZZQMgKN4-itJXsTvaP_WUbivgnIhNQSQ=.43607f75-eb3c-4f20-a7a0-691b83a27cf1@github.com> References: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com> <5p5ZR8m0OB0ZZQMgKN4-itJXsTvaP_WUbivgnIhNQSQ=.43607f75-eb3c-4f20-a7a0-691b83a27cf1@github.com> Message-ID: On Tue, 29 Oct 2024 22:58:31 GMT, Dean Long wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comment in VThreadWaitReenter > > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 316: > >> 314: pc = ContinuationHelper::return_address_at( >> 315: sp - frame::sender_sp_ret_address_offset()); >> 316: } > > You could do this with an overload instead: > > static void set_anchor(JavaThread* thread, intptr_t* sp, address pc) { > assert(pc != nullptr, ""); > [...] > } > static void set_anchor(JavaThread* thread, intptr_t* sp) { > address pc = ContinuationHelper::return_address_at( > sp - frame::sender_sp_ret_address_offset()); > set_anchor(thread, sp, pc); > } > > but the compiler probably optmizes the above check just fine. Added an overload method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828187178 From pchilanomate at openjdk.org Mon Nov 4 18:28:57 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 4 Nov 2024 18:28:57 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v9] In-Reply-To: References: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com> Message-ID: <3ThzYwhF_zfOZCcLiTcQIYjPtA5mNuUYZLWjiH3zJGE=.a4c97906-8a38-4af9-9cee-2c26b1f35271@github.com> On Fri, 25 Oct 2024 04:40:24 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision: >> >> - Rename set/has_owner_anonymous to set/has_anonymous_owner >> - Fix comments in javaThread.hpp and Thread.java >> - Rename nonce/nounce to seqNo in VirtualThread class >> - Remove ObjectMonitor::set_owner_from_BasicLock() > > src/hotspot/share/runtime/objectMonitor.cpp line 132: > >> 130: >> 131: // ----------------------------------------------------------------------------- >> 132: // Theory of operations -- Monitors lists, thread residency, etc: > > This comment block needs updating now owner is not a JavaThread*, and to account for vthread usage Updated comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828195851 From pchilanomate at openjdk.org Mon Nov 4 18:28:55 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 4 Nov 2024 18:28:55 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v9] In-Reply-To: References: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com> <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com> Message-ID: On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang wrote: >> Changed. > > Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? > > (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd) Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828190876 From pchilanomate at openjdk.org Mon Nov 4 18:28:56 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 4 Nov 2024 18:28:56 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v9] In-Reply-To: References: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com> <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com> Message-ID: On Mon, 4 Nov 2024 18:22:42 GMT, Patricio Chilano Mateo wrote: >> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? >> >> (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd) > > Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was? > Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted? > I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828191725 From pchilanomate at openjdk.org Mon Nov 4 18:36:57 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 4 Nov 2024 18:36:57 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v29] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 18:18:23 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision: > > - Update comment block in objectMonitor.cpp > - Fix issue with unmounted virtual thread when dumping heap > - Remove ThawBase::possibly_adjust_frame() I brought a small fix to the heap dump code from the loom repo for an issue found recently. It includes a reproducer test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2455431391 From bstafford at openjdk.org Mon Nov 4 18:55:20 2024 From: bstafford at openjdk.org (Brian Stafford) Date: Mon, 4 Nov 2024 18:55:20 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 01:17:01 GMT, Julian Waters wrote: > Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely @swesonga, can you please take a look at this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2455449037 From jiangli at openjdk.org Mon Nov 4 19:08:34 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 4 Nov 2024 19:08:34 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v9] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Sun, 3 Nov 2024 20:23:32 GMT, Jiangli Zhou wrote: >> Magnus Ihse Bursie 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 'master' into static-jdk-image >> - Fix bug in filtering out -Wl,--exclude-libs,ALL >> - Don't hardcode server variant >> - Setup LDFLAGS_STATIC_JDK >> - Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check >> - Add lookup asserts >> - Remove superfluous SRC. >> - Merge branch 'master' into static-jdk-image >> - Makefile changes needed for static-launcher and static-jdk-image targets >> - Incorporate changes from leyden/hermetic-java-runtime that allows running a static launcher > > https://github.com/openjdk/jdk/pull/21861 for adding DEF_STATIC_JNI_OnLoad in libjimage and libsaproc native libraries. > @jianglizhou I'm trying to follow your comments here... Am I correct in understanding that you are saying that the missing DEF_STATIC_JNI_OnLoad is not, in fact, the problem that causes .java files to not load? Because I tried applying your patch from #21861, and it did not help. The missing`DEF_STATIC_JNI_OnLoad` in jimage.cpp **is** the cause. With the fix, running `static-jdk/bin/java` with `HelloWorld.java` now works for me without failure: build/linux-x86_64-server-slowdebug/images/static-jdk$ bin/java ~/tests/HelloWorld.java HelloWorld > Because I tried applying your patch from #21861, and it did not help. Did you do a clean build? I notice incremental build with your current PR doesn't update `static-jdk/bin/java` properly. This should be fixed as well. Please do `make clean` and rebuild the `images` and `static-jdk-image` to test if you are still running into any failure. If you are still seeing failures, please send me the specific build and run commands. > > > I think we would need to decide what is the `dll_dir` with the static JDK support and hermetic support. > > Do you mean that this the core issue related to the .java launching failure? No, the `dll_dir` issue that I pointed out earlier was not the cause. With static JDK support, `libjimage` is statically linked with `static-jdk/bin/java`. When `loadLibrary()` is called to "load" the `jimage` native library, the system first looks for built-in `jimage` native library by looking up `JNI_OnLoad_jimage` symbol. If the symbol exists, it means the `libjimage` is built in and there is no need to `dlopen` the native library from `dll_dir`. That's why the `dll_dir` issue is not the root cause. If it can't find `JNI_OnLoad_jimage` symbol, the system would try to load `libjimage.so` from `dll_dir`. However, that should never happen with static JDK. `JNI_OnLoad_jimage` symbol is defined by `DEF_STATIC_JNI_OnLoad` macro. That's why the missing `DEF_STATIC_JNI_OnLoad` in jimage.cpp is the root cause of the `loadLibrary()` failure. > > I also find it curious that it does work on macOS, but not on Linux. This indicates, to me, that there is some difference in platform-dependent code that is different between Linux and mac, and there is not much such code in this PR. So maybe it is some pre-existing difference in code that provokes this difference in behavior. I think the macOS might have other bugs that masks this failure. As we discussed in hermetic Java meetings, let's focus on supporting the Linux platform initially. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2455483797 From jiangli at openjdk.org Mon Nov 4 19:08:35 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 4 Nov 2024 19:08:35 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v9] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Fri, 1 Nov 2024 16:25:59 GMT, Magnus Ihse Bursie wrote: >> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. >> >> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. >> >> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). > > Magnus Ihse Bursie 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 'master' into static-jdk-image > - Fix bug in filtering out -Wl,--exclude-libs,ALL > - Don't hardcode server variant > - Setup LDFLAGS_STATIC_JDK > - Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check > - Add lookup asserts > - Remove superfluous SRC. > - Merge branch 'master' into static-jdk-image > - Makefile changes needed for static-launcher and static-jdk-image targets > - Incorporate changes from leyden/hermetic-java-runtime that allows running a static launcher Fixed a typo in above comment: **does** should be **doesn't** > I notice incremental build with your current PR does update `static-jdk/bin/java` properly. This should be fixed as well. Should be: I notice incremental build with your current PR doesn't update `static-jdk/bin/java` properly. This should be fixed as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2455487724 From ihse at openjdk.org Mon Nov 4 19:27:59 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 19:27:59 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v22] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Also remove __cdecl - Also remove __stdcall on tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/dccf1a1d..82fbc51e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=20-21 Stats: 31 lines in 13 files changed: 0 ins; 10 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Mon Nov 4 19:35:42 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 19:35:42 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v22] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Mon, 4 Nov 2024 19:27:59 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Also remove __cdecl > - Also remove __stdcall on tests I created https://bugs.openjdk.org/browse/JDK-8343560 to track the possible removal of `JNICALL` in the JDK source. Ultimately, we need to decide if it is worth the churn, or if we should keep it "just in case" some future platform will require a special keyword in that location (utterly unlikely as it might seem). If we go ahead with it, there are additional "downstream" fixes that needs to go with it, I highlighted some in the JBS issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455537378 From ihse at openjdk.org Mon Nov 4 19:45:57 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 19:45:57 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v23] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Also restore ADLC_CFLAGS_WARNINGS changes that are not needed any longer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/82fbc51e..b5a481db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=21-22 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From wkemper at openjdk.org Mon Nov 4 19:52:30 2024 From: wkemper at openjdk.org (William Kemper) Date: Mon, 4 Nov 2024 19:52:30 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> > This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 503 commits: - Merge openjdk/jdk tip into great-genshen-pr-redux - Merge remote-tracking branch 'jdk/master' into merge-latest - Merge remote-tracking branch 'jdk/master' into merge-latest - Merge - 8342861: GenShen: Old generation in unexpected state when abandoning mixed gc candidates Reviewed-by: kdnilsen - 8342734: GenShen: Test failure gc/shenandoah/TestReferenceRefersToShenandoah.java#generational Reviewed-by: ysr - 8342919: GenShen: Fix whitespace Reviewed-by: xpeng, kdnilsen - 8342927: GenShen: Guarantee slices of time for coalesce and filling Reviewed-by: kdnilsen - 8342924: GenShen: Problem list gc/shenandoah/TestReferenceRefersToShenandoah.java Reviewed-by: kdnilsen, ysr - 8342848: Shenandoah: Marking bitmap may not be completely cleared in generational mode Reviewed-by: wkemper - ... and 493 more: https://git.openjdk.org/jdk/compare/1c448347...19b25bc3 ------------- Changes: https://git.openjdk.org/jdk/pull/21273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=05 Stats: 22859 lines in 229 files changed: 21116 ins; 886 del; 857 mod Patch: https://git.openjdk.org/jdk/pull/21273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21273/head:pull/21273 PR: https://git.openjdk.org/jdk/pull/21273 From ihse at openjdk.org Mon Nov 4 19:58:59 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 19:58:59 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v24] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: buildJniFunctionName is now identical on Windows and Unix, so unify it ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/b5a481db..466a1a7a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=22-23 Stats: 48 lines in 4 files changed: 8 ins; 40 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Mon Nov 4 20:02:32 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 20:02:32 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v25] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix build_agent_function_name to not handle "@"-stdcall style names ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/466a1a7a..88d89e75 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=23-24 Stats: 21 lines in 1 file changed: 3 ins; 16 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Mon Nov 4 20:18:23 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 20:18:23 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v26] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <3ZIvKBKdzJvYU91TwQcAGKUlDENAC5D5VNUFjI8zQzA=.a81d7ec5-c2ba-4eb0-ba78-c94ef65c8e28@github.com> > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: [JNI/JVM/AGENT]_[ONLOAD/ONUNLOAD/ONATTACH]_SYMBOLS are now identical on Windows and Unix, so unify them ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/88d89e75..6f690d02 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=24-25 Stats: 21 lines in 3 files changed: 7 ins; 14 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Mon Nov 4 20:21:09 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 20:21:09 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v27] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <_PNwSCgsqsInETeof5O-P5dZUGus72uvmtcYomw1QII=.eb53d7ac-250c-40cc-9fb5-68d5d3b15dd6@github.com> > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: JVM_EnqueueOperation do not need __stdcall name lookup anymore ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/6f690d02..48d722bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=25-26 Stats: 8 lines in 1 file changed: 0 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Mon Nov 4 20:23:56 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 20:23:56 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v28] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <-YUW42BZ3ZY4k5baNUWfHqBlItoEyoOsXOMPxp_mvyM=.e3f414f4-c1c5-40db-ab72-debeb41968f5@github.com> > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: - Merge branch 'master' into impl-JEP-479 - JVM_EnqueueOperation do not need __stdcall name lookup anymore - [JNI/JVM/AGENT]_[ONLOAD/ONUNLOAD/ONATTACH]_SYMBOLS are now identical on Windows and Unix, so unify them - Fix build_agent_function_name to not handle "@"-stdcall style names - buildJniFunctionName is now identical on Windows and Unix, so unify it - Also restore ADLC_CFLAGS_WARNINGS changes that are not needed any longer - Also remove __cdecl - Also remove __stdcall on tests - Replace WIN32 with _WINDOWS in sharedRuntimeTrans.cpp - Remove __stdcall notation - ... and 23 more: https://git.openjdk.org/jdk/compare/8b474971...699c641a ------------- Changes: https://git.openjdk.org/jdk/pull/21744/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=27 Stats: 1885 lines in 84 files changed: 86 ins; 1572 del; 227 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Mon Nov 4 20:29:23 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 20:29:23 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v29] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Update copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/699c641a..40291b9b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=27-28 Stats: 39 lines in 39 files changed: 0 ins; 0 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Mon Nov 4 20:38:41 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 20:38:41 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v29] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Mon, 4 Nov 2024 20:29:23 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright years I have now searched for `@[0-9]` to find instances of "stdcall-style" symbol names, and fixed those. I have also done a wide sweep of searching for "@" in general over the code base, which (unsurprisingly) generated a sh*tload of hits. I tried to sift through this, using some mental heuristics to skip those that are likely to be irrelevant, and scrutinized some other more carefully, to identify any other code that might be working with name mangling/parsing. I found no such code, outside of what I had already previously located. At this point, I believe I have resolved all outstanding issues from the reviews, and also finished fixing up the additional removal of the 32-bit Windows calling convention remnants. >From my PoV, what remains now is for me to repeat the in-depth testing of this PR, and to wait for the JEP to become targeted. @shipilev @erikj79 @vnkozlov @kimbarrett I'd appreciate a re-review from you at the current commit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455648651 PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455651750 From ihse at openjdk.org Mon Nov 4 20:42:59 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 20:42:59 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: fix: jvm_md.h was included, but not jvm.h... ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/40291b9b..9b10e74c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=28-29 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From sspitsyn at openjdk.org Mon Nov 4 20:57:53 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 4 Nov 2024 20:57:53 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v29] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 18:18:23 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision: > > - Update comment block in objectMonitor.cpp > - Fix issue with unmounted virtual thread when dumping heap > - Remove ThawBase::possibly_adjust_frame() src/hotspot/share/runtime/continuation.cpp line 134: > 132: return true; > 133: } > 134: #endif // INCLUDE_JVMTI Could you, please, consider the simplification below? #if INCLUDE_JVMTI // return true if started vthread unmount bool jvmti_unmount_begin(JavaThread* target) { assert(!target->is_in_any_VTMS_transition(), "must be"); // Don't preempt if there is a pending popframe or earlyret operation. This can // be installed in start_VTMS_transition() so we need to check it here. if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) { JvmtiThreadState* state = target->jvmti_thread_state(); if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) { return false; } } // Don't preempt in case there is an async exception installed since // we would incorrectly throw it during the unmount logic in the carrier. if (target->has_async_exception_condition()) { return false; } if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) { JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true); } else { target->set_is_in_VTMS_transition(true); // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true) } return false; } static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) { if (target->is_in_VTMS_transition()) { // We caught target at the end of a mount transition. return false; } return true; } #endif // INCLUDE_JVMTI ... static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) { assert(java_lang_VirtualThread::is_instance(vthread), ""); if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) { // inside transition return false; } return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true); } ... int Continuation::try_preempt(JavaThread* target, oop continuation) { verify_preempt_preconditions(target, continuation); if (LockingMode == LM_LEGACY) { return freeze_unsupported; } if (!is_safe_vthread_to_preempt(target, target->vthread())) { return freeze_pinned_native; } JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;) int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp()); log_trace(continuations, preempt)("try_preempt: %d", res); return res; } The following won't be needed: target->set_pending_jvmti_unmount_event(true); jvmtiThreadState.cpp: + if (thread->pending_jvmti_unmount_event()) { + assert(java_lang_VirtualThread::is_preempted(JNIHandles::resolve(vthread)), "should be marked preempted"); + JvmtiExport::post_vthread_unmount(vthread); + thread->set_pending_jvmti_unmount_event(false); + } As we discussed before there can be the `has_async_exception_condition()` flag set after a VTMS unmount transition has been started. But there is always such a race in VTMS transitions and the flag has to be processed as usual. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828376585 From dlong at openjdk.org Mon Nov 4 21:10:28 2024 From: dlong at openjdk.org (Dean Long) Date: Mon, 4 Nov 2024 21:10:28 GMT Subject: RFR: 8342893: Highlight special values in hserr file printing [v2] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 15:10:49 GMT, Matthias Baesken wrote: >> There are some special values indicating memory corruption or problematic states. Those should be highlighted / pointed out in some way when printing parts of the hserr / hsinfo file (like register values or locations), > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > compile error on Linux x86 and arm 32bit src/hotspot/share/runtime/os.cpp line 1346: > 1344: #ifndef PRODUCT > 1345: // corruption or uninitialized access pattern > 1346: const intptr_t pat = 0xabababababababab; How about constructing this from `badResourceValue`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21811#discussion_r1828391118 From jbechberger at openjdk.org Mon Nov 4 21:12:42 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Mon, 4 Nov 2024 21:12:42 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v6] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Add worker thread id getter to whitebox ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/1e0dbaea..01783bc9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=04-05 Stats: 34 lines in 4 files changed: 33 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From ihse at openjdk.org Mon Nov 4 21:15:34 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 21:15:34 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v9] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Mon, 4 Nov 2024 19:05:05 GMT, Jiangli Zhou wrote: > I notice incremental build with your current PR doesn't update `static-jdk/bin/java` properly. This should be fixed as well. This I fully agree with; it cannot wait for a follow-up PR. I'll look into it as soon as I have gotten back to a working build. I can confirm that with your patch, and clang, and a complete wipe + rebuild, the .java file loading works. I'm currently testing with gcc as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2455711944 From ihse at openjdk.org Mon Nov 4 21:27:31 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 21:27:31 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v8] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> <0SV1CZsC4-4qlECRdXAsTtfA4SFMOizXH2pZqYggJtM=.d69355b4-ac64-4a9a-836e-957085f04b09@github.com> <-KTe_Kv55w9u0xR8YeEEHDYvYCv3YCUzc9EBac6jL4c=.13b8e842-a9e0-451e-b8c9-6519d9932d57@github.com> Message-ID: On Sun, 3 Nov 2024 05:06:04 GMT, Jiangli Zhou wrote: > There is no `static-jdk/bin/java.debuginfo`. I do see there's a `./support/static-native/launcher/java.debuginfo`. Ah, I missed that part. So it's just about copying it to the right place? Fine, that is trivial to add. Did you verify that these symbols really worked, though? That is my main concern. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2455732445 From ihse at openjdk.org Mon Nov 4 21:32:32 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 21:32:32 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v9] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Fri, 1 Nov 2024 16:25:59 GMT, Magnus Ihse Bursie wrote: >> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. >> >> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. >> >> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). > > Magnus Ihse Bursie 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 'master' into static-jdk-image > - Fix bug in filtering out -Wl,--exclude-libs,ALL > - Don't hardcode server variant > - Setup LDFLAGS_STATIC_JDK > - Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check > - Add lookup asserts > - Remove superfluous SRC. > - Merge branch 'master' into static-jdk-image > - Makefile changes needed for static-launcher and static-jdk-image targets > - Incorporate changes from leyden/hermetic-java-runtime that allows running a static launcher Also, the gcc build succeeds as well. I'll definitely have to look into the incremental build part, this was highly annoying. Anyway, that means we're back in business. I think I ran into this problem when I was working with `LDFLAGS_STATIC_JDK`; I need to to back in the logs to see what I was doing. Also, there is some additional comments from reviewers (incl Johan Vos) that I need to address. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2455738909 From jiangli at openjdk.org Mon Nov 4 21:32:33 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 4 Nov 2024 21:32:33 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v9] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Mon, 4 Nov 2024 21:12:31 GMT, Magnus Ihse Bursie wrote: > I can confirm that with your patch, and clang, and a complete wipe + rebuild, the .java file loading works. I'm currently testing with gcc as well. Good. I tested using gcc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2455740530 From ihse at openjdk.org Mon Nov 4 21:32:33 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 21:32:33 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v9] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Mon, 4 Nov 2024 21:29:51 GMT, Jiangli Zhou wrote: >>> I notice incremental build with your current PR doesn't update `static-jdk/bin/java` properly. This should be fixed as well. >> >> This I fully agree with; it cannot wait for a follow-up PR. I'll look into it as soon as I have gotten back to a working build. >> >> I can confirm that with your patch, and clang, and a complete wipe + rebuild, the .java file loading works. I'm currently testing with gcc as well. > >> I can confirm that with your patch, and clang, and a complete wipe + rebuild, the .java file loading works. I'm currently testing with gcc as well. > > Good. > > I tested using gcc. @jianglizhou Thank you for your assistance in figuring out the problem. I guess I throw out too much code from the hermetic-java-runtime branch when trying to minimize the changes to only build-related stuff. The jimage changes were so busy so I probably ignored them a bit too much. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2455741013 From dlong at openjdk.org Mon Nov 4 21:35:36 2024 From: dlong at openjdk.org (Dean Long) Date: Mon, 4 Nov 2024 21:35:36 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v30] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> Message-ID: <7AyadySq4LdcH9KWWEpQjpFl2jNPm0RoRVT2fTHoREg=.ee92abf5-fc0d-4f89-b26c-7151f55106eb@github.com> On Mon, 21 Oct 2024 14:49:47 GMT, Andrew Haley wrote: >> This patch expands the use of a hash table for secondary superclasses >> to the interpreter, C1, and runtime. It also adds a C2 implementation >> of hashed lookup in cases where the superclass isn't known at compile >> time. >> >> HotSpot shared runtime >> ---------------------- >> >> Building hashed secondary tables is now unconditional. It takes very >> little time, and now that the shared runtime always has the tables, it >> might as well take advantage of them. The shared code is easier to >> follow now, I think. >> >> There might be a performance issue with x86-64 in that we build >> HotSpot for a default x86-64 target that does not support popcount. >> This means that HotSpot C++ runtime on x86 always uses a software >> emulation for popcount, even though the vast majority of machines made >> for the past 20 years can do popcount in a single instruction. It >> wouldn't be terribly hard to do something about that. >> >> Having said that, the software popcount is really not bad. >> >> x86 >> --- >> >> x86 is rather tricky, because we still support >> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as >> well as 32- and 64-bit ports. There's some further complication in >> that only `RCX` can be used as a shift count, so there's some register >> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp >> rather gnarly, with multiple levels of conditionals at compile time >> and runtime. >> >> AArch64 >> ------- >> >> AArch64 is considerably more straightforward. We always have a >> popcount instruction and (thankfully) no 32-bit code to worry about. >> >> Generally >> --------- >> >> I would dearly love simply to rip out the "old" secondary supers cache >> support, but I've left it in just in case someone has a performance >> regression. >> >> The versions of `MacroAssembler::lookup_secondary_supers_table` that >> work with variable superclasses don't take a fixed set of temp >> registers, and neither do they call out to to a slow path subroutine. >> Instead, the slow patch is expanded inline. >> >> I don't think this is necessarily bad. Apart from the very rare cases >> where C2 can't determine the superclass to search for at compile time, >> this code is only used for generating stubs, and it seemed to me >> ridiculous to have stubs calling other stubs. >> >> I've followed the guidance from @iwanowww not to obsess too much about >> the performance of C1-compiled secondary supers lookups, and to prefer >> simplicity over absolute performance. Nonetheless, this i... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Correct comment Marked as reviewed by dlong (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19989#pullrequestreview-2414165011 From ihse at openjdk.org Mon Nov 4 21:37:12 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 21:37:12 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v10] In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge branch 'master' into static-jdk-image - Merge branch 'master' into static-jdk-image - Fix bug in filtering out -Wl,--exclude-libs,ALL - Don't hardcode server variant - Setup LDFLAGS_STATIC_JDK - Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check - Add lookup asserts - Remove superfluous SRC. - Merge branch 'master' into static-jdk-image - Makefile changes needed for static-launcher and static-jdk-image targets - ... and 1 more: https://git.openjdk.org/jdk/compare/825ceb16...f4f6845e ------------- Changes: https://git.openjdk.org/jdk/pull/20837/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=09 Stats: 447 lines in 26 files changed: 367 ins; 5 del; 75 mod Patch: https://git.openjdk.org/jdk/pull/20837.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837 PR: https://git.openjdk.org/jdk/pull/20837 From jiangli at openjdk.org Mon Nov 4 22:31:30 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 4 Nov 2024 22:31:30 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v8] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> <0SV1CZsC4-4qlECRdXAsTtfA4SFMOizXH2pZqYggJtM=.d69355b4-ac64-4a9a-836e-957085f04b09@github.com> <-KTe_Kv55w9u0xR8YeEEHDYvYCv3YCUzc9EBac6jL4c=.13b8e842-a9e0-451e-b8c9-6519d9932d57@github.com> Message-ID: On Mon, 4 Nov 2024 21:24:54 GMT, Magnus Ihse Bursie wrote: > > There is no `static-jdk/bin/java.debuginfo`. I do see there's a `./support/static-native/launcher/java.debuginfo`. > > Ah, I missed that part. So it's just about copying it to the right place? Fine, that is trivial to add. Did you verify that these symbols really worked, though? That is my main concern. The `./support/static-native/launcher/java.debuginfo` works. I can use it in `gdb` to step through code. I haven't specifically looked into how `java.debuginfo` is copied for normal `images/jdk/bin/java`. It's better to handle the `java.debuginfo` for `images/static-jdk/bin/java` the same. As a related note, with `--with-native-debug-symbols`, I believe there is no external `.debuginfo` file. But as long as the `.debuginfo` file for static build is handle the same as for normal build, it will work automatically. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2455832890 From asmehra at openjdk.org Mon Nov 4 22:35:37 2024 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 4 Nov 2024 22:35:37 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v7] In-Reply-To: References: Message-ID: <1wukRI6kmV2-xWutsU-7yRUnYMLAs9jwXIDDlyLj77M=.da0215eb-76bc-4f4c-b3e3-a7b26f642140@github.com> On Mon, 4 Nov 2024 03:15:25 GMT, Ioi Lam wrote: >> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). >> >> ---- >> Note: this is a combined PR of the following individual PRs >> - https://github.com/openjdk/jdk/pull/20516 >> - https://github.com/openjdk/jdk/pull/20517 >> - https://github.com/openjdk/jdk/pull/20843 >> - https://github.com/openjdk/jdk/pull/20958 >> - https://github.com/openjdk/jdk/pull/20959 >> - https://github.com/openjdk/jdk/pull/21049 >> - https://github.com/openjdk/jdk/pull/21143 > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 172 commits: > > - fixed merge > - Merge branch 'master' into jep-483-candidate > - 8343493: Perform module checks during MetaspaceShared::map_archives() > - reverted changes in modules.cpp to make it easy to merge with mainline > - Fixed whitespace; fixed minimal build > - Fixed 8343245: AOT cache creation crashes with "assert(HeapShared::is_archivable_hidden_klass(ik)) failed: sanity" > - fixed comments > - @ashu-mehra comment - renamed function to SystemDictionaryShared::should_be_excluded(); added comments and asserts; make sure the class is indeed checked > - Backed out 58233cc20fa22abfd711bb59aafb78e20fabc195 > - @ashu-mehra comment - rename/comment AOTClassLinker::add_new_candidate() and added asserts for thread safety > - ... and 162 more: https://git.openjdk.org/jdk/compare/29882bfe...935dcc68 Marked as reviewed by asmehra (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2414263812 From vlivanov at openjdk.org Mon Nov 4 23:07:34 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 4 Nov 2024 23:07:34 GMT Subject: RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v30] In-Reply-To: References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> Message-ID: On Mon, 21 Oct 2024 14:49:47 GMT, Andrew Haley wrote: >> This patch expands the use of a hash table for secondary superclasses >> to the interpreter, C1, and runtime. It also adds a C2 implementation >> of hashed lookup in cases where the superclass isn't known at compile >> time. >> >> HotSpot shared runtime >> ---------------------- >> >> Building hashed secondary tables is now unconditional. It takes very >> little time, and now that the shared runtime always has the tables, it >> might as well take advantage of them. The shared code is easier to >> follow now, I think. >> >> There might be a performance issue with x86-64 in that we build >> HotSpot for a default x86-64 target that does not support popcount. >> This means that HotSpot C++ runtime on x86 always uses a software >> emulation for popcount, even though the vast majority of machines made >> for the past 20 years can do popcount in a single instruction. It >> wouldn't be terribly hard to do something about that. >> >> Having said that, the software popcount is really not bad. >> >> x86 >> --- >> >> x86 is rather tricky, because we still support >> `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as >> well as 32- and 64-bit ports. There's some further complication in >> that only `RCX` can be used as a shift count, so there's some register >> shuffling to do. All of this makes the logic in macroAssembler_x86.cpp >> rather gnarly, with multiple levels of conditionals at compile time >> and runtime. >> >> AArch64 >> ------- >> >> AArch64 is considerably more straightforward. We always have a >> popcount instruction and (thankfully) no 32-bit code to worry about. >> >> Generally >> --------- >> >> I would dearly love simply to rip out the "old" secondary supers cache >> support, but I've left it in just in case someone has a performance >> regression. >> >> The versions of `MacroAssembler::lookup_secondary_supers_table` that >> work with variable superclasses don't take a fixed set of temp >> registers, and neither do they call out to to a slow path subroutine. >> Instead, the slow patch is expanded inline. >> >> I don't think this is necessarily bad. Apart from the very rare cases >> where C2 can't determine the superclass to search for at compile time, >> this code is only used for generating stubs, and it seemed to me >> ridiculous to have stubs calling other stubs. >> >> I've followed the guidance from @iwanowww not to obsess too much about >> the performance of C1-compiled secondary supers lookups, and to prefer >> simplicity over absolute performance. Nonetheless, this i... > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Correct comment Marked as reviewed by vlivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/19989#pullrequestreview-2414315243 From iklam at openjdk.org Mon Nov 4 23:57:48 2024 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 4 Nov 2024 23:57:48 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v8] In-Reply-To: References: Message-ID: > This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). > > ---- > Note: this is a combined PR of the following individual PRs > - https://github.com/openjdk/jdk/pull/20516 > - https://github.com/openjdk/jdk/pull/20517 > - https://github.com/openjdk/jdk/pull/20843 > - https://github.com/openjdk/jdk/pull/20958 > - https://github.com/openjdk/jdk/pull/20959 > - https://github.com/openjdk/jdk/pull/21049 > - https://github.com/openjdk/jdk/pull/21143 Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @DanHeidinga comment -- exit VM when runtimeSetup() fails ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21642/files - new: https://git.openjdk.org/jdk/pull/21642/files/935dcc68..c46ae0b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=06-07 Stats: 34 lines in 5 files changed: 20 ins; 9 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642 PR: https://git.openjdk.org/jdk/pull/21642 From iklam at openjdk.org Mon Nov 4 23:57:48 2024 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 4 Nov 2024 23:57:48 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v6] In-Reply-To: References: <8IyBT_SVLgsOjXogoorL6m3SmYK8OVzJDpRv-MH4MaA=.7f7f50c3-db38-4418-9381-9f915bb07470@github.com> Message-ID: On Mon, 4 Nov 2024 14:21:09 GMT, Dan Heidinga wrote: >> I think this is already done: >> >> `runtimeSetup()` is called inside `InstanceKlass::call_class_initializer()`. When that returns, we will proceed to `InstanceKlass::set_initialization_state_and_notify()` which will perform the memory fencing. >> >> https://github.com/iklam/jdk/blob/6eebd18fc2820ffb179d431f179fc6af6d1be247/src/hotspot/share/oops/instanceKlass.cpp#L1276-L1300 > > I think you're right about the memory fencing being covered there but reading that code shows another potential issue - what if the `runtimeSetup()` call throws an exception? > > If I read `InstanceKlass::call_class_initializer()` correctly, an exception from `runtimeSetup()` will lead to marking the class as failing initialization (`initialization_error`) which will be an unexpected outcome as there may be instances of the class in the AOTCache that aren't produced by paths through the `` method. > > Classes are able to create an instance in `` and escape it to other code and then fail initialization. The instances are left in an odd state where after the `` the instance methods can be called but static fields and static methods can't be accessed. > > `runtimeSetup()` expands on this corner case which I think is OK for current "crawl" stage of our "crawl-walk-run" approach as its analogous to the existing `` behaviour. It may need refining in the future to abort the VM or do something else (?) in the case of failed `runtimeSetup` calls Thanks for catching this. I added code to exit the JVM when `runtimeSetup()` fails. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1828549749 From fyang at openjdk.org Tue Nov 5 00:20:53 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 5 Nov 2024 00:20:53 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v9] In-Reply-To: References: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com> <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com> Message-ID: <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0ad6b253-7ab4-4f0c-891a-4a87e902fc59@github.com> On Mon, 4 Nov 2024 18:23:23 GMT, Patricio Chilano Mateo wrote: >> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was? > >> Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted? >> > I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame. > As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case. Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. > Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted? I agree with @pchilano in that we are fine with these places. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828563437 From vlivanov at openjdk.org Tue Nov 5 00:23:34 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 5 Nov 2024 00:23:34 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v8] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 23:57:48 GMT, Ioi Lam wrote: >> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). >> >> ---- >> Note: this is a combined PR of the following individual PRs >> - https://github.com/openjdk/jdk/pull/20516 >> - https://github.com/openjdk/jdk/pull/20517 >> - https://github.com/openjdk/jdk/pull/20843 >> - https://github.com/openjdk/jdk/pull/20958 >> - https://github.com/openjdk/jdk/pull/20959 >> - https://github.com/openjdk/jdk/pull/21049 >> - https://github.com/openjdk/jdk/pull/21143 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @DanHeidinga comment -- exit VM when runtimeSetup() fails Looks good. Stylistic comment: while browsing the code a mix of "AOT" & "aot" caught my eye. I find the former spelling more descriptive. Any particular reason to use "aot" unless all lowercase spelling is preferred in some particular context? ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2414396530 From fyang at openjdk.org Tue Nov 5 00:26:54 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 5 Nov 2024 00:26:54 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v9] In-Reply-To: <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0ad6b253-7ab4-4f0c-891a-4a87e902fc59@github.com> References: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com> <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com> <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0ad6b253-7ab4-4f0c-891a-4a87e902fc59@github.com> Message-ID: On Tue, 5 Nov 2024 00:18:17 GMT, Fei Yang wrote: >>> Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted? >>> >> I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame. > >> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case. > > Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. > >> Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted? > > I agree with @pchilano in that we are fine with these places. > Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was? Or maybe `hf.sp() - frame::metadata_words`. But since we have several other occurrences, I would suggest we leave it as it was and go with a separate PR for the cleanup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828566395 From fyang at openjdk.org Tue Nov 5 00:51:32 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 5 Nov 2024 00:51:32 GMT Subject: RFR: 8343471: RISC-V: compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java fails after JDK-8334999 In-Reply-To: <0kbTYsLzbimfWgJLujNBa3NStR5jCD6RYJem7nha9OQ=.b0fa4a76-7329-491e-8566-a33b9698c1aa@github.com> References: <0kbTYsLzbimfWgJLujNBa3NStR5jCD6RYJem7nha9OQ=.b0fa4a76-7329-491e-8566-a33b9698c1aa@github.com> Message-ID: On Mon, 4 Nov 2024 03:02:11 GMT, SendaoYan wrote: >> Hi, please review this small change. >> >> The test expects a message like `warning: AES instructions are not available on this CPU` for all cpu platforms without AES support. After https://bugs.openjdk.org/browse/JDK-8334999, we report this `warning: AES intrinsics require Zvkn extension (not available on this CPU)` on RISC-V platforms where `Zvkn` extension is not available. Patch fixes this message making it consistent with other CPU platforms. Same test passes with this fix. > > /LGTM @sendaoYan @Hamlin-Li : Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21847#issuecomment-2455994784 From fyang at openjdk.org Tue Nov 5 00:51:33 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 5 Nov 2024 00:51:33 GMT Subject: Integrated: 8343471: RISC-V: compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java fails after JDK-8334999 In-Reply-To: References: Message-ID: On Sat, 2 Nov 2024 09:22:31 GMT, Fei Yang wrote: > Hi, please review this small change. > > The test expects a message like `warning: AES instructions are not available on this CPU` for all cpu platforms without AES support. After https://bugs.openjdk.org/browse/JDK-8334999, we report this `warning: AES intrinsics require Zvkn extension (not available on this CPU)` on RISC-V platforms where `Zvkn` extension is not available. Patch fixes this message making it consistent with other CPU platforms. Same test passes with this fix. This pull request has now been integrated. Changeset: 20f3aaff Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/20f3aaff4470745ff082bc562f4e4e72044090b2 Stats: 19 lines in 1 file changed: 9 ins; 5 del; 5 mod 8343471: RISC-V: compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java fails after JDK-8334999 Reviewed-by: syan, mli ------------- PR: https://git.openjdk.org/jdk/pull/21847 From iklam at openjdk.org Tue Nov 5 01:13:39 2024 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 5 Nov 2024 01:13:39 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v8] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 00:20:56 GMT, Vladimir Ivanov wrote: > Looks good. > > Stylistic comment: while browsing the code a mix of "AOT" & "aot" caught my eye. I find the former spelling more descriptive. Any particular reason to use "aot" unless all lowercase spelling is preferred in some particular context? I've been using AOT in class names and aot in function/variable names. I think that's consistent with HotSpot convention. In logging, I've been using "aot" as logging seems to favor lowercase. In comments, I've been using a mix of AOT-xxx and aot-xxx, for no particular reason :-( ------------- PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2456016366 From fyang at openjdk.org Tue Nov 5 01:34:32 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 5 Nov 2024 01:34:32 GMT Subject: RFR: 8343502: RISC-V: SIGBUS in updateBytesCRC32 after JDK-8339738 In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 13:16:23 GMT, Hamlin Li wrote: >> Hi, please review this small change. >> >> [JDK-8339738](https://bugs.openjdk.org/browse/JDK-8339738) adds vectorization for crc32 intrinsic, which does `vle32.v` from the input byte buffer and calculates the checksum. But the input byte buffer could be misaligned (not 4-byte aligned). This leads to SIGBUS on hardware platforms like `BPI-F3` board where misaligned vector loads are not supported. Similar issue is there for scalar version as well, which could mean performance issue on other hardwares. Patch fixes this issue by adding a small alignment processing on entry for both scalar and vector version. >> >> This also fixes another potential issue in tail handling, where we do a single `lwu` for both versions to load the remaining bytes from the input byte buffer and extract each byte from the loaded 32-bit value. Since we only have less than 4 bytes remaining, this `lwu` would exceed the buffer limit, which I think is not safe. Patch fixes this issue by doing three separate `lbu` instead. >> >> Testing on `BPI-F3` with RVV 1.0 extension: >> - [x] test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java >> - [x] test/jdk/java/util/zip/TestCRC32.java >> - [x] SPECjbb2015 >> >> No obvious impact witnessed on `micro:java.util.TestCRC32`: >> >> >> Before: >> Benchmark (count) Mode Cnt Score Error Units >> TestCRC32.testCRC32Update 64 thrpt 12 4778.903 ? 1.793 ops/ms >> TestCRC32.testCRC32Update 128 thrpt 12 2655.639 ? 2.958 ops/ms >> TestCRC32.testCRC32Update 256 thrpt 12 1430.997 ? 0.970 ops/ms >> TestCRC32.testCRC32Update 512 thrpt 12 965.785 ? 1.840 ops/ms >> TestCRC32.testCRC32Update 2048 thrpt 12 303.056 ? 0.620 ops/ms >> TestCRC32.testCRC32Update 16384 thrpt 12 40.601 ? 0.220 ops/ms >> TestCRC32.testCRC32Update 65536 thrpt 12 9.575 ? 0.045 ops/ms >> TestCRC32C.testCRC32CUpdate 64 thrpt 12 3923.698 ? 23.209 ops/ms >> TestCRC32C.testCRC32CUpdate 128 thrpt 12 2514.616 ? 22.991 ops/ms >> TestCRC32C.testCRC32CUpdate 256 thrpt 12 1477.223 ? 2.319 ops/ms >> TestCRC32C.testCRC32CUpdate 512 thrpt 12 806.179 ? 1.961 ops/ms >> TestCRC32C.testCRC32CUpdate 2048 thrpt 12 216.396 ? 0.172 ops/ms >> TestCRC32C.testCRC32CUpdate 16384 thrpt 12 27.526 ? 0.049 ops/ms >> TestCRC32C.testCRC32CUpdate 65536 thrpt 12 6.530 ? 0.041 ops/ms >> >> After: >> Benchmark (count) Mode Cn... > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1649: > >> 1647: >> 1648: subw(len, len, 1); >> 1649: lbu(tmp1, Address(buf)); > > I guess after the alignment prelogue added in this pr, the previous tail implementation should be fine now. > As in the case of both java heap and native heap, the tail of passed-in buf can not cross the boundary of pages. Yeah, maybe. But I don't think it's good to do things that would exceed the buffer limit :-) I prefer a safer approach which won't performance much because it's only tail processing here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21863#discussion_r1828608490 From pchilanomate at openjdk.org Tue Nov 5 01:40:15 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 01:40:15 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision: - Add oopDesc::has_klass_gap() check - Rename waitTimeout/set_waitTimeout accessors - Revert suggestion to ThawBase::new_stack_frame - Improve JFR pinned reason in event - Use freeze_result consistently ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21565/files - new: https://git.openjdk.org/jdk/pull/21565/files/11396312..79189f9b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=28-29 Stats: 439 lines in 21 files changed: 123 ins; 261 del; 55 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From pchilanomate at openjdk.org Tue Nov 5 01:43:57 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 01:43:57 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v9] In-Reply-To: References: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com> <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com> <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0ad6b253-7ab4-4f0c-891a-4a87e902fc59@github.com> Message-ID: On Tue, 5 Nov 2024 00:23:37 GMT, Fei Yang wrote: >>> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case. >> >> Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. >> >>> Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted? >> >> I agree with @pchilano in that we are fine with these places. > >> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was? > > Or maybe `hf.sp() - frame::metadata_words`. But since we have several other occurrences, I would suggest we leave it as it was and go with a separate PR for the cleanup. Reverted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828615499 From pchilanomate at openjdk.org Tue Nov 5 01:43:58 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 01:43:58 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28] In-Reply-To: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.2ca0fc7a-49b5-47eb-8cc2-56757cafb96e@github.com> References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.2ca0fc7a-49b5-47eb-8cc2-56757cafb96e@github.com> Message-ID: <-NVIl6YW1oji4m0sLlL34aIrsJ0zq1_0PlgT6eva-jY=.9026ecf7-915c-4366-afff-30ec82ec6f98@github.com> On Mon, 4 Nov 2024 05:52:16 GMT, Alan Bateman wrote: >> src/hotspot/share/classfile/javaClasses.cpp line 2107: >> >>> 2105: >>> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) { >>> 2107: return vthread->long_field(_timeout_offset); >> >> Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ?? > > It was initially parkTimeout and waitTimeout but it doesn't require two fields as you can't be waiting in Object.wait(timeout) and LockSupport.parkNanos at the same time. So the field was renamed, the accessors here should probably be renamed too. Renamed accessors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828615772 From pchilanomate at openjdk.org Tue Nov 5 01:43:59 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 01:43:59 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v16] In-Reply-To: References: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com> Message-ID: On Mon, 4 Nov 2024 09:24:13 GMT, Stefan Karlsson wrote: >> If I recall correctly this was a bug where one of the stackChunk fields was allocated in that gap, but since we didn't zeroed it out it would start with some invalid value. I guess the reason why we are not hitting this today is because one of the fields we do initialize (sp/bottom/size) is being allocated there, but with the new fields I added to stackChunk that is not the case anymore. > > This code in `StackChunkAllocator::initialize` mimics the clearing code in: > > void MemAllocator::mem_clear(HeapWord* mem) const { > assert(mem != nullptr, "cannot initialize null object"); > const size_t hs = oopDesc::header_size(); > assert(_word_size >= hs, "unexpected object size"); > oopDesc::set_klass_gap(mem, 0); > Copy::fill_to_aligned_words(mem + hs, _word_size - hs); > } > > > but with a limited amount of clearing at the end of the object, IIRC. So, this looks like a good fix. With JEP 450 we have added an assert to set_klass_gap and changed the code in `mem_clear` to be: > > if (oopDesc::has_klass_gap()) { > oopDesc::set_klass_gap(mem, 0); > } > > > So, unchanged, this code will start to assert when the to projects merge. Maybe it would be nice to make a small/trivial upstream PR to add this code to both `MemAllocator::mem_clear` and `StackChunkAllocator::initialize`? Thanks for confirming. I added the check here which I think should cover any merge order. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828614946 From pchilanomate at openjdk.org Tue Nov 5 01:50:58 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 01:50:58 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision: > > - Add oopDesc::has_klass_gap() check > - Rename waitTimeout/set_waitTimeout accessors > - Revert suggestion to ThawBase::new_stack_frame > - Improve JFR pinned reason in event > - Use freeze_result consistently I brought some JFR changes from the loop repo that improve the reported reason when pinning. @mgronlun @egahlin Could any of you review these JFR changes? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2456054504 From syan at openjdk.org Tue Nov 5 01:51:37 2024 From: syan at openjdk.org (SendaoYan) Date: Tue, 5 Nov 2024 01:51:37 GMT Subject: RFR: 8343490: Update copyright year for JDK-8341692 Message-ID: <2BwWuKdm5FwggsXPwo3P2xRD6CGr5QDdn3gVG5x5fo0=.41d944e6-6737-4d7d-8654-986149b41c9d@github.com> Hi all, The copyright year of some files which has been changed by [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692) wasn't update correctly. This PR update the copyright year of [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692). Trivial fix, no risk. ------------- Commit messages: - delete tail whitespace of test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTest.java - 8343490: Update copyright year for JDK-8341692 Changes: https://git.openjdk.org/jdk/pull/21891/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21891&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343490 Stats: 66 lines in 66 files changed: 2 ins; 0 del; 64 mod Patch: https://git.openjdk.org/jdk/pull/21891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21891/head:pull/21891 PR: https://git.openjdk.org/jdk/pull/21891 From fyang at openjdk.org Tue Nov 5 02:30:08 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 5 Nov 2024 02:30:08 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v3] In-Reply-To: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> Message-ID: <3xbBQjaRN_b_zwjU4d8_yFaOyLouOFMDdSRnFhod7xc=.477d25da-6052-42f6-b334-685870b7e134@github.com> > Hi, please consider this cleanup change. > > The old trampoline call on linux-riscv64 is disabled by default after: https://bugs.openjdk.org/browse/JDK-8332689. > And the new solution (load target address from stub and call) has been baked in jdk master for quite some time. > This propose to remove the old trampoline call related logic so that the code will be cleaner and easier to maintain. > As we are still using `trampoline_stub_Relocation` for the stub, I kept using the original `emit_trampoline_stub` name. > > Testing on linux-riscv64: > - [x] tier1-tier3 (release) > - [x] hotspot:tier1 (fastdebug) Fei Yang has updated the pull request incrementally with one additional commit since the last revision: More comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21822/files - new: https://git.openjdk.org/jdk/pull/21822/files/714bf040..d88f481b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21822&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21822&range=01-02 Stats: 31 lines in 4 files changed: 3 ins; 10 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/21822.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21822/head:pull/21822 PR: https://git.openjdk.org/jdk/pull/21822 From fyang at openjdk.org Tue Nov 5 02:35:28 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 5 Nov 2024 02:35:28 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v2] In-Reply-To: References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> <2sK69C2o504u42d9Dq30fbwmKfwdT0Mn3OGTtxDJX9g=.9affa3a6-7cc2-476b-b19e-6775bf5f8912@github.com> Message-ID: On Mon, 4 Nov 2024 13:33:50 GMT, Robbin Ehn wrote: >> Fei Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> Comment > > src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 1597: > >> 1595: >> 1596: enum NativeFarCall { >> 1597: trampoline_size = 1 * instruction_size + wordSize, > > Call address stub size? I am a bit worried that `MacroAssembler::NativeShortCall` could be confusing with `MacroAssembler::far_call` in naming, so I simply removed this enum. I also improved the code comment about different types of calls. Let me know. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21822#discussion_r1828646165 From fyang at openjdk.org Tue Nov 5 02:38:46 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 5 Nov 2024 02:38:46 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v4] In-Reply-To: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> Message-ID: > Hi, please consider this cleanup change. > > The old trampoline call on linux-riscv64 is disabled by default after: https://bugs.openjdk.org/browse/JDK-8332689. > And the new solution (load target address from stub and call) has been baked in jdk master for quite some time. > This propose to remove the old trampoline call related logic so that the code will be cleaner and easier to maintain. > As we are still using `trampoline_stub_Relocation` for the stub, I kept using the original `emit_trampoline_stub` name. > > Testing on linux-riscv64: > - [x] tier1-tier3 (release) > - [x] hotspot:tier1 (fastdebug) Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Minor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21822/files - new: https://git.openjdk.org/jdk/pull/21822/files/d88f481b..4585a97d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21822&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21822&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21822.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21822/head:pull/21822 PR: https://git.openjdk.org/jdk/pull/21822 From amitkumar at openjdk.org Tue Nov 5 04:15:54 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 5 Nov 2024 04:15:54 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision: > > - Add oopDesc::has_klass_gap() check > - Rename waitTimeout/set_waitTimeout accessors > - Revert suggestion to ThawBase::new_stack_frame > - Improve JFR pinned reason in event > - Use freeze_result consistently Hi @pchilano, I see couple of failures on s390x, can you apply this patch: diff --git a/src/hotspot/cpu/s390/macroAssembler_s390.cpp b/src/hotspot/cpu/s390/macroAssembler_s390.cpp index f342240f3ca..d28b4579824 100644 --- a/src/hotspot/cpu/s390/macroAssembler_s390.cpp +++ b/src/hotspot/cpu/s390/macroAssembler_s390.cpp @@ -3492,7 +3492,7 @@ void MacroAssembler::increment_counter_eq(address counter_address, Register tmp1 void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Register temp1, Register temp2) { assert(LockingMode != LM_LIGHTWEIGHT, "uses fast_lock_lightweight"); - assert_different_registers(oop, box, temp1, temp2); + assert_different_registers(oop, box, temp1, temp2, Z_R0_scratch); Register displacedHeader = temp1; Register currentHeader = temp1; @@ -3566,8 +3566,8 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis // If csg succeeds then CR=EQ, otherwise, register zero is filled // with the current owner. z_lghi(zero, 0); - z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset())); - z_csg(zero, Z_R1_scratch, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner), monitor_tagged); + z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset())); + z_csg(zero, Z_R0_scratch, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner), monitor_tagged); // Store a non-null value into the box. z_stg(box, BasicLock::displaced_header_offset_in_bytes(), box); @@ -3576,7 +3576,7 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis BLOCK_COMMENT("fast_path_recursive_lock {"); // Check if we are already the owner (recursive lock) - z_cgr(Z_R1_scratch, zero); // owner is stored in zero by "z_csg" above + z_cgr(Z_R0_scratch, zero); // owner is stored in zero by "z_csg" above z_brne(done); // not a recursive lock // Current thread already owns the lock. Just increment recursion count. @@ -3594,7 +3594,7 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis void MacroAssembler::compiler_fast_unlock_object(Register oop, Register box, Register temp1, Register temp2) { assert(LockingMode != LM_LIGHTWEIGHT, "uses fast_unlock_lightweight"); - assert_different_registers(oop, box, temp1, temp2); + assert_different_registers(oop, box, temp1, temp2, Z_R0_scratch); Register displacedHeader = temp1; Register currentHeader = temp2; @@ -3641,8 +3641,8 @@ void MacroAssembler::compiler_fast_unlock_object(Register oop, Register box, Reg // Handle existing monitor. bind(object_has_monitor); - z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset())); - z_cg(Z_R1_scratch, Address(currentHeader, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner))); + z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset())); + z_cg(Z_R0_scratch, Address(currentHeader, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner))); z_brne(done); BLOCK_COMMENT("fast_path_recursive_unlock {"); @@ -6164,7 +6164,7 @@ void MacroAssembler::lightweight_unlock(Register obj, Register temp1, Register t } void MacroAssembler::compiler_fast_lock_lightweight_object(Register obj, Register box, Register tmp1, Register tmp2) { - assert_different_registers(obj, box, tmp1, tmp2); + assert_different_registers(obj, box, tmp1, tmp2, Z_R0_scratch); // Handle inflated monitor. NearLabel inflated; @@ -6296,12 +6296,12 @@ void MacroAssembler::compiler_fast_lock_lightweight_object(Register obj, Registe // If csg succeeds then CR=EQ, otherwise, register zero is filled // with the current owner. z_lghi(zero, 0); - z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset())); - z_csg(zero, Z_R1_scratch, owner_address); + z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset())); + z_csg(zero, Z_R0_scratch, owner_address); z_bre(monitor_locked); // Check if recursive. - z_cgr(Z_R1_scratch, zero); // zero contains the owner from z_csg instruction + z_cgr(Z_R0_scratch, zero); // zero contains the owner from z_csg instruction z_brne(slow_path); // Recursive CC: @RealLucy ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2414585800 From fjiang at openjdk.org Tue Nov 5 05:23:32 2024 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 5 Nov 2024 05:23:32 GMT Subject: RFR: 8343502: RISC-V: SIGBUS in updateBytesCRC32 after JDK-8339738 In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 03:48:48 GMT, Fei Yang wrote: > Hi, please review this small change. > > [JDK-8339738](https://bugs.openjdk.org/browse/JDK-8339738) adds vectorization for crc32 intrinsic, which does `vle32.v` from the input byte buffer and calculates the checksum. But the input byte buffer could be misaligned (not 4-byte aligned). This leads to SIGBUS on hardware platforms like `BPI-F3` board where misaligned vector loads are not supported. Similar issue is there for scalar version as well, which could mean performance issue on other hardwares. Patch fixes this issue by adding a small alignment processing on entry for both scalar and vector version. > > This also fixes another potential issue in tail handling, where we do a single `lwu` for both versions to load the remaining bytes from the input byte buffer and extract each byte from the loaded 32-bit value. Since we only have less than 4 bytes remaining, this `lwu` would exceed the buffer limit, which I think is not safe. Patch fixes this issue by doing three separate `lbu` instead. > > Testing on `BPI-F3` with RVV 1.0 extension: > - [x] test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java > - [x] test/jdk/java/util/zip/TestCRC32.java > - [x] SPECjbb2015 > > No obvious impact witnessed on `micro:java.util.TestCRC32`: > > > Before: > Benchmark (count) Mode Cnt Score Error Units > TestCRC32.testCRC32Update 64 thrpt 12 4778.903 ? 1.793 ops/ms > TestCRC32.testCRC32Update 128 thrpt 12 2655.639 ? 2.958 ops/ms > TestCRC32.testCRC32Update 256 thrpt 12 1430.997 ? 0.970 ops/ms > TestCRC32.testCRC32Update 512 thrpt 12 965.785 ? 1.840 ops/ms > TestCRC32.testCRC32Update 2048 thrpt 12 303.056 ? 0.620 ops/ms > TestCRC32.testCRC32Update 16384 thrpt 12 40.601 ? 0.220 ops/ms > TestCRC32.testCRC32Update 65536 thrpt 12 9.575 ? 0.045 ops/ms > TestCRC32C.testCRC32CUpdate 64 thrpt 12 3923.698 ? 23.209 ops/ms > TestCRC32C.testCRC32CUpdate 128 thrpt 12 2514.616 ? 22.991 ops/ms > TestCRC32C.testCRC32CUpdate 256 thrpt 12 1477.223 ? 2.319 ops/ms > TestCRC32C.testCRC32CUpdate 512 thrpt 12 806.179 ? 1.961 ops/ms > TestCRC32C.testCRC32CUpdate 2048 thrpt 12 216.396 ? 0.172 ops/ms > TestCRC32C.testCRC32CUpdate 16384 thrpt 12 27.526 ? 0.049 ops/ms > TestCRC32C.testCRC32CUpdate 65536 thrpt 12 6.530 ? 0.041 ops/ms > > After: > Benchmark (count) Mode Cnt Score Error Units > TestCRC32.testCRC32Update 64 ... Looks good. ------------- Marked as reviewed by fjiang (Committer). PR Review: https://git.openjdk.org/jdk/pull/21863#pullrequestreview-2414646366 From fyang at openjdk.org Tue Nov 5 06:35:52 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 5 Nov 2024 06:35:52 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v12] In-Reply-To: References: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com> Message-ID: On Mon, 4 Nov 2024 18:18:38 GMT, Patricio Chilano Mateo wrote: >> Here's my suggested C2 change: >> >> diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad >> index d9c77a2f529..1e99db191ae 100644 >> --- a/src/hotspot/cpu/aarch64/aarch64.ad >> +++ b/src/hotspot/cpu/aarch64/aarch64.ad >> @@ -3692,14 +3692,13 @@ encode %{ >> __ post_call_nop(); >> } else { >> Label retaddr; >> + // Make the anchor frame walkable >> __ adr(rscratch2, retaddr); >> + __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset())); >> __ lea(rscratch1, RuntimeAddress(entry)); >> - // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc() >> - __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize))); >> __ blr(rscratch1); >> __ bind(retaddr); >> __ post_call_nop(); >> - __ add(sp, sp, 2 * wordSize); >> } >> if (Compile::current()->max_vector_size() > 0) { >> __ reinitialize_ptrue(); > > Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code. > @RealFYang I made the equivalent change for riscv, could you verify it's okay? @pchilano : Hi, Great to see `possibly_adjust_frame()` go away. Nice cleanup! `hotspot_loom jdk_loom` still test good with both release and fastdebug builds on linux-riscv64 platform. BTW: I noticed one more return miss prediction case which I think was previously missed in https://github.com/openjdk/jdk/pull/21565/commits/32840de91953a5e50c85217f2a51fc5a901682a2 Do you mind adding following small addon change to fix it? Thanks. diff --git a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp index 84a292242c3..ac28f4b3514 100644 --- a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp +++ b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp @@ -1263,10 +1263,10 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) { if (LockingMode != LM_LEGACY) { // Check preemption for Object.wait() Label not_preempted; - __ ld(t0, Address(xthread, JavaThread::preempt_alternate_return_offset())); - __ beqz(t0, not_preempted); + __ ld(t1, Address(xthread, JavaThread::preempt_alternate_return_offset())); + __ beqz(t1, not_preempted); __ sd(zr, Address(xthread, JavaThread::preempt_alternate_return_offset())); - __ jr(t0); + __ jr(t1); __ bind(native_return); __ restore_after_resume(true /* is_native */); // reload result_handler ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828797495 From aboldtch at openjdk.org Tue Nov 5 06:39:00 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 5 Nov 2024 06:39:00 GMT Subject: RFR: 8340586: JdkJfrEvent::get_all_klasses stores non-strong oops in JNI handles Message-ID: JdkJfrEvent::get_all_klasses walks the class hierarchy of the Event class to find all event sub klasses. The mirrors of these classes are then stored in JNI handles and eventually transfered to an arraylist which is returned to the java caller. Because the klasses are found by walking the class hierarchy, their is no guarantee that the klass is strongly reachable, and thus that the java_mirror load is strong. So we must explicitly keep the klass alive (and not have a safepoint between the load and the store into the object graph). Having both `fill_klasses` and `transform_klasses_to_local_jni_handles` made the call to `keep_alive` and the comment explaining the reason why somewhat obscured, so I merged them. (The split seems to have served no purpose except to introduce the need for a lot of const and reinterpret casts.) ------------- Commit messages: - 8340586: JdkJfrEvent::get_all_klasses stores non-strong oops in JNI handles Changes: https://git.openjdk.org/jdk/pull/21893/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21893&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340586 Stats: 32 lines in 3 files changed: 15 ins; 13 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/21893.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21893/head:pull/21893 PR: https://git.openjdk.org/jdk/pull/21893 From rehn at openjdk.org Tue Nov 5 07:25:28 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 5 Nov 2024 07:25:28 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v4] In-Reply-To: References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> Message-ID: <22Bv0L9PeAFmBPDRq3mKMLJo0JRponaNZLtxlacgEEo=.2a7285b2-3a05-4ffd-a4fe-7e873c7b7ee1@github.com> On Tue, 5 Nov 2024 02:38:46 GMT, Fei Yang wrote: >> Hi, please consider this cleanup change. >> >> The old trampoline call on linux-riscv64 is disabled by default after: https://bugs.openjdk.org/browse/JDK-8332689. >> And the new solution (load target address from stub and call) has been baked in jdk master for quite some time. >> This propose to remove the old trampoline call related logic so that the code will be cleaner and easier to maintain. >> As we are still using `trampoline_stub_Relocation` for the stub, I kept using the original `emit_trampoline_stub` name. >> >> Testing on linux-riscv64: >> - [x] tier1-tier3 (release) >> - [x] hotspot:tier1 (fastdebug) > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Minor Thanks, I think it looks good. ------------- Marked as reviewed by rehn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21822#pullrequestreview-2414808091 From egahlin at openjdk.org Tue Nov 5 08:02:54 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 5 Nov 2024 08:02:54 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision: > > - Add oopDesc::has_klass_gap() check > - Rename waitTimeout/set_waitTimeout accessors > - Revert suggestion to ThawBase::new_stack_frame > - Improve JFR pinned reason in event > - Use freeze_result consistently src/hotspot/share/jfr/metadata/metadata.xml line 160: > 158: > 159: > 160: Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html (Note: The fact that the event is now written in the JVM doesn't determine the category.) src/hotspot/share/jfr/metadata/metadata.xml line 160: > 158: > 159: > 160: The label should be "Blocking Operation" with a capital "O". Labels use headline-style capitalization. See here for more information: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Label.html ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828875263 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828878025 From alanb at openjdk.org Tue Nov 5 08:22:55 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 5 Nov 2024 08:22:55 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 07:48:40 GMT, Erik Gahlin wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision: >> >> - Add oopDesc::has_klass_gap() check >> - Rename waitTimeout/set_waitTimeout accessors >> - Revert suggestion to ThawBase::new_stack_frame >> - Improve JFR pinned reason in event >> - Use freeze_result consistently > > src/hotspot/share/jfr/metadata/metadata.xml line 160: > >> 158: >> 159: >> 160: > > Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category: > > https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html > > (Note: The fact that the event is now written in the JVM doesn't determine the category.) Thanks for spotting this, it wasn't intended to change the category. I think it's that Event element was copied from another event when adding it to metadata.xml and value that was in the `@Catalog` wasn't carried over. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828915229 From sspitsyn at openjdk.org Tue Nov 5 08:33:28 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 5 Nov 2024 08:33:28 GMT Subject: RFR: 8342577: Clean up JVMTI breakpoint support In-Reply-To: References: Message-ID: On Thu, 24 Oct 2024 01:42:36 GMT, Alex Menkov wrote: > The fix cleans up code to support list of JVMTI breakpoints. > - classes required to supports cache of byte code pointers (GrowableElement, GrowableCache, JvmtiBreakpointCache) are dropped; > - class JvmtiCurrentBreakpoints (JvmtiBreakpoints factory) is left as is, dropped unused code; > - fixed race in JvmtiCurrentBreakpoints::get_jvmti_breakpoints() (fix for JDK-8210637); > - JvmtiBreakpoint:JvmtiBreakpoint() + JvmtiBreakpoint::copy(JvmtiBreakpoint& bp) are replaced with copy ctor; > - JvmtiBreakpoints::clearall_in_class_at_safepoint() is simplified to do a single pass; > > Testing: tier1..tier6 Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21675#pullrequestreview-2414941187 From aph-open at littlepinkcloud.com Tue Nov 5 09:02:28 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 5 Nov 2024 09:02:28 +0000 Subject: RFR: 8328944: NMT reports "unknown" memory In-Reply-To: References: Message-ID: <21c0a0dc-a67f-4d1e-8c7c-9b4d2b41be25@littlepinkcloud.com> On 11/4/24 13:33, Thomas Stuefe wrote: > Bottomline, allocation operations on the system level don't necessarily map 1:1 to NMT semantic tagging. We should not hard-code this requirement into NMT. It limits the future usefulness of NMT, and/or limits how we allow ourselves to allocate memory (which should always take the most efficient route and not be limited by what NMT can or can't do). That makes a lot of sense. -- 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 stuefe at openjdk.org Tue Nov 5 09:18:28 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 5 Nov 2024 09:18:28 GMT Subject: RFR: 8328944: NMT reports "unknown" memory In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 20:44:50 GMT, Gerard Ziemski wrote: > We use mtNone value in several functions default parameters, which may show up in NMT reports. > > We address this, by removing the default value and forcing, where possible, for the callers to declare NMT tag that reflects the usage. > > Eventually the goal would be not to use mtNone anywhere, but we are not there quite yet. > > TODO: update copyrights. > > Testing: undergoing MARCH5 tier1-5 ... In case this does not come across: I really welcome fixing unnecessary "mtNone" uses. I would like to see a nuanced approach though. The rule should be to try to use the correct tag at reservation. But exceptions should be allowed: - if the tag is not clear at reservation, any other tag than mtNone (or the proposed mtAny) would be wrong - if it makes the code a lot more brittle because reservation is "smeared" across many different mmap calls in many conditional branches. In that case, it is easier to tag the whole range after all that reservation business is done, outside the conditional branches. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21843#issuecomment-2456635960 From mli at openjdk.org Tue Nov 5 09:49:43 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 5 Nov 2024 09:49:43 GMT Subject: RFR: 8343600: RISC-V: enable CRC32 intrinsic when either Zba or RVV are supported Message-ID: Hi, Can you help to review this patch? There were 2 intrinsic optimizations, scalar one and vector one, * plain scalar one optimizes cases when data size is small, scalar one with zba optimizes cases when data size is big; * vector one optimizes cases when data size is big (better than scalar one with zba). With RVV supported, when the size is small it will go to scalar code path, when the size is big it will go to RVV path then scalar path, so that means the RVV itself are sufficient enough to enable the intrinsic even without Zba supported. Thanks! ------------- Commit messages: - Initial commit - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Revert "initial commit" - initial commit Changes: https://git.openjdk.org/jdk/pull/21897/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21897&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343600 Stats: 34 lines in 1 file changed: 18 ins; 16 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21897.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21897/head:pull/21897 PR: https://git.openjdk.org/jdk/pull/21897 From fyang at openjdk.org Tue Nov 5 10:18:29 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 5 Nov 2024 10:18:29 GMT Subject: RFR: 8343600: RISC-V: enable CRC32 intrinsic when either Zba or RVV are supported In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 09:44:21 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > There were 2 intrinsic optimizations, scalar one and vector one, > * plain scalar one optimizes cases when data size is small, scalar one with zba optimizes cases when data size is big; > * vector one optimizes cases when data size is big (better than scalar one with zba). > > With RVV supported, when the size is small it will go to scalar code path, when the size is big it will go to RVV path then scalar path, so that means the RVV itself are sufficient enough to enable the intrinsic even without Zba supported. > > Thanks! The previous `UseZba` check seems a bit strange to me. I will retry to see if it's necessary. ------------- PR Review: https://git.openjdk.org/jdk/pull/21897#pullrequestreview-2415196589 From fyang at openjdk.org Tue Nov 5 10:22:29 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 5 Nov 2024 10:22:29 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v4] In-Reply-To: <22Bv0L9PeAFmBPDRq3mKMLJo0JRponaNZLtxlacgEEo=.2a7285b2-3a05-4ffd-a4fe-7e873c7b7ee1@github.com> References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> <22Bv0L9PeAFmBPDRq3mKMLJo0JRponaNZLtxlacgEEo=.2a7285b2-3a05-4ffd-a4fe-7e873c7b7ee1@github.com> Message-ID: On Tue, 5 Nov 2024 07:22:55 GMT, Robbin Ehn wrote: > Thanks, I think it looks good. Thanks for the suggestions. I will wait for another reviewer. @Hamlin-Li : Do you want to take a look? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21822#issuecomment-2456780211 From duke at openjdk.org Tue Nov 5 10:23:37 2024 From: duke at openjdk.org (Mikhail Ablakatov) Date: Tue, 5 Nov 2024 10:23:37 GMT Subject: Integrated: 8341194: [REDO] Implement C2 VectorizedHashCode on AArch64 In-Reply-To: References: Message-ID: On Tue, 1 Oct 2024 12:48:21 GMT, Mikhail Ablakatov wrote: > Fix and redo [JDK-8322770](https://bugs.openjdk.org/browse/JDK-8322770) which got backed out in [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197) due to test failures / jlink failure. Initial PR: https://github.com/openjdk/jdk/pull/18487. > > Compared to the initial PR, this one eliminates a mismatch between the `arrays_hashcode()` template and stub. The template defined v0-v7 & v12-v17 as TEMP registers but the stub used v8-v9 which were not on the list. Changing v8-v9 in the stub to v12-v13 eliminates this mismatch. Other changes in aarch64.ad is just a cleanup as some registers on the list were not used by the stub at all anymore. > > Following the discussion on [JDK-8341197](https://bugs.openjdk.org/browse/JDK-8341197), we've added a `make bootcycle-images` step to our local CI pipeline to verify that the issue is fixed. This pull request has now been integrated. Changeset: 4fc6d413 Author: Mikhail Ablakatov URL: https://git.openjdk.org/jdk/commit/4fc6d4135e795d18a024a6035908f380b81082d1 Stats: 1346 lines in 12 files changed: 766 ins; 0 del; 580 mod 8341194: [REDO] Implement C2 VectorizedHashCode on AArch64 Reviewed-by: aph, adinn ------------- PR: https://git.openjdk.org/jdk/pull/21286 From mli at openjdk.org Tue Nov 5 10:25:29 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 5 Nov 2024 10:25:29 GMT Subject: RFR: 8343600: RISC-V: enable CRC32 intrinsic when either Zba or RVV are supported In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 10:16:00 GMT, Fei Yang wrote: > The previous `UseZba` check seems a bit strange to me. I will retry to see if it's necessary. Thanks. Yeah, seems to me too. Previously, I did not follow the pr all the time, by going through the discussion history, seems without Zba supported and when data size is big enough, it will introduce performance regression, so the pr use Zba to tell if or not turn on the intrinsic finally. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21897#issuecomment-2456786470 From mli at openjdk.org Tue Nov 5 11:00:29 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 5 Nov 2024 11:00:29 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v4] In-Reply-To: References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> Message-ID: On Tue, 5 Nov 2024 02:38:46 GMT, Fei Yang wrote: >> Hi, please consider this cleanup change. >> >> The old trampoline call on linux-riscv64 is disabled by default after: https://bugs.openjdk.org/browse/JDK-8332689. >> And the new solution (load target address from stub and call) has been baked in jdk master for quite some time. >> This propose to remove the old trampoline call related logic so that the code will be cleaner and easier to maintain. >> As we are still using `trampoline_stub_Relocation` for the stub, I kept using the original `emit_trampoline_stub` name. >> >> Testing on linux-riscv64: >> - [x] tier1-tier3 (release) >> - [x] hotspot:tier1 (fastdebug) > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Minor Looks good. Thanks. ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21822#pullrequestreview-2415297164 From mbaesken at openjdk.org Tue Nov 5 11:36:32 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 5 Nov 2024 11:36:32 GMT Subject: RFR: 8342893: Highlight special values in hserr file printing [v2] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 21:07:32 GMT, Dean Long wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> compile error on Linux x86 and arm 32bit > > src/hotspot/share/runtime/os.cpp line 1346: > >> 1344: #ifndef PRODUCT >> 1345: // corruption or uninitialized access pattern >> 1346: const intptr_t pat = 0xabababababababab; > > How about constructing this from `badResourceValue`? We could also put another variable centrally next to badResourceValue , see https://github.com/openjdk/jdk/blob/4fc6d4135e795d18a024a6035908f380b81082d1/src/hotspot/share/utilities/globalDefinitions.hpp#L1044 do you have a good naming for this ? Maybe `badZapValue` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21811#discussion_r1829197572 From sspitsyn at openjdk.org Tue Nov 5 11:38:53 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 5 Nov 2024 11:38:53 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision: > > - Add oopDesc::has_klass_gap() check > - Rename waitTimeout/set_waitTimeout accessors > - Revert suggestion to ThawBase::new_stack_frame > - Improve JFR pinned reason in event > - Use freeze_result consistently src/hotspot/share/runtime/objectMonitor.cpp line 1643: > 1641: // actual callee (see nmethod::preserve_callee_argument_oops()). > 1642: ThreadOnMonitorWaitedEvent tmwe(current); > 1643: JvmtiExport::vthread_post_monitor_waited(current, node->_monitor, timed_out); We post a JVMTI `MonitorWaited` event here for a virtual thread. A couple of questions on this: - Q1: Is this posted after the `VirtualThreadMount` extension event posted? Unfortunately, it is not easy to make this conclusion. - Q2: The `JvmtiExport::post_monitor_waited()` is called at the line 1801. Does it post the `MonitorWaited` event for this virtual thread as well? If not, then it is not clear how posting for virtual thread is avoided. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829199889 From coleenp at openjdk.org Tue Nov 5 13:16:36 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 5 Nov 2024 13:16:36 GMT Subject: RFR: 8340586: JdkJfrEvent::get_all_klasses stores non-strong oops in JNI handles In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 06:34:02 GMT, Axel Boldt-Christmas wrote: > JdkJfrEvent::get_all_klasses walks the class hierarchy of the Event class to find all event sub klasses. The mirrors of these classes are then stored in JNI handles and eventually transfered to an arraylist which is returned to the java caller. > > Because the klasses are found by walking the class hierarchy, their is no guarantee that the klass is strongly reachable, and thus that the java_mirror load is strong. So we must explicitly keep the klass alive (and not have a safepoint between the load and the store into the object graph). > > Having both `fill_klasses` and `transform_klasses_to_local_jni_handles` made the call to `keep_alive` and the comment explaining the reason why somewhat obscured, so I merged them. (The split seems to have served no purpose except to introduce the need for a lot of const and reinterpret casts.) This looks good and thanks for the cleanup of the jfr code. I went through this code for either this bug or another one, and thought it looked okay. We should look for other uses of java_mirror that assume that having a reference to it keeps the CLD alive. src/hotspot/share/oops/klass.inline.hpp line 44: > 42: static_cast(klass_holder()); > 43: } > 44: Can you add a comment to Klass::java_mirror() that says it doesn't keep the loader alive, "see above". ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21893#pullrequestreview-2415590248 PR Review Comment: https://git.openjdk.org/jdk/pull/21893#discussion_r1829330520 From duke at openjdk.org Tue Nov 5 13:18:00 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Tue, 5 Nov 2024 13:18:00 GMT Subject: RFR: 8343452: Incorrect WINDOWS build variable is used in macroAssembler_x86.cpp Message-ID: >From JBS: > HotSpot VM build macro defines _WINDOWS env variable only. > call_clobbered_gp_registers() and call_clobbered_xmm_registers() incorrectly use WINDOWS (without underscore). > RSI and RDI are missing from list of clobbered register on windows due to that and may cause issue when calling native code which modifies them. > > AMM register are less affected because all XMM registers are listed as clobbered. > > The code was added by [JDK-8283327](https://bugs.openjdk.org/browse/JDK-8283327) changes in JDK 19. ------------- Commit messages: - Fix macro name Changes: https://git.openjdk.org/jdk/pull/21901/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21901&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343452 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21901.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21901/head:pull/21901 PR: https://git.openjdk.org/jdk/pull/21901 From duke at openjdk.org Tue Nov 5 13:19:09 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Tue, 5 Nov 2024 13:19:09 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding Message-ID: - Changed several "NULL" in comments to "null" - Changed several `NULL` in code to `nullptr` ------------- Commit messages: - Fix copyright year - 8342860: Fix more NULL usage backsliding Changes: https://git.openjdk.org/jdk/pull/21826/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21826&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342860 Stats: 22 lines in 11 files changed: 0 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/21826.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21826/head:pull/21826 PR: https://git.openjdk.org/jdk/pull/21826 From szaldana at openjdk.org Tue Nov 5 13:19:09 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 5 Nov 2024 13:19:09 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 13:35:56 GMT, theoweidmannoracle wrote: > - Changed several "NULL" in comments to "null" > - Changed several `NULL` in code to `nullptr` I am not a Reviewer but I left a small comment. Cheers! src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 1: > 1: /* Missing copyright update. ------------- Changes requested by szaldana (Committer). PR Review: https://git.openjdk.org/jdk/pull/21826#pullrequestreview-2413904415 PR Review Comment: https://git.openjdk.org/jdk/pull/21826#discussion_r1828249544 From duke at openjdk.org Tue Nov 5 13:19:09 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Tue, 5 Nov 2024 13:19:09 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 19:10:50 GMT, Sonia Zaldana Calles wrote: >> - Changed several "NULL" in comments to "null" >> - Changed several `NULL` in code to `nullptr` > > src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 1: > >> 1: /* > > Missing copyright update. Thanks for spotting this! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21826#discussion_r1829109988 From duke at openjdk.org Tue Nov 5 13:19:15 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Tue, 5 Nov 2024 13:19:15 GMT Subject: RFR: 8341411: C2: remove slice parameter from GraphKit::make_load() and GraphKit::store_to_memor() Message-ID: This patch removes the address type from `GraphKit::make_load()` and `GraphKit::store_to_memory()` As https://github.com/openjdk/jdk/pull/21303 introduced asserts that check that the address type agrees with `C->get_alias_index(_gvn.type(adr)->isa_ptr()`, passing the address type is redundant and it can be computed internally from the address. ------------- Commit messages: - 8341411: C2: remove slice parameter from GraphKit::make_load() and GraphKit::store_to_memor() Changes: https://git.openjdk.org/jdk/pull/21834/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21834&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341411 Stats: 63 lines in 8 files changed: 1 ins; 28 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/21834.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21834/head:pull/21834 PR: https://git.openjdk.org/jdk/pull/21834 From stefank at openjdk.org Tue Nov 5 13:40:28 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 5 Nov 2024 13:40:28 GMT Subject: RFR: 8340586: JdkJfrEvent::get_all_klasses stores non-strong oops in JNI handles In-Reply-To: References: Message-ID: <4FBiwgT4B61lCvH5ARkF8P7ke5L30UGoEgdacDQUu9A=.815cf062-b315-4941-a939-13535bd4b0fd@github.com> On Tue, 5 Nov 2024 06:34:02 GMT, Axel Boldt-Christmas wrote: > JdkJfrEvent::get_all_klasses walks the class hierarchy of the Event class to find all event sub klasses. The mirrors of these classes are then stored in JNI handles and eventually transfered to an arraylist which is returned to the java caller. > > Because the klasses are found by walking the class hierarchy, their is no guarantee that the klass is strongly reachable, and thus that the java_mirror load is strong. So we must explicitly keep the klass alive (and not have a safepoint between the load and the store into the object graph). > > Having both `fill_klasses` and `transform_klasses_to_local_jni_handles` made the call to `keep_alive` and the comment explaining the reason why somewhat obscured, so I merged them. (The split seems to have served no purpose except to introduce the need for a lot of const and reinterpret casts.) Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21893#pullrequestreview-2415643300 From stefank at openjdk.org Tue Nov 5 13:40:30 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 5 Nov 2024 13:40:30 GMT Subject: RFR: 8340586: JdkJfrEvent::get_all_klasses stores non-strong oops in JNI handles In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 13:12:51 GMT, Coleen Phillimore wrote: >> JdkJfrEvent::get_all_klasses walks the class hierarchy of the Event class to find all event sub klasses. The mirrors of these classes are then stored in JNI handles and eventually transfered to an arraylist which is returned to the java caller. >> >> Because the klasses are found by walking the class hierarchy, their is no guarantee that the klass is strongly reachable, and thus that the java_mirror load is strong. So we must explicitly keep the klass alive (and not have a safepoint between the load and the store into the object graph). >> >> Having both `fill_klasses` and `transform_klasses_to_local_jni_handles` made the call to `keep_alive` and the comment explaining the reason why somewhat obscured, so I merged them. (The split seems to have served no purpose except to introduce the need for a lot of const and reinterpret casts.) > > src/hotspot/share/oops/klass.inline.hpp line 44: > >> 42: static_cast(klass_holder()); >> 43: } >> 44: > > Can you add a comment to Klass::java_mirror() that says it doesn't keep the loader alive, "see above". > safe to store in the object graph. It could be good to also mention roots like Handles, since that seems to be a common misunderstanding: > safe to store in the object graph and it's roots (E.g. Handles). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21893#discussion_r1829360474 From mgronlun at openjdk.org Tue Nov 5 13:40:30 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 5 Nov 2024 13:40:30 GMT Subject: RFR: 8340586: JdkJfrEvent::get_all_klasses stores non-strong oops in JNI handles In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 13:32:27 GMT, Stefan Karlsson wrote: >> src/hotspot/share/oops/klass.inline.hpp line 44: >> >>> 42: static_cast(klass_holder()); >>> 43: } >>> 44: >> >> Can you add a comment to Klass::java_mirror() that says it doesn't keep the loader alive, "see above". > >> safe to store in the object graph. > > It could be good to also mention roots like Handles, since that seems to be a common misunderstanding: > >> safe to store in the object graph and it's roots (E.g. Handles). Why is not java_mirror() extended to set this keep_alive() of the CLD oop-stuff under the hood? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21893#discussion_r1829369701 From aboldtch at openjdk.org Tue Nov 5 13:57:04 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 5 Nov 2024 13:57:04 GMT Subject: RFR: 8340586: JdkJfrEvent::get_all_klasses stores non-strong oops in JNI handles [v2] In-Reply-To: References: Message-ID: > JdkJfrEvent::get_all_klasses walks the class hierarchy of the Event class to find all event sub klasses. The mirrors of these classes are then stored in JNI handles and eventually transfered to an arraylist which is returned to the java caller. > > Because the klasses are found by walking the class hierarchy, their is no guarantee that the klass is strongly reachable, and thus that the java_mirror load is strong. So we must explicitly keep the klass alive (and not have a safepoint between the load and the store into the object graph). > > Having both `fill_klasses` and `transform_klasses_to_local_jni_handles` made the call to `keep_alive` and the comment explaining the reason why somewhat obscured, so I merged them. (The split seems to have served no purpose except to introduce the need for a lot of const and reinterpret casts.) Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: Update comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21893/files - new: https://git.openjdk.org/jdk/pull/21893/files/0db0cacd..f8ebdbf1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21893&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21893&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21893.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21893/head:pull/21893 PR: https://git.openjdk.org/jdk/pull/21893 From szaldana at openjdk.org Tue Nov 5 14:24:39 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 5 Nov 2024 14:24:39 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding In-Reply-To: References: Message-ID: <8-DSId0L1YvlZctIylDj_p0UMXpuO-9cd-_lXSVlD1M=.21b528f7-e7ea-4d52-84e4-0af1424c9fa7@github.com> On Fri, 1 Nov 2024 13:35:56 GMT, theoweidmannoracle wrote: > - Changed several "NULL" in comments to "null" > - Changed several `NULL` in code to `nullptr` Hi @theoweidmannoracle, I think the GHA tests are not running because you haven't enabled GHA on your personal fork. See https://wiki.openjdk.org/display/SKARA/Testing for a bit more info. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21826#issuecomment-2457309128 From pchilanomate at openjdk.org Tue Nov 5 14:34:21 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 14:34:21 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v31] In-Reply-To: References: Message-ID: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision: - Fixes to JFR metadata.xml - Fix return miss prediction in generate_native_entry for riscv - Fix s390x failures ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21565/files - new: https://git.openjdk.org/jdk/pull/21565/files/79189f9b..124efa0a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=30 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=29-30 Stats: 16 lines in 3 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From pchilanomate at openjdk.org Tue Nov 5 14:34:22 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 14:34:22 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v12] In-Reply-To: References: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com> Message-ID: On Tue, 5 Nov 2024 06:30:55 GMT, Fei Yang wrote: >> Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code. >> @RealFYang I made the equivalent change for riscv, could you verify it's okay? > > @pchilano : Hi, Great to see `possibly_adjust_frame()` go away. Nice cleanup! > `hotspot_loom jdk_loom` still test good with both release and fastdebug builds on linux-riscv64 platform. > > BTW: I noticed one more return miss prediction case which I think was previously missed in https://github.com/openjdk/jdk/pull/21565/commits/32840de91953a5e50c85217f2a51fc5a901682a2 > Do you mind adding following small addon change to fix it? Thanks. > > diff --git a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp > index 84a292242c3..ac28f4b3514 100644 > --- a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp > +++ b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp > @@ -1263,10 +1263,10 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) { > if (LockingMode != LM_LEGACY) { > // Check preemption for Object.wait() > Label not_preempted; > - __ ld(t0, Address(xthread, JavaThread::preempt_alternate_return_offset())); > - __ beqz(t0, not_preempted); > + __ ld(t1, Address(xthread, JavaThread::preempt_alternate_return_offset())); > + __ beqz(t1, not_preempted); > __ sd(zr, Address(xthread, JavaThread::preempt_alternate_return_offset())); > - __ jr(t0); > + __ jr(t1); > __ bind(native_return); > __ restore_after_resume(true /* is_native */); > // reload result_handler Thanks for checking. Added changes to `TemplateInterpreterGenerator::generate_native_entry`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829457335 From pchilanomate at openjdk.org Tue Nov 5 14:37:54 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 14:37:54 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: <8bSr_dBqhXkGBdKhm3qO4j1XJHBtu_RkeIH8ldtDAVA=.b9ae55cd-0172-40f4-bb51-cb72eadac61d@github.com> On Tue, 5 Nov 2024 01:47:29 GMT, Patricio Chilano Mateo wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision: >> >> - Add oopDesc::has_klass_gap() check >> - Rename waitTimeout/set_waitTimeout accessors >> - Revert suggestion to ThawBase::new_stack_frame >> - Improve JFR pinned reason in event >> - Use freeze_result consistently > > I brought some JFR changes from the loom repo that improve the reported reason when pinning. > @mgronlun @egahlin Could any of you review these JFR changes? Thanks. > Hi @pchilano, > > I see couple of failures on s390x, can you apply this patch: > Thanks @offamitkumar. Fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2457338726 From aboldtch at openjdk.org Tue Nov 5 14:37:57 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 5 Nov 2024 14:37:57 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision: > > - Add oopDesc::has_klass_gap() check > - Rename waitTimeout/set_waitTimeout accessors > - Revert suggestion to ThawBase::new_stack_frame > - Improve JFR pinned reason in event > - Use freeze_result consistently src/hotspot/share/runtime/objectMonitor.inline.hpp line 50: > 48: inline int64_t ObjectMonitor::owner_from(oop vthread) { > 49: int64_t tid = java_lang_Thread::thread_id(vthread); > 50: assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable"); Suggestion: assert(tid >= ThreadIdentifier::initial() && tid < ThreadIdentifier::current(), "must be reasonable"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829464866 From pchilanomate at openjdk.org Tue Nov 5 14:37:55 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 14:37:55 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 08:19:34 GMT, Alan Bateman wrote: >> src/hotspot/share/jfr/metadata/metadata.xml line 160: >> >>> 158: >>> 159: >>> 160: >> >> Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category: >> >> https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html >> >> (Note: The fact that the event is now written in the JVM doesn't determine the category.) > > Thanks for spotting this, it wasn't intended to change the category. I think it's that Event element was copied from another event when adding it to metadata.xml and value from `@Category` wasn't carried over. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829462765 From pchilanomate at openjdk.org Tue Nov 5 14:37:56 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 14:37:56 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 07:51:05 GMT, Erik Gahlin wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision: >> >> - Add oopDesc::has_klass_gap() check >> - Rename waitTimeout/set_waitTimeout accessors >> - Revert suggestion to ThawBase::new_stack_frame >> - Improve JFR pinned reason in event >> - Use freeze_result consistently > > src/hotspot/share/jfr/metadata/metadata.xml line 160: > >> 158: >> 159: >> 160: > > The label should be "Blocking Operation" with a capital "O". > > Labels use headline-style capitalization. See here for more information: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Label.html Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829463128 From coleenp at openjdk.org Tue Nov 5 14:51:32 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 5 Nov 2024 14:51:32 GMT Subject: RFR: 8340586: JdkJfrEvent::get_all_klasses stores non-strong oops in JNI handles [v2] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 13:57:04 GMT, Axel Boldt-Christmas wrote: >> JdkJfrEvent::get_all_klasses walks the class hierarchy of the Event class to find all event sub klasses. The mirrors of these classes are then stored in JNI handles and eventually transfered to an arraylist which is returned to the java caller. >> >> Because the klasses are found by walking the class hierarchy, their is no guarantee that the klass is strongly reachable, and thus that the java_mirror load is strong. So we must explicitly keep the klass alive (and not have a safepoint between the load and the store into the object graph). >> >> Having both `fill_klasses` and `transform_klasses_to_local_jni_handles` made the call to `keep_alive` and the comment explaining the reason why somewhat obscured, so I merged them. (The split seems to have served no purpose except to introduce the need for a lot of const and reinterpret casts.) > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Update comment src/hotspot/share/oops/klass.inline.hpp line 42: > 40: // Resolving the holder (a WeakHandle) will keep the klass alive until the next safepoint. > 41: // Making the klass's CLD handle oops (e.g. the java_mirror), safe to store in the object > 42: // graph and it's roots (e.g. Handles). typo: its doesn't have a ' ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21893#discussion_r1829490928 From ihse at openjdk.org Tue Nov 5 14:51:47 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 5 Nov 2024 14:51:47 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Mon, 4 Nov 2024 20:42:59 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > fix: jvm_md.h was included, but not jvm.h... This has now passed internal CI testing tier1-5 (except for one test that also fails in mainline). ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2457376495 From duke at openjdk.org Tue Nov 5 14:52:28 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Tue, 5 Nov 2024 14:52:28 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding In-Reply-To: <8-DSId0L1YvlZctIylDj_p0UMXpuO-9cd-_lXSVlD1M=.21b528f7-e7ea-4d52-84e4-0af1424c9fa7@github.com> References: <8-DSId0L1YvlZctIylDj_p0UMXpuO-9cd-_lXSVlD1M=.21b528f7-e7ea-4d52-84e4-0af1424c9fa7@github.com> Message-ID: On Tue, 5 Nov 2024 14:22:06 GMT, Sonia Zaldana Calles wrote: >> - Changed several "NULL" in comments to "null" >> - Changed several `NULL` in code to `nullptr` > > Hi @theoweidmannoracle, I think the GHA tests are not running because you haven't enabled GHA on your personal fork. See https://wiki.openjdk.org/display/SKARA/Testing for a bit more info. Hi @SoniaZaldana, thanks for pointing that out. I enabled the tests now, but it seems there's no way to run them except for pushing new changes. I did run Oracle's internal testing, though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21826#issuecomment-2457377145 From jsjolen at openjdk.org Tue Nov 5 14:58:30 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 5 Nov 2024 14:58:30 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 13:35:56 GMT, theoweidmannoracle wrote: > - Changed several "NULL" in comments to "null" > - Changed several `NULL` in code to `nullptr` Thank you, these changes looks good to me. ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21826#pullrequestreview-2415877774 From duke at openjdk.org Tue Nov 5 15:05:51 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Tue, 5 Nov 2024 15:05:51 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v2] In-Reply-To: References: Message-ID: > - Changed several "NULL" in comments to "null" > - Changed several `NULL` in code to `nullptr` theoweidmannoracle 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 'openjdk:master' into JDK-8342860 - Fix copyright year - 8342860: Fix more NULL usage backsliding ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21826/files - new: https://git.openjdk.org/jdk/pull/21826/files/afb592f8..9754145b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21826&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21826&range=00-01 Stats: 123205 lines in 577 files changed: 97665 ins; 8394 del; 17146 mod Patch: https://git.openjdk.org/jdk/pull/21826.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21826/head:pull/21826 PR: https://git.openjdk.org/jdk/pull/21826 From szaldana at openjdk.org Tue Nov 5 15:05:51 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 5 Nov 2024 15:05:51 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding In-Reply-To: <8-DSId0L1YvlZctIylDj_p0UMXpuO-9cd-_lXSVlD1M=.21b528f7-e7ea-4d52-84e4-0af1424c9fa7@github.com> References: <8-DSId0L1YvlZctIylDj_p0UMXpuO-9cd-_lXSVlD1M=.21b528f7-e7ea-4d52-84e4-0af1424c9fa7@github.com> Message-ID: On Tue, 5 Nov 2024 14:22:06 GMT, Sonia Zaldana Calles wrote: >> - Changed several "NULL" in comments to "null" >> - Changed several `NULL` in code to `nullptr` > > Hi @theoweidmannoracle, I think the GHA tests are not running because you haven't enabled GHA on your personal fork. See https://wiki.openjdk.org/display/SKARA/Testing for a bit more info. > Hi @SoniaZaldana, thanks for pointing that out. I enabled the tests now, but it seems there's no way to run them except for pushing new changes. I did run Oracle's internal testing, though. You can try syncing your fork and that should trigger GHA. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21826#issuecomment-2457405542 From duke at openjdk.org Tue Nov 5 15:05:51 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Tue, 5 Nov 2024 15:05:51 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding In-Reply-To: References: <8-DSId0L1YvlZctIylDj_p0UMXpuO-9cd-_lXSVlD1M=.21b528f7-e7ea-4d52-84e4-0af1424c9fa7@github.com> Message-ID: <8_mKDBs4-BvKnB4UuU1BHeYGga7yHYe3KDP2xht6H0g=.dbbc64da-97fa-48a3-860c-73bfbdc961de@github.com> On Tue, 5 Nov 2024 15:00:37 GMT, Sonia Zaldana Calles wrote: >> Hi @theoweidmannoracle, I think the GHA tests are not running because you haven't enabled GHA on your personal fork. See https://wiki.openjdk.org/display/SKARA/Testing for a bit more info. > >> Hi @SoniaZaldana, thanks for pointing that out. I enabled the tests now, but it seems there's no way to run them except for pushing new changes. I did run Oracle's internal testing, though. > > You can try syncing your fork and that should trigger GHA. @SoniaZaldana Thanks for the tip! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21826#issuecomment-2457412470 From mgronlun at openjdk.org Tue Nov 5 15:08:29 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 5 Nov 2024 15:08:29 GMT Subject: RFR: 8340586: JdkJfrEvent::get_all_klasses stores non-strong oops in JNI handles [v2] In-Reply-To: References: Message-ID: <7EtVmpleKVBOQ5y6YwZvA4gfH3loV3E21P55-5UcZxE=.4c7e26a5-d0a2-4b81-9bc3-0e4953c95b9f@github.com> On Tue, 5 Nov 2024 13:57:04 GMT, Axel Boldt-Christmas wrote: >> JdkJfrEvent::get_all_klasses walks the class hierarchy of the Event class to find all event sub klasses. The mirrors of these classes are then stored in JNI handles and eventually transfered to an arraylist which is returned to the java caller. >> >> Because the klasses are found by walking the class hierarchy, their is no guarantee that the klass is strongly reachable, and thus that the java_mirror load is strong. So we must explicitly keep the klass alive (and not have a safepoint between the load and the store into the object graph). >> >> Having both `fill_klasses` and `transform_klasses_to_local_jni_handles` made the call to `keep_alive` and the comment explaining the reason why somewhat obscured, so I merged them. (The split seems to have served no purpose except to introduce the need for a lot of const and reinterpret casts.) > > Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision: > > Update comment Marked as reviewed by mgronlun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21893#pullrequestreview-2415907594 From kbarrett at openjdk.org Tue Nov 5 15:11:31 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 5 Nov 2024 15:11:31 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v2] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 15:05:51 GMT, theoweidmannoracle wrote: >> - Changed several "NULL" in comments to "null" >> - Changed several `NULL` in code to `nullptr` > > theoweidmannoracle 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 'openjdk:master' into JDK-8342860 > - Fix copyright year > - 8342860: Fix more NULL usage backsliding Can you use the (updated) regex in the JBS issue description to verify the only remaining "NULL"s in src/hotspot are jvmti.{xml,xsl} and globalDefinitons_{gcc,visCPP}.hpp? There are also some new NULLs in test/hotspot. ./jtreg/serviceability/jvmti/GetMethodDeclaringClass/libTestUnloadedClass.cpp ./jtreg/serviceability/jvmti/vthread/VThreadEventTest/libVThreadEventTest.cpp There are a couple more (after filtering out java and C source files) that I think shouldn't be changed. ------------- Changes requested by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21826#pullrequestreview-2415914752 From aboldtch at openjdk.org Tue Nov 5 15:20:47 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 5 Nov 2024 15:20:47 GMT Subject: RFR: 8340586: JdkJfrEvent::get_all_klasses stores non-strong oops in JNI handles [v3] In-Reply-To: References: Message-ID: > JdkJfrEvent::get_all_klasses walks the class hierarchy of the Event class to find all event sub klasses. The mirrors of these classes are then stored in JNI handles and eventually transfered to an arraylist which is returned to the java caller. > > Because the klasses are found by walking the class hierarchy, their is no guarantee that the klass is strongly reachable, and thus that the java_mirror load is strong. So we must explicitly keep the klass alive (and not have a safepoint between the load and the store into the object graph). > > Having both `fill_klasses` and `transform_klasses_to_local_jni_handles` made the call to `keep_alive` and the comment explaining the reason why somewhat obscured, so I merged them. (The split seems to have served no purpose except to introduce the need for a lot of const and reinterpret casts.) Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: - Add Klass::java_mirror() comment. - Fix comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21893/files - new: https://git.openjdk.org/jdk/pull/21893/files/f8ebdbf1..41adf48d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21893&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21893&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21893.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21893/head:pull/21893 PR: https://git.openjdk.org/jdk/pull/21893 From aboldtch at openjdk.org Tue Nov 5 15:23:29 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 5 Nov 2024 15:23:29 GMT Subject: RFR: 8340586: JdkJfrEvent::get_all_klasses stores non-strong oops in JNI handles [v3] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 13:38:20 GMT, Markus Gr?nlund wrote: > Why is not java_mirror() extended to set this keep_alive() of the CLD oop-stuff under the hood? Would like to improve our API to have the CLD oop handles accessors work more like WeakHandles w.r.t. peek and resolve. But would need to go over all the CLD oops resolves, because a few of them should be peeks. Side note: OopHandle::peek should probably be removed now that single generational ZGC is gone, as it has the same semantics as OopHandle::resolve. > Can you add a comment to Klass::java_mirror() that says it doesn't keep the loader alive, "see above". Added a comment to Klass::java_mirror() and updated the Klass::keep_alive() comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21893#discussion_r1829546341 From stuefe at openjdk.org Tue Nov 5 15:23:31 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 5 Nov 2024 15:23:31 GMT Subject: RFR: 8336874: WhiteBoxAPI: assert(!method->is_abstract() && (osr_bci == InvocationEntryBci || !method->is_native())) failed: cannot compile abstract/native methods [v3] In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 19:10:28 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8336874](https://bugs.openjdk.org/browse/JDK-8336874) ensuring enqueuing an abstract method for compilation doesn't hit an assert with WhiteBox. >> >> Testing: >> - [x] Added test case passes. >> >> Thanks, >> Sonia > > Sonia Zaldana Calles 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 'openjdk:master' into JDK-8336874 > - Adding enqueue check to be false > - 8336874: WhiteBoxAPI: assert(!method->is_abstract() && (osr_bci == InvocationEntryBci || !method->is_native())) failed: cannot compile abstract/native methods Good ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20973#pullrequestreview-2415949155 From szaldana at openjdk.org Tue Nov 5 15:27:36 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 5 Nov 2024 15:27:36 GMT Subject: RFR: 8336874: WhiteBoxAPI: assert(!method->is_abstract() && (osr_bci == InvocationEntryBci || !method->is_native())) failed: cannot compile abstract/native methods [v3] In-Reply-To: References: Message-ID: <6oZmpwOeHyGD3AokGy5PLw5xy2Lx6Qqwg1qgd2pltfI=.65503ee8-e4bb-4f95-a8f0-e249a4e964e8@github.com> On Tue, 5 Nov 2024 15:21:05 GMT, Thomas Stuefe wrote: >> Sonia Zaldana Calles 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 'openjdk:master' into JDK-8336874 >> - Adding enqueue check to be false >> - 8336874: WhiteBoxAPI: assert(!method->is_abstract() && (osr_bci == InvocationEntryBci || !method->is_native())) failed: cannot compile abstract/native methods > > Good Thanks @tstuefe @lmesnik! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20973#issuecomment-2457466209 From szaldana at openjdk.org Tue Nov 5 15:27:38 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 5 Nov 2024 15:27:38 GMT Subject: Integrated: 8336874: WhiteBoxAPI: assert(!method->is_abstract() && (osr_bci == InvocationEntryBci || !method->is_native())) failed: cannot compile abstract/native methods In-Reply-To: References: Message-ID: On Thu, 12 Sep 2024 19:47:47 GMT, Sonia Zaldana Calles wrote: > Hi all, > > This PR addresses [8336874](https://bugs.openjdk.org/browse/JDK-8336874) ensuring enqueuing an abstract method for compilation doesn't hit an assert with WhiteBox. > > Testing: > - [x] Added test case passes. > > Thanks, > Sonia This pull request has now been integrated. Changeset: 0b733e9a Author: Sonia Zaldana Calles URL: https://git.openjdk.org/jdk/commit/0b733e9a22fd786f3fd133faae3b00d31258e755 Stats: 59 lines in 2 files changed: 59 ins; 0 del; 0 mod 8336874: WhiteBoxAPI: assert(!method->is_abstract() && (osr_bci == InvocationEntryBci || !method->is_native())) failed: cannot compile abstract/native methods Reviewed-by: lmesnik, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/20973 From kvn at openjdk.org Tue Nov 5 15:50:41 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 5 Nov 2024 15:50:41 GMT Subject: RFR: 8343452: Incorrect WINDOWS build variable is used in macroAssembler_x86.cpp In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 12:21:58 GMT, theoweidmannoracle wrote: > From JBS: > >> HotSpot VM build macro defines _WINDOWS env variable only. >> call_clobbered_gp_registers() and call_clobbered_xmm_registers() incorrectly use WINDOWS (without underscore). >> RSI and RDI are missing from list of clobbered register on windows due to that and may cause issue when calling native code which modifies them. >> >> AMM register are less affected because all XMM registers are listed as clobbered. >> >> The code was added by [JDK-8283327](https://bugs.openjdk.org/browse/JDK-8283327) changes in JDK 19. Okay @theoweidmannoracle please enable GHA testing on your branch. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21901#pullrequestreview-2416025758 PR Comment: https://git.openjdk.org/jdk/pull/21901#issuecomment-2457533724 From jwaters at openjdk.org Tue Nov 5 15:52:40 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 5 Nov 2024 15:52:40 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v2] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 15:05:51 GMT, theoweidmannoracle wrote: >> - Changed several "NULL" in comments to "null" >> - Changed several `NULL` in code to `nullptr` > > theoweidmannoracle 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 'openjdk:master' into JDK-8342860 > - Fix copyright year > - 8342860: Fix more NULL usage backsliding Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21826#pullrequestreview-2416030956 From chagedorn at openjdk.org Tue Nov 5 15:57:28 2024 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Tue, 5 Nov 2024 15:57:28 GMT Subject: RFR: 8343452: Incorrect WINDOWS build variable is used in macroAssembler_x86.cpp In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 12:21:58 GMT, theoweidmannoracle wrote: > From JBS: > >> HotSpot VM build macro defines _WINDOWS env variable only. >> call_clobbered_gp_registers() and call_clobbered_xmm_registers() incorrectly use WINDOWS (without underscore). >> RSI and RDI are missing from list of clobbered register on windows due to that and may cause issue when calling native code which modifies them. >> >> AMM register are less affected because all XMM registers are listed as clobbered. >> >> The code was added by [JDK-8283327](https://bugs.openjdk.org/browse/JDK-8283327) changes in JDK 19. Looks good! ------------- Marked as reviewed by chagedorn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21901#pullrequestreview-2416046832 From jwaters at openjdk.org Tue Nov 5 16:02:34 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 5 Nov 2024 16:02:34 GMT Subject: RFR: 8343452: Incorrect WINDOWS build variable is used in macroAssembler_x86.cpp In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 12:21:58 GMT, theoweidmannoracle wrote: > From JBS: > >> HotSpot VM build macro defines _WINDOWS env variable only. >> call_clobbered_gp_registers() and call_clobbered_xmm_registers() incorrectly use WINDOWS (without underscore). >> RSI and RDI are missing from list of clobbered register on windows due to that and may cause issue when calling native code which modifies them. >> >> AMM register are less affected because all XMM registers are listed as clobbered. >> >> The code was added by [JDK-8283327](https://bugs.openjdk.org/browse/JDK-8283327) changes in JDK 19. Nice! ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/21901#pullrequestreview-2416060128 From kbarrett at openjdk.org Tue Nov 5 16:04:34 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 5 Nov 2024 16:04:34 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v2] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 15:05:51 GMT, theoweidmannoracle wrote: >> - Changed several "NULL" in comments to "null" >> - Changed several `NULL` in code to `nullptr` > > theoweidmannoracle 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 'openjdk:master' into JDK-8342860 > - Fix copyright year > - 8342860: Fix more NULL usage backsliding Can you use the (updated) regex in the JBS issue description to verify the only remaining "NULL"s in src/hotspot are the jvmti.{xml,xls} files and the globalDefinitions_{gcc,visCPP}.hpp files? There are also some NULLs recently introduced in test/hotspot: ./jtreg/serviceability/jvmti/GetMethodDeclaringClass/libTestUnloadedClass.cpp ./jtreg/serviceability/jvmti/vthread/VThreadEventTest/libVThreadEventTest.cpp (Found by applying the same regex to test/hotspot, and then removing .java and .c files.) There are a few other files in test/hotspot containing NULLs: ./jtreg/vmTestbase/nsk/share/jni/README ./jtreg/vmTestbase/nsk/share/jvmti/README These are documentation files with examples written in C, so should not be changed. ./jtreg/vmTestbase/nsk/share/native/nsk_tools.hpp In a comment describing a string to be used for printing. Uses would need to be examined to ensure it's okay to change the string used for a null value. I think I planned to do this as a followup to JDK-8324799, and then forgot. I'd be okay with doing something about this being separate from the current PR. While the necessary textual changes are probably small, there's a lot of uses to examine to be sure a change is okay. ------------- Changes requested by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21826#pullrequestreview-2416066994 From kbarrett at openjdk.org Tue Nov 5 16:15:30 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 5 Nov 2024 16:15:30 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding In-Reply-To: References: <8-DSId0L1YvlZctIylDj_p0UMXpuO-9cd-_lXSVlD1M=.21b528f7-e7ea-4d52-84e4-0af1424c9fa7@github.com> Message-ID: On Tue, 5 Nov 2024 15:00:37 GMT, Sonia Zaldana Calles wrote: > Hi @SoniaZaldana, thanks for pointing that out. I enabled the tests now, but it seems there's no way to run them except for pushing new changes. I did run Oracle's internal testing, though. To manually trigger GHA tests: 1. Go to your personal fork, and click on the "Actions" menu item. 2. Select the "OpenJDK GHA Sanity Checks" Action. 3. Click on the "Run workflow" pulldown. 4. Select the branch you want to test in the "Use workflow from" pulldown. 5. Click on "Run workflow". ------------- PR Comment: https://git.openjdk.org/jdk/pull/21826#issuecomment-2457602766 From stefank at openjdk.org Tue Nov 5 16:29:29 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 5 Nov 2024 16:29:29 GMT Subject: RFR: 8340586: JdkJfrEvent::get_all_klasses stores non-strong oops in JNI handles [v3] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 15:20:47 GMT, Axel Boldt-Christmas wrote: >> JdkJfrEvent::get_all_klasses walks the class hierarchy of the Event class to find all event sub klasses. The mirrors of these classes are then stored in JNI handles and eventually transfered to an arraylist which is returned to the java caller. >> >> Because the klasses are found by walking the class hierarchy, their is no guarantee that the klass is strongly reachable, and thus that the java_mirror load is strong. So we must explicitly keep the klass alive (and not have a safepoint between the load and the store into the object graph). >> >> Having both `fill_klasses` and `transform_klasses_to_local_jni_handles` made the call to `keep_alive` and the comment explaining the reason why somewhat obscured, so I merged them. (The split seems to have served no purpose except to introduce the need for a lot of const and reinterpret casts.) > > Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: > > - Add Klass::java_mirror() comment. > - Fix comment Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21893#pullrequestreview-2416132287 From stuefe at openjdk.org Tue Nov 5 16:40:54 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 5 Nov 2024 16:40:54 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v53] In-Reply-To: References: Message-ID: <5EgL-mJp75JLOxEccrrGVxbfS6QdUywRSfsOcgx4zl8=.3c283bf3-3e2e-4fe2-bce5-c30d7d4e2da4@github.com> On Thu, 24 Oct 2024 21:04:51 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Enable riscv in CompressedClassPointersEncodingScheme test Went again through all the changes, with focus on runtime code. Still good. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2416155892 From asmehra at openjdk.org Tue Nov 5 16:44:42 2024 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 5 Nov 2024 16:44:42 GMT Subject: RFR: 8300732: Whitebox functions for Metaspace test should use byte size [v4] In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 19:21:30 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8300732](https://bugs.openjdk.org/browse/JDK-8300732) switching Whitebox Metaspace test functions to use bytes as opposed to words. >> >> Testing: >> - [x] `test/hotspot/jtreg/runtime/Metaspace` tests pass. >> >> Thanks, >> Sonia > > Sonia Zaldana Calles has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' of github.com:openjdk/jdk into JDK-8300732 > - Feedback - updating Unit.valueOf to direct access > - Hard coding values and adding Unit class > - whitebox changes based on feedback. Using is_aligned and asserts > - 8300732: Whitebox functions for Metaspace test should use byte size Marked as reviewed by asmehra (Committer). A couple of minor things, otherwise looks good. src/hotspot/share/prims/whitebox.cpp line 1788: > 1786: > 1787: WB_ENTRY(jlong, WB_RootChunkWordSize(JNIEnv* env)) > 1788: return (jlong)Metaspace::reserve_alignment_words(); indentation required test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocationMT1.java line 109: > 107: > 108: // Note: reserve limit must be a multiple of Metaspace::reserve_alignment_words() > 109: // (512K on 64bit, 1M on 32bit) Are these figures still valid? IIUC Metaspace::reserve_alignment_words() is 16M on 32-bit and 64M on 64-bit. ------------- PR Review: https://git.openjdk.org/jdk/pull/20039#pullrequestreview-2416168758 PR Comment: https://git.openjdk.org/jdk/pull/20039#issuecomment-2457670809 PR Review Comment: https://git.openjdk.org/jdk/pull/20039#discussion_r1829679980 PR Review Comment: https://git.openjdk.org/jdk/pull/20039#discussion_r1829679868 From rkennke at openjdk.org Tue Nov 5 16:49:01 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 5 Nov 2024 16:49:01 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v50] In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 16:22:20 GMT, Roman Kennke wrote: >> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update copyright >> - Avoid assert/endless-loop in JFR code > > @egahlin / @mgronlun could you please review the JFR parts of this PR? One change is for getting the right prototype header, the other is for avoiding an endless loop/assert in a corner case. > @rkennke can you include this small update for s390x as well: > > ```diff > diff --git a/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp b/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp > index 0f7e5c9f457..476e3d5daa4 100644 > --- a/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp > +++ b/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp > @@ -174,8 +174,11 @@ void C1_MacroAssembler::try_allocate( > void C1_MacroAssembler::initialize_header(Register obj, Register klass, Register len, Register Rzero, Register t1) { > assert_different_registers(obj, klass, len, t1, Rzero); > if (UseCompactObjectHeaders) { > - z_lg(t1, Address(klass, in_bytes(Klass::prototype_header_offset()))); > - z_stg(t1, Address(obj, oopDesc::mark_offset_in_bytes())); > + z_mvc( > + Address(obj, oopDesc::mark_offset_in_bytes()), /* move to */ > + Address(klass, in_bytes(Klass::prototype_header_offset())), /* move from */ > + sizeof(markWord) /* how much to move */ > + ); > } else { > load_const_optimized(t1, (intx)markWord::prototype().value()); > z_stg(t1, Address(obj, oopDesc::mark_offset_in_bytes())); > diff --git a/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp b/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp > index 378d5e4cfe1..c5713161bf9 100644 > --- a/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp > +++ b/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp > @@ -46,7 +46,7 @@ void C2_MacroAssembler::load_narrow_klass_compact_c2(Register dst, Address src) > // The incoming address is pointing into obj-start + klass_offset_in_bytes. We need to extract > // obj-start, so that we can load from the object's mark-word instead. > z_lg(dst, src.plus_disp(-oopDesc::klass_offset_in_bytes())); > - z_srlg(dst, dst, markWord::klass_shift); // TODO: could be z_sra > + z_srlg(dst, dst, markWord::klass_shift); > } > > //------------------------------------------------------ > diff --git a/src/hotspot/cpu/s390/templateTable_s390.cpp b/src/hotspot/cpu/s390/templateTable_s390.cpp > index 3cb1aba810d..5b8f7a20478 100644 > --- a/src/hotspot/cpu/s390/templateTable_s390.cpp > +++ b/src/hotspot/cpu/s390/templateTable_s390.cpp > @@ -3980,8 +3980,11 @@ void TemplateTable::_new() { > // Initialize object header only. > __ bind(initialize_header); > if (UseCompactObjectHeaders) { > - __ z_lg(tmp, Address(iklass, in_bytes(Klass::prototype_header_offset()))); > - __ z_stg(tmp, Address(RallocatedObject, oopDesc::mark_offset_in_bytes())); > + __ z_mvc( > + Address(RallocatedObject, oopDesc::mark_offset_in_bytes()), // move to > + Address(iklass, in_bytes(Klass::prototype_header_offset())), // move from > + sizeof(markWord) // how much to move > + ); > } else { > __ store_const(Address(RallocatedObject, oopDesc::mark_offset_in_bytes()), > (long) markWord::prototype().value()); > ``` Hi Amit, sorry I only now get to reply to this, I have been traveling. What does the change do? Is it critical? Would it be possible to fix it after I intergrated the JEP? Because any change that I do now invalidates existing reviews, and might delay integration, and we're already running pretty close to RDP1. If at all possible, I would prefer to take it after I intergrated the JEP - we can have fixes well after RDP1, but not new features. If you agree, then please file a follow-up issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2457674486 From amitkumar at openjdk.org Tue Nov 5 16:49:01 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 5 Nov 2024 16:49:01 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v50] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 16:43:35 GMT, Roman Kennke wrote: >Hi Amit, sorry I only now get to reply to this, I have been traveling. What does the change do? Is it critical? Would it be possible to fix it after I intergrated the JEP? Because any change that I do now invalidates existing reviews, and might delay integration, and we're already running pretty close to RDP1. If at all possible, I would prefer to take it after I intergrated the JEP - we can have fixes well after RDP1, but not new features. If you agree, then please file a follow-up issue. That's perfectly fine. I will do it with separate RFE :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2457680086 From stuefe at openjdk.org Tue Nov 5 16:56:33 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 5 Nov 2024 16:56:33 GMT Subject: RFR: 8300732: Whitebox functions for Metaspace test should use byte size [v4] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 16:41:23 GMT, Ashutosh Mehra wrote: >> Sonia Zaldana Calles has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - Merge branch 'master' of github.com:openjdk/jdk into JDK-8300732 >> - Feedback - updating Unit.valueOf to direct access >> - Hard coding values and adding Unit class >> - whitebox changes based on feedback. Using is_aligned and asserts >> - 8300732: Whitebox functions for Metaspace test should use byte size > > test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocationMT1.java line 109: > >> 107: >> 108: // Note: reserve limit must be a multiple of Metaspace::reserve_alignment_words() >> 109: // (512K on 64bit, 1M on 32bit) > > Are these figures still valid? > IIUC Metaspace::reserve_alignment_words() is 16M on 32-bit and 64M on 64-bit. No, it should be 16MB for both 32- and 64-bit (one metaspace root chunk size). The virtual space node default size is 16/64MB, but it needs not to be aligned at that. But the comment is still obsolete. It cites the number of words needed for the old root chunk size of 4MB. So its obsolete on two accounts. I think it should just say "(16 MB)" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20039#discussion_r1829698239 From kbarrett at openjdk.org Tue Nov 5 17:11:53 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 5 Nov 2024 17:11:53 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Mon, 4 Nov 2024 20:42:59 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > fix: jvm_md.h was included, but not jvm.h... I kind of wish the __cdecl / __stdcall changes had been done separately. Oh well. src/hotspot/os/windows/os_windows.cpp line 5820: > 5818: } > 5819: > 5820: // FIXME ??? src/hotspot/os/windows/os_windows.cpp line 5863: > 5861: return nullptr; > 5862: } > 5863: [pre-existing, and can't comment on line 5858 because it's not sufficiently near a change.] The calculation of `len` is wasting a byte when `lib_name` is null. The `+2` accounts for the terminating `NUL` and the underscore separator between the sym_name part and the lib_name part. That underscore isn't added when there isn't a lib_name part. I think the simplest fix would be to change `name_len` to `(name_len +1)` and `+2` to `+1` in that calculation. And add some commentary. This might be deemed not worth fixing as there is likely often no actual wastage, due to alignment padding, and it slightly further complicates the calculation. But additional commentary would still be desirable, to guide the next careful reader. In which case it might be simpler to describe the fixed version. Since this is pre-existing and relatively harmless in execution, it can be addressed in a followup change. src/hotspot/share/include/jvm.h line 1165: > 1163: #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} > 1164: #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} > 1165: #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} There is more cleanup that can be done here. These definitions are used as array initializers (hence the surrounding curly braces). They are now always singleton, rather than sometimes having 2 elements. The uses iterate over the now always singleton arrays. Those iterations are no longer needed and could be eliminated. And these macros could be eliminated, using the corresponding string directly in each use. This can all be done as a followup change. src/java.base/share/native/libjava/NativeLibraries.c line 67: > 65: strcat(jniEntryName, "_"); > 66: strcat(jniEntryName, cname); > 67: } I would prefer this be directly inlined at the sole call (in findJniFunction), to make it easier to verify there aren't any buffer overrun problems. (I don't think there are, but looking at this in isolation triggered warnings in my head.) Also, it looks like all callers of findJniFunction ensure the cname argument is non-null. So there should be no need to handle the null case in findJniFunction (other than perhaps an assert or something). That could be addressed in a followup. (I've already implicitly suggested elsewhere in this PR revising this function in a followup because of the JNI_ON[UN]LOAD_SYMBOLS thing.) ------------- Changes requested by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2415002837 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1829659373 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1828969105 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1829478432 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1829684759 From szaldana at openjdk.org Tue Nov 5 18:07:19 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 5 Nov 2024 18:07:19 GMT Subject: RFR: 8300732: Whitebox functions for Metaspace test should use byte size [v5] In-Reply-To: References: Message-ID: > Hi all, > > This PR addresses [8300732](https://bugs.openjdk.org/browse/JDK-8300732) switching Whitebox Metaspace test functions to use bytes as opposed to words. > > Testing: > - [x] `test/hotspot/jtreg/runtime/Metaspace` tests pass. > > Thanks, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: Fixing indentation and comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20039/files - new: https://git.openjdk.org/jdk/pull/20039/files/8397a1c5..b27571f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20039&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20039&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20039.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20039/head:pull/20039 PR: https://git.openjdk.org/jdk/pull/20039 From kvn at openjdk.org Tue Nov 5 18:28:33 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 5 Nov 2024 18:28:33 GMT Subject: RFR: 8343173: Remove ZGC-specific non-JVMCI test groups [v2] In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 16:13:53 GMT, Leonid Mesnik wrote: >> The JVMCI should be supported by all GCs and specific >> hotspot_compiler_all_gcs >> group is not needed anymore. >> >> There are few failures of JVMCI tests with ZGC happened, the bug >> https://bugs.openjdk.org/browse/JDK-8343233 >> is filed and corresponding tests are problemlisted. > > Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - typo fixed > - Merge branch 'master' of https://github.com/openjdk/jdk into 8343173 > - 8343173: Remove ZGC-specific non-JVMCI test groups Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21774#pullrequestreview-2416399409 From mullan at openjdk.org Tue Nov 5 18:30:37 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 5 Nov 2024 18:30:37 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v7] In-Reply-To: References: Message-ID: > This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. > > NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. > > The code changes can be broken down into roughly the following categories: > > 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. > 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. > 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. > 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). > 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. > > There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. > > Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). > > I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f... Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 213 commits: - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 - Remove "access" and "policy" options from debug help. - Merge branch 'master' into jep486 - Merge branch 'jep486' of https://github.com/openjdk/jdk-sandbox into jep486 - remove MainClassCantBeLoadedTest from problemlisting - remove LauncherErrors test from problemlisting - Merge branch 'master' into jep486 - Remove left-over paragraph about SM use from LoggerFinder - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - ... and 203 more: https://git.openjdk.org/jdk/compare/f69b6016...51d2a2a3 ------------- Changes: https://git.openjdk.org/jdk/pull/21498/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=06 Stats: 68938 lines in 1889 files changed: 2490 ins; 62600 del; 3848 mod Patch: https://git.openjdk.org/jdk/pull/21498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498 PR: https://git.openjdk.org/jdk/pull/21498 From duke at openjdk.org Tue Nov 5 18:56:13 2024 From: duke at openjdk.org (hanklo6) Date: Tue, 5 Nov 2024 18:56:13 GMT Subject: RFR: 8343317: Extend test generation tool to handle APX NDD/NF flavor of instructions [v2] In-Reply-To: References: Message-ID: > Extend test generation tool and gtest (added as part of https://bugs.openjdk.org/browse/JDK-8339507) to handle Intel APX NDD/NF instructions. > > Intel Advanced Performance Extensions (APX) adds non destructive destination (NDD) and no flags (NF) flavor for the scalar instructions through EVEX encoding. For more information about APX, see https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html. hanklo6 has updated the pull request incrementally with two additional commits since the last revision: - Use load form - Add seed for random ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21795/files - new: https://git.openjdk.org/jdk/pull/21795/files/083ad66e..feebe493 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21795&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21795&range=00-01 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21795.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21795/head:pull/21795 PR: https://git.openjdk.org/jdk/pull/21795 From mullan at openjdk.org Tue Nov 5 18:58:22 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 5 Nov 2024 18:58:22 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v8] In-Reply-To: References: Message-ID: <6Ys0lsn0cw84Hsu-SaEsMIeno_mE2fwcB-Er45r3S2Y=.9d2da633-3647-4539-93ef-d5c1d186e804@github.com> > This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. > > NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. > > The code changes can be broken down into roughly the following categories: > > 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. > 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. > 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. > 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). > 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. > > There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. > > Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). > > I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f... Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 217 commits: - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 - Remove "access" and "policy" options from debug help. - Merge branch 'master' into jep486 - Merge branch 'jep486' of https://github.com/openjdk/jdk-sandbox into jep486 - remove MainClassCantBeLoadedTest from problemlisting - remove LauncherErrors test from problemlisting - ... and 207 more: https://git.openjdk.org/jdk/compare/3fab8e37...e9e7f0c9 ------------- Changes: https://git.openjdk.org/jdk/pull/21498/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=07 Stats: 68934 lines in 1889 files changed: 2490 ins; 62600 del; 3844 mod Patch: https://git.openjdk.org/jdk/pull/21498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498 PR: https://git.openjdk.org/jdk/pull/21498 From duke at openjdk.org Tue Nov 5 18:58:52 2024 From: duke at openjdk.org (hanklo6) Date: Tue, 5 Nov 2024 18:58:52 GMT Subject: RFR: 8343317: Extend test generation tool to handle APX NDD/NF flavor of instructions [v3] In-Reply-To: References: Message-ID: > Extend test generation tool and gtest (added as part of https://bugs.openjdk.org/browse/JDK-8339507) to handle Intel APX NDD/NF instructions. > > Intel Advanced Performance Extensions (APX) adds non destructive destination (NDD) and no flags (NF) flavor for the scalar instructions through EVEX encoding. For more information about APX, see https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html. hanklo6 has updated the pull request incrementally with one additional commit since the last revision: Regenerate asmtest.out.h ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21795/files - new: https://git.openjdk.org/jdk/pull/21795/files/feebe493..14e4bacb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21795&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21795&range=01-02 Stats: 2646 lines in 1 file changed: 423 ins; 463 del; 1760 mod Patch: https://git.openjdk.org/jdk/pull/21795.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21795/head:pull/21795 PR: https://git.openjdk.org/jdk/pull/21795 From mullan at openjdk.org Tue Nov 5 19:24:12 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 5 Nov 2024 19:24:12 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6] In-Reply-To: References: <0j1uUkVMlrLOxFPmXYzvHcDe9I3a34Fbfjh4hBK2BL0=.13667c44-1516-4784-823e-7216e886512c@github.com> Message-ID: On Sun, 3 Nov 2024 12:33:05 GMT, Alan Bateman wrote: >> Right - this paragraph - lines 1620-1625 (old file) / 1362-1367 (new file) is no longer relevant and should be removed too. Thanks for spotting that. > > Removed in jep486 branch in sandbox so will get picked up when PR is refreshed. Fixed in https://github.com/openjdk/jdk/pull/21498/commits/ab586f6619ca5f7e213876219abf61a36155735c ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1829886748 From rkennke at openjdk.org Tue Nov 5 20:00:31 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 5 Nov 2024 20:00:31 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v54] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 104 commits: - Merge tag 'jdk-24+22' into JDK-8305895-v4 Added tag jdk-24+22 for changeset 388d44fb - Enable riscv in CompressedClassPointersEncodingScheme test - s390 port - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test - Update copyright - Avoid assert/endless-loop in JFR code - Update copyright headers - Merge tag 'jdk-24+20' into JDK-8305895-v4 Added tag jdk-24+20 for changeset 7a64fbbb - Fix needle copying in indexOf intrinsic for smaller headers - Compact header riscv (#3) Implement compact headers on RISCV --------- Co-authored-by: hamlin - ... and 94 more: https://git.openjdk.org/jdk/compare/388d44fb...b945822a ------------- Changes: https://git.openjdk.org/jdk/pull/20677/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=53 Stats: 5214 lines in 218 files changed: 3587 ins; 864 del; 763 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From mullan at openjdk.org Tue Nov 5 20:10:20 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 5 Nov 2024 20:10:20 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v8] In-Reply-To: <6Ys0lsn0cw84Hsu-SaEsMIeno_mE2fwcB-Er45r3S2Y=.9d2da633-3647-4539-93ef-d5c1d186e804@github.com> References: <6Ys0lsn0cw84Hsu-SaEsMIeno_mE2fwcB-Er45r3S2Y=.9d2da633-3647-4539-93ef-d5c1d186e804@github.com> Message-ID: On Tue, 5 Nov 2024 18:58:22 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 217 commits: > > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Remove "access" and "policy" options from debug help. > - Merge branch 'master' into jep486 > - Merge branch 'jep486' of https://github.com/openjdk/jdk-sandbox into jep486 > - remove MainClassCantBeLoadedTest from problemlisting > - remove LauncherErrors test from problemlisting > - ... and 207 more: https://git.openjdk.org/jdk/compare/3fab8e37...e9e7f0c9 The latest update includes: - merging with the mainline sources - a couple of test removals from the ProblemList for tests that no longer apply - removal of the "policy" and "access" options from the `-Djava.security.debug` help option. - a small update to remove some SM specific text from the `System.LoggerFinder` class description. - copyright header updates for several tests that were previously modified - addition of a few client manual tests to the ProblemList that have dependencies on the Security Manager and will be resolved later ------------- PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2458058335 From lmesnik at openjdk.org Tue Nov 5 20:55:35 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 5 Nov 2024 20:55:35 GMT Subject: Integrated: 8343173: Remove ZGC-specific non-JVMCI test groups In-Reply-To: References: Message-ID: <-1bZpI933zmujmTibsiiOkDdxnlxnKEGVGAPlqfvYik=.a0981eca-c8da-466c-a209-b266afea8513@github.com> On Tue, 29 Oct 2024 22:01:08 GMT, Leonid Mesnik wrote: > The JVMCI should be supported by all GCs and specific > hotspot_compiler_all_gcs > group is not needed anymore. > > There are few failures of JVMCI tests with ZGC happened, the bug > https://bugs.openjdk.org/browse/JDK-8343233 > is filed and corresponding tests are problemlisted. This pull request has now been integrated. Changeset: 847cc5eb Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/847cc5ebac43b83746d8f238c5f9ecf2972a2796 Stats: 12 lines in 2 files changed: 8 ins; 4 del; 0 mod 8343173: Remove ZGC-specific non-JVMCI test groups Reviewed-by: kvn ------------- PR: https://git.openjdk.org/jdk/pull/21774 From amenkov at openjdk.org Tue Nov 5 22:41:36 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 5 Nov 2024 22:41:36 GMT Subject: Integrated: 8342577: Clean up JVMTI breakpoint support In-Reply-To: References: Message-ID: On Thu, 24 Oct 2024 01:42:36 GMT, Alex Menkov wrote: > The fix cleans up code to support list of JVMTI breakpoints. > - classes required to supports cache of byte code pointers (GrowableElement, GrowableCache, JvmtiBreakpointCache) are dropped; > - class JvmtiCurrentBreakpoints (JvmtiBreakpoints factory) is left as is, dropped unused code; > - fixed race in JvmtiCurrentBreakpoints::get_jvmti_breakpoints() (fix for JDK-8210637); > - JvmtiBreakpoint:JvmtiBreakpoint() + JvmtiBreakpoint::copy(JvmtiBreakpoint& bp) are replaced with copy ctor; > - JvmtiBreakpoints::clearall_in_class_at_safepoint() is simplified to do a single pass; > > Testing: tier1..tier6 This pull request has now been integrated. Changeset: 471f112b Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/471f112bca715d04304cbe35c6ed63df8c7b7fee Stats: 352 lines in 2 files changed: 27 ins; 284 del; 41 mod 8342577: Clean up JVMTI breakpoint support 8210637: Race in JvmtiCurrentBreakpoints::get_jvmti_breakpoints Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/21675 From coleenp at openjdk.org Tue Nov 5 23:06:33 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 5 Nov 2024 23:06:33 GMT Subject: RFR: 8340586: JdkJfrEvent::get_all_klasses stores non-strong oops in JNI handles [v3] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 15:20:47 GMT, Axel Boldt-Christmas wrote: >> JdkJfrEvent::get_all_klasses walks the class hierarchy of the Event class to find all event sub klasses. The mirrors of these classes are then stored in JNI handles and eventually transfered to an arraylist which is returned to the java caller. >> >> Because the klasses are found by walking the class hierarchy, their is no guarantee that the klass is strongly reachable, and thus that the java_mirror load is strong. So we must explicitly keep the klass alive (and not have a safepoint between the load and the store into the object graph). >> >> Having both `fill_klasses` and `transform_klasses_to_local_jni_handles` made the call to `keep_alive` and the comment explaining the reason why somewhat obscured, so I merged them. (The split seems to have served no purpose except to introduce the need for a lot of const and reinterpret casts.) > > Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: > > - Add Klass::java_mirror() comment. > - Fix comment Looks good, thank you for fixing this. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21893#pullrequestreview-2416938458 From coleenp at openjdk.org Tue Nov 5 23:06:34 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 5 Nov 2024 23:06:34 GMT Subject: RFR: 8340586: JdkJfrEvent::get_all_klasses stores non-strong oops in JNI handles [v3] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 15:21:04 GMT, Axel Boldt-Christmas wrote: >> Why is not java_mirror() extended to set this keep_alive() of the CLD oop-stuff under the hood? > >> Why is not java_mirror() extended to set this keep_alive() of the CLD oop-stuff under the hood? > > Would like to improve our API to have the CLD oop handles accessors work more like WeakHandles w.r.t. peek and resolve. But would need to go over all the CLD oops resolves, because a few of them should be peeks. > > Side note: OopHandle::peek should probably be removed now that single generational ZGC is gone, as it has the same semantics as OopHandle::resolve. > >> Can you add a comment to Klass::java_mirror() that says it doesn't keep the loader alive, "see above". > > Added a comment to Klass::java_mirror() and updated the Klass::keep_alive() comment. Yes, I think we're going to need to relearn how to access oops. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21893#discussion_r1830172226 From pchilanomate at openjdk.org Tue Nov 5 23:55:53 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 23:55:53 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v29] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 20:55:07 GMT, Serguei Spitsyn wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision: >> >> - Update comment block in objectMonitor.cpp >> - Fix issue with unmounted virtual thread when dumping heap >> - Remove ThawBase::possibly_adjust_frame() > > src/hotspot/share/runtime/continuation.cpp line 134: > >> 132: return true; >> 133: } >> 134: #endif // INCLUDE_JVMTI > > Could you, please, consider the simplification below? > > > #if INCLUDE_JVMTI > // return true if started vthread unmount > bool jvmti_unmount_begin(JavaThread* target) { > assert(!target->is_in_any_VTMS_transition(), "must be"); > > // Don't preempt if there is a pending popframe or earlyret operation. This can > // be installed in start_VTMS_transition() so we need to check it here. > if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) { > JvmtiThreadState* state = target->jvmti_thread_state(); > if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) { > return false; > } > } > // Don't preempt in case there is an async exception installed since > // we would incorrectly throw it during the unmount logic in the carrier. > if (target->has_async_exception_condition()) { > return false; > } > if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) { > JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true); > } else { > target->set_is_in_VTMS_transition(true); > // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true) > } > return false; > } > > static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) { > if (target->is_in_VTMS_transition()) { > // We caught target at the end of a mount transition. > return false; > } > return true; > } > #endif // INCLUDE_JVMTI > ... > static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) { > assert(java_lang_VirtualThread::is_instance(vthread), ""); > if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) { // inside transition > return false; > } > return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true); > } > ... > int Continuation::try_preempt(JavaThread* target, oop continuation) { > verify_preempt_preconditions(target, continuation); > > if (LockingMode == LM_LEGACY) { > return freeze_unsupported; > } > if (!is_safe_vthread_to_preempt(target, target->vthread())) { > return freeze_pinned_native; > } > JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;) > int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp()); > log_trace(continuations, preempt)("try_preempt: %d", res); > return res; > } > > > The following won't be needed: > > target->set_pending_jvmti_unmou... Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514 We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior. Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830220838 From pchilanomate at openjdk.org Tue Nov 5 23:55:53 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 23:55:53 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v29] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 23:50:29 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/continuation.cpp line 134: >> >>> 132: return true; >>> 133: } >>> 134: #endif // INCLUDE_JVMTI >> >> Could you, please, consider the simplification below? >> >> >> #if INCLUDE_JVMTI >> // return true if started vthread unmount >> bool jvmti_unmount_begin(JavaThread* target) { >> assert(!target->is_in_any_VTMS_transition(), "must be"); >> >> // Don't preempt if there is a pending popframe or earlyret operation. This can >> // be installed in start_VTMS_transition() so we need to check it here. >> if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) { >> JvmtiThreadState* state = target->jvmti_thread_state(); >> if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) { >> return false; >> } >> } >> // Don't preempt in case there is an async exception installed since >> // we would incorrectly throw it during the unmount logic in the carrier. >> if (target->has_async_exception_condition()) { >> return false; >> } >> if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) { >> JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true); >> } else { >> target->set_is_in_VTMS_transition(true); >> // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true) >> } >> return false; >> } >> >> static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) { >> if (target->is_in_VTMS_transition()) { >> // We caught target at the end of a mount transition. >> return false; >> } >> return true; >> } >> #endif // INCLUDE_JVMTI >> ... >> static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) { >> assert(java_lang_VirtualThread::is_instance(vthread), ""); >> if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) { // inside transition >> return false; >> } >> return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true); >> } >> ... >> int Continuation::try_preempt(JavaThread* target, oop continuation) { >> verify_preempt_preconditions(target, continuation); >> >> if (LockingMode == LM_LEGACY) { >> return freeze_unsupported; >> } >> if (!is_safe_vthread_to_preempt(target, target->vthread())) { >> return freeze_pinned_native; >> } >> JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;) >> int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp()); >> log_trace(con... > > Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514 > We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior. > Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events. Regarding the pop_frame/early_ret/async_exception conditions, not checking for them after we started the transition would be an issue. For pop_frame/early_ret checks, the problem is that if any of them are installed in `JvmtiUnmountBeginMark()` while trying to start the transition, and later the call to freeze succeeds, when returning to the interpreter (monitorenter case) we will incorrectly follow the JVMTI code [1], instead of going back to `call_VM_preemptable` to clear the stack from the copied frames. As for the asynchronous exception check, if it gets installed in `JvmtiUnmountBeginMark()` while trying to start the transition, the exception would be thrown in the carrier instead, very likely while executing the unmounting logic. When unmounting from Java, although the race is also there when starting the VTMS transition as you mentioned, I think the end result will be different. For pop_frame/early_ret we will just bail out if trying to install them since the top frame will be a native method (`notifyJvmtiUnmount`). For the async exception, we would process it on return from `notifyJvmtiUnmount` which would still be done in the context of the vthread. [1] https://github.com/openjdk/jdk/blob/471f112bca715d04304cbe35c6ed63df8c7b7fee/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1629 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830222411 From pchilanomate at openjdk.org Wed Nov 6 00:08:16 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 00:08:16 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v32] In-Reply-To: References: Message-ID: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Use ThreadIdentifier::initial() in ObjectMonitor::owner_from() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21565/files - new: https://git.openjdk.org/jdk/pull/21565/files/124efa0a..c0c7e6cf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=30-31 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From pchilanomate at openjdk.org Wed Nov 6 00:08:16 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 00:08:16 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 11:35:29 GMT, Serguei Spitsyn wrote: > Is this posted after the VirtualThreadMount extension event posted? > It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830225909 From pchilanomate at openjdk.org Wed Nov 6 00:08:16 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 00:08:16 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 23:58:39 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 1643: >> >>> 1641: // actual callee (see nmethod::preserve_callee_argument_oops()). >>> 1642: ThreadOnMonitorWaitedEvent tmwe(current); >>> 1643: JvmtiExport::vthread_post_monitor_waited(current, node->_monitor, timed_out); >> >> We post a JVMTI `MonitorWaited` event here for a virtual thread. >> A couple of questions on this: >> - Q1: Is this posted after the `VirtualThreadMount` extension event posted? >> Unfortunately, it is not easy to make this conclusion. >> - Q2: The `JvmtiExport::post_monitor_waited()` is called at the line 1801. >> Does it post the `MonitorWaited` event for this virtual thread as well? >> If not, then it is not clear how posting for virtual thread is avoided. > >> Is this posted after the VirtualThreadMount extension event posted? >> > It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620 > The JvmtiExport::post_monitor_waited() is called at the line 1801. > Does it post the MonitorWaited event for this virtual thread as well? > That's the path a virtual thread will take if pinned. This case is when we were able to unmount the vthread. It is the equivalent, where the vthread finished the wait part (notified, interrupted or timed-out case) and it's going to retry acquiring the monitor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830227475 From pchilanomate at openjdk.org Wed Nov 6 00:08:17 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 00:08:17 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 14:35:11 GMT, Axel Boldt-Christmas wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision: >> >> - Add oopDesc::has_klass_gap() check >> - Rename waitTimeout/set_waitTimeout accessors >> - Revert suggestion to ThawBase::new_stack_frame >> - Improve JFR pinned reason in event >> - Use freeze_result consistently > > src/hotspot/share/runtime/objectMonitor.inline.hpp line 50: > >> 48: inline int64_t ObjectMonitor::owner_from(oop vthread) { >> 49: int64_t tid = java_lang_Thread::thread_id(vthread); >> 50: assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable"); > > Suggestion: > > assert(tid >= ThreadIdentifier::initial() && tid < ThreadIdentifier::current(), "must be reasonable"); Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830229529 From dholmes at openjdk.org Wed Nov 6 01:00:45 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 01:00:45 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Mon, 4 Nov 2024 20:42:59 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > fix: jvm_md.h was included, but not jvm.h... I think you may be throwing the baby out with the bath water when it comes to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see anything that states `__stdcall` is ONLY for 32-bit! src/hotspot/os/windows/os_windows.cpp line 510: > 508: // Thread start routine for all newly created threads. > 509: // Called with the associated Thread* as the argument. > 510: static unsigned thread_native_entry(void* t) { Whoa! Hold on there. The `_stdcall` is required here and nothing to do with 32-bit. We use `begindthreadex` to start threads and the entry function is required to be `_stdcall`. https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170 ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2417056020 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1830259353 From amenkov at openjdk.org Wed Nov 6 01:47:45 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 6 Nov 2024 01:47:45 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 6 Nov 2024 00:58:10 GMT, David Holmes wrote: > I think you may be throwing the baby out with the bath water when it comes to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see anything that states `__stdcall` is ONLY for 32-bit! https://learn.microsoft.com/en-us/cpp/cpp/stdcall?view=msvc-170 `On ARM and x64 processors, __stdcall is accepted and ignored by the compiler; on ARM and x64 architectures, by convention, arguments are passed in registers when possible, and subsequent arguments are passed on the stack.` ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2458534929 From fyang at openjdk.org Wed Nov 6 03:18:06 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 6 Nov 2024 03:18:06 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v5] In-Reply-To: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> Message-ID: > Hi, please consider this cleanup change. > > The old trampoline call on linux-riscv64 is disabled by default after: https://bugs.openjdk.org/browse/JDK-8332689. > And the new solution (load target address from stub and call) has been baked in jdk master for quite some time. > This propose to remove the old trampoline call related logic so that the code will be cleaner and easier to maintain. > As we are still using `trampoline_stub_Relocation` for the stub, I kept using the original `emit_trampoline_stub` name. > > Testing on linux-riscv64: > - [x] tier1-tier3 (release) > - [x] hotspot:tier1 (fastdebug) Fei Yang has updated the pull request incrementally with one additional commit since the last revision: More improvements ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21822/files - new: https://git.openjdk.org/jdk/pull/21822/files/4585a97d..36664c11 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21822&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21822&range=03-04 Stats: 15 lines in 2 files changed: 1 ins; 5 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/21822.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21822/head:pull/21822 PR: https://git.openjdk.org/jdk/pull/21822 From fyang at openjdk.org Wed Nov 6 03:18:07 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 6 Nov 2024 03:18:07 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v4] In-Reply-To: References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> Message-ID: On Tue, 5 Nov 2024 02:38:46 GMT, Fei Yang wrote: >> Hi, please consider this cleanup change. >> >> The old trampoline call on linux-riscv64 is disabled by default after: https://bugs.openjdk.org/browse/JDK-8332689. >> And the new solution (load target address from stub and call) has been baked in jdk master for quite some time. >> This propose to remove the old trampoline call related logic so that the code will be cleaner and easier to maintain. >> As we are still using `trampoline_stub_Relocation` for the stub, I kept using the original `emit_trampoline_stub` name. >> >> Testing on linux-riscv64: >> - [x] tier1-tier3 (release) >> - [x] hotspot:tier1 (fastdebug) > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Minor Hi, I just pushed a small change addressing two remaining issues which I think should be resolved in this PR. 1. The distance calculation in MacroAssembler::reloc_call is confusing and is not necessary; We are not doing a pc-relative loading from the target, but from the stub. 2. The reloc_call in riscv_enc_java_to_runtime could be further simplified into a simple far_call. This reloc_call is there for the old trampoline call. Also updated related code comment. @robehn @Hamlin-Li : I hope that still looks good to you. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21822#issuecomment-2458645669 From dlong at openjdk.org Wed Nov 6 03:43:33 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 03:43:33 GMT Subject: RFR: 8342893: Highlight special values in hserr file printing [v2] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 11:33:28 GMT, Matthias Baesken wrote: >> src/hotspot/share/runtime/os.cpp line 1346: >> >>> 1344: #ifndef PRODUCT >>> 1345: // corruption or uninitialized access pattern >>> 1346: const intptr_t pat = 0xabababababababab; >> >> How about constructing this from `badResourceValue`? > > We could also put another variable centrally next to badResourceValue , see > https://github.com/openjdk/jdk/blob/4fc6d4135e795d18a024a6035908f380b81082d1/src/hotspot/share/utilities/globalDefinitions.hpp#L1044 > do you have a good naming for this ? Maybe `badZapValue` ? Maybe badResourceValueWord? But I would put it in os.cpp instead of globalDefinitions.hpp until there are other clients. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21811#discussion_r1830348851 From fyang at openjdk.org Wed Nov 6 03:47:28 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 6 Nov 2024 03:47:28 GMT Subject: RFR: 8343600: RISC-V: enable CRC32 intrinsic when either Zba or RVV are supported In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 09:44:21 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > There were 2 intrinsic optimizations, scalar one and vector one, > * plain scalar one optimizes cases when data size is small, scalar one with zba optimizes cases when data size is big; > * vector one optimizes cases when data size is big (better than scalar one with zba). > > With RVV supported, when the size is small it will go to scalar code path, when the size is big it will go to RVV path then scalar path, so that means the RVV itself are sufficient enough to enable the intrinsic even without Zba supported. > > Thanks! Just tried on one of my OoO machines (One which is not equipped with Zba). The performance data still looks fine. I also witnessed that the B-extension is becoming popular on new hardwares (BPI-F3, HiFive P550, etc). So I think we can just eliminate this dependence on Zba. Without intrinsic: Benchmark (count) Mode Cnt Score Error Units TestCRC32.testCRC32Update 64 thrpt 12 1102.980 ? 23.698 ops/ms TestCRC32.testCRC32Update 128 thrpt 12 997.338 ? 22.022 ops/ms TestCRC32.testCRC32Update 256 thrpt 12 796.172 ? 17.290 ops/ms TestCRC32.testCRC32Update 512 thrpt 12 581.080 ? 18.992 ops/ms TestCRC32.testCRC32Update 2048 thrpt 12 234.958 ? 4.581 ops/ms TestCRC32.testCRC32Update 16384 thrpt 12 35.167 ? 0.149 ops/ms TestCRC32.testCRC32Update 65536 thrpt 12 8.893 ? 0.013 ops/ms With intrinsic: Benchmark (count) Mode Cnt Score Error Units TestCRC32.testCRC32Update 64 thrpt 12 6875.581 ? 4.371 ops/ms TestCRC32.testCRC32Update 128 thrpt 12 3848.178 ? 6.049 ops/ms TestCRC32.testCRC32Update 256 thrpt 12 2085.047 ? 5.650 ops/ms TestCRC32.testCRC32Update 512 thrpt 12 1090.035 ? 1.054 ops/ms TestCRC32.testCRC32Update 2048 thrpt 12 281.727 ? 0.149 ops/ms TestCRC32.testCRC32Update 16384 thrpt 12 35.563 ? 0.041 ops/ms TestCRC32.testCRC32Update 65536 thrpt 12 8.751 ? 0.023 ops/ms ------------- PR Comment: https://git.openjdk.org/jdk/pull/21897#issuecomment-2458667409 From jwaters at openjdk.org Wed Nov 6 04:43:42 2024 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 6 Nov 2024 04:43:42 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 6 Nov 2024 01:44:48 GMT, Alex Menkov wrote: > I think you may be throwing the baby out with the bath water when it comes to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see anything that states `__stdcall` is ONLY for 32-bit! To my knowledge the only thing __cdecl and __stdcall do is affect the argument passing on the stack since 32 bit uses the stack to pass arguments. Since 64 bit passes arguments inside registers and then only later uses the stack if there are too many parameters to fit in the parameter registers (Basically permanent __fastcall), these specifiers are probably ignored in all 64 bit platforms ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2458712195 From dholmes at openjdk.org Wed Nov 6 04:55:34 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 04:55:34 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v8] In-Reply-To: References: Message-ID: <1KCOK7hSTz6122-AErD-x4tjyCx7xvdymzVHlLOpO-4=.8e39cde5-969d-4ee0-9af0-262c1844a1e9@github.com> On Tue, 5 Nov 2024 01:10:37 GMT, Ioi Lam wrote: > I've been using AOT in class names and aot in function/variable names. I think that's consistent with HotSpot convention. As an acronym I think AOT in capitals should be preferred even in function/variable names. > In logging, I've been using "aot" as logging seems to favor lowercase. Yes log tags seem to be always lower-case, by convention. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2458722622 From dholmes at openjdk.org Wed Nov 6 05:19:28 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 05:19:28 GMT Subject: RFR: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf [v2] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 15:29:49 GMT, Coleen Phillimore wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore previous behaviour for zero length strings > > src/hotspot/share/utilities/exceptions.cpp line 264: > >> 262: // will be within reasonable limits - specifically we will never hit the INT_MAX limit >> 263: // of os::vsnprintf when it tries to report how big a buffer is needed. Even so we >> 264: // further limit the formatted output to 1024 characters. > > If we're chopping off the message at 1024 characters, why do we have to audit the callers? Is it because vsnprintf will overflow before truncating the message? Seems like it could be easy to add a caller that breaks this. There's no way to check here? Thanks for looking at this @coleenp . Yes it is because vsnprintf will try to tell you how big a buffer you would actually need when you pass a smaller size buffer. There is no way to know how big the formatted message would be without actually expanding it - which of course is only done by vsnprintf. So this comes down to doing a basic audit like this and then remembering to pay attention with new code. The alternative would be to define some global max string size, like the 1024 used here, and then have every caller of `fthrow` use `%*s` passing that max. But that is extremely intrusive if you look at how we end up calling `fthrow`. We have code in the classfile parser/error code where one function creates the message with the `%s` and a lower function actually supplies the argument. It is doable, but it is a lot of code churn to put up a safety rail that this code can't run into anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21867#discussion_r1830400893 From dholmes at openjdk.org Wed Nov 6 05:32:53 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 05:32:53 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v32] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 00:08:16 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Use ThreadIdentifier::initial() in ObjectMonitor::owner_from() Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2417279456 From dholmes at openjdk.org Wed Nov 6 05:55:47 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 05:55:47 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <91oCFKrjKmyjkaT3dBRRcpao4NNde2DXg39vjvBn7Wk=.893ab420-92f3-4bda-8744-4a801a07f95c@github.com> On Wed, 6 Nov 2024 01:44:48 GMT, Alex Menkov wrote: > On ARM and x64 processors, __stdcall is accepted and ignored by the compiler; @alexmenkov and @TheShermanTanker , I stand corrected and my apologies to @magicus . ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2458778303 From fyang at openjdk.org Wed Nov 6 06:28:07 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 6 Nov 2024 06:28:07 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v6] In-Reply-To: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> Message-ID: > Hi, please consider this cleanup change. > > The old trampoline call on linux-riscv64 is disabled by default after: https://bugs.openjdk.org/browse/JDK-8332689. > And the new solution (load target address from stub and call) has been baked in jdk master for quite some time. > This propose to remove the old trampoline call related logic so that the code will be cleaner and easier to maintain. > As we are still using `trampoline_stub_Relocation` for the stub, I kept using the original `emit_trampoline_stub` name. > > Testing on linux-riscv64: > - [x] tier1-tier3 (release) > - [x] hotspot:tier1 (fastdebug) Fei Yang has updated the pull request incrementally with one additional commit since the last revision: More naming ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21822/files - new: https://git.openjdk.org/jdk/pull/21822/files/36664c11..5e5655bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21822&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21822&range=04-05 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/21822.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21822/head:pull/21822 PR: https://git.openjdk.org/jdk/pull/21822 From fyang at openjdk.org Wed Nov 6 06:39:35 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 6 Nov 2024 06:39:35 GMT Subject: RFR: 8343502: RISC-V: SIGBUS in updateBytesCRC32 after JDK-8339738 In-Reply-To: References: Message-ID: <9MqniLUDnQkdiavThBDePi6EiU0ALJgHmKBnexhSEC0=.b7a9715c-b625-4aa8-9ab3-f2b1737754af@github.com> On Mon, 4 Nov 2024 13:24:57 GMT, Hamlin Li wrote: >> Hi, please review this small change. >> >> [JDK-8339738](https://bugs.openjdk.org/browse/JDK-8339738) adds vectorization for crc32 intrinsic, which does `vle32.v` from the input byte buffer and calculates the checksum. But the input byte buffer could be misaligned (not 4-byte aligned). This leads to SIGBUS on hardware platforms like `BPI-F3` board where misaligned vector loads are not supported. Similar issue is there for scalar version as well, which could mean performance issue on other hardwares. Patch fixes this issue by adding a small alignment processing on entry for both scalar and vector version. >> >> This also fixes another potential issue in tail handling, where we do a single `lwu` for both versions to load the remaining bytes from the input byte buffer and extract each byte from the loaded 32-bit value. Since we only have less than 4 bytes remaining, this `lwu` would exceed the buffer limit, which I think is not safe. Patch fixes this issue by doing three separate `lbu` instead. >> >> Testing on `BPI-F3` with RVV 1.0 extension: >> - [x] test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java >> - [x] test/jdk/java/util/zip/TestCRC32.java >> - [x] SPECjbb2015 >> >> No obvious impact witnessed on `micro:java.util.TestCRC32`: >> >> >> Before: >> Benchmark (count) Mode Cnt Score Error Units >> TestCRC32.testCRC32Update 64 thrpt 12 4778.903 ? 1.793 ops/ms >> TestCRC32.testCRC32Update 128 thrpt 12 2655.639 ? 2.958 ops/ms >> TestCRC32.testCRC32Update 256 thrpt 12 1430.997 ? 0.970 ops/ms >> TestCRC32.testCRC32Update 512 thrpt 12 965.785 ? 1.840 ops/ms >> TestCRC32.testCRC32Update 2048 thrpt 12 303.056 ? 0.620 ops/ms >> TestCRC32.testCRC32Update 16384 thrpt 12 40.601 ? 0.220 ops/ms >> TestCRC32.testCRC32Update 65536 thrpt 12 9.575 ? 0.045 ops/ms >> TestCRC32C.testCRC32CUpdate 64 thrpt 12 3923.698 ? 23.209 ops/ms >> TestCRC32C.testCRC32CUpdate 128 thrpt 12 2514.616 ? 22.991 ops/ms >> TestCRC32C.testCRC32CUpdate 256 thrpt 12 1477.223 ? 2.319 ops/ms >> TestCRC32C.testCRC32CUpdate 512 thrpt 12 806.179 ? 1.961 ops/ms >> TestCRC32C.testCRC32CUpdate 2048 thrpt 12 216.396 ? 0.172 ops/ms >> TestCRC32C.testCRC32CUpdate 16384 thrpt 12 27.526 ? 0.049 ops/ms >> TestCRC32C.testCRC32CUpdate 65536 thrpt 12 6.530 ? 0.041 ops/ms >> >> After: >> Benchmark (count) Mode Cn... > > Does the non-alignment data cause any similar issue with other intrinsics? @Hamlin-Li @feilongjiang : Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21863#issuecomment-2458824879 From fyang at openjdk.org Wed Nov 6 06:39:36 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 6 Nov 2024 06:39:36 GMT Subject: Integrated: 8343502: RISC-V: SIGBUS in updateBytesCRC32 after JDK-8339738 In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 03:48:48 GMT, Fei Yang wrote: > Hi, please review this small change. > > [JDK-8339738](https://bugs.openjdk.org/browse/JDK-8339738) adds vectorization for crc32 intrinsic, which does `vle32.v` from the input byte buffer and calculates the checksum. But the input byte buffer could be misaligned (not 4-byte aligned). This leads to SIGBUS on hardware platforms like `BPI-F3` board where misaligned vector loads are not supported. Similar issue is there for scalar version as well, which could mean performance issue on other hardwares. Patch fixes this issue by adding a small alignment processing on entry for both scalar and vector version. > > This also fixes another potential issue in tail handling, where we do a single `lwu` for both versions to load the remaining bytes from the input byte buffer and extract each byte from the loaded 32-bit value. Since we only have less than 4 bytes remaining, this `lwu` would exceed the buffer limit, which I think is not safe. Patch fixes this issue by doing three separate `lbu` instead. > > Testing on `BPI-F3` with RVV 1.0 extension: > - [x] test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java > - [x] test/jdk/java/util/zip/TestCRC32.java > - [x] SPECjbb2015 > > No obvious impact witnessed on `micro:java.util.TestCRC32`: > > > Before: > Benchmark (count) Mode Cnt Score Error Units > TestCRC32.testCRC32Update 64 thrpt 12 4778.903 ? 1.793 ops/ms > TestCRC32.testCRC32Update 128 thrpt 12 2655.639 ? 2.958 ops/ms > TestCRC32.testCRC32Update 256 thrpt 12 1430.997 ? 0.970 ops/ms > TestCRC32.testCRC32Update 512 thrpt 12 965.785 ? 1.840 ops/ms > TestCRC32.testCRC32Update 2048 thrpt 12 303.056 ? 0.620 ops/ms > TestCRC32.testCRC32Update 16384 thrpt 12 40.601 ? 0.220 ops/ms > TestCRC32.testCRC32Update 65536 thrpt 12 9.575 ? 0.045 ops/ms > TestCRC32C.testCRC32CUpdate 64 thrpt 12 3923.698 ? 23.209 ops/ms > TestCRC32C.testCRC32CUpdate 128 thrpt 12 2514.616 ? 22.991 ops/ms > TestCRC32C.testCRC32CUpdate 256 thrpt 12 1477.223 ? 2.319 ops/ms > TestCRC32C.testCRC32CUpdate 512 thrpt 12 806.179 ? 1.961 ops/ms > TestCRC32C.testCRC32CUpdate 2048 thrpt 12 216.396 ? 0.172 ops/ms > TestCRC32C.testCRC32CUpdate 16384 thrpt 12 27.526 ? 0.049 ops/ms > TestCRC32C.testCRC32CUpdate 65536 thrpt 12 6.530 ? 0.041 ops/ms > > After: > Benchmark (count) Mode Cnt Score Error Units > TestCRC32.testCRC32Update 64 ... This pull request has now been integrated. Changeset: bdd68163 Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/bdd68163df4d9b63694bfc0900e4b5ddb2475834 Stats: 31 lines in 1 file changed: 21 ins; 3 del; 7 mod 8343502: RISC-V: SIGBUS in updateBytesCRC32 after JDK-8339738 Reviewed-by: mli, fjiang ------------- PR: https://git.openjdk.org/jdk/pull/21863 From aboldtch at openjdk.org Wed Nov 6 06:39:55 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 6 Nov 2024 06:39:55 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v32] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 00:08:16 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Use ThreadIdentifier::initial() in ObjectMonitor::owner_from() Good work! I'll approve the GC related changes. There are some simplifications I think can be done in the ObjectMonitor layer, but nothing that should go into this PR. Similarly, (even if some of this is preexisting issues) I think that the way we describe the frames and the different frame transitions should be overhauled and made easier to understand. There are so many unnamed constants and adjustments which are spread out everywhere, which makes it hard to get an overview of exactly what happens and what interactions are related to what. You and Dean did a good job at simplifying and adding comments in this PR. But I hope this can be improved in the fututre. A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this. // the sp of the oldest known interpreted/call_stub frame inside the // continuation that we know about ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2417363171 From iklam at openjdk.org Wed Nov 6 06:48:33 2024 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 6 Nov 2024 06:48:33 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v8] In-Reply-To: <1KCOK7hSTz6122-AErD-x4tjyCx7xvdymzVHlLOpO-4=.8e39cde5-969d-4ee0-9af0-262c1844a1e9@github.com> References: <1KCOK7hSTz6122-AErD-x4tjyCx7xvdymzVHlLOpO-4=.8e39cde5-969d-4ee0-9af0-262c1844a1e9@github.com> Message-ID: On Wed, 6 Nov 2024 04:52:56 GMT, David Holmes wrote: > > I've been using AOT in class names and aot in function/variable names. I think that's consistent with HotSpot convention. > > As an acronym I think AOT in capitals should be preferred even in function/variable names. I searched for "GC" vs "gc" and "JVMTI" vs "jvmti" in function names. Almost all of them are in lower cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2458836253 From thartmann at openjdk.org Wed Nov 6 08:04:30 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 6 Nov 2024 08:04:30 GMT Subject: RFR: 8341411: C2: remove slice parameter from GraphKit::make_load() and GraphKit::store_to_memory() In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 14:50:31 GMT, theoweidmannoracle wrote: > This patch removes the address type from `GraphKit::make_load()` and `GraphKit::store_to_memory()` > > As https://github.com/openjdk/jdk/pull/21303 introduced asserts that check that the address type agrees with `C->get_alias_index(_gvn.type(adr)->isa_ptr()`, passing the address type is redundant and it can be computed internally from the address. Looks good to me. @rwestrel who proposed the change, should also have a look. ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21834#pullrequestreview-2417492275 From aph at openjdk.org Wed Nov 6 09:00:42 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 6 Nov 2024 09:00:42 GMT Subject: Integrated: 8331341: secondary_super_cache does not scale well: C1 and interpreter In-Reply-To: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> References: <-FcWfOFLvzxVi15ljQ7WQCDKL4Qnioew3EpOANiLlGI=.d7afc108-3dff-492b-889f-915dec0782f8@github.com> Message-ID: <6M8i72tB9dnEGFdNpfnQ4KfrZS53guLwco2R8gVIfnk=.096fc0d8-8b91-4a0a-921d-8ab846633c33@github.com> On Tue, 2 Jul 2024 14:52:09 GMT, Andrew Haley wrote: > This patch expands the use of a hash table for secondary superclasses > to the interpreter, C1, and runtime. It also adds a C2 implementation > of hashed lookup in cases where the superclass isn't known at compile > time. > > HotSpot shared runtime > ---------------------- > > Building hashed secondary tables is now unconditional. It takes very > little time, and now that the shared runtime always has the tables, it > might as well take advantage of them. The shared code is easier to > follow now, I think. > > There might be a performance issue with x86-64 in that we build > HotSpot for a default x86-64 target that does not support popcount. > This means that HotSpot C++ runtime on x86 always uses a software > emulation for popcount, even though the vast majority of machines made > for the past 20 years can do popcount in a single instruction. It > wouldn't be terribly hard to do something about that. > > Having said that, the software popcount is really not bad. > > x86 > --- > > x86 is rather tricky, because we still support > `-XX:-UseSecondarySupersTable` and `-XX:+UseSecondarySupersCache`, as > well as 32- and 64-bit ports. There's some further complication in > that only `RCX` can be used as a shift count, so there's some register > shuffling to do. All of this makes the logic in macroAssembler_x86.cpp > rather gnarly, with multiple levels of conditionals at compile time > and runtime. > > AArch64 > ------- > > AArch64 is considerably more straightforward. We always have a > popcount instruction and (thankfully) no 32-bit code to worry about. > > Generally > --------- > > I would dearly love simply to rip out the "old" secondary supers cache > support, but I've left it in just in case someone has a performance > regression. > > The versions of `MacroAssembler::lookup_secondary_supers_table` that > work with variable superclasses don't take a fixed set of temp > registers, and neither do they call out to to a slow path subroutine. > Instead, the slow patch is expanded inline. > > I don't think this is necessarily bad. Apart from the very rare cases > where C2 can't determine the superclass to search for at compile time, > this code is only used for generating stubs, and it seemed to me > ridiculous to have stubs calling other stubs. > > I've followed the guidance from @iwanowww not to obsess too much about > the performance of C1-compiled secondary supers lookups, and to prefer > simplicity over absolute performance. Nonetheless, this is a > complicated patch that touches many areas. This pull request has now been integrated. Changeset: ead0116f Author: Andrew Haley URL: https://git.openjdk.org/jdk/commit/ead0116f2624e0e34529e47e4f509142d588b994 Stats: 1059 lines in 22 files changed: 783 ins; 140 del; 136 mod 8331341: secondary_super_cache does not scale well: C1 and interpreter Reviewed-by: vlivanov, kvn, dlong ------------- PR: https://git.openjdk.org/jdk/pull/19989 From stuefe at openjdk.org Wed Nov 6 09:13:47 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 6 Nov 2024 09:13:47 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v50] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 16:43:35 GMT, Roman Kennke wrote: >> @egahlin / @mgronlun could you please review the JFR parts of this PR? One change is for getting the right prototype header, the other is for avoiding an endless loop/assert in a corner case. > >> @rkennke can you include this small update for s390x as well: >> >> ```diff >> diff --git a/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp b/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp >> index 0f7e5c9f457..476e3d5daa4 100644 >> --- a/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp >> +++ b/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp >> @@ -174,8 +174,11 @@ void C1_MacroAssembler::try_allocate( >> void C1_MacroAssembler::initialize_header(Register obj, Register klass, Register len, Register Rzero, Register t1) { >> assert_different_registers(obj, klass, len, t1, Rzero); >> if (UseCompactObjectHeaders) { >> - z_lg(t1, Address(klass, in_bytes(Klass::prototype_header_offset()))); >> - z_stg(t1, Address(obj, oopDesc::mark_offset_in_bytes())); >> + z_mvc( >> + Address(obj, oopDesc::mark_offset_in_bytes()), /* move to */ >> + Address(klass, in_bytes(Klass::prototype_header_offset())), /* move from */ >> + sizeof(markWord) /* how much to move */ >> + ); >> } else { >> load_const_optimized(t1, (intx)markWord::prototype().value()); >> z_stg(t1, Address(obj, oopDesc::mark_offset_in_bytes())); >> diff --git a/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp b/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp >> index 378d5e4cfe1..c5713161bf9 100644 >> --- a/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp >> +++ b/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp >> @@ -46,7 +46,7 @@ void C2_MacroAssembler::load_narrow_klass_compact_c2(Register dst, Address src) >> // The incoming address is pointing into obj-start + klass_offset_in_bytes. We need to extract >> // obj-start, so that we can load from the object's mark-word instead. >> z_lg(dst, src.plus_disp(-oopDesc::klass_offset_in_bytes())); >> - z_srlg(dst, dst, markWord::klass_shift); // TODO: could be z_sra >> + z_srlg(dst, dst, markWord::klass_shift); >> } >> >> //------------------------------------------------------ >> diff --git a/src/hotspot/cpu/s390/templateTable_s390.cpp b/src/hotspot/cpu/s390/templateTable_s390.cpp >> index 3cb1aba810d..5b8f7a20478 100644 >> --- a/src/hotspot/cpu/s390/templateTable_s390.cpp >> +++ b/src/hotspot/cpu/s390/templateTable_s390.cpp >> @@ -3980,8 +3980,11 @@ void TemplateTable::_new() { >> // Initialize object header only. >> __ bind(initialize_header); >> if (UseCompactObjectHeaders) { >> - __ z_lg(tmp, Address(iklass, in_bytes(Klass::prototype_header_offset()))); >> - __ z_stg(tmp, Address(RallocatedObject, oo... Merge is good. @rkennke patch for the new test errors due to removal of non-generational ZGC: https://gist.github.com/tstuefe/321b769d3b281198b767b68e18bb7271 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2459069232 From rkennke at openjdk.org Wed Nov 6 09:13:46 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 6 Nov 2024 09:13:46 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v55] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Fix gen-ZGC removal ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20677/files - new: https://git.openjdk.org/jdk/pull/20677/files/b945822a..1ea4de16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=54 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=53-54 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From stuefe at openjdk.org Wed Nov 6 09:15:11 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 6 Nov 2024 09:15:11 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 6 Nov 2024 04:40:24 GMT, Julian Waters wrote: > I think you may be throwing the baby out with the bath water when it comes to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see anything that states `__stdcall` is ONLY for 32-bit! stdcall and cdecl are 32-bit Windows calling conventions. On x64 and arm64, as on all other platforms we support, there is just one calling convention. See https://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention. I am sure __stdcall is ignored by the compiler on x64 or arm64. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2459078526 From stuefe at openjdk.org Wed Nov 6 09:15:12 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 6 Nov 2024 09:15:12 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 6 Nov 2024 09:12:02 GMT, Thomas Stuefe wrote: > > I think you may be throwing the baby out with the bath water when it comes to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see anything that states `__stdcall` is ONLY for 32-bit! > > stdcall and cdecl are 32-bit Windows calling conventions. On x64 and arm64, as on all other platforms we support, there is just one calling convention. See https://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention. > > I am sure __stdcall is ignored by the compiler on x64 or arm64. Never mind my noise, other people did already answer this :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2459080708 From mli at openjdk.org Wed Nov 6 09:16:37 2024 From: mli at openjdk.org (Hamlin Li) Date: Wed, 6 Nov 2024 09:16:37 GMT Subject: RFR: 8343600: RISC-V: enable CRC32 intrinsic when either Zba or RVV are supported In-Reply-To: References: Message-ID: <-dbCTklpgiKJotkgc637HU1RDVOI8VOgCeSB5ruxQtA=.a61624db-c878-4d9d-8b9a-82491d80c9e3@github.com> On Wed, 6 Nov 2024 03:42:42 GMT, Fei Yang wrote: > Just tried on one of my OoO riscv64 machines (One which is not equipped with Zba). The performance data still looks fine. I also witnessed that the B-extension is becoming popular on new hardwares (BPI-F3, HiFive P550, etc). So I think we can just eliminate this dependence on Zba. Great! Thanks for testing! Are these machines with or without RVV? As either RVV and Zba can improvement the performance when the data size is big. So to remove it, it might be safer for us to make sure when both RVV and Zba are not supported, we still get no performance regression when data size is big. And seems the test data above also show a little regression when size is 65536, and the trend shows it will get bigger when data size get bigger than 65536. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21897#issuecomment-2459081257 From stuefe at openjdk.org Wed Nov 6 09:17:31 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 6 Nov 2024 09:17:31 GMT Subject: RFR: 8300732: Whitebox functions for Metaspace test should use byte size [v5] In-Reply-To: References: Message-ID: <5Lq_X6YlO_1KKwyj1dgGZbrBckY0-N8R8Skn4aqWJno=.d24738da-f380-4745-9303-5a218c4dd393@github.com> On Tue, 5 Nov 2024 18:07:19 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8300732](https://bugs.openjdk.org/browse/JDK-8300732) switching Whitebox Metaspace test functions to use bytes as opposed to words. >> >> Testing: >> - [x] `test/hotspot/jtreg/runtime/Metaspace` tests pass. >> >> Thanks, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Fixing indentation and comment All good, but please hold off with pushing until https://github.com/openjdk/jdk/pull/20677 is pushed. Thank you! ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20039#pullrequestreview-2417646494 From alanb at openjdk.org Wed Nov 6 09:26:55 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 09:26:55 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 00:01:21 GMT, Patricio Chilano Mateo wrote: >>> Is this posted after the VirtualThreadMount extension event posted? >>> >> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620 > >> The JvmtiExport::post_monitor_waited() is called at the line 1801. >> Does it post the MonitorWaited event for this virtual thread as well? >> > That's the path a virtual thread will take if pinned. This case is when we were able to unmount the vthread. It is the equivalent, where the vthread finished the wait part (notified, interrupted or timed-out case) and it's going to retry acquiring the monitor. Just to add that the 2 extension events (VirtualThreadMount and VirtualThreadUnmount) are not part of any supported/documented interface. They are a left over from the exploration phase of virtual threads when we assumed the debugger agent would need to track the transitions. So at some point I think we need to figure out how to make them go away as they are an attractive nuisance (esp. if the event callback were to upcall and execute Java code). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830657204 From jbechberger at openjdk.org Wed Nov 6 09:38:45 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 09:38:45 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v7] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision: - Add test case for class unloading - Improve readability of thread_state functions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/01783bc9..1929fa94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=05-06 Stats: 224 lines in 6 files changed: 184 ins; 24 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From fyang at openjdk.org Wed Nov 6 09:45:30 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 6 Nov 2024 09:45:30 GMT Subject: RFR: 8343600: RISC-V: enable CRC32 intrinsic when either Zba or RVV are supported In-Reply-To: <-dbCTklpgiKJotkgc637HU1RDVOI8VOgCeSB5ruxQtA=.a61624db-c878-4d9d-8b9a-82491d80c9e3@github.com> References: <-dbCTklpgiKJotkgc637HU1RDVOI8VOgCeSB5ruxQtA=.a61624db-c878-4d9d-8b9a-82491d80c9e3@github.com> Message-ID: On Wed, 6 Nov 2024 09:13:23 GMT, Hamlin Li wrote: > > Just tried on one of my OoO riscv64 machines (One which is not equipped with Zba). The performance data still looks fine. I also witnessed that the B-extension is becoming popular on new hardwares (BPI-F3, HiFive P550, etc). So I think we can just eliminate this dependence on Zba. > > Great! Thanks for testing! > > Are these machines with or without RVV? As either RVV and Zba can improvement the performance when the data size is big. So to remove it, it might be safer for us to make sure when both RVV and Zba are not supported, we still get no performance regression when data size is big. There is no RVV extension either. I should have mentioned this in my previous message :-) > And seems the test data above also show a little regression when size is 65536, and the trend shows it will get bigger when data size get bigger than 65536. Yeah, kind of. I guess that issue is also there even we have Zba. But I don't see a good way to make it size aware. Maybe we should only keep the vector version? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21897#issuecomment-2459142243 From jbechberger at openjdk.org Wed Nov 6 09:46:38 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 09:46:38 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v8] In-Reply-To: References: Message-ID: <8ctQXH4gYaXlPmZ4bQ228Y9JlQRtr1Ih9q2--t-mbnY=.ded36a33-950b-4ac9-9909-841f2e2dcd2e@github.com> > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Don't crash protect storing walked stack in JFR ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/1929fa94..65423ad8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=06-07 Stats: 37 lines in 2 files changed: 0 ins; 31 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From jbechberger at openjdk.org Wed Nov 6 09:46:39 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 09:46:39 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4] In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 16:09:37 GMT, Markus Gr?nlund wrote: >> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove min_valid_free_size_bytes > > linux-aarch64-debug > > --------------- T H R E A D --------------- > > Current thread (0x0000ffffac4222b0): JavaThread "JFR Recorder Thread" daemon [_thread_in_vm, id=144094, stack(0x0000ffff5e17a000,0x0000ffff5e378000) (2040K)] > > Stack: [0x0000ffff5e17a000,0x0000ffff5e378000], sp=0x0000ffff5e376110, free space=2032k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0xe19e54] get_cld(Klass const*)+0x34 (klass.hpp:684) > V [libjvm.so+0xe1c674] write_klass(JfrCheckpointWriter*, Klass const*, bool, int&)+0x70 (jfrTypeSet.cpp:370) > V [libjvm.so+0xe22d40] JfrArtifactCallbackHost, &(write__klass__leakp(JfrCheckpointWriter*, void const*))>, 183u>, JfrTypeWriterHost, &(write__klass(JfrCheckpointWriter*, void const*))>, 183u> >, KlassArtifactRegistrator> >::do_artifact(void const*)+0x90 (jfrTypeSet.cpp:398) > V [libjvm.so+0xe14fe0] EpochDispatchOp::ElementDispatch >::dispatch(bool, unsigned char const*, unsigned long)+0xd0 (jfrTraceIdKlassQueue.hpp:42) > V [libjvm.so+0xe15328] void JfrEpochQueue::iterate(KlassFunctor&, bool)+0xd8 (jfrStorageUtils.inline.hpp:160) > V [libjvm.so+0xe13ad0] JfrTraceIdKlassQueue::iterate(void (*)(Klass*), bool)+0x40 (jfrTraceIdKlassQueue.cpp:269) > V [libjvm.so+0xe21358] JfrTypeSet::serialize(JfrCheckpointWriter*, JfrCheckpointWriter*, bool, bool)+0x1c4 (jfrTypeSet.cpp:565) > V [libjvm.so+0xd6baf4] JfrCheckpointManager::write_type_set()+0x1a0 (jfrCheckpointManager.cpp:617) > V [libjvm.so+0xddfa54] JfrRecorderService::post_safepoint_write()+0xb0 (jfrRecorderService.cpp:613) > V [libjvm.so+0xde0bdc] JfrRecorderService::chunk_rotation()+0x3c (jfrRecorderService.cpp:573) > V [libjvm.so+0xde2104] JfrRecorderService::rotate(int)+0x100 (jfrRecorderService.cpp:539) > V [libjvm.so+0xde332c] recorderthread_entry(JavaThread*, JavaThread*)+0x2ac (jfrRecorderThreadLoop.cpp:81) > V [libjvm.so+0xd50400] JavaThread::thread_main_inner()+0xcc (javaThread.cpp:759) > V [libjvm.so+0x15e59e0] Thread::call_run()+0xac (thread.cpp:234) > V [libjvm.so+0x131fae4] thread_native_entry(Thread*)+0x130 (os_linux.cpp:858) > C [libc.so.6+0x806b8] start_thread+0x2d8 @mgronlun class unloading related issues should be fixed. Could you please test it again? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2459143981 From jbechberger at openjdk.org Wed Nov 6 09:46:40 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 09:46:40 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 15:41:48 GMT, Johannes Bechberger wrote: >> src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 116: >> >>> 114: return false; >>> 115: } >>> 116: const traceid mid = JfrTraceId::load(frame._method); >> >> This is JfrTraceId::load() barrier code: >> >> inline traceid JfrTraceIdLoadBarrier::load(const Klass* klass, const Method* method) { >> assert(klass != nullptr, "invariant"); >> assert(method != nullptr, "invariant"); >> if (should_tag(method)) { >> SET_METHOD_AND_CLASS_USED_THIS_EPOCH(klass); >> SET_METHOD_FLAG_USED_THIS_EPOCH(method); >> assert(METHOD_AND_CLASS_USED_THIS_EPOCH(klass), "invariant"); >> assert(METHOD_FLAG_USED_THIS_EPOCH(method), "invariant"); >> enqueue(klass); >> JfrTraceIdEpoch::set_changed_tag_state(); >> } >> return (METHOD_ID(klass, method)); >> } >> >> What happens if the sampler crashes at one of these routines? >> >> 1. Sets bits in the Klass, but not in the Method, and does not enqueue? >> 2. Set bits in the Klass and Method, but does not enqueue? >> 3. Sets bits in Klass, Method and enqueues, but does not notify? > > That's a really good point. > > FYI: Today is a bank holiday in Germany, so I don't work on the PR today, but it'll be my main focus in the following weeks I removed the crash protection that surrounds the code. It isn't needed anymore. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1830684081 From mli at openjdk.org Wed Nov 6 09:52:28 2024 From: mli at openjdk.org (Hamlin Li) Date: Wed, 6 Nov 2024 09:52:28 GMT Subject: RFR: 8343600: RISC-V: enable CRC32 intrinsic when either Zba or RVV are supported In-Reply-To: References: <-dbCTklpgiKJotkgc637HU1RDVOI8VOgCeSB5ruxQtA=.a61624db-c878-4d9d-8b9a-82491d80c9e3@github.com> Message-ID: On Wed, 6 Nov 2024 09:42:27 GMT, Fei Yang wrote: > Yeah, kind of. I guess that issue is also there even we have Zba. But I don't see a good way to make it size aware. Maybe we should only keep the vector version? I'm not sure. I saw the trend when that pr was in progress. Although I guess the big size of data is one of main usage cases for CRC, but I don't know how big it can get. So, for now I would suggest to keep both Zba and RVV version at the same time, and in the future if we get regression report in the real world use case, we can just turn off CRC intrinsic when RVV is not supported. How do you think about it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21897#issuecomment-2459158137 From jbechberger at openjdk.org Wed Nov 6 09:56:47 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 09:56:47 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v9] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Make things static ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/65423ad8..814bb97b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=07-08 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From fyang at openjdk.org Wed Nov 6 10:01:30 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 6 Nov 2024 10:01:30 GMT Subject: RFR: 8343600: RISC-V: enable CRC32 intrinsic when either Zba or RVV are supported In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 09:44:21 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > There were 2 intrinsic optimizations, scalar one and vector one, > * plain scalar one optimizes cases when data size is small, scalar one with zba optimizes cases when data size is big; > * vector one optimizes cases when data size is big (better than scalar one with zba). > > With RVV supported, when the size is small it will go to scalar code path, when the size is big it will go to RVV path then scalar path, so that means the RVV itself are sufficient enough to enable the intrinsic even without Zba supported. > > Thanks! Looks fine to me. The dependence on Zba should be a separate issue. Thanks. ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21897#pullrequestreview-2417753424 From mli at openjdk.org Wed Nov 6 10:11:32 2024 From: mli at openjdk.org (Hamlin Li) Date: Wed, 6 Nov 2024 10:11:32 GMT Subject: RFR: 8343600: RISC-V: enable CRC32 intrinsic when either Zba or RVV are supported In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 09:58:35 GMT, Fei Yang wrote: > Looks fine to me. The dependence on Zba should be a separate issue. Thanks. Thanks. Yeah, potential issue due to Zba is better to be resolved when we face the real world issue, or if we can make sure the issue is going to happen in normal cases, for the latter one I'm not sure, if anyone is pretty sure, please help to propose a change, we will fix it soon. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21897#issuecomment-2459198224 From jbechberger at openjdk.org Wed Nov 6 10:14:39 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 10:14:39 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v9] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 05:26:20 GMT, David Holmes wrote: >> Is this really an issue? And if so, how would I implement this? > > Whether the racing is an issue only you can answer. My concern is that using the `Threads_lock` is bad and unnecessary - if you want a stable set of threads then you just need a `ThreadsListIterator`. > > Otherwise you'd implement with a safepoint VM operation that you submit to the VMThread. I just looked into it. We only call the methods that take the locks when - the sampler is first enrolled - the timer intervals are updated - the timer is stopped This shouldn't happen that often in practice, so I think that it is good to have the additional guarantees offered by safepoints. We can modify this if we see real world performance issues. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1830728349 From gcao at openjdk.org Wed Nov 6 10:38:39 2024 From: gcao at openjdk.org (Gui Cao) Date: Wed, 6 Nov 2024 10:38:39 GMT Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well: C1 and interpreter Message-ID: Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter. ### Testing - [ ] Run tier1-3 tests on SOPHON SG2042 (release) ------------- Commit messages: - 8342881: RISC-V: secondary_super_cache does not scale well: C1 and interpreter Changes: https://git.openjdk.org/jdk/pull/21922/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21922&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342881 Stats: 375 lines in 5 files changed: 300 ins; 23 del; 52 mod Patch: https://git.openjdk.org/jdk/pull/21922.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21922/head:pull/21922 PR: https://git.openjdk.org/jdk/pull/21922 From jbechberger at openjdk.org Wed Nov 6 10:57:59 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 10:57:59 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v10] In-Reply-To: References: Message-ID: <9svUVUB63cGcP3iHZfLUa45qfJnyA-WY9zd1S2NDU3M=.eaa2518b-a6cc-4f82-a309-e23d1da0c289@github.com> > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision: - Only do timer init and removal at global safepoint - Only do timer init and removal at global safepoint ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/814bb97b..18a83be7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=08-09 Stats: 72 lines in 4 files changed: 45 ins; 15 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From jbechberger at openjdk.org Wed Nov 6 10:57:59 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 10:57:59 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v10] In-Reply-To: References: Message-ID: <4u6cmDWIxpaZ9_aM91B5ZGlBaeRDU-a1a_wIqNqZheo=.3c38b8d4-5335-4a0f-aaac-6db2dc6c73f9@github.com> On Wed, 6 Nov 2024 10:11:18 GMT, Johannes Bechberger wrote: >> Whether the racing is an issue only you can answer. My concern is that using the `Threads_lock` is bad and unnecessary - if you want a stable set of threads then you just need a `ThreadsListIterator`. >> >> Otherwise you'd implement with a safepoint VM operation that you submit to the VMThread. > > I just looked into it. We only call the methods that take the locks when > - the sampler is first enrolled > - the timer intervals are updated > - the timer is stopped > > This shouldn't happen that often in practice, so I think that it is good to have the additional guarantees offered by safepoints. > > We can modify this if we see real world performance issues. So maybe we do timer init and removal at global safepoints? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1830813096 From jbechberger at openjdk.org Wed Nov 6 11:04:43 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 11:04:43 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v10] In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 21:45:57 GMT, Markus Gr?nlund wrote: > Aha - so even if the event is not decorated with stackTrace=true in metadata.xml, it has an explicit field with the same name "StackTrace". Yes. > Wonder why this should be handled differently from ExecutionSample? You're not the only one. I'm looking into it today. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1830824713 From jbechberger at openjdk.org Wed Nov 6 11:04:43 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 11:04:43 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v10] In-Reply-To: <81JToiHQF-r-a8nhfoZQcO50iIqnwIpEOqF-N7QyW_E=.46bbc341-94fb-4e20-a299-0750278fc1fc@github.com> References: <8fM5N_qr8KP7heWmKun5JVBU095ELhn_cxYSwpb9O8U=.2419d2a6-4172-4b5d-bea6-2a2b13bb0ea5@github.com> <81JToiHQF-r-a8nhfoZQcO50iIqnwIpEOqF-N7QyW_E=.46bbc341-94fb-4e20-a299-0750278fc1fc@github.com> Message-ID: <7x1r_1er-7R-kB9JBC4AZw4v8H9_5hGh7bUCt2Co17E=.2fcd8495-84fd-4f55-8fb8-d4e3b1f4f221@github.com> On Thu, 31 Oct 2024 09:56:17 GMT, Markus Gr?nlund wrote: >> If you say so. Then I set the value to `2000/s` and we're fine? > > If that is the recalculation from 10 ms according to the adjustments, then yes, this is preferable. It's slightly higher, because I assume that most systems don't use all CPU cores all the time (e.g. GCs, ...). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1830826084 From roland at openjdk.org Wed Nov 6 12:24:29 2024 From: roland at openjdk.org (Roland Westrelin) Date: Wed, 6 Nov 2024 12:24:29 GMT Subject: RFR: 8341411: C2: remove slice parameter from GraphKit::make_load() and GraphKit::store_to_memory() In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 14:50:31 GMT, theoweidmannoracle wrote: > This patch removes the address type from `GraphKit::make_load()` and `GraphKit::store_to_memory()` > > As https://github.com/openjdk/jdk/pull/21303 introduced asserts that check that the address type agrees with `C->get_alias_index(_gvn.type(adr)->isa_ptr()`, passing the address type is redundant and it can be computed internally from the address. src/hotspot/share/gc/shared/c2/barrierSetC2.cpp line 220: > 218: load = kit->gvn().transform(load); > 219: } else { > 220: load = kit->make_load(control, adr, val_type, access.type(), adr_type, mo, No similar change to `BarrierSetC2::store_at_resolved()`? src/hotspot/share/opto/graphKit.cpp line 1561: > 1559: bool unsafe, > 1560: uint8_t barrier_data) { > 1561: assert(adr_idx == C->get_alias_index(_gvn.type(adr)->isa_ptr()), "slice of address and input slice don't match"); This assert (and the other one in `store_to_memory`) were added because there are 2 ways to compute the slice for a memory operation. One is from `_gvn.type(adr)->isa_ptr()`. The other is from `C->alias_type(field)->adr_type()` in case of fields accesses (see `Parse::do_get_xxx()` and `Parse::do_put_xxx()`). They should give the same result but in one bug we ran into that wasn't the case (thus the assert). I don't think we want to remove this assert entirely but rather push it up the call chain maybe to `BarrierSetC2::store_at_resolved()`/`BarrierSetC2::load_at_resolved` or all the way to where `C->alias_type(field)->adr_type()` is called. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21834#discussion_r1830926706 PR Review Comment: https://git.openjdk.org/jdk/pull/21834#discussion_r1830901217 From egahlin at openjdk.org Wed Nov 6 12:59:41 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 6 Nov 2024 12:59:41 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v10] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 11:00:25 GMT, Johannes Bechberger wrote: >>> The problem is, is that `eventType.hasStackTrace()` checks for the existence of a field called `stackTrace`, which CPUTimeSample events have. We could of course rename the field to something like `recordedStackTrace`, but I don't think that this is helpful. >> >> Aha - so even if the event is not decorated with stackTrace=true in metadata.xml, it has an explicit field with the same name "StackTrace". Wonder why this should be handled differently from ExecutionSample? > >> Aha - so even if the event is not decorated with stackTrace=true in metadata.xml, it has an explicit field with the same name "StackTrace". > > Yes. > >> Wonder why this should be handled differently from ExecutionSample? > > You're not the only one. I'm looking into it today. Could it be that the ExecutionSample is a periodic event, CPUTimeSample is not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1830972453 From jbechberger at openjdk.org Wed Nov 6 12:59:42 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 12:59:42 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4] In-Reply-To: References: Message-ID: <3m9egyO3qCXG1SN_mEo_eUwugmP2nx8u_Bm8i6B7eww=.43342041-330d-447d-8c79-e03c6a56e9b7@github.com> On Thu, 31 Oct 2024 13:24:32 GMT, Erik Gahlin wrote: >> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove min_valid_free_size_bytes > > test/jdk/jdk/jfr/event/profiling/TestNative.java line 43: > >> 41: public class TestNative { >> 42: >> 43: static String nativeEvent = EventNames.NativeMethodSample; > > Why is this change needed? Good catch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1830975871 From jbechberger at openjdk.org Wed Nov 6 13:08:03 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 13:08:03 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v11] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Tiny refactoring ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/18a83be7..9d6716eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From jbechberger at openjdk.org Wed Nov 6 13:08:04 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 13:08:04 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v11] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 12:54:10 GMT, Erik Gahlin wrote: >>> Aha - so even if the event is not decorated with stackTrace=true in metadata.xml, it has an explicit field with the same name "StackTrace". >> >> Yes. >> >>> Wonder why this should be handled differently from ExecutionSample? >> >> You're not the only one. I'm looking into it today. > > Could it be that the ExecutionSample is a periodic event, CPUTimeSample is not. That makes sense. But can I just keep the code that I wrote then? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1830985372 From jbechberger at openjdk.org Wed Nov 6 13:24:36 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 13:24:36 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v12] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Tiny refactoring ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/9d6716eb..132779fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=10-11 Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From egahlin at openjdk.org Wed Nov 6 13:24:37 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 6 Nov 2024 13:24:37 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v12] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 13:03:36 GMT, Johannes Bechberger wrote: >> Could it be that the ExecutionSample is a periodic event, CPUTimeSample is not. > > That makes sense. But can I just keep the code that I wrote then? Can't you do the same as ObjectAllocationSample and OldObjectSample? They are not periodic and have throttle/cutoff. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1831007275 From jbechberger at openjdk.org Wed Nov 6 13:32:40 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 13:32:40 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v12] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 13:20:02 GMT, Erik Gahlin wrote: >> That makes sense. But can I just keep the code that I wrote then? > > Can't you do the same as ObjectAllocationSample and OldObjectSample? They are not periodic and have throttle/cutoff. And they set a `true` in the settings. But this doesn't make sense here, because without a stacktrace, a sample is not really that useful. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1831021006 From jbechberger at openjdk.org Wed Nov 6 13:51:49 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 13:51:49 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v13] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision: - Don't use method-sample-enabled control - Use ResetNoHandleMark when walking the stack ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/132779fb..7c61bc68 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=11-12 Stats: 6 lines in 2 files changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From jbechberger at openjdk.org Wed Nov 6 13:51:50 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 13:51:50 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4] In-Reply-To: References: <2NwYW96LtQYBAH_mSxlo24yxc5IWMcy9Mql1TKTLpIs=.a8c69824-c239-473f-bec6-bbb678a90c39@github.com> Message-ID: On Thu, 31 Oct 2024 12:03:18 GMT, Johannes Bechberger wrote: >> Perhaps even more interesting is that I got this when running out-of-the-box with: >> >> XX:StartFlightRecording:settings=profile.jfc >> >> // profile.jfc >> >> >> false >> 10ms >> >> >> This indicates that the event is turned on, despite "enabled" being false. Is there a bug in the control / enable setting mechanism? > > That is both interesting (and worrying). I'm going to write a test for the latter issue. > NoHandleMark will not work with with continuations. Please see how we do it in JfrStackTrace::record() Thank you. > This indicates that the event is turned on, despite "enabled" being false. Is there a bug in the control / enable setting mechanism? I was unable to reproduce the issue but I removed the control attribute because I don't think that users would expect CPU sampling to be enabled when they set `method-sampling-enabled`. This hopefully solves your issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1831049378 From egahlin at openjdk.org Wed Nov 6 13:55:42 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 6 Nov 2024 13:55:42 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v13] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 13:29:43 GMT, Johannes Bechberger wrote: >> Can't you do the same as ObjectAllocationSample and OldObjectSample? They are not periodic and have throttle/cutoff. > > And they set a `true` in the settings. But this doesn't make sense here, because without a stacktrace, a sample is not really that useful. If you disable the stackTrace, you will still get the thread. Perhaps not that useful, but that could be said about many events that have a stack trace. I think we should keep it consistent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1831056487 From jbechberger at openjdk.org Wed Nov 6 14:04:41 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 14:04:41 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v13] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 13:51:59 GMT, Erik Gahlin wrote: >> And they set a `true` in the settings. But this doesn't make sense here, because without a stacktrace, a sample is not really that useful. > > If you disable the stackTrace, you will still get the thread. Perhaps not that useful, but that could be said about many events that have a stack trace. I think we should keep it consistent. But doesn't the user expect that they get a stack trace when they write a settings file with: true 150/s Because when they write true 10ms They also get one. So I think we should not force the user to set the stacktrace. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1831071723 From jsjolen at openjdk.org Wed Nov 6 15:00:13 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 6 Nov 2024 15:00:13 GMT Subject: RFR: 8343244: Aarch64: Internal Error virtualMemoryTracker.cpp:444 assert(reserved_rgn != nullptr) failed: Add committed region, No reserved region found Message-ID: Hi, Ping @roberttoyonaga , @tstuefe , @afshin-zafari , @dholmes-ora , @gerard-ziemski We are seeing issues with the transition to one of our 'fat' mutexes. Specifically, we do have `os::commit_memory` that occurs during the running `Thread`'s initialization, see the following stack trace: Stack: [0x0000ffff686ae000,0x0000ffff687ae000], sp=0x0000ffff687ac5f0, free space=1017k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x16aa67c] VirtualMemoryTracker::add_committed_region(unsigned char*, unsigned long, NativeCallStack const&)+0x38c (virtualMemoryTracker.cpp:444) V [libjvm.so+0x131134c] os::commit_memory(char*, unsigned long, bool)+0x198 (memTracker.hpp:165) V [libjvm.so+0x14ddf54] StackOverflow::create_stack_guard_pages()+0x70 (stackOverflow.cpp:97) V [libjvm.so+0xe2e0dc] attach_current_thread.isra.0+0x11c (jni.cpp:3809) C [libExplicitAttach.so+0xa64] thread_main+0x34 (libExplicitAttach.c:45) C [libc.so.6+0x806b8] start_thread+0x2d8 This, in turn, causes issues where the lock isn't actually taken, causing issues with the VMT. I'd like to suggest that we switch out the `Mutex` to a `PlatformMutex`. Platform mutexes are identical in construction to `ThreadCritical`, but are at least not shared globally and can be owned by the `VirtualMemoryTracker`. If you do not agree with this change, then I suggest that we back out [8304824](https://bugs.openjdk.org/browse/JDK-8304824) ASAP and wait for a better solution. Thanks. ------------- Commit messages: - Fix - Rewrite into PlatformMutex Changes: https://git.openjdk.org/jdk/pull/21928/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21928&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343244 Stats: 75 lines in 13 files changed: 39 ins; 11 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/21928.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21928/head:pull/21928 PR: https://git.openjdk.org/jdk/pull/21928 From duke at openjdk.org Wed Nov 6 15:00:13 2024 From: duke at openjdk.org (Robert Toyonaga) Date: Wed, 6 Nov 2024 15:00:13 GMT Subject: RFR: 8343244: Aarch64: Internal Error virtualMemoryTracker.cpp:444 assert(reserved_rgn != nullptr) failed: Add committed region, No reserved region found In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 14:01:43 GMT, Johan Sj?len wrote: > Hi, > > Ping @roberttoyonaga , @tstuefe , @afshin-zafari , @dholmes-ora , @gerard-ziemski > > We are seeing issues with the transition to one of our 'fat' mutexes. Specifically, we do have `os::commit_memory` that occurs during the running `Thread`'s initialization, see the following stack trace: > > > Stack: [0x0000ffff686ae000,0x0000ffff687ae000], sp=0x0000ffff687ac5f0, free space=1017k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x16aa67c] VirtualMemoryTracker::add_committed_region(unsigned char*, unsigned long, NativeCallStack const&)+0x38c (virtualMemoryTracker.cpp:444) > V [libjvm.so+0x131134c] os::commit_memory(char*, unsigned long, bool)+0x198 (memTracker.hpp:165) > V [libjvm.so+0x14ddf54] StackOverflow::create_stack_guard_pages()+0x70 (stackOverflow.cpp:97) > V [libjvm.so+0xe2e0dc] attach_current_thread.isra.0+0x11c (jni.cpp:3809) > C [libExplicitAttach.so+0xa64] thread_main+0x34 (libExplicitAttach.c:45) > C [libc.so.6+0x806b8] start_thread+0x2d8 > > > This, in turn, causes issues where the lock isn't actually taken, causing issues with the VMT. I'd like to suggest that we switch out the `Mutex` to a `PlatformMutex`. Platform mutexes are identical in construction to `ThreadCritical`, but are at least not shared globally and can be owned by the `VirtualMemoryTracker`. > > If you do not agree with this change, then I suggest that we back out [8304824](https://bugs.openjdk.org/browse/JDK-8304824) ASAP and wait for a better solution. > > Thanks. @jdksjolen So just to clarify, the issue is due to `NmtVirtualMemoryLocker` not locking since `Thread::current_or_null_safe` is `nullptr` during thread initialization, and `PlatformMutex` isn't affected by this since it is lower level and performs less checks (we can just set the owner to nullptr)? If so, I think this change makes sense. But it's a bit unfortunate since the reason for using a Hotspot mutex was for the extra safety checks/features. Maybe it's also worth considering either removing the `ThreadCritical` related to NMT in arena.cpp or replacing them with `VirtualMemoryTracker::Locker` (even though they're related to malloc, not virtual memory), as per this comment https://github.com/openjdk/jdk/pull/20852#issuecomment-2450515494 ? src/hotspot/share/nmt/nmtCommon.hpp line 144: > 142: // Same as MutexLocker but can be used during VM init. > 143: // Performs no action if given a null mutex or with detached threads. > 144: class NmtVirtualMemoryLocker: public ConditionalMutexLocker { Maybe you can remove `#include "runtime/mutexLocker.hpp"` as well src/hotspot/share/runtime/mutexLocker.cpp line 296: > 294: MUTEX_DEFN(ThreadsSMRDelete_lock , PaddedMonitor, service-2); // Holds ConcurrentHashTableResize_lock > 295: MUTEX_DEFN(ThreadIdTableCreate_lock , PaddedMutex , safepoint); > 296: MUTEX_DEFN(SharedDecoder_lock , PaddedMutex , service-5); This was originally of rank `tty-1`. But it was lowered due to rank errors after replacing `ThreadCritical` with `NmtVirtualMemory_lock`. It probably makes sense to keep this lower rank now, since the actual locking locations have not changed even though `NmtVirtualMemory_lock` is removed. But maybe there should be a comment explaining that this low rank is needed for lock ordering with NMT `MemTracker::print_containing_region` ------------- PR Comment: https://git.openjdk.org/jdk/pull/21928#issuecomment-2459894337 PR Comment: https://git.openjdk.org/jdk/pull/21928#issuecomment-2459960163 PR Review Comment: https://git.openjdk.org/jdk/pull/21928#discussion_r1831150401 PR Review Comment: https://git.openjdk.org/jdk/pull/21928#discussion_r1831148321 From jsjolen at openjdk.org Wed Nov 6 15:05:49 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 6 Nov 2024 15:05:49 GMT Subject: RFR: 8343244: Aarch64: Internal Error virtualMemoryTracker.cpp:444 assert(reserved_rgn != nullptr) failed: Add committed region, No reserved region found [v2] In-Reply-To: References: Message-ID: > Hi, > > Ping @roberttoyonaga , @tstuefe , @afshin-zafari , @dholmes-ora , @gerard-ziemski > > We are seeing issues with the transition to one of our 'fat' mutexes. Specifically, we do have `os::commit_memory` that occurs during the running `Thread`'s initialization, see the following stack trace: > > > Stack: [0x0000ffff686ae000,0x0000ffff687ae000], sp=0x0000ffff687ac5f0, free space=1017k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x16aa67c] VirtualMemoryTracker::add_committed_region(unsigned char*, unsigned long, NativeCallStack const&)+0x38c (virtualMemoryTracker.cpp:444) > V [libjvm.so+0x131134c] os::commit_memory(char*, unsigned long, bool)+0x198 (memTracker.hpp:165) > V [libjvm.so+0x14ddf54] StackOverflow::create_stack_guard_pages()+0x70 (stackOverflow.cpp:97) > V [libjvm.so+0xe2e0dc] attach_current_thread.isra.0+0x11c (jni.cpp:3809) > C [libExplicitAttach.so+0xa64] thread_main+0x34 (libExplicitAttach.c:45) > C [libc.so.6+0x806b8] start_thread+0x2d8 > > > This, in turn, causes issues where the lock isn't actually taken, causing issues with the VMT. I'd like to suggest that we switch out the `Mutex` to a `PlatformMutex`. Platform mutexes are identical in construction to `ThreadCritical`, but are at least not shared globally and can be owned by the `VirtualMemoryTracker`. > > If you do not agree with this change, then I suggest that we back out [8304824](https://bugs.openjdk.org/browse/JDK-8304824) ASAP and wait for a better solution. > > Thanks. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Is void ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21928/files - new: https://git.openjdk.org/jdk/pull/21928/files/14a0dd93..4130d1b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21928&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21928&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21928.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21928/head:pull/21928 PR: https://git.openjdk.org/jdk/pull/21928 From jsjolen at openjdk.org Wed Nov 6 15:05:49 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 6 Nov 2024 15:05:49 GMT Subject: RFR: 8343244: Aarch64: Internal Error virtualMemoryTracker.cpp:444 assert(reserved_rgn != nullptr) failed: Add committed region, No reserved region found In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 14:01:43 GMT, Johan Sj?len wrote: > Hi, > > Ping @roberttoyonaga , @tstuefe , @afshin-zafari , @dholmes-ora , @gerard-ziemski > > We are seeing issues with the transition to one of our 'fat' mutexes. Specifically, we do have `os::commit_memory` that occurs during the running `Thread`'s initialization, see the following stack trace: > > > Stack: [0x0000ffff686ae000,0x0000ffff687ae000], sp=0x0000ffff687ac5f0, free space=1017k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x16aa67c] VirtualMemoryTracker::add_committed_region(unsigned char*, unsigned long, NativeCallStack const&)+0x38c (virtualMemoryTracker.cpp:444) > V [libjvm.so+0x131134c] os::commit_memory(char*, unsigned long, bool)+0x198 (memTracker.hpp:165) > V [libjvm.so+0x14ddf54] StackOverflow::create_stack_guard_pages()+0x70 (stackOverflow.cpp:97) > V [libjvm.so+0xe2e0dc] attach_current_thread.isra.0+0x11c (jni.cpp:3809) > C [libExplicitAttach.so+0xa64] thread_main+0x34 (libExplicitAttach.c:45) > C [libc.so.6+0x806b8] start_thread+0x2d8 > > > This, in turn, causes issues where the lock isn't actually taken, causing issues with the VMT. I'd like to suggest that we switch out the `Mutex` to a `PlatformMutex`. Platform mutexes are identical in construction to `ThreadCritical`, but are at least not shared globally and can be owned by the `VirtualMemoryTracker`. > > If you do not agree with this change, then I suggest that we back out [8304824](https://bugs.openjdk.org/browse/JDK-8304824) ASAP and wait for a better solution. > > Thanks. Hi Robert, I think that is best for a new PR, this is only meant as a bugfix. Unfortunately, I ran the wrong branch for my testing so I have to re-do that (hooray). ------------- PR Comment: https://git.openjdk.org/jdk/pull/21928#issuecomment-2459982944 From jsjolen at openjdk.org Wed Nov 6 15:11:14 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 6 Nov 2024 15:11:14 GMT Subject: RFR: 8343244: Aarch64: Internal Error virtualMemoryTracker.cpp:444 assert(reserved_rgn != nullptr) failed: Add committed region, No reserved region found [v3] In-Reply-To: References: Message-ID: > Hi, > > Ping @roberttoyonaga , @tstuefe , @afshin-zafari , @dholmes-ora , @gerard-ziemski > > We are seeing issues with the transition to one of our 'fat' mutexes. Specifically, we do have `os::commit_memory` that occurs during the running `Thread`'s initialization, see the following stack trace: > > > Stack: [0x0000ffff686ae000,0x0000ffff687ae000], sp=0x0000ffff687ac5f0, free space=1017k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x16aa67c] VirtualMemoryTracker::add_committed_region(unsigned char*, unsigned long, NativeCallStack const&)+0x38c (virtualMemoryTracker.cpp:444) > V [libjvm.so+0x131134c] os::commit_memory(char*, unsigned long, bool)+0x198 (memTracker.hpp:165) > V [libjvm.so+0x14ddf54] StackOverflow::create_stack_guard_pages()+0x70 (stackOverflow.cpp:97) > V [libjvm.so+0xe2e0dc] attach_current_thread.isra.0+0x11c (jni.cpp:3809) > C [libExplicitAttach.so+0xa64] thread_main+0x34 (libExplicitAttach.c:45) > C [libc.so.6+0x806b8] start_thread+0x2d8 > > > This, in turn, causes issues where the lock isn't actually taken, causing issues with the VMT. I'd like to suggest that we switch out the `Mutex` to a `PlatformMutex`. Platform mutexes are identical in construction to `ThreadCritical`, but are at least not shared globally and can be owned by the `VirtualMemoryTracker`. > > If you do not agree with this change, then I suggest that we back out [8304824](https://bugs.openjdk.org/browse/JDK-8304824) ASAP and wait for a better solution. > > Thanks. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: Translation unit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21928/files - new: https://git.openjdk.org/jdk/pull/21928/files/4130d1b2..39e28ed6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21928&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21928&range=01-02 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21928.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21928/head:pull/21928 PR: https://git.openjdk.org/jdk/pull/21928 From jsjolen at openjdk.org Wed Nov 6 15:17:35 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 6 Nov 2024 15:17:35 GMT Subject: RFR: 8343244: Aarch64: Internal Error virtualMemoryTracker.cpp:444 assert(reserved_rgn != nullptr) failed: Add committed region, No reserved region found [v3] In-Reply-To: References: Message-ID: <5tCS8yzRIwL4af0gXn2b1gfT1bvathB25Vk7DKQdcU8=.388ec2f6-420f-41fd-ac04-bb8f040563ea@github.com> On Wed, 6 Nov 2024 15:11:14 GMT, Johan Sj?len wrote: >> Hi, >> >> Ping @roberttoyonaga , @tstuefe , @afshin-zafari , @dholmes-ora , @gerard-ziemski >> >> We are seeing issues with the transition to one of our 'fat' mutexes. Specifically, we do have `os::commit_memory` that occurs during the running `Thread`'s initialization, see the following stack trace: >> >> >> Stack: [0x0000ffff686ae000,0x0000ffff687ae000], sp=0x0000ffff687ac5f0, free space=1017k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x16aa67c] VirtualMemoryTracker::add_committed_region(unsigned char*, unsigned long, NativeCallStack const&)+0x38c (virtualMemoryTracker.cpp:444) >> V [libjvm.so+0x131134c] os::commit_memory(char*, unsigned long, bool)+0x198 (memTracker.hpp:165) >> V [libjvm.so+0x14ddf54] StackOverflow::create_stack_guard_pages()+0x70 (stackOverflow.cpp:97) >> V [libjvm.so+0xe2e0dc] attach_current_thread.isra.0+0x11c (jni.cpp:3809) >> C [libExplicitAttach.so+0xa64] thread_main+0x34 (libExplicitAttach.c:45) >> C [libc.so.6+0x806b8] start_thread+0x2d8 >> >> >> This, in turn, causes issues where the lock isn't actually taken, causing issues with the VMT. I'd like to suggest that we switch out the `Mutex` to a `PlatformMutex`. Platform mutexes are identical in construction to `ThreadCritical`, but are at least not shared globally and can be owned by the `VirtualMemoryTracker`. >> >> If you do not agree with this change, then I suggest that we back out [8304824](https://bugs.openjdk.org/browse/JDK-8304824) ASAP and wait for a better solution. >> >> Thanks. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Translation unit Running Oracle CI tier1-tier5 ------------- PR Comment: https://git.openjdk.org/jdk/pull/21928#issuecomment-2460030522 From ihse at openjdk.org Wed Nov 6 15:21:10 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 6 Nov 2024 15:21:10 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Remove FIXME ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/9b10e74c..de3c773a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=30 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=29-30 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Wed Nov 6 15:21:10 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 6 Nov 2024 15:21:10 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <1C4ITw6Oql1qCggf80rAZ73NIjGNwdYQzWHUfb_8LLE=.0140fca3-d921-4ec3-bd82-1f9cf7bb0a31@github.com> On Tue, 5 Nov 2024 16:28:04 GMT, Kim Barrett wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> fix: jvm_md.h was included, but not jvm.h... > > src/hotspot/os/windows/os_windows.cpp line 5820: > >> 5818: } >> 5819: >> 5820: // FIXME > > ??? I apologize this slipped through. It was a marker for myself which I added when searching for code that did _stdcall name mangling operations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1831227000 From ihse at openjdk.org Wed Nov 6 15:29:49 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 6 Nov 2024 15:29:49 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <_8hqosvrOekf3ephURXyuAKg9hl2FRpH-tJ-y_PFE6k=.f5ab5105-b4d3-4e5a-ae7d-705838274dc1@github.com> On Tue, 5 Nov 2024 08:58:00 GMT, Kim Barrett wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> fix: jvm_md.h was included, but not jvm.h... > > src/hotspot/os/windows/os_windows.cpp line 5863: > >> 5861: return nullptr; >> 5862: } >> 5863: > > [pre-existing, and can't comment on line 5858 because it's not sufficiently near a change.] > The calculation of `len` is wasting a byte when `lib_name` is null. The `+2` accounts for the > terminating `NUL` and the underscore separator between the sym_name part and the lib_name > part. That underscore isn't added when there isn't a lib_name part. I think the simplest fix would > be to change `name_len` to `(name_len +1)` and `+2` to `+1` in that calculation. And add some > commentary. > > This might be deemed not worth fixing as there is likely often no actual wastage, due to alignment > padding, and it slightly further complicates the calculation. But additional commentary would still > be desirable, to guide the next careful reader. In which case it might be simpler to describe the > fixed version. > > Since this is pre-existing and relatively harmless in execution, it can be addressed in a followup > change. I've created https://bugs.openjdk.org/browse/JDK-8343703 for this, amongst other things. > src/hotspot/share/include/jvm.h line 1165: > >> 1163: #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} >> 1164: #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} >> 1165: #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} > > There is more cleanup that can be done here. These definitions are used as > array initializers (hence the surrounding curly braces). They are now always > singleton, rather than sometimes having 2 elements. The uses iterate over the > now always singleton arrays. Those iterations are no longer needed and could > be eliminated. And these macros could be eliminated, using the corresponding > string directly in each use. This can all be done as a followup change. Handled by https://bugs.openjdk.org/browse/JDK-8343703. > src/java.base/share/native/libjava/NativeLibraries.c line 67: > >> 65: strcat(jniEntryName, "_"); >> 66: strcat(jniEntryName, cname); >> 67: } > > I would prefer this be directly inlined at the sole call (in findJniFunction), > to make it easier to verify there aren't any buffer overrun problems. (I don't > think there are, but looking at this in isolation triggered warnings in my > head.) > > Also, it looks like all callers of findJniFunction ensure the cname argument > is non-null. So there should be no need to handle the null case in > findJniFunction (other than perhaps an assert or something). That could be > addressed in a followup. (I've already implicitly suggested elsewhere in this > PR revising this function in a followup because of the JNI_ON[UN]LOAD_SYMBOLS > thing.) @kimbarrett I added this to https://bugs.openjdk.org/browse/JDK-8343703. You are not as explicit here as the other places you commented that it is okay to do as a follow-up, but I'll assume that was what you meant. If not, let me know, and I'll look at fixing it for this PR already. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1831240264 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1831240942 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1831243370 From mbaesken at openjdk.org Wed Nov 6 15:54:22 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 6 Nov 2024 15:54:22 GMT Subject: RFR: 8342893: Highlight special values in hserr file printing [v3] In-Reply-To: References: Message-ID: > There are some special values indicating memory corruption or problematic states. Those should be highlighted / pointed out in some way when printing parts of the hserr / hsinfo file (like register values or locations), Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Introduce badResourceValueWord variable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21811/files - new: https://git.openjdk.org/jdk/pull/21811/files/2ef76ddf..1336334c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21811&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21811&range=01-02 Stats: 16 lines in 1 file changed: 5 ins; 9 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21811.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21811/head:pull/21811 PR: https://git.openjdk.org/jdk/pull/21811 From mbaesken at openjdk.org Wed Nov 6 15:57:29 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 6 Nov 2024 15:57:29 GMT Subject: RFR: 8342893: Highlight special values in hserr file printing [v2] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 03:40:48 GMT, Dean Long wrote: >> We could also put another variable centrally next to badResourceValue , see >> https://github.com/openjdk/jdk/blob/4fc6d4135e795d18a024a6035908f380b81082d1/src/hotspot/share/utilities/globalDefinitions.hpp#L1044 >> do you have a good naming for this ? Maybe `badZapValue` ? > > Maybe badResourceValueWord? But I would put it in os.cpp instead of globalDefinitions.hpp until there are other clients. Sounds good , let's use this naming ! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21811#discussion_r1831288927 From sspitsyn at openjdk.org Wed Nov 6 16:00:59 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 6 Nov 2024 16:00:59 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 09:24:03 GMT, Alan Bateman wrote: > So at some point I think we need to figure out how to make them go away ... Yes, the 2 extension events (`VirtualThreadMount` and `VirtualThreadUnmount`) were added for testing purposes. We wanted to get rid of them at some point but the Graal team was using them for some purposes. > It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor... The two extension events were designed to be posted when the current thread identity is virtual, so this behavior needs to be considered as a bug. My understanding is that it is not easy to fix. We most likely, we have no tests to fail because of this though. > That's the path a virtual thread will take if pinned. Got it, thanks. I realize it is because we do not thaw and freeze the VM frames. It is not easy to comprehend. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831293112 From jsjolen at openjdk.org Wed Nov 6 16:12:49 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 6 Nov 2024 16:12:49 GMT Subject: RFR: 8343244: Aarch64: Internal Error virtualMemoryTracker.cpp:444 assert(reserved_rgn != nullptr) failed: Add committed region, No reserved region found [v4] In-Reply-To: References: Message-ID: > Hi, > > Ping @roberttoyonaga , @tstuefe , @afshin-zafari , @dholmes-ora , @gerard-ziemski > > We are seeing issues with the transition to one of our 'fat' mutexes. Specifically, we do have `os::commit_memory` that occurs during the running `Thread`'s initialization, see the following stack trace: > > > Stack: [0x0000ffff686ae000,0x0000ffff687ae000], sp=0x0000ffff687ac5f0, free space=1017k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x16aa67c] VirtualMemoryTracker::add_committed_region(unsigned char*, unsigned long, NativeCallStack const&)+0x38c (virtualMemoryTracker.cpp:444) > V [libjvm.so+0x131134c] os::commit_memory(char*, unsigned long, bool)+0x198 (memTracker.hpp:165) > V [libjvm.so+0x14ddf54] StackOverflow::create_stack_guard_pages()+0x70 (stackOverflow.cpp:97) > V [libjvm.so+0xe2e0dc] attach_current_thread.isra.0+0x11c (jni.cpp:3809) > C [libExplicitAttach.so+0xa64] thread_main+0x34 (libExplicitAttach.c:45) > C [libc.so.6+0x806b8] start_thread+0x2d8 > > > This, in turn, causes issues where the lock isn't actually taken, causing issues with the VMT. I'd like to suggest that we switch out the `Mutex` to a `PlatformMutex`. Platform mutexes are identical in construction to `ThreadCritical`, but are at least not shared globally and can be owned by the `VirtualMemoryTracker`. > > If you do not agree with this change, then I suggest that we back out [8304824](https://bugs.openjdk.org/browse/JDK-8304824) ASAP and wait for a better solution. > > Thanks. Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: That assert is clearly incorrect ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21928/files - new: https://git.openjdk.org/jdk/pull/21928/files/39e28ed6..1f865bae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21928&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21928&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21928.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21928/head:pull/21928 PR: https://git.openjdk.org/jdk/pull/21928 From stuefe at openjdk.org Wed Nov 6 16:17:29 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 6 Nov 2024 16:17:29 GMT Subject: RFR: 8343244: Aarch64: Internal Error virtualMemoryTracker.cpp:444 assert(reserved_rgn != nullptr) failed: Add committed region, No reserved region found [v4] In-Reply-To: References: Message-ID: <65hwjJw_FIyfupp2eTzTKjY8rmry13HPpww5YNk1EmY=.de99da81-225c-47fc-be30-9c5aec907cf0@github.com> On Wed, 6 Nov 2024 16:12:49 GMT, Johan Sj?len wrote: >> Hi, >> >> Ping @roberttoyonaga , @tstuefe , @afshin-zafari , @dholmes-ora , @gerard-ziemski >> >> We are seeing issues with the transition to one of our 'fat' mutexes. Specifically, we do have `os::commit_memory` that occurs during the running `Thread`'s initialization, see the following stack trace: >> >> >> Stack: [0x0000ffff686ae000,0x0000ffff687ae000], sp=0x0000ffff687ac5f0, free space=1017k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x16aa67c] VirtualMemoryTracker::add_committed_region(unsigned char*, unsigned long, NativeCallStack const&)+0x38c (virtualMemoryTracker.cpp:444) >> V [libjvm.so+0x131134c] os::commit_memory(char*, unsigned long, bool)+0x198 (memTracker.hpp:165) >> V [libjvm.so+0x14ddf54] StackOverflow::create_stack_guard_pages()+0x70 (stackOverflow.cpp:97) >> V [libjvm.so+0xe2e0dc] attach_current_thread.isra.0+0x11c (jni.cpp:3809) >> C [libExplicitAttach.so+0xa64] thread_main+0x34 (libExplicitAttach.c:45) >> C [libc.so.6+0x806b8] start_thread+0x2d8 >> >> >> This, in turn, causes issues where the lock isn't actually taken, causing issues with the VMT. I'd like to suggest that we switch out the `Mutex` to a `PlatformMutex`. Platform mutexes are identical in construction to `ThreadCritical`, but are at least not shared globally and can be owned by the `VirtualMemoryTracker`. >> >> If you do not agree with this change, then I suggest that we back out [8304824](https://bugs.openjdk.org/browse/JDK-8304824) ASAP and wait for a better solution. >> >> Thanks. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > That assert is clearly incorrect I dont understand. Thread::current should be set before stack guards are enabled. So, whats happening here? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21928#issuecomment-2460208096 From stuefe at openjdk.org Wed Nov 6 16:29:34 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 6 Nov 2024 16:29:34 GMT Subject: RFR: 8343244: Aarch64: Internal Error virtualMemoryTracker.cpp:444 assert(reserved_rgn != nullptr) failed: Add committed region, No reserved region found [v4] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 16:12:49 GMT, Johan Sj?len wrote: >> Hi, >> >> Ping @roberttoyonaga , @tstuefe , @afshin-zafari , @dholmes-ora , @gerard-ziemski >> >> We are seeing issues with the transition to one of our 'fat' mutexes. Specifically, we do have `os::commit_memory` that occurs during the running `Thread`'s initialization, see the following stack trace: >> >> >> Stack: [0x0000ffff686ae000,0x0000ffff687ae000], sp=0x0000ffff687ac5f0, free space=1017k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x16aa67c] VirtualMemoryTracker::add_committed_region(unsigned char*, unsigned long, NativeCallStack const&)+0x38c (virtualMemoryTracker.cpp:444) >> V [libjvm.so+0x131134c] os::commit_memory(char*, unsigned long, bool)+0x198 (memTracker.hpp:165) >> V [libjvm.so+0x14ddf54] StackOverflow::create_stack_guard_pages()+0x70 (stackOverflow.cpp:97) >> V [libjvm.so+0xe2e0dc] attach_current_thread.isra.0+0x11c (jni.cpp:3809) >> C [libExplicitAttach.so+0xa64] thread_main+0x34 (libExplicitAttach.c:45) >> C [libc.so.6+0x806b8] start_thread+0x2d8 >> >> >> This, in turn, causes issues where the lock isn't actually taken, causing issues with the VMT. I'd like to suggest that we switch out the `Mutex` to a `PlatformMutex`. Platform mutexes are identical in construction to `ThreadCritical`, but are at least not shared globally and can be owned by the `VirtualMemoryTracker`. >> >> If you do not agree with this change, then I suggest that we back out [8304824](https://bugs.openjdk.org/browse/JDK-8304824) ASAP and wait for a better solution. >> >> Thanks. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > That assert is clearly incorrect I believe the problem is not in stack guard creation, but in these two lines in attach_current_thread: > thread->register_thread_stack_with_NMT(); > thread->initialize_thread_current(); They should be reversed. I would guess that would solve the problem. But for now, I would probably prefer to back out the patch and think a bit. Changing to PlatformMutex would deny us deadlock detection, right? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21928#issuecomment-2460238057 From jsjolen at openjdk.org Wed Nov 6 16:32:41 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 6 Nov 2024 16:32:41 GMT Subject: RFR: 8343244: Aarch64: Internal Error virtualMemoryTracker.cpp:444 assert(reserved_rgn != nullptr) failed: Add committed region, No reserved region found [v4] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 16:26:58 GMT, Thomas Stuefe wrote: > I believe the problem is not in stack guard creation, but in these two lines in attach_current_thread: > > > thread->register_thread_stack_with_NMT(); > > thread->initialize_thread_current(); > > They should be reversed. I would guess that would solve the problem. > > But for now, I would probably prefer to back out the patch and think a bit. Changing to PlatformMutex would deny us deadlock detection, right? That's probably it. Yeah, I'm happy to back it out for now. I'm closing this PR, getting a backout up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21928#issuecomment-2460246374 From jsjolen at openjdk.org Wed Nov 6 16:32:43 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 6 Nov 2024 16:32:43 GMT Subject: Withdrawn: 8343244: Aarch64: Internal Error virtualMemoryTracker.cpp:444 assert(reserved_rgn != nullptr) failed: Add committed region, No reserved region found In-Reply-To: References: Message-ID: <7jxJUeoKNsql7ejBsBxWfxON-EdoPCZyEd7jM5IEeKc=.545d9ae6-a5bd-4f50-9778-3d10bf1f7cdd@github.com> On Wed, 6 Nov 2024 14:01:43 GMT, Johan Sj?len wrote: > Hi, > > Ping @roberttoyonaga , @tstuefe , @afshin-zafari , @dholmes-ora , @gerard-ziemski > > We are seeing issues with the transition to one of our 'fat' mutexes. Specifically, we do have `os::commit_memory` that occurs during the running `Thread`'s initialization, see the following stack trace: > > > Stack: [0x0000ffff686ae000,0x0000ffff687ae000], sp=0x0000ffff687ac5f0, free space=1017k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x16aa67c] VirtualMemoryTracker::add_committed_region(unsigned char*, unsigned long, NativeCallStack const&)+0x38c (virtualMemoryTracker.cpp:444) > V [libjvm.so+0x131134c] os::commit_memory(char*, unsigned long, bool)+0x198 (memTracker.hpp:165) > V [libjvm.so+0x14ddf54] StackOverflow::create_stack_guard_pages()+0x70 (stackOverflow.cpp:97) > V [libjvm.so+0xe2e0dc] attach_current_thread.isra.0+0x11c (jni.cpp:3809) > C [libExplicitAttach.so+0xa64] thread_main+0x34 (libExplicitAttach.c:45) > C [libc.so.6+0x806b8] start_thread+0x2d8 > > > This, in turn, causes issues where the lock isn't actually taken, causing issues with the VMT. I'd like to suggest that we switch out the `Mutex` to a `PlatformMutex`. Platform mutexes are identical in construction to `ThreadCritical`, but are at least not shared globally and can be owned by the `VirtualMemoryTracker`. > > If you do not agree with this change, then I suggest that we back out [8304824](https://bugs.openjdk.org/browse/JDK-8304824) ASAP and wait for a better solution. > > Thanks. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/21928 From sspitsyn at openjdk.org Wed Nov 6 16:34:54 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 6 Nov 2024 16:34:54 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v29] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 23:53:04 GMT, Patricio Chilano Mateo wrote: >> Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514 >> We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior. >> Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events. > > Regarding the pop_frame/early_ret/async_exception conditions, not checking for them after we started the transition would be an issue. > For pop_frame/early_ret checks, the problem is that if any of them are installed in `JvmtiUnmountBeginMark()` while trying to start the transition, and later the call to freeze succeeds, when returning to the interpreter (monitorenter case) we will incorrectly follow the JVMTI code [1], instead of going back to `call_VM_preemptable` to clear the stack from the copied frames. As for the asynchronous exception check, if it gets installed in `JvmtiUnmountBeginMark()` while trying to start the transition, the exception would be thrown in the carrier instead, very likely while executing the unmounting logic. > When unmounting from Java, although the race is also there when starting the VTMS transition as you mentioned, I think the end result will be different. For pop_frame/early_ret we will just bail out if trying to install them since the top frame will be a native method (`notifyJvmtiUnmount`). For the async exception, we would process it on return from `notifyJvmtiUnmount` which would still be done in the context of the vthread. > > [1] https://github.com/openjdk/jdk/blob/471f112bca715d04304cbe35c6ed63df8c7b7fee/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1629 Thank you for the comment! I'm okay with your modified suggestion in general if there are no road blocks. > but does the specs say the event has to be posted in the context of the vthread? As Alan said below we do not have an official spec for this but still the events need to be posted in vthread context. > For pop_frame/early_ret checks ... The pop_frame/early_ret conditions are installed in handshakes with a context of `JvmtiVTMSTransitionDisabler`. As you noted the `JVMTI_ERROR_OPAQUE_FRAME` might be also returned by the JVMTI `FramePop` and `ForceEarlyReturn*` for some specific cases. So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help. > Maybe we could go with this simplified code now and work on it later... Whatever works better for you. An alternate approach could be to file an enhancement to simplify/refactor this. It would be nice to fix a couple of nits though: - the call to `java_lang_Thread::set_is_in_VTMS_transition()`is not needed in `JvmtiUnmountBeginMark` - the function `is_vthread_safe_to_preempt()` does not need the `vthread` parameter ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831367766 From jsjolen at openjdk.org Wed Nov 6 17:01:52 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 6 Nov 2024 17:01:52 GMT Subject: RFR: 8343726: [BACKOUT] NMT should not use ThreadCritical Message-ID: Hi, We've unfortunately seen a few bugs and crashes related to this PR, so let's back it out. Thanks. ------------- Commit messages: - Revert "8304824: NMT should not use ThreadCritical" Changes: https://git.openjdk.org/jdk/pull/21937/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21937&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343726 Stats: 62 lines in 15 files changed: 21 ins; 19 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/21937.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21937/head:pull/21937 PR: https://git.openjdk.org/jdk/pull/21937 From sparasa at openjdk.org Wed Nov 6 17:03:32 2024 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Wed, 6 Nov 2024 17:03:32 GMT Subject: RFR: 8343317: Extend test generation tool to handle APX NDD/NF flavor of instructions [v3] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 18:58:52 GMT, hanklo6 wrote: >> Extend test generation tool and gtest (added as part of https://bugs.openjdk.org/browse/JDK-8339507) to handle Intel APX NDD/NF instructions. >> >> Intel Advanced Performance Extensions (APX) adds non destructive destination (NDD) and no flags (NF) flavor for the scalar instructions through EVEX encoding. For more information about APX, see https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html. > > hanklo6 has updated the pull request incrementally with one additional commit since the last revision: > > Regenerate asmtest.out.h test/hotspot/gtest/x86/test_assemblerx86.cpp line 1: > 1: /* [Optional] In lines 53 and 58, it prints "Ours" and "Theirs". This is vague. However, it looks like this is the convention used in test_assembler_aarch64.cpp as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21795#discussion_r1831408237 From shade at openjdk.org Wed Nov 6 17:15:30 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 6 Nov 2024 17:15:30 GMT Subject: RFR: 8343726: [BACKOUT] NMT should not use ThreadCritical In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 16:39:15 GMT, Johan Sj?len wrote: > Hi, > > We've unfortunately seen a few bugs and crashes related to this PR, so let's back it out. > > Thanks. Let's do this. Thanks! ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21937#pullrequestreview-2418960141 From pchilanomate at openjdk.org Wed Nov 6 17:39:18 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:39:18 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning Message-ID: This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. In order to make the code review easier the changes have been split into the following initial 4 commits: - Changes to allow unmounting a virtual thread that is currently holding monitors. - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. - Changes to tests, JFR pinned event, and other changes in the JDK libraries. The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. ## Summary of changes ### Unmount virtual thread while holding monitors As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. #### General notes about this part: - Since virtual threads don't need to worry about holding monitors anymore, we don't need to count them, except for `LM_LEGACY`. So the majority of the platform dependent changes in this commit have to do with correcting this. - Zero and x86 (32 bits) where counting monitors even though they don't implement continuations, so I fixed that to stop counting. The idea is to remove all the counting code once we remove `LM_LEGACY`. - Macro `LOOM_MONITOR_SUPPORT` was added at the time to exclude ports that implement continuations but don't yet implement monitor support. It is removed later with the ppc commit changes. - Since now a virtual thread can be unmounted while holding monitors, JVMTI methods `GetOwnedMonitorInfo` and `GetOwnedMonitorStackDepthInfo` had to be adapted. #### Notes specific to the tid changes: - The tid is cached in the JavaThread object under `_lock_id`. It is set on JavaThread creation and changed on mount/unmount. - Changes in the ObjectMonitor class in this commit are pretty much exclusively related to changing `_owner` and `_succ` from `void*` and `JavaThread*` respectively to `int64_t`. - Although we are not trying to fix `LM_LEGACY` the tid changes apply to it as well since the inflated path is shared. Thus, in case of inflation by a contending thread, the `BasicLock*` cannot be stored in the `_owner` field as before. The `_owner` is instead set to anonymous as we do in `LM_LIGHTWEIGHT`, and the `BasicLock*` is stored in the new field `_stack_locker`. - We already assume 32 bit platforms can handle 64 bit atomics, including `cmpxchg` ([JDK-8318776](https://bugs.openjdk.org/browse/JDK-8318776)) so the shared code can stay the same. The assembly code for the c2 fast paths has to be adapted though. On arm (32bits) we already jump directly to the slow path on inflated monitor case so there is nothing to do. For x86 (32bits), since the port is moving towards deprecation ([JDK-8338285](https://bugs.openjdk.org/browse/JDK-8338285)) there is no point in trying to optimize, so the code was changed to do the same thing we do for arm (32bits). ### Unmounting a virtual thread blocked on synchronized Currently virtual thread unmounting is always started from Java, either because of a voluntarily call to `Thread.yield()` or because of performing some blocking operation such as I/O. Now we allow to unmount from inside the VM too, specifically when facing contention trying to acquire a Java monitor. On failure to acquire a monitor inside `ObjectMonitor::enter` a virtual thread will call freeze to copy all Java frames to the heap. We will add the virtual thread to the ObjectMonitor's queue and return back to Java. Instead of continue execution in Java though, the virtual thread will jump to a preempt stub which will clear the frames copied from the physical stack, and will return to `Continuation.run()` to proceed with the unmount logic. Once the owner releases the monitor and selects it as the next successor the virtual thread will be added again to the scheduler queue to run again. The virtual thread will run and attempt to acquire the monitor again. If it succeeds then it will thaw frames as usual to continue execution back were it left off. If it fails it will unmount and wait again to be unblocked. #### General notes about this part: - The easiest way to review these changes is to start from the monitorenter call in the interpreter and follow all the flow of the virtual thread, from unmounting to running again. - Currently we use a dedicated unblocker thread to submit the virtual threads back to the scheduler queue. This avoids calls to Java from monitorexit. We are experimenting on removing this limitation, but that will be left as an enhancement for a future change. - We cannot unmount the virtual thread when the monitor enter call is coming from `jni_enter()` or `ObjectLocker` since we would need to freeze native frames. - If freezing fails, which almost always will be due to having native frames on the stack, the virtual thread will follow the normal platform thread logic but will do a timed-park instead. This is to alleviate some deadlocks cases where the successor picked is an unmounted virtual thread that cannot run, which can happen during class loading or class initiatialization. - After freezing all frames, and while adding itself to the `_cxq` the virtual thread could?have successfully acquired the monitor. In that case we mark the preemption as cancelled. The virtual thread will still need to go back to the preempt stub to cleanup the physical stack but instead of unmounting it will call thaw to continue execution. - The way we jump to the preempt stub is slightly different in the compiler and interpreter. For the compiled case we just patch a return address, so no new code is added. For the interpreter we cannot do this on all platforms so we just check a flag back in the interpreter. For the latter we also need to manually restore some state after we finally acquire the monitor and resume execution. All that logic is contained in new assembler method `call_VM_preemptable()`. #### Notes specific to JVMTI changes: - Since we are not unmounting from Java, there is no call to `VirtualThread.yieldContinuation()`. This means that we have to execute the equivalent of `notifyJvmtiUnmount(/*hide*/true)` for unmount, and of `notifyJvmtiMount(/*hide*/false)` for mount in the VM. The former is implemented with `JvmtiUnmountBeginMark` in `Continuation::try_preempt()`. The latter is implemented in method `jvmti_mount_end()` in `ContinuationFreezeThaw` at the end of thaw. - When unmounting from Java the vthread unmount event is posted before we try to freeze the continuation. If that fails then we post the mount event. This all happens in `VirtualThread.yieldContinuation()`. When unmounting from the VM we only post the event once we know the freeze succeeded. Since at that point we are in the middle of the VTMS transition, posting the event is done in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()` after the transition finishes. Maybe the same thing should be done when unmounting from Java. ### Unmounting a virtual thread blocked on `Object.wait()` This commit just extends the previous mechanism to be able to unmount inside the VM on `ObjectMonitor::wait`. #### General notes about this part: - The mechanism works as before with the difference that now the call will come from the native wrapper. This requires to add support to the continuation code to handle native wrapper frames, which is a main part of the changes in this commit. - Both the compiled and interpreted native wrapper code will check for preemption on return from the wait call, after we have transitioned back to `_thread_in_Java`. #### Note specific to JVMTI changes: - If the monitor waited event is enabled we need to post it after the wait is done but before re-acquiring the monitor. Since the virtual thread is inside the VTMS transition at that point, we cannot do that directly. Currently in the code we end the transition, post the event and start the transition again. This is not ideal, and maybe we should unmount, post the event and then run again to try reacquire the monitor. ### Test changes + JFR Updates + Library code changes #### Tests - The tests in `java/lang/Thread/virtual` are updated to add more tests for monitor enter/exit and Object.wait/notify. New tests are added for JFR events, synchronized native methods, and stress testing for several scenarios. - `test/hotspot/gtest/nmt/test_vmatree.cpp` is changed due to an alias that conflicts. - A small number of tests, e.g.` test/hotspot/jtreg/serviceability/sa/ClhsdbInspect.java` and `test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002`, are updated so they are in sync with the JDK code. - A number of JVMTI tests are updated to fix various issues, e.g. some tests saved a JNIEnv in a static. #### Diagnosing remaining pinning issues - The diagnostic option `jdk.tracePinnedThreads` is removed. - The JFR `jdk.VirtualThreadPinned` event is changed so that it's now recorded in the VM, and for the following cases: parking when pinned, blocking in monitor enter when pinned, Object.wait when pinned, and waiting for a class to be initialized by another thread. The changes to object monitors should mean that only a few events are recorded. Future work may change this to a sampling approach. #### Other changes to VirtualThread class The VirtualThread implementation includes a few robustness changes. The `park/parkNanos` methods now park on the carrier if the freeze throws OOME. Moreover, the use of transitions is reduced so that the call out to the scheduler no longer requires a temporary transition. #### Other changes to libraries: - `ReferenceQueue` is reverted to use `synchronized`, the subclass based on `ReentrantLock` is removed. This change is done now because the changes for object monitors impact this area when there is preemption polling a reference queue. - `java.io` is reverted to use `synchronized`. This change has been important for testing virtual threads. There will be follow-up cleanup in main-line after the JEP is integrated to remove `InternalLock` and its uses in `java.io`. - The epoll and kqueue based Selectors are changed to preempt when doing blocking selects. This has been useful for testing virtual threads with some libraries, e.g. JDBC drivers. We could potentially separate this update if needed but it has been included in all testing and EA builds. - `sun.security.ssl.X509TrustManagerImpl` is changed to eagerly initialize AnchorCertificates, a forced change due to deadlocks in this code when testing. ## Testing The changes have been running in the Loom pipeline for several months now. They have also been included in EA builds throughout the year at different stages (EA builds from earlier this year did not had Object.wait() support yet but more recent ones did) so there has been some external exposure too. The current patch has been run through mach5 tiers 1-8. I'll keep running tests periodically until integration time. ------------- Commit messages: - Use is_top_frame boolean in FreezeBase::check_valid_fast_path() - Move load of _lock_id in C2_MacroAssembler::fast_lock - Add --enable-native-access=ALL-UNNAMED to SynchronizedNative.java - Update comment for _cont_fastpath - Add ReflectionCallerCacheTest.java to test/jdk/ProblemList-Xcomp.txt - Use ThreadIdentifier::initial() in ObjectMonitor::owner_from() - Fixes to JFR metadata.xml - Fix return miss prediction in generate_native_entry for riscv - Fix s390x failures - Add oopDesc::has_klass_gap() check - ... and 70 more: https://git.openjdk.org/jdk/compare/751a914b...211c6c81 Changes: https://git.openjdk.org/jdk/pull/21565/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338383 Stats: 9914 lines in 246 files changed: 7105 ins; 1629 del; 1180 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From aboldtch at openjdk.org Wed Nov 6 17:39:21 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 6 Nov 2024 17:39:21 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... I've done an initial look through of the hotspot changes. In addition to my comments, I have looked at two more things. One is to remove the _waiters reference counter from deflation and only use the _contentions reference counter. As well as tying the _contentions reference counter to the ObjectWaiter, so that it is easier to follow its lifetime, instead of these naked add_to_contentions, now that the ObjectWaiter does not have a straight forward scope, but can be frozen, and thawed on different threads. 46dacdf96999154e808d21e80b4d4e87f73bc802 Then I looked at typing up the thread / lock ids as an enum class 34221f4a50a492cad4785cfcbb4bef8fa51d6f23 Either of these could be future RFEs. Good work! I'll approve the GC related changes. There are some simplifications I think can be done in the ObjectMonitor layer, but nothing that should go into this PR. Similarly, (even if some of this is preexisting issues) I think that the way we describe the frames and the different frame transitions should be overhauled and made easier to understand. There are so many unnamed constants and adjustments which are spread out everywhere, which makes it hard to get an overview of exactly what happens and what interactions are related to what. You and Dean did a good job at simplifying and adding comments in this PR. But I hope this can be improved in the fututre. A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this. // the sp of the oldest known interpreted/call_stub frame inside the // continuation that we know about src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 231: > 229: > 230: StubFrame::~StubFrame() { > 231: __ epilogue(_use_pop_on_epilogue); Can we not hook the `_use_pop_on_epilogue` into `return_state_t`, simplify the constructors and keep the old should_not_reach_here guard for stubs which should not return? e.g. ```C++ enum return_state_t { does_not_return, requires_return, requires_pop_epilogue_return }; StubFrame::~StubFrame() { if (_return_state == does_not_return) { __ should_not_reach_here(); } else { __ epilogue(_return_state == requires_pop_epilogue_return); } } src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 115: > 113: // The object's monitor m is unlocked iff m->owner == nullptr, > 114: // otherwise m->owner may contain a thread id, a stack address for LM_LEGACY, > 115: // or the ANONYMOUS_OWNER constant for LM_LIGHTWEIGHT. Comment seems out of place in `LockingMode != LM_LIGHTWEIGHT` code. src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 380: > 378: lea(t2_owner_addr, owner_address); > 379: > 380: // CAS owner (null => current thread id). I think we should be more careful when and where we talk about thread id and lock id respectively. Given that `switchToCarrierThread` switches the thread, but not the lock id. We should probably define and talk about the lock id when it comes to locking, as saying thread id may be incorrect. Then there is also the different thread ids, the OS level one, and the java level one. (But not sure how to reconcile this without causing confusion) src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 300: > 298: CodeBlob* cb = top.cb(); > 299: > 300: if (cb->frame_size() == 2) { Is this a filter to identify c2 runtime stubs? Is there some other property we can check or assert here? This assumes that no other runtime frame will have this size. src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 313: > 311: > 312: log_develop_trace(continuations, preempt)("adjusted sp for c2 runtime stub, initial sp: " INTPTR_FORMAT " final sp: " INTPTR_FORMAT > 313: " fp: " INTPTR_FORMAT, p2i(sp + frame::metadata_words), p2i(sp), sp[-2]); Is there a reason for the mix of `2` and `frame::metadata_words`? Maybe this could be ```C++ intptr_t* const unadjusted_sp = sp; sp -= frame::metadata_words; sp[-2] = unadjusted_sp[-2]; sp[-1] = unadjusted_sp[-1]; log_develop_trace(continuations, preempt)("adjusted sp for c2 runtime stub, initial sp: " INTPTR_FORMAT " final sp: " INTPTR_FORMAT " fp: " INTPTR_FORMAT, p2i(unadjusted_sp), p2i(sp), sp[-2]); src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 1275: > 1273: void SharedRuntime::continuation_enter_cleanup(MacroAssembler* masm) { > 1274: ::continuation_enter_cleanup(masm); > 1275: } Now that `continuation_enter_cleanup` is a static member function, just merge the static free function with this static member function. src/hotspot/cpu/x86/assembler_x86.cpp line 2866: > 2864: emit_int32(0); > 2865: } > 2866: } Is it possible to make this more general and explicit instead of a sequence of bytes? Something along the lines of: ```C++ const address tar = L.is_bound() ? target(L) : pc(); const Address adr = Address(checked_cast(tar - pc()), tar, relocInfo::none); InstructionMark im(this); emit_prefix_and_int8(get_prefixq(adr, dst), (unsigned char)0x8D); if (!L.is_bound()) { // Patch @0x8D opcode L.add_patch_at(code(), CodeBuffer::locator(offset() - 1, sect())); } // Register and [rip+disp] operand emit_modrm(0b00, raw_encode(dst), 0b101); // Adjust displacement by sizeof lea instruction int32_t disp = adr.disp() - checked_cast(pc() - inst_mark() + sizeof(int32_t)); assert(is_simm32(disp), "must be 32bit offset [rip+offset]"); emit_int32(disp); and then in `pd_patch_instruction` simply match `op == 0x8D /* lea */`. src/hotspot/share/oops/stackChunkOop.cpp line 445: > 443: > 444: void stackChunkOopDesc::transfer_lockstack(oop* dst) { > 445: const bool requires_gc_barriers = is_gc_mode() || requires_barriers(); Given how careful we are in `Thaw` to not call `requires_barriers()` twice and use `_barriers` instead it would probably be nicer to pass in `_barriers` as a bool. There is only one other place we do the extra call and it is in `fix_thawed_frame`, but that only happens after we are committed to the slow path, so it might be nice for completeness, but should be negligible for performance. Here however we might still be in our new "medium" path where we could still do a fast thaw. src/hotspot/share/oops/stackChunkOop.cpp line 460: > 458: } else { > 459: oop value = *reinterpret_cast(at); > 460: HeapAccess<>::oop_store(reinterpret_cast(at), nullptr); Using HeapAccess when `!requires_gc_barriers` is wrong. This would crash with ZGC when/if we fix the flags race and changed `relativize_chunk_concurrently` to only be conditioned `requires_barriers() / _barriers` (and allowing the retry_fast_path "medium" path). So either use `*reinterpret_cast(at) = nullptr;` or do what my initial suggestion with `clear_lockstack` did, just omit the clearing. Before we requires_barriers(), we are allowed to reuse the stackChuncks, so trying to clean them up seems fruitless. src/hotspot/share/oops/stackChunkOop.cpp line 471: > 469: } > 470: } > 471: } Can we turn these three very similar loops into one? In my opinion, it is easier to parse. ```C++ void stackChunkOopDesc::copy_lockstack(oop* dst) { const int cnt = lockstack_size(); const bool requires_gc_barriers = is_gc_mode() || requires_barriers(); const bool requires_uncompress = requires_gc_barriers && has_bitmap() && UseCompressedOops; const auto get_obj = [&](intptr_t* at) -> oop { if (requires_gc_barriers) { if (requires_uncompress) { return HeapAccess<>::oop_load(reinterpret_cast(at)); } return HeapAccess<>::oop_load(reinterpret_cast(at)); } return *reinterpret_cast(at); }; intptr_t* lockstack_start = start_address(); for (int i = 0; i < cnt; i++) { oop mon_owner = get_obj(&lockstack_start[i]); assert(oopDesc::is_oop(mon_owner), "not an oop"); dst[i] = mon_owner; } } src/hotspot/share/prims/jvmtiExport.cpp line 1681: > 1679: EVT_TRIG_TRACE(EXT_EVENT_VIRTUAL_THREAD_UNMOUNT, ("[%p] Trg Virtual Thread Unmount event triggered", vthread)); > 1680: > 1681: // On preemption JVMTI state rebinding has already happened so get it always direclty from the oop. Suggestion: // On preemption JVMTI state rebinding has already happened so get it always directly from the oop. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2234: > 2232: retry_fast_path = true; > 2233: } else { > 2234: relativize_chunk_concurrently(chunk); Is the `relativize_chunk_concurrently` solution to the race only to have a single flag read in `can_thaw_fast` or is there some other subtlety here? While not required for the PR, if it is just to optimise the `can_thaw_fast` check, it can probably be made to work with one load and still allow concurrent gcs do fast_thaw when we only get here due to a lockstack. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2247: > 2245: _thread->lock_stack().move_from_address(tmp_lockstack, lockStackSize); > 2246: > 2247: chunk->set_lockstack_size(0); After some discussion here at the office we think there might be an issue here with simply hiding the oops without clearing them. Below in `recurse_thaw` we `do_barriers`. But it does not touch these lockstack. Missing the SATB store barrier is probably fine from a liveness perspective, because the oops in the lockstack must also be in the frames. But removing the oops without a barrier and clear will probably lead to problems down the line. Something like the following would probably handle this. Or even fuse the `copy_lockstack` and `clear_lockstack` together into some kind of `transfer_lockstack` which both loads and clears the oops. diff --git a/src/hotspot/share/oops/stackChunkOop.cpp b/src/hotspot/share/oops/stackChunkOop.cpp index d3d63533eed..f737bd2db71 100644 --- a/src/hotspot/share/oops/stackChunkOop.cpp +++ b/src/hotspot/share/oops/stackChunkOop.cpp @@ -470,6 +470,28 @@ void stackChunkOopDesc::copy_lockstack(oop* dst) { } } +void stackChunkOopDesc::clear_lockstack() { + const int cnt = lockstack_size(); + const bool requires_gc_barriers = is_gc_mode() || requires_barriers(); + const bool requires_uncompress = has_bitmap() && UseCompressedOops; + const auto clear_obj = [&](intptr_t* at) { + if (requires_uncompress) { + HeapAccess<>::oop_store(reinterpret_cast(at), nullptr); + } else { + HeapAccess<>::oop_store(reinterpret_cast(at), nullptr); + } + }; + + if (requires_gc_barriers) { + intptr_t* lockstack_start = start_address(); + for (int i = 0; i < cnt; i++) { + clear_obj(&lockstack_start[i]); + } + } + set_lockstack_size(0); + set_has_lockstack(false); +} + void stackChunkOopDesc::print_on(bool verbose, outputStream* st) const { if (*((juint*)this) == badHeapWordVal) { st->print_cr("BAD WORD"); diff --git a/src/hotspot/share/oops/stackChunkOop.hpp b/src/hotspot/share/oops/stackChunkOop.hpp index 28e0576801e..928e94dd695 100644 --- a/src/hotspot/share/oops/stackChunkOop.hpp +++ b/src/hotspot/share/oops/stackChunkOop.hpp @@ -167,6 +167,7 @@ class stackChunkOopDesc : public instanceOopDesc { void fix_thawed_frame(const frame& f, const RegisterMapT* map); void copy_lockstack(oop* start); + void clear_lockstack(); template inline void iterate_lockstack(StackChunkLockStackClosureType* closure); diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp index 5b6e48a02f3..e7d505bb9b1 100644 --- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp +++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp @@ -2244,8 +2244,7 @@ NOINLINE intptr_t* Thaw::thaw_slow(stackChunkOop chunk, Continuation::t chunk->copy_lockstack(tmp_lockstack); _thread->lock_stack().move_from_address(tmp_lockstack, lockStackSize); - chunk->set_lockstack_size(0); - chunk->set_has_lockstack(false); + chunk->clear_lockstack(); retry_fast_path = true; } ``` src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2538: > 2536: Method* m = hf.interpreter_frame_method(); > 2537: // For native frames we need to count parameters, possible alignment, plus the 2 extra words (temp oop/result handler). > 2538: const int locals = !m->is_native() ? m->max_locals() : m->size_of_parameters() + frame::align_wiggle + 2; Is it possible to have these extra native frame slots size be a named constant / enum value on `frame`? I think it is used in a couple of places. src/hotspot/share/runtime/frame.cpp line 535: > 533: assert(get_register_address_in_stub(f, SharedRuntime::thread_register()) == (address)thread_addr, "wrong thread address"); > 534: return thread_addr; > 535: #endif With this ifdef, it seems like this belongs in the platform dependent part of the frame class. src/hotspot/share/runtime/javaThread.cpp line 1545: > 1543: if (is_vthread_mounted()) { > 1544: // _lock_id is the thread ID of the mounted virtual thread > 1545: st->print_cr(" Carrying virtual thread #" INT64_FORMAT, lock_id()); What is the interaction here with `switchToCarrierThread` and the window between? carrier.setCurrentThread(carrier); Thread.setCurrentLockId(this.threadId()); Will we print the carrier threads id as a virtual threads id? (I am guessing that is_vthread_mounted is true when switchToCarrierThread is called). src/hotspot/share/runtime/objectMonitor.hpp line 184: > 182: // - We test for anonymous owner by testing for the lowest bit, therefore > 183: // DEFLATER_MARKER must *not* have that bit set. > 184: static const int64_t DEFLATER_MARKER = 2; The comments here should be updated / removed. They are talking about the lower bits of the owner being unset which is no longer true. (And talks about doing bit tests, which I do not think is done anywhere even without this patch). src/hotspot/share/runtime/objectMonitor.hpp line 186: > 184: static const int64_t DEFLATER_MARKER = 2; > 185: > 186: int64_t volatile _owner; // Either tid of owner, ANONYMOUS_OWNER_MARKER or DEFLATER_MARKER. Suggestion: int64_t volatile _owner; // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER. src/hotspot/share/runtime/objectMonitor.inline.hpp line 50: > 48: inline int64_t ObjectMonitor::owner_from(oop vthread) { > 49: int64_t tid = java_lang_Thread::thread_id(vthread); > 50: assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable"); Suggestion: assert(tid >= ThreadIdentifier::initial() && tid < ThreadIdentifier::current(), "must be reasonable"); src/hotspot/share/runtime/synchronizer.cpp line 1467: > 1465: markWord dmw = inf->header(); > 1466: assert(dmw.is_neutral(), "invariant: header=" INTPTR_FORMAT, dmw.value()); > 1467: if (inf->is_owner_anonymous() && inflating_thread != nullptr) { Are these `LM_LEGACY` + `ANONYMOUS_OWNER` changes still required now that `LM_LEGACY` does no freeze? src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62: > 60: NATIVE(2, "Native frame or on stack"), > 61: MONITOR(3, "Monitor held"), > 62: CRITICAL_SECTION(4, "In critical section"); Is there a reason that the `reasonCode` values does not match the `freeze_result` reason values used in `pinnedReason(int reason)` to create one of these? I cannot see that it is used either. Only seem to be read for JFR VirtualThreadPinned Event which only uses the string. ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2381051930 Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2417363171 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808181783 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808189977 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808208652 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808282892 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808261926 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808318304 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808358874 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825949756 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825942254 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808706427 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808809374 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810772765 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810764911 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808460330 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809032469 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809065834 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809091338 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809092367 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829464866 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809111830 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827276764 From dholmes at openjdk.org Wed Nov 6 17:39:47 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:39:47 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... First, congratulations on an exceptional piece of work @pchilano . Also thank you for the very clear breakdown and description in the PR as that helps immensely with trying to digest a change of this size. The overall operational behaviour of this change seems very solid. My only concern is whether the unparker thread may become a bottleneck in some scenarios, but that is a bridge we will have to cross if we come to it. My initial comments mainly come from just trying to understand the top-level changes around the use of the thread-id as the monitor owner. I have a number of suggestions on naming (mainly `is_x` versus `has_x`) and on documenting the API methods more clearly. None of which are showstoppers and some of which pre-exist. Unfortunately though you will need to fix the spelling of `succesor`. Thanks Thanks for those updates. Thanks for updates. (I need to add a Review comment so I get a checkpoint to track further updates.) Next batch of comments ... Updates look good - thanks. I think I have nothing further in terms of the review process. Great work! Marked as reviewed by dholmes (Reviewer). Marked as reviewed by dholmes (Reviewer). > The tid is cached in the JavaThread object under _lock_id. It is set on JavaThread creation and changed on mount/unmount. Why do we need to cache it? Is it the implicit barriers related to accessing the `threadObj` oop each time? Keeping this value up-to-date is a part I find quite confusing. src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2382: > 2380: __ bind(after_transition); > 2381: > 2382: if (LockingMode != LM_LEGACY && method->is_object_wait0()) { It bothers me that we have to add a check for a specific native method in this code (notwithstanding there are already some checks in relation to hashCode). As a follow up I wonder if we can deal with wait-preemption by rewriting the Java code, instead of special casing the wait0 native code? src/hotspot/share/classfile/javaClasses.cpp line 2082: > 2080: } > 2081: > 2082: bool java_lang_VirtualThread::set_onWaitingList(oop vthread, OopHandle& list_head) { Some comments here about the operation would be useful. The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right? I'm struggling to understand how a thread can already be on this list? src/hotspot/share/classfile/javaClasses.cpp line 2086: > 2084: jboolean vthread_on_list = Atomic::load(addr); > 2085: if (!vthread_on_list) { > 2086: vthread_on_list = Atomic::cmpxchg(addr, (jboolean)JNI_FALSE, (jboolean)JNI_TRUE); It is not clear who the racing participants are here. How can the same thread be being placed on the list from two different actions? src/hotspot/share/classfile/javaClasses.cpp line 2107: > 2105: > 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) { > 2107: return vthread->long_field(_timeout_offset); Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ?? src/hotspot/share/code/nmethod.cpp line 711: > 709: // handle the case of an anchor explicitly set in continuation code that doesn't have a callee > 710: JavaThread* thread = reg_map->thread(); > 711: if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) { Suggestion: if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) { src/hotspot/share/prims/jvm.cpp line 4012: > 4010: } > 4011: ThreadBlockInVM tbivm(THREAD); > 4012: parkEvent->park(); What code does the unpark to wake this thread up? I can't quite see how this unparker thread operates as its logic seems dispersed. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889: > 887: return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller); > 888: } else { > 889: // frame can't be freezed. Most likely the call_stub or upcall_stub Suggestion: // Frame can't be frozen. Most likely the call_stub or upcall_stub src/hotspot/share/runtime/javaThread.hpp line 165: > 163: // ID used as owner for inflated monitors. Same as the j.l.Thread.tid of the > 164: // current _vthread object, except during creation of the primordial and JNI > 165: // attached thread cases where this field can have a temporal value. Suggestion: // attached thread cases where this field can have a temporary value. Presumably this is for when the attaching thread is executing the Thread constructor? src/hotspot/share/runtime/javaThread.hpp line 166: > 164: // current _vthread object, except during creation of the primordial and JNI > 165: // attached thread cases where this field can have a temporary value. Also, > 166: // calls to VirtualThread.switchToCarrierThread will temporary change _vthread s/temporary change/temporarily change/ src/hotspot/share/runtime/objectMonitor.cpp line 132: > 130: > 131: // ----------------------------------------------------------------------------- > 132: // Theory of operations -- Monitors lists, thread residency, etc: This comment block needs updating now owner is not a JavaThread*, and to account for vthread usage src/hotspot/share/runtime/objectMonitor.cpp line 1140: > 1138: } > 1139: > 1140: bool ObjectMonitor::resume_operation(JavaThread* current, ObjectWaiter* node, ContinuationWrapper& cont) { Explanatory comment would be good - thanks. src/hotspot/share/runtime/objectMonitor.cpp line 1532: > 1530: } else if (java_lang_VirtualThread::set_onWaitingList(vthread, vthread_cxq_head())) { > 1531: // Virtual thread case. > 1532: Trigger->unpark(); So ignoring for the moment that I can't see how `set_onWaitingList` could return false here, the check is just an optimisation to reduce the number of unparks issued i.e. only unpark if the list has changed? src/hotspot/share/runtime/objectMonitor.cpp line 1673: > 1671: > 1672: ContinuationEntry* ce = current->last_continuation(); > 1673: if (interruptible && ce != nullptr && ce->is_virtual_thread()) { So IIUC this use of `interruptible` would be explained as follows: // Some calls to wait() occur in contexts that still have to pin a vthread to its carrier. // All such contexts perform non-interruptible waits, so by checking `interruptible` we know // this is a regular Object.wait call. src/hotspot/share/runtime/objectMonitor.cpp line 1706: > 1704: // on _WaitSetLock so it's not profitable to reduce the length of the > 1705: // critical section. > 1706: Please restore the blank line, else it looks like the comment block pertains to the `wait_reenter_begin`, but it doesn't. src/hotspot/share/runtime/objectMonitor.cpp line 2028: > 2026: // First time we run after being preempted on Object.wait(). > 2027: // Check if we were interrupted or the wait timed-out, and in > 2028: // that case remove ourselves from the _WaitSet queue. I'm not sure how to interpret this comment block - is this really two sentences because the first is not actually a sentence. Also unclear what "run" and "First time" relate to. src/hotspot/share/runtime/objectMonitor.cpp line 2054: > 2052: // Mark that we are at reenter so that we don't call this method again. > 2053: node->_at_reenter = true; > 2054: assert(!has_owner(current), "invariant"); The position of this assert seems odd as it seems to be something that should hold at entry to this method. src/hotspot/share/runtime/objectMonitor.hpp line 47: > 45: // ParkEvent instead. Beware, however, that the JVMTI code > 46: // knows about ObjectWaiters, so we'll have to reconcile that code. > 47: // See next_waiter(), first_waiter(), etc. This to-do is likely no longer relevant with the current changes. src/hotspot/share/runtime/objectMonitor.hpp line 174: > 172: > 173: int64_t volatile _owner; // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER. > 174: volatile uint64_t _previous_owner_tid; // thread id of the previous owner of the monitor Looks odd to have the current owner as `int64_t` but we save the previous owner as `uint64_t`. ?? src/hotspot/share/runtime/objectMonitor.hpp line 207: > 205: > 206: static void Initialize(); > 207: static void Initialize2(); Please add comment why this needs to be deferred - and till after what? src/hotspot/share/runtime/objectMonitor.hpp line 288: > 286: // Returns true if this OM has an owner, false otherwise. > 287: bool has_owner() const; > 288: int64_t owner() const; // Returns null if DEFLATER_MARKER is observed. null is not an int64_t value. src/hotspot/share/runtime/objectMonitor.hpp line 292: > 290: > 291: static int64_t owner_for(JavaThread* thread); > 292: static int64_t owner_for_oop(oop vthread); Some comments describing this API would be good. I'm struggling a bit with the "owner for" terminology. I think `owner_from` would be better. And can't these just overload rather than using different names? src/hotspot/share/runtime/objectMonitor.hpp line 299: > 297: // Simply set _owner field to new_value; current value must match old_value. > 298: void set_owner_from_raw(int64_t old_value, int64_t new_value); > 299: // Same as above but uses tid of current as new value. By `tid` here (and elsewhere) you actually mean `thread->threadObj()->thread_id()` - right? src/hotspot/share/runtime/objectMonitor.hpp line 302: > 300: // Simply set _owner field to new_value; current value must match old_value. > 301: void set_owner_from_raw(int64_t old_value, int64_t new_value); > 302: void set_owner_from(int64_t old_value, JavaThread* current); Again some comments describing API would good. The old API had vague names like old_value and new_value because of the different forms the owner value could take. Now it is always a thread-id we can do better I think. The distinction between the raw and non-raw forms is unclear and the latter is not covered by the initial comment. src/hotspot/share/runtime/objectMonitor.hpp line 302: > 300: void set_owner_from(int64_t old_value, JavaThread* current); > 301: // Set _owner field to tid of current thread; current value must be ANONYMOUS_OWNER. > 302: void set_owner_from_BasicLock(JavaThread* current); Shouldn't tid there be the basicLock? src/hotspot/share/runtime/objectMonitor.hpp line 303: > 301: void set_owner_from_raw(int64_t old_value, int64_t new_value); > 302: void set_owner_from(int64_t old_value, JavaThread* current); > 303: // Simply set _owner field to current; current value must match basic_lock_p. Comment is no longer accurate src/hotspot/share/runtime/objectMonitor.hpp line 309: > 307: // _owner field. Returns the prior value of the _owner field. > 308: int64_t try_set_owner_from_raw(int64_t old_value, int64_t new_value); > 309: int64_t try_set_owner_from(int64_t old_value, JavaThread* current); Similar to set_owner* need better comments describing API. src/hotspot/share/runtime/objectMonitor.hpp line 311: > 309: int64_t try_set_owner_from(int64_t old_value, JavaThread* current); > 310: > 311: bool is_succesor(JavaThread* thread); I think `has_successor` is more appropriate here as it is not the monitor that is the successor. src/hotspot/share/runtime/objectMonitor.hpp line 312: > 310: void set_successor(JavaThread* thread); > 311: void set_successor(oop vthread); > 312: void clear_successor(); Needs descriptive comments, or at least a preceding comment explaining what a "successor" is. src/hotspot/share/runtime/objectMonitor.hpp line 315: > 313: void set_succesor(oop vthread); > 314: void clear_succesor(); > 315: bool has_succesor(); Sorry but `successor` has two `s` before `or`. src/hotspot/share/runtime/objectMonitor.hpp line 317: > 315: bool has_succesor(); > 316: > 317: bool is_owner(JavaThread* thread) const { return owner() == owner_for(thread); } Again `has_owner` seems more appropriate src/hotspot/share/runtime/objectMonitor.hpp line 323: > 321: } > 322: > 323: bool is_owner_anonymous() const { return owner_raw() == ANONYMOUS_OWNER; } Again I struggle with the pre-existing `is_owner` formulation here. The target of the expression is a monitor and we are asking if the monitor has an anonymous owner. src/hotspot/share/runtime/objectMonitor.hpp line 333: > 331: bool is_stack_locker(JavaThread* current); > 332: BasicLock* stack_locker() const; > 333: void set_stack_locker(BasicLock* locker); Again `is` versus `has`, plus some general comments describing the API. src/hotspot/share/runtime/objectMonitor.hpp line 334: > 332: > 333: // Returns true if BasicLock* stored in _stack_locker > 334: // points to current's stack, false othwerwise. Suggestion: // points to current's stack, false otherwise. src/hotspot/share/runtime/objectMonitor.hpp line 349: > 347: ObjectWaiter* first_waiter() { return _WaitSet; } > 348: ObjectWaiter* next_waiter(ObjectWaiter* o) { return o->_next; } > 349: JavaThread* thread_of_waiter(ObjectWaiter* o) { return o->_thread; } This no longer looks correct if the waiter is a vthread. ?? src/hotspot/share/runtime/objectMonitor.inline.hpp line 110: > 108: } > 109: > 110: // Returns null if DEFLATER_MARKER is observed. Comment needs updating src/hotspot/share/runtime/objectMonitor.inline.hpp line 130: > 128: // Returns true if owner field == DEFLATER_MARKER and false otherwise. > 129: // This accessor is called when we really need to know if the owner > 130: // field == DEFLATER_MARKER and any non-null value won't do the trick. Comment needs updating src/hotspot/share/runtime/synchronizer.cpp line 670: > 668: // Top native frames in the stack will not be seen if we attempt > 669: // preemption, since we start walking from the last Java anchor. > 670: NoPreemptMark npm(current); Don't we still pin for JNI monitor usage? src/hotspot/share/runtime/synchronizer.cpp line 1440: > 1438: } > 1439: > 1440: ObjectMonitor* ObjectSynchronizer::inflate_impl(JavaThread* inflating_thread, oop object, const InflateCause cause) { `inflating_thread` doesn't sound right as it is always the current thread that is doing the inflating. The passed in thread may be a different thread trying to acquire the monitor ... perhaps `contending_thread`? src/hotspot/share/runtime/synchronizer.hpp line 172: > 170: > 171: // Iterate ObjectMonitors where the owner is thread; this does NOT include > 172: // ObjectMonitors where owner is set to a stack lock address in thread. Comment needs updating src/hotspot/share/runtime/threadIdentifier.cpp line 30: > 28: > 29: // starting at 3, excluding reserved values defined in ObjectMonitor.hpp > 30: static const int64_t INITIAL_TID = 3; Can we express this in terms of those reserved values, or are they inaccessible? src/hotspot/share/services/threadService.cpp line 467: > 465: if (waitingToLockMonitor->has_owner()) { > 466: currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor); > 467: // If currentThread is nullptr we would like to know if the owner Suggestion: // If currentThread is null we would like to know if the owner src/hotspot/share/services/threadService.cpp line 474: > 472: // vthread we never record this as a deadlock. Note: unless there > 473: // is a bug in the VM, or a thread exits without releasing monitors > 474: // acquired through JNI, nullptr should imply unmounted vthread owner. Suggestion: // acquired through JNI, null should imply an unmounted vthread owner. src/java.base/share/classes/java/lang/Object.java line 383: > 381: try { > 382: wait0(timeoutMillis); > 383: } catch (InterruptedException e) { I had expected to see a call to a new `wait0` method that returned a value indicating whether the wait was completed or else we had to park. Instead we had to put special logic in the native-call-wrapper code in the VM to detect returning from wait0 and changing the return address. I'm still unclear where that modified return address actually takes us. src/java.base/share/classes/java/lang/Thread.java line 654: > 652: * {@link Thread#PRIMORDIAL_TID} +1 as this class cannot be used during > 653: * early startup to generate the identifier for the primordial thread. The > 654: * counter is off-heap and shared with the VM to allow it assign thread Suggestion: * counter is off-heap and shared with the VM to allow it to assign thread src/java.base/share/classes/java/lang/Thread.java line 655: > 653: * early startup to generate the identifier for the primordial thread. The > 654: * counter is off-heap and shared with the VM to allow it assign thread > 655: * identifiers to non-Java threads. Why do non-JavaThreads need an identifier of this kind? src/java.base/share/classes/java/lang/Thread.java line 731: > 729: > 730: if (attached && VM.initLevel() < 1) { > 731: this.tid = 3; // primordial thread The comment before the `ThreadIdentifiers` class needs updating to account for this change. src/java.base/share/classes/java/lang/VirtualThread.java line 109: > 107: * > 108: * RUNNING -> BLOCKING // blocking on monitor enter > 109: * BLOCKING -> BLOCKED // blocked on monitor enter Should this say something similar to the parked case, about the "yield" being successful? src/java.base/share/classes/java/lang/VirtualThread.java line 110: > 108: * RUNNING -> BLOCKING // blocking on monitor enter > 109: * BLOCKING -> BLOCKED // blocked on monitor enter > 110: * BLOCKED -> UNBLOCKED // unblocked, may be scheduled to continue Does this mean it now owns the monitor, or just it is able to re-contest for monitor entry? src/java.base/share/classes/java/lang/VirtualThread.java line 111: > 109: * BLOCKING -> BLOCKED // blocked on monitor enter > 110: * BLOCKED -> UNBLOCKED // unblocked, may be scheduled to continue > 111: * UNBLOCKED -> RUNNING // continue execution after blocked on monitor enter Presumably this one means it acquired the monitor? src/java.base/share/classes/java/lang/VirtualThread.java line 115: > 113: * RUNNING -> WAITING // transitional state during wait on monitor > 114: * WAITING -> WAITED // waiting on monitor > 115: * WAITED -> BLOCKED // notified, waiting to be unblocked by monitor owner Waiting to re-enter the monitor? src/java.base/share/classes/java/lang/VirtualThread.java line 178: > 176: // timed-wait support > 177: private long waitTimeout; > 178: private byte timedWaitNonce; Strange name - what does this mean? src/java.base/share/classes/java/lang/VirtualThread.java line 530: > 528: && carrier == Thread.currentCarrierThread(); > 529: carrier.setCurrentThread(carrier); > 530: Thread.setCurrentLockId(this.threadId()); // keep lock ID of virtual thread I'm struggling to understand the different threads in play when this is called and what the method actual does to which threads. ?? src/java.base/share/classes/java/lang/VirtualThread.java line 631: > 629: // Object.wait > 630: if (s == WAITING || s == TIMED_WAITING) { > 631: byte nonce; Suggestion: byte seqNo; src/java.base/share/classes/java/lang/VirtualThread.java line 948: > 946: * This method does nothing if the thread has been woken by notify or interrupt. > 947: */ > 948: private void waitTimeoutExpired(byte nounce) { I assume you meant `nonce` here, but please change to `seqNo`. src/java.base/share/classes/java/lang/VirtualThread.java line 952: > 950: for (;;) { > 951: boolean unblocked = false; > 952: synchronized (timedWaitLock()) { Where is the overall design of the timed-wait protocol and it use of synchronization described? src/java.base/share/classes/java/lang/VirtualThread.java line 1397: > 1395: > 1396: /** > 1397: * Returns a lock object to coordinating timed-wait setup and timeout handling. Suggestion: * Returns a lock object for coordinating timed-wait setup and timeout handling. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2384039238 PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2387241944 PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2393910702 PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2393922768 Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2406338095 PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2409348761 PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2417279456 PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2431004707 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818251880 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815838204 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815839094 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827128518 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815840245 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814306675 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825344054 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1805616004 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814260043 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815985700 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815998417 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816002660 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816009160 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816014286 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816017269 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816018848 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810025380 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815956322 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816040287 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810027786 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810029858 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811912133 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810032387 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811913172 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810033016 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810035434 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810037658 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815959203 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810036007 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810041017 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810046285 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810049295 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811914377 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815960013 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815967260 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815969101 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816043275 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816047142 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816041444 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810068395 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825344940 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825345446 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814294622 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814158735 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814159210 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810076019 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810111255 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810113028 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810113953 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810114488 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810116177 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810131339 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814169150 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814170953 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814171503 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814172621 From coleenp at openjdk.org Wed Nov 6 17:39:52 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:39:52 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... I've done a first pass over the first commit and have some comments and questions. Round 2. There are a lot of very helpful comments in the new code to explain what it's doing but I have some requests for some more. And some questions. Some more comments and questions on the latest commit, mostly minor. I've traced through the runtime code (minus calculations for continuations) and found some typos on the way. Excellent piece of work. > Then I looked at typing up the thread / lock ids as an enum class https://github.com/openjdk/jdk/commit/34221f4a50a492cad4785cfcbb4bef8fa51d6f23 Both of these suggested changes should be discussed as different RFEs. I don't really like this ThreadID change because it seems to introduce casting everywhere. Noticed while downloading this that some copyrights need updating. src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 135: > 133: assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame"); > 134: intptr_t* lspp = f.addr_at(frame::interpreter_frame_last_sp_offset); > 135: *lspp = f.unextended_sp() - f.fp(); Can you write a comment what this is doing briefly and why? src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1550: > 1548: #endif /* ASSERT */ > 1549: > 1550: push_cont_fastpath(); One of the callers of this gives a clue what it does. __ push_cont_fastpath(); // Set JavaThread::_cont_fastpath to the sp of the oldest interpreted frame we know about Why do you do this here? Oh please more comments... src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5354: > 5352: str(rscratch2, dst); > 5353: Label ok; > 5354: tbz(rscratch2, 63, ok); 63? Does this really need to have underflow checking? That would alleviate the register use concerns if it didn't. And it's only for legacy locking which should be stable until it's removed. src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 2032: > 2030: // Force freeze slow path in case we try to preempt. We will pin the > 2031: // vthread to the carrier (see FreezeBase::recurse_freeze_native_frame()). > 2032: __ push_cont_fastpath(); We need to do this because we might freeze, so JavaThread::_cont_fastpath should be set in case we do? src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 2629: > 2627: addi(temp, displaced_header, in_bytes(ObjectMonitor::owner_offset()) - markWord::monitor_value); > 2628: Register thread_id = displaced_header; > 2629: ld(thread_id, in_bytes(JavaThread::lock_id_offset()), R16_thread); Maybe to make things really clear, you could call this thread_lock_id ? Seems to be used consistently as thread_id in much of the platform code. src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 231: > 229: > 230: void MacroAssembler::inc_held_monitor_count(Register tmp) { > 231: Address dst = Address(xthread, JavaThread::held_monitor_count_offset()); Address dst(xthread, JavaThread::held_monitor_count_offset()); src/hotspot/share/interpreter/oopMapCache.cpp line 268: > 266: } > 267: > 268: int num_oops() { return _num_oops; } I can't find what uses this from OopMapCacheEntry. src/hotspot/share/oops/stackChunkOop.inline.hpp line 189: > 187: inline ObjectMonitor* stackChunkOopDesc::current_pending_monitor() const { > 188: ObjectWaiter* waiter = object_waiter(); > 189: if (waiter != nullptr && (waiter->is_monitorenter() || (waiter->is_wait() && (waiter->at_reenter() || waiter->notified())))) { Can we hide this conditional under ObjectWaiter::pending_monitor() { all this stuff with a comment; } Not sure what this is excluding. src/hotspot/share/runtime/continuation.cpp line 89: > 87: // we would incorrectly throw it during the unmount logic in the carrier. > 88: if (_target->has_async_exception_condition()) { > 89: _failed = false; This says "Don't" but then failed is false which doesn't make sense. Should it be true? src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1275: > 1273: > 1274: if (caller.is_interpreted_frame()) { > 1275: _total_align_size += frame::align_wiggle; Please put a comment here about frame align-wiggle. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1278: > 1276: } > 1277: > 1278: patch(f, hf, caller, false /*is_bottom_frame*/); I also forgot what patch does. Can you add a comment here too? src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1550: > 1548: assert(!cont.is_empty(), ""); > 1549: // This is done for the sake of the enterSpecial frame > 1550: StackWatermarkSet::after_unwind(thread); Is there a new place for this StackWatermark code? src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1657: > 1655: } > 1656: > 1657: template This function is kind of big, do we really want it duplicated to pass preempt as a template parameter? src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2235: > 2233: assert(!mon_acquired || mon->has_owner(_thread), "invariant"); > 2234: if (!mon_acquired) { > 2235: // Failed to aquire monitor. Return to enterSpecial to unmount again. typo: acquire src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2492: > 2490: void ThawBase::throw_interrupted_exception(JavaThread* current, frame& top) { > 2491: ContinuationWrapper::SafepointOp so(current, _cont); > 2492: // Since we might safepoint set the anchor so that the stack can we walked. typo: can be walked src/hotspot/share/runtime/javaThread.cpp line 2002: > 2000: #ifdef SUPPORT_MONITOR_COUNT > 2001: > 2002: #ifdef LOOM_MONITOR_SUPPORT If LOOM_MONITOR_SUPPORT is not true, this would skip this block and assert for LIGHTWEIGHT locking. Do we need this #ifdef ? src/hotspot/share/runtime/javaThread.hpp line 334: > 332: bool _pending_jvmti_unmount_event; // When preempting we post unmount event at unmount end rather than start > 333: bool _on_monitor_waited_event; // Avoid callee arg processing for enterSpecial when posting waited event > 334: ObjectMonitor* _contended_entered_monitor; // Monitor por pending monitor_contended_entered callback typo: Monitor **for** pending_contended_entered callback src/hotspot/share/runtime/objectMonitor.cpp line 416: > 414: set_owner_from_BasicLock(cur, current); // Convert from BasicLock* to Thread*. > 415: return true; > 416: } Not needed? Oh I see, BasicLock is now in stack_locker. src/hotspot/share/runtime/objectMonitor.cpp line 876: > 874: // and in doing so avoid some transitions ... > 875: > 876: // For virtual threads that are pinned do a timed-park instead, to I had trouble parsing this first sentence. I think it needs a comma after pinned and remove the comma after instead. src/hotspot/share/runtime/objectMonitor.cpp line 1014: > 1012: assert_mark_word_consistency(); > 1013: UnlinkAfterAcquire(current, currentNode); > 1014: if (is_succesor(current)) clear_succesor(); successor has two 's'. src/hotspot/share/runtime/objectMonitor.cpp line 1158: > 1156: if (LockingMode != LM_LIGHTWEIGHT && current->is_lock_owned((address)cur)) { > 1157: assert(_recursions == 0, "invariant"); > 1158: set_owner_from_BasicLock(cur, current); // Convert from BasicLock* to Thread*. This is nice you don't have to do this anymore. src/hotspot/share/runtime/objectMonitor.cpp line 2305: > 2303: } > 2304: > 2305: void ObjectMonitor::Initialize2() { Can you put a comment why there's a second initialize function? Presumably after some state is set. src/hotspot/share/runtime/objectMonitor.hpp line 43: > 41: // ParkEvent instead. Beware, however, that the JVMTI code > 42: // knows about ObjectWaiters, so we'll have to reconcile that code. > 43: // See next_waiter(), first_waiter(), etc. Also a nice cleanup. Did you reconcile the JVMTI code? src/hotspot/share/runtime/objectMonitor.hpp line 71: > 69: bool is_wait() { return _is_wait; } > 70: bool notified() { return _notified; } > 71: bool at_reenter() { return _at_reenter; } should these be const member functions? ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2386614214 PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2390813935 PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2396572570 Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2405734604 PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2430528701 PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442058307 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813899129 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814081166 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811590155 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814084085 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811591482 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811595282 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817407075 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823088425 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814905064 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815015410 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815016232 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815245735 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815036910 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823233359 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823252062 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811611376 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823091373 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811613400 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815445109 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811614453 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817415918 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815479877 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817419797 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817420178 From fbredberg at openjdk.org Wed Nov 6 17:39:53 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 6 Nov 2024 17:39:53 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Been learning a ton by reading the code changes and questions/answers from/to others. But I still have some questions (and some small suggestions). I'm done reviewing this piece of good-looking code, and I really enjoyed it. Thanks! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 945: > 943: > 944: void inc_held_monitor_count(); > 945: void dec_held_monitor_count(); I prefer to pass the `tmp` register as it's done in PPC. Manual register allocation is hard as it is, hiding what registers are clobbered makes it even harder. Suggestion: void inc_held_monitor_count(Register tmp); void dec_held_monitor_count(Register tmp); src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 740: > 738: void MacroAssembler::clobber_nonvolatile_registers() { > 739: BLOCK_COMMENT("clobber nonvolatile registers {"); > 740: Register regs[] = { Maybe I've worked in the embedded world for too, but it's always faster and safer to store arrays with values that never change in read only memory. Suggestion: static const Register regs[] = { src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273: > 271: ? frame_sp + fsize - frame::sender_sp_offset > 272: // we need to re-read fp because it may be an oop and we might have fixed the frame. > 273: : *(intptr_t**)(hf.sp() - 2); Suggestion: : *(intptr_t**)(hf.sp() - frame::sender_sp_offset); src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 793: > 791: > 792: void inc_held_monitor_count(Register tmp = t0); > 793: void dec_held_monitor_count(Register tmp = t0); I prefer if we don't use any default argument. Manual register allocation is hard as it is, hiding what registers are clobbered makes it even harder. Also it would make it more in line with how it's done in PPC. Suggestion: void inc_held_monitor_count(Register tmp); void dec_held_monitor_count(Register tmp); src/hotspot/share/runtime/continuation.cpp line 125: > 123: }; > 124: > 125: static bool is_safe_vthread_to_preempt_for_jvmti(JavaThread* target, oop vthread) { I think the code reads better if you change to `is_safe_to_preempt_vthread_for_jvmti`. Suggestion: static bool is_safe_to_preempt_vthread_for_jvmti(JavaThread* target, oop vthread) { src/hotspot/share/runtime/continuation.cpp line 135: > 133: #endif // INCLUDE_JVMTI > 134: > 135: static bool is_safe_vthread_to_preempt(JavaThread* target, oop vthread) { I think the code reads better if you change to `is_safe_to_preempt_vthread`. Suggestion: static bool is_safe_to_preempt_vthread(JavaThread* target, oop vthread) { src/hotspot/share/runtime/continuation.hpp line 66: > 64: > 65: enum preempt_kind { > 66: freeze_on_monitorenter = 1, Is there a reason why the first enumerator doesn't start at zero? src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889: > 887: return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller); > 888: } else { > 889: return freeze_pinned_native; Can you add a comment about why you only end up here for `freeze_pinned_native`, cause that is not clear to me. src/hotspot/share/runtime/objectMonitor.cpp line 1193: > 1191: } > 1192: > 1193: assert(node->TState == ObjectWaiter::TS_ENTER || node->TState == ObjectWaiter::TS_CXQ, ""); In `ObjectMonitor::resume_operation()` the exact same line is a `guarantee`- not an `assert`-line, is there any reason why? ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2404133418 Marked as reviewed by fbredberg (Committer). PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2410872086 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822551094 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822696920 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822200193 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822537887 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824253403 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824255622 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824262945 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824405820 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824676122 From dlong at openjdk.org Wed Nov 6 17:39:59 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:39:59 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Marked as reviewed by dlong (Reviewer). > On failure to acquire a monitor inside `ObjectMonitor::enter` a virtual thread will call freeze to copy all Java frames to the heap. We will add the virtual thread to the ObjectMonitor's queue and return back to Java. Instead of continue execution in Java though, the virtual thread will jump to a preempt stub which will clear the frames copied from the physical stack, and will return to `Continuation.run()` to proceed with the unmount logic. During this time, the Java frames are not changing, so it seems like it doesn't matter if the freeze/copy happens immediately or after we unwind the native frames and enter the preempt stub. In fact, it seems like it could be more efficient to delay the freeze/copy, given the fact that the preemption can be canceled. Looking at this reminds me of a paper I read a long time ago, "Using continuations to implement thread management and communication in operating systems" (https://dl.acm.org/doi/10.1145/121133.121155). For some reason github thinks VirtualThreadPinnedEvent.java was renamed to libSynchronizedNative.c and libTracePinnedThreads.c was renamed to LockingMode.java. Is there a way to fix that? I finished looking at this, and it looks good. Nice work! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 188: > 186: // Avoid using a leave instruction when this frame may > 187: // have been frozen, since the current value of rfp > 188: // restored from the stub would be invalid. We still It sounds like freeze/thaw isn't preserving FP, even though it is a callee-saved register according to the ABI. If the stubs tried to modify FP (or any other callee-saved register) and use that value after the native call, wouldn't that be a problem? Do we actually need FP set by the enter() prologue for stubs? If we can walk compiled frames based on SP and frame size, it seems like we should be able to do the same for stubs. We could consider making stub prologue/epilogue look the same as compiled frames, then this FP issue goes away. src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 191: > 189: // must restore the rfp value saved on enter though. > 190: if (use_pop) { > 191: ldp(rfp, lr, Address(post(sp, 2 * wordSize))); leave() also calls authenticate_return_address(), which I assume we still want to call here. How about adding an optional parameter to leave() that will skip the problematic `mov(sp, rfp)`? src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 133: > 131: > 132: inline void FreezeBase::prepare_freeze_interpreted_top_frame(const frame& f) { > 133: assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame"); Suggestion: assert(f.interpreter_frame_last_sp() == nullptr, "should be null for top frame"); src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 135: > 133: assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame"); > 134: intptr_t* lspp = f.addr_at(frame::interpreter_frame_last_sp_offset); > 135: *lspp = f.unextended_sp() - f.fp(); Suggestion: f.interpreter_frame_set_last_sp(f.unextended_sp()); src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 159: > 157: > 158: // The interpreter native wrapper code adds space in the stack equal to size_of_parameters() > 159: // after the fixed part of the frame. For wait0 this is equal to 3 words (this + long parameter). Suggestion: // after the fixed part of the frame. For wait0 this is equal to 2 words (this + long parameter). Isn't that 2 words, not 3? src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 310: > 308: sp -= 2; > 309: sp[-2] = sp[0]; > 310: sp[-1] = sp[1]; This also seems fragile. This seems to depend on an intimate knowledge of what the stub will do when returning. We don't need this when doing a regular return from the native call, so why do we need it here? I'm guessing freeze/thaw hasn't restored the state quite the same way that the stub expects. Why is this needed for C2 and not C1? src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 338: > 336: // Make sure that extended_sp is kept relativized. > 337: DEBUG_ONLY(Method* m = hf.interpreter_frame_method();) > 338: DEBUG_ONLY(int extra_space = m->is_object_wait0() ? m->size_of_parameters() : 0;) // see comment in relativize_interpreted_frame_metadata() Isn't m->size_of_parameters() always correct? Why is wait0 a special case? src/hotspot/cpu/aarch64/frame_aarch64.hpp line 77: > 75: // Interpreter frames > 76: interpreter_frame_result_handler_offset = 3, // for native calls only > 77: interpreter_frame_oop_temp_offset = 2, // for native calls only This conflicts with sender_sp_offset. Doesn't that cause a problem? src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1555: > 1553: // Make VM call. In case of preemption set last_pc to the one we want to resume to. > 1554: adr(rscratch1, resume_pc); > 1555: str(rscratch1, Address(rthread, JavaThread::last_Java_pc_offset())); Is it really needed to set an alternative last_Java_pc()? I couldn't find where it's used in a way that would require a different value. src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1567: > 1565: > 1566: // In case of preemption, this is where we will resume once we finally acquire the monitor. > 1567: bind(resume_pc); If the idea is that we return directly to `resume_pc`, because of `last_Java_pc`(), then why do we poll `preempt_alternate_return_offset` above? src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp line 119: > 117: return mask.num_oops() > 118: + 1 // for the mirror oop > 119: + (f.interpreter_frame_method()->is_native() ? 1 : 0) // temp oop slot Where is this temp oop slot set and used? src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1351: > 1349: // set result handler > 1350: __ mov(result_handler, r0); > 1351: __ str(r0, Address(rfp, frame::interpreter_frame_result_handler_offset * wordSize)); I'm guessing this is here because preemption doesn't save/restore registers, even callee-saved registers, so we need to save this somewhere. I think this deserves a comment. src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1509: > 1507: Label no_oop; > 1508: __ adr(t, ExternalAddress(AbstractInterpreter::result_handler(T_OBJECT))); > 1509: __ ldr(result_handler, Address(rfp, frame::interpreter_frame_result_handler_offset*wordSize)); We only need this when preempted, right? So could this be moved into the block above, where we call restore_after_resume()? src/hotspot/cpu/x86/c1_Runtime1_x86.cpp line 223: > 221: } > 222: > 223: void StubAssembler::epilogue(bool use_pop) { Is there a better name we could use, like `trust_fp` or `after_resume`? src/hotspot/cpu/x86/c1_Runtime1_x86.cpp line 643: > 641: uint Runtime1::runtime_blob_current_thread_offset(frame f) { > 642: #ifdef _LP64 > 643: return r15_off / 2; I think using r15_offset_in_bytes() would be less confusing. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 324: > 322: movq(scrReg, tmpReg); > 323: xorq(tmpReg, tmpReg); > 324: movptr(boxReg, Address(r15_thread, JavaThread::lock_id_offset())); I don't know if it helps to schedule this load earlier (it is used in the next instruction), but it probably won't hurt. src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp line 146: > 144: // Make sure that locals is already relativized. > 145: DEBUG_ONLY(Method* m = f.interpreter_frame_method();) > 146: DEBUG_ONLY(int max_locals = !m->is_native() ? m->max_locals() : m->size_of_parameters() + 2;) What is the + 2 for? Is the check for is_native because of wait0? Please add a comment what this line is doing. src/hotspot/cpu/x86/interp_masm_x86.cpp line 359: > 357: push_cont_fastpath(); > 358: > 359: // Make VM call. In case of preemption set last_pc to the one we want to resume to. >From the comment, it sounds like we want to set last_pc to resume_pc, but I don't see that happening. The push/pop of rscratch1 doesn't seem to be doing anything. src/hotspot/cpu/x86/interp_masm_x86.cpp line 361: > 359: // Make VM call. In case of preemption set last_pc to the one we want to resume to. > 360: lea(rscratch1, resume_pc); > 361: push(rscratch1); Suggestion: push(rscratch1); // call_VM_helper requires last_Java_pc for anchor to be at the top of the stack src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3796: > 3794: __ movbool(rscratch1, Address(r15_thread, JavaThread::preemption_cancelled_offset())); > 3795: __ testbool(rscratch1); > 3796: __ jcc(Assembler::notZero, preemption_cancelled); If preemption was canceled, then I wouldn't expect patch_return_pc_with_preempt_stub() to get called. Does this mean preemption can get canceled (asynchronously be a different thread?) even afgter patch_return_pc_with_preempt_stub() is called? src/hotspot/share/c1/c1_Runtime1.hpp line 138: > 136: static void initialize_pd(); > 137: > 138: static uint runtime_blob_current_thread_offset(frame f); I think this returns an offset in wordSize units, but it's not documented. In some places we always return an offset in bytes and let the caller convert. src/hotspot/share/code/nmethod.cpp line 712: > 710: JavaThread* thread = reg_map->thread(); > 711: if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) > 712: JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) { I'm guessing this is because JVMTI can cause a safepoint? This might need a comment. src/hotspot/share/code/nmethod.cpp line 1302: > 1300: _compiler_type = type; > 1301: _orig_pc_offset = 0; > 1302: _num_stack_arg_slots = 0; Was the old value wrong, unneeded, or is this set somewhere else? If this field is not used, then we might want to set it to an illegal value in debug builds. src/hotspot/share/oops/method.cpp line 870: > 868: } > 869: > 870: bool Method::is_object_wait0() const { It might be worth mentioning that is not a general-purpose API, so we don't have to worry about false positives here. src/hotspot/share/oops/stackChunkOop.inline.hpp line 255: > 253: RegisterMap::WalkContinuation::include); > 254: full_map.set_include_argument_oops(false); > 255: closure->do_frame(f, map); This could use a comment. I guess we weren't looking at the stub frame before, only the caller. Why is this using `map` instead of `full_map`? src/hotspot/share/prims/jvmtiEnv.cpp line 1363: > 1361: } > 1362: > 1363: if (LockingMode == LM_LEGACY && java_thread == nullptr) { Do we need to check for `java_thread == nullptr` for other locking modes? src/hotspot/share/prims/jvmtiEnvBase.cpp line 1602: > 1600: // If the thread was found on the ObjectWaiter list, then > 1601: // it has not been notified. > 1602: Handle th(current_thread, w->threadObj()); Why use get_vthread_or_thread_oop() above but threadObj()? It probably needs a comment. src/hotspot/share/runtime/continuation.hpp line 50: > 48: class JavaThread; > 49: > 50: // should match Continuation.toPreemptStatus() in Continuation.java I can't find Continuation.toPreemptStatus() and the enum in Continuation.java doesn't match. src/hotspot/share/runtime/continuation.hpp line 50: > 48: class JavaThread; > 49: > 50: // should match Continuation.PreemptStatus() in Continuation.java As far as I can tell, these enum values still don't match the Java values. If they need to match, then maybe there should be asserts that check that. src/hotspot/share/runtime/continuationEntry.cpp line 51: > 49: _return_pc = nm->code_begin() + _return_pc_offset; > 50: _thaw_call_pc = nm->code_begin() + _thaw_call_pc_offset; > 51: _cleanup_pc = nm->code_begin() + _cleanup_offset; I don't see why we need these relative offsets. Instead of doing _thaw_call_pc_offset = __ pc() - start; why not do _thaw_call_pc = __ pc(); The only reason for the offsets would be if what gen_continuation_enter() generated was going to be relocated, but I don't think it is. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 316: > 314: pc = ContinuationHelper::return_address_at( > 315: sp - frame::sender_sp_ret_address_offset()); > 316: } You could do this with an overload instead: static void set_anchor(JavaThread* thread, intptr_t* sp, address pc) { assert(pc != nullptr, ""); [...] } static void set_anchor(JavaThread* thread, intptr_t* sp) { address pc = ContinuationHelper::return_address_at( sp - frame::sender_sp_ret_address_offset()); set_anchor(thread, sp, pc); } but the compiler probably optmizes the above check just fine. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 696: > 694: // in a fresh chunk, we freeze *with* the bottom-most frame's stack arguments. > 695: // They'll then be stored twice: in the chunk and in the parent chunk's top frame > 696: const int chunk_start_sp = cont_size() + frame::metadata_words + _monitors_in_lockstack; `cont_size() + frame::metadata_words + _monitors_in_lockstack` is used more than once. Would it make sense to add a helper function named something like `total_cont_size()`? src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1063: > 1061: unwind_frames(); > 1062: > 1063: chunk->set_max_thawing_size(chunk->max_thawing_size() + _freeze_size - _monitors_in_lockstack - frame::metadata_words); It seems a little weird to subtract these here only to add them back in other places (see my comment above suggesting total_cont_size). I wonder if there is a way to simply these adjustments. Having to replicate _monitors_in_lockstack +- frame::metadata_words in lots of places seems error-prone. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1411: > 1409: // zero out fields (but not the stack) > 1410: const size_t hs = oopDesc::header_size(); > 1411: oopDesc::set_klass_gap(mem, 0); Why, bug fix or cleanup? src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1659: > 1657: int i = 0; > 1658: for (frame f = freeze_start_frame(); Continuation::is_frame_in_continuation(ce, f); f = f.sender(&map), i++) { > 1659: if (!((f.is_compiled_frame() && !f.is_deoptimized_frame()) || (i == 0 && (f.is_runtime_frame() || f.is_native_frame())))) { OK, `i == 0` just means first frame here, so you could use a bool instead of an int, or even check for f == freeze_start_frame(), right? src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1842: > 1840: size += frame::metadata_words; // For the top pc+fp in push_return_frame or top = stack_sp - frame::metadata_words in thaw_fast > 1841: size += 2*frame::align_wiggle; // in case of alignments at the top and bottom > 1842: size += frame::metadata_words; // for preemption case (see possibly_adjust_frame) So this means it's OK to over-estimate the size here? src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2045: > 2043: // If we don't thaw the top compiled frame too, after restoring the saved > 2044: // registers back in Java, we would hit the return barrier to thaw one more > 2045: // frame effectively overwritting the restored registers during that call. Suggestion: // frame effectively overwriting the restored registers during that call. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2062: > 2060: } > 2061: > 2062: f.next(SmallRegisterMap::instance, true /* stop */); Suggestion: f.next(SmallRegisterMap::instance(), true /* stop */); This looks like a typo, so I wonder how it compiled. I guess template magic is hiding it. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2650: > 2648: _cont.tail()->do_barriers(_stream, &map); > 2649: } else { > 2650: _stream.next(SmallRegisterMap::instance); Suggestion: _stream.next(SmallRegisterMap::instance()); src/hotspot/share/runtime/continuationJavaClasses.inline.hpp line 189: > 187: > 188: inline uint8_t jdk_internal_vm_StackChunk::lockStackSize(oop chunk) { > 189: return Atomic::load(chunk->field_addr(_lockStackSize_offset)); If these accesses need to be atomic, could you add a comment explaining why? src/hotspot/share/runtime/deoptimization.cpp line 125: > 123: > 124: void DeoptimizationScope::mark(nmethod* nm, bool inc_recompile_counts) { > 125: if (!nm->can_be_deoptimized()) { Is this a performance optimization? src/hotspot/share/runtime/objectMonitor.cpp line 1612: > 1610: > 1611: static void vthread_monitor_waited_event(JavaThread *current, ObjectWaiter* node, ContinuationWrapper& cont, EventJavaMonitorWait* event, jboolean timed_out) { > 1612: // Since we might safepoint set the anchor so that the stack can we walked. I was assuming the anchor would have been restored to what it was at preemption time. What is the state of the anchor at resume time, and is it documented anywhere? I'm a little fuzzy on what frames are on the stack at this point, so I'm not sure if entry_sp and entry_pc are the best choice or only choice here. src/hotspot/share/runtime/objectMonitor.inline.hpp line 44: > 42: inline int64_t ObjectMonitor::owner_from(JavaThread* thread) { > 43: int64_t tid = thread->lock_id(); > 44: assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable"); Should the "3" be a named constant with a comment? src/hotspot/share/runtime/objectMonitor.inline.hpp line 207: > 205: } > 206: > 207: inline bool ObjectMonitor::has_successor() { Why are _succ accesses atomic here when previously they were not? src/hotspot/share/runtime/vframe.cpp line 289: > 287: current >= f.interpreter_frame_monitor_end(); > 288: current = f.previous_monitor_in_interpreter_frame(current)) { > 289: oop owner = !heap_frame ? current->obj() : StackValue::create_stack_value_from_oop_location(stack_chunk(), (void*)current->obj_adr())->get_obj()(); It looks like we don't really need the StackValue. We might want to make it possible to call oop_from_oop_location() directly. src/hotspot/share/runtime/vframe.inline.hpp line 130: > 128: // Waited event after target vthread was preempted. Since all continuation frames > 129: // are freezed we get the top frame from the stackChunk instead. > 130: _frame = Continuation::last_frame(java_lang_VirtualThread::continuation(_thread->vthread()), &_reg_map); What happens if we don't do this? That might help explain why we are doing this. src/hotspot/share/services/threadService.cpp line 467: > 465: if (waitingToLockMonitor->has_owner()) { > 466: currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor); > 467: } Please explain why it is safe to remvoe the above code. src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 108: > 106: processDeregisterQueue(); > 107: > 108: if (Thread.currentThread().isVirtual()) { It looks like we have two implementations, depending on if the current thread is virtual or not. The two implementations differ in the way they signal interrupted. Can we unify the two somehow? src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 57: > 55: static { > 56: try { > 57: MethodHandles.lookup().ensureInitialized(AnchorCertificates.class); Why is this needed? A comment would help. test/hotspot/gtest/nmt/test_vmatree.cpp line 34: > 32: > 33: using Tree = VMATree; > 34: using TNode = Tree::TreapNode; Why is this needed? test/hotspot/jtreg/compiler/codecache/stress/OverloadCompileQueueTest.java line 42: > 40: * -XX:CompileCommand=exclude,java.lang.Thread::beforeSleep > 41: * -XX:CompileCommand=exclude,java.lang.Thread::afterSleep > 42: * -XX:CompileCommand=exclude,java.util.concurrent.TimeUnit::toNanos I'm guessing these changes have something to do with JDK-8279653? test/hotspot/jtreg/serviceability/jvmti/events/MonitorContendedEnter/mcontenter01/libmcontenter01.cpp line 73: > 71: /* ========================================================================== */ > 72: > 73: static int prepare(JNIEnv* jni) { Is this a bug fix? test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java line 30: > 28: * by reflection API > 29: * @library /test/lib/ > 30: * @requires vm.compMode != "Xcomp" If there is a problem with this test running with -Xcomp and virtual threads, maybe it should be handled as a separate bug fix. ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2410825883 PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2439180320 PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442765996 PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2448962446 PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2452534349 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817461936 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817426321 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817439076 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817437593 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817441437 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817464371 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817465037 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819964369 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817537666 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817539657 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817549144 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819973901 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820002377 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819979640 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819982432 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821434823 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819763504 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819996648 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821706030 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817552633 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819981522 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821503185 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821506576 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821558267 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821571623 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821594124 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821601480 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821617785 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821746421 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821623432 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821628036 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821632152 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821636581 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821644040 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821653194 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821656267 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821755997 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821670778 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821685316 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823640621 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823644339 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823580051 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823663674 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823665393 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825045757 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825050976 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825054769 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825111095 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825097245 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825109698 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825104359 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825107638 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817413638 From amitkumar at openjdk.org Wed Nov 6 17:39:59 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 6 Nov 2024 17:39:59 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Hi @pchilano, I see couple of failures on s390x, can you apply this patch: diff --git a/src/hotspot/cpu/s390/macroAssembler_s390.cpp b/src/hotspot/cpu/s390/macroAssembler_s390.cpp index f342240f3ca..d28b4579824 100644 --- a/src/hotspot/cpu/s390/macroAssembler_s390.cpp +++ b/src/hotspot/cpu/s390/macroAssembler_s390.cpp @@ -3492,7 +3492,7 @@ void MacroAssembler::increment_counter_eq(address counter_address, Register tmp1 void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Register temp1, Register temp2) { assert(LockingMode != LM_LIGHTWEIGHT, "uses fast_lock_lightweight"); - assert_different_registers(oop, box, temp1, temp2); + assert_different_registers(oop, box, temp1, temp2, Z_R0_scratch); Register displacedHeader = temp1; Register currentHeader = temp1; @@ -3566,8 +3566,8 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis // If csg succeeds then CR=EQ, otherwise, register zero is filled // with the current owner. z_lghi(zero, 0); - z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset())); - z_csg(zero, Z_R1_scratch, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner), monitor_tagged); + z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset())); + z_csg(zero, Z_R0_scratch, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner), monitor_tagged); // Store a non-null value into the box. z_stg(box, BasicLock::displaced_header_offset_in_bytes(), box); @@ -3576,7 +3576,7 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis BLOCK_COMMENT("fast_path_recursive_lock {"); // Check if we are already the owner (recursive lock) - z_cgr(Z_R1_scratch, zero); // owner is stored in zero by "z_csg" above + z_cgr(Z_R0_scratch, zero); // owner is stored in zero by "z_csg" above z_brne(done); // not a recursive lock // Current thread already owns the lock. Just increment recursion count. @@ -3594,7 +3594,7 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis void MacroAssembler::compiler_fast_unlock_object(Register oop, Register box, Register temp1, Register temp2) { assert(LockingMode != LM_LIGHTWEIGHT, "uses fast_unlock_lightweight"); - assert_different_registers(oop, box, temp1, temp2); + assert_different_registers(oop, box, temp1, temp2, Z_R0_scratch); Register displacedHeader = temp1; Register currentHeader = temp2; @@ -3641,8 +3641,8 @@ void MacroAssembler::compiler_fast_unlock_object(Register oop, Register box, Reg // Handle existing monitor. bind(object_has_monitor); - z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset())); - z_cg(Z_R1_scratch, Address(currentHeader, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner))); + z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset())); + z_cg(Z_R0_scratch, Address(currentHeader, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner))); z_brne(done); BLOCK_COMMENT("fast_path_recursive_unlock {"); @@ -6164,7 +6164,7 @@ void MacroAssembler::lightweight_unlock(Register obj, Register temp1, Register t } void MacroAssembler::compiler_fast_lock_lightweight_object(Register obj, Register box, Register tmp1, Register tmp2) { - assert_different_registers(obj, box, tmp1, tmp2); + assert_different_registers(obj, box, tmp1, tmp2, Z_R0_scratch); // Handle inflated monitor. NearLabel inflated; @@ -6296,12 +6296,12 @@ void MacroAssembler::compiler_fast_lock_lightweight_object(Register obj, Registe // If csg succeeds then CR=EQ, otherwise, register zero is filled // with the current owner. z_lghi(zero, 0); - z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset())); - z_csg(zero, Z_R1_scratch, owner_address); + z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset())); + z_csg(zero, Z_R0_scratch, owner_address); z_bre(monitor_locked); // Check if recursive. - z_cgr(Z_R1_scratch, zero); // zero contains the owner from z_csg instruction + z_cgr(Z_R0_scratch, zero); // zero contains the owner from z_csg instruction z_brne(slow_path); // Recursive CC: @RealLucy ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2414585800 From aph at openjdk.org Wed Nov 6 17:40:00 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > * We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. This last sentence has interesting consequences for user-defined schedulers. Would it make sense to throw an exception if a carrier thread is holding a monitor while mounting a virtual thread? Doing that would also have the advantage of making some kinds of deadlock impossible. src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 60: > 58: > 59: assert(LockingMode != LM_LIGHTWEIGHT, "lightweight locking should use fast_lock_lightweight"); > 60: assert_different_registers(oop, box, tmp, disp_hdr, rscratch2); Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake. Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5341: > 5339: > 5340: void MacroAssembler::inc_held_monitor_count() { > 5341: Address dst = Address(rthread, JavaThread::held_monitor_count_offset()); Suggestion: // Clobbers: rscratch1 and rscratch2 void MacroAssembler::inc_held_monitor_count() { Address dst = Address(rthread, JavaThread::held_monitor_count_offset()); src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5357: > 5355: > 5356: void MacroAssembler::dec_held_monitor_count() { > 5357: Address dst = Address(rthread, JavaThread::held_monitor_count_offset()); Suggestion: // Clobbers: rscratch1 and rscratch2 void MacroAssembler::dec_held_monitor_count() { Address dst = Address(rthread, JavaThread::held_monitor_count_offset()); ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2429587519 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810966647 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810987929 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810989022 From alanb at openjdk.org Wed Nov 6 17:40:00 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 15:23:50 GMT, Andrew Haley wrote: > This last sentence has interesting consequences for user-defined schedulers. Would it make sense to throw an exception if a carrier thread is holding a monitor while mounting a virtual thread? Doing that would also have the advantage of making some kinds of deadlock impossible. There's nothing exposed today to allow custom schedulers. The experiments/explorations going on right now have to be careful to not hold any locks. Throwing if holding a monitor is an option but only it would need to be backed by spec and would also shine light on the issue of j.u.concurrent locks as a carrier might independently hold a lock there too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2431600434 From coleenp at openjdk.org Wed Nov 6 17:40:00 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Wed, 23 Oct 2024 06:15:27 GMT, David Holmes wrote: > Why do we need to cache it? Is it the implicit barriers related to accessing the threadObj oop each time? We cache threadObj.thread_id in JavaThread::_lock_id so that the fast path c2_MacroAssembler code has one less load and code to find the offset of java.lang.Thread.threadId in the code. Also, yes, we were worried about performance of the barrier in this path. > src/hotspot/share/runtime/objectMonitor.hpp line 174: > >> 172: >> 173: int64_t volatile _owner; // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER. >> 174: volatile uint64_t _previous_owner_tid; // thread id of the previous owner of the monitor > > Looks odd to have the current owner as `int64_t` but we save the previous owner as `uint64_t`. ?? I was wondering what this was too but the _previous_owner_tid is the os thread id, not the Java thread id. $ grep -r JFR_THREAD_ID jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) (JfrThreadLocal::external_thread_id(thread)) jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) ((traceid)(thread)->osthread()->thread_id()) runtime/objectMonitor.cpp: _previous_owner_tid = JFR_THREAD_ID(current); runtime/objectMonitor.cpp: iterator->_notifier_tid = JFR_THREAD_ID(current); runtime/vmThread.cpp: event->set_caller(JFR_THREAD_ID(op->calling_thread())); > src/hotspot/share/runtime/synchronizer.cpp line 1440: > >> 1438: } >> 1439: >> 1440: ObjectMonitor* ObjectSynchronizer::inflate_impl(JavaThread* inflating_thread, oop object, const InflateCause cause) { > > `inflating_thread` doesn't sound right as it is always the current thread that is doing the inflating. The passed in thread may be a different thread trying to acquire the monitor ... perhaps `contending_thread`? If it's always the current thread, then it should be called 'current' imo. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2433252605 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816550112 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816551794 From mchung at openjdk.org Wed Nov 6 17:40:00 2024 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... I looked at java.lang.ref and java.lang.invoke changes. ReferenceQueue was reverted back to use synchronized and also adding the code disable/enable preemption looks right. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2438401789 From bpb at openjdk.org Wed Nov 6 17:40:00 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... The `InternalLock` and `ByteArrayOutputStream` changes look all right. I'll follow up with [JDK-8343039](https://bugs.openjdk.org/browse/JDK-8343039) once this PR for [JEP 491](https://openjdk.org/jeps/491) is integrated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2438461962 From pchilanomate at openjdk.org Wed Nov 6 17:40:00 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Sat, 26 Oct 2024 02:15:29 GMT, Dean Long wrote: > > On failure to acquire a monitor inside `ObjectMonitor::enter` a virtual thread will call freeze to copy all Java frames to the heap. We will add the virtual thread to the ObjectMonitor's queue and return back to Java. Instead of continue execution in Java though, the virtual thread will jump to a preempt stub which will clear the frames copied from the physical stack, and will return to `Continuation.run()` to proceed with the unmount logic. > > During this time, the Java frames are not changing, so it seems like it doesn't matter if the freeze/copy happens immediately or after we unwind the native frames and enter the preempt stub. In fact, it seems like it could be more efficient to delay the freeze/copy, given the fact that the preemption can be canceled. > The problem is that freezing the frames can fail. By then we would have already added the ObjectWaiter as representing a virtual thread. Regarding efficiency (and ignoring the previous issue) both approaches would be equal anyways, since regardless of when you freeze, while doing the freezing the monitor could have been released already. So trying to acquire the monitor after freezing can always succeed, which means we don't want to unmount but continue execution, i.e cancel the preemption. >It sounds like freeze/thaw isn't preserving FP, even though it is a callee-saved register according to the ABI. If the stubs tried to modify FP (or any other callee-saved register) and use that value after the native call, wouldn't that be a problem? > Yes, that would be a problem. We can't use callee saved registers in the stub after the call. I guess we could add some debug code that trashes all those registers right when we come back from the call. Or maybe just adding a comment there is enough. > src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 191: > >> 189: // must restore the rfp value saved on enter though. >> 190: if (use_pop) { >> 191: ldp(rfp, lr, Address(post(sp, 2 * wordSize))); > > leave() also calls authenticate_return_address(), which I assume we still want to call here. > How about adding an optional parameter to leave() that will skip the problematic `mov(sp, rfp)`? Right. I added it here for now to follow the same style in all platforms. > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 133: > >> 131: >> 132: inline void FreezeBase::prepare_freeze_interpreted_top_frame(const frame& f) { >> 133: assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame"); > > Suggestion: > > assert(f.interpreter_frame_last_sp() == nullptr, "should be null for top frame"); Changed, here and in the other platforms. > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 135: > >> 133: assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame"); >> 134: intptr_t* lspp = f.addr_at(frame::interpreter_frame_last_sp_offset); >> 135: *lspp = f.unextended_sp() - f.fp(); > > Suggestion: > > f.interpreter_frame_set_last_sp(f.unextended_sp()); Changed, here and in the other platforms. > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 159: > >> 157: >> 158: // The interpreter native wrapper code adds space in the stack equal to size_of_parameters() >> 159: // after the fixed part of the frame. For wait0 this is equal to 3 words (this + long parameter). > > Suggestion: > > // after the fixed part of the frame. For wait0 this is equal to 2 words (this + long parameter). > > Isn't that 2 words, not 3? The timeout parameter is a long which we count as 2 words: https://github.com/openjdk/jdk/blob/0e3fc93dfb14378a848571a6b83282c0c73e690f/src/hotspot/share/runtime/signature.hpp#L347 I don't know why we do that for 64 bits. > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 338: > >> 336: // Make sure that extended_sp is kept relativized. >> 337: DEBUG_ONLY(Method* m = hf.interpreter_frame_method();) >> 338: DEBUG_ONLY(int extra_space = m->is_object_wait0() ? m->size_of_parameters() : 0;) // see comment in relativize_interpreted_frame_metadata() > > Isn't m->size_of_parameters() always correct? Why is wait0 a special case? There are two cases where the interpreter native wrapper frame is freezed: synchronized native method, and `Object.wait()`. The extra push of the parameters to the stack is done after we synchronize on the method, so it only applies to `Object.wait()`. > src/hotspot/cpu/aarch64/frame_aarch64.hpp line 77: > >> 75: // Interpreter frames >> 76: interpreter_frame_result_handler_offset = 3, // for native calls only >> 77: interpreter_frame_oop_temp_offset = 2, // for native calls only > > This conflicts with sender_sp_offset. Doesn't that cause a problem? No, it just happens to be stored at the sender_sp marker. We were already making room for two words but only using one. > src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1351: > >> 1349: // set result handler >> 1350: __ mov(result_handler, r0); >> 1351: __ str(r0, Address(rfp, frame::interpreter_frame_result_handler_offset * wordSize)); > > I'm guessing this is here because preemption doesn't save/restore registers, even callee-saved registers, so we need to save this somewhere. I think this deserves a comment. Added comment. > src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1509: > >> 1507: Label no_oop; >> 1508: __ adr(t, ExternalAddress(AbstractInterpreter::result_handler(T_OBJECT))); >> 1509: __ ldr(result_handler, Address(rfp, frame::interpreter_frame_result_handler_offset*wordSize)); > > We only need this when preempted, right? So could this be moved into the block above, where we call restore_after_resume()? Moved. > src/hotspot/cpu/x86/c1_Runtime1_x86.cpp line 643: > >> 641: uint Runtime1::runtime_blob_current_thread_offset(frame f) { >> 642: #ifdef _LP64 >> 643: return r15_off / 2; > > I think using r15_offset_in_bytes() would be less confusing. I copied the same comments the other platforms have to make it more clear. > src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp line 146: > >> 144: // Make sure that locals is already relativized. >> 145: DEBUG_ONLY(Method* m = f.interpreter_frame_method();) >> 146: DEBUG_ONLY(int max_locals = !m->is_native() ? m->max_locals() : m->size_of_parameters() + 2;) > > What is the + 2 for? Is the check for is_native because of wait0? Please add a comment what this line is doing. It's for the 2 extra words for native methods (temp oop/result handler). Added comment. > src/hotspot/cpu/x86/interp_masm_x86.cpp line 359: > >> 357: push_cont_fastpath(); >> 358: >> 359: // Make VM call. In case of preemption set last_pc to the one we want to resume to. > > From the comment, it sounds like we want to set last_pc to resume_pc, but I don't see that happening. The push/pop of rscratch1 doesn't seem to be doing anything. Method `MacroAssembler::call_VM_helper()` expects the current value at the top of the stack to be the last_java_pc. There is comment on that method explaining it: https://github.com/openjdk/jdk/blob/60364ef0010bde2933c22bf581ff8b3700c4afd6/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1658 > src/hotspot/cpu/x86/interp_masm_x86.cpp line 361: > >> 359: // Make VM call. In case of preemption set last_pc to the one we want to resume to. >> 360: lea(rscratch1, resume_pc); >> 361: push(rscratch1); > > Suggestion: > > push(rscratch1); // call_VM_helper requires last_Java_pc for anchor to be at the top of the stack Added it as a note with the comment above. > src/hotspot/share/c1/c1_Runtime1.hpp line 138: > >> 136: static void initialize_pd(); >> 137: >> 138: static uint runtime_blob_current_thread_offset(frame f); > > I think this returns an offset in wordSize units, but it's not documented. In some places we always return an offset in bytes and let the caller convert. Added comment. > src/hotspot/share/code/nmethod.cpp line 712: > >> 710: JavaThread* thread = reg_map->thread(); >> 711: if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) >> 712: JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) { > > I'm guessing this is because JVMTI can cause a safepoint? This might need a comment. I added a comment already in `vthread_monitor_waited_event()` in ObjectMonitor.cpp. I think it's better placed there. > src/hotspot/share/code/nmethod.cpp line 1302: > >> 1300: _compiler_type = type; >> 1301: _orig_pc_offset = 0; >> 1302: _num_stack_arg_slots = 0; > > Was the old value wrong, unneeded, or is this set somewhere else? If this field is not used, then we might want to set it to an illegal value in debug builds. We read this value from the freeze/thaw code in several places. Since the only compiled native frame we allow to freeze is Object.wait0 the old value would be zero too. But I think the correct thing is to just set it to zero?always since a value > 0 is only meaningful for Java methods. > src/hotspot/share/oops/method.cpp line 870: > >> 868: } >> 869: >> 870: bool Method::is_object_wait0() const { > > It might be worth mentioning that is not a general-purpose API, so we don't have to worry about false positives here. Right, I added a check for the klass too. > src/hotspot/share/oops/stackChunkOop.inline.hpp line 255: > >> 253: RegisterMap::WalkContinuation::include); >> 254: full_map.set_include_argument_oops(false); >> 255: closure->do_frame(f, map); > > This could use a comment. I guess we weren't looking at the stub frame before, only the caller. Why is this using `map` instead of `full_map`? The full map gets only populated once we get the sender. We only need it when processing the caller which needs to know where each register was spilled since it might contain an oop. > src/hotspot/share/prims/jvmtiEnv.cpp line 1363: > >> 1361: } >> 1362: >> 1363: if (LockingMode == LM_LEGACY && java_thread == nullptr) { > > Do we need to check for `java_thread == nullptr` for other locking modes? No, both LM_LIGHTWEIGHT and LM_MONITOR have support for virtual threads. LM_LEGACY doesn't, so if the virtual thread is unmounted we know there is no monitor information to collect. > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1602: > >> 1600: // If the thread was found on the ObjectWaiter list, then >> 1601: // it has not been notified. >> 1602: Handle th(current_thread, w->threadObj()); > > Why use get_vthread_or_thread_oop() above but threadObj()? It probably needs a comment. We already filtered virtual threads above so no point in calling get_vthread_or_thread_oop() again. They will actually return the same result though. > src/hotspot/share/runtime/continuation.hpp line 50: > >> 48: class JavaThread; >> 49: >> 50: // should match Continuation.toPreemptStatus() in Continuation.java > > I can't find Continuation.toPreemptStatus() and the enum in Continuation.java doesn't match. Should be just PreemptStatus. Fixed. > src/hotspot/share/runtime/continuation.hpp line 50: > >> 48: class JavaThread; >> 49: >> 50: // should match Continuation.PreemptStatus() in Continuation.java > > As far as I can tell, these enum values still don't match the Java values. If they need to match, then maybe there should be asserts that check that. `PreemptStatus` is meant to be used with `tryPreempt()` which is not implemented yet, i.e. there is no method yet that maps between these values and the PreemptStatus enum. The closest is `Continuation.pinnedReason` which we do use. So if you want I can remove the reference to PreemptStatus and use pinnedReason instead. > src/hotspot/share/runtime/continuationEntry.cpp line 51: > >> 49: _return_pc = nm->code_begin() + _return_pc_offset; >> 50: _thaw_call_pc = nm->code_begin() + _thaw_call_pc_offset; >> 51: _cleanup_pc = nm->code_begin() + _cleanup_offset; > > I don't see why we need these relative offsets. Instead of doing > > _thaw_call_pc_offset = __ pc() - start; > > why not do > > _thaw_call_pc = __ pc(); > > The only reason for the offsets would be if what gen_continuation_enter() generated was going to be relocated, but I don't think it is. But these are generated in a temporary buffer. Until we call nmethod::new_native_nmethod() we won't know the final addresses. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 316: > >> 314: pc = ContinuationHelper::return_address_at( >> 315: sp - frame::sender_sp_ret_address_offset()); >> 316: } > > You could do this with an overload instead: > > static void set_anchor(JavaThread* thread, intptr_t* sp, address pc) { > assert(pc != nullptr, ""); > [...] > } > static void set_anchor(JavaThread* thread, intptr_t* sp) { > address pc = ContinuationHelper::return_address_at( > sp - frame::sender_sp_ret_address_offset()); > set_anchor(thread, sp, pc); > } > > but the compiler probably optmizes the above check just fine. Added an overload method. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 696: > >> 694: // in a fresh chunk, we freeze *with* the bottom-most frame's stack arguments. >> 695: // They'll then be stored twice: in the chunk and in the parent chunk's top frame >> 696: const int chunk_start_sp = cont_size() + frame::metadata_words + _monitors_in_lockstack; > > `cont_size() + frame::metadata_words + _monitors_in_lockstack` is used more than once. Would it make sense to add a helper function named something like `total_cont_size()`? Maybe, but I only see it twice, not sure we gain much. Also we save having to jump back and forth to see what total_cont_size() would actually account for. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1063: > >> 1061: unwind_frames(); >> 1062: >> 1063: chunk->set_max_thawing_size(chunk->max_thawing_size() + _freeze_size - _monitors_in_lockstack - frame::metadata_words); > > It seems a little weird to subtract these here only to add them back in other places (see my comment above suggesting total_cont_size). I wonder if there is a way to simply these adjustments. Having to replicate _monitors_in_lockstack +- frame::metadata_words in lots of places seems error-prone. The reason why this is added and later subtracted is because when allocating the stackChunk we need to account for all space needed, but when specifying how much space the vthread needs in the stack to allocate the frames we don't need to count _monitors_in_lockstack. I'd rather not group it with frame::metadata_words because these are logically different things. In fact, if we never subtract frame::metadata_words when setting max_thawing_size we should not need to account for it in thaw_size() (this is probably something we should clean up in the future). But for _monitors_in_lockstack we always need to subtract it to max_thawing_size. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1842: > >> 1840: size += frame::metadata_words; // For the top pc+fp in push_return_frame or top = stack_sp - frame::metadata_words in thaw_fast >> 1841: size += 2*frame::align_wiggle; // in case of alignments at the top and bottom >> 1842: size += frame::metadata_words; // for preemption case (see possibly_adjust_frame) > > So this means it's OK to over-estimate the size here? Yes, this will be the space allocated in the stack by the vthread when thawing. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2045: > >> 2043: // If we don't thaw the top compiled frame too, after restoring the saved >> 2044: // registers back in Java, we would hit the return barrier to thaw one more >> 2045: // frame effectively overwritting the restored registers during that call. > > Suggestion: > > // frame effectively overwriting the restored registers during that call. Fixed. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2062: > >> 2060: } >> 2061: >> 2062: f.next(SmallRegisterMap::instance, true /* stop */); > > Suggestion: > > f.next(SmallRegisterMap::instance(), true /* stop */); > > This looks like a typo, so I wonder how it compiled. I guess template magic is hiding it. Fixed. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2650: > >> 2648: _cont.tail()->do_barriers(_stream, &map); >> 2649: } else { >> 2650: _stream.next(SmallRegisterMap::instance); > > Suggestion: > > _stream.next(SmallRegisterMap::instance()); Fixed. > src/hotspot/share/runtime/continuationJavaClasses.inline.hpp line 189: > >> 187: >> 188: inline uint8_t jdk_internal_vm_StackChunk::lockStackSize(oop chunk) { >> 189: return Atomic::load(chunk->field_addr(_lockStackSize_offset)); > > If these accesses need to be atomic, could you add a comment explaining why? It is read concurrently by GC threads. Added comment. > src/hotspot/share/runtime/deoptimization.cpp line 125: > >> 123: >> 124: void DeoptimizationScope::mark(nmethod* nm, bool inc_recompile_counts) { >> 125: if (!nm->can_be_deoptimized()) { > > Is this a performance optimization? No, this might be a leftover. When working on the change for Object.wait I was looking at the deopt code and thought this check was missing. It seems most callers already filter this case except WB_DeoptimizeMethod. > src/hotspot/share/runtime/objectMonitor.cpp line 1612: > >> 1610: >> 1611: static void vthread_monitor_waited_event(JavaThread *current, ObjectWaiter* node, ContinuationWrapper& cont, EventJavaMonitorWait* event, jboolean timed_out) { >> 1612: // Since we might safepoint set the anchor so that the stack can we walked. > > I was assuming the anchor would have been restored to what it was at preemption time. What is the state of the anchor at resume time, and is it documented anywhere? > I'm a little fuzzy on what frames are on the stack at this point, so I'm not sure if entry_sp and entry_pc are the best choice or only choice here. The virtual thread is inside the thaw call here which is a leaf VM method, so there is no anchor. It is still in the mount transition before thawing frames. The top frame is Continuation.enterSpecial so that's what we set the anchor to. > src/hotspot/share/runtime/objectMonitor.inline.hpp line 44: > >> 42: inline int64_t ObjectMonitor::owner_from(JavaThread* thread) { >> 43: int64_t tid = thread->lock_id(); >> 44: assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable"); > > Should the "3" be a named constant with a comment? Yes, changed to use ThreadIdentifier::initial(). > src/hotspot/share/runtime/vframe.inline.hpp line 130: > >> 128: // Waited event after target vthread was preempted. Since all continuation frames >> 129: // are freezed we get the top frame from the stackChunk instead. >> 130: _frame = Continuation::last_frame(java_lang_VirtualThread::continuation(_thread->vthread()), &_reg_map); > > What happens if we don't do this? That might help explain why we are doing this. We would walk the carrier thread frames instead of the vthread ones. > src/hotspot/share/services/threadService.cpp line 467: > >> 465: if (waitingToLockMonitor->has_owner()) { >> 466: currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor); >> 467: } > > Please explain why it is safe to remvoe the above code. Yes, I should have added a comment here. The previous code assumed that if the monitor had an owner but it was not findable it meant the previous currentThread will be blocked permanently and so we recorded this as a deadlock. With these changes, the owner could be not findable because it is an unmounted vthread. There is currently no fast way to determine if that's the case so we never record this as a deadlock. Now, unless there is a bug in the VM, or a thread exits without releasing monitors acquired through JNI, unfindable owner should imply an unmounted vthread. I added a comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442387426 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819473410 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819465574 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819592799 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819466532 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819472086 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819481705 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821393856 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821591515 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821593810 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821592920 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821591143 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821593351 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823505700 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821591930 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821594779 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821595264 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821695166 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821695964 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821697629 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821698318 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821698705 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823509538 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821699155 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828187178 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823486049 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823487296 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823488795 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823511520 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823502075 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823503636 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824792648 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824793200 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824791832 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824793737 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825208611 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825210260 From dlong at openjdk.org Wed Nov 6 17:40:00 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <6dVwVwIL7UaAvf1KMrBnlgAqr0zn-qScNuB86a8PdFo=.b2d24f69-7fef-403c-97c0-2d1301d1995e@github.com> On Mon, 28 Oct 2024 18:58:29 GMT, Patricio Chilano Mateo wrote: > regardless of when you freeze, while doing the freezing the monitor could have been released already. So trying to acquire the monitor after freezing can always succeed, which means we don't want to unmount but continue execution, i.e cancel the preemption. Is this purely a performance optimization, or is there a correctness issue if we don't notice the monitor was released and cancel the preemption? It seems like the monitor can be released at any time, so what makes freeze special that we need to check afterwards? We aren't doing the monitor check atomically, so the monitor could get released right after we check it. So I'm guessing we choose to check after freeze because freeze has non-trivial overhead. >> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 159: >> >>> 157: >>> 158: // The interpreter native wrapper code adds space in the stack equal to size_of_parameters() >>> 159: // after the fixed part of the frame. For wait0 this is equal to 3 words (this + long parameter). >> >> Suggestion: >> >> // after the fixed part of the frame. For wait0 this is equal to 2 words (this + long parameter). >> >> Isn't that 2 words, not 3? > > The timeout parameter is a long which we count as 2 words: https://github.com/openjdk/jdk/blob/0e3fc93dfb14378a848571a6b83282c0c73e690f/src/hotspot/share/runtime/signature.hpp#L347 > I don't know why we do that for 64 bits. OK, I think there are historical or technical reasons why it's hard to change, because of the way the JVM spec is written. >> src/hotspot/cpu/aarch64/frame_aarch64.hpp line 77: >> >>> 75: // Interpreter frames >>> 76: interpreter_frame_result_handler_offset = 3, // for native calls only >>> 77: interpreter_frame_oop_temp_offset = 2, // for native calls only >> >> This conflicts with sender_sp_offset. Doesn't that cause a problem? > > No, it just happens to be stored at the sender_sp marker. We were already making room for two words but only using one. `sender_sp_offset` is listed under "All frames", but I guess that's wrong and should be changed. Can we fix the comments to match x86, which lists this offset under "non-interpreter frames"? >> src/hotspot/cpu/x86/interp_masm_x86.cpp line 359: >> >>> 357: push_cont_fastpath(); >>> 358: >>> 359: // Make VM call. In case of preemption set last_pc to the one we want to resume to. >> >> From the comment, it sounds like we want to set last_pc to resume_pc, but I don't see that happening. The push/pop of rscratch1 doesn't seem to be doing anything. > > Method `MacroAssembler::call_VM_helper()` expects the current value at the top of the stack to be the last_java_pc. There is comment on that method explaining it: https://github.com/openjdk/jdk/blob/60364ef0010bde2933c22bf581ff8b3700c4afd6/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1658 OK, I was looking for where it stores it in the anchor, but it doesn't, at least not until make_walkable() is called. >> src/hotspot/share/code/nmethod.cpp line 1302: >> >>> 1300: _compiler_type = type; >>> 1301: _orig_pc_offset = 0; >>> 1302: _num_stack_arg_slots = 0; >> >> Was the old value wrong, unneeded, or is this set somewhere else? If this field is not used, then we might want to set it to an illegal value in debug builds. > > We read this value from the freeze/thaw code in several places. Since the only compiled native frame we allow to freeze is Object.wait0 the old value would be zero too. But I think the correct thing is to just set it to zero?always since a value > 0 is only meaningful for Java methods. Isn't it possible that we might allow more compiled native frames in the future, and then we would have to undo this change? I think this change should be reverted. If continuations code wants to assert that this is 0, then that should be in continuations code, the nmethod code doesn't need to know how this field is used. However, it looks like continuations code is the only client of this field, so I can see how it would be tempting to just set it to 0 here, but it doesn't feel right. >> src/hotspot/share/runtime/continuation.hpp line 50: >> >>> 48: class JavaThread; >>> 49: >>> 50: // should match Continuation.PreemptStatus() in Continuation.java >> >> As far as I can tell, these enum values still don't match the Java values. If they need to match, then maybe there should be asserts that check that. > > `PreemptStatus` is meant to be used with `tryPreempt()` which is not implemented yet, i.e. there is no method yet that maps between these values and the PreemptStatus enum. The closest is `Continuation.pinnedReason` which we do use. So if you want I can remove the reference to PreemptStatus and use pinnedReason instead. Yes, that would be better for now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442880740 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819705281 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821524020 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821705135 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823572138 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823584967 From michaelm at openjdk.org Wed Nov 6 17:40:00 2024 From: michaelm at openjdk.org (Michael McMahon) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... I have reviewed the changes to the NIO selector/poller implementations and they look fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2444268747 From pchilanomate at openjdk.org Wed Nov 6 17:40:00 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <6dVwVwIL7UaAvf1KMrBnlgAqr0zn-qScNuB86a8PdFo=.b2d24f69-7fef-403c-97c0-2d1301d1995e@github.com> References: <6dVwVwIL7UaAvf1KMrBnlgAqr0zn-qScNuB86a8PdFo=.b2d24f69-7fef-403c-97c0-2d1301d1995e@github.com> Message-ID: On Mon, 28 Oct 2024 23:46:09 GMT, Dean Long wrote: > > regardless of when you freeze, while doing the freezing the monitor could have been released already. So trying to acquire the monitor after freezing can always succeed, which means we don't want to unmount but continue execution, i.e cancel the preemption. > > Is this purely a performance optimization, or is there a correctness issue if we don't notice the monitor was released and cancel the preemption? It seems like the monitor can be released at any time, so what makes freeze special that we need to check afterwards? We aren't doing the monitor check atomically, so the monitor could get released right after we check it. So I'm guessing we choose to check after freeze because freeze has non-trivial overhead. > After adding the ObjectWaiter to the _cxq we always have to retry acquiring the monitor; this is the same for platform threads. So freezing before that, implies we have to retry. As for whether we need to cancel the preemption if we acquire the monitor, not necessarily. We could still unmount with a state of YIELDING, so the virtual thread will be scheduled to run again. So that part is an optimization to avoid the unmount. >> No, it just happens to be stored at the sender_sp marker. We were already making room for two words but only using one. > > `sender_sp_offset` is listed under "All frames", but I guess that's wrong and should be changed. Can we fix the comments to match x86, which lists this offset under "non-interpreter frames"? I think aarch64 is the correct one. For interpreter frames we also have a sender_sp() that we get through that offset value: https://github.com/openjdk/jdk/blob/7404ddf24a162cff445cd0a26aec446461988bc8/src/hotspot/cpu/x86/frame_x86.cpp#L458 I think the confusion is because we also have interpreter_frame_sender_sp_offset where we store the unextended sp. >> We read this value from the freeze/thaw code in several places. Since the only compiled native frame we allow to freeze is Object.wait0 the old value would be zero too. But I think the correct thing is to just set it to zero?always since a value > 0 is only meaningful for Java methods. > > Isn't it possible that we might allow more compiled native frames in the future, and then we would have to undo this change? I think this change should be reverted. If continuations code wants to assert that this is 0, then that should be in continuations code, the nmethod code doesn't need to know how this field is used. However, it looks like continuations code is the only client of this field, so I can see how it would be tempting to just set it to 0 here, but it doesn't feel right. Any compiled native frame would still require a value of zero. This field should be read as the size of the argument area in the caller frame that this method(callee) might access during execution. That's why we set it to zero for OSR nmethods too. The thaw code uses this value to see if we need to thaw a compiled frame with stack arguments that reside in the caller frame. The freeze code also uses it to check for overlap and avoid copying these arguments twice. Currently we have a case for "nmethods" when reading this value, which includes both Java and native. I'd rather not add branches to separate these cases, specially given that we already have this field available in the nmethod class. >> `PreemptStatus` is meant to be used with `tryPreempt()` which is not implemented yet, i.e. there is no method yet that maps between these values and the PreemptStatus enum. The closest is `Continuation.pinnedReason` which we do use. So if you want I can remove the reference to PreemptStatus and use pinnedReason instead. > > Yes, that would be better for now. Changed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2445106760 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823495787 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824785565 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824788898 From alanb at openjdk.org Wed Nov 6 17:40:00 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 03:52:31 GMT, Dean Long wrote: > For some reason github thinks VirtualThreadPinnedEvent.java was renamed to libSynchronizedNative.c and libTracePinnedThreads.c was renamed to LockingMode.java. Is there a way to fix that? I don't know which view this is but just to say that VirtualThreadPinnedEvent.java and libTracePinnedThreads.c are removed. libSynchronizedNative.c is part of a new test (as it happens, it was previously reviewed as pull/18600 but we had to hold it back as it needed a fix from the loom repo that is part of the JEP 491 implementation). You find is easier to just fetch and checkout the branch to look at the changes locally. Personally I have this easier for large change and makes it easier to see renames and/or removals. > src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 108: > >> 106: processDeregisterQueue(); >> 107: >> 108: if (Thread.currentThread().isVirtual()) { > > It looks like we have two implementations, depending on if the current thread is virtual or not. The two implementations differ in the way they signal interrupted. Can we unify the two somehow? When executed on a platform thread is will block in epoll_wait or kqueue so it has to handle EINTR. It doesn't block in sys call when executed in a virtual thread. So very different implementations. > src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 57: > >> 55: static { >> 56: try { >> 57: MethodHandles.lookup().ensureInitialized(AnchorCertificates.class); > > Why is this needed? A comment would help. That's probably a good idea. It?s caused by pinning due to the sun.security.util.AnchorCertificates?s class initializer, some of the http client tests are running into this. Once monitors are out of the way then class initializers, both executing, and waiting for, will be a priority. > test/hotspot/gtest/nmt/test_vmatree.cpp line 34: > >> 32: >> 33: using Tree = VMATree; >> 34: using TNode = Tree::TreapNode; > > Why is this needed? We had to rename the alias to avoid a conflict with the Node in compile.hpp. Just lucky not to run into this in main-line. It comes and goes, depends on changes to header files that are transitively included by the test. I think Johan had planned to change this in main line but it may have got forgotten. > test/hotspot/jtreg/compiler/codecache/stress/OverloadCompileQueueTest.java line 42: > >> 40: * -XX:CompileCommand=exclude,java.lang.Thread::beforeSleep >> 41: * -XX:CompileCommand=exclude,java.lang.Thread::afterSleep >> 42: * -XX:CompileCommand=exclude,java.util.concurrent.TimeUnit::toNanos > > I'm guessing these changes have something to do with JDK-8279653? It should have been added when Thread.sleep was changed but we got lucky. > test/hotspot/jtreg/serviceability/jvmti/events/MonitorContendedEnter/mcontenter01/libmcontenter01.cpp line 73: > >> 71: /* ========================================================================== */ >> 72: >> 73: static int prepare(JNIEnv* jni) { > > Is this a bug fix? Testing ran into a couple of bugs in JVMTI tests. One of was tests that was stashing the JNIEnv into a static. > test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java line 30: > >> 28: * by reflection API >> 29: * @library /test/lib/ >> 30: * @requires vm.compMode != "Xcomp" > > If there is a problem with this test running with -Xcomp and virtual threads, maybe it should be handled as a separate bug fix. JBS has several issues related to ReflectionCallerCacheTest.java and -Xcomp, going back several releases. It seems some nmethod is keeping objects alive and is preventing class unloading in this test. The refactoring of j.l.ref in JDK 19 to workaround pinning issues made it go away. There is some minimal revert in this PR to deal with the potential for preemption when polling a reference queue and it seems the changes to this Java code have brought back the issue. So it's excluded from -Xcomp again. Maybe it would be better to add it to ProblemList-Xcomp.txt instead? That would allow it to link to one of the JSB issue on this issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2449153774 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825115214 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825127591 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825121520 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825112326 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825110254 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817692430 From pchilanomate at openjdk.org Wed Nov 6 17:40:00 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... I brought a small fix to the heap dump code from the loom repo for an issue found recently. It includes a reproducer test. I brought some JFR changes from the loom repo that improve the reported reason when pinning. @mgronlun @egahlin Could any of you review these JFR changes? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2455431391 PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2456054504 From pchilanomate at openjdk.org Wed Nov 6 17:40:01 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:01 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <8bSr_dBqhXkGBdKhm3qO4j1XJHBtu_RkeIH8ldtDAVA=.bd6692e9-93aa-46cf-b9de-75b06d83dd73@github.com> On Tue, 5 Nov 2024 01:47:29 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > I brought some JFR changes from the loom repo that improve the reported reason when pinning. > @mgronlun @egahlin Could any of you review these JFR changes? Thanks. > Hi @pchilano, > > I see couple of failures on s390x, can you apply this patch: > Thanks @offamitkumar. Fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2457338726 From pchilanomate at openjdk.org Wed Nov 6 17:40:01 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:01 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 17:31:45 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 188: >> >>> 186: // Avoid using a leave instruction when this frame may >>> 187: // have been frozen, since the current value of rfp >>> 188: // restored from the stub would be invalid. We still >> >> It sounds like freeze/thaw isn't preserving FP, even though it is a callee-saved register according to the ABI. If the stubs tried to modify FP (or any other callee-saved register) and use that value after the native call, wouldn't that be a problem? >> Do we actually need FP set by the enter() prologue for stubs? If we can walk compiled frames based on SP and frame size, it seems like we should be able to do the same for stubs. We could consider making stub prologue/epilogue look the same as compiled frames, then this FP issue goes away. > >>It sounds like freeze/thaw isn't preserving FP, even though it is a callee-saved register according to the ABI. If the stubs tried to modify FP (or any other callee-saved register) and use that value after the native call, wouldn't that be a problem? >> > Yes, that would be a problem. We can't use callee saved registers in the stub after the call. I guess we could add some debug code that trashes all those registers right when we come back from the call. Or maybe just adding a comment there is enough. > Do we actually need FP set by the enter() prologue for stubs? If we can walk compiled frames based on SP and frame size, it seems like we should be able to do the same for stubs. We could consider making stub prologue/epilogue look the same as compiled frames, then this FP issue goes away. > I think we need it for the pending exception case. I see we use rfp to get the exception pc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819474263 From pchilanomate at openjdk.org Wed Nov 6 17:40:01 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:01 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 21 Oct 2024 06:38:28 GMT, Axel Boldt-Christmas wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 231: > >> 229: >> 230: StubFrame::~StubFrame() { >> 231: __ epilogue(_use_pop_on_epilogue); > > Can we not hook the `_use_pop_on_epilogue` into `return_state_t`, simplify the constructors and keep the old should_not_reach_here guard for stubs which should not return? > e.g. > ```C++ > enum return_state_t { > does_not_return, requires_return, requires_pop_epilogue_return > }; > > StubFrame::~StubFrame() { > if (_return_state == does_not_return) { > __ should_not_reach_here(); > } else { > __ epilogue(_return_state == requires_pop_epilogue_return); > } > } Yes, that's much better. I changed it in both aarch64 and riscv. > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 115: > >> 113: // The object's monitor m is unlocked iff m->owner == nullptr, >> 114: // otherwise m->owner may contain a thread id, a stack address for LM_LEGACY, >> 115: // or the ANONYMOUS_OWNER constant for LM_LIGHTWEIGHT. > > Comment seems out of place in `LockingMode != LM_LIGHTWEIGHT` code. I removed this comment about what other values might be stored in _owner since we don't need to handle those cases here. > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 380: > >> 378: lea(t2_owner_addr, owner_address); >> 379: >> 380: // CAS owner (null => current thread id). > > I think we should be more careful when and where we talk about thread id and lock id respectively. Given that `switchToCarrierThread` switches the thread, but not the lock id. We should probably define and talk about the lock id when it comes to locking, as saying thread id may be incorrect. > > Then there is also the different thread ids, the OS level one, and the java level one. (But not sure how to reconcile this without causing confusion) Fixed the comments to refer to _lock_id. Even without the switchToCarrierThread case I think that's the correct thing to do. > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 300: > >> 298: CodeBlob* cb = top.cb(); >> 299: >> 300: if (cb->frame_size() == 2) { > > Is this a filter to identify c2 runtime stubs? Is there some other property we can check or assert here? This assumes that no other runtime frame will have this size. We could also check the caller of the runtime frame, something like: #ifdef ASSERT RegisterMap map(JavaThread::current(), RegisterMap::UpdateMap::skip, RegisterMap::ProcessFrames::skip, RegisterMap::WalkContinuation::skip); frame caller = top.sender(&map); assert(caller.is_compiled_frame(), ""); assert(cb->frame_size() > 2 || caller.cb()->as_nmethod()->is_compiled_by_c2(), ""); #endif Ideally we would want to check if cb->frame_size() is different than the actual?size of the physical frame. > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 313: > >> 311: >> 312: log_develop_trace(continuations, preempt)("adjusted sp for c2 runtime stub, initial sp: " INTPTR_FORMAT " final sp: " INTPTR_FORMAT >> 313: " fp: " INTPTR_FORMAT, p2i(sp + frame::metadata_words), p2i(sp), sp[-2]); > > Is there a reason for the mix of `2` and `frame::metadata_words`? > > Maybe this could be > ```C++ > intptr_t* const unadjusted_sp = sp; > sp -= frame::metadata_words; > sp[-2] = unadjusted_sp[-2]; > sp[-1] = unadjusted_sp[-1]; > > log_develop_trace(continuations, preempt)("adjusted sp for c2 runtime stub, initial sp: " INTPTR_FORMAT " final sp: " INTPTR_FORMAT > " fp: " INTPTR_FORMAT, p2i(unadjusted_sp), p2i(sp), sp[-2]); I removed the use of frame::metadata_words from the log statement instead to make it consistent, since we would still implicitly be assuming metadata_words it's 2 words when we do the copying. We could use a memcpy and refer to metadata_words, but I think it is clear this way since we are explicitly talking about the 2 extra words missing from the runtime frame as the comment explains. > src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 1275: > >> 1273: void SharedRuntime::continuation_enter_cleanup(MacroAssembler* masm) { >> 1274: ::continuation_enter_cleanup(masm); >> 1275: } > > Now that `continuation_enter_cleanup` is a static member function, just merge the static free function with this static member function. Since we have 3 free static functions to handle the continuation entry(create, fill, cleanup) I would prefer to keep the cleanup one for consistency. We could also change them all to be members of SharedRuntime. But except for the exception I added for continuation_enter_cleanup(), all these are called by gen_continuation_enter/gen_continuation_yield() which are also static free functions. > src/hotspot/cpu/x86/assembler_x86.cpp line 2866: > >> 2864: emit_int32(0); >> 2865: } >> 2866: } > > Is it possible to make this more general and explicit instead of a sequence of bytes? > > Something along the lines of: > ```C++ > const address tar = L.is_bound() ? target(L) : pc(); > const Address adr = Address(checked_cast(tar - pc()), tar, relocInfo::none); > > InstructionMark im(this); > emit_prefix_and_int8(get_prefixq(adr, dst), (unsigned char)0x8D); > if (!L.is_bound()) { > // Patch @0x8D opcode > L.add_patch_at(code(), CodeBuffer::locator(offset() - 1, sect())); > } > // Register and [rip+disp] operand > emit_modrm(0b00, raw_encode(dst), 0b101); > // Adjust displacement by sizeof lea instruction > int32_t disp = adr.disp() - checked_cast(pc() - inst_mark() + sizeof(int32_t)); > assert(is_simm32(disp), "must be 32bit offset [rip+offset]"); > emit_int32(disp); > > > and then in `pd_patch_instruction` simply match `op == 0x8D /* lea */`. I'll test it out but looks fine. > src/hotspot/share/oops/stackChunkOop.cpp line 445: > >> 443: >> 444: void stackChunkOopDesc::transfer_lockstack(oop* dst) { >> 445: const bool requires_gc_barriers = is_gc_mode() || requires_barriers(); > > Given how careful we are in `Thaw` to not call `requires_barriers()` twice and use `_barriers` instead it would probably be nicer to pass in `_barriers` as a bool. > > There is only one other place we do the extra call and it is in `fix_thawed_frame`, but that only happens after we are committed to the slow path, so it might be nice for completeness, but should be negligible for performance. Here however we might still be in our new "medium" path where we could still do a fast thaw. Good, passed as argument now. > src/hotspot/share/oops/stackChunkOop.cpp line 460: > >> 458: } else { >> 459: oop value = *reinterpret_cast(at); >> 460: HeapAccess<>::oop_store(reinterpret_cast(at), nullptr); > > Using HeapAccess when `!requires_gc_barriers` is wrong. This would crash with ZGC when/if we fix the flags race and changed `relativize_chunk_concurrently` to only be conditioned `requires_barriers() / _barriers` (and allowing the retry_fast_path "medium" path). > So either use `*reinterpret_cast(at) = nullptr;` or do what my initial suggestion with `clear_lockstack` did, just omit the clearing. Before we requires_barriers(), we are allowed to reuse the stackChuncks, so trying to clean them up seems fruitless. Ok, I just omitted clearing the oop. > src/hotspot/share/oops/stackChunkOop.cpp line 471: > >> 469: } >> 470: } >> 471: } > > Can we turn these three very similar loops into one? In my opinion, it is easier to parse. > > ```C++ > void stackChunkOopDesc::copy_lockstack(oop* dst) { > const int cnt = lockstack_size(); > const bool requires_gc_barriers = is_gc_mode() || requires_barriers(); > const bool requires_uncompress = requires_gc_barriers && has_bitmap() && UseCompressedOops; > const auto get_obj = [&](intptr_t* at) -> oop { > if (requires_gc_barriers) { > if (requires_uncompress) { > return HeapAccess<>::oop_load(reinterpret_cast(at)); > } > return HeapAccess<>::oop_load(reinterpret_cast(at)); > } > return *reinterpret_cast(at); > }; > > intptr_t* lockstack_start = start_address(); > for (int i = 0; i < cnt; i++) { > oop mon_owner = get_obj(&lockstack_start[i]); > assert(oopDesc::is_oop(mon_owner), "not an oop"); > dst[i] = mon_owner; > } > } Done. I combined it with the oop clearing suggestion. > src/hotspot/share/prims/jvmtiExport.cpp line 1681: > >> 1679: EVT_TRIG_TRACE(EXT_EVENT_VIRTUAL_THREAD_UNMOUNT, ("[%p] Trg Virtual Thread Unmount event triggered", vthread)); >> 1680: >> 1681: // On preemption JVMTI state rebinding has already happened so get it always direclty from the oop. > > Suggestion: > > // On preemption JVMTI state rebinding has already happened so get it always directly from the oop. Fixed. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2234: > >> 2232: retry_fast_path = true; >> 2233: } else { >> 2234: relativize_chunk_concurrently(chunk); > > Is the `relativize_chunk_concurrently` solution to the race only to have a single flag read in `can_thaw_fast` or is there some other subtlety here? > > While not required for the PR, if it is just to optimise the `can_thaw_fast` check, it can probably be made to work with one load and still allow concurrent gcs do fast_thaw when we only get here due to a lockstack. Yes, it's just to do a single read. I guess you are thinking of combining flags and lockStackSize into a int16_t? > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2247: > >> 2245: _thread->lock_stack().move_from_address(tmp_lockstack, lockStackSize); >> 2246: >> 2247: chunk->set_lockstack_size(0); > > After some discussion here at the office we think there might be an issue here with simply hiding the oops without clearing them. Below in `recurse_thaw` we `do_barriers`. But it does not touch these lockstack. Missing the SATB store barrier is probably fine from a liveness perspective, because the oops in the lockstack must also be in the frames. But removing the oops without a barrier and clear will probably lead to problems down the line. > > Something like the following would probably handle this. Or even fuse the `copy_lockstack` and `clear_lockstack` together into some kind of `transfer_lockstack` which both loads and clears the oops. > > > diff --git a/src/hotspot/share/oops/stackChunkOop.cpp b/src/hotspot/share/oops/stackChunkOop.cpp > index d3d63533eed..f737bd2db71 100644 > --- a/src/hotspot/share/oops/stackChunkOop.cpp > +++ b/src/hotspot/share/oops/stackChunkOop.cpp > @@ -470,6 +470,28 @@ void stackChunkOopDesc::copy_lockstack(oop* dst) { > } > } > > +void stackChunkOopDesc::clear_lockstack() { > + const int cnt = lockstack_size(); > + const bool requires_gc_barriers = is_gc_mode() || requires_barriers(); > + const bool requires_uncompress = has_bitmap() && UseCompressedOops; > + const auto clear_obj = [&](intptr_t* at) { > + if (requires_uncompress) { > + HeapAccess<>::oop_store(reinterpret_cast(at), nullptr); > + } else { > + HeapAccess<>::oop_store(reinterpret_cast(at), nullptr); > + } > + }; > + > + if (requires_gc_barriers) { > + intptr_t* lockstack_start = start_address(); > + for (int i = 0; i < cnt; i++) { > + clear_obj(&lockstack_start[i]); > + } > + } > + set_lockstack_size(0); > + set_has_lockstack(false); > +} > + > void stackChunkOopDesc::print_on(bool verbose, outputStream* st) const { > if (*((juint*)this) == badHeapWordVal) { > st->print_cr("BAD WORD"); > diff --git a/src/hotspot/share/oops/stackChunkOop.hpp b/src/hotspot/share/oops/stackChunkOop.hpp > index 28e0576801e..928e94dd695 100644 > --- a/src/hotspot/share/oops/stackChunkOop.hpp > +++ b/src/hotspot/share/oops/stackChunkOop.hpp > @@ -167,6 +167,7 @@ class stackChunkOopDesc : public instanceOopDesc { > void fix_thawed_frame(const frame& f, const RegisterMapT* map); > > void copy_lockstack(oop* start); > + void clear_lockstack(); > > template src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2538: > >> 2536: Method* m = hf.interpreter_frame_method(); >> 2537: // For native frames we need to count parameters, possible alignment, plus the 2 extra words (temp oop/result handler). >> 2538: const int locals = !m->is_native() ? m->max_locals() : m->size_of_parameters() + frame::align_wiggle + 2; > > Is it possible to have these extra native frame slots size be a named constant / enum value on `frame`? I think it is used in a couple of places. I reverted this change and added an assert instead, since for native methods we always thaw the caller too, i.e. it will not be the bottom frame. I added a comment in the other two references for the extra native slots in continuationFreezeThaw_x86.inline.hpp. > src/hotspot/share/runtime/frame.cpp line 535: > >> 533: assert(get_register_address_in_stub(f, SharedRuntime::thread_register()) == (address)thread_addr, "wrong thread address"); >> 534: return thread_addr; >> 535: #endif > > With this ifdef, it seems like this belongs in the platform dependent part of the frame class. I moved it to the platform dependent files. > src/hotspot/share/runtime/objectMonitor.hpp line 184: > >> 182: // - We test for anonymous owner by testing for the lowest bit, therefore >> 183: // DEFLATER_MARKER must *not* have that bit set. >> 184: static const int64_t DEFLATER_MARKER = 2; > > The comments here should be updated / removed. They are talking about the lower bits of the owner being unset which is no longer true. (And talks about doing bit tests, which I do not think is done anywhere even without this patch). Removed the comments. > src/hotspot/share/runtime/objectMonitor.hpp line 186: > >> 184: static const int64_t DEFLATER_MARKER = 2; >> 185: >> 186: int64_t volatile _owner; // Either tid of owner, ANONYMOUS_OWNER_MARKER or DEFLATER_MARKER. > > Suggestion: > > int64_t volatile _owner; // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER. Fixed. > src/hotspot/share/runtime/objectMonitor.inline.hpp line 50: > >> 48: inline int64_t ObjectMonitor::owner_from(oop vthread) { >> 49: int64_t tid = java_lang_Thread::thread_id(vthread); >> 50: assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable"); > > Suggestion: > > assert(tid >= ThreadIdentifier::initial() && tid < ThreadIdentifier::current(), "must be reasonable"); Fixed. > src/hotspot/share/runtime/synchronizer.cpp line 1467: > >> 1465: markWord dmw = inf->header(); >> 1466: assert(dmw.is_neutral(), "invariant: header=" INTPTR_FORMAT, dmw.value()); >> 1467: if (inf->is_owner_anonymous() && inflating_thread != nullptr) { > > Are these `LM_LEGACY` + `ANONYMOUS_OWNER` changes still required now that `LM_LEGACY` does no freeze? Yes, it's just a consequence of using tid as the owner, not really related to freezing. So when a thread inflates a monitor that is already owned we cannot store the BasicLock* in the _owner field anymore, since it can clash with some tid, so we mark it as anonymously owned instead. The owner will fix it here when trying to get the monitor, as we do with LM_LIGHTWEIGHT. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809745804 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809746249 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809746397 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809753868 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809747046 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809749481 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809749657 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826149674 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826148888 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813222417 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809749805 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811244844 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811244206 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823317839 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809750408 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809750552 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809750685 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830229529 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809754940 From aph at openjdk.org Wed Nov 6 17:40:01 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 6 Nov 2024 17:40:01 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 15:37:23 GMT, Andrew Haley wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 60: > >> 58: >> 59: assert(LockingMode != LM_LIGHTWEIGHT, "lightweight locking should use fast_lock_lightweight"); >> 60: assert_different_registers(oop, box, tmp, disp_hdr, rscratch2); > > Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake. > Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility. Note also that `inc_held_monitor_count` clobbers `rscratch2`. That might be worth a comment at the call site. I guess `inc_held_monitor_count` is so hot that we can't push and pop scratch registers, in which case it'd clobber nothing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810985771 From aph at openjdk.org Wed Nov 6 17:40:01 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 6 Nov 2024 17:40:01 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 15:48:43 GMT, Andrew Haley wrote: >> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 60: >> >>> 58: >>> 59: assert(LockingMode != LM_LIGHTWEIGHT, "lightweight locking should use fast_lock_lightweight"); >>> 60: assert_different_registers(oop, box, tmp, disp_hdr, rscratch2); >> >> Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake. >> Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility. > > Note also that `inc_held_monitor_count` clobbers `rscratch2`. That might be worth a comment at the call site. > I guess `inc_held_monitor_count` is so hot that we can't push and pop scratch registers, in which case it'd clobber nothing. > Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake. Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility. Hmm, forget that. It's rather tricky code, that's true, but I think we're OK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810998545 From pchilanomate at openjdk.org Wed Nov 6 17:40:01 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:01 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 15:56:21 GMT, Andrew Haley wrote: >> Note also that `inc_held_monitor_count` clobbers `rscratch2`. That might be worth a comment at the call site. >> I guess `inc_held_monitor_count` is so hot that we can't push and pop scratch registers, in which case it'd clobber nothing. > >> Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake. Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility. > > Hmm, forget that. It's rather tricky code, that's true, but I think we're OK. I see we are already using rscratch1 in these locking macros so I could change it to use that instead. But looking at all other macros in this file we are already using rscratch1 and rscratch2 too, so I think we would be fine either way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813513144 From coleenp at openjdk.org Wed Nov 6 17:40:01 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:40:01 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 02:09:33 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 380: >> >>> 378: lea(t2_owner_addr, owner_address); >>> 379: >>> 380: // CAS owner (null => current thread id). >> >> I think we should be more careful when and where we talk about thread id and lock id respectively. Given that `switchToCarrierThread` switches the thread, but not the lock id. We should probably define and talk about the lock id when it comes to locking, as saying thread id may be incorrect. >> >> Then there is also the different thread ids, the OS level one, and the java level one. (But not sure how to reconcile this without causing confusion) > > Fixed the comments to refer to _lock_id. Even without the switchToCarrierThread case I think that's the correct thing to do. yes, we preferred lock_id here which is the same as the Java version of thread id, but not the same as the os thread-id. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811583503 From pchilanomate at openjdk.org Wed Nov 6 17:40:01 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:01 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Wed, 23 Oct 2024 22:59:19 GMT, Coleen Phillimore wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 135: > >> 133: assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame"); >> 134: intptr_t* lspp = f.addr_at(frame::interpreter_frame_last_sp_offset); >> 135: *lspp = f.unextended_sp() - f.fp(); > > Can you write a comment what this is doing briefly and why? Added comment. > src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1550: > >> 1548: #endif /* ASSERT */ >> 1549: >> 1550: push_cont_fastpath(); > > One of the callers of this gives a clue what it does. > > __ push_cont_fastpath(); // Set JavaThread::_cont_fastpath to the sp of the oldest interpreted frame we know about > > Why do you do this here? Oh please more comments... _cont_fastpath is what we check in freeze_internal to decide if we can take the fast path. Since we are calling from the interpreter we have to take the slow path. Added a comment. > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5354: > >> 5352: str(rscratch2, dst); >> 5353: Label ok; >> 5354: tbz(rscratch2, 63, ok); > > 63? Does this really need to have underflow checking? That would alleviate the register use concerns if it didn't. And it's only for legacy locking which should be stable until it's removed. I can remove the check. I don't think it hurts either though. Also we can actually just use rscratch1 in the ASSERT case. > src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 2032: > >> 2030: // Force freeze slow path in case we try to preempt. We will pin the >> 2031: // vthread to the carrier (see FreezeBase::recurse_freeze_native_frame()). >> 2032: __ push_cont_fastpath(); > > We need to do this because we might freeze, so JavaThread::_cont_fastpath should be set in case we do? Right. We want to take the slow path to find the compiled native wrapper frame and fail to freeze. Otherwise the fast path won't find it since we don't walk the stack. > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 231: > >> 229: >> 230: void MacroAssembler::inc_held_monitor_count(Register tmp) { >> 231: Address dst = Address(xthread, JavaThread::held_monitor_count_offset()); > > Address dst(xthread, JavaThread::held_monitor_count_offset()); Done. > src/hotspot/share/interpreter/oopMapCache.cpp line 268: > >> 266: } >> 267: >> 268: int num_oops() { return _num_oops; } > > I can't find what uses this from OopMapCacheEntry. It's needed for verification in VerifyStackChunkFrameClosure. It's called in OopMapCacheEntry::fill_for_native(), and we get there from here: https://github.com/openjdk/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/x86/stackChunkFrameStream_x86.inline.hpp#L114 > src/hotspot/share/runtime/continuation.cpp line 89: > >> 87: // we would incorrectly throw it during the unmount logic in the carrier. >> 88: if (_target->has_async_exception_condition()) { >> 89: _failed = false; > > This says "Don't" but then failed is false which doesn't make sense. Should it be true? Yes, good catch. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1275: > >> 1273: >> 1274: if (caller.is_interpreted_frame()) { >> 1275: _total_align_size += frame::align_wiggle; > > Please put a comment here about frame align-wiggle. I removed this case since it can never happen. The caller has to be compiled, and we assert that at the beginning. This was a leftover from the forceful preemption at a safepoint work. I removed the similar code in recurse_thaw_stub_frame. I added a comment for the compiled and native cases though. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1278: > >> 1276: } >> 1277: >> 1278: patch(f, hf, caller, false /*is_bottom_frame*/); > > I also forgot what patch does. Can you add a comment here too? I added a comment where it is defined since it is used in several places. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1550: > >> 1548: assert(!cont.is_empty(), ""); >> 1549: // This is done for the sake of the enterSpecial frame >> 1550: StackWatermarkSet::after_unwind(thread); > > Is there a new place for this StackWatermark code? I removed it. We have already processed the enterSpecial frame as part of flush_stack_processing(), in fact we processed up to the caller of `Continuation.run()`. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2235: > >> 2233: assert(!mon_acquired || mon->has_owner(_thread), "invariant"); >> 2234: if (!mon_acquired) { >> 2235: // Failed to aquire monitor. Return to enterSpecial to unmount again. > > typo: acquire Fixed. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2492: > >> 2490: void ThawBase::throw_interrupted_exception(JavaThread* current, frame& top) { >> 2491: ContinuationWrapper::SafepointOp so(current, _cont); >> 2492: // Since we might safepoint set the anchor so that the stack can we walked. > > typo: can be walked Fixed. > src/hotspot/share/runtime/javaThread.hpp line 334: > >> 332: bool _pending_jvmti_unmount_event; // When preempting we post unmount event at unmount end rather than start >> 333: bool _on_monitor_waited_event; // Avoid callee arg processing for enterSpecial when posting waited event >> 334: ObjectMonitor* _contended_entered_monitor; // Monitor por pending monitor_contended_entered callback > > typo: Monitor **for** pending_contended_entered callback Fixed. > src/hotspot/share/runtime/objectMonitor.cpp line 876: > >> 874: // and in doing so avoid some transitions ... >> 875: >> 876: // For virtual threads that are pinned do a timed-park instead, to > > I had trouble parsing this first sentence. I think it needs a comma after pinned and remove the comma after instead. Fixed. > src/hotspot/share/runtime/objectMonitor.cpp line 2305: > >> 2303: } >> 2304: >> 2305: void ObjectMonitor::Initialize2() { > > Can you put a comment why there's a second initialize function? Presumably after some state is set. Added comment. > src/hotspot/share/runtime/objectMonitor.hpp line 43: > >> 41: // ParkEvent instead. Beware, however, that the JVMTI code >> 42: // knows about ObjectWaiters, so we'll have to reconcile that code. >> 43: // See next_waiter(), first_waiter(), etc. > > Also a nice cleanup. Did you reconcile the JVMTI code? We didn't remove the ObjectWaiter. As for the presence of virtual threads in the list, we skip them in JVMTI get_object_monitor_usage. We already degraded virtual thread support for GetObjectMonitorUsage. > src/hotspot/share/runtime/objectMonitor.hpp line 71: > >> 69: bool is_wait() { return _is_wait; } >> 70: bool notified() { return _notified; } >> 71: bool at_reenter() { return _at_reenter; } > > should these be const member functions? Yes, changed to const. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816658344 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816660065 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813516395 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816660542 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813519648 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819462987 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816660817 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816661388 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816661733 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816662247 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823583906 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823583954 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823583822 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816662554 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816663065 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819463651 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819463958 From dlong at openjdk.org Wed Nov 6 17:40:01 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:01 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 02:18:19 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 300: >> >>> 298: CodeBlob* cb = top.cb(); >>> 299: >>> 300: if (cb->frame_size() == 2) { >> >> Is this a filter to identify c2 runtime stubs? Is there some other property we can check or assert here? This assumes that no other runtime frame will have this size. > > We could also check the caller of the runtime frame, something like: > > #ifdef ASSERT > RegisterMap map(JavaThread::current(), > RegisterMap::UpdateMap::skip, > RegisterMap::ProcessFrames::skip, > RegisterMap::WalkContinuation::skip); > frame caller = top.sender(&map); > assert(caller.is_compiled_frame(), ""); > assert(cb->frame_size() > 2 || caller.cb()->as_nmethod()->is_compiled_by_c2(), ""); > #endif > > Ideally we would want to check if cb->frame_size() is different than the actual?size of the physical frame. I agree, checking for frame_size() == 2 seems fragile. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817458483 From dlong at openjdk.org Wed Nov 6 17:40:02 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Sat, 26 Oct 2024 00:27:25 GMT, Dean Long wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 310: > >> 308: sp -= 2; >> 309: sp[-2] = sp[0]; >> 310: sp[-1] = sp[1]; > > This also seems fragile. This seems to depend on an intimate knowledge of what the stub will do when returning. We don't need this when doing a regular return from the native call, so why do we need it here? I'm guessing freeze/thaw hasn't restored the state quite the same way that the stub expects. Why is this needed for C2 and not C1? Could the problem be solved with a resume adapter instead, like the interpreter uses? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817556946 From pchilanomate at openjdk.org Wed Nov 6 17:40:02 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Sat, 26 Oct 2024 01:58:30 GMT, Dean Long wrote: >> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 310: >> >>> 308: sp -= 2; >>> 309: sp[-2] = sp[0]; >>> 310: sp[-1] = sp[1]; >> >> This also seems fragile. This seems to depend on an intimate knowledge of what the stub will do when returning. We don't need this when doing a regular return from the native call, so why do we need it here? I'm guessing freeze/thaw hasn't restored the state quite the same way that the stub expects. Why is this needed for C2 and not C1? > > Could the problem be solved with a resume adapter instead, like the interpreter uses? The issue with the c2 runtime stub on aarch64 (and riscv) is that cb->frame_size() doesn't match the size of the physical frame, it's short by 2 words. I explained the reason for that in the comment above. So for a regular return we don't care about last_Java_sp, rsp will point to the same place as before the call when we return. But when resuming for the preemption case, the rsp will be two words short, since when we freezed the runtime stub we freeze 2 words less (and we have to do that to be able to correctly get the sender when we walk it). One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. I guess this was a micro optimization. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819593485 From pchilanomate at openjdk.org Wed Nov 6 17:40:02 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 18:56:25 GMT, Patricio Chilano Mateo wrote: >> Could the problem be solved with a resume adapter instead, like the interpreter uses? > > The issue with the c2 runtime stub on aarch64 (and riscv) is that cb->frame_size() doesn't match the size of the physical frame, it's short by 2 words. I explained the reason for that in the comment above. So for a regular return we don't care about last_Java_sp, rsp will point to the same place as before the call when we return. But when resuming for the preemption case, the rsp will be two words short, since when we freezed the runtime stub we freeze 2 words less (and we have to do that to be able to correctly get the sender when we walk it). > One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. I guess this was a micro optimization. > Could the problem be solved with a resume adapter instead, like the interpreter uses? > It will just move the task of adjusting the size of the frame somewhere else. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819594475 From dlong at openjdk.org Wed Nov 6 17:40:02 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 18:56:58 GMT, Patricio Chilano Mateo wrote: >> The issue with the c2 runtime stub on aarch64 (and riscv) is that cb->frame_size() doesn't match the size of the physical frame, it's short by 2 words. I explained the reason for that in the comment above. So for a regular return we don't care about last_Java_sp, rsp will point to the same place as before the call when we return. But when resuming for the preemption case, the rsp will be two words short, since when we freezed the runtime stub we freeze 2 words less (and we have to do that to be able to correctly get the sender when we walk it). >> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. I guess this was a micro optimization. > >> Could the problem be solved with a resume adapter instead, like the interpreter uses? >> > It will just move the task of adjusting the size of the frame somewhere else. > One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. If that would solve the problem, then that must mean we save/freeze last_Java_pc as part of the virtual thread's state. So why can't we just call make_walkable() before we freeze, to fix things up as if C2 had stored last_Java_pc to the anchor? Then freeze could assert that the thread is already walkable. I'm surprised it doesn't already. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819896849 From pchilanomate at openjdk.org Wed Nov 6 17:40:02 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 23:38:43 GMT, Dean Long wrote: >>> Could the problem be solved with a resume adapter instead, like the interpreter uses? >>> >> It will just move the task of adjusting the size of the frame somewhere else. > >> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. > > If that would solve the problem, then that must mean we save/freeze last_Java_pc as part of the virtual thread's state. So why can't we just call make_walkable() before we freeze, to fix things up as if C2 had stored last_Java_pc to the anchor? Then freeze could assert that the thread is already walkable. I'm surprised it doesn't already. The issue is not when we make the frame walkable but how. The way it currently works is by pushing the last_Java_pc to the stack in the runtime stub before making the call to the VM (plus an alignment word). So to make the frame walkable we do last_Java_sp[-1] in the VM. But this approach creates a mismatch between the recorded cb->frame_size() (which starts from last_Java_sp) vs the physical size of the frame which starts with rsp right before the call. This is what the c2 runtime stub code for aarch64 looks like: 0xffffdfdba584: sub sp, sp, #0x10 0xffffdfdba588: stp x29, x30, [sp] 0xffffdfdba58c: ldrb w8, [x28, #1192] 0xffffdfdba590: cbz x8, 0xffffdfdba5a8 0xffffdfdba594: mov x8, #0x4ba0 0xffffdfdba598: movk x8, #0xf6a8, lsl #16 0xffffdfdba59c: movk x8, #0xffff, lsl #32 0xffffdfdba5a0: mov x0, x28 0xffffdfdba5a4: blr x8 0xffffdfdba5a8: mov x9, sp 0xffffdfdba5ac: str x9, [x28, #1000] <------- store last_Java_sp 0xffffdfdba5b0: mov x0, x1 0xffffdfdba5b4: mov x1, x2 0xffffdfdba5b8: mov x2, x28 0xffffdfdba5bc: adr x9, 0xffffdfdba5d4 0xffffdfdba5c0: mov x8, #0xe6a4 0xffffdfdba5c4: movk x8, #0xf717, lsl #16 0xffffdfdba5c8: movk x8, #0xffff, lsl #32 0xffffdfdba5cc: stp xzr, x9, [sp, #-16]! <------- Push two extra words 0xffffdfdba5d0: blr x8 0xffffdfdba5d4: nop 0xffffdfdba5d8: movk xzr, #0x0 0xffffdfdba5dc: movk xzr, #0x0 0xffffdfdba5e0: add sp, sp, #0x10 <------- Remove two extra words 0xffffdfdba5e4: str xzr, [x28, #1000] 0xffffdfdba5e8: str xzr, [x28, #1008] 0xffffdfdba5ec: ldr x10, [x28, #8] 0xffffdfdba5f0: cbnz x10, 0xffffdfdba600 0xffffdfdba5f4: ldp x29, x30, [sp] 0xffffdfdba5f8: add sp, sp, #0x10 0xffffdfdba5fc: ret 0xffffdfdba600: ldp x29, x30, [sp] 0xffffdfdba604: add sp, sp, #0x10 0xffffdfdba608: adrp x8, 0xffffdfc30000 0xffffdfdba60c: add x8, x8, #0x80 0xffffdfdba610: br x8 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821389434 From dlong at openjdk.org Wed Nov 6 17:40:02 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 29 Oct 2024 19:01:03 GMT, Patricio Chilano Mateo wrote: >>> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. >> >> If that would solve the problem, then that must mean we save/freeze last_Java_pc as part of the virtual thread's state. So why can't we just call make_walkable() before we freeze, to fix things up as if C2 had stored last_Java_pc to the anchor? Then freeze could assert that the thread is already walkable. I'm surprised it doesn't already. > > The issue is not when we make the frame walkable but how. The way it currently works is by pushing the last_Java_pc to the stack in the runtime stub before making the call to the VM (plus an alignment word). So to make the frame walkable we do last_Java_sp[-1] in the VM. But this approach creates a mismatch between the recorded cb->frame_size() (which starts from last_Java_sp) vs the physical size of the frame which starts with rsp right before the call. This is what the c2 runtime stub code for aarch64 looks like: > > > 0xffffdfdba584: sub sp, sp, #0x10 > 0xffffdfdba588: stp x29, x30, [sp] > 0xffffdfdba58c: ldrb w8, [x28, #1192] > 0xffffdfdba590: cbz x8, 0xffffdfdba5a8 > 0xffffdfdba594: mov x8, #0x4ba0 > 0xffffdfdba598: movk x8, #0xf6a8, lsl #16 > 0xffffdfdba59c: movk x8, #0xffff, lsl #32 > 0xffffdfdba5a0: mov x0, x28 > 0xffffdfdba5a4: blr x8 > 0xffffdfdba5a8: mov x9, sp > 0xffffdfdba5ac: str x9, [x28, #1000] <------- store last_Java_sp > 0xffffdfdba5b0: mov x0, x1 > 0xffffdfdba5b4: mov x1, x2 > 0xffffdfdba5b8: mov x2, x28 > 0xffffdfdba5bc: adr x9, 0xffffdfdba5d4 > 0xffffdfdba5c0: mov x8, #0xe6a4 > 0xffffdfdba5c4: movk x8, #0xf717, lsl #16 > 0xffffdfdba5c8: movk x8, #0xffff, lsl #32 > 0xffffdfdba5cc: stp xzr, x9, [sp, #-16]! <------- Push two extra words > 0xffffdfdba5d0: blr x8 > 0xffffdfdba5d4: nop > 0xffffdfdba5d8: movk xzr, #0x0 > 0xffffdfdba5dc: movk xzr, #0x0 > 0xffffdfdba5e0: add sp, sp, #0x10 <------- Remove two extra words > 0xffffdfdba5e4: str xzr, [x28, #1000] > 0xffffdfdba5e8: str xzr, [x28, #1008] > 0xffffdfdba5ec: ldr x10, [x28, #8] > 0xffffdfdba5f0: cbnz x10, 0xffffdfdba600 > 0xffffdfdba5f4: ldp x29, x30, [sp] > 0xffffdfdba5f8: add sp, sp, #0x10 > 0xffffdfdba5fc: ret > 0xffffdfdba600: ldp x29, x30, [sp] > 0xffffdfdba604: add sp, sp, #0x10 > 0xffffdfdba608: adrp x8, 0xffffdfc30000 > 0xffffdfdba60c: add x8, x8, #0x80 > 0xffffdfdba610: br x8 OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed? I also think we should fix the aarch64 c2 stub to just store last_Java_pc like you suggest. Adjusting the stack like this has in the past caused other problems, in particular making it hard to obtain safe stack traces during asynchronous profiling. It's still unclear to me exactly how we resume after preemption. It looks like we resume at last_Java_pc with rsp set based on last_Java_sp, which is why it needs to be adjusted. If that's the case, an alternative simplification for aarch64 is to set a different last_Java_pc that is preemption-friendly that skips the stack adjustment. In your example, last_Java_pc would be set to 0xffffdfdba5e4. I think it is a reasonable requirement that preemption can return to last_Java_pc/last_Java_sp without adjustments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823701666 From pchilanomate at openjdk.org Wed Nov 6 17:40:02 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 02:33:30 GMT, Dean Long wrote: > OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed? > It's not a bug, it's just that the code from the runtime stub only cares about the actual rsp, not last_Java_sp. We are returning to the pc right after the call so we need to adjust rsp to what the runtime stub expects. Both alternatives will work, either changing the runtime stub to set last pc and not push those two extra words, or your suggestion of just setting the last pc to the instruction after the adjustment. Either way it requires to change the c2 code though which I'm not familiar with. But if you can provide a patch I'm happy to apply it and we can remove this `possibly_adjust_frame()` method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824782389 From dlong at openjdk.org Wed Nov 6 17:40:02 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 16:27:05 GMT, Patricio Chilano Mateo wrote: >> OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed? I also think we should fix the aarch64 c2 stub to just store last_Java_pc like you suggest. Adjusting the stack like this has in the past caused other problems, in particular making it hard to obtain safe stack traces during asynchronous profiling. >> >> It's still unclear to me exactly how we resume after preemption. It looks like we resume at last_Java_pc with rsp set based on last_Java_sp, which is why it needs to be adjusted. If that's the case, an alternative simplification for aarch64 is to set a different last_Java_pc that is preemption-friendly that skips the stack adjustment. In your example, last_Java_pc would be set to 0xffffdfdba5e4. I think it is a reasonable requirement that preemption can return to last_Java_pc/last_Java_sp without adjustments. > >> OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed? >> > It's not a bug, it's just that the code from the runtime stub only cares about the actual rsp, not last_Java_sp. We are returning to the pc right after the call so we need to adjust rsp to what the runtime stub expects. Both alternatives will work, either changing the runtime stub to set last pc and not push those two extra words, or your suggestion of just setting the last pc to the instruction after the adjustment. Either way it requires to change the c2 code though which I'm not familiar with. But if you can provide a patch I'm happy to apply it and we can remove this `possibly_adjust_frame()` method. It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes. Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825498409 From dlong at openjdk.org Wed Nov 6 17:40:02 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 07:14:35 GMT, Dean Long wrote: >>> OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed? >>> >> It's not a bug, it's just that the code from the runtime stub only cares about the actual rsp, not last_Java_sp. We are returning to the pc right after the call so we need to adjust rsp to what the runtime stub expects. Both alternatives will work, either changing the runtime stub to set last pc and not push those two extra words, or your suggestion of just setting the last pc to the instruction after the adjustment. Either way it requires to change the c2 code though which I'm not familiar with. But if you can provide a patch I'm happy to apply it and we can remove this `possibly_adjust_frame()` method. > > It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes. Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative. Here's my suggested C2 change: diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad index d9c77a2f529..1e99db191ae 100644 --- a/src/hotspot/cpu/aarch64/aarch64.ad +++ b/src/hotspot/cpu/aarch64/aarch64.ad @@ -3692,14 +3692,13 @@ encode %{ __ post_call_nop(); } else { Label retaddr; + // Make the anchor frame walkable __ adr(rscratch2, retaddr); + __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset())); __ lea(rscratch1, RuntimeAddress(entry)); - // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc() - __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize))); __ blr(rscratch1); __ bind(retaddr); __ post_call_nop(); - __ add(sp, sp, 2 * wordSize); } if (Compile::current()->max_vector_size() > 0) { __ reinitialize_ptrue(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826252551 From pchilanomate at openjdk.org Wed Nov 6 17:40:02 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 20:08:51 GMT, Dean Long wrote: >> It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes. Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative. > > Here's my suggested C2 change: > > diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad > index d9c77a2f529..1e99db191ae 100644 > --- a/src/hotspot/cpu/aarch64/aarch64.ad > +++ b/src/hotspot/cpu/aarch64/aarch64.ad > @@ -3692,14 +3692,13 @@ encode %{ > __ post_call_nop(); > } else { > Label retaddr; > + // Make the anchor frame walkable > __ adr(rscratch2, retaddr); > + __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset())); > __ lea(rscratch1, RuntimeAddress(entry)); > - // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc() > - __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize))); > __ blr(rscratch1); > __ bind(retaddr); > __ post_call_nop(); > - __ add(sp, sp, 2 * wordSize); > } > if (Compile::current()->max_vector_size() > 0) { > __ reinitialize_ptrue(); Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code. @RealFYang I made the equivalent change for riscv, could you verify it's okay? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828186069 From fyang at openjdk.org Wed Nov 6 17:40:02 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 18:18:38 GMT, Patricio Chilano Mateo wrote: >> Here's my suggested C2 change: >> >> diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad >> index d9c77a2f529..1e99db191ae 100644 >> --- a/src/hotspot/cpu/aarch64/aarch64.ad >> +++ b/src/hotspot/cpu/aarch64/aarch64.ad >> @@ -3692,14 +3692,13 @@ encode %{ >> __ post_call_nop(); >> } else { >> Label retaddr; >> + // Make the anchor frame walkable >> __ adr(rscratch2, retaddr); >> + __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset())); >> __ lea(rscratch1, RuntimeAddress(entry)); >> - // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc() >> - __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize))); >> __ blr(rscratch1); >> __ bind(retaddr); >> __ post_call_nop(); >> - __ add(sp, sp, 2 * wordSize); >> } >> if (Compile::current()->max_vector_size() > 0) { >> __ reinitialize_ptrue(); > > Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code. > @RealFYang I made the equivalent change for riscv, could you verify it's okay? @pchilano : Hi, Great to see `possibly_adjust_frame()` go away. Nice cleanup! `hotspot_loom jdk_loom` still test good with both release and fastdebug builds on linux-riscv64 platform. BTW: I noticed one more return miss prediction case which I think was previously missed in https://github.com/openjdk/jdk/pull/21565/commits/32840de91953a5e50c85217f2a51fc5a901682a2 Do you mind adding following small addon change to fix it? Thanks. diff --git a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp index 84a292242c3..ac28f4b3514 100644 --- a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp +++ b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp @@ -1263,10 +1263,10 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) { if (LockingMode != LM_LEGACY) { // Check preemption for Object.wait() Label not_preempted; - __ ld(t0, Address(xthread, JavaThread::preempt_alternate_return_offset())); - __ beqz(t0, not_preempted); + __ ld(t1, Address(xthread, JavaThread::preempt_alternate_return_offset())); + __ beqz(t1, not_preempted); __ sd(zr, Address(xthread, JavaThread::preempt_alternate_return_offset())); - __ jr(t0); + __ jr(t1); __ bind(native_return); __ restore_after_resume(true /* is_native */); // reload result_handler ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828797495 From pchilanomate at openjdk.org Wed Nov 6 17:40:02 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 06:30:55 GMT, Fei Yang wrote: >> Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code. >> @RealFYang I made the equivalent change for riscv, could you verify it's okay? > > @pchilano : Hi, Great to see `possibly_adjust_frame()` go away. Nice cleanup! > `hotspot_loom jdk_loom` still test good with both release and fastdebug builds on linux-riscv64 platform. > > BTW: I noticed one more return miss prediction case which I think was previously missed in https://github.com/openjdk/jdk/pull/21565/commits/32840de91953a5e50c85217f2a51fc5a901682a2 > Do you mind adding following small addon change to fix it? Thanks. > > diff --git a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp > index 84a292242c3..ac28f4b3514 100644 > --- a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp > +++ b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp > @@ -1263,10 +1263,10 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) { > if (LockingMode != LM_LEGACY) { > // Check preemption for Object.wait() > Label not_preempted; > - __ ld(t0, Address(xthread, JavaThread::preempt_alternate_return_offset())); > - __ beqz(t0, not_preempted); > + __ ld(t1, Address(xthread, JavaThread::preempt_alternate_return_offset())); > + __ beqz(t1, not_preempted); > __ sd(zr, Address(xthread, JavaThread::preempt_alternate_return_offset())); > - __ jr(t0); > + __ jr(t1); > __ bind(native_return); > __ restore_after_resume(true /* is_native */); > // reload result_handler Thanks for checking. Added changes to `TemplateInterpreterGenerator::generate_native_entry`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829457335 From dholmes at openjdk.org Wed Nov 6 17:40:02 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 13:11:18 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1550: >> >>> 1548: #endif /* ASSERT */ >>> 1549: >>> 1550: push_cont_fastpath(); >> >> One of the callers of this gives a clue what it does. >> >> __ push_cont_fastpath(); // Set JavaThread::_cont_fastpath to the sp of the oldest interpreted frame we know about >> >> Why do you do this here? Oh please more comments... > > _cont_fastpath is what we check in freeze_internal to decide if we can take the fast path. Since we are calling from the interpreter we have to take the slow path. Added a comment. It seems somewhat of an oxymoron that to force a slow path we push a fastpath. ??? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818245043 From pchilanomate at openjdk.org Wed Nov 6 17:40:02 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <02jUq4u02-eLrK-60b82BZKUo-M9WmExcZqQrZpRlog=.c929b191-f5d3-4f07-9ba6-5c60602e0441@github.com> On Mon, 28 Oct 2024 00:53:40 GMT, David Holmes wrote: >> _cont_fastpath is what we check in freeze_internal to decide if we can take the fast path. Since we are calling from the interpreter we have to take the slow path. Added a comment. > > It seems somewhat of an oxymoron that to force a slow path we push a fastpath. ??? Yes, I find the name confusing too. But since this is pre-existent and to avoid the noise in the PR I would rather not change it here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819831895 From coleenp at openjdk.org Wed Nov 6 17:40:03 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <02jUq4u02-eLrK-60b82BZKUo-M9WmExcZqQrZpRlog=.c929b191-f5d3-4f07-9ba6-5c60602e0441@github.com> References: <02jUq4u02-eLrK-60b82BZKUo-M9WmExcZqQrZpRlog=.c929b191-f5d3-4f07-9ba6-5c60602e0441@github.com> Message-ID: On Mon, 28 Oct 2024 22:04:23 GMT, Patricio Chilano Mateo wrote: >> It seems somewhat of an oxymoron that to force a slow path we push a fastpath. ??? > > Yes, I find the name confusing too. But since this is pre-existent and to avoid the noise in the PR I would rather not change it here. Yes the comment did seem to contradict the name of the function. But it's something we can re-examine at some later time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819858784 From pchilanomate at openjdk.org Wed Nov 6 17:40:03 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.fb41dbbd-8e96-4b54-920b-3f3759579de8@github.com> References: <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.fb41dbbd-8e96-4b54-920b-3f3759579de8@github.com> Message-ID: On Mon, 28 Oct 2024 18:51:31 GMT, Dean Long wrote: >> Its indeed difficult to see how the value is propagaged. I think it goes like this: >> >> - read from the frame anchor and set as pc of `_last_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L517 >> - copied to the result of `new_heap_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L99 >> - Written to the frame here: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L177 >> - Here it's done when freezing fast: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L771 > > Thanks, that's what I was missing. Right, whatever address is in last_Java_pc is the one we are going to freeze for that frame, i.e. that's the address we are going to return to when resuming. For the freeze slow path this was already how it worked before this PR. For the fast path I added a case to correct the last pc that we freeze on preemption, as Richard pointed out in the last link, since otherwise we would freeze a different one. The idea is that if we already freeze the right pc, then on thaw we don't have to do anything. Note that when there are interpreter frames on the stack we always take the slow path. > If preemption was cancelled, we skip over the cleanup. > We only skip the cleanup for the enterSpecial frame since we are going to call thaw again, all other frames are removed: https://github.com/openjdk/jdk/pull/21565/files#diff-b938ab8a7bd9f57eb02271e2dd24a305bca30f06e9f8b028e18a139c4908ec92R3791 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819595482 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819770854 From rrich at openjdk.org Wed Nov 6 17:40:03 2024 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Sat, 26 Oct 2024 01:40:41 GMT, Dean Long wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1555: > >> 1553: // Make VM call. In case of preemption set last_pc to the one we want to resume to. >> 1554: adr(rscratch1, resume_pc); >> 1555: str(rscratch1, Address(rthread, JavaThread::last_Java_pc_offset())); > > Is it really needed to set an alternative last_Java_pc()? I couldn't find where it's used in a way that would require a different value. Its indeed difficult to see how the value is propagaged. I think it goes like this: - read from the frame anchor and set as pc of `_last_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L517 - copied to the result of `new_heap_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L99 - Written to the frame here: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L177 - Here it's done when freezing fast: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L771 > src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1567: > >> 1565: >> 1566: // In case of preemption, this is where we will resume once we finally acquire the monitor. >> 1567: bind(resume_pc); > > If the idea is that we return directly to `resume_pc`, because of `last_Java_pc`(), then why do we poll `preempt_alternate_return_offset` above? The address at `preempt_alternate_return_offset` is how to continue immediately after the call was preempted. It's where the vthread frames are popped off the carrier stack. At `resume_pc` execution continues when the vthread becomes runnable again. Before its frames were thawed and copied to its carriers stack. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3796: > >> 3794: __ movbool(rscratch1, Address(r15_thread, JavaThread::preemption_cancelled_offset())); >> 3795: __ testbool(rscratch1); >> 3796: __ jcc(Assembler::notZero, preemption_cancelled); > > If preemption was canceled, then I wouldn't expect patch_return_pc_with_preempt_stub() to get called. Does this mean preemption can get canceled (asynchronously be a different thread?) even afgter patch_return_pc_with_preempt_stub() is called? The comment at the `preemption_cancelled` label explains that a second attempt to acquire the monitor succeeded after freezing. The vthread has to continue execution. For that its frames (removed just above) need to be thawed again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817702223 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817702986 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817703994 From coleenp at openjdk.org Wed Nov 6 17:40:03 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 15:49:32 GMT, Andrew Haley wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5341: > >> 5339: >> 5340: void MacroAssembler::inc_held_monitor_count() { >> 5341: Address dst = Address(rthread, JavaThread::held_monitor_count_offset()); > > Suggestion: > > // Clobbers: rscratch1 and rscratch2 > void MacroAssembler::inc_held_monitor_count() { > Address dst = Address(rthread, JavaThread::held_monitor_count_offset()); Also, is it better to have this without assignment. Which is a nit. Address dst(rthread, JavaThread::held_monitor_count_offset()); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811584584 From dlong at openjdk.org Wed Nov 6 17:40:03 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.fb41dbbd-8e96-4b54-920b-3f3759579de8@github.com> On Sat, 26 Oct 2024 06:51:08 GMT, Richard Reingruber wrote: >> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1555: >> >>> 1553: // Make VM call. In case of preemption set last_pc to the one we want to resume to. >>> 1554: adr(rscratch1, resume_pc); >>> 1555: str(rscratch1, Address(rthread, JavaThread::last_Java_pc_offset())); >> >> Is it really needed to set an alternative last_Java_pc()? I couldn't find where it's used in a way that would require a different value. > > Its indeed difficult to see how the value is propagaged. I think it goes like this: > > - read from the frame anchor and set as pc of `_last_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L517 > - copied to the result of `new_heap_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L99 > - Written to the frame here: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L177 > - Here it's done when freezing fast: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L771 Thanks, that's what I was missing. >> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1567: >> >>> 1565: >>> 1566: // In case of preemption, this is where we will resume once we finally acquire the monitor. >>> 1567: bind(resume_pc); >> >> If the idea is that we return directly to `resume_pc`, because of `last_Java_pc`(), then why do we poll `preempt_alternate_return_offset` above? > > The address at `preempt_alternate_return_offset` is how to continue immediately after the call was preempted. It's where the vthread frames are popped off the carrier stack. > > At `resume_pc` execution continues when the vthread becomes runnable again. Before its frames were thawed and copied to its carriers stack. OK, that makes sense now. >> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3796: >> >>> 3794: __ movbool(rscratch1, Address(r15_thread, JavaThread::preemption_cancelled_offset())); >>> 3795: __ testbool(rscratch1); >>> 3796: __ jcc(Assembler::notZero, preemption_cancelled); >> >> If preemption was canceled, then I wouldn't expect patch_return_pc_with_preempt_stub() to get called. Does this mean preemption can get canceled (asynchronously be a different thread?) even afgter patch_return_pc_with_preempt_stub() is called? > > The comment at the `preemption_cancelled` label explains that a second attempt to acquire the monitor succeeded after freezing. The vthread has to continue execution. For that its frames (removed just above) need to be thawed again. If preemption was cancelled, we skip over the cleanup. The native frames haven't been unwound yet. So when we call thaw, does it cleanup the native frames first, or does it copy the frames back on top of the existing frames (overwrite)? It seems like we could avoid redundant copying if we could somehow throw out the freeze data and use the native frames still on the stack, which would probably involve not patching in this stub until we know that the preemption wasn't canceled. Some some finalize actions would be delated, like a two-stage commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819586705 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819605366 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819657858 From aboldtch at openjdk.org Wed Nov 6 17:40:03 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Wed, 23 Oct 2024 00:08:54 GMT, Coleen Phillimore wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5341: >> >>> 5339: >>> 5340: void MacroAssembler::inc_held_monitor_count() { >>> 5341: Address dst = Address(rthread, JavaThread::held_monitor_count_offset()); >> >> Suggestion: >> >> // Clobbers: rscratch1 and rscratch2 >> void MacroAssembler::inc_held_monitor_count() { >> Address dst = Address(rthread, JavaThread::held_monitor_count_offset()); > > Also, is it better to have this without assignment. Which is a nit. > Address dst(rthread, JavaThread::held_monitor_count_offset()); The `=` in a variable definition is always construction, never assignment. That said, I also prefer `Address dst(rthread, JavaThread::held_monitor_count_offset());` Less redundant information. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811925424 From pchilanomate at openjdk.org Wed Nov 6 17:40:03 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> References: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> Message-ID: On Wed, 30 Oct 2024 12:48:02 GMT, Fredrik Bredberg wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 945: > >> 943: >> 944: void inc_held_monitor_count(); >> 945: void dec_held_monitor_count(); > > I prefer to pass the `tmp` register as it's done in PPC. Manual register allocation is hard as it is, hiding what registers are clobbered makes it even harder. > > Suggestion: > > void inc_held_monitor_count(Register tmp); > void dec_held_monitor_count(Register tmp); Changed. > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 740: > >> 738: void MacroAssembler::clobber_nonvolatile_registers() { >> 739: BLOCK_COMMENT("clobber nonvolatile registers {"); >> 740: Register regs[] = { > > Maybe I've worked in the embedded world for too, but it's always faster and safer to store arrays with values that never change in read only memory. > Suggestion: > > static const Register regs[] = { Added. > src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273: > >> 271: ? frame_sp + fsize - frame::sender_sp_offset >> 272: // we need to re-read fp because it may be an oop and we might have fixed the frame. >> 273: : *(intptr_t**)(hf.sp() - 2); > > Suggestion: > > : *(intptr_t**)(hf.sp() - frame::sender_sp_offset); Changed. > src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 793: > >> 791: >> 792: void inc_held_monitor_count(Register tmp = t0); >> 793: void dec_held_monitor_count(Register tmp = t0); > > I prefer if we don't use any default argument. Manual register allocation is hard as it is, hiding what registers are clobbered makes it even harder. Also it would make it more in line with how it's done in PPC. > Suggestion: > > void inc_held_monitor_count(Register tmp); > void dec_held_monitor_count(Register tmp); Changed. > src/hotspot/share/runtime/continuation.cpp line 125: > >> 123: }; >> 124: >> 125: static bool is_safe_vthread_to_preempt_for_jvmti(JavaThread* target, oop vthread) { > > I think the code reads better if you change to `is_safe_to_preempt_vthread_for_jvmti`. > Suggestion: > > static bool is_safe_to_preempt_vthread_for_jvmti(JavaThread* target, oop vthread) { I renamed it to is_vthread_safe_to_preempt_for_jvmti. > src/hotspot/share/runtime/continuation.cpp line 135: > >> 133: #endif // INCLUDE_JVMTI >> 134: >> 135: static bool is_safe_vthread_to_preempt(JavaThread* target, oop vthread) { > > I think the code reads better if you change to `is_safe_to_preempt_vthread`. > Suggestion: > > static bool is_safe_to_preempt_vthread(JavaThread* target, oop vthread) { I renamed it to is_vthread_safe_to_preempt, which I think it reads even better. > src/hotspot/share/runtime/continuation.hpp line 66: > >> 64: >> 65: enum preempt_kind { >> 66: freeze_on_monitorenter = 1, > > Is there a reason why the first enumerator doesn't start at zero? There was one value that meant to be for the regular freeze from java. But it was not used so I removed it. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889: > >> 887: return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller); >> 888: } else { >> 889: return freeze_pinned_native; > > Can you add a comment about why you only end up here for `freeze_pinned_native`, cause that is not clear to me. We just found a frame that can't be freezed, most likely the call_stub or upcall_stub which indicate there are further natives frames up the stack. I added a comment. > src/hotspot/share/runtime/objectMonitor.cpp line 1193: > >> 1191: } >> 1192: >> 1193: assert(node->TState == ObjectWaiter::TS_ENTER || node->TState == ObjectWaiter::TS_CXQ, ""); > > In `ObjectMonitor::resume_operation()` the exact same line is a `guarantee`- not an `assert`-line, is there any reason why? The `guarantee` tries to mimic the one here: https://github.com/openjdk/jdk/blob/ae82cc1ba101f6c566278f79a2e94bd1d1dd9efe/src/hotspot/share/runtime/objectMonitor.cpp#L1613 The assert at the epilogue is probably redundant. Also in `UnlinkAfterAcquire`, the else branch already asserts `ObjectWaiter::TS_CXQ`. I removed it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825101744 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825108078 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825100526 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825101246 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825107036 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825102359 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825103008 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825104666 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825106368 From fbredberg at openjdk.org Wed Nov 6 17:40:03 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 13:11:38 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 2032: >> >>> 2030: // Force freeze slow path in case we try to preempt. We will pin the >>> 2031: // vthread to the carrier (see FreezeBase::recurse_freeze_native_frame()). >>> 2032: __ push_cont_fastpath(); >> >> We need to do this because we might freeze, so JavaThread::_cont_fastpath should be set in case we do? > > Right. We want to take the slow path to find the compiled native wrapper frame and fail to freeze. Otherwise the fast path won't find it since we don't walk the stack. It would be nice if Coleen's question and your answer could be turned into a source comment. It really describes what's going more clearly than the current comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820487130 From pchilanomate at openjdk.org Wed Nov 6 17:40:03 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <6y2W6yaKBLRBbNe-yP_lenR4PMPbWb1Pa9wS3VpFGcI=.0465a56a-7cf4-4455-82c6-4097a3f8e456@github.com> On Tue, 29 Oct 2024 10:06:01 GMT, Fredrik Bredberg wrote: >> Right. We want to take the slow path to find the compiled native wrapper frame and fail to freeze. Otherwise the fast path won't find it since we don't walk the stack. > > It would be nice if Coleen's question and your answer could be turned into a source comment. It really describes what's going more clearly than the current comment. I updated the comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821386261 From pchilanomate at openjdk.org Wed Nov 6 17:40:03 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 15:50:15 GMT, Andrew Haley wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5357: > >> 5355: >> 5356: void MacroAssembler::dec_held_monitor_count() { >> 5357: Address dst = Address(rthread, JavaThread::held_monitor_count_offset()); > > Suggestion: > > // Clobbers: rscratch1 and rscratch2 > void MacroAssembler::dec_held_monitor_count() { > Address dst = Address(rthread, JavaThread::held_monitor_count_offset()); Added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813515113 From pchilanomate at openjdk.org Wed Nov 6 17:40:03 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <793XB62tkVT9w5ix7Ie1Hhxse4WnmnA7baNi__fs0Dw=.b1b308d9-8e8e-4d1d-8cd3-935c637679ab@github.com> On Wed, 23 Oct 2024 05:56:48 GMT, Axel Boldt-Christmas wrote: >> Also, is it better to have this without assignment. Which is a nit. >> Address dst(rthread, JavaThread::held_monitor_count_offset()); > > The `=` in a variable definition is always construction, never assignment. > > That said, I also prefer `Address dst(rthread, JavaThread::held_monitor_count_offset());` Less redundant information. Added comment and fixed dst definition. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813514402 From coleenp at openjdk.org Wed Nov 6 17:40:04 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Sat, 26 Oct 2024 01:51:12 GMT, Dean Long wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp line 119: > >> 117: return mask.num_oops() >> 118: + 1 // for the mirror oop >> 119: + (f.interpreter_frame_method()->is_native() ? 1 : 0) // temp oop slot > > Where is this temp oop slot set and used? It's the offset of the mirror passed to static native calls. It pre-existed saving the mirror in all frames to keep the Method alive, and is duplicated. I think this could be cleaned up someday, which would remove this special case. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1411: > >> 1409: // zero out fields (but not the stack) >> 1410: const size_t hs = oopDesc::header_size(); >> 1411: oopDesc::set_klass_gap(mem, 0); > > Why, bug fix or cleanup? This might confuse the change for JEP 450 since with CompactObjectHeaders there's no klass_gap, so depending on which change goes first, there will be conditional code here. Good question though, it looks like we only ever want to copy the payload of the object. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819394224 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823227312 From dlong at openjdk.org Wed Nov 6 17:40:04 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 16:39:14 GMT, Coleen Phillimore wrote: >> src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp line 119: >> >>> 117: return mask.num_oops() >>> 118: + 1 // for the mirror oop >>> 119: + (f.interpreter_frame_method()->is_native() ? 1 : 0) // temp oop slot >> >> Where is this temp oop slot set and used? > > It's the offset of the mirror passed to static native calls. It pre-existed saving the mirror in all frames to keep the Method alive, and is duplicated. I think this could be cleaned up someday, which would remove this special case. I tried to track down how interpreter_frame_num_oops() is used, and as far as I can tell, it is only used to compare against the bitmap in debug/verify code. So if this slot was added here, shouldn't there be a corresponding change for the bitmap? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819687576 From pchilanomate at openjdk.org Wed Nov 6 17:40:04 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 20:10:16 GMT, Dean Long wrote: >> It's the offset of the mirror passed to static native calls. It pre-existed saving the mirror in all frames to keep the Method alive, and is duplicated. I think this could be cleaned up someday, which would remove this special case. > > I tried to track down how interpreter_frame_num_oops() is used, and as far as I can tell, it is only used to compare against the bitmap in debug/verify code. So if this slot was added here, shouldn't there be a corresponding change for the bitmap? When creating the bitmap, processing oops in an interpreter frame is done with `frame::oops_interpreted_do()` which already counts this extra oop for native methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819757374 From coleenp at openjdk.org Wed Nov 6 17:40:04 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 21:01:47 GMT, Patricio Chilano Mateo wrote: >> I tried to track down how interpreter_frame_num_oops() is used, and as far as I can tell, it is only used to compare against the bitmap in debug/verify code. So if this slot was added here, shouldn't there be a corresponding change for the bitmap? > > When creating the bitmap, processing oops in an interpreter frame is done with `frame::oops_interpreted_do()` which already counts this extra oop for native methods. What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change? in MaskFillerForNative::set_one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819869538 From dlong at openjdk.org Wed Nov 6 17:40:04 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 22:52:40 GMT, Coleen Phillimore wrote: >> When creating the bitmap, processing oops in an interpreter frame is done with `frame::oops_interpreted_do()` which already counts this extra oop for native methods. > > What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change? in MaskFillerForNative::set_one. So it sounds like the adjustment at line 119 is a bug fix, but what I don't understand is why we weren't seeing problems before. Something in this PR exposed the need for this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819887000 From pchilanomate at openjdk.org Wed Nov 6 17:40:04 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 23:21:14 GMT, Dean Long wrote: >> What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change? in MaskFillerForNative::set_one. > > So it sounds like the adjustment at line 119 is a bug fix, but what I don't understand is why we weren't seeing problems before. Something in this PR exposed the need for this change. > What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change? in MaskFillerForNative::set_one. > The number of oops in the parameter's for this native method. For Object.wait() we have only one, the j.l.Object reference. But for synchronized native methods there could be more. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819908946 From pchilanomate at openjdk.org Wed Nov 6 17:40:04 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 23:59:55 GMT, Patricio Chilano Mateo wrote: >> So it sounds like the adjustment at line 119 is a bug fix, but what I don't understand is why we weren't seeing problems before. Something in this PR exposed the need for this change. > >> What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change? in MaskFillerForNative::set_one. >> > The number of oops in the parameter's for this native method. For Object.wait() we have only one, the j.l.Object reference. But for synchronized native methods there could be more. > So it sounds like the adjustment at line 119 is a bug fix, but what I don't understand is why we weren't seeing problems before. Something in this PR exposed the need for this change. > Because before this PR we never freezed interpreter frames belonging to native methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819909304 From fbredberg at openjdk.org Wed Nov 6 17:40:04 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> Message-ID: On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang wrote: >> Changed. > > Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? > > (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd) As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case. Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827720269 From fyang at openjdk.org Wed Nov 6 17:40:04 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> Message-ID: On Thu, 31 Oct 2024 20:02:31 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273: >> >>> 271: ? frame_sp + fsize - frame::sender_sp_offset >>> 272: // we need to re-read fp because it may be an oop and we might have fixed the frame. >>> 273: : *(intptr_t**)(hf.sp() - 2); >> >> Suggestion: >> >> : *(intptr_t**)(hf.sp() - frame::sender_sp_offset); > > Changed. Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826453713 From pchilanomate at openjdk.org Wed Nov 6 17:40:04 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> Message-ID: On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang wrote: >> Changed. > > Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? > > (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd) Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828190876 From fyang at openjdk.org Wed Nov 6 17:40:04 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> Message-ID: <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0b848799-b140-4d77-89aa-20ab815c68df@github.com> On Mon, 4 Nov 2024 18:23:23 GMT, Patricio Chilano Mateo wrote: >> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was? > >> Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted? >> > I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame. > As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case. Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. > Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted? I agree with @pchilano in that we are fine with these places. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828563437 From pchilanomate at openjdk.org Wed Nov 6 17:40:04 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> Message-ID: On Mon, 4 Nov 2024 18:22:42 GMT, Patricio Chilano Mateo wrote: >> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? >> >> (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd) > > Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was? > Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted? > I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828191725 From fyang at openjdk.org Wed Nov 6 17:40:04 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0b848799-b140-4d77-89aa-20ab815c68df@github.com> References: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0b848799-b140-4d77-89aa-20ab815c68df@github.com> Message-ID: On Tue, 5 Nov 2024 00:18:17 GMT, Fei Yang wrote: >>> Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted? >>> >> I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame. > >> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case. > > Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. > >> Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted? > > I agree with @pchilano in that we are fine with these places. > Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was? Or maybe `hf.sp() - frame::metadata_words`. But since we have several other occurrences, I would suggest we leave it as it was and go with a separate PR for the cleanup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828566395 From pchilanomate at openjdk.org Wed Nov 6 17:40:05 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:05 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0b848799-b140-4d77-89aa-20ab815c68df@github.com> Message-ID: On Tue, 5 Nov 2024 00:23:37 GMT, Fei Yang wrote: >>> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case. >> >> Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. >> >>> Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted? >> >> I agree with @pchilano in that we are fine with these places. > >> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was? > > Or maybe `hf.sp() - frame::metadata_words`. But since we have several other occurrences, I would suggest we leave it as it was and go with a separate PR for the cleanup. Reverted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828615499 From pchilanomate at openjdk.org Wed Nov 6 17:40:05 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:05 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/x86/assembler_x86.cpp line 2866: >> >>> 2864: emit_int32(0); >>> 2865: } >>> 2866: } >> >> Is it possible to make this more general and explicit instead of a sequence of bytes? >> >> Something along the lines of: >> ```C++ >> const address tar = L.is_bound() ? target(L) : pc(); >> const Address adr = Address(checked_cast(tar - pc()), tar, relocInfo::none); >> >> InstructionMark im(this); >> emit_prefix_and_int8(get_prefixq(adr, dst), (unsigned char)0x8D); >> if (!L.is_bound()) { >> // Patch @0x8D opcode >> L.add_patch_at(code(), CodeBuffer::locator(offset() - 1, sect())); >> } >> // Register and [rip+disp] operand >> emit_modrm(0b00, raw_encode(dst), 0b101); >> // Adjust displacement by sizeof lea instruction >> int32_t disp = adr.disp() - checked_cast(pc() - inst_mark() + sizeof(int32_t)); >> assert(is_simm32(disp), "must be 32bit offset [rip+offset]"); >> emit_int32(disp); >> >> >> and then in `pd_patch_instruction` simply match `op == 0x8D /* lea */`. > > I'll test it out but looks fine. Done. I simplified the code a bit to make it more readable. It also follows the current style of keeping the cases separate. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811237106 From dlong at openjdk.org Wed Nov 6 17:40:05 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:05 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Mon, 28 Oct 2024 20:49:45 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2382: >> >>> 2380: __ bind(after_transition); >>> 2381: >>> 2382: if (LockingMode != LM_LEGACY && method->is_object_wait0()) { >> >> It bothers me that we have to add a check for a specific native method in this code (notwithstanding there are already some checks in relation to hashCode). As a follow up I wonder if we can deal with wait-preemption by rewriting the Java code, instead of special casing the wait0 native code? > > Not sure. We would have to return from wait0 and immediately clear the physical stack from the frames just copied without safepoint polls in the middle. Otherwise if someone walks the thread's stack it will find the frames appearing twice: in the physical stack and in the heap. It's conceivable that in the future we might have more native methods we want to preempt. Instead of enumerating them all, we could set a flag on the method. I was assuming that David was suggesting we have the Java caller do a yield() or something, instead of having the native code call freeze. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819880228 From pchilanomate at openjdk.org Wed Nov 6 17:40:05 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:05 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> On Mon, 28 Oct 2024 01:13:05 GMT, David Holmes wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2382: > >> 2380: __ bind(after_transition); >> 2381: >> 2382: if (LockingMode != LM_LEGACY && method->is_object_wait0()) { > > It bothers me that we have to add a check for a specific native method in this code (notwithstanding there are already some checks in relation to hashCode). As a follow up I wonder if we can deal with wait-preemption by rewriting the Java code, instead of special casing the wait0 native code? Not sure. We would have to return from wait0 and immediately clear the physical stack from the frames just copied without safepoint polls in the middle. Otherwise if someone walks the thread's stack it will find the frames appearing twice: in the physical stack and in the heap. > The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right? > Yes. > src/hotspot/share/classfile/javaClasses.cpp line 2086: > >> 2084: jboolean vthread_on_list = Atomic::load(addr); >> 2085: if (!vthread_on_list) { >> 2086: vthread_on_list = Atomic::cmpxchg(addr, (jboolean)JNI_FALSE, (jboolean)JNI_TRUE); > > It is not clear who the racing participants are here. How can the same thread be being placed on the list from two different actions? The same example mentioned above, with a different timing, could result in two threads trying to add the same virtual thread to the list at the same time. > src/hotspot/share/code/nmethod.cpp line 711: > >> 709: // handle the case of an anchor explicitly set in continuation code that doesn't have a callee >> 710: JavaThread* thread = reg_map->thread(); >> 711: if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) { > > Suggestion: > > if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) > JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) { Fixed. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889: > >> 887: return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller); >> 888: } else { >> 889: // frame can't be freezed. Most likely the call_stub or upcall_stub > > Suggestion: > > // Frame can't be frozen. Most likely the call_stub or upcall_stub Fixed. > src/hotspot/share/runtime/javaThread.hpp line 165: > >> 163: // ID used as owner for inflated monitors. Same as the j.l.Thread.tid of the >> 164: // current _vthread object, except during creation of the primordial and JNI >> 165: // attached thread cases where this field can have a temporal value. > > Suggestion: > > // attached thread cases where this field can have a temporary value. > > Presumably this is for when the attaching thread is executing the Thread constructor? Exactly. > src/hotspot/share/runtime/javaThread.hpp line 166: > >> 164: // current _vthread object, except during creation of the primordial and JNI >> 165: // attached thread cases where this field can have a temporary value. Also, >> 166: // calls to VirtualThread.switchToCarrierThread will temporary change _vthread > > s/temporary change/temporarily change/ Fixed. > src/hotspot/share/runtime/objectMonitor.cpp line 132: > >> 130: >> 131: // ----------------------------------------------------------------------------- >> 132: // Theory of operations -- Monitors lists, thread residency, etc: > > This comment block needs updating now owner is not a JavaThread*, and to account for vthread usage Updated comment. > src/hotspot/share/runtime/objectMonitor.cpp line 1140: > >> 1138: } >> 1139: >> 1140: bool ObjectMonitor::resume_operation(JavaThread* current, ObjectWaiter* node, ContinuationWrapper& cont) { > > Explanatory comment would be good - thanks. Added comment. > src/hotspot/share/runtime/objectMonitor.cpp line 1532: > >> 1530: } else if (java_lang_VirtualThread::set_onWaitingList(vthread, vthread_cxq_head())) { >> 1531: // Virtual thread case. >> 1532: Trigger->unpark(); > > So ignoring for the moment that I can't see how `set_onWaitingList` could return false here, the check is just an optimisation to reduce the number of unparks issued i.e. only unpark if the list has changed? Right. > src/hotspot/share/runtime/objectMonitor.cpp line 1673: > >> 1671: >> 1672: ContinuationEntry* ce = current->last_continuation(); >> 1673: if (interruptible && ce != nullptr && ce->is_virtual_thread()) { > > So IIUC this use of `interruptible` would be explained as follows: > > // Some calls to wait() occur in contexts that still have to pin a vthread to its carrier. > // All such contexts perform non-interruptible waits, so by checking `interruptible` we know > // this is a regular Object.wait call. Yes, although the non-interruptible call is coming from ObjectLocker, which already has the NoPreemptMark, so I removed this check. > src/hotspot/share/runtime/objectMonitor.cpp line 1706: > >> 1704: // on _WaitSetLock so it's not profitable to reduce the length of the >> 1705: // critical section. >> 1706: > > Please restore the blank line, else it looks like the comment block pertains to the `wait_reenter_begin`, but it doesn't. Restored. > src/hotspot/share/runtime/objectMonitor.cpp line 2028: > >> 2026: // First time we run after being preempted on Object.wait(). >> 2027: // Check if we were interrupted or the wait timed-out, and in >> 2028: // that case remove ourselves from the _WaitSet queue. > > I'm not sure how to interpret this comment block - is this really two sentences because the first is not actually a sentence. Also unclear what "run" and "First time" relate to. This vthread was unmounted on the call to `Object.wait`. Now it is mounted and "running" again, and we need to check which case it is in: notified, interrupted or timed-out. "First time" means it is the first time it's running after the original unmount on `Object.wait`. This is because once we are on the monitor reentry phase, the virtual thread can be potentially unmounted and mounted many times until it successfully acquires the monitor. Not sure how to rewrite the comment to make it clearer. > src/hotspot/share/runtime/objectMonitor.cpp line 2054: > >> 2052: // Mark that we are at reenter so that we don't call this method again. >> 2053: node->_at_reenter = true; >> 2054: assert(!has_owner(current), "invariant"); > > The position of this assert seems odd as it seems to be something that should hold at entry to this method. Ok, I moved it to the beginning of resume_operation. > src/hotspot/share/runtime/objectMonitor.hpp line 47: > >> 45: // ParkEvent instead. Beware, however, that the JVMTI code >> 46: // knows about ObjectWaiters, so we'll have to reconcile that code. >> 47: // See next_waiter(), first_waiter(), etc. > > This to-do is likely no longer relevant with the current changes. Removed. > src/hotspot/share/runtime/objectMonitor.hpp line 207: > >> 205: >> 206: static void Initialize(); >> 207: static void Initialize2(); > > Please add comment why this needs to be deferred - and till after what? Added comment. > src/hotspot/share/runtime/objectMonitor.hpp line 288: > >> 286: // Returns true if this OM has an owner, false otherwise. >> 287: bool has_owner() const; >> 288: int64_t owner() const; // Returns null if DEFLATER_MARKER is observed. > > null is not an int64_t value. Changed to NO_OWNER. > src/hotspot/share/runtime/objectMonitor.hpp line 292: > >> 290: >> 291: static int64_t owner_for(JavaThread* thread); >> 292: static int64_t owner_for_oop(oop vthread); > > Some comments describing this API would be good. I'm struggling a bit with the "owner for" terminology. I think `owner_from` would be better. And can't these just overload rather than using different names? I changed them to `owner_from`. I added a comment referring to the return value as tid, and then I used this tid name in some other comments. Maybe this methods should be called `tid_from()`? Alternatively we could use the term owner id instead, and these would be `owner_id_from()`. In theory, this tid term or owner id (or whatever other name) does not need to be related to `j.l.Thread.tid`, it just happens that that's what we are using as the actual value for this id. > src/hotspot/share/runtime/objectMonitor.hpp line 299: > >> 297: // Simply set _owner field to new_value; current value must match old_value. >> 298: void set_owner_from_raw(int64_t old_value, int64_t new_value); >> 299: // Same as above but uses tid of current as new value. > > By `tid` here (and elsewhere) you actually mean `thread->threadObj()->thread_id()` - right? It is `thread->vthread()->thread_id()` but it will match `thread->threadObj()->thread_id()` when there is no virtual thread mounted. But we cache it in thread->_lockd_id so we retrieve it from there. I think we should probably change the name of _lock_id. > src/hotspot/share/runtime/objectMonitor.hpp line 302: > >> 300: // Simply set _owner field to new_value; current value must match old_value. >> 301: void set_owner_from_raw(int64_t old_value, int64_t new_value); >> 302: void set_owner_from(int64_t old_value, JavaThread* current); > > Again some comments describing API would good. The old API had vague names like old_value and new_value because of the different forms the owner value could take. Now it is always a thread-id we can do better I think. The distinction between the raw and non-raw forms is unclear and the latter is not covered by the initial comment. I added a comment. How about s/old_value/old_tid and s/new_value/new_tid? > src/hotspot/share/runtime/objectMonitor.hpp line 302: > >> 300: void set_owner_from(int64_t old_value, JavaThread* current); >> 301: // Set _owner field to tid of current thread; current value must be ANONYMOUS_OWNER. >> 302: void set_owner_from_BasicLock(JavaThread* current); > > Shouldn't tid there be the basicLock? So the value stored in _owner has to be ANONYMOUS_OWNER. We cannot store the BasicLock* in there as before since it can clash with some other thread's tid. We store it in the new field _stack_locker instead. > src/hotspot/share/runtime/objectMonitor.hpp line 303: > >> 301: void set_owner_from_raw(int64_t old_value, int64_t new_value); >> 302: void set_owner_from(int64_t old_value, JavaThread* current); >> 303: // Simply set _owner field to current; current value must match basic_lock_p. > > Comment is no longer accurate Fixed. > src/hotspot/share/runtime/objectMonitor.hpp line 309: > >> 307: // _owner field. Returns the prior value of the _owner field. >> 308: int64_t try_set_owner_from_raw(int64_t old_value, int64_t new_value); >> 309: int64_t try_set_owner_from(int64_t old_value, JavaThread* current); > > Similar to set_owner* need better comments describing API. Added similar comment. > src/hotspot/share/runtime/objectMonitor.hpp line 311: > >> 309: int64_t try_set_owner_from(int64_t old_value, JavaThread* current); >> 310: >> 311: bool is_succesor(JavaThread* thread); > > I think `has_successor` is more appropriate here as it is not the monitor that is the successor. Right, changed. > src/hotspot/share/runtime/objectMonitor.hpp line 312: > >> 310: void set_successor(JavaThread* thread); >> 311: void set_successor(oop vthread); >> 312: void clear_successor(); > > Needs descriptive comments, or at least a preceding comment explaining what a "successor" is. Added comment. > src/hotspot/share/runtime/objectMonitor.hpp line 315: > >> 313: void set_succesor(oop vthread); >> 314: void clear_succesor(); >> 315: bool has_succesor(); > > Sorry but `successor` has two `s` before `or`. Fixed. > src/hotspot/share/runtime/objectMonitor.hpp line 317: > >> 315: bool has_succesor(); >> 316: >> 317: bool is_owner(JavaThread* thread) const { return owner() == owner_for(thread); } > > Again `has_owner` seems more appropriate Yes, changed. > src/hotspot/share/runtime/objectMonitor.hpp line 323: > >> 321: } >> 322: >> 323: bool is_owner_anonymous() const { return owner_raw() == ANONYMOUS_OWNER; } > > Again I struggle with the pre-existing `is_owner` formulation here. The target of the expression is a monitor and we are asking if the monitor has an anonymous owner. I changed it to `has_owner_anonymous`. > src/hotspot/share/runtime/objectMonitor.hpp line 333: > >> 331: bool is_stack_locker(JavaThread* current); >> 332: BasicLock* stack_locker() const; >> 333: void set_stack_locker(BasicLock* locker); > > Again `is` versus `has`, plus some general comments describing the API. Fixed and added comments. > src/hotspot/share/runtime/objectMonitor.hpp line 334: > >> 332: >> 333: // Returns true if BasicLock* stored in _stack_locker >> 334: // points to current's stack, false othwerwise. > > Suggestion: > > // points to current's stack, false otherwise. Fixed. > src/hotspot/share/runtime/objectMonitor.hpp line 349: > >> 347: ObjectWaiter* first_waiter() { return _WaitSet; } >> 348: ObjectWaiter* next_waiter(ObjectWaiter* o) { return o->_next; } >> 349: JavaThread* thread_of_waiter(ObjectWaiter* o) { return o->_thread; } > > This no longer looks correct if the waiter is a vthread. ?? It is, we still increment _waiters for the vthread case. > src/hotspot/share/runtime/objectMonitor.inline.hpp line 110: > >> 108: } >> 109: >> 110: // Returns null if DEFLATER_MARKER is observed. > > Comment needs updating Updated. > src/hotspot/share/runtime/objectMonitor.inline.hpp line 130: > >> 128: // Returns true if owner field == DEFLATER_MARKER and false otherwise. >> 129: // This accessor is called when we really need to know if the owner >> 130: // field == DEFLATER_MARKER and any non-null value won't do the trick. > > Comment needs updating Updated. Removed the second sentence, seemed redundant. > src/hotspot/share/runtime/synchronizer.cpp line 670: > >> 668: // Top native frames in the stack will not be seen if we attempt >> 669: // preemption, since we start walking from the last Java anchor. >> 670: NoPreemptMark npm(current); > > Don't we still pin for JNI monitor usage? Only when facing contention on this call. But once we have the monitor we don't. > src/hotspot/share/runtime/synchronizer.hpp line 172: > >> 170: >> 171: // Iterate ObjectMonitors where the owner is thread; this does NOT include >> 172: // ObjectMonitors where owner is set to a stack lock address in thread. > > Comment needs updating Updated. > src/hotspot/share/runtime/threadIdentifier.cpp line 30: > >> 28: >> 29: // starting at 3, excluding reserved values defined in ObjectMonitor.hpp >> 30: static const int64_t INITIAL_TID = 3; > > Can we express this in terms of those reserved values, or are they inaccessible? Yes, we could define a new public constant `static const int64_t FIRST_AVAILABLE_TID = 3` (or some similar name) and use it here: diff --git a/src/hotspot/share/runtime/threadIdentifier.cpp b/src/hotspot/share/runtime/threadIdentifier.cpp index 60d6a990779..710c3141768 100644 --- a/src/hotspot/share/runtime/threadIdentifier.cpp +++ b/src/hotspot/share/runtime/threadIdentifier.cpp @@ -24,15 +24,15 @@ #include "precompiled.hpp" #include "runtime/atomic.hpp" +#include "runtime/objectMonitor.hpp" #include "runtime/threadIdentifier.hpp" -// starting at 3, excluding reserved values defined in ObjectMonitor.hpp -static const int64_t INITIAL_TID = 3; -static volatile int64_t next_thread_id = INITIAL_TID; +// excluding reserved values defined in ObjectMonitor.hpp +static volatile int64_t next_thread_id = ObjectMonitor::FIRST_AVAILABLE_TID; #ifdef ASSERT int64_t ThreadIdentifier::initial() { - return INITIAL_TID; + return ObjectMonitor::FIRST_AVAILABLE_TID; } #endif Or maybe define it as MAX_RESERVED_TID instead, and here we would add one to it. > src/hotspot/share/services/threadService.cpp line 467: > >> 465: if (waitingToLockMonitor->has_owner()) { >> 466: currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor); >> 467: // If currentThread is nullptr we would like to know if the owner > > Suggestion: > > // If currentThread is null we would like to know if the owner Fixed. > src/hotspot/share/services/threadService.cpp line 474: > >> 472: // vthread we never record this as a deadlock. Note: unless there >> 473: // is a bug in the VM, or a thread exits without releasing monitors >> 474: // acquired through JNI, nullptr should imply unmounted vthread owner. > > Suggestion: > > // acquired through JNI, null should imply an unmounted vthread owner. Fixed. > src/java.base/share/classes/java/lang/Object.java line 383: > >> 381: try { >> 382: wait0(timeoutMillis); >> 383: } catch (InterruptedException e) { > > I had expected to see a call to a new `wait0` method that returned a value indicating whether the wait was completed or else we had to park. Instead we had to put special logic in the native-call-wrapper code in the VM to detect returning from wait0 and changing the return address. I'm still unclear where that modified return address actually takes us. We jump to `StubRoutines::cont_preempt_stub()`. We need to remove all the frames that were just copied to the heap from the physical stack, and then return to the calling method which will be `Continuation.run`. > src/java.base/share/classes/java/lang/Thread.java line 654: > >> 652: * {@link Thread#PRIMORDIAL_TID} +1 as this class cannot be used during >> 653: * early startup to generate the identifier for the primordial thread. The >> 654: * counter is off-heap and shared with the VM to allow it assign thread > > Suggestion: > > * counter is off-heap and shared with the VM to allow it to assign thread Fixed. > src/java.base/share/classes/java/lang/Thread.java line 731: > >> 729: >> 730: if (attached && VM.initLevel() < 1) { >> 731: this.tid = 3; // primordial thread > > The comment before the `ThreadIdentifiers` class needs updating to account for this change. Fixed. > src/java.base/share/classes/java/lang/VirtualThread.java line 109: > >> 107: * >> 108: * RUNNING -> BLOCKING // blocking on monitor enter >> 109: * BLOCKING -> BLOCKED // blocked on monitor enter > > Should this say something similar to the parked case, about the "yield" being successful? Since the unmount is triggered from the VM we never call yieldContinuation(), unlike with the PARKING case. In other words, there are no two cases to handle. If freezing the continuation fails, the virtual thread will already block in the monitor code pinned to the carrier, so a state of BLOCKING means freezing the continuation succeeded. > src/java.base/share/classes/java/lang/VirtualThread.java line 110: > >> 108: * RUNNING -> BLOCKING // blocking on monitor enter >> 109: * BLOCKING -> BLOCKED // blocked on monitor enter >> 110: * BLOCKED -> UNBLOCKED // unblocked, may be scheduled to continue > > Does this mean it now owns the monitor, or just it is able to re-contest for monitor entry? It means it is scheduled to run again and re-contest for the monitor. > src/java.base/share/classes/java/lang/VirtualThread.java line 111: > >> 109: * BLOCKING -> BLOCKED // blocked on monitor enter >> 110: * BLOCKED -> UNBLOCKED // unblocked, may be scheduled to continue >> 111: * UNBLOCKED -> RUNNING // continue execution after blocked on monitor enter > > Presumably this one means it acquired the monitor? Not really, it is the state we set when the virtual thread is mounted and runs again. In this case it will just run to re-contest for the monitor. > src/java.base/share/classes/java/lang/VirtualThread.java line 631: > >> 629: // Object.wait >> 630: if (s == WAITING || s == TIMED_WAITING) { >> 631: byte nonce; > > Suggestion: > > byte seqNo; Changed to seqNo. > src/java.base/share/classes/java/lang/VirtualThread.java line 948: > >> 946: * This method does nothing if the thread has been woken by notify or interrupt. >> 947: */ >> 948: private void waitTimeoutExpired(byte nounce) { > > I assume you meant `nonce` here, but please change to `seqNo`. Changed. > src/java.base/share/classes/java/lang/VirtualThread.java line 952: > >> 950: for (;;) { >> 951: boolean unblocked = false; >> 952: synchronized (timedWaitLock()) { > > Where is the overall design of the timed-wait protocol and it use of synchronization described? When we unmount on a timed-wait call we schedule a wakeup task at the end of `afterYield`. There are two mechanisms that avoid the scheduled task to run and wake up the virtual thread on a future timed-wait call, since in this call the virtual thread could have been already notified before the scheduled task runs. The first one is to cancel the scheduled task once we return from the wait call (see `Object.wait(long timeoutMillis)`). Since the task could have been already started though, we also use `timedWaitSeqNo`, which the wake up task checks here to make sure it is not an old one. Since we synchronize on `timedWaitLock` to increment `timedWaitSeqNo` and change state to `TIMED_WAIT` before scheduling the wake up task in `afterYield`, here either a wrong `timedWaitSeqNo` or a state different than `TIMED_WAIT` means there is nothing to do. The only exception is checking for `SUSPENDED` state, in which case we just loop to retry. > src/java.base/share/classes/java/lang/VirtualThread.java line 1397: > >> 1395: >> 1396: /** >> 1397: * Returns a lock object to coordinating timed-wait setup and timeout handling. > > Suggestion: > > * Returns a lock object for coordinating timed-wait setup and timeout handling. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819744051 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817192967 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817195264 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817195487 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826154797 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1805830255 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815700441 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828195851 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817196602 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817197017 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817388840 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817199027 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200025 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200202 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811596618 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200507 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811596855 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811600012 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813525449 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811600739 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814187730 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601098 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601168 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601545 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817195731 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601472 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601619 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601871 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811602000 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814187856 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817195899 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817196260 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817196374 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200860 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200711 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813237094 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826155159 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826155815 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815701043 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815693906 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813237507 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813239314 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813239799 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813240352 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815699934 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815700133 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817190381 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815700312 From dholmes at openjdk.org Wed Nov 6 17:40:05 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:05 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Mon, 28 Oct 2024 23:09:58 GMT, Dean Long wrote: >> Not sure. We would have to return from wait0 and immediately clear the physical stack from the frames just copied without safepoint polls in the middle. Otherwise if someone walks the thread's stack it will find the frames appearing twice: in the physical stack and in the heap. > > It's conceivable that in the future we might have more native methods we want to preempt. Instead of enumerating them all, we could set a flag on the method. > > I was assuming that David was suggesting we have the Java caller do a yield() or something, instead of having the native code call freeze. Yes. Instead of calling wait0 for a virtual thread we would call another method `needToBlockForWait` that enqueues the VT in the wait-set, releases the monitor and returns true so that caller can then "yield". It would return false if there was no longer a need to block. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820337946 From pchilanomate at openjdk.org Wed Nov 6 17:40:05 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:05 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Tue, 29 Oct 2024 08:29:55 GMT, David Holmes wrote: >> It's conceivable that in the future we might have more native methods we want to preempt. Instead of enumerating them all, we could set a flag on the method. >> >> I was assuming that David was suggesting we have the Java caller do a yield() or something, instead of having the native code call freeze. > > Yes. Instead of calling wait0 for a virtual thread we would call another method `needToBlockForWait` that enqueues the VT in the wait-set, releases the monitor and returns true so that caller can then "yield". It would return false if there was no longer a need to block. It's not that straightforward because the freeze can fail. By then we would have already started the wait call as a virtual thread though, not a platform thread. Maybe we could try to freeze before the wait0 call. We always have the option to use a flag in the method as Dean suggests instead of checking for a specific one. Since now there is only `Object.wait()` I think it's better to explicitly check for it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821391532 From dlong at openjdk.org Wed Nov 6 17:40:05 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:05 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.fb41dbbd-8e96-4b54-920b-3f3759579de8@github.com> Message-ID: On Mon, 28 Oct 2024 21:13:33 GMT, Patricio Chilano Mateo wrote: >> If preemption was cancelled, we skip over the cleanup. The native frames haven't been unwound yet. So when we call thaw, does it cleanup the native frames first, or does it copy the frames back on top of the existing frames (overwrite)? It seems like we could avoid redundant copying if we could somehow throw out the freeze data and use the native frames still on the stack, which would probably involve not patching in this stub until we know that the preemption wasn't canceled. Some some finalize actions would be delated, like a two-stage commit. > >> If preemption was cancelled, we skip over the cleanup. >> > We only skip the cleanup for the enterSpecial frame since we are going to call thaw again, all other frames are removed: https://github.com/openjdk/jdk/pull/21565/files#diff-b938ab8a7bd9f57eb02271e2dd24a305bca30f06e9f8b028e18a139c4908ec92R3791 OK got it. I guess it's too early to know if it's worth it to further optimize this case, which is hopefully rare. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819865539 From rrich at openjdk.org Wed Nov 6 17:40:06 2024 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 6 Nov 2024 17:40:06 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com> On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 602: > 600: > 601: address generate_cont_preempt_stub(); > 602: address generate_cont_resume_monitor_operation(); The declaration of `generate_cont_resume_monitor_operation` seems to be unused. src/hotspot/share/runtime/javaThread.hpp line 166: > 164: // current _vthread object, except during creation of the primordial and JNI > 165: // attached thread cases where this field can have a temporary value. > 166: int64_t _lock_id; Following the review I wanted to better understand when `_lock_id` changes. There seems to be another exception to the rule that `_lock_id` is equal to the `tid` of the current `_vthread`. I think they won't be equal when switching temporarily from the virtual to the carrier thread in `VirtualThread::switchToCarrierThread()`. src/hotspot/share/runtime/objectMonitor.hpp line 202: > 200: > 201: // Used in LM_LEGACY mode to store BasicLock* in case of inflation by contending thread. > 202: BasicLock* volatile _stack_locker; IIUC the new field `_stack_locker` is needed because we cannot store the `BasicLock*` anymore in the `_owner` field as it could be interpreted as a thread id by mistake. Wouldn't it be an option to have only odd thread ids? Then we could store the `BasicLock*` in the `_owner` field without loosing the information if it is a `BasicLock*` or a thread id. I think this would reduce complexity quite a bit, woudn't it? src/hotspot/share/runtime/synchronizer.cpp line 1559: > 1557: // and set the stack locker field in the monitor. > 1558: m->set_stack_locker(mark.locker()); > 1559: m->set_anonymous_owner(); // second Is it important that this is done after the stack locker is set? I think I saw another comment that indicated that order is important but I cannot find it now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818523530 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812377293 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819029029 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818521820 From pchilanomate at openjdk.org Wed Nov 6 17:40:06 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:06 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com> References: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com> Message-ID: On Mon, 28 Oct 2024 07:55:02 GMT, Richard Reingruber wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 602: > >> 600: >> 601: address generate_cont_preempt_stub(); >> 602: address generate_cont_resume_monitor_operation(); > > The declaration of `generate_cont_resume_monitor_operation` seems to be unused. Removed. > src/hotspot/share/runtime/synchronizer.cpp line 1559: > >> 1557: // and set the stack locker field in the monitor. >> 1558: m->set_stack_locker(mark.locker()); >> 1559: m->set_anonymous_owner(); // second > > Is it important that this is done after the stack locker is set? I think I saw another comment that indicated that order is important but I cannot find it now. No, I removed that comment. Both will be visible once we publish the monitor with `object->release_set_mark(markWord::encode(m))`. There was a "first" comment in method ObjectMonitor::set_owner_from_BasicLock() which I removed in [1]. Clearing _stack_locker now happens here in the `mark.has_monitor()` case. The order there doesn't matter either. If some other thread sees that the owner is anonymous and tries to check if he is the owner the comparison will always fail, regardless of reading the BasicLock* value or a nullptr value. [1] https://github.com/pchilano/jdk/commit/13353fdd6ad3c509b82b1fb0b9a3d05284b592b7#diff-4707eeadeff2ce30c09c4ce8c5a987abf58ac06f7bf78e7717cffa9c36cc392fL195 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819746524 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819746309 From pchilanomate at openjdk.org Wed Nov 6 17:40:06 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:06 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Fri, 25 Oct 2024 18:39:23 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/classfile/javaClasses.cpp line 2082: >> >>> 2080: } >>> 2081: >>> 2082: bool java_lang_VirtualThread::set_onWaitingList(oop vthread, OopHandle& list_head) { >> >> Some comments here about the operation would be useful. The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right? >> >> I'm struggling to understand how a thread can already be on this list? > >> The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right? >> > Yes. > Some comments here about the operation would be useful. > Added a comment. >> src/hotspot/share/runtime/javaThread.hpp line 165: >> >>> 163: // ID used as owner for inflated monitors. Same as the j.l.Thread.tid of the >>> 164: // current _vthread object, except during creation of the primordial and JNI >>> 165: // attached thread cases where this field can have a temporal value. >> >> Suggestion: >> >> // attached thread cases where this field can have a temporary value. >> >> Presumably this is for when the attaching thread is executing the Thread constructor? > > Exactly. Comment adjusted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817193493 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809072960 From dholmes at openjdk.org Wed Nov 6 17:40:06 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:06 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Fri, 25 Oct 2024 18:40:51 GMT, Patricio Chilano Mateo wrote: >>> Some comments here about the operation would be useful. >>> >> Added a comment. > >> I'm struggling to understand how a thread can already be on this list? >> > With the removal of the _Responsible thread, it's less likely but it could still happen. One case is when the virtual thread acquires the monitor after adding itself to?`_cxq`?in?`ObjectMonitor::VThreadMonitorEnter`. The owner could have released the monitor in?`ExitEpilog`?and already added the virtual thread to the waiting list. The virtual thread will continue running and may face contention on a different monitor. When the owner of this latter monitor picks the virtual thread as the successor it might still find it on the waiting list (unblocker thread did not run yet). The same case can happen in?`ObjectMonitor::resume_operation`?when acquiring the monitor after clearing successor. Hmmmm ... I guess we either slow down the monitor code by having the thread search for and remove itself, or we allow for this and handle it correctly ... okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818242015 From dholmes at openjdk.org Wed Nov 6 17:40:06 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:06 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Mon, 28 Oct 2024 00:43:47 GMT, David Holmes wrote: >>> I'm struggling to understand how a thread can already be on this list? >>> >> With the removal of the _Responsible thread, it's less likely but it could still happen. One case is when the virtual thread acquires the monitor after adding itself to?`_cxq`?in?`ObjectMonitor::VThreadMonitorEnter`. The owner could have released the monitor in?`ExitEpilog`?and already added the virtual thread to the waiting list. The virtual thread will continue running and may face contention on a different monitor. When the owner of this latter monitor picks the virtual thread as the successor it might still find it on the waiting list (unblocker thread did not run yet). The same case can happen in?`ObjectMonitor::resume_operation`?when acquiring the monitor after clearing successor. > > Hmmmm ... I guess we either slow down the monitor code by having the thread search for and remove itself, or we allow for this and handle it correctly ... okay. That said such a scenario is not about concurrently pushing the same thread to the list from different threads. So I'm still somewhat confused about the concurrency control here. Specifically I can't see how the cmpxchg on line 2090 could fail. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818245776 From pchilanomate at openjdk.org Wed Nov 6 17:40:06 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:06 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Fri, 25 Oct 2024 18:39:54 GMT, Patricio Chilano Mateo wrote: >>> The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right? >>> >> Yes. > >> Some comments here about the operation would be useful. >> > Added a comment. > I'm struggling to understand how a thread can already be on this list? > With the removal of the _Responsible thread, it's less likely but it could still happen. One case is when the virtual thread acquires the monitor after adding itself to?`_cxq`?in?`ObjectMonitor::VThreadMonitorEnter`. The owner could have released the monitor in?`ExitEpilog`?and already added the virtual thread to the waiting list. The virtual thread will continue running and may face contention on a different monitor. When the owner of this latter monitor picks the virtual thread as the successor it might still find it on the waiting list (unblocker thread did not run yet). The same case can happen in?`ObjectMonitor::resume_operation`?when acquiring the monitor after clearing successor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817194346 From pchilanomate at openjdk.org Wed Nov 6 17:40:06 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:06 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Mon, 28 Oct 2024 00:55:34 GMT, David Holmes wrote: >> Hmmmm ... I guess we either slow down the monitor code by having the thread search for and remove itself, or we allow for this and handle it correctly ... okay. > > That said such a scenario is not about concurrently pushing the same thread to the list from different threads. So I'm still somewhat confused about the concurrency control here. Specifically I can't see how the cmpxchg on line 2090 could fail. Let's say ThreadA owns monitorA and ThreadB owns monitorB, here is how the cmpxchg could fail: | ThreadA | ThreadB | ThreadC | | --------------------------------------| --------------------------------------| ---------------------------------------------| | | |VThreadMonitorEnter:fails to acquire monitorB | | | | VThreadMonitorEnter:adds to B's _cxq | | | ExitEpilog:picks ThreadC as succesor | | | | ExitEpilog:releases monitorB | | | | | VThreadMonitorEnter:acquires monitorB | | | | VThreadMonitorEnter:removes from B's _cxq | | | | continues execution in Java | | | |VThreadMonitorEnter:fails to acquire monitorA | | | | VThreadMonitorEnter:adds to A's _cxq | | ExitEpilog:picks ThreadC as succesor | | | | ExitEpilog:releases monitorA | | | | ExitEpilog:calls set_onWaitingList() | ExitEpilog:calls set_onWaitingList() | | ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819829472 From alanb at openjdk.org Wed Nov 6 17:40:06 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:06 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> On Mon, 4 Nov 2024 02:12:40 GMT, David Holmes wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/classfile/javaClasses.cpp line 2107: > >> 2105: >> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) { >> 2107: return vthread->long_field(_timeout_offset); > > Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ?? It was initially parkTimeout and waitTimeout but it doesn't require two fields as you can't be waiting in Object.wait(timeout) and LockSupport.parkNanos at the same time. So the field was renamed, the accessors here should probably be renamed too. > src/hotspot/share/prims/jvm.cpp line 4012: > >> 4010: } >> 4011: ThreadBlockInVM tbivm(THREAD); >> 4012: parkEvent->park(); > > What code does the unpark to wake this thread up? I can't quite see how this unparker thread operates as its logic seems dispersed. It's very similar to the "Reference Handler" thread. That thread calls into the VM to get the pending-Reference list. Now we have "VirtualThread-unblocker" calling into the VM to get the list of virtual threads to unblock. ObjectMonitor::ExitEpilog will the unpark this thread when the virtual thread successor is on the list to unblock. > src/java.base/share/classes/java/lang/Thread.java line 655: > >> 653: * early startup to generate the identifier for the primordial thread. The >> 654: * counter is off-heap and shared with the VM to allow it assign thread >> 655: * identifiers to non-Java threads. > > Why do non-JavaThreads need an identifier of this kind? JFR. We haven't changed anything there, just the initial tid. > src/java.base/share/classes/java/lang/VirtualThread.java line 115: > >> 113: * RUNNING -> WAITING // transitional state during wait on monitor >> 114: * WAITING -> WAITED // waiting on monitor >> 115: * WAITED -> BLOCKED // notified, waiting to be unblocked by monitor owner > > Waiting to re-enter the monitor? yes > src/java.base/share/classes/java/lang/VirtualThread.java line 178: > >> 176: // timed-wait support >> 177: private long waitTimeout; >> 178: private byte timedWaitNonce; > > Strange name - what does this mean? Sequence number, nouce, anything will work here as it's just to deal with the scenario where the timeout task for a previous wait may run concurrently with a subsequent wait. > src/java.base/share/classes/java/lang/VirtualThread.java line 530: > >> 528: && carrier == Thread.currentCarrierThread(); >> 529: carrier.setCurrentThread(carrier); >> 530: Thread.setCurrentLockId(this.threadId()); // keep lock ID of virtual thread > > I'm struggling to understand the different threads in play when this is called and what the method actual does to which threads. ?? A virtual thread is mounted but doing a timed-park that requires temporarily switching to the identity of the carrier (identity = Therad.currentThread) when queuing the timer task. As mentioned in a reply to Axel, we are close to the point of removing this (nothing to do with object monitors of course, we've had the complexity with temporary transitions since JDK 19). More context here is that there isn't support yet for a carrier to own a monitor before a virtual thread is mounted, and same thing during these temporary transitions. If support for custom schedulers is exposed then that issue will need to be addressed as you don't want some entries on the lock stack owned by the carrier and the others by the mounted virtual thread. Patricio has mentioned inflating any held monitors before mount. There are a couple of efforts in this area going on now, all would need that issue fixed before anything is exposed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827219720 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814450822 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814387940 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810579901 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810583267 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810598265 From dholmes at openjdk.org Wed Nov 6 17:40:06 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:06 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: <-1gsoTUPRiypD1etOiePGvVI0vBmYKUy_ltb6C4ADNU=.7a75db37-1cb9-4256-969d-d532b6cdc8e5@github.com> On Mon, 28 Oct 2024 22:02:02 GMT, Patricio Chilano Mateo wrote: >> That said such a scenario is not about concurrently pushing the same thread to the list from different threads. So I'm still somewhat confused about the concurrency control here. Specifically I can't see how the cmpxchg on line 2090 could fail. > > Let's say ThreadA owns monitorA and ThreadB owns monitorB, here is how the cmpxchg could fail: > > | ThreadA | ThreadB | ThreadC | > | --------------------------------------| --------------------------------------| ---------------------------------------------| > | | |VThreadMonitorEnter:fails to acquire monitorB | > | | | VThreadMonitorEnter:adds to B's _cxq | > | | ExitEpilog:picks ThreadC as succesor | | > | | ExitEpilog:releases monitorB | | > | | | VThreadMonitorEnter:acquires monitorB | > | | | VThreadMonitorEnter:removes from B's _cxq | > | | | continues execution in Java | > | | |VThreadMonitorEnter:fails to acquire monitorA | > | | | VThreadMonitorEnter:adds to A's _cxq | > | ExitEpilog:picks ThreadC as succesor | | | > | ExitEpilog:releases monitorA | | | > | ExitEpilog:calls set_onWaitingList() | ExitEpilog:calls set_onWaitingList() | | Thanks for that detailed explanation. It is a bit disconcerting that Thread C could leave a trace on monitors it acquired and released in the distant past. But that is an effect of waking the successor after releasing the monitor (which is generally a good thing for performance). We could potentially re-check the successor (which Thread C will clear) before doing the actual unpark (and set_onWaitingList) but that would just narrow the race window not close it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823394886 From pchilanomate at openjdk.org Wed Nov 6 17:40:06 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:06 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> Message-ID: <-NVIl6YW1oji4m0sLlL34aIrsJ0zq1_0PlgT6eva-jY=.e2d498b3-8477-48a7-be81-b328c592289e@github.com> On Mon, 4 Nov 2024 05:52:16 GMT, Alan Bateman wrote: >> src/hotspot/share/classfile/javaClasses.cpp line 2107: >> >>> 2105: >>> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) { >>> 2107: return vthread->long_field(_timeout_offset); >> >> Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ?? > > It was initially parkTimeout and waitTimeout but it doesn't require two fields as you can't be waiting in Object.wait(timeout) and LockSupport.parkNanos at the same time. So the field was renamed, the accessors here should probably be renamed too. Renamed accessors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828615772 From pchilanomate at openjdk.org Wed Nov 6 17:40:07 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 07:51:05 GMT, Erik Gahlin wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/jfr/metadata/metadata.xml line 160: > >> 158: >> 159: >> 160: > > The label should be "Blocking Operation" with a capital "O". > > Labels use headline-style capitalization. See here for more information: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Label.html Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829463128 From egahlin at openjdk.org Wed Nov 6 17:40:07 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 6 Nov 2024 17:40:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... src/hotspot/share/jfr/metadata/metadata.xml line 160: > 158: > 159: > 160: Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html (Note: The fact that the event is now written in the JVM doesn't determine the category.) src/hotspot/share/jfr/metadata/metadata.xml line 160: > 158: > 159: > 160: The label should be "Blocking Operation" with a capital "O". Labels use headline-style capitalization. See here for more information: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Label.html ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828875263 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828878025 From pchilanomate at openjdk.org Wed Nov 6 17:40:07 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 08:19:34 GMT, Alan Bateman wrote: >> src/hotspot/share/jfr/metadata/metadata.xml line 160: >> >>> 158: >>> 159: >>> 160: >> >> Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category: >> >> https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html >> >> (Note: The fact that the event is now written in the JVM doesn't determine the category.) > > Thanks for spotting this, it wasn't intended to change the category. I think it's that Event element was copied from another event when adding it to metadata.xml and value from `@Category` wasn't carried over. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829462765 From alanb at openjdk.org Wed Nov 6 17:40:07 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 07:48:40 GMT, Erik Gahlin wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/jfr/metadata/metadata.xml line 160: > >> 158: >> 159: >> 160: > > Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category: > > https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html > > (Note: The fact that the event is now written in the JVM doesn't determine the category.) Thanks for spotting this, it wasn't intended to change the category. I think it's that Event element was copied from another event when adding it to metadata.xml and value from `@Category` wasn't carried over. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828915229 From pchilanomate at openjdk.org Wed Nov 6 17:40:07 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 10:37:21 GMT, Yudi Zheng wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 329: > >> 327: nonstatic_field(ObjArrayKlass, _element_klass, Klass*) \ >> 328: \ >> 329: unchecked_nonstatic_field(ObjectMonitor, _owner, int64_t) \ > > to make the type assert more precise: > > diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp > index 20b9609cdbf..f2b8a69c03f 100644 > --- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp > +++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp > @@ -326,7 +326,7 @@ > \ > nonstatic_field(ObjArrayKlass, _element_klass, Klass*) \ > \ > - unchecked_nonstatic_field(ObjectMonitor, _owner, int64_t) \ > + volatile_nonstatic_field(ObjectMonitor, _owner, int64_t) \ > volatile_nonstatic_field(ObjectMonitor, _recursions, intptr_t) \ > volatile_nonstatic_field(ObjectMonitor, _cxq, ObjectWaiter*) \ > volatile_nonstatic_field(ObjectMonitor, _EntryList, ObjectWaiter*) \ > diff --git a/src/hotspot/share/runtime/vmStructs.cpp b/src/hotspot/share/runtime/vmStructs.cpp > index 86d7277f88b..0492f28e15b 100644 > --- a/src/hotspot/share/runtime/vmStructs.cpp > +++ b/src/hotspot/share/runtime/vmStructs.cpp > @@ -786,8 +786,8 @@ > \ > volatile_nonstatic_field(ObjectMonitor, _metadata, uintptr_t) \ > unchecked_nonstatic_field(ObjectMonitor, _object, sizeof(void *)) /*... Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819746890 From pchilanomate at openjdk.org Wed Nov 6 17:40:08 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:08 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 29 Oct 2024 02:56:30 GMT, Serguei Spitsyn wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1082: > >> 1080: } else { >> 1081: assert(vthread != nullptr, "no vthread oop"); >> 1082: oop oopCont = java_lang_VirtualThread::continuation(vthread); > > Nit: The name `oopCont` does not match the HotSpot naming convention. > What about `cont_oop` or even better just `cont` as at the line 2550? Renamed to cont. > src/hotspot/share/prims/jvmtiExport.cpp line 1682: > >> 1680: >> 1681: // On preemption JVMTI state rebinding has already happened so get it always directly from the oop. >> 1682: JvmtiThreadState *state = java_lang_Thread::jvmti_thread_state(JNIHandles::resolve(vthread)); > > I'm not sure this change is right. The `get_jvmti_thread_state()` has a role to lazily create a `JvmtiThreadState` if it was not created before. With this change the `JvmtiThreadState` creation can be missed if the `unmount` event is the first event encountered for this particular virtual thread. You probably remember that lazy creation of the `JvmtiThreadState`'s is an important optimization to avoid big performance overhead when a JVMTI agent is present. Right, good find. I missed `get_jvmti_thread_state ` will also create the state if null. How about this fix: https://github.com/pchilano/jdk/commit/baf30d92f79cc084824b207a199672f5b7f9be88 I now also see that JvmtiVirtualThreadEventMark tries to save some state of the JvmtiThreadState for the current thread before the callback, which is not the JvmtiThreadState of the vthread for this case. Don't know if something needs to change there too. > src/hotspot/share/runtime/continuation.cpp line 88: > >> 86: if (_target->has_async_exception_condition()) { >> 87: _failed = true; >> 88: } > > Q: I wonder why the failed conditions are not checked before the `start_VTMS_transition()` call. At least, it'd be nice to add a comment about on this. These will be rare conditions so I don't think it matters to check them before. But I can move them to some method that we call before and after if you prefer. > src/hotspot/share/runtime/continuation.cpp line 115: > >> 113: if (jvmti_present) { >> 114: _target->rebind_to_jvmti_thread_state_of(_target->threadObj()); >> 115: if (JvmtiExport::should_post_vthread_mount()) { > > This has to be `JvmtiExport::should_post_vthread_unmount()` instead of `JvmtiExport::should_post_vthread_mount()`. > Also, it'd be nice to add a comment explaining why the event posting is postponed to the `unmount` end point. Fixed and added comment. > src/hotspot/share/runtime/continuation.cpp line 134: > >> 132: return true; >> 133: } >> 134: #endif // INCLUDE_JVMTI > > Could you, please, consider the simplification below? > > > #if INCLUDE_JVMTI > // return true if started vthread unmount > bool jvmti_unmount_begin(JavaThread* target) { > assert(!target->is_in_any_VTMS_transition(), "must be"); > > // Don't preempt if there is a pending popframe or earlyret operation. This can > // be installed in start_VTMS_transition() so we need to check it here. > if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) { > JvmtiThreadState* state = target->jvmti_thread_state(); > if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) { > return false; > } > } > // Don't preempt in case there is an async exception installed since > // we would incorrectly throw it during the unmount logic in the carrier. > if (target->has_async_exception_condition()) { > return false; > } > if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) { > JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true); > } else { > target->set_is_in_VTMS_transition(true); > // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true) > } > return false; > } > > static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) { > if (target->is_in_VTMS_transition()) { > // We caught target at the end of a mount transition. > return false; > } > return true; > } > #endif // INCLUDE_JVMTI > ... > static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) { > assert(java_lang_VirtualThread::is_instance(vthread), ""); > if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) { // inside transition > return false; > } > return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true); > } > ... > int Continuation::try_preempt(JavaThread* target, oop continuation) { > verify_preempt_preconditions(target, continuation); > > if (LockingMode == LM_LEGACY) { > return freeze_unsupported; > } > if (!is_safe_vthread_to_preempt(target, target->vthread())) { > return freeze_pinned_native; > } > JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;) > int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp()); > log_trace(continuations, preempt)("try_preempt: %d", res); > return res; > } > > > The following won't be needed: > > target->set_pending_jvmti_unmou... Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514 We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior. Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events. > Is this posted after the VirtualThreadMount extension event posted? > It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823319745 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823322449 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823324965 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823323891 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830220838 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830225909 From yzheng at openjdk.org Wed Nov 6 17:40:07 2024 From: yzheng at openjdk.org (Yudi Zheng) Date: Wed, 6 Nov 2024 17:40:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 329: > 327: nonstatic_field(ObjArrayKlass, _element_klass, Klass*) \ > 328: \ > 329: unchecked_nonstatic_field(ObjectMonitor, _owner, int64_t) \ to make the type assert more precise: diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp index 20b9609cdbf..f2b8a69c03f 100644 --- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp +++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp @@ -326,7 +326,7 @@ \ nonstatic_field(ObjArrayKlass, _element_klass, Klass*) \ \ - unchecked_nonstatic_field(ObjectMonitor, _owner, int64_t) \ + volatile_nonstatic_field(ObjectMonitor, _owner, int64_t) \ volatile_nonstatic_field(ObjectMonitor, _recursions, intptr_t) \ volatile_nonstatic_field(ObjectMonitor, _cxq, ObjectWaiter*) \ volatile_nonstatic_field(ObjectMonitor, _EntryList, ObjectWaiter*) \ diff --git a/src/hotspot/share/runtime/vmStructs.cpp b/src/hotspot/share/runtime/vmStructs.cpp index 86d7277f88b..0492f28e15b 100644 --- a/src/hotspot/share/runtime/vmStructs.cpp +++ b/src/hotspot/share/runtime/vmStructs.cpp @@ -786,8 +786,8 @@ \ volatile_nonstatic_field(ObjectMonitor, _metadata, uintptr_t) \ unchecked_nonstatic_field(ObjectMonitor, _object, sizeof(void *)) /* NOTE: no type */ \ - unchecked_nonstatic_field(ObjectMonitor, _owner, int64_t) \ - unchecked_nonstatic_field(ObjectMonitor, _stack_locker, BasicLock*) \ + volatile_nonstatic_field(ObjectMonitor, _owner, int64_t) \ + volatile_nonstatic_field(ObjectMonitor, _stack_locker, BasicLock*) \ volatile_nonstatic_field(ObjectMonitor, _next_om, ObjectMonitor*) \ volatile_nonstatic_field(BasicLock, _metadata, uintptr_t) \ nonstatic_field(ObjectMonitor, _contentions, int) \ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818818274 From sspitsyn at openjdk.org Wed Nov 6 17:40:08 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 6 Nov 2024 17:40:08 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... src/hotspot/share/prims/jvmtiEnvBase.cpp line 1082: > 1080: } else { > 1081: assert(vthread != nullptr, "no vthread oop"); > 1082: oop oopCont = java_lang_VirtualThread::continuation(vthread); Nit: The name `oopCont` does not match the HotSpot naming convention. What about `cont_oop` or even better just `cont` as at the line 2550? src/hotspot/share/prims/jvmtiExport.cpp line 1682: > 1680: > 1681: // On preemption JVMTI state rebinding has already happened so get it always directly from the oop. > 1682: JvmtiThreadState *state = java_lang_Thread::jvmti_thread_state(JNIHandles::resolve(vthread)); I'm not sure this change is right. The `get_jvmti_thread_state()` has a role to lazily create a `JvmtiThreadState` if it was not created before. With this change the `JvmtiThreadState` creation can be missed if the `unmount` event is the first event encountered for this particular virtual thread. You probably remember that lazy creation of the `JvmtiThreadState`'s is an important optimization to avoid big performance overhead when a JVMTI agent is present. src/hotspot/share/prims/jvmtiExport.cpp line 2879: > 2877: JvmtiVTMSTransitionDisabler::start_VTMS_transition((jthread)vthread.raw_value(), /* is_mount */ true); > 2878: current->rebind_to_jvmti_thread_state_of(current->threadObj()); > 2879: } This function looks a little bit unusual. I need to think about the consequences but do not see anything bad so far. I'll look at the `ObjectMonitor` and `continuation` side updates to get more details on this. src/hotspot/share/runtime/continuation.cpp line 88: > 86: if (_target->has_async_exception_condition()) { > 87: _failed = true; > 88: } Q: I wonder why the failed conditions are not checked before the `start_VTMS_transition()` call. At least, it'd be nice to add a comment about on this. src/hotspot/share/runtime/continuation.cpp line 115: > 113: if (jvmti_present) { > 114: _target->rebind_to_jvmti_thread_state_of(_target->threadObj()); > 115: if (JvmtiExport::should_post_vthread_mount()) { This has to be `JvmtiExport::should_post_vthread_unmount()` instead of `JvmtiExport::should_post_vthread_mount()`. Also, it'd be nice to add a comment explaining why the event posting is postponed to the `unmount` end point. src/hotspot/share/runtime/continuation.cpp line 134: > 132: return true; > 133: } > 134: #endif // INCLUDE_JVMTI Could you, please, consider the simplification below? #if INCLUDE_JVMTI // return true if started vthread unmount bool jvmti_unmount_begin(JavaThread* target) { assert(!target->is_in_any_VTMS_transition(), "must be"); // Don't preempt if there is a pending popframe or earlyret operation. This can // be installed in start_VTMS_transition() so we need to check it here. if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) { JvmtiThreadState* state = target->jvmti_thread_state(); if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) { return false; } } // Don't preempt in case there is an async exception installed since // we would incorrectly throw it during the unmount logic in the carrier. if (target->has_async_exception_condition()) { return false; } if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) { JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true); } else { target->set_is_in_VTMS_transition(true); // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true) } return false; } static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) { if (target->is_in_VTMS_transition()) { // We caught target at the end of a mount transition. return false; } return true; } #endif // INCLUDE_JVMTI ... static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) { assert(java_lang_VirtualThread::is_instance(vthread), ""); if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) { // inside transition return false; } return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true); } ... int Continuation::try_preempt(JavaThread* target, oop continuation) { verify_preempt_preconditions(target, continuation); if (LockingMode == LM_LEGACY) { return freeze_unsupported; } if (!is_safe_vthread_to_preempt(target, target->vthread())) { return freeze_pinned_native; } JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;) int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp()); log_trace(continuations, preempt)("try_preempt: %d", res); return res; } The following won't be needed: target->set_pending_jvmti_unmount_event(true); jvmtiThreadState.cpp: + if (thread->pending_jvmti_unmount_event()) { + assert(java_lang_VirtualThread::is_preempted(JNIHandles::resolve(vthread)), "should be marked preempted"); + JvmtiExport::post_vthread_unmount(vthread); + thread->set_pending_jvmti_unmount_event(false); + } As we discussed before there can be the `has_async_exception_condition()` flag set after a VTMS unmount transition has been started. But there is always such a race in VTMS transitions and the flag has to be processed as usual. src/hotspot/share/runtime/objectMonitor.cpp line 1643: > 1641: // actual callee (see nmethod::preserve_callee_argument_oops()). > 1642: ThreadOnMonitorWaitedEvent tmwe(current); > 1643: JvmtiExport::vthread_post_monitor_waited(current, node->_monitor, timed_out); We post a JVMTI `MonitorWaited` event here for a virtual thread. A couple of questions on this: - Q1: Is this posted after the `VirtualThreadMount` extension event posted? Unfortunately, it is not easy to make this conclusion. - Q2: The `JvmtiExport::post_monitor_waited()` is called at the line 1801. Does it post the `MonitorWaited` event for this virtual thread as well? If not, then it is not clear how posting for virtual thread is avoided. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820012783 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820052049 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820062505 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822235309 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822224512 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828376585 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829199889 From sspitsyn at openjdk.org Wed Nov 6 17:40:08 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 6 Nov 2024 17:40:08 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 23:53:04 GMT, Patricio Chilano Mateo wrote: >> Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514 >> We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior. >> Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events. > > Regarding the pop_frame/early_ret/async_exception conditions, not checking for them after we started the transition would be an issue. > For pop_frame/early_ret checks, the problem is that if any of them are installed in `JvmtiUnmountBeginMark()` while trying to start the transition, and later the call to freeze succeeds, when returning to the interpreter (monitorenter case) we will incorrectly follow the JVMTI code [1], instead of going back to `call_VM_preemptable` to clear the stack from the copied frames. As for the asynchronous exception check, if it gets installed in `JvmtiUnmountBeginMark()` while trying to start the transition, the exception would be thrown in the carrier instead, very likely while executing the unmounting logic. > When unmounting from Java, although the race is also there when starting the VTMS transition as you mentioned, I think the end result will be different. For pop_frame/early_ret we will just bail out if trying to install them since the top frame will be a native method (`notifyJvmtiUnmount`). For the async exception, we would process it on return from `notifyJvmtiUnmount` which would still be done in the context of the vthread. > > [1] https://github.com/openjdk/jdk/blob/471f112bca715d04304cbe35c6ed63df8c7b7fee/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1629 Thank you for the comment! I'm okay with your modified suggestion in general if there are no road blocks. > but does the specs say the event has to be posted in the context of the vthread? As Alan said below we do not have an official spec for this but still the events need to be posted in vthread context. > For pop_frame/early_ret checks ... The pop_frame/early_ret conditions are installed in handshakes with a context of `JvmtiVTMSTransitionDisabler`. As you noted the `JVMTI_ERROR_OPAQUE_FRAME` might be also returned by the JVMTI `FramePop` and `ForceEarlyReturn*` for some specific cases. So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help. > Maybe we could go with this simplified code now and work on it later... Whatever works better for you. An alternate approach could be to file an enhancement to simplify/refactor this. It would be nice to fix a couple of nits though: - the call to `java_lang_Thread::set_is_in_VTMS_transition()`is not needed in `JvmtiUnmountBeginMark` - the function `is_vthread_safe_to_preempt()` does not need the `vthread` parameter ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831367766 From stefank at openjdk.org Wed Nov 6 17:40:09 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 6 Nov 2024 17:40:09 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 23:14:53 GMT, Patricio Chilano Mateo wrote: >> This might confuse the change for JEP 450 since with CompactObjectHeaders there's no klass_gap, so depending on which change goes first, there will be conditional code here. Good question though, it looks like we only ever want to copy the payload of the object. > > If I recall correctly this was a bug where one of the stackChunk fields was allocated in that gap, but since we didn't zeroed it out it would start with some invalid value. I guess the reason why we are not hitting this today is because one of the fields we do initialize (sp/bottom/size) is being allocated there, but with the new fields I added to stackChunk that is not the case anymore. This code in `StackChunkAllocator::initialize` mimics the clearing code in: void MemAllocator::mem_clear(HeapWord* mem) const { assert(mem != nullptr, "cannot initialize null object"); const size_t hs = oopDesc::header_size(); assert(_word_size >= hs, "unexpected object size"); oopDesc::set_klass_gap(mem, 0); Copy::fill_to_aligned_words(mem + hs, _word_size - hs); } but with a limited amount of clearing at the end of the object, IIRC. So, this looks like a good fix. With JEP 450 we have added an assert to set_klass_gap and changed the code in `mem_clear` to be: if (oopDesc::has_klass_gap()) { oopDesc::set_klass_gap(mem, 0); } So, unchanged, this code will start to assert when the to projects merge. Maybe it would be nice to make a small/trivial upstream PR to add this code to both `MemAllocator::mem_clear` and `StackChunkAllocator::initialize`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827424227 From pchilanomate at openjdk.org Wed Nov 6 17:40:09 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:09 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 09:24:13 GMT, Stefan Karlsson wrote: >> If I recall correctly this was a bug where one of the stackChunk fields was allocated in that gap, but since we didn't zeroed it out it would start with some invalid value. I guess the reason why we are not hitting this today is because one of the fields we do initialize (sp/bottom/size) is being allocated there, but with the new fields I added to stackChunk that is not the case anymore. > > This code in `StackChunkAllocator::initialize` mimics the clearing code in: > > void MemAllocator::mem_clear(HeapWord* mem) const { > assert(mem != nullptr, "cannot initialize null object"); > const size_t hs = oopDesc::header_size(); > assert(_word_size >= hs, "unexpected object size"); > oopDesc::set_klass_gap(mem, 0); > Copy::fill_to_aligned_words(mem + hs, _word_size - hs); > } > > > but with a limited amount of clearing at the end of the object, IIRC. So, this looks like a good fix. With JEP 450 we have added an assert to set_klass_gap and changed the code in `mem_clear` to be: > > if (oopDesc::has_klass_gap()) { > oopDesc::set_klass_gap(mem, 0); > } > > > So, unchanged, this code will start to assert when the to projects merge. Maybe it would be nice to make a small/trivial upstream PR to add this code to both `MemAllocator::mem_clear` and `StackChunkAllocator::initialize`? Thanks for confirming. I added the check here which I think should cover any merge order. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828614946 From sspitsyn at openjdk.org Wed Nov 6 17:40:08 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 6 Nov 2024 17:40:08 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 20:10:03 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/continuation.cpp line 88: >> >>> 86: if (_target->has_async_exception_condition()) { >>> 87: _failed = true; >>> 88: } >> >> Q: I wonder why the failed conditions are not checked before the `start_VTMS_transition()` call. At least, it'd be nice to add a comment about on this. > > These will be rare conditions so I don't think it matters to check them before. But I can move them to some method that we call before and after if you prefer. Just wanted to understand what needs to be checked after the start_VTMS_transition() call. You are right, we need to check the `_thread->has_async_exception_condition()` after the call. The pending `popframe` and `earlyret` can be checked before as I understand. I'm not sure there is a real need in double-checking before and after. So, let's keep it as it is for now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824134075 From pchilanomate at openjdk.org Wed Nov 6 17:40:08 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:08 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 23:50:29 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/continuation.cpp line 134: >> >>> 132: return true; >>> 133: } >>> 134: #endif // INCLUDE_JVMTI >> >> Could you, please, consider the simplification below? >> >> >> #if INCLUDE_JVMTI >> // return true if started vthread unmount >> bool jvmti_unmount_begin(JavaThread* target) { >> assert(!target->is_in_any_VTMS_transition(), "must be"); >> >> // Don't preempt if there is a pending popframe or earlyret operation. This can >> // be installed in start_VTMS_transition() so we need to check it here. >> if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) { >> JvmtiThreadState* state = target->jvmti_thread_state(); >> if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) { >> return false; >> } >> } >> // Don't preempt in case there is an async exception installed since >> // we would incorrectly throw it during the unmount logic in the carrier. >> if (target->has_async_exception_condition()) { >> return false; >> } >> if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) { >> JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true); >> } else { >> target->set_is_in_VTMS_transition(true); >> // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true) >> } >> return false; >> } >> >> static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) { >> if (target->is_in_VTMS_transition()) { >> // We caught target at the end of a mount transition. >> return false; >> } >> return true; >> } >> #endif // INCLUDE_JVMTI >> ... >> static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) { >> assert(java_lang_VirtualThread::is_instance(vthread), ""); >> if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) { // inside transition >> return false; >> } >> return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true); >> } >> ... >> int Continuation::try_preempt(JavaThread* target, oop continuation) { >> verify_preempt_preconditions(target, continuation); >> >> if (LockingMode == LM_LEGACY) { >> return freeze_unsupported; >> } >> if (!is_safe_vthread_to_preempt(target, target->vthread())) { >> return freeze_pinned_native; >> } >> JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;) >> int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp()); >> log_trace(con... > > Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514 > We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior. > Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events. Regarding the pop_frame/early_ret/async_exception conditions, not checking for them after we started the transition would be an issue. For pop_frame/early_ret checks, the problem is that if any of them are installed in `JvmtiUnmountBeginMark()` while trying to start the transition, and later the call to freeze succeeds, when returning to the interpreter (monitorenter case) we will incorrectly follow the JVMTI code [1], instead of going back to `call_VM_preemptable` to clear the stack from the copied frames. As for the asynchronous exception check, if it gets installed in `JvmtiUnmountBeginMark()` while trying to start the transition, the exception would be thrown in the carrier instead, very likely while executing the unmounting logic. When unmounting from Java, although the race is also there when starting the VTMS transition as you mentioned, I think the end result will be different. For pop_frame/early_ret we will just bail out if trying to install them since the top frame will be a native method (`notifyJvmtiUnmount`). For the async exception, we would process it on return from `notifyJvmtiUnmount` which would still be done in the context of the vthread. [1] https://github.com/openjdk/jdk/blob/471f112bca715d04304cbe35c6ed63df8c7b7fee/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1629 >> src/hotspot/share/runtime/objectMonitor.cpp line 1643: >> >>> 1641: // actual callee (see nmethod::preserve_callee_argument_oops()). >>> 1642: ThreadOnMonitorWaitedEvent tmwe(current); >>> 1643: JvmtiExport::vthread_post_monitor_waited(current, node->_monitor, timed_out); >> >> We post a JVMTI `MonitorWaited` event here for a virtual thread. >> A couple of questions on this: >> - Q1: Is this posted after the `VirtualThreadMount` extension event posted? >> Unfortunately, it is not easy to make this conclusion. >> - Q2: The `JvmtiExport::post_monitor_waited()` is called at the line 1801. >> Does it post the `MonitorWaited` event for this virtual thread as well? >> If not, then it is not clear how posting for virtual thread is avoided. > >> Is this posted after the VirtualThreadMount extension event posted? >> > It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620 > The JvmtiExport::post_monitor_waited() is called at the line 1801. > Does it post the MonitorWaited event for this virtual thread as well? > That's the path a virtual thread will take if pinned. This case is when we were able to unmount the vthread. It is the equivalent, where the vthread finished the wait part (notified, interrupted or timed-out case) and it's going to retry acquiring the monitor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830222411 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830227475 From pchilanomate at openjdk.org Wed Nov 6 17:40:09 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:09 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 19:02:05 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1411: >> >>> 1409: // zero out fields (but not the stack) >>> 1410: const size_t hs = oopDesc::header_size(); >>> 1411: oopDesc::set_klass_gap(mem, 0); >> >> Why, bug fix or cleanup? > > This might confuse the change for JEP 450 since with CompactObjectHeaders there's no klass_gap, so depending on which change goes first, there will be conditional code here. Good question though, it looks like we only ever want to copy the payload of the object. If I recall correctly this was a bug where one of the stackChunk fields was allocated in that gap, but since we didn't zeroed it out it would start with some invalid value. I guess the reason why we are not hitting this today is because one of the fields we do initialize (sp/bottom/size) is being allocated there, but with the new fields I added to stackChunk that is not the case anymore. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823580273 From coleenp at openjdk.org Wed Nov 6 17:40:09 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:40:09 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <1kRcFJhxhwGYGZxCslZJ_TUZ_SLx-io6w_zCFpIlfxw=.60f00ea4-6466-4a9d-b27d-0d657b0a6fb5@github.com> On Fri, 25 Oct 2024 13:12:11 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1275: >> >>> 1273: >>> 1274: if (caller.is_interpreted_frame()) { >>> 1275: _total_align_size += frame::align_wiggle; >> >> Please put a comment here about frame align-wiggle. > > I removed this case since it can never happen. The caller has to be compiled, and we assert that at the beginning. This was a leftover from the forceful preemption at a safepoint work. I removed the similar code in recurse_thaw_stub_frame. I added a comment for the compiled and native cases though. ok that's helpful. >> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1550: >> >>> 1548: assert(!cont.is_empty(), ""); >>> 1549: // This is done for the sake of the enterSpecial frame >>> 1550: StackWatermarkSet::after_unwind(thread); >> >> Is there a new place for this StackWatermark code? > > I removed it. We have already processed the enterSpecial frame as part of flush_stack_processing(), in fact we processed up to the caller of `Continuation.run()`. Okay, good! >> src/hotspot/share/runtime/objectMonitor.hpp line 43: >> >>> 41: // ParkEvent instead. Beware, however, that the JVMTI code >>> 42: // knows about ObjectWaiters, so we'll have to reconcile that code. >>> 43: // See next_waiter(), first_waiter(), etc. >> >> Also a nice cleanup. Did you reconcile the JVMTI code? > > We didn't remove the ObjectWaiter. As for the presence of virtual threads in the list, we skip them in JVMTI get_object_monitor_usage. We already degraded virtual thread support for GetObjectMonitorUsage. Ok, good that there isn't a jvmti special case here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819860241 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819860643 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819864520 From pchilanomate at openjdk.org Wed Nov 6 17:40:09 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:09 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> Message-ID: <5GigB3kzUJRlduxsGT_kXkmG-Jki2N-gyGkNHNNwXi4=.f139275c-bc20-4f0b-9eef-c979c3e83e12@github.com> On Thu, 31 Oct 2024 21:11:39 GMT, Fredrik Bredberg wrote: >> There was one value that meant to be for the regular freeze from java. But it was not used so I removed it. > > Fair enough, but I would prefer if you start at zero. Just so people like me don't start scratching their head trying to figure out the cosmic reason for why it doesn't start at zero. Yes, I missed to include it in the previous changes. I actually removed the assignment altogether since there is no need to rely on particular values (although it will start at zero by default). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825202651 From fbredberg at openjdk.org Wed Nov 6 17:40:09 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 6 Nov 2024 17:40:09 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> Message-ID: On Thu, 31 Oct 2024 20:05:18 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/continuation.hpp line 66: >> >>> 64: >>> 65: enum preempt_kind { >>> 66: freeze_on_monitorenter = 1, >> >> Is there a reason why the first enumerator doesn't start at zero? > > There was one value that meant to be for the regular freeze from java. But it was not used so I removed it. Fair enough, but I would prefer if you start at zero. Just so people like me don't start scratching their head trying to figure out the cosmic reason for why it doesn't start at zero. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825168519 From alanb at openjdk.org Wed Nov 6 17:40:10 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 21 Oct 2024 15:41:45 GMT, Axel Boldt-Christmas wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/runtime/javaThread.cpp line 1545: > >> 1543: if (is_vthread_mounted()) { >> 1544: // _lock_id is the thread ID of the mounted virtual thread >> 1545: st->print_cr(" Carrying virtual thread #" INT64_FORMAT, lock_id()); > > What is the interaction here with `switchToCarrierThread` and the window between? > > carrier.setCurrentThread(carrier); > Thread.setCurrentLockId(this.threadId()); > > Will we print the carrier threads id as a virtual threads id? (I am guessing that is_vthread_mounted is true when switchToCarrierThread is called). Just to say that we hope to eventually remove these "temporary transitions". This PR brings in a change that we've had in the loom repo to not need this when calling out to the scheduler. The only significant remaining use is timed-park. Once we address that then we will remove the need to switch the thread identity and remove some complexity, esp. for JVMTI and serviceability. In the mean-time, yes, the JavaThread.lock_id will temporarily switch to the carrier so a thread-dump/safepoint at just the right time looks like it print will be tid of the carrier rather than the mounted virtual thread. So we should fix that. (The original code in main line skipped this case so was lossy when taking a thread dump when hitting this case, David might remember the discussion on that issue). > src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62: > >> 60: NATIVE(2, "Native frame or on stack"), >> 61: MONITOR(3, "Monitor held"), >> 62: CRITICAL_SECTION(4, "In critical section"); > > Is there a reason that the `reasonCode` values does not match the `freeze_result` reason values used in `pinnedReason(int reason)` to create one of these? > > I cannot see that it is used either. Only seem to be read for JFR VirtualThreadPinned Event which only uses the string. That's a good question as they should match. Not noticed as it's not currently used. As it happens, this has been reverted in the loom repo as part of improving this code and fixing another issue. Related is the freeze_result enum has new members, e.g. freeze_unsupported for LM_LEGACY, that don't have a mapping to a Pinned, need to check if we could trip over that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810578179 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827316145 From aboldtch at openjdk.org Wed Nov 6 17:40:09 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 6 Nov 2024 17:40:09 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 19:04:16 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2234: >> >>> 2232: retry_fast_path = true; >>> 2233: } else { >>> 2234: relativize_chunk_concurrently(chunk); >> >> Is the `relativize_chunk_concurrently` solution to the race only to have a single flag read in `can_thaw_fast` or is there some other subtlety here? >> >> While not required for the PR, if it is just to optimise the `can_thaw_fast` check, it can probably be made to work with one load and still allow concurrent gcs do fast_thaw when we only get here due to a lockstack. > > Yes, it's just to do a single read. I guess you are thinking of combining flags and lockStackSize into a int16_t? Something along those lines, yes. >> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2247: >> >>> 2245: _thread->lock_stack().move_from_address(tmp_lockstack, lockStackSize); >>> 2246: >>> 2247: chunk->set_lockstack_size(0); >> >> After some discussion here at the office we think there might be an issue here with simply hiding the oops without clearing them. Below in `recurse_thaw` we `do_barriers`. But it does not touch these lockstack. Missing the SATB store barrier is probably fine from a liveness perspective, because the oops in the lockstack must also be in the frames. But removing the oops without a barrier and clear will probably lead to problems down the line. >> >> Something like the following would probably handle this. Or even fuse the `copy_lockstack` and `clear_lockstack` together into some kind of `transfer_lockstack` which both loads and clears the oops. >> >> >> diff --git a/src/hotspot/share/oops/stackChunkOop.cpp b/src/hotspot/share/oops/stackChunkOop.cpp >> index d3d63533eed..f737bd2db71 100644 >> --- a/src/hotspot/share/oops/stackChunkOop.cpp >> +++ b/src/hotspot/share/oops/stackChunkOop.cpp >> @@ -470,6 +470,28 @@ void stackChunkOopDesc::copy_lockstack(oop* dst) { >> } >> } >> >> +void stackChunkOopDesc::clear_lockstack() { >> + const int cnt = lockstack_size(); >> + const bool requires_gc_barriers = is_gc_mode() || requires_barriers(); >> + const bool requires_uncompress = has_bitmap() && UseCompressedOops; >> + const auto clear_obj = [&](intptr_t* at) { >> + if (requires_uncompress) { >> + HeapAccess<>::oop_store(reinterpret_cast(at), nullptr); >> + } else { >> + HeapAccess<>::oop_store(reinterpret_cast(at), nullptr); >> + } >> + }; >> + >> + if (requires_gc_barriers) { >> + intptr_t* lockstack_start = start_address(); >> + for (int i = 0; i < cnt; i++) { >> + clear_obj(&lockstack_start[i]); >> + } >> + } >> + set_lockstack_size(0); >> + set_has_lockstack(false); >> +} >> + >> void stackChunkOopDesc::print_on(bool verbose, outputStream* st) const { >> if (*((juint*)this) == badHeapWordVal) { >> st->print_cr("BAD WORD"); >> diff --git a/src/hotspot/share/oops/stackChunkOop.hpp b/src/hotspot/share/oops/stackChunkOop.hpp >> index 28e0576801e..928e94dd695 100644 >> --- a/src/hotspot/share/oops/stackChunkOop.hpp >> +++ b/src/hotspot/share/oops/stackChunkOop.hpp >> @@ -167,6 +167,7 @@ class stackChunkOopDesc : public instanceOopDesc { >> void fix_thawed_frame(const frame& f, const RegisterMapT* map); >> >> void copy_lo... > > Ok, I'll change copy_lockstack to both load and clear the oops in the same method. Now, when we call do_barriers on recurse_thaw we don't clear the oops, we just load and store the loaded value again. Is it the case that we just need to do a store, so that already works, or are we missing clearing the oops from the copied frames? The store is the important part for SATB. The fact that do_barriers (only) does a self store seems is an optimisation. As we need to do the store before we do the copy (to enable a plane memcpy). And clearing is not something that we rely on / need at the moment. The nicest model would have been to first fix the oops, (mem)copy, then clear them. But as mentioned, clearing is currently unnecessary. For the lockstack we do not need this optimisation as we do the copy when we do the load barrier. So we can just clear in our store. It is a little interesting that we template parameterise `do_barriers` on the barrier type and instantiate all the load functions, while only ever using the store version. Guess it is a remnant from some earlier model. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811903902 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811900946 From duke at openjdk.org Wed Nov 6 17:49:15 2024 From: duke at openjdk.org (hanklo6) Date: Wed, 6 Nov 2024 17:49:15 GMT Subject: RFR: 8343317: Extend test generation tool to handle APX NDD/NF flavor of instructions [v4] In-Reply-To: References: Message-ID: > Extend test generation tool and gtest (added as part of https://bugs.openjdk.org/browse/JDK-8339507) to handle Intel APX NDD/NF instructions. > > Intel Advanced Performance Extensions (APX) adds non destructive destination (NDD) and no flags (NF) flavor for the scalar instructions through EVEX encoding. For more information about APX, see https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html. hanklo6 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: - Update assembler test output labels for clarity - Merge branch 'master' of https://git.openjdk.java.net/jdk into ndd-nf-test - Regenerate asmtest.out.h - Use load form - Add seed for random - Add popcnt feature - Add ndd and nf tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21795/files - new: https://git.openjdk.org/jdk/pull/21795/files/14e4bacb..082653c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21795&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21795&range=02-03 Stats: 190426 lines in 1803 files changed: 118245 ins; 50723 del; 21458 mod Patch: https://git.openjdk.org/jdk/pull/21795.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21795/head:pull/21795 PR: https://git.openjdk.org/jdk/pull/21795 From pchilanomate at openjdk.org Wed Nov 6 17:40:10 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 11:51:47 GMT, Alan Bateman wrote: >> src/hotspot/share/runtime/javaThread.cpp line 1545: >> >>> 1543: if (is_vthread_mounted()) { >>> 1544: // _lock_id is the thread ID of the mounted virtual thread >>> 1545: st->print_cr(" Carrying virtual thread #" INT64_FORMAT, lock_id()); >> >> What is the interaction here with `switchToCarrierThread` and the window between? >> >> carrier.setCurrentThread(carrier); >> Thread.setCurrentLockId(this.threadId()); >> >> Will we print the carrier threads id as a virtual threads id? (I am guessing that is_vthread_mounted is true when switchToCarrierThread is called). > > Just to say that we hope to eventually remove these "temporary transitions". This PR brings in a change that we've had in the loom repo to not need this when calling out to the scheduler. The only significant remaining use is timed-park. Once we address that then we will remove the need to switch the thread identity and remove some complexity, esp. for JVMTI and serviceability. > > In the mean-time, yes, the JavaThread.lock_id will temporarily switch to the carrier so a thread-dump/safepoint at just the right time looks like it print will be tid of the carrier rather than the mounted virtual thread. So we should fix that. (The original code in main line skipped this case so was lossy when taking a thread dump when hitting this case, David might remember the discussion on that issue). The problem is that within that window we don't have access to the virtual thread's tid. The current thread has already been changed and we haven't yet set the lock id back. Since this will be a rare corner case maybe we can just print tid unavailable if we hit it. We could also add a boolean to setCurrentThread to indicate we don't want to change the lock_id, but not sure it's worth it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811240529 From pchilanomate at openjdk.org Wed Nov 6 17:40:09 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:09 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <21HfKDagatsu-A7zva9eZ_ndGye37_BRkJ3cyAKQoN0=.4428db89-23a9-4968-878d-c2427ee67622@github.com> On Wed, 23 Oct 2024 05:33:55 GMT, Axel Boldt-Christmas wrote: >> Ok, I'll change copy_lockstack to both load and clear the oops in the same method. Now, when we call do_barriers on recurse_thaw we don't clear the oops, we just load and store the loaded value again. Is it the case that we just need to do a store, so that already works, or are we missing clearing the oops from the copied frames? > > The store is the important part for SATB. The fact that do_barriers (only) does a self store seems is an optimisation. As we need to do the store before we do the copy (to enable a plane memcpy). And clearing is not something that we rely on / need at the moment. The nicest model would have been to first fix the oops, (mem)copy, then clear them. But as mentioned, clearing is currently unnecessary. For the lockstack we do not need this optimisation as we do the copy when we do the load barrier. So we can just clear in our store. > > It is a little interesting that we template parameterise `do_barriers` on the barrier type and instantiate all the load functions, while only ever using the store version. Guess it is a remnant from some earlier model. I renamed it to transfer_lockstack() and applied the suggested version with the lambda. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813224287 From alanb at openjdk.org Wed Nov 6 17:40:10 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 19:02:50 GMT, Patricio Chilano Mateo wrote: >> Just to say that we hope to eventually remove these "temporary transitions". This PR brings in a change that we've had in the loom repo to not need this when calling out to the scheduler. The only significant remaining use is timed-park. Once we address that then we will remove the need to switch the thread identity and remove some complexity, esp. for JVMTI and serviceability. >> >> In the mean-time, yes, the JavaThread.lock_id will temporarily switch to the carrier so a thread-dump/safepoint at just the right time looks like it print will be tid of the carrier rather than the mounted virtual thread. So we should fix that. (The original code in main line skipped this case so was lossy when taking a thread dump when hitting this case, David might remember the discussion on that issue). > > The problem is that within that window we don't have access to the virtual thread's tid. The current thread has already been changed and we haven't yet set the lock id back. Since this will be a rare corner case maybe we can just print tid unavailable if we hit it. We could also add a boolean to setCurrentThread to indicate we don't want to change the lock_id, but not sure it's worth it. It should be rare and once we make further progress on timers then the use of temporary transitions will mostly disappear. I think the main thing for the thread dump is not to print a confusing "Carrying virtual thread" with the tid of the carrier. This came up in [pull/19482](https://github.com/openjdk/jdk/pull/19482) when the thread was extended. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812377091 From duke at openjdk.org Wed Nov 6 17:49:15 2024 From: duke at openjdk.org (hanklo6) Date: Wed, 6 Nov 2024 17:49:15 GMT Subject: RFR: 8343317: Extend test generation tool to handle APX NDD/NF flavor of instructions [v3] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 16:59:24 GMT, Srinivas Vamsi Parasa wrote: >> hanklo6 has updated the pull request incrementally with one additional commit since the last revision: >> >> Regenerate asmtest.out.h > > test/hotspot/gtest/x86/test_assemblerx86.cpp line 1: > >> 1: /* > > [Optional] In lines 53 and 58, it prints "Ours" and "Theirs". This is vague. However, it looks like this is the convention used in test_assembler_aarch64.cpp as well. Thanks, I updated the label. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21795#discussion_r1831472111 From pchilanomate at openjdk.org Wed Nov 6 17:40:10 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Wed, 23 Oct 2024 09:53:44 GMT, Alan Bateman wrote: >> The problem is that within that window we don't have access to the virtual thread's tid. The current thread has already been changed and we haven't yet set the lock id back. Since this will be a rare corner case maybe we can just print tid unavailable if we hit it. We could also add a boolean to setCurrentThread to indicate we don't want to change the lock_id, but not sure it's worth it. > > It should be rare and once we make further progress on timers then the use of temporary transitions will mostly disappear. I think the main thing for the thread dump is not to print a confusing "Carrying virtual thread" with the tid of the carrier. This came up in [pull/19482](https://github.com/openjdk/jdk/pull/19482) when the thread was extended. Pushed a fix to avoid printing the virtual thread tid if we hit that case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814186777 From dholmes at openjdk.org Wed Nov 6 17:40:10 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Fri, 25 Oct 2024 18:46:52 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 2028: >> >>> 2026: // First time we run after being preempted on Object.wait(). >>> 2027: // Check if we were interrupted or the wait timed-out, and in >>> 2028: // that case remove ourselves from the _WaitSet queue. >> >> I'm not sure how to interpret this comment block - is this really two sentences because the first is not actually a sentence. Also unclear what "run" and "First time" relate to. > > This vthread was unmounted on the call to `Object.wait`. Now it is mounted and "running" again, and we need to check which case it is in: notified, interrupted or timed-out. "First time" means it is the first time it's running after the original unmount on `Object.wait`. This is because once we are on the monitor reentry phase, the virtual thread can be potentially unmounted and mounted many times until it successfully acquires the monitor. Not sure how to rewrite the comment to make it clearer. The first sentence is not a sentence. Is it supposed to be saying: // The first time we run after being preempted on Object.wait() // we check if we were interrupted or the wait timed-out ... ? >> src/hotspot/share/runtime/objectMonitor.hpp line 292: >> >>> 290: >>> 291: static int64_t owner_for(JavaThread* thread); >>> 292: static int64_t owner_for_oop(oop vthread); >> >> Some comments describing this API would be good. I'm struggling a bit with the "owner for" terminology. I think `owner_from` would be better. And can't these just overload rather than using different names? > > I changed them to `owner_from`. I added a comment referring to the return value as tid, and then I used this tid name in some other comments. Maybe this methods should be called `tid_from()`? Alternatively we could use the term owner id instead, and these would be `owner_id_from()`. In theory, this tid term or owner id (or whatever other name) does not need to be related to `j.l.Thread.tid`, it just happens that that's what we are using as the actual value for this id. I like the idea of using `owner_id_from` but it then suggests to me that `JavaThread::_lock_id` should be something like `JavaThread::_monitor_owner_id`. The use of `tid` in comments can be confusing when applied to a `JavaThread` as the "tid" there would normally be a reference of its `osThread()->thread_id()" not it's `threadObj()->thread_id()`. I don't have an obviously better suggestion though. >> src/hotspot/share/runtime/objectMonitor.hpp line 302: >> >>> 300: // Simply set _owner field to new_value; current value must match old_value. >>> 301: void set_owner_from_raw(int64_t old_value, int64_t new_value); >>> 302: void set_owner_from(int64_t old_value, JavaThread* current); >> >> Again some comments describing API would good. The old API had vague names like old_value and new_value because of the different forms the owner value could take. Now it is always a thread-id we can do better I think. The distinction between the raw and non-raw forms is unclear and the latter is not covered by the initial comment. > > I added a comment. How about s/old_value/old_tid and s/new_value/new_tid? old_tid/new_tid works for me. >> src/hotspot/share/runtime/objectMonitor.hpp line 302: >> >>> 300: void set_owner_from(int64_t old_value, JavaThread* current); >>> 301: // Set _owner field to tid of current thread; current value must be ANONYMOUS_OWNER. >>> 302: void set_owner_from_BasicLock(JavaThread* current); >> >> Shouldn't tid there be the basicLock? > > So the value stored in _owner has to be ANONYMOUS_OWNER. We cannot store the BasicLock* in there as before since it can clash with some other thread's tid. We store it in the new field _stack_locker instead. Right I understand we can't store the BasicLock* directly in owner, but the naming of this method has me confused as to what it actually does. With the old version we have: Before: owner = BasicLock* belonging to current After: owner = JavaThread* of current with the new version we have: Before: owner = ANONYMOUS_OWNER After: owner = tid of current so "BasicLock" doesn't mean anything here any more. Isn't this just `set_owner_from_anonymous` ? >> src/hotspot/share/runtime/objectMonitor.hpp line 349: >> >>> 347: ObjectWaiter* first_waiter() { return _WaitSet; } >>> 348: ObjectWaiter* next_waiter(ObjectWaiter* o) { return o->_next; } >>> 349: JavaThread* thread_of_waiter(ObjectWaiter* o) { return o->_thread; } >> >> This no longer looks correct if the waiter is a vthread. ?? > > It is, we still increment _waiters for the vthread case. Sorry the target of my comment was not clear. `thread_of_waiter` looks suspicious - will JVMTI find the vthread from the JavaThread? >> src/hotspot/share/runtime/synchronizer.cpp line 670: >> >>> 668: // Top native frames in the stack will not be seen if we attempt >>> 669: // preemption, since we start walking from the last Java anchor. >>> 670: NoPreemptMark npm(current); >> >> Don't we still pin for JNI monitor usage? > > Only when facing contention on this call. But once we have the monitor we don't. But if this is from JNI then we have at least one native frame on the stack making the JNI call, so we have to be pinned if we were to block on the monitor. ??? >> src/java.base/share/classes/java/lang/VirtualThread.java line 111: >> >>> 109: * BLOCKING -> BLOCKED // blocked on monitor enter >>> 110: * BLOCKED -> UNBLOCKED // unblocked, may be scheduled to continue >>> 111: * UNBLOCKED -> RUNNING // continue execution after blocked on monitor enter >> >> Presumably this one means it acquired the monitor? > > Not really, it is the state we set when the virtual thread is mounted and runs again. In this case it will just run to re-contest for the monitor. So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have: RUNNING -> BLOCKING -> BLOCKED BLOCKED -> UNBLOCKING -> RUNNABLE I'm just trying to get a better sense of what we can infer if we see these "transition" states. >> src/java.base/share/classes/java/lang/VirtualThread.java line 952: >> >>> 950: for (;;) { >>> 951: boolean unblocked = false; >>> 952: synchronized (timedWaitLock()) { >> >> Where is the overall design of the timed-wait protocol and it use of synchronization described? > > When we unmount on a timed-wait call we schedule a wakeup task at the end of `afterYield`. There are two mechanisms that avoid the scheduled task to run and wake up the virtual thread on a future timed-wait call, since in this call the virtual thread could have been already notified before the scheduled task runs. The first one is to cancel the scheduled task once we return from the wait call (see `Object.wait(long timeoutMillis)`). Since the task could have been already started though, we also use `timedWaitSeqNo`, which the wake up task checks here to make sure it is not an old one. Since we synchronize on `timedWaitLock` to increment `timedWaitSeqNo` and change state to `TIMED_WAIT` before scheduling the wake up task in `afterYield`, here either a wrong `timedWaitSeqNo` or a state different than `TIMED_WAIT` means there is nothing to do. The only exception is checking for `SUSPENDED` state, in which case we just loop to retry. Thanks for the explanation but that needs to be documented somewhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818239594 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811933408 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811935087 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814330162 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818236368 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818240013 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814163283 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818228510 From alanb at openjdk.org Wed Nov 6 17:40:10 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <_NABF4JJUlSQ9_XfNtXtDGFIkqOPpDcUaoL6wAaJFkY=.70199a12-d9cd-4a85-86e1-2dbdaf474300@github.com> On Wed, 23 Oct 2024 00:56:34 GMT, Coleen Phillimore wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/runtime/javaThread.cpp line 2002: > >> 2000: #ifdef SUPPORT_MONITOR_COUNT >> 2001: >> 2002: #ifdef LOOM_MONITOR_SUPPORT > > If LOOM_MONITOR_SUPPORT is not true, this would skip this block and assert for LIGHTWEIGHT locking. Do we need this #ifdef ? LOOM_MONITOR_SUPPORT was only needed when there were ports missing. All 4 are included now so this goes away. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812389702 From alanb at openjdk.org Wed Nov 6 17:40:10 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com> References: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com> Message-ID: On Wed, 23 Oct 2024 09:53:53 GMT, Richard Reingruber wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/runtime/javaThread.hpp line 166: > >> 164: // current _vthread object, except during creation of the primordial and JNI >> 165: // attached thread cases where this field can have a temporary value. >> 166: int64_t _lock_id; > > Following the review I wanted to better understand when `_lock_id` changes. There seems to be another exception to the rule that `_lock_id` is equal to the `tid` of the current `_vthread`. I think they won't be equal when switching temporarily from the virtual to the carrier thread in `VirtualThread::switchToCarrierThread()`. Right, and we hope this temporary. We had more use of temporary transitions when the feature was initially added in JDK 19, now we mostly down to the nested parking issue. That will go away when we get to replacing the timer code, and we should be able to remove the switchXXX method and avoid the distraction/complexity that goes with them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812385061 From sspitsyn at openjdk.org Wed Nov 6 17:40:10 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 09:24:03 GMT, Alan Bateman wrote: > So at some point I think we need to figure out how to make them go away ... Yes, the 2 extension events (`VirtualThreadMount` and `VirtualThreadUnmount`) were added for testing purposes. We wanted to get rid of them at some point but the Graal team was using them for some purposes. > It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor... The two extension events were designed to be posted when the current thread identity is virtual, so this behavior needs to be considered as a bug. My understanding is that it is not easy to fix. We most likely, we have no tests to fail because of this though. > That's the path a virtual thread will take if pinned. Got it, thanks. I realize it is because we do not thaw and freeze the VM frames. It is not easy to comprehend. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831293112 From pchilanomate at openjdk.org Wed Nov 6 17:40:10 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Mon, 28 Oct 2024 00:35:11 GMT, David Holmes wrote: >> This vthread was unmounted on the call to `Object.wait`. Now it is mounted and "running" again, and we need to check which case it is in: notified, interrupted or timed-out. "First time" means it is the first time it's running after the original unmount on `Object.wait`. This is because once we are on the monitor reentry phase, the virtual thread can be potentially unmounted and mounted many times until it successfully acquires the monitor. Not sure how to rewrite the comment to make it clearer. > > The first sentence is not a sentence. Is it supposed to be saying: > > // The first time we run after being preempted on Object.wait() > // we check if we were interrupted or the wait timed-out ... > > ? Yes, I fixed the wording. >> So the value stored in _owner has to be ANONYMOUS_OWNER. We cannot store the BasicLock* in there as before since it can clash with some other thread's tid. We store it in the new field _stack_locker instead. > > Right I understand we can't store the BasicLock* directly in owner, but the naming of this method has me confused as to what it actually does. With the old version we have: > > Before: owner = BasicLock* belonging to current > After: owner = JavaThread* of current > > with the new version we have: > > Before: owner = ANONYMOUS_OWNER > After: owner = tid of current > > so "BasicLock" doesn't mean anything here any more. Isn't this just `set_owner_from_anonymous` ? I see your point. I removed this method and had the only caller just call set_owner_from_anonymous() and set_stack_locker(nullptr). There was one other caller in ObjectMonitor::complete_exit() but it was actually not needed so I removed it. ObjectMonitor::complete_exit() is only called today on JavaThread exit to possibly unlock monitors acquired through JNI that where not unlocked. >> It is, we still increment _waiters for the vthread case. > > Sorry the target of my comment was not clear. `thread_of_waiter` looks suspicious - will JVMTI find the vthread from the JavaThread? If the ObjectWaiter is associated with a vthread(we unmounted in `Object.wait`) we just return null. We'll skip it from JVMTI code. >> Only when facing contention on this call. But once we have the monitor we don't. > > But if this is from JNI then we have at least one native frame on the stack making the JNI call, so we have to be pinned if we were to block on the monitor. ??? We will have the native wrapper frame at the top, but we still need to add some extra check to differentiate this `jni_enter()` case with respect to the case of facing contention on a synchronize native method, where we do allow to unmount (only when coming from the interpreter since the changes to support it where minimal). I used the NoPreemptMark here, but we could filter this case anywhere along the freeze path. Another option could be to check `thread->current_pending_monitor_is_from_java()` in the ObjectMonitor code before trying to preempt. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819907304 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815697784 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819834478 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819907921 From alanb at openjdk.org Wed Nov 6 17:40:10 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 00:01:21 GMT, Patricio Chilano Mateo wrote: >>> Is this posted after the VirtualThreadMount extension event posted? >>> >> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620 > >> The JvmtiExport::post_monitor_waited() is called at the line 1801. >> Does it post the MonitorWaited event for this virtual thread as well? >> > That's the path a virtual thread will take if pinned. This case is when we were able to unmount the vthread. It is the equivalent, where the vthread finished the wait part (notified, interrupted or timed-out case) and it's going to retry acquiring the monitor. Just to add that the 2 extension events (VirtualThreadMount and VirtualThreadUnmount) are not part of any supported/documented interface. They are a left over from the exploration phase of virtual threads when we assumed the debugger agent would need to track the transitions. So at some point I think we need to figure out how to make them go away as they are an attractive nuisance (esp. if the event callback were to upcall and execute Java code). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830657204 From pchilanomate at openjdk.org Wed Nov 6 17:40:10 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com> Message-ID: On Wed, 23 Oct 2024 09:58:44 GMT, Alan Bateman wrote: >> src/hotspot/share/runtime/javaThread.hpp line 166: >> >>> 164: // current _vthread object, except during creation of the primordial and JNI >>> 165: // attached thread cases where this field can have a temporary value. >>> 166: int64_t _lock_id; >> >> Following the review I wanted to better understand when `_lock_id` changes. There seems to be another exception to the rule that `_lock_id` is equal to the `tid` of the current `_vthread`. I think they won't be equal when switching temporarily from the virtual to the carrier thread in `VirtualThread::switchToCarrierThread()`. > > Right, and we hope this temporary. We had more use of temporary transitions when the feature was initially added in JDK 19, now we mostly down to the nested parking issue. That will go away when we get to replacing the timer code, and we should be able to remove the switchXXX method and avoid the distraction/complexity that goes with them. I extended the comment to mention this case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814189388 From coleenp at openjdk.org Wed Nov 6 17:40:11 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:40:11 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Wed, 23 Oct 2024 20:42:44 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/objectMonitor.hpp line 299: >> >>> 297: // Simply set _owner field to new_value; current value must match old_value. >>> 298: void set_owner_from_raw(int64_t old_value, int64_t new_value); >>> 299: // Same as above but uses tid of current as new value. >> >> By `tid` here (and elsewhere) you actually mean `thread->threadObj()->thread_id()` - right? > > It is `thread->vthread()->thread_id()` but it will match `thread->threadObj()->thread_id()` when there is no virtual thread mounted. But we cache it in thread->_lockd_id so we retrieve it from there. I think we should probably change the name of _lock_id. but we can't change it there to thread_id because then it would be too confusing. Since it's used for locking, lock_id seems like a good name. >> src/hotspot/share/runtime/objectMonitor.hpp line 315: >> >>> 313: void set_succesor(oop vthread); >>> 314: void clear_succesor(); >>> 315: bool has_succesor(); >> >> Sorry but `successor` has two `s` before `or`. > > Fixed. Yes, need to fix successor spelling. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817420867 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811616558 From pchilanomate at openjdk.org Wed Nov 6 17:40:11 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:11 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com> Message-ID: <2y3cYO8ua_6QovrRnR6ndjSA6apEMXRdaNfnn_m2NdE=.0f1297b9-be4e-4fb9-b34d-4db86ad9a7f8@github.com> On Mon, 28 Oct 2024 13:12:22 GMT, Richard Reingruber wrote: >> src/hotspot/share/runtime/objectMonitor.hpp line 202: >> >>> 200: >>> 201: // Used in LM_LEGACY mode to store BasicLock* in case of inflation by contending thread. >>> 202: BasicLock* volatile _stack_locker; >> >> IIUC the new field `_stack_locker` is needed because we cannot store the `BasicLock*` anymore in the `_owner` field as it could be interpreted as a thread id by mistake. >> Wouldn't it be an option to have only odd thread ids? Then we could store the `BasicLock*` in the `_owner` field without loosing the information if it is a `BasicLock*` or a thread id. I think this would reduce complexity quite a bit, woudn't it? > > `ObjectMonitor::_owner` would never be `ANONYMOUS_OWNER` with `LM_LEGACY`. I remember I thought about doing this but discarded it. I don't think it will reduce complexity since we still need to handle that as a special case. In fact I removed several checks throughout the ObjectMonitor code where we had to check for this case. Now it works like with LM_LIGHTWEIGHT (also a plus), where once the owner gets into ObjectMonitor the owner will be already fixed. So setting and clearing _stack_locker is contained here in ObjectSynchronizer::inflate_impl(). Granted that we could do the same when restricting the ids, but then complexity would be the same. Also even though there are no guarantees about the ids I think it might look weird for somebody looking at a thread dump to only see odd ids. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819748043 From rrich at openjdk.org Wed Nov 6 17:40:11 2024 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 6 Nov 2024 17:40:11 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com> References: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com> Message-ID: On Mon, 28 Oct 2024 13:08:37 GMT, Richard Reingruber wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/runtime/objectMonitor.hpp line 202: > >> 200: >> 201: // Used in LM_LEGACY mode to store BasicLock* in case of inflation by contending thread. >> 202: BasicLock* volatile _stack_locker; > > IIUC the new field `_stack_locker` is needed because we cannot store the `BasicLock*` anymore in the `_owner` field as it could be interpreted as a thread id by mistake. > Wouldn't it be an option to have only odd thread ids? Then we could store the `BasicLock*` in the `_owner` field without loosing the information if it is a `BasicLock*` or a thread id. I think this would reduce complexity quite a bit, woudn't it? `ObjectMonitor::_owner` would never be `ANONYMOUS_OWNER` with `LM_LEGACY`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819034645 From stefank at openjdk.org Wed Nov 6 17:40:11 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 6 Nov 2024 17:40:11 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... src/hotspot/share/runtime/objectMonitor.hpp line 325: > 323: } > 324: > 325: bool has_owner_anonymous() const { return owner_raw() == ANONYMOUS_OWNER; } Small, drive-by comment. The rename to `has_owner_anonymous` sounds worse than the previous `is_owner_anonymous` name. I think the code reads better if you change it to `has_anonymous_owner`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814489387 From dholmes at openjdk.org Wed Nov 6 17:40:11 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:11 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 11:59:03 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/objectMonitor.hpp line 174: >> >>> 172: >>> 173: int64_t volatile _owner; // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER. >>> 174: volatile uint64_t _previous_owner_tid; // thread id of the previous owner of the monitor >> >> Looks odd to have the current owner as `int64_t` but we save the previous owner as `uint64_t`. ?? > > I was wondering what this was too but the _previous_owner_tid is the os thread id, not the Java thread id. > > > $ grep -r JFR_THREAD_ID > jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) (JfrThreadLocal::external_thread_id(thread)) > jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) ((traceid)(thread)->osthread()->thread_id()) > runtime/objectMonitor.cpp: _previous_owner_tid = JFR_THREAD_ID(current); > runtime/objectMonitor.cpp: iterator->_notifier_tid = JFR_THREAD_ID(current); > runtime/vmThread.cpp: event->set_caller(JFR_THREAD_ID(op->calling_thread())); Then it looks like the JFR code needs updating as well, otherwise it is going to be reporting inconsistent information when virtual threads are locking monitors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818234543 From pchilanomate at openjdk.org Wed Nov 6 17:40:11 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:11 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 24 Oct 2024 08:08:56 GMT, Stefan Karlsson wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/runtime/objectMonitor.hpp line 325: > >> 323: } >> 324: >> 325: bool has_owner_anonymous() const { return owner_raw() == ANONYMOUS_OWNER; } > > Small, drive-by comment. The rename to `has_owner_anonymous` sounds worse than the previous `is_owner_anonymous` name. I think the code reads better if you change it to `has_anonymous_owner`. I renamed both `set/has_owner_anonymous` to `set/has_anonymous_owner`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815701746 From pchilanomate at openjdk.org Wed Nov 6 17:40:11 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:11 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.67f63f45-ca6f-4e4c-8989-00e3740a861a@github.com> Message-ID: On Thu, 31 Oct 2024 16:34:41 GMT, Patricio Chilano Mateo wrote: >> General convention is that racily accessed variables should be accessed via Atomic::load/store to make it clear(er) they are racy accesses. But I agree it seems odd when direct accesses to `_succ` in the main cpp file are not atomic. > >> Why are _succ accesses atomic here when previously they were not? >> > They should had always been atomic. > But I agree it seems odd when direct accesses to _succ in the main cpp file are not atomic. > There was only one remaining direct access in debugging function `print_debug_style_on` which I fixed now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824794795 From dholmes at openjdk.org Wed Nov 6 17:40:11 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:11 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.67f63f45-ca6f-4e4c-8989-00e3740a861a@github.com> On Thu, 31 Oct 2024 01:32:19 GMT, Dean Long wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/runtime/objectMonitor.inline.hpp line 207: > >> 205: } >> 206: >> 207: inline bool ObjectMonitor::has_successor() { > > Why are _succ accesses atomic here when previously they were not? General convention is that racily accessed variables should be accessed via Atomic::load/store to make it clear(er) they are racy accesses. But I agree it seems odd when direct accesses to `_succ` in the main cpp file are not atomic. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823698001 From pchilanomate at openjdk.org Wed Nov 6 17:40:12 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 12:00:43 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/synchronizer.cpp line 1440: >> >>> 1438: } >>> 1439: >>> 1440: ObjectMonitor* ObjectSynchronizer::inflate_impl(JavaThread* inflating_thread, oop object, const InflateCause cause) { >> >> `inflating_thread` doesn't sound right as it is always the current thread that is doing the inflating. The passed in thread may be a different thread trying to acquire the monitor ... perhaps `contending_thread`? > > If it's always the current thread, then it should be called 'current' imo. I see that in lightweightSynchronizer.cpp we already use the name `locking_thread` (although `LightweightSynchronizer::inflate_into_object_header` still uses `inflating_thread`). So how about using `locking_thread` instead? I can fix `LightweightSynchronizer::inflate_into_object_header` too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817389380 From pchilanomate at openjdk.org Wed Nov 6 17:40:11 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:11 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.67f63f45-ca6f-4e4c-8989-00e3740a861a@github.com> References: <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.67f63f45-ca6f-4e4c-8989-00e3740a861a@github.com> Message-ID: On Thu, 31 Oct 2024 02:26:42 GMT, David Holmes wrote: >> src/hotspot/share/runtime/objectMonitor.inline.hpp line 207: >> >>> 205: } >>> 206: >>> 207: inline bool ObjectMonitor::has_successor() { >> >> Why are _succ accesses atomic here when previously they were not? > > General convention is that racily accessed variables should be accessed via Atomic::load/store to make it clear(er) they are racy accesses. But I agree it seems odd when direct accesses to `_succ` in the main cpp file are not atomic. > Why are _succ accesses atomic here when previously they were not? > They should had always been atomic. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824794270 From coleenp at openjdk.org Wed Nov 6 17:40:12 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 21:29:05 GMT, Patricio Chilano Mateo wrote: >> I see that in lightweightSynchronizer.cpp we already use the name `locking_thread` (although `LightweightSynchronizer::inflate_into_object_header` still uses `inflating_thread`). So how about using `locking_thread` instead? I can fix `LightweightSynchronizer::inflate_into_object_header` too. > >> If it's always the current thread, then it should be called 'current' imo. >> > The inflating thread is always the current one but it's not always equal to `inflating_thread`. I thought locking_thread there may not be the current thread for enter_for() in deopt. It's the thread that should hold the lock but not the current thread. But it might be different now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817423564 From pchilanomate at openjdk.org Wed Nov 6 17:40:12 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 21:28:22 GMT, Patricio Chilano Mateo wrote: >> If it's always the current thread, then it should be called 'current' imo. > > I see that in lightweightSynchronizer.cpp we already use the name `locking_thread` (although `LightweightSynchronizer::inflate_into_object_header` still uses `inflating_thread`). So how about using `locking_thread` instead? I can fix `LightweightSynchronizer::inflate_into_object_header` too. > If it's always the current thread, then it should be called 'current' imo. > The inflating thread is always the current one but it's not always equal to `inflating_thread`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817389882 From dholmes at openjdk.org Wed Nov 6 17:40:12 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.96865d82-6267-4065-a3d5-6eb56d958a00@github.com> On Fri, 25 Oct 2024 22:29:56 GMT, Coleen Phillimore wrote: >>> If it's always the current thread, then it should be called 'current' imo. >>> >> The inflating thread is always the current one but it's not always equal to `inflating_thread`. > > I thought locking_thread there may not be the current thread for enter_for() in deopt. It's the thread that should hold the lock but not the current thread. But it might be different now. The thread passed in need not be the current thread, and IIUC is the thread that should become the owner of the newly inflated monitor (either current thread or a suspended thread). The actual inflation is always done by the current thread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818240440 From pchilanomate at openjdk.org Wed Nov 6 17:40:12 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.96865d82-6267-4065-a3d5-6eb56d958a00@github.com> Message-ID: <1MAelVhUXDdz7GI63iJPUEg6QeOQ4DO4S0B0_eC3CRQ=.ec5ff767-4b75-40ab-b40c-1579907b978a@github.com> On Mon, 28 Oct 2024 11:59:57 GMT, Coleen Phillimore wrote: >> The thread passed in need not be the current thread, and IIUC is the thread that should become the owner of the newly inflated monitor (either current thread or a suspended thread). The actual inflation is always done by the current thread. > > ok, I now I see what the discussion is. Yes I think locking_thread is better than inflating thread in this. Unless it's a bigger cleanup and we can do it post-integrating this. Changed to locking_thread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819461999 From alanb at openjdk.org Wed Nov 6 17:40:12 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.c460c377-e8a9-4fd3-b8f4-5063ddd5aedd@github.com> On Thu, 24 Oct 2024 02:47:14 GMT, David Holmes wrote: >> Not really, it is the state we set when the virtual thread is mounted and runs again. In this case it will just run to re-contest for the monitor. > > So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have: > > RUNNING -> BLOCKING -> BLOCKED > BLOCKED -> UNBLOCKING -> RUNNABLE > > I'm just trying to get a better sense of what we can infer if we see these "transition" states. We named it UNBLOCKED when unblocked, like UNPARKED when unparked, as that accurately describes the state at this point. It's not mounted but may be scheduled to continue. In the user facing APIs this is mapped to "RUNNABLE", it's the equivalent of OS thread queued to the OS scheduler. So I think the name is good and would prefer not change it. >> When we unmount on a timed-wait call we schedule a wakeup task at the end of `afterYield`. There are two mechanisms that avoid the scheduled task to run and wake up the virtual thread on a future timed-wait call, since in this call the virtual thread could have been already notified before the scheduled task runs. The first one is to cancel the scheduled task once we return from the wait call (see `Object.wait(long timeoutMillis)`). Since the task could have been already started though, we also use `timedWaitSeqNo`, which the wake up task checks here to make sure it is not an old one. Since we synchronize on `timedWaitLock` to increment `timedWaitSeqNo` and change state to `TIMED_WAIT` before scheduling the wake up task in `afterYield`, here either a wrong `timedWaitSeqNo` or a state different than `TIMED_WAIT` means there is nothing to do. The only exception is checking for `SUSPENDED` state, in which case we just loop to retry. > > Thanks for the explanation but that needs to be documented somewhere. The comment in afterYield has been expanded in the loom repo, we may be able to bring that update in. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814517084 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818670426 From coleenp at openjdk.org Wed Nov 6 17:40:12 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.96865d82-6267-4065-a3d5-6eb56d958a00@github.com> References: <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.96865d82-6267-4065-a3d5-6eb56d958a00@github.com> Message-ID: On Mon, 28 Oct 2024 00:38:39 GMT, David Holmes wrote: >> I thought locking_thread there may not be the current thread for enter_for() in deopt. It's the thread that should hold the lock but not the current thread. But it might be different now. > > The thread passed in need not be the current thread, and IIUC is the thread that should become the owner of the newly inflated monitor (either current thread or a suspended thread). The actual inflation is always done by the current thread. ok, I now I see what the discussion is. Yes I think locking_thread is better than inflating thread in this. Unless it's a bigger cleanup and we can do it post-integrating this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818935916 From sparasa at openjdk.org Wed Nov 6 17:51:31 2024 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Wed, 6 Nov 2024 17:51:31 GMT Subject: RFR: 8343317: Extend test generation tool to handle APX NDD/NF flavor of instructions [v3] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 17:45:39 GMT, hanklo6 wrote: >> test/hotspot/gtest/x86/test_assemblerx86.cpp line 1: >> >>> 1: /* >> >> [Optional] In lines 53 and 58, it prints "Ours" and "Theirs". This is vague. However, it looks like this is the convention used in test_assembler_aarch64.cpp as well. > > Thanks, I updated the label. Thanks Hank! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21795#discussion_r1831476221 From dholmes at openjdk.org Wed Nov 6 17:40:12 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> Message-ID: <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> On Tue, 22 Oct 2024 11:52:46 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/lang/VirtualThread.java line 115: >> >>> 113: * RUNNING -> WAITING // transitional state during wait on monitor >>> 114: * WAITING -> WAITED // waiting on monitor >>> 115: * WAITED -> BLOCKED // notified, waiting to be unblocked by monitor owner >> >> Waiting to re-enter the monitor? > > yes Okay so should it say that? >> src/java.base/share/classes/java/lang/VirtualThread.java line 178: >> >>> 176: // timed-wait support >>> 177: private long waitTimeout; >>> 178: private byte timedWaitNonce; >> >> Strange name - what does this mean? > > Sequence number, nouce, anything will work here as it's just to deal with the scenario where the timeout task for a previous wait may run concurrently with a subsequent wait. Suggestion: `timedWaitCounter` ? >> src/java.base/share/classes/java/lang/VirtualThread.java line 530: >> >>> 528: && carrier == Thread.currentCarrierThread(); >>> 529: carrier.setCurrentThread(carrier); >>> 530: Thread.setCurrentLockId(this.threadId()); // keep lock ID of virtual thread >> >> I'm struggling to understand the different threads in play when this is called and what the method actual does to which threads. ?? > > A virtual thread is mounted but doing a timed-park that requires temporarily switching to the identity of the carrier (identity = Therad.currentThread) when queuing the timer task. As mentioned in a reply to Axel, we are close to the point of removing this (nothing to do with object monitors of course, we've had the complexity with temporary transitions since JDK 19). > > More context here is that there isn't support yet for a carrier to own a monitor before a virtual thread is mounted, and same thing during these temporary transitions. If support for custom schedulers is exposed then that issue will need to be addressed as you don't want some entries on the lock stack owned by the carrier and the others by the mounted virtual thread. Patricio has mentioned inflating any held monitors before mount. There are a couple of efforts in this area going on now, all would need that issue fixed before anything is exposed. Okay but .... 1. We have the current virtual thread 2. We have the current carrier for that virtual thread (which is iotself a java.alng.Thread object 3. We have Thread.setCurrentLockId which ... ? which thread does it update? And what does "current" refer to in the name? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811937674 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811938604 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810615473 From alanb at openjdk.org Wed Nov 6 17:40:12 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> Message-ID: On Wed, 23 Oct 2024 06:11:26 GMT, David Holmes wrote: >> Sequence number, nouce, anything will work here as it's just to deal with the scenario where the timeout task for a previous wait may run concurrently with a subsequent wait. > > Suggestion: `timedWaitCounter` ? We could rename it to timedWaitSeqNo if needed. >> A virtual thread is mounted but doing a timed-park that requires temporarily switching to the identity of the carrier (identity = Therad.currentThread) when queuing the timer task. As mentioned in a reply to Axel, we are close to the point of removing this (nothing to do with object monitors of course, we've had the complexity with temporary transitions since JDK 19). >> >> More context here is that there isn't support yet for a carrier to own a monitor before a virtual thread is mounted, and same thing during these temporary transitions. If support for custom schedulers is exposed then that issue will need to be addressed as you don't want some entries on the lock stack owned by the carrier and the others by the mounted virtual thread. Patricio has mentioned inflating any held monitors before mount. There are a couple of efforts in this area going on now, all would need that issue fixed before anything is exposed. > > Okay but .... > 1. We have the current virtual thread > 2. We have the current carrier for that virtual thread (which is iotself a java.alng.Thread object > 3. We have Thread.setCurrentLockId which ... ? which thread does it update? And what does "current" refer to in the name? Thread identity switches to the carrier so Thread.currentThread() is the carrier thread and JavaThread._lock_id is the thread identifier of the carrier. setCurrentLockId changes JavaThread._lock_id back to the virtual thread's identifier. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812537648 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810636960 From dholmes at openjdk.org Wed Nov 6 17:40:13 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> Message-ID: On Tue, 22 Oct 2024 12:31:24 GMT, Alan Bateman wrote: >> Okay but .... >> 1. We have the current virtual thread >> 2. We have the current carrier for that virtual thread (which is iotself a java.alng.Thread object >> 3. We have Thread.setCurrentLockId which ... ? which thread does it update? And what does "current" refer to in the name? > > Thread identity switches to the carrier so Thread.currentThread() is the carrier thread and JavaThread._lock_id is the thread identifier of the carrier. setCurrentLockId changes JavaThread._lock_id back to the virtual thread's identifier. If the virtual thread is un-mounting from the carrier, why do we need to set the "lock id" back to the virtual thread's id? Sorry I'm finding this quite confusing. Also `JavaThread::_lock_id` in the VM means "the java.lang.Thread thread-id to use for locking" - correct? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811877637 From dholmes at openjdk.org Wed Nov 6 17:40:12 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.c460c377-e8a9-4fd3-b8f4-5063ddd5aedd@github.com> References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.c460c377-e8a9-4fd3-b8f4-5063ddd5aedd@github.com> Message-ID: On Thu, 24 Oct 2024 08:26:12 GMT, Alan Bateman wrote: >> So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have: >> >> RUNNING -> BLOCKING -> BLOCKED >> BLOCKED -> UNBLOCKING -> RUNNABLE >> >> I'm just trying to get a better sense of what we can infer if we see these "transition" states. > > We named it UNBLOCKED when unblocked, like UNPARKED when unparked, as that accurately describes the state at this point. It's not mounted but may be scheduled to continue. In the user facing APIs this is mapped to "RUNNABLE", it's the equivalent of OS thread queued to the OS scheduler. So I think the name is good and would prefer not change it. Okay but I'm finding it hard to see these names and easily interpret what some of them mean. I think there is a difference between UNBLOCKED and UNPARKED, because as an API once you are unparked that is it - operation over. But for UNBLOCKED you are still in a transitional state and it is not yet determined what you will actually end up doing i.e. get the monitor or block again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815761305 From pchilanomate at openjdk.org Wed Nov 6 17:40:12 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> Message-ID: On Wed, 23 Oct 2024 11:32:54 GMT, Alan Bateman wrote: >> Suggestion: `timedWaitCounter` ? > > We could rename it to timedWaitSeqNo if needed. Ok, renamed to timedWaitSeqNo. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813240667 From dholmes at openjdk.org Wed Nov 6 17:40:13 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.9c35109b-7e23-4525-8ca7-7fc3d272844b@github.com> Message-ID: On Thu, 24 Oct 2024 21:08:47 GMT, Patricio Chilano Mateo wrote: >> I guess I don't understand where this piece code fits in the overall transition of the virtual thread to being parked. I would have expected the LockStack to already have been moved by the time we switch identities to the carrier thread. > > We don't unmount the virtual thread here, we just temporarily change the thread identity. You could think of this method as switchIdentityToCarrierThread if that helps. Sorry to belabour this but why are we temporarily changing the thread identity? What is the bigger operation that in underway here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815762233 From pchilanomate at openjdk.org Wed Nov 6 17:40:13 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.9c35109b-7e23-4525-8ca7-7fc3d272844b@github.com> References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.9c35109b-7e23-4525-8ca7-7fc3d272844b@github.com> Message-ID: On Thu, 24 Oct 2024 02:55:18 GMT, David Holmes wrote: >>> Also JavaThread::_lock_id in the VM means "the java.lang.Thread thread-id to use for locking" - correct? >>> >> Yes. > > I guess I don't understand where this piece code fits in the overall transition of the virtual thread to being parked. I would have expected the LockStack to already have been moved by the time we switch identities to the carrier thread. We don't unmount the virtual thread here, we just temporarily change the thread identity. You could think of this method as switchIdentityToCarrierThread if that helps. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815697084 From pchilanomate at openjdk.org Wed Nov 6 17:40:13 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> Message-ID: On Wed, 23 Oct 2024 20:34:48 GMT, Patricio Chilano Mateo wrote: >> If the virtual thread is un-mounting from the carrier, why do we need to set the "lock id" back to the virtual thread's id? Sorry I'm finding this quite confusing. >> >> Also `JavaThread::_lock_id` in the VM means "the java.lang.Thread thread-id to use for locking" - correct? > > Sorry, I should add context on why this is needed. The problem is that inside this temporal transition we could try to acquire some monitor. If the monitor is not inflated we will try to use the LockStack, but the LockStack might be full from monitors the virtual thread acquired before entering this transition. Since the LockStack is full we will try to make room by inflating one or more of the monitors in it [1]. But when inflating the monitors we would be using the j.l.Thread.tid of the carrier (set into _lock_id when switching the identity), which is wrong. We need to use the j.l.Thread.tid of the virtual thread, so we need to change _lock_id back. > We are not really unmounting the virtual thread, the only thing that we want is to set the identity to the carrier thread so that we don't end up in this nested calls to parkNanos. > > [1] https://github.com/openjdk/jdk/blob/afb62f73499c09f4a7bde6f522fcd3ef1278e526/src/hotspot/share/runtime/lightweightSynchronizer.cpp#L491 > Also JavaThread::_lock_id in the VM means "the java.lang.Thread thread-id to use for locking" - correct? > Yes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813507846 From dholmes at openjdk.org Wed Nov 6 17:40:13 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> Message-ID: <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.9c35109b-7e23-4525-8ca7-7fc3d272844b@github.com> On Wed, 23 Oct 2024 20:36:23 GMT, Patricio Chilano Mateo wrote: >> Sorry, I should add context on why this is needed. The problem is that inside this temporal transition we could try to acquire some monitor. If the monitor is not inflated we will try to use the LockStack, but the LockStack might be full from monitors the virtual thread acquired before entering this transition. Since the LockStack is full we will try to make room by inflating one or more of the monitors in it [1]. But when inflating the monitors we would be using the j.l.Thread.tid of the carrier (set into _lock_id when switching the identity), which is wrong. We need to use the j.l.Thread.tid of the virtual thread, so we need to change _lock_id back. >> We are not really unmounting the virtual thread, the only thing that we want is to set the identity to the carrier thread so that we don't end up in this nested calls to parkNanos. >> >> [1] https://github.com/openjdk/jdk/blob/afb62f73499c09f4a7bde6f522fcd3ef1278e526/src/hotspot/share/runtime/lightweightSynchronizer.cpp#L491 > >> Also JavaThread::_lock_id in the VM means "the java.lang.Thread thread-id to use for locking" - correct? >> > Yes. I guess I don't understand where this piece code fits in the overall transition of the virtual thread to being parked. I would have expected the LockStack to already have been moved by the time we switch identities to the carrier thread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814167842 From alanb at openjdk.org Wed Nov 6 17:40:13 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.9c35109b-7e23-4525-8ca7-7fc3d272844b@github.com> Message-ID: On Thu, 24 Oct 2024 22:13:27 GMT, David Holmes wrote: >> We don't unmount the virtual thread here, we just temporarily change the thread identity. You could think of this method as switchIdentityToCarrierThread if that helps. > > Sorry to belabour this but why are we temporarily changing the thread identity? What is the bigger operation that in underway here? We've had these temporary transitions from day 1. The changes in this PR remove one usage, they don't add any new usages. The intention is to make this nuisance go away. The last usage requires changes to the timer support, working on it. For now, it's easiest to think of it as a "java on java" issue where critical code is in Java rather than the VM. The timer issue arises when a virtual thread does a timed park needs to schedule and cancel a timer. This currently requires executing Java code that may contend on a timer or trigger a timer thread to start. This has implications for thread state, the park blocker, and the parking permit. Adding support for nested parking gets very messy, adds overhead, and is confusing for serviceability observers. The exiting behavior is to just temporarily switch the thread identity (as in Thread::currentThread) so it executes in the context of the carrier rather than the virtual thread. As I said, we are working to make this go away, it would have been nice to have removed in advance of the changes here. Update: The temporary transitions are now removed in the fibers branch (loom repo). This removes the switchToCarrierThread and switchToVirtualThread methods, and removes the need to introduce setCurrentLockId that is hard to explain in the discussions here. Need to decide if we should include it in this PR or try to do it before or after. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816425590 From pchilanomate at openjdk.org Wed Nov 6 17:40:13 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> Message-ID: On Wed, 23 Oct 2024 05:18:10 GMT, David Holmes wrote: >> Thread identity switches to the carrier so Thread.currentThread() is the carrier thread and JavaThread._lock_id is the thread identifier of the carrier. setCurrentLockId changes JavaThread._lock_id back to the virtual thread's identifier. > > If the virtual thread is un-mounting from the carrier, why do we need to set the "lock id" back to the virtual thread's id? Sorry I'm finding this quite confusing. > > Also `JavaThread::_lock_id` in the VM means "the java.lang.Thread thread-id to use for locking" - correct? Sorry, I should add context on why this is needed. The problem is that inside this temporal transition we could try to acquire some monitor. If the monitor is not inflated we will try to use the LockStack, but the LockStack might be full from monitors the virtual thread acquired before entering this transition. Since the LockStack is full we will try to make room by inflating one or more of the monitors in it [1]. But when inflating the monitors we would be using the j.l.Thread.tid of the carrier (set into _lock_id when switching the identity), which is wrong. We need to use the j.l.Thread.tid of the virtual thread, so we need to change _lock_id back. We are not really unmounting the virtual thread, the only thing that we want is to set the identity to the carrier thread so that we don't end up in this nested calls to parkNanos. [1] https://github.com/openjdk/jdk/blob/afb62f73499c09f4a7bde6f522fcd3ef1278e526/src/hotspot/share/runtime/lightweightSynchronizer.cpp#L491 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813503450 From aturbanov at openjdk.org Wed Nov 6 17:40:13 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... test/jdk/java/lang/Thread/virtual/JfrEvents.java line 323: > 321: var started2 = new AtomicBoolean(); > 322: > 323: Thread vthread1 = Thread.ofVirtual().unstarted(() -> { Suggestion: Thread vthread1 = Thread.ofVirtual().unstarted(() -> { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808287799 From pchilanomate at openjdk.org Wed Nov 6 17:40:13 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 20:28:06 GMT, Alan Bateman wrote: >> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 57: >> >>> 55: static { >>> 56: try { >>> 57: MethodHandles.lookup().ensureInitialized(AnchorCertificates.class); >> >> Why is this needed? A comment would help. > > That's probably a good idea. It?s caused by pinning due to the sun.security.util.AnchorCertificates?s class initializer, some of the http client tests are running into this. Once monitors are out of the way then class initializers, both executing, and waiting for, will be a priority. Added comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826153929 From pchilanomate at openjdk.org Wed Nov 6 17:40:13 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.c460c377-e8a9-4fd3-b8f4-5063ddd5aedd@github.com> References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.c460c377-e8a9-4fd3-b8f4-5063ddd5aedd@github.com> Message-ID: On Mon, 28 Oct 2024 09:19:48 GMT, Alan Bateman wrote: >> Thanks for the explanation but that needs to be documented somewhere. > > The comment in afterYield has been expanded in the loom repo, we may be able to bring that update in. Brought the comment from the loom repo. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826160691 From pchilanomate at openjdk.org Wed Nov 6 17:40:13 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 21 Oct 2024 08:01:09 GMT, Andrey Turbanov wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > test/jdk/java/lang/Thread/virtual/JfrEvents.java line 323: > >> 321: var started2 = new AtomicBoolean(); >> 322: >> 323: Thread vthread1 = Thread.ofVirtual().unstarted(() -> { > > Suggestion: > > Thread vthread1 = Thread.ofVirtual().unstarted(() -> { Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809073267 From pchilanomate at openjdk.org Wed Nov 6 17:52:59 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:52:59 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 06:36:58 GMT, Axel Boldt-Christmas wrote: > A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this. > > ``` > // the sp of the oldest known interpreted/call_stub frame inside the > // continuation that we know about > ``` > Updated comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2460396452 From pchilanomate at openjdk.org Wed Nov 6 17:53:00 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:53:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <4EGJTS9LsdYLK3ecIsExhUZaQupaES8wASP95dS88Cc=.3646b0fe-6e6c-4884-b37f-08360f8e144b@github.com> On Mon, 4 Nov 2024 07:59:22 GMT, Alan Bateman wrote: >> src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62: >> >>> 60: NATIVE(2, "Native frame or on stack"), >>> 61: MONITOR(3, "Monitor held"), >>> 62: CRITICAL_SECTION(4, "In critical section"); >> >> Is there a reason that the `reasonCode` values does not match the `freeze_result` reason values used in `pinnedReason(int reason)` to create one of these? >> >> I cannot see that it is used either. Only seem to be read for JFR VirtualThreadPinned Event which only uses the string. > > That's a good question as they should match. Not noticed as it's not currently used. As it happens, this has been reverted in the loom repo as part of improving this code and fixing another issue. > > Related is the freeze_result enum has new members, e.g. freeze_unsupported for LM_LEGACY, that don't have a mapping to a Pinned, need to check if we could trip over that. These have been updated with the latest JFR changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831465256 From duke at openjdk.org Wed Nov 6 17:56:08 2024 From: duke at openjdk.org (hanklo6) Date: Wed, 6 Nov 2024 17:56:08 GMT Subject: RFR: 8343317: Extend test generation tool to handle APX NDD/NF flavor of instructions [v5] In-Reply-To: References: Message-ID: > Extend test generation tool and gtest (added as part of https://bugs.openjdk.org/browse/JDK-8339507) to handle Intel APX NDD/NF instructions. > > Intel Advanced Performance Extensions (APX) adds non destructive destination (NDD) and no flags (NF) flavor for the scalar instructions through EVEX encoding. For more information about APX, see https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html. hanklo6 has updated the pull request incrementally with one additional commit since the last revision: Align output in assembler test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21795/files - new: https://git.openjdk.org/jdk/pull/21795/files/082653c7..b8ef01db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21795&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21795&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21795.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21795/head:pull/21795 PR: https://git.openjdk.org/jdk/pull/21795 From mgronlun at openjdk.org Wed Nov 6 18:28:41 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 6 Nov 2024 18:28:41 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4] In-Reply-To: References: Message-ID: <1Munu7jgeQRy5YxkvJ25qYM3AN0DcmmoveJqk4sjkSw=.cc0c71f0-8f0b-4025-8192-e7ebb59367c6@github.com> On Thu, 31 Oct 2024 16:09:37 GMT, Markus Gr?nlund wrote: >> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove min_valid_free_size_bytes > > linux-aarch64-debug > > --------------- T H R E A D --------------- > > Current thread (0x0000ffffac4222b0): JavaThread "JFR Recorder Thread" daemon [_thread_in_vm, id=144094, stack(0x0000ffff5e17a000,0x0000ffff5e378000) (2040K)] > > Stack: [0x0000ffff5e17a000,0x0000ffff5e378000], sp=0x0000ffff5e376110, free space=2032k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0xe19e54] get_cld(Klass const*)+0x34 (klass.hpp:684) > V [libjvm.so+0xe1c674] write_klass(JfrCheckpointWriter*, Klass const*, bool, int&)+0x70 (jfrTypeSet.cpp:370) > V [libjvm.so+0xe22d40] JfrArtifactCallbackHost, &(write__klass__leakp(JfrCheckpointWriter*, void const*))>, 183u>, JfrTypeWriterHost, &(write__klass(JfrCheckpointWriter*, void const*))>, 183u> >, KlassArtifactRegistrator> >::do_artifact(void const*)+0x90 (jfrTypeSet.cpp:398) > V [libjvm.so+0xe14fe0] EpochDispatchOp::ElementDispatch >::dispatch(bool, unsigned char const*, unsigned long)+0xd0 (jfrTraceIdKlassQueue.hpp:42) > V [libjvm.so+0xe15328] void JfrEpochQueue::iterate(KlassFunctor&, bool)+0xd8 (jfrStorageUtils.inline.hpp:160) > V [libjvm.so+0xe13ad0] JfrTraceIdKlassQueue::iterate(void (*)(Klass*), bool)+0x40 (jfrTraceIdKlassQueue.cpp:269) > V [libjvm.so+0xe21358] JfrTypeSet::serialize(JfrCheckpointWriter*, JfrCheckpointWriter*, bool, bool)+0x1c4 (jfrTypeSet.cpp:565) > V [libjvm.so+0xd6baf4] JfrCheckpointManager::write_type_set()+0x1a0 (jfrCheckpointManager.cpp:617) > V [libjvm.so+0xddfa54] JfrRecorderService::post_safepoint_write()+0xb0 (jfrRecorderService.cpp:613) > V [libjvm.so+0xde0bdc] JfrRecorderService::chunk_rotation()+0x3c (jfrRecorderService.cpp:573) > V [libjvm.so+0xde2104] JfrRecorderService::rotate(int)+0x100 (jfrRecorderService.cpp:539) > V [libjvm.so+0xde332c] recorderthread_entry(JavaThread*, JavaThread*)+0x2ac (jfrRecorderThreadLoop.cpp:81) > V [libjvm.so+0xd50400] JavaThread::thread_main_inner()+0xcc (javaThread.cpp:759) > V [libjvm.so+0x15e59e0] Thread::call_run()+0xac (thread.cpp:234) > V [libjvm.so+0x131fae4] thread_native_entry(Thread*)+0x130 (os_linux.cpp:858) > C [libc.so.6+0x806b8] start_thread+0x2d8 > @mgronlun class unloading related issues should be fixed. Could you please test it again? java.util.IllegalFormatConversionException: d != java.lang.Double at java.base/java.util.Formatter$FormatSpecifier.failConversion(Formatter.java:4702) at java.base/java.util.Formatter$FormatSpecifier.printInteger(Formatter.java:3240) at java.base/java.util.Formatter$FormatSpecifier.print(Formatter.java:3195) at java.base/java.util.Formatter.format(Formatter.java:2801) at java.base/java.util.Formatter.format(Formatter.java:2738) at java.base/java.lang.String.format(String.java:4481) at jdk.jfr/jdk.jfr.internal.util.TimespanRate.toString(TimespanRate.java:62) at jdk.jfr/jdk.jfr.internal.settings.CPUThrottleSetting.combine(CPUThrottleSetting.java:71) at jdk.jfr/jdk.jfr.internal.Control.combine(Control.java:138) at jdk.jfr/jdk.jfr.internal.Control.findCombine(Control.java:163) at jdk.jfr/jdk.jfr.internal.Control.apply(Control.java:67) at jdk.jfr/jdk.jfr.internal.SettingsManager.setEventControl(SettingsManager.java:230) at jdk.jfr/jdk.jfr.internal.SettingsManager.setSettings(SettingsManager.java:148) at jdk.jfr/jdk.jfr.internal.MetadataRepository.setSettings(MetadataRepository.java:243) at jdk.jfr/jdk.jfr.internal.PlatformRecorder.updateSettingsButIgnoreRecording(PlatformRecorder.java:393) at jdk.jfr/jdk.jfr.internal.PlatformRecorder.updateSettings(PlatformRecorder.java:382) at jdk.jfr/jdk.jfr.internal.PlatformRecorder.start(PlatformRecorder.java:272) at jdk.jfr/jdk.jfr.internal.PlatformRecording.start(PlatformRecording.java:127) at jdk.jfr/jdk.jfr.Recording.start(Recording.java:177) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2460487291 From mgronlun at openjdk.org Wed Nov 6 19:01:44 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 6 Nov 2024 19:01:44 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v10] In-Reply-To: <9svUVUB63cGcP3iHZfLUa45qfJnyA-WY9zd1S2NDU3M=.eaa2518b-a6cc-4f82-a309-e23d1da0c289@github.com> References: <9svUVUB63cGcP3iHZfLUa45qfJnyA-WY9zd1S2NDU3M=.eaa2518b-a6cc-4f82-a309-e23d1da0c289@github.com> Message-ID: On Wed, 6 Nov 2024 10:57:59 GMT, Johannes Bechberger wrote: >> This is the code for the [JEP draft: CPU Time based profiling for JFR]. > > Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision: > > - Only do timer init and removal at global safepoint > - Only do timer init and removal at global safepoint src/hotspot/share/jfr/recorder/storage/jfrMemorySpaceRetrieval.hpp line 88: > 86: if (node == nullptr) return nullptr; > 87: assert(node->free_size() >= size, "invariant"); > 88: assert(node->identity() == nullptr, "invariant"); This is not the right way to do it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1831561202 From pchilanomate at openjdk.org Wed Nov 6 19:40:47 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 19:40:47 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <79vVMnHrSZ9MEDcn0UzBYaPJKz63XZ3a7Qn4N0i-pa8=.adbe56c4-4a73-4015-b364-0196f1a4a75a@github.com> On Mon, 28 Oct 2024 00:29:25 GMT, David Holmes wrote: >> I was wondering what this was too but the _previous_owner_tid is the os thread id, not the Java thread id. >> >> >> $ grep -r JFR_THREAD_ID >> jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) (JfrThreadLocal::external_thread_id(thread)) >> jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) ((traceid)(thread)->osthread()->thread_id()) >> runtime/objectMonitor.cpp: _previous_owner_tid = JFR_THREAD_ID(current); >> runtime/objectMonitor.cpp: iterator->_notifier_tid = JFR_THREAD_ID(current); >> runtime/vmThread.cpp: event->set_caller(JFR_THREAD_ID(op->calling_thread())); > > Then it looks like the JFR code needs updating as well, otherwise it is going to be reporting inconsistent information when virtual threads are locking monitors. So we use the os thread id when INCLUDE_JFR is not defined, but in that case we never actually post JFR events. So these _previous_owner_tid/_notifier_tid will be unused. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831592617 From pchilanomate at openjdk.org Wed Nov 6 19:40:46 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 19:40:46 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 29 Oct 2024 02:09:24 GMT, Dean Long wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/x86/c1_Runtime1_x86.cpp line 223: > >> 221: } >> 222: >> 223: void StubAssembler::epilogue(bool use_pop) { > > Is there a better name we could use, like `trust_fp` or `after_resume`? I think `trust_fp` would be confusing because at this point rfp will have an invalid value and we don't want to use it to restore sp, i.e. we should not trust fp. And `after_resume` wouldn't always apply since we don't always preempt. The `use_pop` name was copied form x64, but I think it's still fine here. We also have the comment right below this line which explains why we don't want to use `leave()` and instead pop the top words from the stack. > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 324: > >> 322: movq(scrReg, tmpReg); >> 323: xorq(tmpReg, tmpReg); >> 324: movptr(boxReg, Address(r15_thread, JavaThread::lock_id_offset())); > > I don't know if it helps to schedule this load earlier (it is used in the next instruction), but it probably won't hurt. I moved it before `movq(scrReg, tmpReg)` since we need `boxReg` above, but I don't think this will change anything. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1659: > >> 1657: int i = 0; >> 1658: for (frame f = freeze_start_frame(); Continuation::is_frame_in_continuation(ce, f); f = f.sender(&map), i++) { >> 1659: if (!((f.is_compiled_frame() && !f.is_deoptimized_frame()) || (i == 0 && (f.is_runtime_frame() || f.is_native_frame())))) { > > OK, `i == 0` just means first frame here, so you could use a bool instead of an int, or even check for f == freeze_start_frame(), right? Changed to use boolean `is_top_frame`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831594384 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831597325 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831599268 From pchilanomate at openjdk.org Wed Nov 6 19:40:48 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 19:40:48 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Sat, 26 Oct 2024 05:39:32 GMT, Alan Bateman wrote: >> test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java line 30: >> >>> 28: * by reflection API >>> 29: * @library /test/lib/ >>> 30: * @requires vm.compMode != "Xcomp" >> >> If there is a problem with this test running with -Xcomp and virtual threads, maybe it should be handled as a separate bug fix. > > JBS has several issues related to ReflectionCallerCacheTest.java and -Xcomp, going back several releases. It seems some nmethod is keeping objects alive and is preventing class unloading in this test. The refactoring of j.l.ref in JDK 19 to workaround pinning issues made it go away. There is some minimal revert in this PR to deal with the potential for preemption when polling a reference queue and it seems the changes to this Java code have brought back the issue. So it's excluded from -Xcomp again. Maybe it would be better to add it to ProblemList-Xcomp.txt instead? That would allow it to link to one of the JSB issue on this issue. I added the test to `test/jdk/ProblemList-Xcomp.txt` instead with a reference to 8332028. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831604339 From dholmes at openjdk.org Wed Nov 6 20:13:55 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 20:13:55 GMT Subject: RFR: 8343726: [BACKOUT] NMT should not use ThreadCritical In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 16:39:15 GMT, Johan Sj?len wrote: > Hi, > > We've unfortunately seen a few bugs and crashes related to this PR, so let's back it out. > > Thanks. Backout looks accurate. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21937#pullrequestreview-2419328563 From jbechberger at openjdk.org Wed Nov 6 20:52:57 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 20:52:57 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v10] In-Reply-To: References: <9svUVUB63cGcP3iHZfLUa45qfJnyA-WY9zd1S2NDU3M=.eaa2518b-a6cc-4f82-a309-e23d1da0c289@github.com> Message-ID: <8IgbomysipN9ibrSbHFoqiuuD6RdUS5y-upc2bganss=.dfc5dc19-5de5-4ae1-af3f-b60e227a143b@github.com> On Wed, 6 Nov 2024 18:58:44 GMT, Markus Gr?nlund wrote: >> Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision: >> >> - Only do timer init and removal at global safepoint >> - Only do timer init and removal at global safepoint > > src/hotspot/share/jfr/recorder/storage/jfrMemorySpaceRetrieval.hpp line 88: > >> 86: if (node == nullptr) return nullptr; >> 87: assert(node->free_size() >= size, "invariant"); >> 88: assert(node->identity() == nullptr, "invariant"); > > This is not the right way to do it. Good catch, I removed it during debugging. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1831691709 From jbechberger at openjdk.org Wed Nov 6 21:01:43 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 21:01:43 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v14] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Fix TimespanRate#toString and readd assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/7c61bc68..0a4454cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=12-13 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From jbechberger at openjdk.org Wed Nov 6 21:01:43 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 6 Nov 2024 21:01:43 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4] In-Reply-To: <1Munu7jgeQRy5YxkvJ25qYM3AN0DcmmoveJqk4sjkSw=.cc0c71f0-8f0b-4025-8192-e7ebb59367c6@github.com> References: <1Munu7jgeQRy5YxkvJ25qYM3AN0DcmmoveJqk4sjkSw=.cc0c71f0-8f0b-4025-8192-e7ebb59367c6@github.com> Message-ID: <2sF2us9QkTpthxYzn0xk7Cmm9t_MKft-sKiiIJRrlYE=.0521dc7f-1907-40a6-bd9e-b62b7bede908@github.com> On Wed, 6 Nov 2024 18:26:18 GMT, Markus Gr?nlund wrote: > java.util.IllegalFormatConversionException: d != java.lang.Double It's fixed, It's interesting that my tests didn't catch it... ------------- PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2460762446 From sviswanathan at openjdk.org Wed Nov 6 21:13:44 2024 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Wed, 6 Nov 2024 21:13:44 GMT Subject: RFR: 8343317: Extend test generation tool to handle APX NDD/NF flavor of instructions [v5] In-Reply-To: References: Message-ID: <-B5zN2IfNqO7qs0M0VRTeP4NhZLNs_c5bXNyweHn0Cc=.9e0c4bd5-5a8c-47b8-a800-c70f66354d13@github.com> On Wed, 6 Nov 2024 17:56:08 GMT, hanklo6 wrote: >> Extend test generation tool and gtest (added as part of https://bugs.openjdk.org/browse/JDK-8339507) to handle Intel APX NDD/NF instructions. >> >> Intel Advanced Performance Extensions (APX) adds non destructive destination (NDD) and no flags (NF) flavor for the scalar instructions through EVEX encoding. For more information about APX, see https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html. > > hanklo6 has updated the pull request incrementally with one additional commit since the last revision: > > Align output in assembler test Looks good to me. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21795#pullrequestreview-2419426270 From kbarrett at openjdk.org Wed Nov 6 21:27:59 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 6 Nov 2024 21:27:59 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 6 Nov 2024 15:21:10 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Remove FIXME Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2419454529 From kbarrett at openjdk.org Wed Nov 6 21:28:00 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 6 Nov 2024 21:28:00 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: <_8hqosvrOekf3ephURXyuAKg9hl2FRpH-tJ-y_PFE6k=.f5ab5105-b4d3-4e5a-ae7d-705838274dc1@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <_8hqosvrOekf3ephURXyuAKg9hl2FRpH-tJ-y_PFE6k=.f5ab5105-b4d3-4e5a-ae7d-705838274dc1@github.com> Message-ID: On Wed, 6 Nov 2024 15:27:16 GMT, Magnus Ihse Bursie wrote: >> src/java.base/share/native/libjava/NativeLibraries.c line 67: >> >>> 65: strcat(jniEntryName, "_"); >>> 66: strcat(jniEntryName, cname); >>> 67: } >> >> I would prefer this be directly inlined at the sole call (in findJniFunction), >> to make it easier to verify there aren't any buffer overrun problems. (I don't >> think there are, but looking at this in isolation triggered warnings in my >> head.) >> >> Also, it looks like all callers of findJniFunction ensure the cname argument >> is non-null. So there should be no need to handle the null case in >> findJniFunction (other than perhaps an assert or something). That could be >> addressed in a followup. (I've already implicitly suggested elsewhere in this >> PR revising this function in a followup because of the JNI_ON[UN]LOAD_SYMBOLS >> thing.) > > @kimbarrett I added this to https://bugs.openjdk.org/browse/JDK-8343703. You are not as explicit here as the other places you commented that it is okay to do as a follow-up, but I'll assume that was what you meant. If not, let me know, and I'll look at fixing it for this PR already. The first part, eliminating the (IMO not actually helpful) helper function, I wanted done here. The second part, cleaning up or commenting the calculation of the length and dealing with perhaps unneeded conditionals, I'm okay with being in a followup. I guess I can live with the first part being in that followup too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1831728737 From sparasa at openjdk.org Wed Nov 6 23:33:43 2024 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Wed, 6 Nov 2024 23:33:43 GMT Subject: RFR: 8343317: Extend test generation tool to handle APX NDD/NF flavor of instructions [v5] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 17:56:08 GMT, hanklo6 wrote: >> Extend test generation tool and gtest (added as part of https://bugs.openjdk.org/browse/JDK-8339507) to handle Intel APX NDD/NF instructions. >> >> Intel Advanced Performance Extensions (APX) adds non destructive destination (NDD) and no flags (NF) flavor for the scalar instructions through EVEX encoding. For more information about APX, see https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html. > > hanklo6 has updated the pull request incrementally with one additional commit since the last revision: > > Align output in assembler test This PR looks good to me. Also, I Independently tested that this tool works (i.e. all the tests are passing) after pulling in the APX encoding bugfix (https://github.com/openjdk/jdk/pull/21770) changes recently integrated into OpenJDK. Thanks, Srinivas Vamsi Parasa (from Intel) ------------- Marked as reviewed by sparasa (Author). PR Review: https://git.openjdk.org/jdk/pull/21795#pullrequestreview-2419646377 From sviswanathan at openjdk.org Thu Nov 7 00:33:46 2024 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Thu, 7 Nov 2024 00:33:46 GMT Subject: RFR: 8343317: Extend test generation tool to handle APX NDD/NF flavor of instructions [v5] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 17:56:08 GMT, hanklo6 wrote: >> Extend test generation tool and gtest (added as part of https://bugs.openjdk.org/browse/JDK-8339507) to handle Intel APX NDD/NF instructions. >> >> Intel Advanced Performance Extensions (APX) adds non destructive destination (NDD) and no flags (NF) flavor for the scalar instructions through EVEX encoding. For more information about APX, see https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html. > > hanklo6 has updated the pull request incrementally with one additional commit since the last revision: > > Align output in assembler test @vnkozlov Could you please run this PR through your testing? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21795#issuecomment-2461079711 From pchilanomate at openjdk.org Thu Nov 7 00:38:18 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 7 Nov 2024 00:38:18 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: References: Message-ID: <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com> > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21565/files - new: https://git.openjdk.org/jdk/pull/21565/files/211c6c81..37e30171 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=00-01 Stats: 108 lines in 7 files changed: 65 ins; 33 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From pchilanomate at openjdk.org Thu Nov 7 00:43:07 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 7 Nov 2024 00:43:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 16:31:24 GMT, Serguei Spitsyn wrote: >> Regarding the pop_frame/early_ret/async_exception conditions, not checking for them after we started the transition would be an issue. >> For pop_frame/early_ret checks, the problem is that if any of them are installed in `JvmtiUnmountBeginMark()` while trying to start the transition, and later the call to freeze succeeds, when returning to the interpreter (monitorenter case) we will incorrectly follow the JVMTI code [1], instead of going back to `call_VM_preemptable` to clear the stack from the copied frames. As for the asynchronous exception check, if it gets installed in `JvmtiUnmountBeginMark()` while trying to start the transition, the exception would be thrown in the carrier instead, very likely while executing the unmounting logic. >> When unmounting from Java, although the race is also there when starting the VTMS transition as you mentioned, I think the end result will be different. For pop_frame/early_ret we will just bail out if trying to install them since the top frame will be a native method (`notifyJvmtiUnmount`). For the async exception, we would process it on return from `notifyJvmtiUnmount` which would still be done in the context of the vthread. >> >> [1] https://github.com/openjdk/jdk/blob/471f112bca715d04304cbe35c6ed63df8c7b7fee/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1629 > > Thank you for the comment! I'm okay with your modified suggestion in general if there are no road blocks. > >> but does the specs say the event has to be posted in the context of the vthread? > > As Alan said below we do not have an official spec for this but still the events need to be posted in vthread context. > >> For pop_frame/early_ret checks ... > > The pop_frame/early_ret conditions are installed in handshakes with a context of `JvmtiVTMSTransitionDisabler`. As you noted the `JVMTI_ERROR_OPAQUE_FRAME` might be also returned by the JVMTI `FramePop` and `ForceEarlyReturn*` for some specific cases. So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help. > >> Maybe we could go with this simplified code now and work on it later... > > Whatever works better for you. An alternate approach could be to file an enhancement to simplify/refactor this. > It would be nice to fix a couple of nits though: > - the call to `java_lang_Thread::set_is_in_VTMS_transition()`is not needed in `JvmtiUnmountBeginMark` > - the function `is_vthread_safe_to_preempt()` does not need the `vthread` parameter Great, I applied the suggested simplification. I had to update test `VThreadEventTest.java` to check the stack during the mount/unmount events to only count the real cases. This is because now we are getting a variable number of spurious mount/unmount events (freeze failed) generated during the initialization of some class (`VirtualThreadEndEvent`) after the task is finished. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831898126 From pchilanomate at openjdk.org Thu Nov 7 00:43:07 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 7 Nov 2024 00:43:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 00:37:53 GMT, Patricio Chilano Mateo wrote: >> Great, I applied the suggested simplification. I had to update test `VThreadEventTest.java` to check the stack during the mount/unmount events to only count the real cases. This is because now we are getting a variable number of spurious mount/unmount events (freeze failed) generated during the initialization of some class (`VirtualThreadEndEvent`) after the task is finished. > >> So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help. >> > The problem here is that for monitorenter the top frame will not be a native method, so the bail out will not happen as it would when unmounting from Java. > the call to java_lang_Thread::set_is_in_VTMS_transition()is not needed in JvmtiUnmountBeginMark > Why is not needed? I guess you meant to say we should use `JvmtiVTMSTransitionDisabler::set_is_in_VTMS_transition()` which does both? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831898891 From pchilanomate at openjdk.org Thu Nov 7 00:43:08 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 7 Nov 2024 00:43:08 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 00:38:40 GMT, Patricio Chilano Mateo wrote: >>> So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help. >>> >> The problem here is that for monitorenter the top frame will not be a native method, so the bail out will not happen as it would when unmounting from Java. > >> the call to java_lang_Thread::set_is_in_VTMS_transition()is not needed in JvmtiUnmountBeginMark >> > Why is not needed? I guess you meant to say we should use `JvmtiVTMSTransitionDisabler::set_is_in_VTMS_transition()` which does both? > the function is_vthread_safe_to_preempt() does not need the vthread parameter > Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831899049 From pchilanomate at openjdk.org Thu Nov 7 00:43:07 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 7 Nov 2024 00:43:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 00:37:17 GMT, Patricio Chilano Mateo wrote: >> Thank you for the comment! I'm okay with your modified suggestion in general if there are no road blocks. >> >>> but does the specs say the event has to be posted in the context of the vthread? >> >> As Alan said below we do not have an official spec for this but still the events need to be posted in vthread context. >> >>> For pop_frame/early_ret checks ... >> >> The pop_frame/early_ret conditions are installed in handshakes with a context of `JvmtiVTMSTransitionDisabler`. As you noted the `JVMTI_ERROR_OPAQUE_FRAME` might be also returned by the JVMTI `FramePop` and `ForceEarlyReturn*` for some specific cases. So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help. >> >>> Maybe we could go with this simplified code now and work on it later... >> >> Whatever works better for you. An alternate approach could be to file an enhancement to simplify/refactor this. >> It would be nice to fix a couple of nits though: >> - the call to `java_lang_Thread::set_is_in_VTMS_transition()`is not needed in `JvmtiUnmountBeginMark` >> - the function `is_vthread_safe_to_preempt()` does not need the `vthread` parameter > > Great, I applied the suggested simplification. I had to update test `VThreadEventTest.java` to check the stack during the mount/unmount events to only count the real cases. This is because now we are getting a variable number of spurious mount/unmount events (freeze failed) generated during the initialization of some class (`VirtualThreadEndEvent`) after the task is finished. > So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help. > The problem here is that for monitorenter the top frame will not be a native method, so the bail out will not happen as it would when unmounting from Java. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831898439 From pchilanomate at openjdk.org Thu Nov 7 00:43:08 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 7 Nov 2024 00:43:08 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: References: Message-ID: <5ZFkpNRHw-d5qP3ggPI41D6Z5Em7HyjLy-0kt3JX_u8=.7ffe4080-8792-43ba-a67b-b43098417019@github.com> On Wed, 6 Nov 2024 15:57:55 GMT, Serguei Spitsyn wrote: > The two extension events were designed to be posted when the current thread identity is virtual, so this behavior > needs to be considered as a bug. My understanding is that it is not easy to fix. > If we want to post the mount/unmount events here is actually simple if we also use `JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount`. I included it in the last commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831899882 From aboldtch at openjdk.org Thu Nov 7 06:30:47 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 7 Nov 2024 06:30:47 GMT Subject: RFR: 8340586: JdkJfrEvent::get_all_klasses stores non-strong oops in JNI handles [v3] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 15:20:47 GMT, Axel Boldt-Christmas wrote: >> JdkJfrEvent::get_all_klasses walks the class hierarchy of the Event class to find all event sub klasses. The mirrors of these classes are then stored in JNI handles and eventually transfered to an arraylist which is returned to the java caller. >> >> Because the klasses are found by walking the class hierarchy, their is no guarantee that the klass is strongly reachable, and thus that the java_mirror load is strong. So we must explicitly keep the klass alive (and not have a safepoint between the load and the store into the object graph). >> >> Having both `fill_klasses` and `transform_klasses_to_local_jni_handles` made the call to `keep_alive` and the comment explaining the reason why somewhat obscured, so I merged them. (The split seems to have served no purpose except to introduce the need for a lot of const and reinterpret casts.) > > Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision: > > - Add Klass::java_mirror() comment. > - Fix comment Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21893#issuecomment-2461426005 From aboldtch at openjdk.org Thu Nov 7 06:30:48 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 7 Nov 2024 06:30:48 GMT Subject: Integrated: 8340586: JdkJfrEvent::get_all_klasses stores non-strong oops in JNI handles In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 06:34:02 GMT, Axel Boldt-Christmas wrote: > JdkJfrEvent::get_all_klasses walks the class hierarchy of the Event class to find all event sub klasses. The mirrors of these classes are then stored in JNI handles and eventually transfered to an arraylist which is returned to the java caller. > > Because the klasses are found by walking the class hierarchy, their is no guarantee that the klass is strongly reachable, and thus that the java_mirror load is strong. So we must explicitly keep the klass alive (and not have a safepoint between the load and the store into the object graph). > > Having both `fill_klasses` and `transform_klasses_to_local_jni_handles` made the call to `keep_alive` and the comment explaining the reason why somewhat obscured, so I merged them. (The split seems to have served no purpose except to introduce the need for a lot of const and reinterpret casts.) This pull request has now been integrated. Changeset: 97b681e9 Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/97b681e93a9469d8d16122dc10bbf2f5b5fe2266 Stats: 34 lines in 3 files changed: 17 ins; 13 del; 4 mod 8340586: JdkJfrEvent::get_all_klasses stores non-strong oops in JNI handles Reviewed-by: coleenp, stefank, mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/21893 From duke at openjdk.org Thu Nov 7 07:33:45 2024 From: duke at openjdk.org (duke) Date: Thu, 7 Nov 2024 07:33:45 GMT Subject: RFR: 8343452: Incorrect WINDOWS build variable is used in macroAssembler_x86.cpp In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 12:21:58 GMT, theoweidmannoracle wrote: > From JBS: > >> HotSpot VM build macro defines _WINDOWS env variable only. >> call_clobbered_gp_registers() and call_clobbered_xmm_registers() incorrectly use WINDOWS (without underscore). >> RSI and RDI are missing from list of clobbered register on windows due to that and may cause issue when calling native code which modifies them. >> >> AMM register are less affected because all XMM registers are listed as clobbered. >> >> The code was added by [JDK-8283327](https://bugs.openjdk.org/browse/JDK-8283327) changes in JDK 19. @theoweidmannoracle Your change (at version 93a01ee4af11aa27c49c999b6de8a1a4592241a6) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21901#issuecomment-2461509537 From duke at openjdk.org Thu Nov 7 07:50:49 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Thu, 7 Nov 2024 07:50:49 GMT Subject: Integrated: 8343452: Incorrect WINDOWS build variable is used in macroAssembler_x86.cpp In-Reply-To: References: Message-ID: <6m71AKSxSCUozdmhUEJ2R_3u3Oi7peaLqZLPGRYy-UI=.60f40baa-05ba-4059-b1e9-9efda119e5de@github.com> On Tue, 5 Nov 2024 12:21:58 GMT, theoweidmannoracle wrote: > From JBS: > >> HotSpot VM build macro defines _WINDOWS env variable only. >> call_clobbered_gp_registers() and call_clobbered_xmm_registers() incorrectly use WINDOWS (without underscore). >> RSI and RDI are missing from list of clobbered register on windows due to that and may cause issue when calling native code which modifies them. >> >> AMM register are less affected because all XMM registers are listed as clobbered. >> >> The code was added by [JDK-8283327](https://bugs.openjdk.org/browse/JDK-8283327) changes in JDK 19. This pull request has now been integrated. Changeset: 0e1c1b79 Author: theoweidmannoracle Committer: Christian Hagedorn URL: https://git.openjdk.org/jdk/commit/0e1c1b793d43064aabe9571057284899c9580f30 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8343452: Incorrect WINDOWS build variable is used in macroAssembler_x86.cpp Reviewed-by: kvn, chagedorn, jwaters ------------- PR: https://git.openjdk.org/jdk/pull/21901 From jsjolen at openjdk.org Thu Nov 7 08:19:59 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 7 Nov 2024 08:19:59 GMT Subject: RFR: 8343726: [BACKOUT] NMT should not use ThreadCritical In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 16:39:15 GMT, Johan Sj?len wrote: > Hi, > > We've unfortunately seen a few bugs and crashes related to this PR, so let's back it out. > > Thanks. Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/21937#issuecomment-2461586062 From jsjolen at openjdk.org Thu Nov 7 08:19:59 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 7 Nov 2024 08:19:59 GMT Subject: Integrated: 8343726: [BACKOUT] NMT should not use ThreadCritical In-Reply-To: References: Message-ID: <8bPakAokDuJqAR6hWn3nql8ofSTfwAVVFiFomR-b3Kg=.def8b36a-eca7-4268-a672-d10443c4cab0@github.com> On Wed, 6 Nov 2024 16:39:15 GMT, Johan Sj?len wrote: > Hi, > > We've unfortunately seen a few bugs and crashes related to this PR, so let's back it out. > > Thanks. This pull request has now been integrated. Changeset: c3df050b Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/c3df050b88ecef123199a4e96f6d9884d064ae45 Stats: 62 lines in 15 files changed: 21 ins; 19 del; 22 mod 8343726: [BACKOUT] NMT should not use ThreadCritical Reviewed-by: shade, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/21937 From duke at openjdk.org Thu Nov 7 08:32:16 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Thu, 7 Nov 2024 08:32:16 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v3] In-Reply-To: References: Message-ID: > - Changed several "NULL" in comments to "null" > - Changed several `NULL` in code to `nullptr` theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: Fix backslides in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21826/files - new: https://git.openjdk.org/jdk/pull/21826/files/9754145b..e79b7bde Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21826&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21826&range=01-02 Stats: 10 lines in 2 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/21826.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21826/head:pull/21826 PR: https://git.openjdk.org/jdk/pull/21826 From duke at openjdk.org Thu Nov 7 08:32:16 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Thu, 7 Nov 2024 08:32:16 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v2] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 16:02:07 GMT, Kim Barrett wrote: > Can you use the (updated) regex in the JBS issue description to verify the only remaining "NULL"s in src/hotspot are the jvmti.{xml,xls} files and the globalDefinitions_{gcc,visCPP}.hpp files? > > There are also some NULLs recently introduced in test/hotspot: ./jtreg/serviceability/jvmti/GetMethodDeclaringClass/libTestUnloadedClass.cpp ./jtreg/serviceability/jvmti/vthread/VThreadEventTest/libVThreadEventTest.cpp > > (Found by applying the same regex to test/hotspot, and then removing .java and .c files.) > > There are a few other files in test/hotspot containing NULLs: ./jtreg/vmTestbase/nsk/share/jni/README ./jtreg/vmTestbase/nsk/share/jvmti/README These are documentation files with examples written in C, so should not be changed. > > ./jtreg/vmTestbase/nsk/share/native/nsk_tools.hpp In a comment describing a string to be used for printing. Uses would need to be examined to ensure it's okay to change the string used for a null value. I think I planned to do this as a followup to JDK-8324799, and then forgot. I'd be okay with doing something about this being separate from the current PR. While the necessary textual changes are probably small, there's a lot of uses to examine to be sure a change is okay. @kimbarrett I fixed the backslides in the *.cpp files you mentioned. The egrep outputs are now: % find test/hotspot -type f ! -name "*.c" ! -name "*.java" -exec egrep -H "[^[:alnum:]_]NULL([^[:alnum:]_]|$)" {} ; test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.hpp: * Returns str or "" if str is null; useful for printing strings. test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/README: if (!NSK_JVMTI_VERIFY(jvmti->GetVersion(&version) != NULL)) { test/hotspot/jtreg/vmTestbase/nsk/share/jni/README: jni->FindClass(class_name) != NULL)) { test/hotspot/jtreg/vmTestbase/nsk/share/jni/README: jni->FindClass(class_name)) != NULL)) { and egrep -R "[^[:alnum:]_]NULL([^[:alnum:]_]|$)" src/hotspot src/hotspot/share/prims/jvmti.xml: or return value. A "null pointer" is C NULL or C++ nullptr. src/hotspot/share/prims/jvmti.xml: &methodName, NULL, NULL); src/hotspot/share/prims/jvmti.xml: GetThreadCpuTime(env, NULL, nanos_ptr) src/hotspot/share/prims/jvmti.xsl: , NULL) src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:// When __cplusplus is defined, NULL is defined as 0 (32-bit constant) in src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:// On 64-bit architectures, defining NULL as a 32-bit constant can cause src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:// varargs, we pass the argument 0 as an int. So, if NULL was passed to a src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:// only 32-bits of the "NULL" pointer may be initialized to zero. The src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:// Solution: For 64-bit architectures, redefine NULL as 64-bit constant 0. src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:#undef NULL src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:#define NULL 0LL src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:#ifndef NULL src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:#define NULL 0 src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:// NULL vs NULL_WORD: src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:// On Linux NULL is defined as a special type '__null'. Assigning __null to src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:#define NULL_WORD NULL src/hotspot/share/utilities/globalDefinitions_gcc.hpp:// NULL vs NULL_WORD: src/hotspot/share/utilities/globalDefinitions_gcc.hpp:// On Linux NULL is defined as a special type '__null'. Assigning __null to src/hotspot/share/utilities/globalDefinitions_gcc.hpp: #define NULL_WORD NULL ------------- PR Comment: https://git.openjdk.org/jdk/pull/21826#issuecomment-2461610347 From amitkumar at openjdk.org Thu Nov 7 08:47:14 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 7 Nov 2024 08:47:14 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: References: Message-ID: <8WsQTNy83zv4Z7kD6SPo60kURL1EFe3ZMbD4QCqo3II=.3895ed74-7940-436a-aff2-f7aeafbef2b3@github.com> On Wed, 6 Nov 2024 17:38:59 GMT, Patricio Chilano Mateo wrote: >> Good work! I'll approve the GC related changes. >> >> There are some simplifications I think can be done in the ObjectMonitor layer, but nothing that should go into this PR. >> >> Similarly, (even if some of this is preexisting issues) I think that the way we describe the frames and the different frame transitions should be overhauled and made easier to understand. There are so many unnamed constants and adjustments which are spread out everywhere, which makes it hard to get an overview of exactly what happens and what interactions are related to what. You and Dean did a good job at simplifying and adding comments in this PR. But I hope this can be improved in the fututre. >> >> A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this. >> >> // the sp of the oldest known interpreted/call_stub frame inside the >> // continuation that we know about > >> A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this. >> >> ``` >> // the sp of the oldest known interpreted/call_stub frame inside the >> // continuation that we know about >> ``` >> > Updated comment. @pchilano `CancelTimerWithContention.java` test is failing on s390x with Timeout Error. One weird thing is that it only fails when I run whole tier1 test suite. But when ran independently test passes. One thing I would like to mention is that I ran test by **disabling** VMContinuations, as Vthreads are not yet supported by s390x. [CancelTimerWithContention.log](https://github.com/user-attachments/files/17658594/CancelTimerWithContention.log) ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2461640546 From alanb at openjdk.org Thu Nov 7 09:43:11 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 7 Nov 2024 09:43:11 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: References: Message-ID: <04lJ9Fw4vDQWjvQkCuYmVoaMN3t7Gq4pjg32puxcahQ=.3795a7ae-13d1-4cdb-b27d-db50ff53b59b@github.com> On Wed, 6 Nov 2024 17:38:59 GMT, Patricio Chilano Mateo wrote: >> Good work! I'll approve the GC related changes. >> >> There are some simplifications I think can be done in the ObjectMonitor layer, but nothing that should go into this PR. >> >> Similarly, (even if some of this is preexisting issues) I think that the way we describe the frames and the different frame transitions should be overhauled and made easier to understand. There are so many unnamed constants and adjustments which are spread out everywhere, which makes it hard to get an overview of exactly what happens and what interactions are related to what. You and Dean did a good job at simplifying and adding comments in this PR. But I hope this can be improved in the fututre. >> >> A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this. >> >> // the sp of the oldest known interpreted/call_stub frame inside the >> // continuation that we know about > >> A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this. >> >> ``` >> // the sp of the oldest known interpreted/call_stub frame inside the >> // continuation that we know about >> ``` >> > Updated comment. > @pchilano `CancelTimerWithContention.java` test is failing on s390x with Timeout Error. One weird thing is that it only fails when I run whole tier1 test suite. But when ran independently test passes. > > One thing I would like to mention is that I ran test by **disabling** VMContinuations, as Vthreads are not yet supported by s390x. We added this test to provoke contention on the delay queues, lots of timed-Object.wait with notification before the timeout is reached. This code is not used when running with -XX:+UnlockExperimentalVMOptions -XX:-VMContinuation. In that execution mode, each virtual thread is backed by a platform/native thread and in this test it will ramp up 10_000 virtual threads. The output in your log suggests it gets to ~4700 threads before the jtreg timeout kicks in. It might be that when you run the test on its own that there is enough resources for the test to pass, but not enough resources (just too slow) when competing with other tests. I think we can add `@requires vm.continuations` to this test. It's not useful to run with the alternative virtual thread implementation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2461756432 From amitkumar at openjdk.org Thu Nov 7 09:49:12 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 7 Nov 2024 09:49:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: <04lJ9Fw4vDQWjvQkCuYmVoaMN3t7Gq4pjg32puxcahQ=.3795a7ae-13d1-4cdb-b27d-db50ff53b59b@github.com> References: <04lJ9Fw4vDQWjvQkCuYmVoaMN3t7Gq4pjg32puxcahQ=.3795a7ae-13d1-4cdb-b27d-db50ff53b59b@github.com> Message-ID: <7trSDsagiP_ARB6Fi8hffBxAn1tYxAMRxV1sV-GL0qw=.4899e993-c276-48ca-a6a6-ea5e1e56ac55@github.com> On Thu, 7 Nov 2024 09:40:19 GMT, Alan Bateman wrote: >I think we can add @requires vm.continuations to this test. It's not useful to run with the alternative virtual thread implementation. Sure, that sounds ok. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2461768715 From duke at openjdk.org Thu Nov 7 10:14:03 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Thu, 7 Nov 2024 10:14:03 GMT Subject: RFR: 8341411: C2: remove slice parameter from GraphKit::make_load() and GraphKit::store_to_memory() [v2] In-Reply-To: References: Message-ID: <859Tes8E6YyPWVsevWKHIfTJ31v2L57U3FLXGtqn_Zk=.bba73b76-09a9-4d99-bfc7-310ce73a469e@github.com> On Wed, 6 Nov 2024 12:19:16 GMT, Roland Westrelin wrote: >> theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary store_to_memory param/overload > > src/hotspot/share/gc/shared/c2/barrierSetC2.cpp line 220: > >> 218: load = kit->gvn().transform(load); >> 219: } else { >> 220: load = kit->make_load(control, adr, val_type, access.type(), adr_type, mo, > > No similar change to `BarrierSetC2::store_at_resolved()`? I missed that. Fixed now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21834#discussion_r1832411316 From duke at openjdk.org Thu Nov 7 10:14:03 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Thu, 7 Nov 2024 10:14:03 GMT Subject: RFR: 8341411: C2: remove slice parameter from GraphKit::make_load() and GraphKit::store_to_memory() [v2] In-Reply-To: References: Message-ID: > This patch removes the address type from `GraphKit::make_load()` and `GraphKit::store_to_memory()` > > As https://github.com/openjdk/jdk/pull/21303 introduced asserts that check that the address type agrees with `C->get_alias_index(_gvn.type(adr)->isa_ptr()`, passing the address type is redundant and it can be computed internally from the address. theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary store_to_memory param/overload ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21834/files - new: https://git.openjdk.org/jdk/pull/21834/files/a595ddd9..f89f2cf4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21834&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21834&range=00-01 Stats: 25 lines in 5 files changed: 0 ins; 17 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/21834.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21834/head:pull/21834 PR: https://git.openjdk.org/jdk/pull/21834 From galder at openjdk.org Thu Nov 7 10:20:45 2024 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Thu, 7 Nov 2024 10:20:45 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) In-Reply-To: References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> Message-ID: On Thu, 11 Jul 2024 22:30:45 GMT, Vladimir Ivanov wrote: > Overall, looks fine. > > So, there will be `inline_min_max`, `inline_fp_min_max`, and `inline_long_min_max` which slightly vary. I'd prefer to see them unified. (Or, at least, enhance `inline_min_max` to cover `minL`/maxL` cases). > > Also, it's a bit confusing to see int variants names w/o basic type (`_min`/`_minL` vs `_minI`/`_minL`). Please, clean it up along the way. (FTR I'm also fine handling the renaming as a separate change.) @iwanowww I applied the changes you suggested. Could you review them? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2461843670 From shade at openjdk.org Thu Nov 7 12:12:01 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Nov 2024 12:12:01 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 6 Nov 2024 00:56:49 GMT, David Holmes wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> fix: jvm_md.h was included, but not jvm.h... > > src/hotspot/os/windows/os_windows.cpp line 510: > >> 508: // Thread start routine for all newly created threads. >> 509: // Called with the associated Thread* as the argument. >> 510: static unsigned thread_native_entry(void* t) { > > Whoa! Hold on there. The `_stdcall` is required here and nothing to do with 32-bit. We use `begindthreadex` to start threads and the entry function is required to be `_stdcall`. > https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170 Not sure why this comment was marked as "Resolved". I have the same question here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1832573434 From shade at openjdk.org Thu Nov 7 12:18:57 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Nov 2024 12:18:57 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> On Wed, 6 Nov 2024 15:21:10 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Remove FIXME I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO. ------------- PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2420814976 From jwaters at openjdk.org Thu Nov 7 12:18:58 2024 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 7 Nov 2024 12:18:58 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Thu, 7 Nov 2024 12:08:50 GMT, Aleksey Shipilev wrote: >> src/hotspot/os/windows/os_windows.cpp line 510: >> >>> 508: // Thread start routine for all newly created threads. >>> 509: // Called with the associated Thread* as the argument. >>> 510: static unsigned thread_native_entry(void* t) { >> >> Whoa! Hold on there. The `_stdcall` is required here and nothing to do with 32-bit. We use `begindthreadex` to start threads and the entry function is required to be `_stdcall`. >> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170 > > Not sure why this comment was marked as "Resolved". I have the same question here. @shipilev See addressing comments below: > https://learn.microsoft.com/en-us/cpp/cpp/stdcall?view=msvc-170 > On ARM and x64 processors, __stdcall is accepted and ignored by the compiler; on ARM and x64 architectures, by convention, arguments are passed in registers when possible, and subsequent arguments are passed on the stack. > To my knowledge the only thing __cdecl and __stdcall do is affect the argument passing on the stack since 32 bit uses the stack to pass arguments. Since 64 bit passes arguments inside registers and then only later uses the stack if there are too many parameters to fit in the parameter registers (Basically permanent __fastcall), these specifiers are probably ignored in all 64 bit platforms ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1832581212 From ihse at openjdk.org Thu Nov 7 13:00:02 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 7 Nov 2024 13:00:02 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> Message-ID: On Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove FIXME > > I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO. @shipilev Sure, I can revert the `_stdcall` changes from here and put them in a a separate PR. Kim also expressed a similar wish. Removing dead code like this is both a bit of an iterative process ("oh, now that we removed X, we can also remove Y"), and a bit of a judgement call ("now that `JNICALL` is not needed,we can remove it"). Sometimes it is not clear where to draw the line. Personally, I'm mostly interested in getting rid of all the junk in the build system; all the rest is just stuff I do as a "community service" to avoid having stuff laying around. (And I did it, under the (apparently na?ve) assumption that this would not require that much extra work :-), coupled with the (more cynical) assumption that if I did not do this, nothing would really happen on this front...) I personally do think that removing the obsolete `_stdcall` is "provably, uncontroversially, visibly safe". But then again, it's not me who is going to have to chase the future bugs, so I respect your opinion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2462174907 From jbechberger at openjdk.org Thu Nov 7 13:10:32 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 7 Nov 2024 13:10:32 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v15] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Make native stack walking code simpler ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/0a4454cd..49e7899a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=13-14 Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From jbechberger at openjdk.org Thu Nov 7 13:10:32 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 7 Nov 2024 13:10:32 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4] In-Reply-To: References: Message-ID: <2iDIXZs1XND2h0UUK-Cj31lABoF1XV0aVKNKwU6UFI4=.05499862-05b9-43cc-87dc-9b829cf86d85@github.com> On Thu, 31 Oct 2024 23:52:05 GMT, Markus Gr?nlund wrote: >> This is not always the case, as far as I know. > > It should be ok to start from the anchor frame. > > Please see JfrNativeSamplerCallback::call(). Interestingly, removing the lines reduced the number of failed samples. Maybe we should also improve ASGCT (from where the lines come)? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1832648915 From jbechberger at openjdk.org Thu Nov 7 13:18:01 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 7 Nov 2024 13:18:01 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4] In-Reply-To: <8ziHdjO8nrSJdL9zVITYy5vU1F67mlmyf72f_cIhhcI=.04c40b75-3d05-40b2-bec9-a7f763b056ce@github.com> References: <8ziHdjO8nrSJdL9zVITYy5vU1F67mlmyf72f_cIhhcI=.04c40b75-3d05-40b2-bec9-a7f763b056ce@github.com> Message-ID: On Thu, 31 Oct 2024 12:36:32 GMT, Markus Gr?nlund wrote: >> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove min_valid_free_size_bytes > > test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleThrottling.java line 65: > >> 63: private static void testThrottleSettingsPeriod() throws Exception { >> 64: float rate = countEvents(1000, "1ms").rate(); >> 65: Asserts.assertTrue(rate > 950 && rate < 1050, "Expected around 1000 events per second, got " + rate); > > Fails on linux-aarch64-debug builds: > > ----------System.out:(0/0)---------- > ----------System.err:(14/1061)---------- > java.lang.RuntimeException: Expected around 1000 events per second, got 245.15503: expected true, was false > at jdk.test.lib.Asserts.fail(Asserts.java:691) > at jdk.test.lib.Asserts.assertTrue(Asserts.java:543) > at jdk.jfr.event.profiling.TestCPUTimeEventThrottling.testThrottleSettingsPeriod(TestCPUTimeEventThrottling.java:65) > at jdk.jfr.event.profiling.TestCPUTimeEventThrottling.main(TestCPUTimeEventThrottling.java:49) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:573) > at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) > at java.base/java.lang.Thread.run(Thread.java:1576) > > JavaTest Message: Test threw exception: java.lang.RuntimeException: Expected around 1000 events per second, got 245.15503: expected true, was false > JavaTest Message: shutting down test This is interesting, it shouldn't happen (assuming that the system has at least one CPU that the CPU wasting code can run alone). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1832662175 From egahlin at openjdk.org Thu Nov 7 13:33:55 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 7 Nov 2024 13:33:55 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v15] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 14:02:06 GMT, Johannes Bechberger wrote: >> If you disable the stackTrace, you will still get the thread. Perhaps not that useful, but that could be said about many events that have a stack trace. I think we should keep it consistent. > > But doesn't the user expect that they get a stack trace when they write a settings file with: > > > > true > 150/s > > > > Because when they write > > > > true > 10ms > > > > They also get one. So I think we should not force the user to set the stacktrace. Stack trace is enabled by default, so a user should not need to do additional work with a stackTrace setting. I could be wrong, but I think the reason the ExecutionSample event looks like that is due to legacy. Then we just copied that when we created the NativeMethodSample event. Maybe we should change ExecutionSample and NativeMethodSample so they work like other events (but not in this PR)? I can look into it in the next few days and see if there is a reason they don't have a stackTrace setting. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1832683303 From coleenp at openjdk.org Thu Nov 7 13:34:50 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 7 Nov 2024 13:34:50 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v8] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 23:57:48 GMT, Ioi Lam wrote: >> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). >> >> ---- >> Note: this is a combined PR of the following individual PRs >> - https://github.com/openjdk/jdk/pull/20516 >> - https://github.com/openjdk/jdk/pull/20517 >> - https://github.com/openjdk/jdk/pull/20843 >> - https://github.com/openjdk/jdk/pull/20958 >> - https://github.com/openjdk/jdk/pull/20959 >> - https://github.com/openjdk/jdk/pull/21049 >> - https://github.com/openjdk/jdk/pull/21143 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @DanHeidinga comment -- exit VM when runtimeSetup() fails I had a couple of drive by comments. src/hotspot/share/cds/aotConstantPoolResolver.cpp line 2: > 1: /* > 2: * Copyright (c) 2022, 2024, Oracle and/or its affiliates. All rights reserved. If this is a new file, it shouldn't have 2022 in the copyright year. src/hotspot/share/cds/aotConstantPoolResolver.cpp line 81: > 79: } > 80: > 81: if (!k->is_instance_klass()) { How can a field, interface or method cp reference point to a non-instance klass? Or is this for a method in java.lang.Object, which can be an array klass ? I doubt you should bother to support this special case. src/hotspot/share/cds/aotConstantPoolResolver.cpp line 138: > 136: } else if (elem->is_typeArray_klass()) { > 137: return true; > 138: } else { I think bottom_klass can only be InstanceKlass or typeArrayKlass, so else should be not possible and an assert. ------------- PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2420951812 PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1832663874 PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1832668217 PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1832674559 From coleenp at openjdk.org Thu Nov 7 13:34:51 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 7 Nov 2024 13:34:51 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v8] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 13:16:19 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @DanHeidinga comment -- exit VM when runtimeSetup() fails > > src/hotspot/share/cds/aotConstantPoolResolver.cpp line 2: > >> 1: /* >> 2: * Copyright (c) 2022, 2024, Oracle and/or its affiliates. All rights reserved. > > If this is a new file, it shouldn't have 2022 in the copyright year. Oh looks like it's been moved from classPrelinker, except git doesn't show it's moved. If it's added as a moved file, would there be less diffs to look at? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1832685160 From mbaesken at openjdk.org Thu Nov 7 13:51:52 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 7 Nov 2024 13:51:52 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v15] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 13:10:32 GMT, Johannes Bechberger wrote: >> This is the code for the [JEP draft: CPU Time based profiling for JFR]. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Make native stack walking code simpler test/jdk/jdk/jfr/event/profiling/classes/test/RecursiveMethods.java line 76: > 74: return depth; > 75: } > 76: } Is there an issue here with the file ending of the added file ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1832713749 From jbechberger at openjdk.org Thu Nov 7 14:04:22 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 7 Nov 2024 14:04:22 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v16] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 13:29:35 GMT, Erik Gahlin wrote: > Maybe we should change ExecutionSample and NativeMethodSample so they work like other events (but not in this PR)? Good idea. Ok, then I change the code accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1832730362 From jbechberger at openjdk.org Thu Nov 7 14:04:22 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 7 Nov 2024 14:04:22 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v16] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Add newline to file end ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/49e7899a..b0fbd431 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=14-15 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From jbechberger at openjdk.org Thu Nov 7 15:11:00 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 7 Nov 2024 15:11:00 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v17] In-Reply-To: References: Message-ID: <8gpM6lOT_ncKkCtMDNlwzkC89K-uxWcvzmkv5xxTeaA=.e97688f7-8c2d-4d8a-8e0b-b467d1de9c0d@github.com> > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Don't treat stackTrace attribute specially for CPUTimeSamples ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/b0fbd431..9f96cc0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=15-16 Stats: 3 lines in 3 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From mbaesken at openjdk.org Thu Nov 7 15:25:56 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 7 Nov 2024 15:25:56 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v17] In-Reply-To: <8gpM6lOT_ncKkCtMDNlwzkC89K-uxWcvzmkv5xxTeaA=.e97688f7-8c2d-4d8a-8e0b-b467d1de9c0d@github.com> References: <8gpM6lOT_ncKkCtMDNlwzkC89K-uxWcvzmkv5xxTeaA=.e97688f7-8c2d-4d8a-8e0b-b467d1de9c0d@github.com> Message-ID: On Thu, 7 Nov 2024 15:11:00 GMT, Johannes Bechberger wrote: >> This is the code for the [JEP draft: CPU Time based profiling for JFR]. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Don't treat stackTrace attribute specially for CPUTimeSamples src/hotspot/share/jfr/metadata/metadata.xml line 940: > 938: > 939: 940: description="Snapshot of a threads state from the CPU time sampler. The throttle can be either an upper bound for the event emission rate, e.g. 100/s, or the cpu-time period, e.g. 10ms, with s, ms, us and ns supported as time units." The throttle event setting is 'true' (boolean) by default; but then you speak about that it is some time unit like 10ms. Maybe the description might need a bit of adjustment to make it more clear to the average JFR user what it is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1832872474 From stuefe at openjdk.org Thu Nov 7 15:28:05 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 7 Nov 2024 15:28:05 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> Message-ID: <6qzIK_QQ2Rs5deO4jIyicr7ob4CZCg7ajBnbEd9vCFU=.6fc95a24-9f01-4e61-bb21-442720c53437@github.com> On Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove FIXME > > I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO. @shipilev @magicus Okay but where do we draw the line? Because then we also need to keep the code that takes care of x86 calling convention name mangling. [Microsoft states](https://learn.microsoft.com/en-us/cpp/cpp/stdcall?view=msvc-170) "On ARM and x64 processors, __stdcall is accepted and *ignored by the compiler*; on ARM and x64 architectures, by convention, arguments are passed in registers when possible, and subsequent arguments are passed on the stack." Similar statements can be found in the MSDN documentation for __cdecl and __fastcall. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2462517302 From jbechberger at openjdk.org Thu Nov 7 15:32:05 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 7 Nov 2024 15:32:05 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v17] In-Reply-To: References: <8gpM6lOT_ncKkCtMDNlwzkC89K-uxWcvzmkv5xxTeaA=.e97688f7-8c2d-4d8a-8e0b-b467d1de9c0d@github.com> Message-ID: On Thu, 7 Nov 2024 15:23:10 GMT, Matthias Baesken wrote: >> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't treat stackTrace attribute specially for CPUTimeSamples > > src/hotspot/share/jfr/metadata/metadata.xml line 940: > >> 938: >> 939: > 940: description="Snapshot of a threads state from the CPU time sampler. The throttle can be either an upper bound for the event emission rate, e.g. 100/s, or the cpu-time period, e.g. 10ms, with s, ms, us and ns supported as time units." > > The throttle event setting is 'true' (boolean) by default; but then you speak about that it is some time unit like 10ms. Maybe the description might need a bit of adjustment to make it more clear to the average JFR user what it is. `throttle=true` means that this event has a throttle attribute, that should be clear to the user. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1832882472 From duke at openjdk.org Thu Nov 7 16:06:16 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Thu, 7 Nov 2024 16:06:16 GMT Subject: RFR: 8341411: C2: remove slice parameter from GraphKit::make_load() and GraphKit::store_to_memory() [v3] In-Reply-To: References: Message-ID: > This patch removes the address type from `GraphKit::make_load()` and `GraphKit::store_to_memory()` > > As https://github.com/openjdk/jdk/pull/21303 introduced asserts that check that the address type agrees with `C->get_alias_index(_gvn.type(adr)->isa_ptr()`, passing the address type is redundant and it can be computed internally from the address. theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: Add asserts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21834/files - new: https://git.openjdk.org/jdk/pull/21834/files/f89f2cf4..cb703a4e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21834&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21834&range=01-02 Stats: 5 lines in 3 files changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21834.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21834/head:pull/21834 PR: https://git.openjdk.org/jdk/pull/21834 From duke at openjdk.org Thu Nov 7 16:06:17 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Thu, 7 Nov 2024 16:06:17 GMT Subject: RFR: 8341411: C2: remove slice parameter from GraphKit::make_load() and GraphKit::store_to_memory() [v3] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 12:01:41 GMT, Roland Westrelin wrote: >> theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: >> >> Add asserts > > src/hotspot/share/opto/graphKit.cpp line 1561: > >> 1559: bool unsafe, >> 1560: uint8_t barrier_data) { >> 1561: assert(adr_idx == C->get_alias_index(_gvn.type(adr)->isa_ptr()), "slice of address and input slice don't match"); > > This assert (and the other one in `store_to_memory`) were added because there are 2 ways to compute the slice for a memory operation. One is from `_gvn.type(adr)->isa_ptr()`. The other is from `C->alias_type(field)->adr_type()` in case of fields accesses (see `Parse::do_get_xxx()` and `Parse::do_put_xxx()`). They should give the same result but in one bug we ran into that wasn't the case (thus the assert). I don't think we want to remove this assert entirely but rather push it up the call chain maybe to `BarrierSetC2::store_at_resolved()`/`BarrierSetC2::load_at_resolved` or all the way to where `C->alias_type(field)->adr_type()` is called. I've added the asserts as we discussed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21834#discussion_r1832940662 From rkennke at openjdk.org Thu Nov 7 16:58:36 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 7 Nov 2024 16:58:36 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v56] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 106 commits: - Merge tag 'jdk-25+23' into JDK-8305895-v4 Added tag jdk-24+23 for changeset c0e6c3b9 - Fix gen-ZGC removal - Merge tag 'jdk-24+22' into JDK-8305895-v4 Added tag jdk-24+22 for changeset 388d44fb - Enable riscv in CompressedClassPointersEncodingScheme test - s390 port - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test - Update copyright - Avoid assert/endless-loop in JFR code - Update copyright headers - Merge tag 'jdk-24+20' into JDK-8305895-v4 Added tag jdk-24+20 for changeset 7a64fbbb - ... and 96 more: https://git.openjdk.org/jdk/compare/c0e6c3b9...4d282247 ------------- Changes: https://git.openjdk.org/jdk/pull/20677/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=55 Stats: 5212 lines in 218 files changed: 3585 ins; 864 del; 763 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From rkennke at openjdk.org Thu Nov 7 17:25:40 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 7 Nov 2024 17:25:40 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: - Merge branch 'master' into JDK-8305895-v4 - Merge tag 'jdk-25+23' into JDK-8305895-v4 Added tag jdk-24+23 for changeset c0e6c3b9 - Fix gen-ZGC removal - Merge tag 'jdk-24+22' into JDK-8305895-v4 Added tag jdk-24+22 for changeset 388d44fb - Enable riscv in CompressedClassPointersEncodingScheme test - s390 port - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test - Update copyright - Avoid assert/endless-loop in JFR code - Update copyright headers - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b ------------- Changes: https://git.openjdk.org/jdk/pull/20677/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=56 Stats: 5212 lines in 218 files changed: 3585 ins; 864 del; 763 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From rkennke at openjdk.org Thu Nov 7 17:33:11 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 7 Nov 2024 17:33:11 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b I'd like to prepare for integration now. I merged from master and resolved some conflicts. I am now running at least tier1 on aarch64 x x86_64 x -UCOH x +UCOH, possibly tier2 .. 4, too (time permitting). In the meantime, could you please re-approve the PR? I hope it doesn't catch any more conflicts until we're ready for intergration. As soon as the JEP is targeted (sometime today, I think), tests are clean and approvals are there, I would like to integrate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2462834035 From coleenp at openjdk.org Thu Nov 7 17:46:11 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 7 Nov 2024 17:46:11 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b Reapproving. Please wait for GHA to complete, when JEP is targeted to integrate. Thanks! ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2421741026 From stefank at openjdk.org Thu Nov 7 17:53:10 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 7 Nov 2024 17:53:10 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b Marked as reviewed by stefank (Reviewer). Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2417620293 PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2421753879 From sspitsyn at openjdk.org Thu Nov 7 18:33:14 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 7 Nov 2024 18:33:14 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com> References: <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com> Message-ID: On Thu, 7 Nov 2024 00:38:18 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount Thank you for updates! Looks good. Overall, it is a great job! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadEventTest/libVThreadEventTest.cpp line 104: > 102: > 103: err = jvmti->GetMethodName(frameInfo[idx].method, &methodName, nullptr, nullptr); > 104: check_jvmti_status(jni, err, "event handler: error in JVMTI GetMethodName call"); Nit: There is the test library function `get_method_name()` in `jvmti_common.hpp` that can be used here. Also, the `methodName` is better to deallocate with the `deallocate() function. The same is in the `VirtualThreadMount` callback. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2421828032 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833167652 From sspitsyn at openjdk.org Thu Nov 7 18:33:14 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 7 Nov 2024 18:33:14 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 00:38:57 GMT, Patricio Chilano Mateo wrote: >>> the call to java_lang_Thread::set_is_in_VTMS_transition()is not needed in JvmtiUnmountBeginMark >>> >> Why is not needed? I guess you meant to say we should use `JvmtiVTMSTransitionDisabler::set_is_in_VTMS_transition()` which does both? > >> the function is_vthread_safe_to_preempt() does not need the vthread parameter >> > Removed. Thank you for the update! It looks okay to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833168776 From sspitsyn at openjdk.org Thu Nov 7 18:33:14 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 7 Nov 2024 18:33:14 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: <5ZFkpNRHw-d5qP3ggPI41D6Z5Em7HyjLy-0kt3JX_u8=.7ffe4080-8792-43ba-a67b-b43098417019@github.com> References: <5ZFkpNRHw-d5qP3ggPI41D6Z5Em7HyjLy-0kt3JX_u8=.7ffe4080-8792-43ba-a67b-b43098417019@github.com> Message-ID: <8fsvkr2uAamrF-VvR5mNHGF4NF_FJkgMDzxLeVh1wNs=.54597efe-cc91-426d-ae86-f13d20a1f889@github.com> On Thu, 7 Nov 2024 00:40:26 GMT, Patricio Chilano Mateo wrote: >>> So at some point I think we need to figure out how to make them go away ... >> >> Yes, the 2 extension events (`VirtualThreadMount` and `VirtualThreadUnmount`) were added for testing purposes. We wanted to get rid of them at some point but the Graal team was using them for some purposes. >> >>> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor... >> >> The two extension events were designed to be posted when the current thread identity is virtual, so this behavior needs to be considered as a bug. My understanding is that it is not easy to fix. We most likely, we have no tests to fail because of this though. >> >>> That's the path a virtual thread will take if pinned. >> >> Got it, thanks. I realize it is because we do not thaw and freeze the VM frames. It is not easy to comprehend. > >> The two extension events were designed to be posted when the current thread identity is virtual, so this behavior > needs to be considered as a bug. My understanding is that it is not easy to fix. >> > If we want to post the mount/unmount events here is actually simple if we also use `JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount`. I included it in the last commit. Thank you for the explanations and update. The update looks okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833171024 From kbarrett at openjdk.org Thu Nov 7 18:34:52 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 7 Nov 2024 18:34:52 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v3] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 08:32:16 GMT, theoweidmannoracle wrote: >> - Changed several "NULL" in comments to "null" >> - Changed several `NULL` in code to `nullptr` > > theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: > > Fix backslides in test Looks good. The grep results are exactly as expected. Thanks for checking that. Now if we can just get the build to start checking for us, we can stop needing these periodic cleanups. I forget whether a JBS issue has been filed for that. If not, I will do so. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21826#pullrequestreview-2421831752 From sspitsyn at openjdk.org Thu Nov 7 18:38:07 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 7 Nov 2024 18:38:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com> References: <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com> Message-ID: On Thu, 7 Nov 2024 00:38:18 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount src/hotspot/share/prims/jvmtiThreadState.cpp line 2: > 1: /* > 2: * Copyright (c) 2003, 2024, Oracle and/or its affiliates. All rights reserved. Nit: No need in the copyright update anymore. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833174843 From kbarrett at openjdk.org Thu Nov 7 18:42:02 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 7 Nov 2024 18:42:02 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> Message-ID: <3Rg6yosMIl2HdD2FNR-dPM8dSWZiIS3irKW0uOxNnh8=.91ba8741-d3fb-4ecd-9651-325d4f06f9ca@github.com> On Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove FIXME > > I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO. > @shipilev Sure, I can revert the `_stdcall` changes from here and put them in a a separate PR. Kim also expressed a similar wish. To be clear, I wished it had been done as a separate followup, but reviewed it here all the same, in the interest of limiting review and testing churn. If you back it out, that will be more churn that I don't think is particularly beneficial. I'll go along with whatever @magicus and @shipilev and @tstuefe decide to do about it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2462963330 From pchilanomate at openjdk.org Thu Nov 7 19:15:50 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 7 Nov 2024 19:15:50 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v3] In-Reply-To: References: Message-ID: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 84 commits: - Use get_method_name + copyright revert in jvmtiThreadState.cpp - Merge branch 'master' into JDK-8338383 - Add @requires vm.continuations to CancelTimerWithContention.java - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount - Use is_top_frame boolean in FreezeBase::check_valid_fast_path() - Move load of _lock_id in C2_MacroAssembler::fast_lock - Add --enable-native-access=ALL-UNNAMED to SynchronizedNative.java - Update comment for _cont_fastpath - Add ReflectionCallerCacheTest.java to test/jdk/ProblemList-Xcomp.txt - Use ThreadIdentifier::initial() in ObjectMonitor::owner_from() - ... and 74 more: https://git.openjdk.org/jdk/compare/d3c042f9...62b16c6a ------------- Changes: https://git.openjdk.org/jdk/pull/21565/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=02 Stats: 9939 lines in 247 files changed: 7131 ins; 1629 del; 1179 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From pchilanomate at openjdk.org Thu Nov 7 19:20:12 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 7 Nov 2024 19:20:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: References: <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com> Message-ID: On Thu, 7 Nov 2024 18:32:14 GMT, Serguei Spitsyn wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount > > src/hotspot/share/prims/jvmtiThreadState.cpp line 2: > >> 1: /* >> 2: * Copyright (c) 2003, 2024, Oracle and/or its affiliates. All rights reserved. > > Nit: No need in the copyright update anymore. Fixed. > test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadEventTest/libVThreadEventTest.cpp line 104: > >> 102: >> 103: err = jvmti->GetMethodName(frameInfo[idx].method, &methodName, nullptr, nullptr); >> 104: check_jvmti_status(jni, err, "event handler: error in JVMTI GetMethodName call"); > > Nit: There is the test library function `get_method_name()` in `jvmti_common.hpp` that can be used here. > Also, the `methodName` is better to deallocate with the `deallocate() function. > The same is in the `VirtualThreadMount` callback. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833226416 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833225816 From pchilanomate at openjdk.org Thu Nov 7 19:24:07 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 7 Nov 2024 19:24:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v3] In-Reply-To: <7trSDsagiP_ARB6Fi8hffBxAn1tYxAMRxV1sV-GL0qw=.4899e993-c276-48ca-a6a6-ea5e1e56ac55@github.com> References: <04lJ9Fw4vDQWjvQkCuYmVoaMN3t7Gq4pjg32puxcahQ=.3795a7ae-13d1-4cdb-b27d-db50ff53b59b@github.com> <7trSDsagiP_ARB6Fi8hffBxAn1tYxAMRxV1sV-GL0qw=.4899e993-c276-48ca-a6a6-ea5e1e56ac55@github.com> Message-ID: On Thu, 7 Nov 2024 09:45:40 GMT, Amit Kumar wrote: > > I think we can add @requires vm.continuations to this test. It's not useful to run with the alternative virtual thread implementation. > > Sure, that sounds ok. Thanks. > Added `@requires vm.continuations` to the test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2463035166 From rkennke at openjdk.org Thu Nov 7 21:27:09 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 7 Nov 2024 21:27:09 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: <2xoAD2r5G_6IHT9gt8-uSkN_hPiRmIkJ6VhkB1GarfI=.4e3c65db-3aab-4926-b1fc-fc78599b2885@github.com> On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b GHA failures look like one unrelated timeout and one unrelated infra problem. Please confirm. I also run tier1 on x86_64 x aarch64 x -UCOH x + UCOH, with nothing sticking out (same timeout observed, though). ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2463245179 From kbarrett at openjdk.org Thu Nov 7 21:56:34 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 7 Nov 2024 21:56:34 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v3] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 18:31:51 GMT, Kim Barrett wrote: > The grep results are exactly as expected. Thanks for checking that. Now if we can just get the build to start checking for us, we can stop needing these periodic cleanups. I forget whether a JBS issue has been filed for that. If not, I will do so. II've filed these followup issues: https://bugs.openjdk.org/browse/JDK-8343802 Prevent NULL usage backsliding https://bugs.openjdk.org/browse/JDK-8343800 Cleanup definition of NULL_WORD https://bugs.openjdk.org/browse/JDK-8343801 Change string printed by nsk_null_string for null strings ------------- PR Comment: https://git.openjdk.org/jdk/pull/21826#issuecomment-2463290137 From henryjen at openjdk.org Thu Nov 7 22:13:02 2024 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 7 Nov 2024 22:13:02 GMT Subject: RFR: 8342035: jlink plugins for setting java.vendor, java.vm.vendor and java.vendor.url Message-ID: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url. The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps. To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build. ------------- Commit messages: - Avoid N/A used as java.vm.vendor value as currently build behavior - 8342035: jlink plugins for setting java.vendor, java.vm.vendor and java.vendor.url Changes: https://git.openjdk.org/jdk/pull/21964/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21964&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342035 Stats: 224 lines in 14 files changed: 213 ins; 5 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/21964.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21964/head:pull/21964 PR: https://git.openjdk.org/jdk/pull/21964 From coleenp at openjdk.org Thu Nov 7 22:15:49 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 7 Nov 2024 22:15:49 GMT Subject: RFR: 8343244: Aarch64: Internal Error virtualMemoryTracker.cpp:444 assert(reserved_rgn != nullptr) failed: Add committed region, No reserved region found [v4] In-Reply-To: References: Message-ID: <2_g2KYopxbj1Kl2zpe8ScRBQVzeDc0a9q-pMbrc92Og=.c7ce5a27-a311-45c6-9141-3cc5479fe702@github.com> On Wed, 6 Nov 2024 16:12:49 GMT, Johan Sj?len wrote: >> Hi, >> >> Ping @roberttoyonaga , @tstuefe , @afshin-zafari , @dholmes-ora , @gerard-ziemski >> >> We are seeing issues with the transition to one of our 'fat' mutexes. Specifically, we do have `os::commit_memory` that occurs during the running `Thread`'s initialization, see the following stack trace: >> >> >> Stack: [0x0000ffff686ae000,0x0000ffff687ae000], sp=0x0000ffff687ac5f0, free space=1017k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x16aa67c] VirtualMemoryTracker::add_committed_region(unsigned char*, unsigned long, NativeCallStack const&)+0x38c (virtualMemoryTracker.cpp:444) >> V [libjvm.so+0x131134c] os::commit_memory(char*, unsigned long, bool)+0x198 (memTracker.hpp:165) >> V [libjvm.so+0x14ddf54] StackOverflow::create_stack_guard_pages()+0x70 (stackOverflow.cpp:97) >> V [libjvm.so+0xe2e0dc] attach_current_thread.isra.0+0x11c (jni.cpp:3809) >> C [libExplicitAttach.so+0xa64] thread_main+0x34 (libExplicitAttach.c:45) >> C [libc.so.6+0x806b8] start_thread+0x2d8 >> >> >> This, in turn, causes issues where the lock isn't actually taken, causing issues with the VMT. I'd like to suggest that we switch out the `Mutex` to a `PlatformMutex`. Platform mutexes are identical in construction to `ThreadCritical`, but are at least not shared globally and can be owned by the `VirtualMemoryTracker`. >> >> If you do not agree with this change, then I suggest that we back out [8304824](https://bugs.openjdk.org/browse/JDK-8304824) ASAP and wait for a better solution. >> >> Thanks. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > That assert is clearly incorrect I don't think you should use PlatformMutex in the raw in runtime code (some GC code does use it) - if Mutex is not yet initialized, use ConditionalMutex instead. Yes, PlatformMutex doesn't have the deadlock detection which you'll want with NMT code (other locks are being held when you take out NMT locks so verifying rank is important), and it also has no-safepoint checking since you'll want these locks to not check for a safepoint. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21928#issuecomment-2463331535 From dholmes at openjdk.org Fri Nov 8 02:16:02 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 8 Nov 2024 02:16:02 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 6 Nov 2024 15:21:10 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Remove FIXME Can someone confirm that use of `__stdcall` has no affect on name decorations, as there is no mention here about anything being ignored: https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170 I would have expected that if argument passing needs to use the stack then the decorated name would still need to encode that somehow. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2463619091 From amenkov at openjdk.org Fri Nov 8 02:38:17 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 8 Nov 2024 02:38:17 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Fri, 8 Nov 2024 02:13:09 GMT, David Holmes wrote: > Can someone confirm that use of `__stdcall` has no affect on name decorations, as there is no mention here about anything being ignored: > > https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170 > > I would have expected that if argument passing needs to use the stack then the decorated name would still need to encode that somehow. In the page you mentioned: Format of a C decorated name The form of decoration for a C function depends on the calling convention used in its declaration, as shown in the following table. It's also the decoration format that's used when C++ code is declared to have extern "C" linkage. The default calling convention is __cdecl. **In a 64-bit environment, C or extern "C" functions are only decorated when using the __vectorcall calling convention**. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2463636430 From sspitsyn at openjdk.org Fri Nov 8 03:05:13 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 8 Nov 2024 03:05:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v3] In-Reply-To: References: Message-ID: <-R7NADC_veb_n80hbfTME54iuMOvSj38dfBrT0KJQOw=.9345dfb0-58bd-4485-b92a-8c79b9114d25@github.com> On Thu, 7 Nov 2024 19:15:50 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 84 commits: > > - Use get_method_name + copyright revert in jvmtiThreadState.cpp > - Merge branch 'master' into JDK-8338383 > - Add @requires vm.continuations to CancelTimerWithContention.java > - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount > - Use is_top_frame boolean in FreezeBase::check_valid_fast_path() > - Move load of _lock_id in C2_MacroAssembler::fast_lock > - Add --enable-native-access=ALL-UNNAMED to SynchronizedNative.java > - Update comment for _cont_fastpath > - Add ReflectionCallerCacheTest.java to test/jdk/ProblemList-Xcomp.txt > - Use ThreadIdentifier::initial() in ObjectMonitor::owner_from() > - ... and 74 more: https://git.openjdk.org/jdk/compare/d3c042f9...62b16c6a Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2422590696 From iklam at openjdk.org Fri Nov 8 03:31:51 2024 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 8 Nov 2024 03:31:51 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v9] In-Reply-To: References: Message-ID: > This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). > > ---- > Note: this is a combined PR of the following individual PRs > - https://github.com/openjdk/jdk/pull/20516 > - https://github.com/openjdk/jdk/pull/20517 > - https://github.com/openjdk/jdk/pull/20843 > - https://github.com/openjdk/jdk/pull/20958 > - https://github.com/openjdk/jdk/pull/20959 > - https://github.com/openjdk/jdk/pull/21049 > - https://github.com/openjdk/jdk/pull/21143 Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits: - fixed merge - Merge branch 'master' of https://github.com/openjdk/jdk into merge-mainline - @DanHeidinga comment -- exit VM when runtimeSetup() fails - fixed merge - Merge branch 'master' into jep-483-candidate - 8343493: Perform module checks during MetaspaceShared::map_archives() - reverted changes in modules.cpp to make it easy to merge with mainline - Fixed whitespace; fixed minimal build - Fixed 8343245: AOT cache creation crashes with "assert(HeapShared::is_archivable_hidden_klass(ik)) failed: sanity" - fixed comments - ... and 165 more: https://git.openjdk.org/jdk/compare/f621f26c...7b06b7c7 ------------- Changes: https://git.openjdk.org/jdk/pull/21642/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=08 Stats: 7184 lines in 107 files changed: 6349 ins; 513 del; 322 mod Patch: https://git.openjdk.org/jdk/pull/21642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642 PR: https://git.openjdk.org/jdk/pull/21642 From jwaters at openjdk.org Fri Nov 8 05:34:19 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 8 Nov 2024 05:34:19 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <5MiMXHq-N3d78GScK19QTQAg0t9eyJUo3XznZE-7VJg=.4121e038-b666-4770-a497-5a5522c51027@github.com> On Fri, 8 Nov 2024 02:32:42 GMT, Alex Menkov wrote: > Can someone confirm that use of `__stdcall` has no affect on name decorations, as there is no mention here about anything being ignored: > > https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170 > > I would have expected that if argument passing needs to use the stack then the decorated name would still need to encode that somehow. https://godbolt.org/z/xve7cbG1e ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2463794511 From dholmes at openjdk.org Fri Nov 8 05:34:19 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 8 Nov 2024 05:34:19 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Fri, 8 Nov 2024 02:32:42 GMT, Alex Menkov wrote: > In the page you mentioned: @alexmenkov that is for C functions, not C++. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2463796536 From dholmes at openjdk.org Fri Nov 8 05:46:58 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 8 Nov 2024 05:46:58 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: <5MiMXHq-N3d78GScK19QTQAg0t9eyJUo3XznZE-7VJg=.4121e038-b666-4770-a497-5a5522c51027@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <5MiMXHq-N3d78GScK19QTQAg0t9eyJUo3XznZE-7VJg=.4121e038-b666-4770-a497-5a5522c51027@github.com> Message-ID: On Fri, 8 Nov 2024 05:26:37 GMT, Julian Waters wrote: >>> Can someone confirm that use of `__stdcall` has no affect on name decorations, as there is no mention here about anything being ignored: >>> >>> https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170 >>> >>> I would have expected that if argument passing needs to use the stack then the decorated name would still need to encode that somehow. >> >> In the page you mentioned: >> >> Format of a C decorated name >> The form of decoration for a C function depends on the calling convention used in its declaration, as shown in the following table. It's also the decoration format that's used when C++ code is declared to have extern "C" linkage. The default calling convention is __cdecl. **In a 64-bit environment, C or extern "C" functions are only decorated when using the __vectorcall calling convention**. > >> Can someone confirm that use of `__stdcall` has no affect on name decorations, as there is no mention here about anything being ignored: >> >> https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170 >> >> I would have expected that if argument passing needs to use the stack then the decorated name would still need to encode that somehow. > > Not __stdcall: https://godbolt.org/z/nvjTP5WPc > __stdcall: https://godbolt.org/z/1KejW44vY Thanks @TheShermanTanker . I see the arguments do affect the encoding but the `__stdcall` makes no difference. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2463816359 From dholmes at openjdk.org Fri Nov 8 05:51:28 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 8 Nov 2024 05:51:28 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <1D5bn5rgr4DaceNVvTisKsP3eAm-2R4D9DcZJ6gp1bk=.6add3137-d50a-488d-89e8-dd503d524e5c@github.com> On Wed, 6 Nov 2024 15:21:10 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Remove FIXME Clearing my "changes requested" status ------------- PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2422752388 From stuefe at openjdk.org Fri Nov 8 07:02:51 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 8 Nov 2024 07:02:51 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b Merge looks good. build errors on MacOS unrelated. ------------- PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2422830379 From duke at openjdk.org Fri Nov 8 08:26:14 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Fri, 8 Nov 2024 08:26:14 GMT Subject: RFR: 8341411: C2: remove slice parameter from GraphKit::make_load() and GraphKit::store_to_memory() [v4] In-Reply-To: References: Message-ID: > This patch removes the address type from `GraphKit::make_load()` and `GraphKit::store_to_memory()` > > As https://github.com/openjdk/jdk/pull/21303 introduced asserts that check that the address type agrees with `C->get_alias_index(_gvn.type(adr)->isa_ptr()`, passing the address type is redundant and it can be computed internally from the address. theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: Added assert message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21834/files - new: https://git.openjdk.org/jdk/pull/21834/files/cb703a4e..256bcf4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21834&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21834&range=02-03 Stats: 10 lines in 3 files changed: 5 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21834.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21834/head:pull/21834 PR: https://git.openjdk.org/jdk/pull/21834 From tschatzl at openjdk.org Fri Nov 8 08:45:39 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Nov 2024 08:45:39 GMT Subject: RFR: 8343783: Improve asserts in concurrentHashTable.inline.hpp Message-ID: Hi all, please review this simple change to improve the asserts in the CHT to get more information if/when there is a failure like in JDK-8337216. Testing: gha Thanks, Thomas ------------- Commit messages: - 8343783 Changes: https://git.openjdk.org/jdk/pull/21970/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21970&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343783 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21970.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21970/head:pull/21970 PR: https://git.openjdk.org/jdk/pull/21970 From duke at openjdk.org Fri Nov 8 09:16:03 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Fri, 8 Nov 2024 09:16:03 GMT Subject: RFR: 8341411: C2: remove slice parameter from GraphKit::make_load() and GraphKit::store_to_memory() [v5] In-Reply-To: References: Message-ID: > This patch removes the address type from `GraphKit::make_load()` and `GraphKit::store_to_memory()` > > As https://github.com/openjdk/jdk/pull/21303 introduced asserts that check that the address type agrees with `C->get_alias_index(_gvn.type(adr)->isa_ptr()`, passing the address type is redundant and it can be computed internally from the address. theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: Fix asserts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21834/files - new: https://git.openjdk.org/jdk/pull/21834/files/256bcf4a..8d239fdc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21834&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21834&range=03-04 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21834.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21834/head:pull/21834 PR: https://git.openjdk.org/jdk/pull/21834 From chagedorn at openjdk.org Fri Nov 8 09:16:28 2024 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Fri, 8 Nov 2024 09:16:28 GMT Subject: RFR: 8343783: Improve asserts in concurrentHashTable.inline.hpp In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 08:05:47 GMT, Thomas Schatzl wrote: > Hi all, > > please review this simple change to improve the asserts in the CHT to get more information if/when there is a failure like in JDK-8337216. > > Testing: gha > > Thanks, > Thomas Looks good and trivial. ------------- Marked as reviewed by chagedorn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21970#pullrequestreview-2423151041 From tschatzl at openjdk.org Fri Nov 8 09:18:30 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Nov 2024 09:18:30 GMT Subject: RFR: 8343783: Improve asserts in concurrentHashTable.inline.hpp In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 09:13:44 GMT, Christian Hagedorn wrote: >> Hi all, >> >> please review this simple change to improve the asserts in the CHT to get more information if/when there is a failure like in JDK-8337216. >> >> Testing: gha >> >> Thanks, >> Thomas > > Looks good and trivial. Thanks @chhagedorn for your review. I agree about triviality, and will push. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21970#issuecomment-2464202378 From tschatzl at openjdk.org Fri Nov 8 09:20:02 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Nov 2024 09:20:02 GMT Subject: Integrated: 8343783: Improve asserts in concurrentHashTable.inline.hpp In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 08:05:47 GMT, Thomas Schatzl wrote: > Hi all, > > please review this simple change to improve the asserts in the CHT to get more information if/when there is a failure like in JDK-8337216. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: a9e53bb1 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/a9e53bb11788761277563d5912a9981932a7c1c9 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8343783: Improve asserts in concurrentHashTable.inline.hpp Reviewed-by: chagedorn ------------- PR: https://git.openjdk.org/jdk/pull/21970 From duke at openjdk.org Fri Nov 8 09:27:29 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Fri, 8 Nov 2024 09:27:29 GMT Subject: RFR: 8341411: C2: remove slice parameter from GraphKit::make_load() and GraphKit::store_to_memory() [v5] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 08:02:04 GMT, Tobias Hartmann wrote: >> theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix asserts > > Looks good to me. @rwestrel who proposed the change, should also have a look. @TobiHartmann @rwestrel I added new assert as discussed with @rwestrel. It would be great if you could review the new changes again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21834#issuecomment-2464216264 From ihse at openjdk.org Fri Nov 8 09:35:26 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 8 Nov 2024 09:35:26 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> Message-ID: On Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove FIXME > > I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO. @shipilev Could you consider accepting the existing `__stdcall` changes in this PR? That seems like the easiest way out of satisfying everyones opinions here.. As I said, I think they are just as safe as any other changes -- the only difference is that it is perhaps not as well-known in the community that they only affect x86. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2464232813 From amenkov at openjdk.org Fri Nov 8 09:41:54 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 8 Nov 2024 09:41:54 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Fri, 8 Nov 2024 05:29:05 GMT, David Holmes wrote: > > In the page you mentioned: > > @alexmenkov that is for C functions, not C++. And also for `extern "C"` (AFAIU we export all C++ functions as extern "C") ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2464243142 From jwaters at openjdk.org Fri Nov 8 09:43:46 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 8 Nov 2024 09:43:46 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 01:17:01 GMT, Julian Waters wrote: > Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely Bumping ------------- PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2464250156 From jwaters at openjdk.org Fri Nov 8 09:47:41 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 8 Nov 2024 09:47:41 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken In-Reply-To: References: <9C3_nSzX9UY6959Q1mpv1JpE7MMQ8l9JvRWUWSOuRQY=.e8928e43-8664-4de1-b240-3dca1f4ab4af@github.com> <31Dtdw2Xv9w5M6KbSN4lkHhpflbU3Nw123ZincFNHuk=.0c68c7e0-797b-4185-b59b-de2a49d29bd9@github.com> Message-ID: On Thu, 31 Oct 2024 10:09:32 GMT, Bernhard Urban-Forster wrote: >> I did mean the entire thing. I don't see any point in WIN64 code being in the x86 file when there is an x86_64 file. Of course I had forgotten about the Aarch64 Windows side, so maybe as I said this is really something for a os/windows file rather then `cpu/` ? > > If it's needed on AArch64 too, this should move to something in `os/windows` as David said. > > However, judging from the comment in https://github.com/openjdk/jdk/blob/c40bb7621c0e49581dac587b6900b6d281572813/src/hotspot/os/windows/sharedRuntimeRem.cpp#L34-L38 this workaround might not be needed anymore. The minimum version required for Windows-AArch64 is VS2017 (or even VS2019?), and for Windows-X64 apparently VS2022 is used (not sure what the minimum is): https://github.com/openjdk/jdk/blob/c40bb7621c0e49581dac587b6900b6d281572813/make/conf/jib-profiles.js#L1105 > > > So maybe this can be removed altogether? Someone needs to check if this assumption is still true today. > > Alas I don't have a Windows setup anymore. @karianna who is the local HotSpot Windows expert these days who could have a look at this? ? I don't think this workaround was intended for ARM64 in the first place, it explicitly mentions that it was written for x64, and the ifdef mess that resulted in this bug ended up bringing it over to ARM64 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1834028457 From mgronlun at openjdk.org Fri Nov 8 09:56:58 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 8 Nov 2024 09:56:58 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v17] In-Reply-To: <8gpM6lOT_ncKkCtMDNlwzkC89K-uxWcvzmkv5xxTeaA=.e97688f7-8c2d-4d8a-8e0b-b467d1de9c0d@github.com> References: <8gpM6lOT_ncKkCtMDNlwzkC89K-uxWcvzmkv5xxTeaA=.e97688f7-8c2d-4d8a-8e0b-b467d1de9c0d@github.com> Message-ID: On Thu, 7 Nov 2024 15:11:00 GMT, Johannes Bechberger wrote: >> This is the code for the [JEP draft: CPU Time based profiling for JFR]. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Don't treat stackTrace attribute specially for CPUTimeSamples A fatal error has been detected by the Java Runtime Environment: Internal Error (/open/src/hotspot/share/oops/accessBackend.cpp:180), pid=482941, tid=483074 assert(state == _thread_in_vm || state == _thread_in_Java || state == _thread_new) failed: Wrong thread state for accesses: 10 --------------- T H R E A D --------------- Current thread (0x00007f868c0043d0): JavaThread "ForkJoinPool-1-worker-10" daemon [_thread_blocked, id=483074, stack(0x00007f87607c9000,0x00007f87608c9000) (1024K)] Stack: [0x00007f87607c9000,0x00007f87608c9000], sp=0x00007f87608c4e10, free space=1007k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x34c9b9] AccessInternal::check_access_thread_state()+0xb9 (accessBackend.cpp:180) V [libjvm.so+0xa920d6] ContinuationWrapper::ContinuationWrapper(oop)+0x1e6 (accessBackend.hpp:447) V [libjvm.so+0xa8cce1] Continuation::top_frame(frame const&, RegisterMap*)+0x161 (continuation.cpp:182) V [libjvm.so+0x84784e] frame::sender_for_compiled_frame(RegisterMap*) const+0x9e (frame_x86.inline.hpp:421) V [libjvm.so+0xf9f9d0] JfrVframeStream::next_vframe()+0x550 (frame_x86.inline.hpp:373) V [libjvm.so+0xf096b7] JfrAsyncStackTrace::record_async(JavaThread*, frame const&)+0x127 (jfrAsyncStackTrace.cpp:92) V [libjvm.so+0xf0c038] JfrCPUTimeThreadSampler::handle_timer_signal(void*)+0x498 (jfrCPUTimeThreadSampler.cpp:211) V [libjvm.so+0xf0c14f] handle_timer_signal(int, siginfo*, void*)+0x4f (jfrCPUTimeThreadSampler.cpp:704) C [libpthread.so.0+0x12d70] V [libjvm.so+0x1479ed6] Mutex::lock(Thread*)+0x86 (mutex.cpp:125) V [libjvm.so+0x11e003d] JvmtiExport::cleanup_thread(JavaThread*)+0x3d (mutexLocker.hpp:213) V [libjvm.so+0x1228e9a] JvmtiVTMSTransitionDisabler::VTMS_vthread_end(_jobject*)+0x7a (jvmtiThreadState.cpp:607) V [libjvm.so+0x1041ae4] JVM_VirtualThreadEnd+0xc4 (jvm.cpp:3902) J 2261 java.lang.VirtualThread.notifyJvmtiEnd()V java.base at 24-internal (0 bytes) @ 0x00007f87e03c2c30 [0x00007f87e03c2ba0+0x0000000000000090] J 2476 c1 java.lang.VirtualThread$VThreadContinuation$1.run()V java.base at 24-internal (39 bytes) @ 0x00007f87d8ab61fc [0x00007f87d8ab60c0+0x000000000000013c] J 143 jdk.internal.vm.Continuation.enterSpecial(Ljdk/internal/vm/Continuation;ZZ)V java.base at 24-internal (0 bytes) @ 0x00007f87e02e95b3 [0x00007f87e02e9440+0x0000000000000173] J 2358 c1 jdk.internal.vm.Continuation.run()V java.base at 24-internal (586 bytes) @ 0x00007f87d8a8eb54 [0x00007f87d8a8e860+0x00000000000002f4] J 2717 c2 java.lang.VirtualThread.runContinuation()V java.base at 24-internal (132 bytes) @ 0x00007f87e0412ffc [0x00007f87e0412dc0+0x000000000000023c] J 2403 c2 java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Ljava/util/concurrent/ForkJoinTask;I)V java.base at 24-internal (34 bytes) @ 0x00007f87e03d84a4 [0x00007f87e03d82e0+0x00000000000001c4] j java.util.concurrent.ForkJoinPool.runWorker(Ljava/util/concurrent/ForkJoinPool$WorkQueue;)V+366 java.base at 24-internal j java.util.concurrent.ForkJoinWorkerThread.run()V+31 java.base at 24-internal v ~StubRoutines::call_stub 0x00007f87dfd49d01 V [libjvm.so+0xec524c] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x48c (javaCalls.cpp:421) V [libjvm.so+0xec5943] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x373 (javaCalls.cpp:329) V [libjvm.so+0xec5e46] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x76 (javaCalls.cpp:191) V [libjvm.so+0x103d943] thread_entry(JavaThread*, JavaThread*)+0x93 (jvm.cpp:2911) V [libjvm.so+0xefc36c] JavaThread::thread_main_inner()+0xcc (javaThread.cpp:759) V [libjvm.so+0x1836206] Thread::call_run()+0xb6 (thread.cpp:234) V [libjvm.so+0x15145a8] thread_native_entry(Thread*)+0x128 (os_linux.cpp:858) Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J 2261 java.lang.VirtualThread.notifyJvmtiEnd()V java.base at 24-internal (0 bytes) @ 0x00007f87e03c2bfe [0x00007f87e03c2ba0+0x000000000000005e] J 2476 c1 java.lang.VirtualThread$VThreadContinuation$1.run()V java.base at 24-internal (39 bytes) @ 0x00007f87d8ab61fc [0x00007f87d8ab60c0+0x000000000000013c] J 143 jdk.internal.vm.Continuation.enterSpecial(Ljdk/internal/vm/Continuation;ZZ)V java.base at 24-internal (0 bytes) @ 0x00007f87e02e95b3 [0x00007f87e02e9440+0x0000000000000173] J 2358 c1 jdk.internal.vm.Continuation.run()V java.base at 24-internal (586 bytes) @ 0x00007f87d8a8eb54 [0x00007f87d8a8e860+0x00000000000002f4] J 2717 c2 java.lang.VirtualThread.runContinuation()V java.base at 24-internal (132 bytes) @ 0x00007f87e0412ffc [0x00007f87e0412dc0+0x000000000000023c] J 2403 c2 java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Ljava/util/concurrent/ForkJoinTask;I)V java.base at 24-internal (34 bytes) @ 0x00007f87e03d84a4 [0x00007f87e03d82e0+0x00000000000001c4] j java.util.concurrent.ForkJoinPool.runWorker(Ljava/util/concurrent/ForkJoinPool$WorkQueue;)V+366 java.base at 24-internal j java.util.concurrent.ForkJoinWorkerThread.run()V+31 java.base at 24-internal v ~StubRoutines::call_stub 0x00007f87dfd49d01 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2464275393 From mgronlun at openjdk.org Fri Nov 8 10:02:37 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 8 Nov 2024 10:02:37 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v17] In-Reply-To: <8gpM6lOT_ncKkCtMDNlwzkC89K-uxWcvzmkv5xxTeaA=.e97688f7-8c2d-4d8a-8e0b-b467d1de9c0d@github.com> References: <8gpM6lOT_ncKkCtMDNlwzkC89K-uxWcvzmkv5xxTeaA=.e97688f7-8c2d-4d8a-8e0b-b467d1de9c0d@github.com> Message-ID: On Thu, 7 Nov 2024 15:11:00 GMT, Johannes Bechberger wrote: >> This is the code for the [JEP draft: CPU Time based profiling for JFR]. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Don't treat stackTrace attribute specially for CPUTimeSamples A fatal error has been detected by the Java Runtime Environment: Internal Error (open/src/hotspot/share/runtime/handles.inline.hpp:89), pid=2248310, tid=2248368 assert(_area->size_in_bytes() > size_in_bytes()) failed: Sanity check Retrying call stack printing without source information... Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xc58290] HandleMark::~HandleMark()+0x110 (handles.inline.hpp:89) V [libjvm.so+0xd5cf5c] JfrAsyncStackTrace::record_async(JavaThread*, frame const&)+0x22c V [libjvm.so+0xd5fa34] JfrCPUTimeThreadSampler::handle_timer_signal(void*)+0x480 V [libjvm.so+0xd5fbb8] handle_timer_signal(int, siginfo_t*, void*)+0x68 C [linux-vdso.so.1+0x8dc] __kernel_rt_sigreturn+0x0 V [libjvm.so+0x15e64f4] ThreadCritical::~ThreadCritical()+0x44 V [libjvm.so+0x588c34] Chunk::chop(Chunk*)+0x124 V [libjvm.so+0x588cb4] Chunk::next_chop(Chunk*)+0x34 V [libjvm.so+0x70567c] HandleMark::pop_and_restore()+0x4c V [libjvm.so+0xe85b18] JVM_FillInStackTrace+0xb8 C [libjava.so+0x13ee4] Java_java_lang_Throwable_fillInStackTrace+0x14 J 930 java.lang.Throwable.fillInStackTrace(I)Ljava/lang/Throwable; java.base at 24-internal (0 bytes) @ 0x0000ffff9c3031a0 [0x0000ffff9c303100+0x00000000000000a0] J 9195 c2 java.lang.ClassNotFoundException.(Ljava/lang/String;)V java.base at 24-internal (7 bytes) @ 0x0000ffff9c6f6b9c [0x0000ffff9c6f6980+0x000000000000021c] J 3193 c2 jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class; java.base at 24-internal (40 bytes) @ 0x0000ffff9c418f58 [0x0000ffff9c418e80+0x00000000000000d8] j java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+38 java.base at 24-internal j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 java.base at 24-internal v ~StubRoutines::call_stub 0x0000ffff9bd2d190 V [libjvm.so+0xd19ab4] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x444 V [libjvm.so+0xd1a150] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x2c0 V [libjvm.so+0xd1a6b8] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Handle, JavaThread*)+0x74 V [libjvm.so+0x1598550] SystemDictionary::load_instance_class_impl(Symbol*, Handle, JavaThread*)+0x15c V [libjvm.so+0x1596614] SystemDictionary::load_instance_class(Symbol*, Handle, JavaThread*)+0x24 V [libjvm.so+0x1596e48] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, JavaThread*)+0x6a8 V [libjvm.so+0x1597a84] SystemDictionary::resolve_with_circularity_detection(Symbol*, Symbol*, Handle, Handle, bool, JavaThread*)+0x2f4 V [libjvm.so+0x83658c] ClassFileParser::parse_interfaces(ClassFileStream const*, int, ConstantPool*, bool*, JavaThread*)+0x32c V [libjvm.so+0x842234] ClassFileParser::parse_stream(ClassFileStream const*, JavaThread*)+0x834 V [libjvm.so+0x842780] ClassFileParser::ClassFileParser(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const*, ClassFileParser::Publicity, JavaThread*)+0x1a0 V [libjvm.so+0x106f4b8] KlassFactory::create_from_stream(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const&, JavaThread*)+0xc4 V [libjvm.so+0x1596400] SystemDictionary::resolve_class_from_stream(ClassFileStream*, Symbol*, Handle, ClassLoadInfo const&, JavaThread*)+0xa0 V [libjvm.so+0xe9d9d0] jvm_define_class_common(char const*, _jobject*, signed char const*, int, _jobject*, char const*, JavaThread*)+0x230 V [libjvm.so+0xe9dc28] JVM_DefineClassWithSource+0xa4 C [libjava.so+0xeb98] Java_java_lang_ClassLoader_defineClass1+0x118 J 8562 java.lang.ClassLoader.defineClass1(Ljava/lang/ClassLoader;Ljava/lang/String;[BIILjava/security/ProtectionDomain;Ljava/lang/String;)Ljava/lang/Class; java.base at 24-internal (0 bytes) @ 0x0000ffff9c375840 [0x0000ffff9c375740+0x0000000000000100] j java.lang.ClassLoader.defineClass(Ljava/lang/String;[BIILjava/security/ProtectionDomain;)Ljava/lang/Class;+27 java.base at 24-internal j java.security.SecureClassLoader.defineClass(Ljava/lang/String;[BIILjava/security/CodeSource;)Ljava/lang/Class;+12 java.base at 24-internal j java.net.URLClassLoader.defineClass(Ljava/lang/String;Ljdk/internal/loader/Resource;)Ljava/lang/Class;+220 java.base at 24-internal j java.net.URLClassLoader$1.run()Ljava/lang/Class;+43 java.base at 24-internal j java.net.URLClassLoader$1.run()Ljava/lang/Object;+1 java.base at 24-internal j java.security.AccessController.executePrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base at 24-internal j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+13 java.base at 24-internal j java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13 java.base at 24-internal j java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+69 java.base at 24-internal j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 java.base at 24-internal v ~StubRoutines::call_stub 0x0000ffff9bd2d190 V [libjvm.so+0xd19ab4] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x444 V [libjvm.so+0xd1a150] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x2c0 V [libjvm.so+0xd1a6b8] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Handle, JavaThread*)+0x74 V [libjvm.so+0x1598550] SystemDictionary::load_instance_class_impl(Symbol*, Handle, JavaThread*)+0x15c V [libjvm.so+0x1596614] SystemDictionary::load_instance_class(Symbol*, Handle, JavaThread*)+0x24 V [libjvm.so+0x1596e48] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, JavaThread*)+0x6a8 V [libjvm.so+0x1597a84] SystemDictionary::resolve_with_circularity_detection(Symbol*, Symbol*, Handle, Handle, bool, JavaThread*)+0x2f4 V [libjvm.so+0x83c1ac] ClassFileParser::post_process_parsed_stream(ClassFileStream const*, ConstantPool*, JavaThread*)+0x1cc V [libjvm.so+0x8428b0] ClassFileParser::ClassFileParser(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const*, ClassFileParser::Publicity, JavaThread*)+0x2d0 V [libjvm.so+0x106f4b8] KlassFactory::create_from_stream(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const&, JavaThread*)+0xc4 V [libjvm.so+0x1596400] SystemDictionary::resolve_class_from_stream(ClassFileStream*, Symbol*, Handle, ClassLoadInfo const&, JavaThread*)+0xa0 V [libjvm.so+0xe9d9d0] jvm_define_class_common(char const*, _jobject*, signed char const*, int, _jobject*, char const*, JavaThread*)+0x230 V [libjvm.so+0xe9dc28] JVM_DefineClassWithSource+0xa4 C [libjava.so+0xeb98] Java_java_lang_ClassLoader_defineClass1+0x118 J 8562 java.lang.ClassLoader.defineClass1(Ljava/lang/ClassLoader;Ljava/lang/String;[BIILjava/security/ProtectionDomain;Ljava/lang/String;)Ljava/lang/Class; java.base at 24-internal (0 bytes) @ 0x0000ffff9c375840 [0x0000ffff9c375740+0x0000000000000100] j java.lang.ClassLoader.defineClass(Ljava/lang/String;[BIILjava/security/ProtectionDomain;)Ljava/lang/Class;+27 java.base at 24-internal j java.security.SecureClassLoader.defineClass(Ljava/lang/String;[BIILjava/security/CodeSource;)Ljava/lang/Class;+12 java.base at 24-internal j java.net.URLClassLoader.defineClass(Ljava/lang/String;Ljdk/internal/loader/Resource;)Ljava/lang/Class;+220 java.base at 24-internal j java.net.URLClassLoader$1.run()Ljava/lang/Class;+43 java.base at 24-internal j java.net.URLClassLoader$1.run()Ljava/lang/Object;+1 java.base at 24-internal j java.security.AccessController.executePrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object;+29 java.base at 24-internal j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+13 java.base at 24-internal j java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13 java.base at 24-internal j java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+69 java.base at 24-internal j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3 java.base at 24-internal v ~StubRoutines::call_stub 0x0000ffff9bd2d190 V [libjvm.so+0xd19ab4] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x444 V [libjvm.so+0xd1a150] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x2c0 V [libjvm.so+0xd1a6b8] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Handle, JavaThread*)+0x74 V [libjvm.so+0x1598550] SystemDictionary::load_instance_class_impl(Symbol*, Handle, JavaThread*)+0x15c V [libjvm.so+0x1596614] SystemDictionary::load_instance_class(Symbol*, Handle, JavaThread*)+0x24 V [libjvm.so+0x1596e48] SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, JavaThread*)+0x6a8 V [libjvm.so+0x1597a84] SystemDictionary::resolve_with_circularity_detection(Symbol*, Symbol*, Handle, Handle, bool, JavaThread*)+0x2f4 V [libjvm.so+0x83c1ac] ClassFileParser::post_process_parsed_stream(ClassFileStream const*, ConstantPool*, JavaThread*)+0x1cc V [libjvm.so+0x8428b0] ClassFileParser::ClassFileParser(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const*, ClassFileParser::Publicity, JavaThread*)+0x2d0 V [libjvm.so+0x106f4b8] KlassFactory::create_from_stream(ClassFileStream*, Symbol*, ClassLoaderData*, ClassLoadInfo const&, JavaThread*)+0xc4 V [libjvm.so+0x1596400] SystemDictionary::resolve_class_from_stream(ClassFileStream*, Symbol*, Handle, ClassLoadInfo const&, JavaThread*)+0xa0 V [libjvm.so+0xe9d9d0] jvm_define_class_common(char const*, _jobject*, signed char const*, int, _jobject*, char const*, JavaThread*)+0x230 V [libjvm.so+0xe9dc28] JVM_DefineClassWithSource+0xa4 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2464283831 From duke at openjdk.org Fri Nov 8 10:09:23 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Fri, 8 Nov 2024 10:09:23 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v2] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 14:56:10 GMT, Johan Sj?len wrote: >> theoweidmannoracle 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 'openjdk:master' into JDK-8342860 >> - Fix copyright year >> - 8342860: Fix more NULL usage backsliding > > Thank you, these changes looks good to me. @jdksjolen @TheShermanTanker It would be great if you could also take another look at the latest changes I made. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21826#issuecomment-2464298298 From shade at openjdk.org Fri Nov 8 10:09:26 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 8 Nov 2024 10:09:26 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> Message-ID: On Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove FIXME > > I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO. > @shipilev Could you consider accepting the existing `__stdcall` changes in this PR? That seems like the easiest way out of satisfying everyones opinions here.. Sure, fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2464299781 From shade at openjdk.org Fri Nov 8 10:17:19 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 8 Nov 2024 10:17:19 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 6 Nov 2024 15:21:10 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Remove FIXME Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2423300933 From jwaters at openjdk.org Fri Nov 8 10:30:21 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 8 Nov 2024 10:30:21 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v3] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 08:32:16 GMT, theoweidmannoracle wrote: >> - Changed several "NULL" in comments to "null" >> - Changed several `NULL` in code to `nullptr` > > theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: > > Fix backslides in test Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21826#pullrequestreview-2423332121 From azafari at openjdk.org Fri Nov 8 10:51:27 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 8 Nov 2024 10:51:27 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree Message-ID: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. - Adding a runtime flag for selecting the old or new version can be added later. - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. ------------- Commit messages: - added some descriptions of how VMT works. - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - fixes after merge with use_tag_inplace - fixed merged glitches. - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - snaphot thread stack updated and tested. - removed unnecessary line from visit committed region function. - fixed hpp gaurd of vmtCommon. - Johan's feedback. - ... and 33 more: https://git.openjdk.org/jdk/compare/ac82a8f8...1e4fbf21 Changes: https://git.openjdk.org/jdk/pull/20425/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337217 Stats: 3294 lines in 55 files changed: 1520 ins; 1525 del; 249 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From jsjolen at openjdk.org Fri Nov 8 10:51:33 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 8 Nov 2024 10:51:33 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 1 Aug 2024 15:44:32 GMT, Afshin Zafari wrote: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. > - Adding a runtime flag for selecting the old or new version can be added later. > - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. Hi, Great work! I'm slowly working through the code, let's take our time with this. My PR got too stressful for everyone involved :-/. I've reviewed some of the code. Could you go a bit more in-depth on what the results of this work was? Did it improve performance, for example? >All tier1 tests pass except one that expects a 50% increase in committed memory *but it does not happen*. ~~I don't understand what this means, could you expand on this?~~ Edit: Re-read it again now and I get it, which test is this? Thanks! Changes requested by jsjolen (Reviewer). Changes requested by jsjolen (Reviewer). This code generally over-uses pointers. Please have a go through this code and change to references when applicable. Another round of review comments :). What is the consensus on having two implementations alive at the same time? I'd like to see us delete the old VirtualMemoryTracker and only have the tree implementation left as part of this PR. What is the status of our testing? Is the tree version equivalent now and passes all tests? I'd also like to see the tty printing code to either be deleted or if it's useful for mainline be adjusted so that it is using UL instead. Some more reviews here along with some questions. I see that you've merged in my PR 8340103. That's good, let's wait until that PR is integrated before this is integrated. > Is there a concrete advantage here for using lambda expression when iterating committed regions? I'm asking because personally I find > > ```c++ > while ((committed_rgn = itr.next()) != nullptr) { > print_committed_rgn(committed_rgn); > } > ``` > > simpler and more compact, hence easier to understand, than > > ```c++ > CommittedMemoryRegion cmr; > VirtualMemoryTrackerWithTree::tree()->visit_committed_regions(reserved_rgn, &cmr, [&](CommittedMemoryRegion* crgn) { > print_committed_rgn(crgn); > return true; > }); > ``` Hi Gerard, I'm the one who prefers passing in a lambda and introduced that style, sorry :-). First off, I think the lambda code should be simplified, it should be: ```c++ VMWT::tree().visit_committed_regions_of(*reserved_rgn, [](const CommittedMemoryRegion& crgn) { print_committed_region(crgn)); return true; }); I don't think that's too bad, right? The `return true` is a bit unfortunate. It's for being able to stop early, which I agree that regular iterators do better by just performing a `break;`. I'll go ahead and say one nice thing too: If the body of the lambda is a bit more complicated, then we can look at the capture list (the `[]` above) to see what the lambda can alter in the outside scope. With a while-loop, you really have to read the whole thing. **The reason** that I write these kinds of iterators is that they're much simpler to implement and maintain and, *to me*, STL-style iterators aren't easier to read, it's about the same level of complexity. I'll admit that your style of iterators (which are *not* STL) is about the same complexity, though I find it unfortunate that we have to write an entire class for each iterator. With the simplifications I made, is this style of iterator acceptable? It seems like there's a bug with the virtual memory walker. Essentially, the thread stack walker extends the reserved memory region that's passed in, but we don't save the results of that addition. This is missed because the `SnapshotThreadStackWalker` casts away the `const` of the `const ReservedMemoryRegion*`. ```c++ // All code is in vmtCommon.cpp void VirtualMemoryTracker::Instance::snapshot_thread_stacks() { SnapshotThreadStackWalker walker; walk_virtual_memory(&walker); } // ... while (itr.next_committed(committed_start, committed_size)) { assert(committed_start != nullptr, "Should not be null"); assert(committed_size > 0, "Should not be 0"); // unaligned stack_size case: correct the region to fit the actual stack_size if (stack_bottom + stack_size < committed_start + committed_size) { committed_size = stack_bottom + stack_size - committed_start; } region->add_committed_region(committed_start, committed_size, ncs); // <-- LOST! DEBUG_ONLY(found_stack = true;) } This particular walker should probably be re-written to only use the `VMATree` facilities. Note that we can't do the insertion in the iteration loop, as our iterator will be invalidated. They must be accumulated first, and then inserted all at once. Is this part of the code under-tested as we didn't receive a test failure regarding this? src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp line 262: > 260: vm_exit_out_of_memory(word_size * BytesPerWord, OOM_MMAP_ERROR, "Failed to reserve memory for metaspace"); > 261: } > 262: assert(rs.size() == word_size * BytesPerWord, " must be"); " must be" -> "must be" src/hotspot/share/nmt/memReporter.cpp line 442: > 440: if (all_committed) { > 441: bool reserved_and_committed = false; > 442: VirtualMemoryTracker::Instance::tree()->visit_committed_regions(*reserved_rgn, Change the signature of `visit_committed_regions` to taking `(position start, size size)` instead of the `ReservedMemoryRegion`. src/hotspot/share/nmt/memReporter.cpp line 458: > 456: } > 457: > 458: auto print_committed_rgn = [&](CommittedMemoryRegion* crgn) { `crgn` can be const reference instead of pointer. src/hotspot/share/nmt/memTracker.hpp line 291: > 289: // Query lock > 290: static Mutex* _query_lock; > 291: Remove src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp line 93: > 91: > 92: const inline NativeCallStack& get(StackIndex si) { > 93: if (is_invalid(si) || si >= _stacks.length()) { I don't think this should be here? src/hotspot/share/nmt/regionsTree.cpp line 33: > 31: log_debug(nmt)("trc base: " INTPTR_FORMAT " , trc end: " INTPTR_FORMAT, > 32: p2i(region_in_tree.base()), p2i(region_in_tree.end())); > 33: } Remove `with_trace` and improve the logging message. This should log unconditionally, probably under a `(nmt,vmtracker)` tagset. src/hotspot/share/nmt/regionsTree.cpp line 50: > 48: ReservedMemoryRegion rgn = find_reserved_region(addr); > 49: return reserve_mapping((VMATree::position)addr, size, make_region_data(NativeCallStack::empty_stack(), rgn.mem_tag())); > 50: } Can now be fixed. src/hotspot/share/nmt/regionsTree.cpp line 52: > 50: rgn = find_reserved_region(addr, true); > 51: ShouldNotReachHere(); > 52: } TODO: Remove this when 8335091 is merged src/hotspot/share/nmt/regionsTree.cpp line 54: > 52: } > 53: return commit_mapping((VMATree::position)addr, size, make_region_data(stack, rgn.flag())); > 54: Style: Extra space src/hotspot/share/nmt/regionsTree.cpp line 64: > 62: rgn = find_reserved_region(addr, true); > 63: ShouldNotReachHere(); > 64: } TODO: Remove this when https://github.com/openjdk/jdk/commit/8335091a5dd9a0654d9a616addcfdcc1863747ca is merged src/hotspot/share/nmt/regionsTree.hpp line 31: > 29: #include "nmt/vmatree.hpp" > 30: > 31: class RegionsTree : public VMATree { Is it necessary for this to be a superclass? Seems like this class contains utilities for working with a `VMATree`. Could it instead be `AllStatic` and take a tree as its first argument? I'd like to avoid inheritance unless necessary (typically for the usage of virtual functions). src/hotspot/share/nmt/regionsTree.hpp line 33: > 31: class RegionsTree : public VMATree { > 32: private: > 33: NativeCallStackStorage* _ncs_storage; No need for this to be a pointer. src/hotspot/share/nmt/regionsTree.hpp line 38: > 36: public: > 37: RegionsTree(bool with_storage) : VMATree() , _ncs_storage(with_storage) { } > 38: Whitespace src/hotspot/share/nmt/regionsTree.hpp line 46: > 44: using Node = VMATree::TreapNode; > 45: > 46: class NodeHelper : public Node { This shouldn't inherit from `Node` and then have each instance be cast into `NodeHelper`. Make into `class Utils : public AllStatic`. src/hotspot/share/nmt/regionsTree.hpp line 47: > 45: > 46: class NodeHelper { > 47: Node *_node; Style: `*` should hug type, not name. src/hotspot/share/nmt/regionsTree.hpp line 50: > 48: inline bool is_before(VMATree::position addr) { return VMATree::PositionComparator::cmp(key(), addr) < 0; } > 49: inline bool is_after(VMATree::position addr) { return VMATree::PositionComparator::cmp(key(), addr) > 0; } > 50: inline bool is_region_begin() { return is_reserved_begin()|| is_committed_begin(); } Not used? src/hotspot/share/nmt/regionsTree.hpp line 52: > 50: inline bool is_region_begin() { return is_reserved_begin()|| is_committed_begin(); } > 51: inline bool is_region_end(NodeHelper* node) { return is_released_begin() || (node != nullptr && node->out_flag() != out_flag()); } > 52: inline bool is_end_only(NodeHelper* node) { return !is_region_begin() && is_region_end(node); } Only used for debugging? src/hotspot/share/nmt/regionsTree.hpp line 53: > 51: inline bool is_region_end(NodeHelper* node) { return is_released_begin() || (node != nullptr && node->out_flag() != out_flag()); } > 52: inline bool is_end_only(NodeHelper* node) { return !is_region_begin() && is_region_end(node); } > 53: inline bool is_joint(NodeHelper* node) { return is_region_begin() && is_region_end(node); } Only used for debugging? src/hotspot/share/nmt/regionsTree.hpp line 58: > 56: // inline bool is_region_end(NodeHelper* node) { return is_released_begin() || (node != nullptr && node->out_flag() != out_flag()); } > 57: // inline bool is_end_only(NodeHelper* node) { return !is_region_begin() && is_region_end(node); } > 58: // inline bool is_joint(NodeHelper* node) { return is_region_begin() && is_region_end(node); } No commented out code like this please. src/hotspot/share/nmt/regionsTree.hpp line 61: > 59: inline VMATree::StateType out_state() { return val().out.type(); } > 60: inline size_t distance_from(NodeHelper* other) { return key() - other->key(); } > 61: inline const NativeCallStack& stack(NativeCallStackStorage* ncss) { return ncss->get(val().in.stack()); } Remove this src/hotspot/share/nmt/regionsTree.hpp line 66: > 64: inline VMATree::StateType out_state() { return _node->val().out.type(); } > 65: inline size_t distance_from(NodeHelper& other) { return position() - other.position(); } > 66: inline const NativeCallStackStorage::StackIndex out_stack_index() { return _node->val().out.stack(); } Unnecessary const in return type. src/hotspot/share/nmt/regionsTree.hpp line 71: > 69: inline void set_in_flag(MEMFLAGS flag) { _node->val().in.set_flag(flag); } > 70: inline void set_out_flag(MEMFLAGS flag) { _node->val().out.set_flag(flag); } > 71: inline void dump(outputStream* st) { `dump` is typically called `print_on` in HotSpot. src/hotspot/share/nmt/regionsTree.hpp line 91: > 89: > 90: template // F == bool(*)(CommittedMemoryRegion*) > 91: void visit_committed_regions(const ReservedMemoryRegion* rgn, CommittedMemoryRegion* cmr, F func) { Why does it take the `ReservedMemoryRegion` as a pointer instead of a reference? There's no need to take a pointer to the `CommittedMemoryRegion`, just construct it in the function and pass it to `f`. src/hotspot/share/nmt/regionsTree.hpp line 91: > 89: template // F == bool(*)(CommittedMemoryRegion&) > 90: void visit_committed_regions(position start, size_t size, F func) { > 91: size_t end = start + size + 1; It's not clear to me why `+ 1` is needed. If we have a range `[start, size+start)`, will it be missed by `visit_range_in_order`? src/hotspot/share/nmt/regionsTree.hpp line 95: > 93: size_t end = (size_t)rgn->end(); > 94: size_t comm_size = 0; > 95: size_t base = (size_t)rgn->base(); Why casting these? src/hotspot/share/nmt/regionsTree.hpp line 108: > 106: CommittedMemoryRegion cmr((address)base, comm_size, st); > 107: comm_size = 0; > 108: prev.clear_node(); This is unneeded. src/hotspot/share/nmt/regionsTree.hpp line 140: > 138: if (r_size != rgn_size) { > 139: log_debug(nmt)("----------------- size differ, distance: " SIZE_FORMAT " size: " SIZE_FORMAT, r_size, rgn_size); > 140: } Not needed anymore? src/hotspot/share/nmt/regionsTree.hpp line 143: > 141: visit_in_order([&](Node* node) { > 142: NodeHelper* curr = (NodeHelper*)node; > 143: /* Delete src/hotspot/share/nmt/regionsTree.hpp line 172: > 170: inline const NativeCallStack stack(NodeHelper& node) { > 171: NativeCallStackStorage::StackIndex si = node.out_stack_index(); > 172: if (!si.is_invalid()) { Change check to `NativeCallStackStorage::is_invalid`. src/hotspot/share/nmt/virtualMemoryTrackerWithTree.cpp line 101: > 99: } > 100: > 101: void VirtualMemoryTrackerWithTree::apply_summary_diff(VMATree::SummaryDiff diff) { Applying a summary diff in the MemoryFileTracker is this: ```c++ for (int i = 0; i < mt_number_of_types; i++) { VirtualMemory* summary = file->_summary.by_type(NMTUtil::index_to_flag(i)); summary->reserve_memory(diff.flag[i].commit); summary->commit_memory(diff.flag[i].commit); } This is much simpler and doesn't require looking at signs and so on. src/hotspot/share/nmt/virtualMemoryTrackerWithTree.cpp line 109: > 107: return true; > 108: }); > 109: } TODO: This should be replaced with the implementation in 8340103 Will happen when that PR has been reviewed and integrated. src/hotspot/share/nmt/virtualMemoryTrackerWithTree.cpp line 115: > 113: " vms-committed: " SIZE_FORMAT, > 114: str, NMTUtil::flag_to_name(flag), r, c, reserved, committed); > 115: }; Move this up to before the loop. src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 34: > 32: #include "utilities/ostream.hpp" > 33: > 34: class VirtualMemoryTrackerWithTree : AllStatic { Can this class be redone to use the same pattern as `MemoryFileTracker` with an outer class that's not static and an inner class that's stack, storing an instance of the outer class? That makes testing the class by creating an instance of it possible, unlike our old tests. src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 41: > 39: VirtualMemoryTrackerWithTree(bool is_detailed_mode) : _tree(is_detailed_mode) { } > 40: > 41: bool add_reserved_region (address base_addr, size_t size, const NativeCallStack& stack, MEMFLAGS flag = mtNone); Style: Align open paren with other functions. src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 64: > 62: void apply_summary_diff(VMATree::SummaryDiff diff); > 63: RegionsTree* tree() { return &_tree; } > 64: class Instance : public AllStatic { Style: Newline to separate the new class to the getter above. src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 67: > 65: friend class VirtualMemoryTrackerTest; > 66: friend class CommittedVirtualMemoryTest; > 67: friend class ReservedMemoryRegion; Why is this necessary? src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 69: > 67: > 68: private: > 69: static RegionsTree* _tree; If you do the instance/static pattern then you can switch this into a regular member, no pointer necessary. src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 69: > 67: friend class ReservedMemoryRegion; > 68: > 69: private: Unnecessary, remove. src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 70: > 68: private: > 69: static RegionsTree* _tree; > 70: static NativeCallStackStorage* _ncs_storage; Doesn't seem like this is ever initialized? src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 77: > 75: > 76: static bool add_reserved_region (address base_addr, size_t size, const NativeCallStack& stack, MEMFLAGS flag = mtNone); > 77: Style: Extra space src/hotspot/share/nmt/vmatree.cpp line 33: > 31: > 32: const char* VMATree::statetype_strings[4] = { > 33: "released","reserved", "'only-committed", "committed", Extra quote in `"only-committed"`. Why is this new state required by the way? src/hotspot/share/nmt/vmatree.cpp line 36: > 34: }; > 35: > 36: void VMATree::put_if_absent(position A, position B, StateType state, const RegionData& region_data) { Unused. src/hotspot/share/nmt/vmatree.hpp line 40: > 38: // or from committed memory of a certain MEMFLAGS to committed memory of a different MEMFLAGS. > 39: // The set of points is stored in a balanced binary tree for efficient querying and updating. > 40: class VMATree : public AnyObj { Why is it AnyObj now? src/hotspot/share/nmt/vmatree.hpp line 41: > 39: // or from committed memory of a certain MemTag to committed memory of a different MemTag. > 40: // The set of points is stored in a balanced binary tree for efficient querying and updating. > 41: class VMATree : public CHeapObj { Is this still needed? src/hotspot/share/nmt/vmatree.hpp line 57: > 55: }; > 56: > 57: enum class StateType : uint8_t { Reserved = 1, Committed = 3, Released = 0, COUNT = 3 }; Why not the following? ```c++ enum class StateType : uint8_t { Released, Reserved, Committed, COUNT }; If this particular ordering is necessary then it should be documented why. src/hotspot/share/nmt/vmatree.hpp line 59: > 57: // Bit fields view: bit 0 for Reserved, bit 1 for Committed. > 58: // Setting a region as Committed preserves the Reserved state. > 59: enum class StateType : uint8_t { Reserved = 1, Committed = 3, Released = 0, COUNT = 4 }; Why do we now consider `StateType` to be a bit field? src/hotspot/share/nmt/vmatree.hpp line 234: > 232: } > 233: > 234: void put_if_absent(position A, position B, StateType state, const RegionData& region_data); Not used. src/hotspot/share/nmt/vmtCommon.cpp line 1: > 1: /* Is this all of the code that is still required by the reporter to be able to function? src/hotspot/share/nmt/vmtCommon.hpp line 40: > 38: > 39: > 40: A lot of excessive spaces. src/java.base/share/classes/java/lang/String.java line 2990: > 2988: return this; > 2989: } > 2990: return StringConcatHelper.doConcat(this, str == null ? "null" : str); Remove test/hotspot/gtest/nmt/test_nmt_treap.cpp line 168: > 166: tty->print_cr("d1: %lf, d2: %lf, d2/d1: %lf", d1, d2, d2 / d1); > 167: EXPECT_LT((int)(d2 / d1), N2 / N1); > 168: } 1000 and 10_000 elements are both quite small, isn't one measurement prone to being slower than expected due to unforeseen circumstances? For example, if `malloc` performs a heavy allocation (by mapping in a few new pages) during the 10_000 elements insertion then that may stall enough that the `EXPECT_LT` fails. We are also bound to only performing the test once. Is your thinking that these perf tests should be kept in, or should they be removed before integrating? test/hotspot/gtest/nmt/test_vmatree.cpp line 368: > 366: } > 367: > 368: TEST_VM_F(NMTVMATreeTest, SummaryAccounting_dup) { Better name for the test, please avoid underscores in test names. I know, we have underscores in places in Hotspot, but it's a good rule for GTest naming. test/hotspot/jtreg/runtime/NMT/VirtualAllocCommitMerge.java line 123: > 121: checkCommitted(output, addrC, commitSize, "128KB"); > 122: checkCommitted(output, addrE, commitSize, "128KB"); > 123: System.out.println(output.getStdout()); Shouldn't be here? ------------- PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2214987478 PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2216996817 PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2218354564 PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2229844713 PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2309488897 PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2330835910 PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2363917957 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2277599150 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2410656300 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1776822998 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797708571 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797709609 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797709829 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1776830627 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797710529 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1802524769 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763180620 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763179219 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763181328 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1702620226 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1702613618 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797710838 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711201076 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763121326 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711202054 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711202833 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711203437 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763122189 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711204473 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763087825 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763114280 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711194217 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1803020903 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711195818 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797710967 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797711165 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711102998 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763084724 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1701512262 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763130736 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1701507820 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1702621499 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763078198 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763079618 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763080836 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703756244 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763081303 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1702615789 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763078450 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797711711 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797711641 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1701493261 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797711401 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703759119 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763128004 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797711940 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797712152 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797712349 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1701486398 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1701503355 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1701513351 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797712911 From azafari at openjdk.org Fri Nov 8 10:51:33 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 8 Nov 2024 10:51:33 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 1 Aug 2024 15:44:32 GMT, Afshin Zafari wrote: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. > - Adding a runtime flag for selecting the old or new version can be added later. > - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. Thanks for your comments. They are replied or applied. More fixes and questions. Review comments applied. The comments are applied. Performance test runs insert/remove operations for SortedLinkList (SLL in the code) and Treap and expects that Treap be faster. Both tests pass with a factor of 70+ faster for 10000 elements. Dear reviewers in recent commit the following can be considered: ### Changes made to the code - Instance/Static implemented. - Using of Reference instead of pointers, as much as possible. - Removed extra un-needed args from functions - `NodeHelper` is implemented using composition approach. - Non-used methods are removed from `NodeHelper` ### Still open conversations from previous reviews - Two alternatives for implementing `apply_summary_diff` - Is readability improved after latest changes? - Are `lambda` usages acceptable now? Any improvement suggestion? - Which pointers still remained to be replaced by references? GHA failures are for some tests that have already a related JBS issue, not for this PR. > ```c++ > region->add_committed_region(committed_start, committed_size, ncs); // <-- LOST! > ``` The `region` is not a VMATree::node, it is a `ReservedMemoryRegion*`. Dear @tstuefe, this PR has been reviewed couple of rounds. Would you please, give your feedback? Thanks. ------------- PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2217791061 PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2219547262 PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2333278135 PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2365877947 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2273208292 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2283953888 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2380017488 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2410734124 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2462154991 From gziemski at openjdk.org Fri Nov 8 10:51:37 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Fri, 8 Nov 2024 10:51:37 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 1 Aug 2024 15:44:32 GMT, Afshin Zafari wrote: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. > - Adding a runtime flag for selecting the old or new version can be added later. > - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. Changes requested by gziemski (Reviewer). Changes requested by gziemski (Reviewer). More review feedback... Changes requested by gziemski (Reviewer). Are we keeping both the linked list based and VMATree based implementations just for the review process, and we will drop the linked list one, once we are done with the review, or are they both going to be checked in? Is there a concrete advantage here for using lambda expression when iterating committed regions? I'm asking because personally I find while ((committed_rgn = itr.next()) != nullptr) { print_committed_rgn(committed_rgn); } simpler and more compact, hence easier to understand, than CommittedMemoryRegion cmr; VirtualMemoryTrackerWithTree::tree()->visit_committed_regions(reserved_rgn, &cmr, [&](CommittedMemoryRegion* crgn) { print_committed_rgn(crgn); return true; }); Same here: if (MemTracker::is_using_tree()) { CommittedMemoryRegion cmr; bool reserved_and_committed = false; VirtualMemoryTrackerWithTree::tree()->visit_committed_regions(reserved_rgn, &cmr, [&](CommittedMemoryRegion* committed_rgn) { if (committed_rgn->size() == reserved_rgn->size() && committed_rgn->call_stack()->equals(*stack)) { // One region spanning the entire reserved region, with the same stack trace. // Don't print this regions because the "reserved and committed" line above // already indicates that the region is committed. reserved_and_committed = true; return false; } return true; }); if (reserved_and_committed) return; } } We are setting `reserved_and_committed` inside lambda, then we need to check it outside. It's messy and harder to follow which `return` belongs to which context. > > Is there a concrete advantage here for using lambda expression when iterating committed regions? I'm asking because personally I find > > ```c++ > > while ((committed_rgn = itr.next()) != nullptr) { > > print_committed_rgn(committed_rgn); > > } > > ``` > > > > > > > > > > > > > > > > > > > > > > > > simpler and more compact, hence easier to understand, than > > ```c++ > > CommittedMemoryRegion cmr; > > VirtualMemoryTrackerWithTree::tree()->visit_committed_regions(reserved_rgn, &cmr, [&](CommittedMemoryRegion* crgn) { > > print_committed_rgn(crgn); > > return true; > > }); > > ``` > > Hi Gerard, I'm the one who prefers passing in a lambda and introduced that style, sorry :-). > > First off, I think the lambda code should be simplified, it should be: > > ```c++ > VMWT::tree().visit_committed_regions_of(*reserved_rgn, [](const CommittedMemoryRegion& crgn) { > print_committed_region(crgn)); > return true; > }); > ``` > > I don't think that's too bad, right? The `return true` is a bit unfortunate. It's for being able to stop early, which I agree that regular iterators do better by just performing a `break;`. > > I'll go ahead and say one nice thing too: If the body of the lambda is a bit more complicated, then we can look at the capture list (the `[]` above) to see what the lambda can alter in the outside scope. With a while-loop, you really have to read the whole thing. > > **The reason** that I write these kinds of iterators is that they're much simpler to implement and maintain and, _to me_, STL-style iterators aren't easier to read, it's about the same level of complexity. > > I'll admit that your style of iterators (which are _not_ STL) is about the same complexity, though I find it unfortunate that we have to write an entire class for each iterator. > > With the simplifications I made, is this style of iterator acceptable? hi Johan, Yes, this does look better. I looked at https://www.geeksforgeeks.org/when-to-use-lambda-expressions-instead-of-functions-in-cpp to see when one should consider using lambda and I like one particular scenario - improving readability by implementing the code locally, so one can see exactly what is going on without having to look inside a function. I think this is our use case scenario here. If only we didn't need all those `return` statements, I'd have clearly preferred lambda here in fact. Is the plan to check-in the fix with both paths? Or are we going to remove the linked-list based one after the review? Did you consider using the single lambda in `report_virtual_memory_region()` as I suggested? outputStream* out = output(); const char* scale = current_scale(); auto print_rgn = [&](const VirtualMemoryRegion* rgn, const NativeCallStack* stack, MEMFLAGS mem_type = MEMFLAGS::mtNone, const char* region_type = "committed", bool committed = true) { // Don't report if size is too small if (amount_in_current_scale(rgn->size()) == 0) return; out->cr(); INDENT_BY(committed?8:0, print_virtual_memory_region(region_type, rgn->base(), rgn->size()); if (stack->is_empty()) { out->cr(); } else { if (!committed) { out->print(" for %s", NMTUtil::flag_to_name(mem_type)); } out->print_cr(" from "); INDENT_BY(4, _stackprinter.print_stack(stack);) } ) }; and then: bool all_committed = reserved_rgn->size() == reserved_rgn->committed_size(); const char* region_type = (all_committed ? "reserved and committed" : "reserved"); print_rgn(reserved_rgn, reserved_rgn->call_stack(), reserved_rgn->flag(), region_type, false); and if (MemTracker::is_using_sorted_link_list()) { CommittedRegionIterator itr = reserved_rgn->iterate_committed_regions(); CommittedMemoryRegion* crgn; while ((crgn = itr.next()) != nullptr) { print_rgn(crgn, crgn->call_stack()); } } if (MemTracker::is_using_tree()) { VirtualMemoryTrackerWithTree::Instance::tree()->visit_committed_regions(*reserved_rgn, [&](CommittedMemoryRegion& crgn) { print_rgn(&crgn, crgn.call_stack()); return true; }); } I honestly do not think we should be checking in 2 implementations, unless they are nicely hidden away. I do not like the way we manage them right now with 2 explicit `if` checks, each and every time we need to do something. If you could push the 2 implementations into a factory class, so that instead of: if (is_using_sorted_link_list()) VirtualMemoryTracker::snapshot_thread_stacks(); if (is_using_tree()) VirtualMemoryTrackerWithTree::Instance::snapshot_thread_stacks(); we have just: ` VirtualMemoryTracker::snapshot_thread_stacks(); ` and VirtualMemoryTracker::VirtualMemoryTracker(bool useLinkedList) { if (useLinkedList) { instance = new VirtualMemoryTrackerWithLinkedList() } else { instance = new VirtualMemoryTrackerWithLinkedList() } } VirtualMemoryTracker::snapshot_thread_stacks() { instance.snapshot_thread_stacks(); } I still haven't run the benchmarks to verify the speed increase promise. Ideally, I would like to do this with my mechanism, but will only do it, if I can manage it without getting sucked into working on the mechanism itself. I will definitively want to run the provided microbenchmarks though. src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 279: > 277: "Cannot commit verification bitmap memory"); > 278: } > 279: MemTracker::record_virtual_memory_type(verify_bitmap.base(), verify_bitmap..size(), mtGC); Does this even compile? src/hotspot/share/nmt/memReporter.cpp line 440: > 438: if (all_committed) { > 439: if (MemTracker::is_using_sorted_link_list()) { > 440: CommittedRegionIterator itr = reserved_rgn->iterate_committed_regions(); Indentation. src/hotspot/share/nmt/memReporter.cpp line 467: > 465: > 466: if (reserved_and_committed) > 467: return; This looks better, but now that I got more comfortable with anonymous local functions using lambda, I think we can do better. We can write a single `print_rgn` lambda function that we can use in both "reserved" and "committed" cases: outputStream* out = output(); const char* scale = current_scale(); auto print_rgn = [&](const VirtualMemoryRegion* rgn, const NativeCallStack* stack, MEMFLAGS mem_type = MEMFLAGS::mtNone, const char* region_type = "committed", bool committed = true) { // Don't report if size is too small if (amount_in_current_scale(rgn->size()) == 0) return; out->cr(); INDENT_BY(committed?8:0, print_virtual_memory_region(region_type, rgn->base(), rgn->size()); if (stack->is_empty()) { out->cr(); } else { if (!committed) { out->print(" for %s", NMTUtil::flag_to_name(mem_type)); } out->print_cr(" from "); INDENT_BY(4, _stackprinter.print_stack(stack);) } ) }; src/hotspot/share/nmt/memReporter.cpp line 478: > 476: stack = committed_rgn->call_stack(); > 477: out->cr(); > 478: INDENT_BY(8, This entire section looks messy and in need of some cleanup. We have lines that are only relevant to one implementation not the other, used in both. We share `committed_rgn` name between common path and old impl, then use `crgn` in the new impl. May I suggest something like: auto print_committed_rgn = [&](CommittedMemoryRegion* crgn) { // Don't report if size is too small if (amount_in_current_scale(crgn->size()) == 0) return; stack = crgn->call_stack(); out->cr(); INDENT_BY(8, print_virtual_memory_region("committed", crgn->base(), crgn->size()); if (stack->is_empty()) { out->cr(); } else { out->print_cr(" from"); INDENT_BY(4, stack->print_on(out);) } ) }; if (MemTracker::is_using_sorted_link_list()) { CommittedRegionIterator itr = reserved_rgn->iterate_committed_regions(); CommittedMemoryRegion* crgn; while ((crgn = itr.next()) != nullptr) { print_committed_rgn(crgn); } } if (MemTracker::is_using_tree()) { CommittedMemoryRegion cmr; VirtualMemoryTrackerWithTree::tree()->visit_committed_regions(reserved_rgn, &cmr, [&](CommittedMemoryRegion* crgn) { print_committed_rgn(crgn); return true; }); } src/hotspot/share/nmt/memReporter.cpp line 482: > 480: } else { > 481: out->print_cr(" from"); > 482: INDENT_BY(4, stack->print_on(out);) Why aren't we using `_stackprinter` here to print, like in all the other places? ` INDENT_BY(4, _stackprinter.print_stack(stack);) ` src/hotspot/share/nmt/memTracker.hpp line 67: > 65: if (is_using_tree()) > 66: VirtualMemoryTrackerWithTree::Instance::snapshot_thread_stacks(); > 67: } I'd prefer to see just: static void snapshot_thread_stacks() { VirtualMemoryTracker::snapshot_thread_stacks(); } and: static void VirtualMemoryTracker::snapshot_thread_stacks() { if (is_using_sorted_link_list()) VirtualMemoryTrackerWithLinkedList::Instance::snapshot_thread_stacks(); if (is_using_tree()) VirtualMemoryTrackerWithTree::Instance::snapshot_thread_stacks(); } Basically hide the two implementations and then we don't need to expose them. All the APIs such as `is_using_tree()` would not need to be public, but just implementation detail. If we wanted to go one step further, we could create an instance of either one at the init time, then keep using that instance, instead of checking each time we want to do something. src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp line 94: > 92: if (si._stack_index < 0 || si._stack_index >= _stacks.length()) { > 93: return _fake_stack; > 94: } Is that a leftover from debugging? Shouldn't this be an `assert` in final code? src/hotspot/share/nmt/nmtTreap.hpp line 219: > 217: } > 218: last_seen = node; > 219: return true; Why are we returning a `bool` value in `void` function? src/hotspot/share/nmt/nmtTreap.hpp line 320: > 318: } > 319: head = to_visit.pop(); > 320: if(!f(head)) Needs space `if (!f(head))` src/hotspot/share/nmt/nmtTreap.hpp line 348: > 346: const int cmp_to = COMPARATOR::cmp(head->key(), to); > 347: if (cmp_from >= 0 && cmp_to < 0) { > 348: if(!f(head)) Needs space `if (!f(head))` src/hotspot/share/nmt/nmtTreap.hpp line 356: > 354: head = nullptr; > 355: } > 356: Remove. ------------- PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2228842744 PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2236512021 Changes requested by gziemski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2246166901 PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2331868978 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2276641131 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2276654335 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2276656880 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2278278886 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2307806504 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2316185120 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2377524395 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2377532616 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1777443492 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1710280816 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1717432884 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1710318264 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1715887989 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1722171034 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1722186507 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1777449328 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1722187617 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1722188013 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1722188713 From azafari at openjdk.org Fri Nov 8 10:51:38 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 8 Nov 2024 10:51:38 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Fri, 23 Aug 2024 21:02:25 GMT, Gerard Ziemski wrote: > Is the plan to check-in the fix with both paths? Or are we going to remove the linked-list based one after the review? The plan is to have both versions available at run-time. In this plan, we will add JVM options to let the user to select either of them. This can be used for: 1?? stepping back if new version fails in some use-cases, and also for 2?? running benchmarks and comparing the results of both. > I still haven't run the benchmarks to verify the speed increase promise. Ideally, I would like to do this with my mechanism, but will only do it, if I can manage it without getting sucked into working on the mechanism itself. > > I will definitively want to run the provided microbenchmarks though. In `test_vmt_with_tree.cpp`, two versions are compared. One of the tests (`PerformanceComparison`) is comparing the time they take for the same operation. This test is skipped for now, because its expectation of time-improvement fails. Until the time we still did not merge all other related changes (like the `copy_flag` or `use_tag_inplace`, [#20330](https://github.com/openjdk/jdk/pull/20330)) to this PR we cannot expect the time to be improved. > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 279: > >> 277: "Cannot commit verification bitmap memory"); >> 278: } >> 279: MemTracker::record_virtual_memory_type(verify_bitmap.base(), verify_bitmap..size(), mtGC); > > Does this even compile? No it doesn't, you're right. Shenandoah is not in the main build. I thought that GHA builds do this but seems not. Fixed. Thanks. > src/hotspot/share/nmt/memReporter.cpp line 440: > >> 438: if (all_committed) { >> 439: if (MemTracker::is_using_sorted_link_list()) { >> 440: CommittedRegionIterator itr = reserved_rgn->iterate_committed_regions(); > > Indentation. Done. > src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp line 94: > >> 92: if (si._stack_index < 0 || si._stack_index >= _stacks.length()) { >> 93: return _fake_stack; >> 94: } > > Is that a leftover from debugging? > > Shouldn't this be an `assert` in final code? You are right. Since the next lines check the `-1` as special case; this check should be either an `assert` or logged. I wait for @jdksjolen, as this is his code. > src/hotspot/share/nmt/nmtTreap.hpp line 219: > >> 217: } >> 218: last_seen = node; >> 219: return true; > > Why are we returning a `bool` value in `void` function? That is returning from the lambda function. In `visit_in_order(F func)`, when function `func` (in our case the lambda) returns `false` it means the iteration should stop. Otherwise, if it returns `true` it means to continue iterating. > src/hotspot/share/nmt/nmtTreap.hpp line 320: > >> 318: } >> 319: head = to_visit.pop(); >> 320: if(!f(head)) > > Needs space `if (!f(head))` Fixed. > src/hotspot/share/nmt/nmtTreap.hpp line 348: > >> 346: const int cmp_to = COMPARATOR::cmp(head->key(), to); >> 347: if (cmp_from >= 0 && cmp_to < 0) { >> 348: if(!f(head)) > > Needs space `if (!f(head))` Done. > src/hotspot/share/nmt/nmtTreap.hpp line 356: > >> 354: head = nullptr; >> 355: } >> 356: > > Remove. Done ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2309507439 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2378923225 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1778342931 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713348422 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1722829439 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1778361486 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1722821927 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1722822141 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1722822343 From jsjolen at openjdk.org Fri Nov 8 10:51:39 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 8 Nov 2024 10:51:39 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: <4mRy8kaaZMfKM3Tat40w_WxxjqLAoH5hJO_T0fZ5UTw=.d9c9ffc2-4d8a-496a-a9aa-ef8abe9412d4@github.com> On Fri, 9 Aug 2024 16:05:00 GMT, Gerard Ziemski wrote: > > > Is there a concrete advantage here for using lambda expression when iterating committed regions? I'm asking because personally I find > > > ```c++ > > > while ((committed_rgn = itr.next()) != nullptr) { > > > print_committed_rgn(committed_rgn); > > > } > > > ``` > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > simpler and more compact, hence easier to understand, than > > > ```c++ > > > CommittedMemoryRegion cmr; > > > VirtualMemoryTrackerWithTree::tree()->visit_committed_regions(reserved_rgn, &cmr, [&](CommittedMemoryRegion* crgn) { > > > print_committed_rgn(crgn); > > > return true; > > > }); > > > ``` > > > > > > Hi Gerard, I'm the one who prefers passing in a lambda and introduced that style, sorry :-). > > First off, I think the lambda code should be simplified, it should be: > > ```c++ > > VMWT::tree().visit_committed_regions_of(*reserved_rgn, [](const CommittedMemoryRegion& crgn) { > > print_committed_region(crgn)); > > return true; > > }); > > ``` > > > > > > > > > > > > > > > > > > > > > > > > I don't think that's too bad, right? The `return true` is a bit unfortunate. It's for being able to stop early, which I agree that regular iterators do better by just performing a `break;`. > > I'll go ahead and say one nice thing too: If the body of the lambda is a bit more complicated, then we can look at the capture list (the `[]` above) to see what the lambda can alter in the outside scope. With a while-loop, you really have to read the whole thing. > > **The reason** that I write these kinds of iterators is that they're much simpler to implement and maintain and, _to me_, STL-style iterators aren't easier to read, it's about the same level of complexity. > > I'll admit that your style of iterators (which are _not_ STL) is about the same complexity, though I find it unfortunate that we have to write an entire class for each iterator. > > With the simplifications I made, is this style of iterator acceptable? > > hi Johan, > > Yes, this does look better. I looked at https://www.geeksforgeeks.org/when-to-use-lambda-expressions-instead-of-functions-in-cpp to see when one should consider using lambda and I like one particular scenario - improving readability by implementing the code locally, so one can see exactly what is going on without having to look inside a function. I think this is our use case scenario here. > > If only we didn't need all those `return` statements, I'd have clearly preferred lambda here in fact. It's tedious to have to write `return true;` if you never `return false;` in the function. I looked into fixing this with some metaprogramming, and I found two C++14 solutions and one C++17 one. Here's the Godbolt: https://godbolt.org/z/xGzoGYhf8 And here's the code, reproduced for posterity: ```c++ #include #include // C++14 solution // Here we take extra runtime cost for the void returning function #define ENABLE_IF(...) \ std::enable_if_t = 0 template ::type>::value)> void iterate(std::vector& arr, F fun) { for (int i = 0; i < arr.size(); i++) { if (!fun(arr[i])) { return; } } } template::type>::value)> void iterate(std::vector& arr, F fun) { iterate(arr, [&fun](int& i) { fun(i); return true; }); } // C++17 solution, notice that this compiles two functions: one for when early_return is true and when for when it's not. /* template void iterate(std::vector& arr, F fun) { using ret_type = decltype(fun(arr[0])); // This doesn't actually execute fun(arr[0]); constexpr bool early_return = std::is_same::value; for (int i = 0; i < arr.size(); i++) { if constexpr (early_return) { if (!fun(arr[i])) { return; } } else { fun(arr[i]); } } } */ // C++14 solution // Here we have to make the two implementations ourselves. /* #define ENABLE_IF(...) \ std::enable_if_t = 0 template ::type>::value)> void iterate(std::vector& arr, F fun) { for (int i = 0; i < arr.size(); i++) { if (!fun(arr[i])) { return; } } } template::type>::value)> void iterate(std::vector& arr, F fun) { for (int i = 0; i < arr.size(); i++) { fun(arr[i]); } } */ int main() { std::vector my_array{0,1,2,3}; auto no_early = [](int& x) { std::cout << x << " "; }; auto early = [](int &x) { if (x == 2) return false; std::cout << x << " "; return true; }; iterate(my_array, no_early); std::cout << std::endl; iterate(my_array, early); std::cout << std::endl; } > I honestly do not think we should be checking in 2 implementations, unless they are nicely hidden away. I do not like the way we manage them right now with 2 explicit `if` checks, each and every time we need to do something. > > If you could push the 2 implementations into a factory class, so that instead of: > > ``` > if (is_using_sorted_link_list()) > VirtualMemoryTracker::snapshot_thread_stacks(); > if (is_using_tree()) > VirtualMemoryTrackerWithTree::Instance::snapshot_thread_stacks(); > ``` > > we have just: > > ` VirtualMemoryTracker::snapshot_thread_stacks();` and > > ``` > VirtualMemoryTracker::VirtualMemoryTracker(bool useLinkedList) { > if (useLinkedList) { > instance = new VirtualMemoryTrackerWithLinkedList() > } else { > instance = new VirtualMemoryTrackerWithLinkedList() > } > } > > VirtualMemoryTracker::snapshot_thread_stacks() { > instance.snapshot_thread_stacks(); > } > ``` >From reading the code, this might be a bit harder to do than preferred. We'd need some wrapping for the iterators, since they use two different styles. Wrapping the "old" iterators inside of the "new" style is possible of course. The fork for JDK-24 is on December 5th. That means that we have at most 8 weeks in the testing system to find and fix any bugs that we might have missed after integration. To me, that feels a bit short. Either we wait after the fork to integrate, or we integrate with two implementations and a `java` option for choosing implementation. I'm open to other opinions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2309938825 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2378890343 From gziemski at openjdk.org Fri Nov 8 10:51:40 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Fri, 8 Nov 2024 10:51:40 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: <6HDJgDRPF7OvsR5vV3FZQWph4M2wHd4mtueXuy1ldYw=.e34b1f2f-f1fe-44d9-9970-5ed8c9224aee@github.com> On Mon, 26 Aug 2024 07:16:39 GMT, Afshin Zafari wrote: > > Is the plan to check-in the fix with both paths? Or are we going to remove the linked-list based one after the review? > > The plan is to have both versions available at run-time. In this plan, we will add JVM options to let the user to select either of them. This can be used for: 1?? stepping back if new version fails in some use-cases, and also for 2?? running benchmarks and comparing the results of both. If we are going to keep the 2 versions for a while, then I would really, really like to see the two implementations as instances of `VirtualMemoryTrackerWithLinkedList` and `VirtualMemoryTrackerWithTree`, and have `VirtualMemoryTracker` be the single class we have the external code deal with, i.e. I think we can do better that: ``` static void snapshot_thread_stacks() { if (is_using_sorted_link_list()) VirtualMemoryTracker::snapshot_thread_stacks(); if (is_using_tree()) VirtualMemoryTrackerWithTree::Instance::snapshot_thread_stacks(); } > > I still haven't run the benchmarks to verify the speed increase promise. Ideally, I would like to do this with my mechanism, but will only do it, if I can manage it without getting sucked into working on the mechanism itself. > > I will definitively want to run the provided microbenchmarks though. > > In `test_vmt_with_tree.cpp`, two versions are compared. One of the tests (`PerformanceComparison`) is comparing the time they take for the same operation. This test is skipped for now, because its expectation of time-improvement fails. Until the time we still did not merge all other related changes (like the `copy_flag` or `use_tag_inplace`, [#20330](https://github.com/openjdk/jdk/pull/20330)) to this PR we cannot expect the time to be improved. Should we say then, that this is blocked by those 2 issues? Is it OK then if I wait till those get checked in before verifying the performance benefits if the new implementation? The performance was the main motivation here, correct? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2316167719 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2379647798 From gziemski at openjdk.org Fri Nov 8 10:51:40 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Fri, 8 Nov 2024 10:51:40 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: <4mRy8kaaZMfKM3Tat40w_WxxjqLAoH5hJO_T0fZ5UTw=.d9c9ffc2-4d8a-496a-a9aa-ef8abe9412d4@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <4mRy8kaaZMfKM3Tat40w_WxxjqLAoH5hJO_T0fZ5UTw=.d9c9ffc2-4d8a-496a-a9aa-ef8abe9412d4@github.com> Message-ID: On Mon, 26 Aug 2024 11:03:25 GMT, Johan Sj?len wrote: > It's tedious to have to write return true; if you never return false; in the function. I looked into fixing this with some metaprogramming, and I found two C++14 solutions and one C++17 one. Here's the Godbolt I'd like the lambdas without `return true` if possible, pretty please. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2316187388 From azafari at openjdk.org Fri Nov 8 10:51:42 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 8 Nov 2024 10:51:42 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 26 Sep 2024 10:58:31 GMT, Johan Sj?len wrote: > What is the consensus on having two implementations alive at the same time? I'd like to see us delete the old VirtualMemoryTracker and only have the tree implementation left as part of this PR. What is the status of our testing? Is the tree version equivalent now and passes all tests? > I have already told that the main reason to have 2 versions is to be able to switch back from new to old version at customer site at runtime. This is what Thomas has requested. During the implementation, it is much beneficial to have access to the old version to compare the results and debug problems when they occur. Until the whole port to VMATree is not done, we need this 2 versions side-by-side feature. > That's good, let's wait until that PR is integrated before this is integrated. Sure, I do. > Is this part of the code under-tested as we didn't receive a test failure regarding this? All JTREG runtime/NMT tests and all tier1 tests have been passed on this code. > Note that we can't do the insertion in the iteration loop, as our iterator will be invalidated. I meant that the iterator is not going through the nodes in VMATree. And the `add_committeed_region` is called on a local `ReservedMemoryRegion*`. Anyway, I agree to rewrite this for many more reasons than above, but not sure how. The required change was deferred for a later time when we started new VMT. Should think about it. > src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp line 262: > >> 260: vm_exit_out_of_memory(word_size * BytesPerWord, OOM_MMAP_ERROR, "Failed to reserve memory for metaspace"); >> 261: } >> 262: assert(rs.size() == word_size * BytesPerWord, " must be"); > > " must be" -> "must be" Done > src/hotspot/share/nmt/memReporter.cpp line 442: > >> 440: if (all_committed) { >> 441: bool reserved_and_committed = false; >> 442: VirtualMemoryTracker::Instance::tree()->visit_committed_regions(*reserved_rgn, > > Change the signature of `visit_committed_regions` to taking `(position start, size size)` instead of the `ReservedMemoryRegion`. Done. > src/hotspot/share/nmt/memReporter.cpp line 458: > >> 456: } >> 457: >> 458: auto print_committed_rgn = [&](CommittedMemoryRegion* crgn) { > > `crgn` can be const reference instead of pointer. Done. > src/hotspot/share/nmt/memTracker.hpp line 291: > >> 289: // Query lock >> 290: static Mutex* _query_lock; >> 291: > > Remove Done. > src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp line 93: > >> 91: >> 92: const inline NativeCallStack& get(StackIndex si) { >> 93: if (is_invalid(si) || si >= _stacks.length()) { > > I don't think this should be here? Removed. > src/hotspot/share/nmt/regionsTree.cpp line 33: > >> 31: log_debug(nmt)("trc base: " INTPTR_FORMAT " , trc end: " INTPTR_FORMAT, >> 32: p2i(region_in_tree.base()), p2i(region_in_tree.end())); >> 33: } > > Remove `with_trace` and improve the logging message. This should log unconditionally, probably under a `(nmt,vmtracker)` tagset. Done. > src/hotspot/share/nmt/regionsTree.cpp line 50: > >> 48: ReservedMemoryRegion rgn = find_reserved_region(addr); >> 49: return reserve_mapping((VMATree::position)addr, size, make_region_data(NativeCallStack::empty_stack(), rgn.mem_tag())); >> 50: } > > Can now be fixed. Done. > src/hotspot/share/nmt/regionsTree.cpp line 52: > >> 50: rgn = find_reserved_region(addr, true); >> 51: ShouldNotReachHere(); >> 52: } > > TODO: Remove this when 8335091 is merged Added a TODO comment to remind it. > src/hotspot/share/nmt/regionsTree.cpp line 54: > >> 52: } >> 53: return commit_mapping((VMATree::position)addr, size, make_region_data(stack, rgn.flag())); >> 54: > > Style: Extra space Fixed. > src/hotspot/share/nmt/regionsTree.cpp line 64: > >> 62: rgn = find_reserved_region(addr, true); >> 63: ShouldNotReachHere(); >> 64: } > > TODO: Remove this when https://github.com/openjdk/jdk/commit/8335091a5dd9a0654d9a616addcfdcc1863747ca is merged Added a TODO comment to remind this. > src/hotspot/share/nmt/regionsTree.hpp line 31: > >> 29: #include "nmt/vmatree.hpp" >> 30: >> 31: class RegionsTree : public VMATree { > > Is it necessary for this to be a superclass? Seems like this class contains utilities for working with a `VMATree`. Could it instead be `AllStatic` and take a tree as its first argument? I'd like to avoid inheritance unless necessary (typically for the usage of virtual functions). It is inherited because it is not a new type. I think that `_tree->visit_reserved_region(par1, par2)` is more readable than `VMATree::visit_reserved_region(_tree, par1, par2)` I could not find any *virtual functions* in these classes, what do you mean by that? > src/hotspot/share/nmt/regionsTree.hpp line 33: > >> 31: class RegionsTree : public VMATree { >> 32: private: >> 33: NativeCallStackStorage* _ncs_storage; > > No need for this to be a pointer. How to use the ctor with a `bool` arg, then? > src/hotspot/share/nmt/regionsTree.hpp line 38: > >> 36: public: >> 37: RegionsTree(bool with_storage) : VMATree() , _ncs_storage(with_storage) { } >> 38: > > Whitespace Done. > src/hotspot/share/nmt/regionsTree.hpp line 47: > >> 45: >> 46: class NodeHelper { >> 47: Node *_node; > > Style: `*` should hug type, not name. Fixed. > src/hotspot/share/nmt/regionsTree.hpp line 50: > >> 48: inline bool is_before(VMATree::position addr) { return VMATree::PositionComparator::cmp(key(), addr) < 0; } >> 49: inline bool is_after(VMATree::position addr) { return VMATree::PositionComparator::cmp(key(), addr) > 0; } >> 50: inline bool is_region_begin() { return is_reserved_begin()|| is_committed_begin(); } > > Not used? Removed non-used methods. > src/hotspot/share/nmt/regionsTree.hpp line 52: > >> 50: inline bool is_region_begin() { return is_reserved_begin()|| is_committed_begin(); } >> 51: inline bool is_region_end(NodeHelper* node) { return is_released_begin() || (node != nullptr && node->out_flag() != out_flag()); } >> 52: inline bool is_end_only(NodeHelper* node) { return !is_region_begin() && is_region_end(node); } > > Only used for debugging? Done. > src/hotspot/share/nmt/regionsTree.hpp line 53: > >> 51: inline bool is_region_end(NodeHelper* node) { return is_released_begin() || (node != nullptr && node->out_flag() != out_flag()); } >> 52: inline bool is_end_only(NodeHelper* node) { return !is_region_begin() && is_region_end(node); } >> 53: inline bool is_joint(NodeHelper* node) { return is_region_begin() && is_region_end(node); } > > Only used for debugging? Not anymore. Removed. > src/hotspot/share/nmt/regionsTree.hpp line 58: > >> 56: // inline bool is_region_end(NodeHelper* node) { return is_released_begin() || (node != nullptr && node->out_flag() != out_flag()); } >> 57: // inline bool is_end_only(NodeHelper* node) { return !is_region_begin() && is_region_end(node); } >> 58: // inline bool is_joint(NodeHelper* node) { return is_region_begin() && is_region_end(node); } > > No commented out code like this please. OK. Fixed. > src/hotspot/share/nmt/regionsTree.hpp line 61: > >> 59: inline VMATree::StateType out_state() { return val().out.type(); } >> 60: inline size_t distance_from(NodeHelper* other) { return key() - other->key(); } >> 61: inline const NativeCallStack& stack(NativeCallStackStorage* ncss) { return ncss->get(val().in.stack()); } > > Remove this Changed to return StackIndex. > src/hotspot/share/nmt/regionsTree.hpp line 66: > >> 64: inline VMATree::StateType out_state() { return _node->val().out.type(); } >> 65: inline size_t distance_from(NodeHelper& other) { return position() - other.position(); } >> 66: inline const NativeCallStackStorage::StackIndex out_stack_index() { return _node->val().out.stack(); } > > Unnecessary const in return type. Fixed. > src/hotspot/share/nmt/regionsTree.hpp line 71: > >> 69: inline void set_in_flag(MEMFLAGS flag) { _node->val().in.set_flag(flag); } >> 70: inline void set_out_flag(MEMFLAGS flag) { _node->val().out.set_flag(flag); } >> 71: inline void dump(outputStream* st) { > > `dump` is typically called `print_on` in HotSpot. `print_on` is used. > src/hotspot/share/nmt/regionsTree.hpp line 91: > >> 89: >> 90: template // F == bool(*)(CommittedMemoryRegion*) >> 91: void visit_committed_regions(const ReservedMemoryRegion* rgn, CommittedMemoryRegion* cmr, F func) { > > Why does it take the `ReservedMemoryRegion` as a pointer instead of a reference? There's no need to take a pointer to the `CommittedMemoryRegion`, just construct it in the function and pass it to `f`. Fixed. > src/hotspot/share/nmt/regionsTree.hpp line 91: > >> 89: template // F == bool(*)(CommittedMemoryRegion&) >> 90: void visit_committed_regions(position start, size_t size, F func) { >> 91: size_t end = start + size + 1; > > It's not clear to me why `+ 1` is needed. If we have a range `[start, size+start)`, will it be missed by `visit_range_in_order`? Yes it is missed. In the `visit_range_in_order` code, the variable `cmp_to` is never checked against `0` (`cmp_to == 0`). > src/hotspot/share/nmt/regionsTree.hpp line 95: > >> 93: size_t end = (size_t)rgn->end(); >> 94: size_t comm_size = 0; >> 95: size_t base = (size_t)rgn->base(); > > Why casting these? Because the args to `visit_range_in_order` are of type `position` which is `size_t`. Otherwise, compiler complains about conversion from `address` to `size_t`. > src/hotspot/share/nmt/regionsTree.hpp line 108: > >> 106: CommittedMemoryRegion cmr((address)base, comm_size, st); >> 107: comm_size = 0; >> 108: prev.clear_node(); > > This is unneeded. Which part? Why? `clear_node()` is the same as `prev = nullptr` if pointers were used. `is_valid()` is the same as `prev == nullptr` if pointers were used. > src/hotspot/share/nmt/regionsTree.hpp line 140: > >> 138: if (r_size != rgn_size) { >> 139: log_debug(nmt)("----------------- size differ, distance: " SIZE_FORMAT " size: " SIZE_FORMAT, r_size, rgn_size); >> 140: } > > Not needed anymore? Removed. > src/hotspot/share/nmt/regionsTree.hpp line 143: > >> 141: visit_in_order([&](Node* node) { >> 142: NodeHelper* curr = (NodeHelper*)node; >> 143: /* > > Delete Done. > src/hotspot/share/nmt/regionsTree.hpp line 172: > >> 170: inline const NativeCallStack stack(NodeHelper& node) { >> 171: NativeCallStackStorage::StackIndex si = node.out_stack_index(); >> 172: if (!si.is_invalid()) { > > Change check to `NativeCallStackStorage::is_invalid`. Done. > src/hotspot/share/nmt/virtualMemoryTrackerWithTree.cpp line 101: > >> 99: } >> 100: >> 101: void VirtualMemoryTrackerWithTree::apply_summary_diff(VMATree::SummaryDiff diff) { > > Applying a summary diff in the MemoryFileTracker is this: > > ```c++ > for (int i = 0; i < mt_number_of_types; i++) { > VirtualMemory* summary = file->_summary.by_type(NMTUtil::index_to_flag(i)); > summary->reserve_memory(diff.flag[i].commit); > summary->commit_memory(diff.flag[i].commit); > } > > > This is much simpler and doesn't require looking at signs and so on. In `MemoryFileTracker`, the changes in commit/reserve are applied to a local `VirtualMemorySnapshot`. Here we have to apply them to the global `VirtualMemorySummary`. > src/hotspot/share/nmt/virtualMemoryTrackerWithTree.cpp line 109: > >> 107: return true; >> 108: }); >> 109: } > > TODO: This should be replaced with the implementation in 8340103 > > Will happen when that PR has been reviewed and integrated. Replaced. > src/hotspot/share/nmt/virtualMemoryTrackerWithTree.cpp line 115: > >> 113: " vms-committed: " SIZE_FORMAT, >> 114: str, NMTUtil::flag_to_name(flag), r, c, reserved, committed); >> 115: }; > > Move this up to before the loop. Done. > src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 34: > >> 32: #include "utilities/ostream.hpp" >> 33: >> 34: class VirtualMemoryTrackerWithTree : AllStatic { > > Can this class be redone to use the same pattern as `MemoryFileTracker` with an outer class that's not static and an inner class that's stack, storing an instance of the outer class? That makes testing the class by creating an instance of it possible, unlike our old tests. Can we do this change as a separate RFE? It impacts the code a lot. > src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 41: > >> 39: VirtualMemoryTrackerWithTree(bool is_detailed_mode) : _tree(is_detailed_mode) { } >> 40: >> 41: bool add_reserved_region (address base_addr, size_t size, const NativeCallStack& stack, MEMFLAGS flag = mtNone); > > Style: Align open paren with other functions. Done. > src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 64: > >> 62: void apply_summary_diff(VMATree::SummaryDiff diff); >> 63: RegionsTree* tree() { return &_tree; } >> 64: class Instance : public AllStatic { > > Style: Newline to separate the new class to the getter above. Done. > src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 67: > >> 65: friend class VirtualMemoryTrackerTest; >> 66: friend class CommittedVirtualMemoryTest; >> 67: friend class ReservedMemoryRegion; > > Why is this necessary? Not anymore. Left over from initial tests. Removed. > src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 69: > >> 67: >> 68: private: >> 69: static RegionsTree* _tree; > > If you do the instance/static pattern then you can switch this into a regular member, no pointer necessary. The `_tree` ctor to be called in `initialize` with a `bool` depending the `NMT_Level`. Existing VMT also uses a pointer to a `SortedLinkList`. I am not sure yet: What is the advantage of not-a-pointer member? How the instance/static helps this? > src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 69: > >> 67: friend class ReservedMemoryRegion; >> 68: >> 69: private: > > Unnecessary, remove. Done. > src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 70: > >> 68: private: >> 69: static RegionsTree* _tree; >> 70: static NativeCallStackStorage* _ncs_storage; > > Doesn't seem like this is ever initialized? Removed. > src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 77: > >> 75: >> 76: static bool add_reserved_region (address base_addr, size_t size, const NativeCallStack& stack, MEMFLAGS flag = mtNone); >> 77: > > Style: Extra space The open paren should've been aligned with other functions. It is aligned now. > src/hotspot/share/nmt/vmatree.cpp line 33: > >> 31: >> 32: const char* VMATree::statetype_strings[4] = { >> 33: "released","reserved", "'only-committed", "committed", > > Extra quote in `"only-committed"`. Why is this new state required by the way? Removed the extra quote. Do you remember the new bit flags for state? 0 = Released, 1 = Reserved, 2= Committed(but not Reserved), 3= both Reserved and Committed > src/hotspot/share/nmt/vmatree.cpp line 36: > >> 34: }; >> 35: >> 36: void VMATree::put_if_absent(position A, position B, StateType state, const RegionData& region_data) { > > Unused. Removed. > src/hotspot/share/nmt/vmatree.hpp line 40: > >> 38: // or from committed memory of a certain MEMFLAGS to committed memory of a different MEMFLAGS. >> 39: // The set of points is stored in a balanced binary tree for efficient querying and updating. >> 40: class VMATree : public AnyObj { > > Why is it AnyObj now? Mainly to be able to use `new operator`. Changed to `CheapObj`. > src/hotspot/share/nmt/vmatree.hpp line 41: > >> 39: // or from committed memory of a certain MemTag to committed memory of a different MemTag. >> 40: // The set of points is stored in a balanced binary tree for efficient querying and updating. >> 41: class VMATree : public CHeapObj { > > Is this still needed? Not anymore. Removed. > src/hotspot/share/nmt/vmatree.hpp line 57: > >> 55: }; >> 56: >> 57: enum class StateType : uint8_t { Reserved = 1, Committed = 3, Released = 0, COUNT = 3 }; > > Why not the following? > > ```c++ > enum class StateType : uint8_t { Released, Reserved, Committed, COUNT }; > > > If this particular ordering is necessary then it should be documented why. Done. > src/hotspot/share/nmt/vmatree.hpp line 59: > >> 57: // Bit fields view: bit 0 for Reserved, bit 1 for Committed. >> 58: // Setting a region as Committed preserves the Reserved state. >> 59: enum class StateType : uint8_t { Reserved = 1, Committed = 3, Released = 0, COUNT = 4 }; > > Why do we now consider `StateType` to be a bit field? As the comments above it says, and we already had a discussion on it: The 'Committed' state now means 'Reserved and Committed'. So, when we visit nodes and check for Reserved ones, the committed nodes are also considered as Reserved. Otherwise, we would ignore the Committed nodes and continue looking for Reserved nodes. > src/hotspot/share/nmt/vmatree.hpp line 234: > >> 232: } >> 233: >> 234: void put_if_absent(position A, position B, StateType state, const RegionData& region_data); > > Not used. Removed. > src/hotspot/share/nmt/vmtCommon.cpp line 1: > >> 1: /* > > Is this all of the code that is still required by the reporter to be able to function? Actually, it is the old `virtualMemoryTracker.hpp` that now is renamed and refined to have only common stuff for the NMT. This is included in 13 files, not only the reporter. > src/hotspot/share/nmt/vmtCommon.hpp line 40: > >> 38: >> 39: >> 40: > > A lot of excessive spaces. Removed. > src/java.base/share/classes/java/lang/String.java line 2990: > >> 2988: return this; >> 2989: } >> 2990: return StringConcatHelper.doConcat(this, str == null ? "null" : str); > > Remove Done. It was a merge glitch. > test/hotspot/gtest/nmt/test_nmt_treap.cpp line 168: > >> 166: tty->print_cr("d1: %lf, d2: %lf, d2/d1: %lf", d1, d2, d2 / d1); >> 167: EXPECT_LT((int)(d2 / d1), N2 / N1); >> 168: } > > 1000 and 10_000 elements are both quite small, isn't one measurement prone to being slower than expected due to unforeseen circumstances? For example, if `malloc` performs a heavy allocation (by mapping in a few new pages) during the 10_000 elements insertion then that may stall enough that the `EXPECT_LT` fails. We are also bound to only performing the test once. > > Is your thinking that these perf tests should be kept in, or should they be removed before integrating? Generally, I think it is necessary to have performance tests to verify if any future changes do not degrade the performance. The approach of stress testing can be agreed between us, but the tests have to exist. In this approach, the input size is scaled N times and we expect the execution time grows as O(log(N)) which is much less than N. This test fails and we need to have a justification for it. If approach is invalid or not correct implemented, we fix it. But the expectations remains the same. > test/hotspot/gtest/nmt/test_vmatree.cpp line 368: > >> 366: } >> 367: >> 368: TEST_VM_F(NMTVMATreeTest, SummaryAccounting_dup) { > > Better name for the test, please avoid underscores in test names. I know, we have underscores in places in Hotspot, but it's a good rule for GTest naming. Done. > test/hotspot/jtreg/runtime/NMT/VirtualAllocCommitMerge.java line 123: > >> 121: checkCommitted(output, addrC, commitSize, "128KB"); >> 122: checkCommitted(output, addrE, commitSize, "128KB"); >> 123: System.out.println(output.getStdout()); > > Shouldn't be here? Removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2378894979 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2410539689 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2410730815 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2411241108 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1778343343 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799016774 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799017291 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799018897 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1778343610 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799027228 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1803165698 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770961200 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770961642 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770962435 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703291746 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703292159 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799028731 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770964698 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713717938 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713466616 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713467548 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770965082 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713469220 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770966862 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770967338 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713563471 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1803163360 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713537731 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799031692 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799031982 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713721268 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770975913 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703295371 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770978952 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703295725 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703296483 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770981600 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770982361 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770986444 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1704419039 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770987209 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713454670 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770988800 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799036588 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799036836 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703314202 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799037302 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1704419263 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770973856 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799038284 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799059723 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799038564 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703298094 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703300827 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703303785 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799038857 From jsjolen at openjdk.org Fri Nov 8 10:51:43 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 8 Nov 2024 10:51:43 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com> On Fri, 27 Sep 2024 09:52:07 GMT, Afshin Zafari wrote: > > What is the consensus on having two implementations alive at the same time? I'd like to see us delete the old VirtualMemoryTracker and only have the tree implementation left as part of this PR. What is the status of our testing? Is the tree version equivalent now and passes all tests? > > I have already told that the main reason to have 2 versions is to be able to switch back from new to old version at customer site at runtime. This is what Thomas has requested. The issue with having two implementations is that it requires adding a new `java` option, and deprecating and removing those take 3 releases. That's 18 months of us being required to have the old version in the codebase, and being required to maintain it. I don't think that's a negligible promise to make. Rather than having 2 implementations, I'd like to see us aiming for integration for JDK-25 after forking 24, so integration in December. That would give us 6 months of ensuring stability of the new implementation before it reaches any customers. During those 6 months it will go through all of our testing multiple times over, and be used by OpenJDK developers. What do you think of this idea? > During the implementation, it is much beneficial to have access to the old version to compare the results and debug problems when they occur. Until the whole port to VMATree is not done, we need this 2 versions side-by-side feature. Sure, I can understand that it's nice to have both versions present during development. Right now it seems like we have a broken build, do you have any plans on having a functioning and fully featured build soon? >> src/hotspot/share/nmt/regionsTree.hpp line 31: >> >>> 29: #include "nmt/vmatree.hpp" >>> 30: >>> 31: class RegionsTree : public VMATree { >> >> Is it necessary for this to be a superclass? Seems like this class contains utilities for working with a `VMATree`. Could it instead be `AllStatic` and take a tree as its first argument? I'd like to avoid inheritance unless necessary (typically for the usage of virtual functions). > > It is inherited because it is not a new type. I think that `_tree->visit_reserved_region(par1, par2)` is more readable than `VMATree::visit_reserved_region(_tree, par1, par2)` > I could not find any *virtual functions* in these classes, what do you mean by that? I'm saying that inheritance is mostly useful when we have virtual functions which we can specialize, and that `VMATree` has none. >> src/hotspot/share/nmt/regionsTree.hpp line 33: >> >>> 31: class RegionsTree : public VMATree { >>> 32: private: >>> 33: NativeCallStackStorage* _ncs_storage; >> >> No need for this to be a pointer. > > How to use the ctor with a `bool` arg, then? The bool argument is just passed along. ```c++ RegionsTree(bool with_storage) : VMATree(), _ncs_storage(with_storage) { } >> src/hotspot/share/nmt/regionsTree.hpp line 108: >> >>> 106: CommittedMemoryRegion cmr((address)base, comm_size, st); >>> 107: comm_size = 0; >>> 108: prev.clear_node(); >> >> This is unneeded. > > Which part? Why? > `clear_node()` is the same as `prev = nullptr` if pointers were used. > `is_valid()` is the same as `prev == nullptr` if pointers were used. Because you immediately reassign `prev` to `curr` in L114 it's not necessary to first call `clear_node`. >> src/hotspot/share/nmt/virtualMemoryTrackerWithTree.cpp line 101: >> >>> 99: } >>> 100: >>> 101: void VirtualMemoryTrackerWithTree::apply_summary_diff(VMATree::SummaryDiff diff) { >> >> Applying a summary diff in the MemoryFileTracker is this: >> >> ```c++ >> for (int i = 0; i < mt_number_of_types; i++) { >> VirtualMemory* summary = file->_summary.by_type(NMTUtil::index_to_flag(i)); >> summary->reserve_memory(diff.flag[i].commit); >> summary->commit_memory(diff.flag[i].commit); >> } >> >> >> This is much simpler and doesn't require looking at signs and so on. > > In `MemoryFileTracker`, the changes in commit/reserve are applied to a local `VirtualMemorySnapshot`. Here we have to apply them to the global `VirtualMemorySummary`. Yeah, that doesn't seem like a problem. ```c++ for (int i = 0; i < mt_number_of_types; i++) { r = diff.flag[i].reserve; c = diff.flag[i].commit; flag = NMTUtil::index_to_flag(i); VirtualMemory* mem = VirtualMemorySummary::as_snapshot()->by_type(flag); reserved = mem->reserved(); committed = mem->committed(); mem->reserve_memory(r); mem->commit_memory(c); if ((size_t)-r > reserved) { print_err("release"); } if ((size_t)-c > reserved || (size_t)c > committed) { print_err("uncommit"); } } >> src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 34: >> >>> 32: #include "utilities/ostream.hpp" >>> 33: >>> 34: class VirtualMemoryTrackerWithTree : AllStatic { >> >> Can this class be redone to use the same pattern as `MemoryFileTracker` with an outer class that's not static and an inner class that's stack, storing an instance of the outer class? That makes testing the class by creating an instance of it possible, unlike our old tests. > > Can we do this change as a separate RFE? It impacts the code a lot. Then just invert it: Have the outer class be static and the inner class be an instance. We can change the `MemoryFileTracker` to be that, as it's not as large of a change. >> src/hotspot/share/nmt/vmatree.hpp line 59: >> >>> 57: // Bit fields view: bit 0 for Reserved, bit 1 for Committed. >>> 58: // Setting a region as Committed preserves the Reserved state. >>> 59: enum class StateType : uint8_t { Reserved = 1, Committed = 3, Released = 0, COUNT = 4 }; >> >> Why do we now consider `StateType` to be a bit field? > > As the comments above it says, and we already had a discussion on it: The 'Committed' state now means 'Reserved and Committed'. So, when we visit nodes and check for Reserved ones, the committed nodes are also considered as Reserved. Otherwise, we would ignore the Committed nodes and continue looking for Reserved nodes. Right, I don't remember the discussion on this being a bit field. I agree, though, Committed also means Reserved, but it's not necessary to express that as a bit field. Regardless, I leave it up to you how we express this. >> test/hotspot/gtest/nmt/test_nmt_treap.cpp line 168: >> >>> 166: tty->print_cr("d1: %lf, d2: %lf, d2/d1: %lf", d1, d2, d2 / d1); >>> 167: EXPECT_LT((int)(d2 / d1), N2 / N1); >>> 168: } >> >> 1000 and 10_000 elements are both quite small, isn't one measurement prone to being slower than expected due to unforeseen circumstances? For example, if `malloc` performs a heavy allocation (by mapping in a few new pages) during the 10_000 elements insertion then that may stall enough that the `EXPECT_LT` fails. We are also bound to only performing the test once. >> >> Is your thinking that these perf tests should be kept in, or should they be removed before integrating? > > Generally, I think it is necessary to have performance tests to verify if any future changes do not degrade the performance. > The approach of stress testing can be agreed between us, but the tests have to exist. > In this approach, the input size is scaled N times and we expect the execution time grows as O(log(N)) which is much less than N. > This test fails and we need to have a justification for it. If approach is invalid or not correct implemented, we fix it. But the expectations remains the same. Why would the execution time grow logarithmically when we do linearly more work? When we run this with `N2` we will perform `10_000 * log(10_000, 2)` units of work, and for `N1` we will perform `1_000 * log(1_000, 2)` units of work, approximately. A closer approximation is `O(log(1)) + O(log(2)) + ... + O(log(n))` for `n = N2` or `n = N1`. Let's calculate that: >>> import math >>> def time_it(n): ... t = 0 ... for i in range(1, n): ... t = t + math.log(i) ... return [t, 3*t] # Approximate best and worst case ... >>> time_it(1000) [5905.220423209189, 17715.661269627566] >>> time_it(10_000) [82099.71749644217, 246299.15248932652] >>> def compare(a, b): ... ab, aw = a ... bb, bw = b ... return [ bb / ab, bw / aw ] ... >>> compare(time_it(1000), time_it(10_000)) [13.902904821938064, 13.902904821938066] >>> # Ouch, that's outside of our linear bound! What I said previously also applies, especially the performance of `malloc` will impact this I suspect. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2378929190 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711105506 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703735921 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799085027 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703751887 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703739805 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1776820787 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703877183 From azafari at openjdk.org Fri Nov 8 10:51:44 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 8 Nov 2024 10:51:44 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: <4mRy8kaaZMfKM3Tat40w_WxxjqLAoH5hJO_T0fZ5UTw=.d9c9ffc2-4d8a-496a-a9aa-ef8abe9412d4@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <4mRy8kaaZMfKM3Tat40w_WxxjqLAoH5hJO_T0fZ5UTw=.d9c9ffc2-4d8a-496a-a9aa-ef8abe9412d4@github.com> Message-ID: On Fri, 27 Sep 2024 09:49:37 GMT, Johan Sj?len wrote: > The fork for JDK-24 is on December 5th. That means that we have at most 8 weeks in the testing system to find and fix any bugs that we might have missed after integration. To me, that feels a bit short. Either we wait after the fork to integrate, or we integrate with two implementations and a `java` option for choosing implementation. I'm open to other opinions. Yes, time is tight. The chance of catching up the December 5th is not high. Anyway, we have already decided to add a new JVM option to enable/disable this new VMATree ( default = disabled). ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2378951599 From jsjolen at openjdk.org Fri Nov 8 10:51:45 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 8 Nov 2024 10:51:45 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <4mRy8kaaZMfKM3Tat40w_WxxjqLAoH5hJO_T0fZ5UTw=.d9c9ffc2-4d8a-496a-a9aa-ef8abe9412d4@github.com> Message-ID: On Fri, 27 Sep 2024 10:22:57 GMT, Afshin Zafari wrote: > > The fork for JDK-24 is on December 5th. That means that we have at most 8 weeks in the testing system to find and fix any bugs that we might have missed after integration. To me, that feels a bit short. Either we wait after the fork to integrate, or we integrate with two implementations and a `java` option for choosing implementation. I'm open to other opinions. > > Yes, time is tight. The chance of catching up the December 5th is not high. Anyway, we have already decided to add a new JVM option to enable/disable this new VMATree ( default = disabled). I don't believe that we have decided that already. Both me and, I believe, Gerard have been negative towards the proposal to keep both implementations. I'd like to use this as an opportunity to discuss the pros and cons of different approaches, which is why I asked for your opinion on my alternative. I believe that it is very important that we all agree on the approach taken, as we will all have to deal with the consequences of that approach. > ( default = disabled). Why should the default be disabled? That requires customers to explicitly pick the new tree to be used, which they are very unlikely to do. As I understand it, and correct me if I am wrong, the main goal of having two implementations is the ability to revert back in case we have bugs in the new one. If the default is to have the new implementation be disabled, then how are we ever going to find any real use bugs? Cheers, Johan ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2379082883 From azafari at openjdk.org Fri Nov 8 10:51:46 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 8 Nov 2024 10:51:46 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com> Message-ID: On Fri, 27 Sep 2024 10:10:37 GMT, Johan Sj?len wrote: > Sure, I can understand that it's nice to have both versions present during development. Right now it seems like we have a broken build, do you have any plans on having a functioning and fully featured build soon? The new commit is pushed. I will monitor the build results. > Rather than having 2 implementations, I'd like to see us aiming for integration for JDK-25 after forking 24, so integration in December. That would give us 6 months of ensuring stability of the new implementation before it reaches any customers. During those 6 months it will go through all of our testing multiple times over, and be used by OpenJDK developers. What do you think of this idea? No objection. We can do this way. >> It is inherited because it is not a new type. I think that `_tree->visit_reserved_region(par1, par2)` is more readable than `VMATree::visit_reserved_region(_tree, par1, par2)` >> I could not find any *virtual functions* in these classes, what do you mean by that? > > I'm saying that inheritance is mostly useful when we have virtual functions which we can specialize, and that `VMATree` has none. Done. I used inheritance for extending a class. >> How to use the ctor with a `bool` arg, then? > > The bool argument is just passed along. > > ```c++ > RegionsTree(bool with_storage) : VMATree(), _ncs_storage(with_storage) { > } Done. For my curiosity, what is the advantage? >> Can we do this change as a separate RFE? It impacts the code a lot. > > Then just invert it: Have the outer class be static and the inner class be an instance. We can change the `MemoryFileTracker` to be that, as it's not as large of a change. It is still a big change. Why not another RFE? >> Generally, I think it is necessary to have performance tests to verify if any future changes do not degrade the performance. >> The approach of stress testing can be agreed between us, but the tests have to exist. >> In this approach, the input size is scaled N times and we expect the execution time grows as O(log(N)) which is much less than N. >> This test fails and we need to have a justification for it. If approach is invalid or not correct implemented, we fix it. But the expectations remains the same. > > Why would the execution time grow logarithmically when we do linearly more work? When we run this with `N2` we will perform `10_000 * log(10_000, 2)` units of work, and for `N1` we will perform `1_000 * log(1_000, 2)` units of work, approximately. A closer approximation is `O(log(1)) + O(log(2)) + ... + O(log(n))` for `n = N2` or `n = N1`. > > Let's calculate that: > > >>>> import math >>>> def time_it(n): > ... t = 0 > ... for i in range(1, n): > ... t = t + math.log(i) > ... return [t, 3*t] # Approximate best and worst case > ... >>>> time_it(1000) > [5905.220423209189, 17715.661269627566] >>>> time_it(10_000) > [82099.71749644217, 246299.15248932652] >>>> def compare(a, b): > ... ab, aw = a > ... bb, bw = b > ... return [ bb / ab, bw / aw ] > ... >>>> compare(time_it(1000), time_it(10_000)) > [13.902904821938064, 13.902904821938066] >>>> # Ouch, that's outside of our linear bound! > > > What I said previously also applies, especially the performance of `malloc` will impact this I suspect. It is considered that `malloc` or other external events are the same for two cases. If we know that there might be some noise for one or another, we should check and disable them. This is the approach I have talked. How can we avoid noise from `malloc` side? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2379615290 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2379618102 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713461169 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1704394160 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1704401031 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1704424029 From azafari at openjdk.org Fri Nov 8 10:51:46 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 8 Nov 2024 10:51:46 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <4mRy8kaaZMfKM3Tat40w_WxxjqLAoH5hJO_T0fZ5UTw=.d9c9ffc2-4d8a-496a-a9aa-ef8abe9412d4@github.com> Message-ID: On Fri, 27 Sep 2024 11:43:19 GMT, Johan Sj?len wrote: > Why should the default be disabled? That requires customers to explicitly pick the new tree to be used, which they are very unlikely to do. As I understand it, and correct me if I am wrong, the main goal of having two implementations is the ability to revert back in case we have bugs in the new one. If the default is to have the new implementation be disabled, then how are we ever going to find any real use bugs? You are right. This should be defualt = enabled. Anyway, we are not going to have two versions. > I don't believe that we have decided that already. Both me and, I believe, Gerard have been negative towards the proposal to keep both implementations. I'd like to use this as an opportunity to discuss the pros and cons of different approaches, which is why I asked for your opinion on my alternative. I believe that it is very important that we all agree on the approach taken, as we will all have to deal with the consequences of that approach. Sorry for misunderstanding. We go for 1 version only. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2379619838 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2379622866 From gziemski at openjdk.org Fri Nov 8 10:51:48 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Fri, 8 Nov 2024 10:51:48 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com> Message-ID: On Fri, 27 Sep 2024 16:05:33 GMT, Afshin Zafari wrote: > > Rather than having 2 implementations, I'd like to see us aiming for integration for JDK-25 after forking 24, so integration in December. That would give us 6 months of ensuring stability of the new implementation before it reaches any customers. During those 6 months it will go through all of our testing multiple times over, and be used by OpenJDK developers. What do you think of this idea? > > No objection. We can do this way. Thank you Afshin for agreeing and thank you Johan for clearly stating the arguments. I was trying to think of a precedent where we shipped JDK with 2 small implementation details that were exposed via runtime flags, but nothing comes to mind... ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2379627354 From jsjolen at openjdk.org Fri Nov 8 10:51:49 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 8 Nov 2024 10:51:49 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com> Message-ID: On Fri, 27 Sep 2024 16:10:59 GMT, Gerard Ziemski wrote: > > > Rather than having 2 implementations, I'd like to see us aiming for integration for JDK-25 after forking 24, so integration in December. That would give us 6 months of ensuring stability of the new implementation before it reaches any customers. During those 6 months it will go through all of our testing multiple times over, and be used by OpenJDK developers. What do you think of this idea? > > > > > > No objection. We can do this way. > > Thank you Afshin for agreeing and thank you Johan for clearly stating the arguments. > > I was trying to think of a precedent where we shipped JDK with 2 small implementation details that were exposed via runtime flags, but nothing comes to mind... Yes, thank you Afshin for reconsidering. I do sympathise with the goal of ensuring that no user receives a faulty build. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2379664905 From azafari at openjdk.org Fri Nov 8 10:51:50 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 8 Nov 2024 10:51:50 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: <6HDJgDRPF7OvsR5vV3FZQWph4M2wHd4mtueXuy1ldYw=.e34b1f2f-f1fe-44d9-9970-5ed8c9224aee@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <6HDJgDRPF7OvsR5vV3FZQWph4M2wHd4mtueXuy1ldYw=.e34b1f2f-f1fe-44d9-9970-5ed8c9224aee@github.com> Message-ID: <7jle3GZrJMPxgMd4AUjyDrf-jPazyOhn-2rxP9JkvqE=.e327b819-1117-4339-a069-8565fc4fd7f3@github.com> On Fri, 27 Sep 2024 16:23:29 GMT, Gerard Ziemski wrote: > Should we say then, that this is blocked by those 2 issues? Is it OK then if I wait till those get checked in before verifying the performance benefits if the new implementation? The performance was the main motivation here, correct? It is not blocked, but until those 2 other PRs we cannot expect the full speed of the new VMT. There are some functions that are not efficient without those 2 PRs. You can test VMT with your microbenchmarks but if it fails in competition give it another chance after those PRs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2379801032 From jsjolen at openjdk.org Fri Nov 8 10:51:52 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 8 Nov 2024 10:51:52 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Mon, 14 Oct 2024 10:24:54 GMT, Afshin Zafari wrote: > > ```c++ > > region->add_committed_region(committed_start, committed_size, ncs); // <-- LOST! > > ``` > > The `region` is not a VMATree::node, it is a `ReservedMemoryRegion*`. I don't understand what you're trying to say here. Do you see the bug that I'm talking about? > > Is this part of the code under-tested as we didn't receive a test failure regarding this? > > All JTREG runtime/NMT tests and all tier1 tests have been passed on this code. Yes, but this code is incorrect. So we should have a test detecting this, but we do not, and so this is under-tested. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2411115944 From azafari at openjdk.org Fri Nov 8 10:51:52 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 8 Nov 2024 10:51:52 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Mon, 14 Oct 2024 12:37:05 GMT, Johan Sj?len wrote: > Yes, but this code is incorrect. So we should have a test detecting this, but we do not, and so this is under-tested. This code finds committed regions within a Stack region if they are not accounted by NMT so far, IIUC. By running this incorrect code, we may get some extra committed size in NMT reports. This is hard in NMT tests to catch. How can we expect a NMT test to measure X bytes of committed stack and not Y bytes? We need to know exactly the X and/or Y to test this code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2411263187 From jsjolen at openjdk.org Fri Nov 8 10:51:53 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 8 Nov 2024 10:51:53 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Mon, 14 Oct 2024 13:22:54 GMT, Afshin Zafari wrote: > > Yes, but this code is incorrect. So we should have a test detecting this, but we do not, and so this is under-tested. > > This code finds committed regions within a Stack region if they are not accounted by NMT so far, IIUC. By running this incorrect code, we may get some extra committed size in NMT reports. This is hard in NMT tests to catch. How can we expect a NMT test to measure X bytes of committed stack and not Y bytes? We need to know exactly the X and/or Y to test this code. I think it's actually the opposite: None of the committed regions will survive after this function. This is one of those times when having the ability to create new instances of NMT makes things very nice for testing. You simply do something like this (pseudo-code): ```c++ void test_it() { VMT vmt; size_t sz = 4096 * 16; void* mem = os::reserve_memory(sz, mtThreadStack); os::commit_memory(mem + 4096*2, 4096); vmt.reserve(mem, sz, mtThreadStack); vmt.walk_thread_stacks(); EXPECT_EQ(4096, sum_committed_of(vmt, mtThreadStack)); } ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2412008724 From azafari at openjdk.org Fri Nov 8 10:51:54 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 8 Nov 2024 10:51:54 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: <_-S6hRbiAOCHQMCAL-JEHmBaEdbX_-Rokt-nXOVgqTE=.2afbb2f6-b772-4b20-9785-dba1223bafc9@github.com> On Mon, 14 Oct 2024 18:56:47 GMT, Johan Sj?len wrote: > I think it's actually the opposite: None of the committed regions will survive after this function. You maybe missed my point when said " ... some extra committed size in NMT reports". I emphasize on the " the NMT reports", since the committed sizes in this function are added to the global VirtualMemorySummary which is used in reports. And yes, no committed regions that added here won't survive after this function. > This is one of those times when having the ability to create new instances of NMT makes things very nice for testing. I was talking about the existing tests and why they couldn't catch this bug.(why this is under-tested) > You simply do something like this (pseudo-code): Thanks for the pseudo-code, I will implement a test for this specific case. You will see it in one of the future commits here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2413222662 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2413225089 PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2413227952 From stuefe at openjdk.org Fri Nov 8 10:51:56 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 8 Nov 2024 10:51:56 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 7 Nov 2024 12:48:12 GMT, Afshin Zafari wrote: >> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. >> - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. >> - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` >> - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. >> - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. >> - Adding a runtime flag for selecting the old or new version can be added later. >> - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. > > Dear @tstuefe, this PR has been reviewed couple of rounds. Would you please, give your feedback? > Thanks. Hi @afshin-zafari, I'll take a look next week. Could you please remove draft state, so that the discussions are public on the ML? Could you also please, to make reviewing easier and for documentation, describe the desired behavior? You should also add this description (or reuse, could be the same text) to the header/start of the implementation. Detailed questions are: 1. where does the data structure live? E.g. "Its a global data structure". Important here is the distinction to the ZGC file mapping tracker. 2. How is the data structure guarded? (locking question) 3. how are memory reservations realized (what tree operations?) E.g. "creates a VMATree memory section with state=reserved and the given tag/stack combination". 3.1 Do we allow reservations to overlap with existing sections? If no, why? If yes, under which conditions, and what happens to the old sections? 4. how is memory commit realized? 4.2. What happens if I specify tag and stack? Any restrictions then? 4.1. What happens if I omit tag and stack on commit? What are the restrictions? 5. same for uncommit 6. How is release done? 7. How do we find memory sections? 8. Do we allow modifying the tag? (See @jdksjolen set_tag PR) Here is what I think how this should work: NMT should normally not put any restrictions on the use of mmap APIs. It should just faithfully track what we do. However, we may want a "paranoid" mode where we bail out/warn if something looks fishy. 3. reservations should create a new tree section with the given flag/stack 3.1 there should be no restrictions. If there are old sections in that range, they are replaced. However, with paranoid mode enabled, I would warn if we reserve over committed sections because that would replace the mapping in reality. Remapping just reserved but uncommitted sections should be fine, I think. I think we do this sometimes. 4. commit should work differently when giving tag+stack, or when tag and stack are omitted. 4.1 if tag+stack are given, commit just creates a single new section across the range with the given tag + stack. That should always work, regardless of whats there before (paranoid off). With paranoid=on, it should warn if we commit over already Committed sections, since that destroys those sections. 4.2) committing when tag+stack are omitted. As in "please commit what I reserved before, and just with the same tag and stack". In that case, commit just changes the tag for the range. That may or may not cause sections to coalesce (if changing the tag causes neighboring sections to have the same set of properties) or be created (if you commit middle of an existing section, and the set of properties now differs). Restrictions: there should be a clear unconditional restriction that this only works if there are no Released sections in that range, since a Released section (address holes) has no tag+stack to copy from. 5. Uncommit should never require tag+stack. It should change the state of the range to "Reserved" and leave tag+stack alone. Again, cannot work across address space holes. It can cause the splintering of existing sections, if we uncommit the middle of a committed section. 6. Releasing should just create a new section with State=Released, tag=mtNone and no stack. WDYT. I think it is a must to have all of this clearly specified before starting to implement, because the code is complex and one needs to know this logic beforehand. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2463896881 From gziemski at openjdk.org Fri Nov 8 10:51:57 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Fri, 8 Nov 2024 10:51:57 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Wed, 14 Aug 2024 19:11:58 GMT, Gerard Ziemski wrote: >> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. >> - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. >> - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` >> - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. >> - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. >> - Adding a runtime flag for selecting the old or new version can be added later. >> - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. > > src/hotspot/share/nmt/memReporter.cpp line 467: > >> 465: >> 466: if (reserved_and_committed) >> 467: return; > > This looks better, but now that I got more comfortable with anonymous local functions using lambda, I think we can do better. We can write a single `print_rgn` lambda function that we can use in both "reserved" and "committed" cases: > > > outputStream* out = output(); > const char* scale = current_scale(); > auto print_rgn = [&](const VirtualMemoryRegion* rgn, const NativeCallStack* stack, > MEMFLAGS mem_type = MEMFLAGS::mtNone, > const char* region_type = "committed", > bool committed = true) { > // Don't report if size is too small > if (amount_in_current_scale(rgn->size()) == 0) return; > out->cr(); > INDENT_BY(committed?8:0, > print_virtual_memory_region(region_type, rgn->base(), rgn->size()); > if (stack->is_empty()) { > out->cr(); > } else { > if (!committed) { > out->print(" for %s", NMTUtil::flag_to_name(mem_type)); > } > out->print_cr(" from "); > INDENT_BY(4, _stackprinter.print_stack(stack);) > } > ) > }; The whole method here then becomes: void MemDetailReporter::report_virtual_memory_region(const ReservedMemoryRegion* reserved_rgn) { assert(reserved_rgn != nullptr, "null pointer"); // We don't bother about reporting peaks here. // That is because peaks - in the context of virtual memory, peak of committed areas - make little sense // when we report *by region*, which are identified by their location in memory. There is a philosophical // question about identity here: e.g. a committed region that has been split into three regions by // uncommitting a middle section of it, should that still count as "having peaked" before the split? If // yes, which of the three new regions would be the spiritual successor? Rather than introducing more // complexity, we avoid printing peaks altogether. Note that peaks should still be printed when reporting // usage *by callsite*. if (reserved_rgn->flag() == mtTest) { log_debug(nmt)("report vmem, rgn base: " INTPTR_FORMAT " size: " SIZE_FORMAT "cur-scale: " SIZE_FORMAT, p2i(reserved_rgn->base()), reserved_rgn->size(),amount_in_current_scale(reserved_rgn->size())); } outputStream* out = output(); const char* scale = current_scale(); auto print_rgn = [&](const VirtualMemoryRegion* rgn, const NativeCallStack* stack, MEMFLAGS mem_type = MEMFLAGS::mtNone, const char* region_type = "committed", bool committed = true) { // Don't report if size is too small if (amount_in_current_scale(rgn->size()) == 0) return; out->cr(); INDENT_BY(committed?8:0, print_virtual_memory_region(region_type, rgn->base(), rgn->size()); if (stack->is_empty()) { out->cr(); } else { if (!committed) { out->print(" for %s", NMTUtil::flag_to_name(mem_type)); } out->print_cr(" from "); INDENT_BY(4, _stackprinter.print_stack(stack);) } ) }; bool all_committed = reserved_rgn->size() == reserved_rgn->committed_size(); const char* region_type = (all_committed ? "reserved and committed" : "reserved"); print_rgn(reserved_rgn, reserved_rgn->call_stack(), reserved_rgn->flag(), region_type, false); if (all_committed) { if (MemTracker::is_using_sorted_link_list()) { CommittedRegionIterator itr = reserved_rgn->iterate_committed_regions(); const CommittedMemoryRegion* committed_rgn = itr.next(); if (committed_rgn->size() == reserved_rgn->size() && committed_rgn->call_stack()->equals(*reserved_rgn->call_stack())) { // One region spanning the entire reserved region, with the same stack trace. // Don't print this regions because the "reserved and committed" line above // already indicates that the region is committed. assert(itr.next() == nullptr, "Unexpectedly more than one regions"); return; } } if (MemTracker::is_using_tree()) { bool reserved_and_committed = false; VirtualMemoryTrackerWithTree::Instance::tree()->visit_committed_regions(*reserved_rgn, [&](CommittedMemoryRegion& committed_rgn) { if (committed_rgn.size() == reserved_rgn->size() && committed_rgn.call_stack()->equals(*reserved_rgn->call_stack())) { // One region spanning the entire reserved region, with the same stack trace. // Don't print this regions because the "reserved and committed" line above // already indicates that the region is committed. reserved_and_committed = true; return false; } return true; }); if (reserved_and_committed) return; } } if (MemTracker::is_using_sorted_link_list()) { CommittedRegionIterator itr = reserved_rgn->iterate_committed_regions(); CommittedMemoryRegion* crgn; while ((crgn = itr.next()) != nullptr) { print_rgn(crgn, crgn->call_stack()); } } if (MemTracker::is_using_tree()) { VirtualMemoryTrackerWithTree::Instance::tree()->visit_committed_regions(*reserved_rgn, [&](CommittedMemoryRegion& crgn) { print_rgn(&crgn, crgn.call_stack()); return true; }); } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1717435317 From gziemski at openjdk.org Fri Nov 8 10:52:00 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Fri, 8 Nov 2024 10:52:00 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Wed, 14 Aug 2024 19:13:49 GMT, Gerard Ziemski wrote: >> src/hotspot/share/nmt/memReporter.cpp line 467: >> >>> 465: >>> 466: if (reserved_and_committed) >>> 467: return; >> >> This looks better, but now that I got more comfortable with anonymous local functions using lambda, I think we can do better. We can write a single `print_rgn` lambda function that we can use in both "reserved" and "committed" cases: >> >> >> outputStream* out = output(); >> const char* scale = current_scale(); >> auto print_rgn = [&](const VirtualMemoryRegion* rgn, const NativeCallStack* stack, >> MEMFLAGS mem_type = MEMFLAGS::mtNone, >> const char* region_type = "committed", >> bool committed = true) { >> // Don't report if size is too small >> if (amount_in_current_scale(rgn->size()) == 0) return; >> out->cr(); >> INDENT_BY(committed?8:0, >> print_virtual_memory_region(region_type, rgn->base(), rgn->size()); >> if (stack->is_empty()) { >> out->cr(); >> } else { >> if (!committed) { >> out->print(" for %s", NMTUtil::flag_to_name(mem_type)); >> } >> out->print_cr(" from "); >> INDENT_BY(4, _stackprinter.print_stack(stack);) >> } >> ) >> }; > > The whole method here then becomes: > > > void MemDetailReporter::report_virtual_memory_region(const ReservedMemoryRegion* reserved_rgn) { > assert(reserved_rgn != nullptr, "null pointer"); > > // We don't bother about reporting peaks here. > // That is because peaks - in the context of virtual memory, peak of committed areas - make little sense > // when we report *by region*, which are identified by their location in memory. There is a philosophical > // question about identity here: e.g. a committed region that has been split into three regions by > // uncommitting a middle section of it, should that still count as "having peaked" before the split? If > // yes, which of the three new regions would be the spiritual successor? Rather than introducing more > // complexity, we avoid printing peaks altogether. Note that peaks should still be printed when reporting > // usage *by callsite*. > > if (reserved_rgn->flag() == mtTest) { > log_debug(nmt)("report vmem, rgn base: " INTPTR_FORMAT " size: " SIZE_FORMAT "cur-scale: " SIZE_FORMAT, > p2i(reserved_rgn->base()), reserved_rgn->size(),amount_in_current_scale(reserved_rgn->size())); > } > > outputStream* out = output(); > const char* scale = current_scale(); > auto print_rgn = [&](const VirtualMemoryRegion* rgn, const NativeCallStack* stack, > MEMFLAGS mem_type = MEMFLAGS::mtNone, > const char* region_type = "committed", > bool committed = true) { > // Don't report if size is too small > if (amount_in_current_scale(rgn->size()) == 0) return; > out->cr(); > INDENT_BY(committed?8:0, > print_virtual_memory_region(region_type, rgn->base(), rgn->size()); > if (stack->is_empty()) { > out->cr(); > } else { > if (!committed) { > out->print(" for %s", NMTUtil::flag_to_name(mem_type)); > } > out->print_cr(" from "); > INDENT_BY(4, _stackprinter.print_stack(stack);) > } > ) > }; > > bool all_committed = reserved_rgn->size() == reserved_rgn->committed_size(); > const char* region_type = (all_committed ? "reserved and committed" : "reserved"); > print_rgn(reserved_rgn, reserved_rgn->call_stack(), reserved_rgn->flag(), region_type, false); > > if (all_committed) { > if (MemTracker::is_using_sorted_link_list()) { > CommittedRegionIterator itr = reserved_rgn->iterate_committed_regions(); > const CommittedMemoryRegion* committed_rgn = itr.next(); > if (committed_rgn->size() == reserved_rgn->... Notice that by changing: `INDENT_BY(4, stack->print_on(out);)` to `INDENT_BY(4, _stackprinter.print_stack(stack);)` we went from: [0x0000000600000000 - 0x0000000620000000] committed 536870912 from [0x000000010ce40dfe]ReservedSpace::reserve(unsigned long, unsigned long, unsigned long, char*, bool)+0x2da[0x000000010ce41214]ReservedHeapSpace::try_reserve_heap(unsigned long, unsigned long, unsigned long, char*)+0x60[0x000000010ce413ac]ReservedHeapSpace::try_reserve_range(char*, char*, unsigned long, char*, char*, unsigned long, unsigned long, unsigned long)+0xae[0x000000010ce41571]ReservedHeapSpace::initialize_compressed_heap(unsigned long, unsigned long, unsigned long)+0x1b5 to [0x0000000600000000 - 0x0000000620000000] committed 536870912 from [0x000000010be40d4e]ReservedSpace::reserve(unsigned long, unsigned long, unsigned long, char*, bool)+0x2da [0x000000010be41164]ReservedHeapSpace::try_reserve_heap(unsigned long, unsigned long, unsigned long, char*)+0x60 [0x000000010be412fc]ReservedHeapSpace::try_reserve_range(char*, char*, unsigned long, char*, char*, unsigned long, unsigned long, unsigned long)+0xae [0x000000010be414c1]ReservedHeapSpace::initialize_compressed_heap(unsigned long, unsigned long, unsigned long)+0x1b5 which I think is now correct, and used to be wrong. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1717438580 From azafari at openjdk.org Fri Nov 8 10:52:03 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 8 Nov 2024 10:52:03 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: <9UIAcuZEBgvAaPcqvejgUtwP0YJjacmOHv-I6qLPRrQ=.1c5add51-73dd-4e7f-891e-08f1cfb9a288@github.com> On Fri, 27 Sep 2024 09:46:27 GMT, Afshin Zafari wrote: >> src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp line 93: >> >>> 91: >>> 92: const inline NativeCallStack& get(StackIndex si) { >>> 93: if (is_invalid(si) || si >= _stacks.length()) { >> >> I don't think this should be here? > > Removed. No, returned back. This assert is triggered: # Internal Error (/home/afshin/scratch/833XX_nmt_VMT_with_tree/src/hotspot/share/utilities/growableArray.hpp:142), pid=1972883, tid=1972931 # assert(0 <= i && i < _len) failed: illegal index 0 for length 0 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1778358195 From jsjolen at openjdk.org Fri Nov 8 10:52:03 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 8 Nov 2024 10:52:03 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: <9UIAcuZEBgvAaPcqvejgUtwP0YJjacmOHv-I6qLPRrQ=.1c5add51-73dd-4e7f-891e-08f1cfb9a288@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <9UIAcuZEBgvAaPcqvejgUtwP0YJjacmOHv-I6qLPRrQ=.1c5add51-73dd-4e7f-891e-08f1cfb9a288@github.com> Message-ID: On Fri, 27 Sep 2024 09:57:35 GMT, Afshin Zafari wrote: >> Removed. > > No, returned back. > This assert is triggered: > > # Internal Error (/home/afshin/scratch/833XX_nmt_VMT_with_tree/src/hotspot/share/utilities/growableArray.hpp:142), pid=1972883, tid=1972931 > # assert(0 <= i && i < _len) failed: illegal index 0 for length 0 Why is this assert triggered? That sounds like a bug. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797710083 From azafari at openjdk.org Fri Nov 8 10:52:04 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 8 Nov 2024 10:52:04 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <9UIAcuZEBgvAaPcqvejgUtwP0YJjacmOHv-I6qLPRrQ=.1c5add51-73dd-4e7f-891e-08f1cfb9a288@github.com> Message-ID: On Sat, 12 Oct 2024 14:24:15 GMT, Johan Sj?len wrote: >> No, returned back. >> This assert is triggered: >> >> # Internal Error (/home/afshin/scratch/833XX_nmt_VMT_with_tree/src/hotspot/share/utilities/growableArray.hpp:142), pid=1972883, tid=1972931 >> # assert(0 <= i && i < _len) failed: illegal index 0 for length 0 > > Why is this assert triggered? That sounds like a bug. The assertion that happens during building jdk-image: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/afshin/scratch/833XX_nmt_VMT_with_tree/src/hotspot/share/utilities/growableArray.hpp:142), pid=1234272, tid=1234278 # assert(0 <= i && i < _len) failed: illegal index 0 for length 0 # # JRE version: (24.0) (fastdebug build ) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 24-internal-2024-09-30-0937351.afshin..., mixed mode, emulated-client, tiered, compressed oops, compressed class ptrs, serial gc, linux-amd64) # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/afshin/scratch/833XX_nmt_VMT_with_tree/make/core.1234272) # # --------------- S U M M A R Y ------------ Command Line: -Denv.class.path= -Dapplication.home=/home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/jdk -Xms8m -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 -Djdk.module.main=jdk.jlink jdk.jlink/jdk.tools.jmod.Main create --module-version 24-internal --target-platform linux-amd64 --module-path /home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/images/jmods --libs /home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/support/modules_libs/jdk.sctp --class-path /home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/jdk/modules/jdk.sctp --legal-notices /home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/support/modules_legal/common --exclude **{_the.*,_*.marker*,*.diz,*.debuginfo,*.dSYM/**,*.dSYM} --compress zip-1 --date 2024-09-30T09:37:57Z /home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/support/images/jmods/jdk.sctp.jmod Host: afshin-Precision-7920-Tower, Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz, 40 cores, 62G, Ubuntu 20.04.6 LTS Time: Mon Oct 14 10:52:34 2024 CEST elapsed time: 0.002402 seconds (0d 0h 0m 0s) --------------- T H R E A D --------------- Current thread is native thread Stack: [0x00007ffa5243a000,0x00007ffa5253b000], sp=0x00007ffa52539390, free space=1020k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x18df026] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x486 (growableArray.hpp:142) V [libjvm.so+0x18df870] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, ...)+0x0 (vmError.cpp:1611) V [libjvm.so+0xac3a81] report_vm_error(char const*, int, char const*, char const*, ...)+0xf1 (debug.cpp:193) V [libjvm.so+0x15f7851] void Treap::visit_in_order(RegionsTree::find_reserved_region(unsigned char*)::{lambda(ReservedMemoryRegion&)#1})::{lambda(Treap::TreapNode*)#1}>(RegionsTree::visit_reserved_regions(RegionsTree::find_reserved_region(unsigned char*)::{lambda(ReservedMemoryRegion&)#1})::{lambda(Treap::TreapNode*)#1}) const+0x4c1 (growableArray.hpp:142) V [libjvm.so+0x15f7b59] RegionsTree::commit_region(unsigned char*, unsigned long, NativeCallStack const&)+0x149 (vmatree.hpp:227) V [libjvm.so+0x18cc8cc] VirtualMemoryTracker::add_committed_region(unsigned char*, unsigned long, NativeCallStack const&)+0x2c (virtualMemoryTracker.cpp:150) V [libjvm.so+0x14dc5b7] os::commit_memory(char*, unsigned long, bool)+0x97 (memTracker.hpp:175) V [libjvm.so+0xac611f] initialize_assert_poison()+0x7f (debug.cpp:715) V [libjvm.so+0x181aecd] Threads::create_vm(JavaVMInitArgs*, bool*)+0x53d (threads.cpp:490) V [libjvm.so+0xfb4494] JNI_CreateJavaVM+0x54 (jni.cpp:3596) C [libjli.so+0x432f] JavaMain+0x8f (java.c:1490) C [libjli.so+0x79b9] ThreadJavaMain+0x9 (java_md.c:633) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799014090 From jsjolen at openjdk.org Fri Nov 8 10:52:04 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 8 Nov 2024 10:52:04 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <9UIAcuZEBgvAaPcqvejgUtwP0YJjacmOHv-I6qLPRrQ=.1c5add51-73dd-4e7f-891e-08f1cfb9a288@github.com> Message-ID: On Mon, 14 Oct 2024 08:50:52 GMT, Afshin Zafari wrote: >> Why is this assert triggered? That sounds like a bug. > > The assertion that happens during building jdk-image: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/afshin/scratch/833XX_nmt_VMT_with_tree/src/hotspot/share/utilities/growableArray.hpp:142), pid=1234272, tid=1234278 > # assert(0 <= i && i < _len) failed: illegal index 0 for length 0 > # > # JRE version: (24.0) (fastdebug build ) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 24-internal-2024-09-30-0937351.afshin..., mixed mode, emulated-client, tiered, compressed oops, compressed class ptrs, serial gc, linux-amd64) > # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/afshin/scratch/833XX_nmt_VMT_with_tree/make/core.1234272) > # > # > > --------------- S U M M A R Y ------------ > > Command Line: -Denv.class.path= -Dapplication.home=/home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/jdk -Xms8m -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 -Djdk.module.main=jdk.jlink jdk.jlink/jdk.tools.jmod.Main create --module-version 24-internal --target-platform linux-amd64 --module-path /home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/images/jmods --libs /home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/support/modules_libs/jdk.sctp --class-path /home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/jdk/modules/jdk.sctp --legal-notices /home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/support/modules_legal/common --exclude **{_the.*,_*.marker*,*.diz,*.debuginfo,*.dSYM/**,*.dSYM} --compress zip-1 --date 2024-09-30T09:37:57Z /home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/support/images/jmods/jdk.sctp.jmod > > Host: afshin-Precision-7920-Tower, Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz, 40 cores, 62G, Ubuntu 20.04.6 LTS > Time: Mon Oct 14 10:52:34 2024 CEST elapsed time: 0.002402 seconds (0d 0h 0m 0s) > > --------------- T H R E A D --------------- > > Current thread is native thread > > Stack: [0x00007ffa5243a000,0x00007ffa5253b000], sp=0x00007ffa52539390, free space=1020k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x18df026] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x486 (growableArray.hpp:142) > V [libjvm.so+0x18df870] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*,... OK, so there's a bug in the new VMT. You should be getting the command run so that you can reproduce it in gdb. If not, you can add `LOG=cmdlines` as an environment variable before building. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1802521408 From jsjolen at openjdk.org Fri Nov 8 10:52:05 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 8 Nov 2024 10:52:05 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Tue, 20 Aug 2024 07:33:06 GMT, Afshin Zafari wrote: >> src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp line 94: >> >>> 92: if (si._stack_index < 0 || si._stack_index >= _stacks.length()) { >>> 93: return _fake_stack; >>> 94: } >> >> Is that a leftover from debugging? >> >> Shouldn't this be an `assert` in final code? > > You are right. Since the next lines check the `-1` as special case; this check should be either an `assert` or logged. I wait for @jdksjolen, as this is his code. Old code, delete it. No logging for this. You can always add an assert for `si._stack_index >= _stacks.length()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1731029704 From jsjolen at openjdk.org Fri Nov 8 10:52:05 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 8 Nov 2024 10:52:05 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com> Message-ID: <6o6kdvS3Uy-Fq1bbRBmiPYvV7ztF6Urm0x5lkfgA2kY=.9e576627-d4cb-47a9-a916-59687afa11b5@github.com> On Mon, 5 Aug 2024 16:50:00 GMT, Afshin Zafari wrote: >> The bool argument is just passed along. >> >> ```c++ >> RegionsTree(bool with_storage) : VMATree(), _ncs_storage(with_storage) { >> } > > Done. > For my curiosity, what is the advantage? 1. No malloc 2. No indirection, so no cache misses 3. A clear lifetime and clear ownership, both are bound to the `RegionsTree` object >> Then just invert it: Have the outer class be static and the inner class be an instance. We can change the `MemoryFileTracker` to be that, as it's not as large of a change. > > It is still a big change. Why not another RFE? Because we want to switch to a new way of exposing the public interface, as opposed to an under-the-hood optimization. This PR is still in draft and we're far away from next RDP1, we're not in a hurry and can afford to get this right. I do not want to repeat the same mistakes of the old codebase. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711099968 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711190300 From azafari at openjdk.org Fri Nov 8 10:52:06 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 8 Nov 2024 10:52:06 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: <6o6kdvS3Uy-Fq1bbRBmiPYvV7ztF6Urm0x5lkfgA2kY=.9e576627-d4cb-47a9-a916-59687afa11b5@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com> <6o6kdvS3Uy-Fq1bbRBmiPYvV7ztF6Urm0x5lkfgA2kY=.9e576627-d4cb-47a9-a916-59687afa11b5@github.com> Message-ID: <1NaOK_jn5BkkHoXnlaP_vLz0Gyp9PcqFbHzFYOhlmuI=.d65aa63e-26c5-4084-997c-dd9b1cc03cd2@github.com> On Fri, 9 Aug 2024 09:05:37 GMT, Johan Sj?len wrote: >> Done. >> For my curiosity, what is the advantage? > > 1. No malloc > 2. No indirection, so no cache misses > 3. A clear lifetime and clear ownership, both are bound to the `RegionsTree` object OK. Thanks for your description. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713371752 From jsjolen at openjdk.org Fri Nov 8 10:52:06 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 8 Nov 2024 10:52:06 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Fri, 9 Aug 2024 10:14:10 GMT, Johan Sj?len wrote: >> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. >> - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. >> - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` >> - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. >> - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. >> - Adding a runtime flag for selecting the old or new version can be added later. >> - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. > > src/hotspot/share/nmt/regionsTree.hpp line 46: > >> 44: using Node = VMATree::TreapNode; >> 45: >> 46: class NodeHelper : public Node { > > This shouldn't inherit from `Node` and then have each instance be cast into `NodeHelper`. Make into `class Utils : public AllStatic`. Alternatively create it by composition: ```c++ class NodeHelper { Node& node; NodeHelper(Node* node) : node(*node) {} // All of the methods }; { // Some Node* node NodeHelper nh(node); // Use nh } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711643629 From azafari at openjdk.org Fri Nov 8 10:52:06 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 8 Nov 2024 10:52:06 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: <34_DIwceR7SBt_B6wwmMqA9yLFss4bkqGx4f-k6gSeM=.88fa4c55-442a-4d71-a511-1a81d070d185@github.com> On Fri, 9 Aug 2024 15:05:59 GMT, Johan Sj?len wrote: >> src/hotspot/share/nmt/regionsTree.hpp line 46: >> >>> 44: using Node = VMATree::TreapNode; >>> 45: >>> 46: class NodeHelper : public Node { >> >> This shouldn't inherit from `Node` and then have each instance be cast into `NodeHelper`. Make into `class Utils : public AllStatic`. > > Alternatively create it by composition: > > ```c++ > class NodeHelper { > Node& node; > NodeHelper(Node* node) : node(*node) {} > // All of the methods > }; > > { // Some Node* node > NodeHelper nh(node); > // Use nh > } Done. The alternative way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713462208 From jsjolen at openjdk.org Fri Nov 8 10:52:07 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 8 Nov 2024 10:52:07 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com> Message-ID: On Mon, 5 Aug 2024 08:41:49 GMT, Johan Sj?len wrote: >> In `MemoryFileTracker`, the changes in commit/reserve are applied to a local `VirtualMemorySnapshot`. Here we have to apply them to the global `VirtualMemorySummary`. > > Yeah, that doesn't seem like a problem. > > ```c++ > for (int i = 0; i < mt_number_of_types; i++) { > r = diff.flag[i].reserve; > c = diff.flag[i].commit; > flag = NMTUtil::index_to_flag(i); > VirtualMemory* mem = VirtualMemorySummary::as_snapshot()->by_type(flag); > reserved = mem->reserved(); > committed = mem->committed(); > mem->reserve_memory(r); > mem->commit_memory(c); > if ((size_t)-r > reserved) { > print_err("release"); > } > if ((size_t)-c > reserved || (size_t)c > committed) { > print_err("uncommit"); > } > } This applies the reserve/commit regardless of outcome, so slightly different. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703753128 From azafari at openjdk.org Fri Nov 8 10:52:07 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 8 Nov 2024 10:52:07 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com> Message-ID: On Mon, 5 Aug 2024 08:42:43 GMT, Johan Sj?len wrote: >> Yeah, that doesn't seem like a problem. >> >> ```c++ >> for (int i = 0; i < mt_number_of_types; i++) { >> r = diff.flag[i].reserve; >> c = diff.flag[i].commit; >> flag = NMTUtil::index_to_flag(i); >> VirtualMemory* mem = VirtualMemorySummary::as_snapshot()->by_type(flag); >> reserved = mem->reserved(); >> committed = mem->committed(); >> mem->reserve_memory(r); >> mem->commit_memory(c); >> if ((size_t)-r > reserved) { >> print_err("release"); >> } >> if ((size_t)-c > reserved || (size_t)c > committed) { >> print_err("uncommit"); >> } >> } > > This applies the reserve/commit regardless of outcome, so slightly different. The main purpose of the `if (...)` cases is to find if the request to apply the delta is valid or not. There are related assertions in VirtualMemory but not so informative. Also, using `log_debug` lets the build proceed and just show the messages. These messages help a lot when something goes wrong in terms of commit/uncommit/release failure. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1704398731 From jsjolen at openjdk.org Fri Nov 8 10:52:07 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 8 Nov 2024 10:52:07 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com> Message-ID: On Mon, 5 Aug 2024 16:54:40 GMT, Afshin Zafari wrote: >> This applies the reserve/commit regardless of outcome, so slightly different. > > The main purpose of the `if (...)` cases is to find if the request to apply the delta is valid or not. There are related assertions in VirtualMemory but not so informative. Also, using `log_debug` lets the build proceed and just show the messages. > These messages help a lot when something goes wrong in terms of commit/uncommit/release failure. How does my example code not account for this? You can still get rid of the sign checking. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711187386 From azafari at openjdk.org Fri Nov 8 10:52:08 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 8 Nov 2024 10:52:08 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com> Message-ID: On Fri, 9 Aug 2024 10:03:52 GMT, Johan Sj?len wrote: >> The main purpose of the `if (...)` cases is to find if the request to apply the delta is valid or not. There are related assertions in VirtualMemory but not so informative. Also, using `log_debug` lets the build proceed and just show the messages. >> These messages help a lot when something goes wrong in terms of commit/uncommit/release failure. > > How does my example code not account for this? You can still get rid of the sign checking. Case of 'commit' error is missing from your suggestion. At commit time, ` c > reserved` is invalid too. `(size_t)-r` for positive `r` is a large number and is greater than `reserved`. We have to find out the intent of the call first (by checking the sign of `r` or `c`) and then check if it is valid or not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713513436 From azafari at openjdk.org Fri Nov 8 10:52:08 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 8 Nov 2024 10:52:08 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com> Message-ID: <5y5A3NZ0xOQvQ26ao94mbrvFMbF1mLaqyL6YZcTHJ9U=.f73c445f-38b0-4419-bc6d-50e7793d7084@github.com> On Mon, 5 Aug 2024 17:20:24 GMT, Afshin Zafari wrote: >> Why would the execution time grow logarithmically when we do linearly more work? When we run this with `N2` we will perform `10_000 * log(10_000, 2)` units of work, and for `N1` we will perform `1_000 * log(1_000, 2)` units of work, approximately. A closer approximation is `O(log(1)) + O(log(2)) + ... + O(log(n))` for `n = N2` or `n = N1`. >> >> Let's calculate that: >> >> >>>>> import math >>>>> def time_it(n): >> ... t = 0 >> ... for i in range(1, n): >> ... t = t + math.log(i) >> ... return [t, 3*t] # Approximate best and worst case >> ... >>>>> time_it(1000) >> [5905.220423209189, 17715.661269627566] >>>>> time_it(10_000) >> [82099.71749644217, 246299.15248932652] >>>>> def compare(a, b): >> ... ab, aw = a >> ... bb, bw = b >> ... return [ bb / ab, bw / aw ] >> ... >>>>> compare(time_it(1000), time_it(10_000)) >> [13.902904821938064, 13.902904821938066] >>>>> # Ouch, that's outside of our linear bound! >> >> >> What I said previously also applies, especially the performance of `malloc` will impact this I suspect. > > It is considered that `malloc` or other external events are the same for two cases. If we know that there might be some noise for one or another, we should check and disable them. This is the approach I have talked. How can we avoid noise from `malloc` side? When it is said that an algorithm has the log(n) time-complexity, it means that if the input grows n times, the times grows log(n) times. The tree data-structure has log(n) time-complexity. VMATree may have not exactly log(n) response times due to self-balancing costs. But it is still expected to be less than O(n). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1704427407 From jsjolen at openjdk.org Fri Nov 8 10:52:09 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 8 Nov 2024 10:52:09 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: <5y5A3NZ0xOQvQ26ao94mbrvFMbF1mLaqyL6YZcTHJ9U=.f73c445f-38b0-4419-bc6d-50e7793d7084@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com> <5y5A3NZ0xOQvQ26ao94mbrvFMbF1mLaqyL6YZcTHJ9U=.f73c445f-38b0-4419-bc6d-50e7793d7084@github.com> Message-ID: On Mon, 5 Aug 2024 17:23:46 GMT, Afshin Zafari wrote: >> It is considered that `malloc` or other external events are the same for two cases. If we know that there might be some noise for one or another, we should check and disable them. This is the approach I have talked. How can we avoid noise from `malloc` side? > > When it is said that an algorithm has the log(n) time-complexity, it means that if the input grows n times, the times grows log(n) times. The tree data-structure has log(n) time-complexity. VMATree may have not exactly log(n) response times due to self-balancing costs. But it is still expected to be less than O(n). Hi Afshin, could we take a step back and do some asymptotic time complexity analysis of this problem? The test is measuring the following code: ```c++ for (int i = 0; i < n; i++) { int a = (os::random() % n) * 100; treap.upsert(a, 0); } So this algorithm is the tme complexity which we are trying to understand. First, let's simplify the code slightly: ```c++ auto f = [&](auto n) { int a = (os::random() % n) * 100; treap.upsert(a, i); }; for (int i = 0; i < n; i++) { f(i); } Clearly, `f(n)` is executed `n` times, agreed? Then the time complexity of the whole program must be `O(n*f(n))`, correct? It's the time complexity of `f(n)` performed `n` times. Let's replace `f` with something else to see if we can understand the time complexity of the whole code snippet again. ```c++ int arr[n]; auto f = [&](auto n) { arr[n] = 0; }; for (int i = 0; i < n; i++) { f(i); } Now, we both agree that assigning to an array has time complexity `O(1)`, correct? Then, if we fill that in in our expression `O(n * f(n))` we receive `O(n * 1) = O(n)`, correct? In other words, the time complexity of the algorithm the test is measuring is *linear*, and we ought to expect that with an array the time taken for the array should be 10x longer with 10k elements as compared to 1k elements. OK, now let's *assume* that `f(n)` has time complexity `O(log n)`, then shouldn't the algorithm we're measuring have time complexity `O(n * log n)`, that is actually *slower* than `O(n)`. In conclusion: if `treap.upsert()` has time complexity `O(log n)` then the whole algorithm should have time complexity `O(n * log n)` and the measurements we're seeing are as expected *and the test shouldn't fail*. Have I missed anything or made any mistakes? Please let me know. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1705025716 From azafari at openjdk.org Fri Nov 8 10:52:09 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 8 Nov 2024 10:52:09 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com> <5y5A3NZ0xOQvQ26ao94mbrvFMbF1mLaqyL6YZcTHJ9U=.f73c445f-38b0-4419-bc6d-50e7793d7084@github.com> Message-ID: <0Z4IlT_4DH7rajUP2HfXV55YUiJ_kJnFhpdbD71p52k=.c18e3a38-6c97-497b-9a4c-2724207b454e@github.com> On Tue, 6 Aug 2024 07:12:13 GMT, Johan Sj?len wrote: >> When it is said that an algorithm has the log(n) time-complexity, it means that if the input grows n times, the times grows log(n) times. The tree data-structure has log(n) time-complexity. VMATree may have not exactly log(n) response times due to self-balancing costs. But it is still expected to be less than O(n). > > Hi Afshin, could we take a step back and do some asymptotic time complexity analysis of this problem? > > The test is measuring the following code: > > ```c++ > for (int i = 0; i < n; i++) { > int a = (os::random() % n) * 100; > treap.upsert(a, 0); > } > > > So this algorithm is the tme complexity which we are trying to understand. First, let's simplify the code slightly: > > ```c++ > auto f = [&](auto n) { int a = (os::random() % n) * 100; treap.upsert(a, i); }; > for (int i = 0; i < n; i++) { > f(i); > } > > > Clearly, `f(n)` is executed `n` times, agreed? Then the time complexity of the whole program must be `O(n*f(n))`, correct? It's the time complexity of `f(n)` performed `n` times. > > Let's replace `f` with something else to see if we can understand the time complexity of the whole code snippet again. > > ```c++ > int arr[n]; > auto f = [&](auto n) { arr[n] = 0; }; > for (int i = 0; i < n; i++) { > f(i); > } > > > Now, we both agree that assigning to an array has time complexity `O(1)`, correct? Then, if we fill that in in our expression `O(n * f(n))` we receive `O(n * 1) = O(n)`, correct? In other words, the time complexity of the algorithm the test is measuring is *linear*, and we ought to expect that with an array the time taken for the array should be 10x longer with 10k elements as compared to 1k elements. > > OK, now let's *assume* that `f(n)` has time complexity `O(log n)`, then shouldn't the algorithm we're measuring have time complexity `O(n * log n)`, that is actually *slower* than `O(n)`. > > In conclusion: if `treap.upsert()` has time complexity `O(log n)` then the whole algorithm should have time complexity `O(n * log n)` and the measurements we're seeing are as expected *and the test shouldn't fail*. > > Have I missed anything or made any mistakes? Please let me know. The big O is a _notation_ and is not a math function. So `O(a * b)` is not always same as `O(a) * O(b)`. Stick to this _definition_: "when an algorithm has time-complexity of O(`g(n)`), it means if the input grows `n` times the time of executing the algorithm grows `g(n)` times." Where `g()` is `log()` in our case. IOW, the big O answers the following question: $t_1$ = time for running `f()` for $n_1$ items $t_2$ = time for running `f()` for $n_2$ items if we know $\Large{\frac{n_2}{n_1} = n}$ what is expected value of $t_2$? A detailed description can be found [here](https://en.wikipedia.org/wiki/Big_O_notation). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1705161898 From ihse at openjdk.org Fri Nov 8 11:24:52 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 8 Nov 2024 11:24:52 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v32] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: - Merge branch 'master' into impl-JEP-479 - Remove FIXME - fix: jvm_md.h was included, but not jvm.h... - Update copyright years - Merge branch 'master' into impl-JEP-479 - JVM_EnqueueOperation do not need __stdcall name lookup anymore - [JNI/JVM/AGENT]_[ONLOAD/ONUNLOAD/ONATTACH]_SYMBOLS are now identical on Windows and Unix, so unify them - Fix build_agent_function_name to not handle "@"-stdcall style names - buildJniFunctionName is now identical on Windows and Unix, so unify it - Also restore ADLC_CFLAGS_WARNINGS changes that are not needed any longer - ... and 27 more: https://git.openjdk.org/jdk/compare/0c281acf...a9d56f2f ------------- Changes: https://git.openjdk.org/jdk/pull/21744/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=31 Stats: 1925 lines in 85 files changed: 86 ins; 1572 del; 267 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Fri Nov 8 11:31:40 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 8 Nov 2024 11:31:40 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v33] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Inline buildJniFunctionName ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/a9d56f2f..445515e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=32 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=31-32 Stats: 14 lines in 1 file changed: 4 ins; 9 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Fri Nov 8 11:31:41 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 8 Nov 2024 11:31:41 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <_8hqosvrOekf3ephURXyuAKg9hl2FRpH-tJ-y_PFE6k=.f5ab5105-b4d3-4e5a-ae7d-705838274dc1@github.com> Message-ID: <9-Gr4GhhtLOPX6w1PMSIcvx25_d9-MchNZtIId2mZLg=.79e4368a-412d-42c6-8db7-7288b50cb63e@github.com> On Wed, 6 Nov 2024 21:24:14 GMT, Kim Barrett wrote: >> @kimbarrett I added this to https://bugs.openjdk.org/browse/JDK-8343703. You are not as explicit here as the other places you commented that it is okay to do as a follow-up, but I'll assume that was what you meant. If not, let me know, and I'll look at fixing it for this PR already. > > The first part, eliminating the (IMO not actually helpful) helper function, I wanted done here. The second part, > cleaning up or commenting the calculation of the length and dealing with perhaps unneeded conditionals, I'm > okay with being in a followup. I guess I can live with the first part being in that followup too. Ok, fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834182702 From mli at openjdk.org Fri Nov 8 11:48:09 2024 From: mli at openjdk.org (Hamlin Li) Date: Fri, 8 Nov 2024 11:48:09 GMT Subject: RFR: 8343827: RISC-V: set AlignVector as false if applicable to enable SLP Message-ID: Hi, Can you help to review this patch? SLP vectorization in C2 checks the data alignment optionally, if fast misaliged access is supported by CPU it will skip the alignment check in SLP, this is good for both C2 compile time and run time (as more loops can be potentially vectorized. And the performance of vector implementation is good enough, which was already verified by existing tests (array copy, crc32, ...)). On the other hand, we have some existing tests which verify that generated IRs should contain some specific Nodes, with the intrdocution of Compact Object Header, some tests related to SLP was observed failure which is due to the data offset change which is due to header change in the JEP, by enabling C2 SLP when fast misaliged access is supported, we should be able to resolve these issues. Although riscv support misaligned access optionally, started from RVA22 it's mandatory. Thanks! ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/21974/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21974&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343827 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21974.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21974/head:pull/21974 PR: https://git.openjdk.org/jdk/pull/21974 From jsjolen at openjdk.org Fri Nov 8 12:40:26 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 8 Nov 2024 12:40:26 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 1 Aug 2024 15:44:32 GMT, Afshin Zafari wrote: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. > - Adding a runtime flag for selecting the old or new version can be added later. > - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. I was actually hoping that we could close this PR and open a new one when this moves out of draft, in order to have a clean slate for reviews to start from. This is fine, however. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2464656724 From tschatzl at openjdk.org Fri Nov 8 12:46:29 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Nov 2024 12:46:29 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v3] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 08:32:16 GMT, theoweidmannoracle wrote: >> - Changed several "NULL" in comments to "null" >> - Changed several `NULL` in code to `nullptr` > > theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: > > Fix backslides in test Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21826#pullrequestreview-2423710194 From duke at openjdk.org Fri Nov 8 12:57:30 2024 From: duke at openjdk.org (duke) Date: Fri, 8 Nov 2024 12:57:30 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v3] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 08:32:16 GMT, theoweidmannoracle wrote: >> - Changed several "NULL" in comments to "null" >> - Changed several `NULL` in code to `nullptr` > > theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: > > Fix backslides in test @theoweidmannoracle Your change (at version e79b7bdeaf9bdd13e04814f51858e257ed0f1aa9) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21826#issuecomment-2464687406 From duke at openjdk.org Fri Nov 8 13:31:20 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Fri, 8 Nov 2024 13:31:20 GMT Subject: RFR: 8343837: Remove unnecessary reinterpret_cast from C2AccessValuePtr Message-ID: C2AccessValuePtr contains a reinterpret cast from TypePtr* to its base class Type*. This cast was added in [JDK-8202377](https://bugs.openjdk.org/browse/JDK-8202377), due to a circular dependency problem, which no longer exists. The code compiles fine without it and this cast was removed. Furthermore, a downcast from Type* to TypePtr* exists in this class using reinterpret_cast. This is replaced with the less powerful and more safe static_cast. ------------- Commit messages: - Remove reinterpret_cast Changes: https://git.openjdk.org/jdk/pull/21977/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21977&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343837 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21977.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21977/head:pull/21977 PR: https://git.openjdk.org/jdk/pull/21977 From duke at openjdk.org Fri Nov 8 13:36:34 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Fri, 8 Nov 2024 13:36:34 GMT Subject: Integrated: 8342860: Fix more NULL usage backsliding In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 13:35:56 GMT, theoweidmannoracle wrote: > - Changed several "NULL" in comments to "null" > - Changed several `NULL` in code to `nullptr` This pull request has now been integrated. Changeset: 7d6a2f37 Author: theoweidmannoracle URL: https://git.openjdk.org/jdk/commit/7d6a2f3740bf42652bdf05bb922d1f2b2ae60d6a Stats: 32 lines in 13 files changed: 0 ins; 0 del; 32 mod 8342860: Fix more NULL usage backsliding Reviewed-by: kbarrett, jwaters, tschatzl, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/21826 From duke at openjdk.org Fri Nov 8 13:45:34 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Fri, 8 Nov 2024 13:45:34 GMT Subject: RFR: 8343837: Remove unnecessary reinterpret_cast from C2AccessValuePtr [v2] In-Reply-To: References: Message-ID: > C2AccessValuePtr contains a reinterpret cast from TypePtr* to its base class Type*. This cast was added in [JDK-8202377](https://bugs.openjdk.org/browse/JDK-8202377), due to a circular dependency problem, which no longer exists. The code compiles fine without it and this cast was removed. > > Furthermore, a downcast from Type* to TypePtr* exists in this class using reinterpret_cast. This is replaced with the less powerful and more safe static_cast. theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/gc/shared/c2/barrierSetC2.hpp Co-authored-by: Tobias Hartmann ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21977/files - new: https://git.openjdk.org/jdk/pull/21977/files/f5251e38..dfe4d65e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21977&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21977&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21977.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21977/head:pull/21977 PR: https://git.openjdk.org/jdk/pull/21977 From thartmann at openjdk.org Fri Nov 8 13:45:36 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 8 Nov 2024 13:45:36 GMT Subject: RFR: 8343837: Remove unnecessary reinterpret_cast from C2AccessValuePtr [v2] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 13:42:30 GMT, theoweidmannoracle wrote: >> C2AccessValuePtr contains a reinterpret cast from TypePtr* to its base class Type*. This cast was added in [JDK-8202377](https://bugs.openjdk.org/browse/JDK-8202377), due to a circular dependency problem, which no longer exists. The code compiles fine without it and this cast was removed. >> >> Furthermore, a downcast from Type* to TypePtr* exists in this class using reinterpret_cast. This is replaced with the less powerful and more safe static_cast. > > theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/gc/shared/c2/barrierSetC2.hpp > > Co-authored-by: Tobias Hartmann src/hotspot/share/gc/shared/c2/barrierSetC2.hpp line 97: > 95: C2AccessValue(node, type) {} > 96: > 97: const TypePtr* type() const { return static_cast(_type); } I think this should be: Suggestion: const TypePtr* type() const { return _type->is_ptr(); } Which has the advantage that we assert that the type is as expected. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21977#discussion_r1834423445 From thartmann at openjdk.org Fri Nov 8 13:45:38 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 8 Nov 2024 13:45:38 GMT Subject: RFR: 8343837: Remove unnecessary reinterpret_cast from C2AccessValuePtr [v2] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 13:40:09 GMT, Tobias Hartmann wrote: >> theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/hotspot/share/gc/shared/c2/barrierSetC2.hpp >> >> Co-authored-by: Tobias Hartmann > > src/hotspot/share/gc/shared/c2/barrierSetC2.hpp line 97: > >> 95: C2AccessValue(node, type) {} >> 96: >> 97: const TypePtr* type() const { return static_cast(_type); } > > I think this should be: > > Suggestion: > > const TypePtr* type() const { return _type->is_ptr(); } > > > Which has the advantage that we assert that the type is as expected. And yes the name of this method is suboptimal :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21977#discussion_r1834424016 From apangin at openjdk.org Fri Nov 8 13:47:47 2024 From: apangin at openjdk.org (Andrei Pangin) Date: Fri, 8 Nov 2024 13:47:47 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v17] In-Reply-To: <8gpM6lOT_ncKkCtMDNlwzkC89K-uxWcvzmkv5xxTeaA=.e97688f7-8c2d-4d8a-8e0b-b467d1de9c0d@github.com> References: <8gpM6lOT_ncKkCtMDNlwzkC89K-uxWcvzmkv5xxTeaA=.e97688f7-8c2d-4d8a-8e0b-b467d1de9c0d@github.com> Message-ID: On Thu, 7 Nov 2024 15:11:00 GMT, Johannes Bechberger wrote: >> This is the code for the [JEP draft: CPU Time based profiling for JFR]. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Don't treat stackTrace attribute specially for CPUTimeSamples src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 58: > 56: // This is because RegisterMap uses Handles to support continuations. > 57: ResetNoHandleMark rnhm; > 58: HandleMark hm(jt); HandleMark cannot be used in async-signal-safe context ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1834428400 From pchilanomate at openjdk.org Fri Nov 8 13:48:00 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 8 Nov 2024 13:48:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v4] In-Reply-To: References: Message-ID: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision: - Fix in JvmtiEnvBase::get_locked_objects_in_frame() - Add ObjectWaiter::at_monitorenter ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21565/files - new: https://git.openjdk.org/jdk/pull/21565/files/62b16c6a..3cdb8f86 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=02-03 Stats: 44 lines in 5 files changed: 36 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From pchilanomate at openjdk.org Fri Nov 8 13:48:03 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 8 Nov 2024 13:48:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v4] In-Reply-To: References: Message-ID: <_9UitJwAQtkjVFcSNwxZuuxBI9HaJ3N0fLHTIcVHyk8=.229fa38b-deca-4adf-974f-c8301ae6cd5d@github.com> On Wed, 30 Oct 2024 17:23:31 GMT, Coleen Phillimore wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix in JvmtiEnvBase::get_locked_objects_in_frame() >> - Add ObjectWaiter::at_monitorenter > > src/hotspot/share/oops/stackChunkOop.inline.hpp line 189: > >> 187: inline ObjectMonitor* stackChunkOopDesc::current_pending_monitor() const { >> 188: ObjectWaiter* waiter = object_waiter(); >> 189: if (waiter != nullptr && (waiter->is_monitorenter() || (waiter->is_wait() && (waiter->at_reenter() || waiter->notified())))) { > > Can we hide this conditional under ObjectWaiter::pending_monitor() { all this stuff with a comment; } > > Not sure what this is excluding. I added method `at_monitorenter()` to ObjectWaiter. We are checking if the vthread is blocked trying to acquire (or re-acquire for the wait case) the monitor. While looking at these I also noticed we were missing a call to `current_waiting_monitor` in `JvmtiEnvBase::get_locked_objects_in_frame()` so I added it. We didn?t had a case for this so it went unnoticed. I extended JVMTI test `VThreadMonitorTest.java` to cover this case. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1657: > >> 1655: } >> 1656: >> 1657: template > > This function is kind of big, do we really want it duplicated to pass preempt as a template parameter? I checked and release build is same size and fast/slow debug difference is only about 16kb. Since it doesn?t hurt I would rather not touch the fast paths, but I see `ConfigT` has been unused for some time now so I can do a follow up cleanup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1834427410 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1834425311 From mullan at openjdk.org Fri Nov 8 13:49:55 2024 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 8 Nov 2024 13:49:55 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v9] In-Reply-To: References: Message-ID: > This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. > > NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. > > The code changes can be broken down into roughly the following categories: > > 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. > 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. > 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. > 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). > 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. > > There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. > > Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). > > I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f... Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 224 commits: - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 - Merge branch 'master' into jep486 - Move remaining JEP 486 failing tests into correct groups. - Move JEP 486 failing tests into hotspot_runtime group. - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - ... and 214 more: https://git.openjdk.org/jdk/compare/d0077eec...6ad9192e ------------- Changes: https://git.openjdk.org/jdk/pull/21498/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=08 Stats: 68915 lines in 1889 files changed: 2475 ins; 62597 del; 3843 mod Patch: https://git.openjdk.org/jdk/pull/21498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498 PR: https://git.openjdk.org/jdk/pull/21498 From pchilanomate at openjdk.org Fri Nov 8 13:48:03 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 8 Nov 2024 13:48:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v4] In-Reply-To: <_9UitJwAQtkjVFcSNwxZuuxBI9HaJ3N0fLHTIcVHyk8=.229fa38b-deca-4adf-974f-c8301ae6cd5d@github.com> References: <_9UitJwAQtkjVFcSNwxZuuxBI9HaJ3N0fLHTIcVHyk8=.229fa38b-deca-4adf-974f-c8301ae6cd5d@github.com> Message-ID: <4wpTgmx1V3RtcHOC0q-19yKgMwSg4og_30EdNvz6oA0=.d8be3ea5-7a30-4ec9-89cb-a013318189f2@github.com> On Fri, 8 Nov 2024 13:43:14 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/oops/stackChunkOop.inline.hpp line 189: >> >>> 187: inline ObjectMonitor* stackChunkOopDesc::current_pending_monitor() const { >>> 188: ObjectWaiter* waiter = object_waiter(); >>> 189: if (waiter != nullptr && (waiter->is_monitorenter() || (waiter->is_wait() && (waiter->at_reenter() || waiter->notified())))) { >> >> Can we hide this conditional under ObjectWaiter::pending_monitor() { all this stuff with a comment; } >> >> Not sure what this is excluding. > > I added method `at_monitorenter()` to ObjectWaiter. We are checking if the vthread is blocked trying to acquire (or re-acquire for the wait case) the monitor. While looking at these I also noticed we were missing a call to `current_waiting_monitor` in `JvmtiEnvBase::get_locked_objects_in_frame()` so I added it. We didn?t had a case for this so it went unnoticed. I extended JVMTI test `VThreadMonitorTest.java` to cover this case. Thanks for pointing at this code because I also realized there is a nice cleanup that can be done here. First these methods should be moved to `java_lang_VirtualThread` class where they naturally belong (these are the equivalent of the JavaThread methods but for an unmounted vthread). Also the `objectWaiter` field can be added to the VirtualThread class rather than the stackChunk, which not?only is more appropriate too and gives us the get/set symmetry for these methods, but we can also save memory since one virtual thread can have many stackChunks around. I have a patch for that but I?ll do it after this PR to avoid new changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1834429835 From duke at openjdk.org Fri Nov 8 13:57:19 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Fri, 8 Nov 2024 13:57:19 GMT Subject: RFR: 8343837: Remove unnecessary reinterpret_cast from C2AccessValuePtr [v3] In-Reply-To: References: Message-ID: > C2AccessValuePtr contains a reinterpret cast from TypePtr* to its base class Type*. This cast was added in [JDK-8202377](https://bugs.openjdk.org/browse/JDK-8202377), due to a circular dependency problem, which no longer exists. The code compiles fine without it and this cast was removed. > > Furthermore, a downcast from Type* to TypePtr* exists in this class using reinterpret_cast. This is replaced with Type::is_ptr, which performs the downcast safely by including an assert. theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: Update copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21977/files - new: https://git.openjdk.org/jdk/pull/21977/files/dfe4d65e..35c77fb2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21977&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21977&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21977.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21977/head:pull/21977 PR: https://git.openjdk.org/jdk/pull/21977 From thartmann at openjdk.org Fri Nov 8 13:57:19 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 8 Nov 2024 13:57:19 GMT Subject: RFR: 8343837: Remove unnecessary reinterpret_cast from C2AccessValuePtr [v3] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 13:54:32 GMT, theoweidmannoracle wrote: >> C2AccessValuePtr contains a reinterpret cast from TypePtr* to its base class Type*. This cast was added in [JDK-8202377](https://bugs.openjdk.org/browse/JDK-8202377), due to a circular dependency problem, which no longer exists. The code compiles fine without it and this cast was removed. >> >> Furthermore, a downcast from Type* to TypePtr* exists in this class using reinterpret_cast. This is replaced with Type::is_ptr, which performs the downcast safely by including an assert. > > theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright Looks good and trivial. ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21977#pullrequestreview-2423870389 From mgronlun at openjdk.org Fri Nov 8 14:10:00 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 8 Nov 2024 14:10:00 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v17] In-Reply-To: <8gpM6lOT_ncKkCtMDNlwzkC89K-uxWcvzmkv5xxTeaA=.e97688f7-8c2d-4d8a-8e0b-b467d1de9c0d@github.com> References: <8gpM6lOT_ncKkCtMDNlwzkC89K-uxWcvzmkv5xxTeaA=.e97688f7-8c2d-4d8a-8e0b-b467d1de9c0d@github.com> Message-ID: On Thu, 7 Nov 2024 15:11:00 GMT, Johannes Bechberger wrote: >> This is the code for the [JEP draft: CPU Time based profiling for JFR]. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Don't treat stackTrace attribute specially for CPUTimeSamples AArch64: A fatal error has been detected by the Java Runtime Environment: SIGILL (0x4) at pc=0x0000ffff76288fc8, pid=3163616, tid=3163757 Java VM: Java HotSpot(TM) 64-Bit Server VM (24-internal-2024-11-07-1636009.markus.gronlund.jdkcopy, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) Problematic frame: J 44547 c1 java.lang.invoke.LambdaForm$DMH+0x0000ffff40d0a3a8.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V java.base at 24-internal (14 bytes) @ 0x0000ffff76288fc8 [0x0000ffff76289100+0xfffffffffffffec8] Current thread (0x0000ffff0412fbc0): JfrCPUTimeThreadSampler "JFR CPU Time Thread Sampler" [id=3163757, stack(0x0000fffedc1fd000,0x0000fffedc3fb000) (2040K)] Stack: [0x0000fffedc1fd000,0x0000fffedc3fb000], sp=0x0000fffedc3f9510, free space=2033k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) J 44547 c1 java.lang.invoke.LambdaForm$DMH+0x0000ffff40d0a3a8.invokeStatic(Ljava/lang/Object;Ljava/lang/Object;)V java.base at 24-internal (14 bytes) @ 0x0000ffff76288fc8 [0x0000ffff76289100+0xfffffffffffffec8] V [libjvm.so+0x816ac8] JFRRecordSampledThreadCallback::call()+0x18 (jfrCPUTimeThreadSampler.cpp:531) V [libjvm.so+0xd2e658] ThreadCrashProtection::call(CrashProtectionCallback&)+0x68 (threadCrashProtection_posix.cpp:49) V [libjvm.so+0x815070] JfrCPUTimeThreadSampler::process_trace_queue()+0x290 (jfrCPUTimeThreadSampler.cpp:571) V [libjvm.so+0x815324] JfrCPUTimeThreadSampler::run()+0x114 (jfrCPUTimeThreadSampler.cpp:511) V [libjvm.so+0xd2e2c8] Thread::call_run()+0xa8 (thread.cpp:234) V [libjvm.so+0xb9cf50] thread_native_entry(Thread*)+0xdc (os_linux.cpp:858) C [libpthread.so.0+0x7950] start_thread+0x190 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2464855727 From mli at openjdk.org Fri Nov 8 15:10:46 2024 From: mli at openjdk.org (Hamlin Li) Date: Fri, 8 Nov 2024 15:10:46 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v6] In-Reply-To: References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> Message-ID: On Wed, 6 Nov 2024 06:28:07 GMT, Fei Yang wrote: >> Hi, please consider this cleanup change. >> >> The old trampoline call on linux-riscv64 is disabled by default after: https://bugs.openjdk.org/browse/JDK-8332689. >> And the new solution (load target address from stub and call) has been baked in jdk master for quite some time. >> This propose to remove the old trampoline call related logic so that the code will be cleaner and easier to maintain. >> As we are still using `trampoline_stub_Relocation` for the stub, I kept using the original `emit_trampoline_stub` name. >> >> Testing on linux-riscv64: >> - [x] tier1-tier3 (release) >> - [x] hotspot:tier1 (fastdebug) > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > More naming Thanks for updating. Sorry for the delay. Just had another look, got some questions. src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4227: > 4225: auipc(tmp, (int32_t)distance + 0x800); > 4226: ld(tmp, Address(tmp, ((int32_t)distance << 20) >> 20)); > 4227: jalr(tmp); Seems we can totally remove the usage of `distance`? could be something like below: auipc(tmp, 0); ld(tmp, Address(tmp, 0)); jalr(tmp); ------------- PR Review: https://git.openjdk.org/jdk/pull/21822#pullrequestreview-2424042545 PR Review Comment: https://git.openjdk.org/jdk/pull/21822#discussion_r1834547049 From mli at openjdk.org Fri Nov 8 15:10:47 2024 From: mli at openjdk.org (Hamlin Li) Date: Fri, 8 Nov 2024 15:10:47 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v6] In-Reply-To: References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> Message-ID: On Fri, 8 Nov 2024 15:03:43 GMT, Hamlin Li wrote: >> Fei Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> More naming > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4227: > >> 4225: auipc(tmp, (int32_t)distance + 0x800); >> 4226: ld(tmp, Address(tmp, ((int32_t)distance << 20) >> 20)); >> 4227: jalr(tmp); > > Seems we can totally remove the usage of `distance`? could be something like below: > > auipc(tmp, 0); > ld(tmp, Address(tmp, 0)); > jalr(tmp); If the above simplication make sense, then what we're doing here is to load from pc as the destination addr, then jump to the addr? I could be misunderstanding. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21822#discussion_r1834550104 From duke at openjdk.org Fri Nov 8 16:09:21 2024 From: duke at openjdk.org (Saint Wesonga) Date: Fri, 8 Nov 2024 16:09:21 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 09:41:38 GMT, Julian Waters wrote: > Bumping Reviewing this change today. cc @brianjstafford ------------- PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2465126561 From stuefe at openjdk.org Fri Nov 8 16:10:56 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 8 Nov 2024 16:10:56 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b Marked as reviewed by stuefe (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2424199289 From phh at openjdk.org Fri Nov 8 16:15:14 2024 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 8 Nov 2024 16:15:14 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2424210008 From stefank at openjdk.org Fri Nov 8 16:26:28 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 8 Nov 2024 16:26:28 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2424260100 From coleenp at openjdk.org Fri Nov 8 16:26:28 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 8 Nov 2024 16:26:28 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b Still looks good. Nice work! ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2424274474 From never at openjdk.org Fri Nov 8 16:44:01 2024 From: never at openjdk.org (Tom Rodriguez) Date: Fri, 8 Nov 2024 16:44:01 GMT Subject: RFR: 8338007: [JVMCI] ResolvedJavaMethod.reprofile can crash ciMethodData [v3] In-Reply-To: <4Hg0HCzLxAyCxPaXI-on0epXvyJY3Ap1DJqNK0WoY5w=.60103e4a-fbcd-4a63-98c9-ec68f527a89b@github.com> References: <4Hg0HCzLxAyCxPaXI-on0epXvyJY3Ap1DJqNK0WoY5w=.60103e4a-fbcd-4a63-98c9-ec68f527a89b@github.com> Message-ID: > Graal unit testing uses ResolvedJavaMethod.reprofile to reset profiles between test but the current code rewrites the layout in a non-atomic way which can break other readers. Instead perform the reinitialization at a safepoint which should protect all readers from seeing any transient initialization states. Tom Rodriguez 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 tkr-mdo-reinitialize - Review comments - 8338007: [JVMCI] ResolvedJavaMethod.reprofile can crash ciMethodData ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21746/files - new: https://git.openjdk.org/jdk/pull/21746/files/86c1625c..3543c20b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21746&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21746&range=01-02 Stats: 193040 lines in 1814 files changed: 119909 ins; 51252 del; 21879 mod Patch: https://git.openjdk.org/jdk/pull/21746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21746/head:pull/21746 PR: https://git.openjdk.org/jdk/pull/21746 From rkennke at openjdk.org Fri Nov 8 17:24:05 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 8 Nov 2024 17:24:05 GMT Subject: Integrated: 8305895: Implement JEP 450: Compact Object Headers (Experimental) In-Reply-To: References: Message-ID: On Thu, 22 Aug 2024 13:35:08 GMT, Roman Kennke wrote: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... This pull request has now been integrated. Changeset: 44ec501a Author: Roman Kennke URL: https://git.openjdk.org/jdk/commit/44ec501a41f4794259dd03cd168838e79334890e Stats: 5212 lines in 218 files changed: 3585 ins; 864 del; 763 mod 8305895: Implement JEP 450: Compact Object Headers (Experimental) Co-authored-by: Sandhya Viswanathan Co-authored-by: Martin Doerr Co-authored-by: Hamlin Li Co-authored-by: Thomas Stuefe Co-authored-by: Amit Kumar Co-authored-by: Stefan Karlsson Co-authored-by: Coleen Phillimore Co-authored-by: Axel Boldt-Christmas Reviewed-by: coleenp, stefank, stuefe, phh, ihse, lmesnik, tschatzl, matsaave, rcastanedalo, vpaprotski, yzheng, egahlin ------------- PR: https://git.openjdk.org/jdk/pull/20677 From kvn at openjdk.org Fri Nov 8 17:34:29 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 8 Nov 2024 17:34:29 GMT Subject: RFR: 8343837: Remove unnecessary reinterpret_cast from C2AccessValuePtr [v3] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 13:57:19 GMT, theoweidmannoracle wrote: >> C2AccessValuePtr contains a reinterpret cast from TypePtr* to its base class Type*. This cast was added in [JDK-8202377](https://bugs.openjdk.org/browse/JDK-8202377), due to a circular dependency problem, which no longer exists. The code compiles fine without it and this cast was removed. >> >> Furthermore, a downcast from Type* to TypePtr* exists in this class using reinterpret_cast. This is replaced with Type::is_ptr, which performs the downcast safely by including an assert. > > theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21977#pullrequestreview-2424490420 From rkennke at openjdk.org Fri Nov 8 17:45:40 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 8 Nov 2024 17:45:40 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 12:22:34 GMT, Yudi Zheng wrote: >> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: >> >> - CompressedKlassPointers::is_encodable shall be callable with -UseCCP >> - Johan review feedback > > Could you please cherry pick https://github.com/mur47x111/jdk/commit/c45ebc2a89d0b25a3dd8cc46386e37a635ff9af2 for the JVMCI support? @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2465413222 From yzheng at openjdk.org Fri Nov 8 17:52:05 2024 From: yzheng at openjdk.org (Yudi Zheng) Date: Fri, 8 Nov 2024 17:52:05 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 17:42:24 GMT, Roman Kennke wrote: >> Could you please cherry pick https://github.com/mur47x111/jdk/commit/c45ebc2a89d0b25a3dd8cc46386e37a635ff9af2 for the JVMCI support? > > @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-) @rkennke It is in the merge queue ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2465423342 From duke at openjdk.org Fri Nov 8 17:54:17 2024 From: duke at openjdk.org (Saint Wesonga) Date: Fri, 8 Nov 2024 17:54:17 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v13] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 30 Oct 2024 11:05:17 GMT, Magnus Ihse Bursie wrote: >> make/scripts/compare.sh line 1457: >> >>> 1455: THIS_SEC_BIN="$THIS_SEC_DIR/sec-bin.zip" >>> 1456: if [ "$OPENJDK_TARGET_OS" = "windows" ]; then >>> 1457: JGSS_WINDOWS_BIN="jgss-windows-x64-bin.zip" >> >> This is now being defined for windows-aarch64 too, when it previously wasn't. That seems wrong, >> given the "x64" suffix. > > Well... this was broken on windows-aarch64 before, too, since then it would have looked for `jgss-windows-i586-bin.zip`. > > I'm going to leave this as it is. Obviously there is a lot more work needed to get the compare script running on windows-aarch64, and I seriously doubt anyone care about that platform enough to spend that time (Microsoft themselves seems to have all but abandoned the windows-aarch64 port...). @magicus @kimbarrett @shipilev Thanks for catching this. We want to get this working on Windows AArch64. I have filed https://bugs.openjdk.org/browse/JDK-8343857. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834839335 From aivanov at openjdk.org Fri Nov 8 18:18:07 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 8 Nov 2024 18:18:07 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v9] In-Reply-To: References: Message-ID: On Tue, 29 Oct 2024 17:06:08 GMT, Harshitha Onkar wrote: >> src/java.desktop/share/classes/java/awt/MouseInfo.java line 68: >> >>> 66: * @throws SecurityException if a security manager exists and its >>> 67: * {@code checkPermission} method doesn't allow the operation >>> 68: * @see GraphicsConfiguration >> >> Is `GraphicsConfiguration` removed from the list because it's already mentioned and linked in the description above? Is it intentional? > >> Is it intentional? > > It was probably by mistake. but you are right, I see it mentioned already in the doc. I don't think we need to mention it again? It has a value? when it's mentioned with `@see`, the link is present in the *See Also* section, as you can see in the the specification of [`MouseInfo.getPointerInfo()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/MouseInfo.html#getPointerInfo()). Without the `@see` tag, one has to read the entire description to find the link. It looks subtle. We can restore the `@see`-link later if deemed necessary. Does anyone else have an opinion? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826266398 From duke at openjdk.org Fri Nov 8 18:29:37 2024 From: duke at openjdk.org (Saint Wesonga) Date: Fri, 8 Nov 2024 18:29:37 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v33] In-Reply-To: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> Message-ID: On Fri, 8 Nov 2024 11:31:40 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Inline buildJniFunctionName src/hotspot/os/posix/include/jvm_md.h line 41: > 39: > 40: #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} > 41: #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} are these changes related to the Windows 32-bit x86 port? src/hotspot/os/posix/os_posix.cpp line 699: > 697: } > 698: > 699: void os::print_jni_name_prefix_on(outputStream* st, int args_size) { are these changes related to the Windows 32-bit x86 port? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834878288 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834878195 From honkar at openjdk.org Fri Nov 8 18:36:29 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 8 Nov 2024 18:36:29 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v9] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 20:26:45 GMT, Alexey Ivanov wrote: >>> Is it intentional? >> >> It was probably by mistake. but you are right, I see it mentioned already in the doc. I don't think we need to mention it again? > > It has a value? when it's mentioned with `@see`, the link is present in the *See Also* section, as you can see in the the specification of [`MouseInfo.getPointerInfo()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/MouseInfo.html#getPointerInfo()). > > Without the `@see` tag, one has to read the entire description to find the link. > > It looks subtle. We can restore the `@see`-link later if deemed necessary. > > Does anyone else have an opinion? I can add it back if it is more convenient and readable to have the `@see` tag. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1834883137 From kbarrett at openjdk.org Fri Nov 8 18:53:34 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 8 Nov 2024 18:53:34 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v33] In-Reply-To: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> Message-ID: On Fri, 8 Nov 2024 11:31:40 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Inline buildJniFunctionName Still looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2424652542 From kbarrett at openjdk.org Fri Nov 8 18:53:35 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 8 Nov 2024 18:53:35 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v33] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> Message-ID: <8YGMIrEQv6aPy_9IXzP9VqZ6tB0CTSwnH1XkfkDlXzM=.c1dd03d4-6d33-4dc8-a8b1-691a0616a6a5@github.com> On Fri, 8 Nov 2024 18:26:25 GMT, Saint Wesonga wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Inline buildJniFunctionName > > src/hotspot/os/posix/include/jvm_md.h line 41: > >> 39: >> 40: #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} >> 41: #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} > > are these changes related to the Windows 32-bit x86 port? After removal of Windows 32-bit x86 port, all definitions of these macros are identical, so are merged into jvm.h. There is additional followup work involving these: see https://bugs.openjdk.org/browse/JDK-8343703. > src/hotspot/os/posix/os_posix.cpp line 699: > >> 697: } >> 698: >> 699: void os::print_jni_name_prefix_on(outputStream* st, int args_size) { > > are these changes related to the Windows 32-bit x86 port? As part of removal of Windows 32-bit x86 port, these functions are no longer needed nor called, and all definitions removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834900456 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834900337 From kvn at openjdk.org Fri Nov 8 19:11:41 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 8 Nov 2024 19:11:41 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v33] In-Reply-To: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> Message-ID: On Fri, 8 Nov 2024 11:31:40 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Inline buildJniFunctionName Re-approve. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2424696022 From duke at openjdk.org Fri Nov 8 20:12:19 2024 From: duke at openjdk.org (Saint Wesonga) Date: Fri, 8 Nov 2024 20:12:19 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v33] In-Reply-To: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> Message-ID: On Fri, 8 Nov 2024 11:31:40 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Inline buildJniFunctionName Marked as reviewed by swesonga at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2424836232 From iklam at openjdk.org Fri Nov 8 21:02:16 2024 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 8 Nov 2024 21:02:16 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v10] In-Reply-To: References: Message-ID: <4wG_Fbrs_mcjApZOJqSgVNa5RUMflOwm9G3W4a4OzWQ=.6203c74f-0eaf-47dd-8121-a9e845153265@github.com> > This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). > > ---- > Note: this is a combined PR of the following individual PRs > - https://github.com/openjdk/jdk/pull/20516 > - https://github.com/openjdk/jdk/pull/20517 > - https://github.com/openjdk/jdk/pull/20843 > - https://github.com/openjdk/jdk/pull/20958 > - https://github.com/openjdk/jdk/pull/20959 > - https://github.com/openjdk/jdk/pull/21049 > - https://github.com/openjdk/jdk/pull/21143 Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 177 commits: - fixed merge with UseCompactObjectHeaders - Merge branch 'master' into jep-483-candidate - fixed merge - Merge branch 'master' of https://github.com/openjdk/jdk into merge-mainline - @DanHeidinga comment -- exit VM when runtimeSetup() fails - fixed merge - Merge branch 'master' into jep-483-candidate - 8343493: Perform module checks during MetaspaceShared::map_archives() - reverted changes in modules.cpp to make it easy to merge with mainline - Fixed whitespace; fixed minimal build - ... and 167 more: https://git.openjdk.org/jdk/compare/44ec501a...ce4c93ee ------------- Changes: https://git.openjdk.org/jdk/pull/21642/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=09 Stats: 7193 lines in 107 files changed: 6358 ins; 513 del; 322 mod Patch: https://git.openjdk.org/jdk/pull/21642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642 PR: https://git.openjdk.org/jdk/pull/21642 From prr at openjdk.org Fri Nov 8 21:05:41 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 8 Nov 2024 21:05:41 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v9] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 13:49:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 224 commits: > > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Move remaining JEP 486 failing tests into correct groups. > - Move JEP 486 failing tests into hotspot_runtime group. > - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - ... and 214 more: https://git.openjdk.org/jdk/compare/d0077eec...6ad9192e Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2424915104 From prr at openjdk.org Fri Nov 8 21:05:42 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 8 Nov 2024 21:05:42 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 18:06:47 GMT, Alexey Ivanov wrote: > > I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used. But I don't see a problem with keeping the rest of the test. > > @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`? > > The [`MultiUIDefaults` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java) is used in `UIManager`: > > https://github.com/openjdk/jdk/blob/c82ad845e101bf5d97c0744377d68002907d4a0e/src/java.desktop/share/classes/javax/swing/UIManager.java#L198 I think I was just saying there appeared to be dead code in the test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1835053637 From mgronlun at openjdk.org Fri Nov 8 21:42:09 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 8 Nov 2024 21:42:09 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows Message-ID: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Greetings, This enhancement adds register printouts on asserts or guarantees into the hs_err_pid.log error reporting files for Windows. Additionally, it saves an accurate EXCEPTION_RECORD into the hs_err_pid.mdmp file, also for asserts or guarantees, so the assertion context is now easily accessible in Windbg using .ecxr. For more details on this enhancement, please see the JIRA issue. Testing: Tier 1,2,3, jdk_jfr Thanks Markus ------------- Commit messages: - slight modifications - 8343756 Changes: https://git.openjdk.org/jdk/pull/21994/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21994&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343756 Stats: 210 lines in 11 files changed: 120 ins; 32 del; 58 mod Patch: https://git.openjdk.org/jdk/pull/21994.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21994/head:pull/21994 PR: https://git.openjdk.org/jdk/pull/21994 From mgronlun at openjdk.org Fri Nov 8 21:48:25 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 8 Nov 2024 21:48:25 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v2] In-Reply-To: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: > Greetings, > > This enhancement adds register printouts on asserts or guarantees into the hs_err_pid.log error reporting files for Windows. > > Additionally, it saves an accurate EXCEPTION_RECORD into the hs_err_pid.mdmp file, also for asserts or guarantees, so the assertion context is now easily accessible in Windbg using .ecxr. > > For more details on this enhancement, please see the JIRA issue. > > Testing: Tier 1,2,3, jdk_jfr > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: initialize report page ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21994/files - new: https://git.openjdk.org/jdk/pull/21994/files/7fc55f3f..9b80c688 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21994&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21994&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21994.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21994/head:pull/21994 PR: https://git.openjdk.org/jdk/pull/21994 From duke at openjdk.org Fri Nov 8 23:08:16 2024 From: duke at openjdk.org (Saint Wesonga) Date: Fri, 8 Nov 2024 23:08:16 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken In-Reply-To: References: <9C3_nSzX9UY6959Q1mpv1JpE7MMQ8l9JvRWUWSOuRQY=.e8928e43-8664-4de1-b240-3dca1f4ab4af@github.com> <31Dtdw2Xv9w5M6KbSN4lkHhpflbU3Nw123ZincFNHuk=.0c68c7e0-797b-4185-b59b-de2a49d29bd9@github.com> Message-ID: On Fri, 8 Nov 2024 09:43:47 GMT, Julian Waters wrote: >> If it's needed on AArch64 too, this should move to something in `os/windows` as David said. >> >> However, judging from the comment in https://github.com/openjdk/jdk/blob/c40bb7621c0e49581dac587b6900b6d281572813/src/hotspot/os/windows/sharedRuntimeRem.cpp#L34-L38 this workaround might not be needed anymore. The minimum version required for Windows-AArch64 is VS2017 (or even VS2019?), and for Windows-X64 apparently VS2022 is used (not sure what the minimum is): https://github.com/openjdk/jdk/blob/c40bb7621c0e49581dac587b6900b6d281572813/make/conf/jib-profiles.js#L1105 >> >> >> So maybe this can be removed altogether? Someone needs to check if this assumption is still true today. >> >> Alas I don't have a Windows setup anymore. @karianna who is the local HotSpot Windows expert these days who could have a look at this? ? > > I don't think this workaround was intended for ARM64 in the first place, it explicitly mentions that it was written for x64, and the ifdef mess that resulted in this bug ended up bringing it over to ARM64 The minimum Visual Studio version required to build the Windows AArch64 port is VS 2022 via the DevKit - https://wiki.openjdk.org/display/Build/Supported+Build+Platforms I'm now verifying whether this workaround is still needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1835137108 From sviswanathan at openjdk.org Fri Nov 8 23:20:29 2024 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 8 Nov 2024 23:20:29 GMT Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle implementation [v2] In-Reply-To: References: Message-ID: On Sun, 6 Oct 2024 10:24:53 GMT, Quan Anh Mai wrote: >> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> [vectorapi] Refactor VectorShuffle implementation > > I have adapted the patch in accordance with https://github.com/openjdk/jdk/pull/20634, I moved the index wrapping into C2 instead of making it a separate step as I think it seems clearer. Also, I think in the future we can eliminate this step so putting it in C2 would make the progress easier. > > Please take a look, thanks a lot. @merykitty Could you please merge with the latest and resolve conflicts? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2465889165 From weijun at openjdk.org Sat Nov 9 00:57:23 2024 From: weijun at openjdk.org (Weijun Wang) Date: Sat, 9 Nov 2024 00:57:23 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v9] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 13:49:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 224 commits: > > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Move remaining JEP 486 failing tests into correct groups. > - Move JEP 486 failing tests into hotspot_runtime group. > - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - ... and 214 more: https://git.openjdk.org/jdk/compare/d0077eec...6ad9192e Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2425106253 From stuefe at openjdk.org Sat Nov 9 07:24:10 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 9 Nov 2024 07:24:10 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v33] In-Reply-To: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> Message-ID: On Fri, 8 Nov 2024 11:31:40 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Inline buildJniFunctionName Still looks good to me. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2425254474 From fyang at openjdk.org Mon Nov 11 02:31:38 2024 From: fyang at openjdk.org (Fei Yang) Date: Mon, 11 Nov 2024 02:31:38 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v7] In-Reply-To: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> Message-ID: <14IasQU3f3Q1Lw__swFWCrX7d0ZpAdX8D_QTBtbHLTo=.4e88a911-e2a2-4934-9013-8a72ffa9c8bc@github.com> > Hi, please consider this cleanup change. > > The old trampoline call on linux-riscv64 is disabled by default after: https://bugs.openjdk.org/browse/JDK-8332689. > And the new solution (load target address from stub and call) has been baked in jdk master for quite some time. > This propose to remove the old trampoline call related logic so that the code will be cleaner and easier to maintain. > As we are still using `trampoline_stub_Relocation` for the stub, I kept using the original `emit_trampoline_stub` name. > > Testing on linux-riscv64: > - [x] tier1-tier3 (release) > - [x] hotspot:tier1 (fastdebug) Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - More Comments - Merge remote-tracking branch 'upstream/master' into JDK-8343430 - More naming - More improvements - Minor - More comments - Comment - Improve - Code comment - Merge remote-tracking branch 'upstream/master' into JDK-8343430 - ... and 1 more: https://git.openjdk.org/jdk/compare/7b0f273e...ad6df2fe ------------- Changes: https://git.openjdk.org/jdk/pull/21822/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21822&range=06 Stats: 632 lines in 12 files changed: 9 ins; 546 del; 77 mod Patch: https://git.openjdk.org/jdk/pull/21822.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21822/head:pull/21822 PR: https://git.openjdk.org/jdk/pull/21822 From fyang at openjdk.org Mon Nov 11 02:35:14 2024 From: fyang at openjdk.org (Fei Yang) Date: Mon, 11 Nov 2024 02:35:14 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v6] In-Reply-To: References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> Message-ID: On Fri, 8 Nov 2024 15:05:44 GMT, Hamlin Li wrote: >> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4227: >> >>> 4225: auipc(tmp, (int32_t)distance + 0x800); >>> 4226: ld(tmp, Address(tmp, ((int32_t)distance << 20) >> 20)); >>> 4227: jalr(tmp); >> >> Seems we can totally remove the usage of `distance`? could be something like below: >> >> auipc(tmp, 0); >> ld(tmp, Address(tmp, 0)); >> jalr(tmp); > > If the above simplication make sense, then what we're doing here is to load from pc as the destination addr, then jump to the addr? I could be misunderstanding. Thanks. I removed `distance` and simplified the code as suggested. Note that the use of PC as address here is only temporary. The relocation created while emitting the stub will ensure this call sequence is subsequently patched to call the stub. I have added code comments for to help understand. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21822#discussion_r1835886176 From fyang at openjdk.org Mon Nov 11 03:08:53 2024 From: fyang at openjdk.org (Fei Yang) Date: Mon, 11 Nov 2024 03:08:53 GMT Subject: RFR: 8343827: RISC-V: set AlignVector as false if applicable to enable SLP In-Reply-To: References: Message-ID: <1-Sfuv3vdbuICkLsMnfChXYZ6NaEVfJvbhltJel1EFY=.dff9c8f8-fc74-47f6-b569-4cb8fe01af91@github.com> On Fri, 8 Nov 2024 11:40:46 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > SLP vectorization in C2 checks the data alignment optionally, if fast misaliged access is supported by CPU it will skip the alignment check in SLP, this is good for both C2 compile time and run time (as more loops can be potentially vectorized. And the performance of vector implementation is good enough, which was already verified by existing tests (array copy, crc32, ...)). > On the other hand, we have some existing tests which verify that generated IRs should contain some specific Nodes, with the intrdocution of Compact Object Header, some tests related to SLP was observed failure which is due to the data offset change which is due to header change in the JEP, by enabling C2 SLP when fast misaliged access is supported, we should be able to resolve these issues. Although riscv support misaligned access optionally, started from RVA22 it's mandatory. > > Thanks! Looks fine. Thanks. ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21974#pullrequestreview-2426032870 From duke at openjdk.org Mon Nov 11 07:01:39 2024 From: duke at openjdk.org (duke) Date: Mon, 11 Nov 2024 07:01:39 GMT Subject: RFR: 8343837: Remove unnecessary reinterpret_cast from C2AccessValuePtr [v3] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 13:57:19 GMT, theoweidmannoracle wrote: >> C2AccessValuePtr contains a reinterpret cast from TypePtr* to its base class Type*. This cast was added in [JDK-8202377](https://bugs.openjdk.org/browse/JDK-8202377), due to a circular dependency problem, which no longer exists. The code compiles fine without it and this cast was removed. >> >> Furthermore, a downcast from Type* to TypePtr* exists in this class using reinterpret_cast. This is replaced with Type::is_ptr, which performs the downcast safely by including an assert. > > theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright @theoweidmannoracle Your change (at version 35c77fb2736c0f13dc27aa3edadb10191e58df26) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21977#issuecomment-2467380617 From kbarrett at openjdk.org Mon Nov 11 07:23:20 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 11 Nov 2024 07:23:20 GMT Subject: RFR: 8343837: Remove unnecessary reinterpret_cast from C2AccessValuePtr [v3] In-Reply-To: References: Message-ID: <0WZp_pTDHW99UkRdGRCYaHyUOvfktgGbsj6exuECcj8=.2ef0a08b-edb9-4fb2-ae43-a441e26ee744@github.com> On Fri, 8 Nov 2024 13:57:19 GMT, theoweidmannoracle wrote: >> C2AccessValuePtr contains a reinterpret cast from TypePtr* to its base class Type*. This cast was added in [JDK-8202377](https://bugs.openjdk.org/browse/JDK-8202377), due to a circular dependency problem, which no longer exists. The code compiles fine without it and this cast was removed. >> >> Furthermore, a downcast from Type* to TypePtr* exists in this class using reinterpret_cast. This is replaced with Type::is_ptr, which performs the downcast safely by including an assert. > > theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright Looks good. I very much approve of unnecessary cast removals. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21977#issuecomment-2467409622 From kbarrett at openjdk.org Mon Nov 11 07:27:38 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 11 Nov 2024 07:27:38 GMT Subject: RFR: 8343837: Remove unnecessary reinterpret_cast from C2AccessValuePtr [v3] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 13:57:19 GMT, theoweidmannoracle wrote: >> C2AccessValuePtr contains a reinterpret cast from TypePtr* to its base class Type*. This cast was added in [JDK-8202377](https://bugs.openjdk.org/browse/JDK-8202377), due to a circular dependency problem, which no longer exists. The code compiles fine without it and this cast was removed. >> >> Furthermore, a downcast from Type* to TypePtr* exists in this class using reinterpret_cast. This is replaced with Type::is_ptr, which performs the downcast safely by including an assert. > > theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright Marked as reviewed by kbarrett (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21977#pullrequestreview-2426287253 From duke at openjdk.org Mon Nov 11 08:21:04 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Mon, 11 Nov 2024 08:21:04 GMT Subject: Integrated: 8343837: Remove unnecessary reinterpret_cast from C2AccessValuePtr In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 13:25:26 GMT, theoweidmannoracle wrote: > C2AccessValuePtr contains a reinterpret cast from TypePtr* to its base class Type*. This cast was added in [JDK-8202377](https://bugs.openjdk.org/browse/JDK-8202377), due to a circular dependency problem, which no longer exists. The code compiles fine without it and this cast was removed. > > Furthermore, a downcast from Type* to TypePtr* exists in this class using reinterpret_cast. This is replaced with Type::is_ptr, which performs the downcast safely by including an assert. This pull request has now been integrated. Changeset: 5b2f7f3b Author: theoweidmannoracle Committer: Tobias Hartmann URL: https://git.openjdk.org/jdk/commit/5b2f7f3b30adf9942fa8a3382e7661d6816fbb38 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8343837: Remove unnecessary reinterpret_cast from C2AccessValuePtr Reviewed-by: thartmann, kvn, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/21977 From azafari at openjdk.org Mon Nov 11 09:59:19 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 11 Nov 2024 09:59:19 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Fri, 8 Nov 2024 12:36:37 GMT, Johan Sj?len wrote: > I was actually hoping that we could close this PR and open a new one when this moves out of draft, in order to have a clean slate for reviews to start from. This is fine, however. Sorry. Maybe I misinterpreted when it is said that "... remove the draft state..". ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2467705855 From jsjolen at openjdk.org Mon Nov 11 10:02:24 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 11 Nov 2024 10:02:24 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Mon, 11 Nov 2024 09:55:44 GMT, Afshin Zafari wrote: > > I was actually hoping that we could close this PR and open a new one when this moves out of draft, in order to have a clean slate for reviews to start from. This is fine, however. > > Sorry. Maybe I misinterpreted when it is said that "... remove the draft state..". No, I think you interpreted Thomas correctly. I don't think Thomas was aware of my wishes :-). ------------- PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2467717580 From jbechberger at openjdk.org Mon Nov 11 10:34:32 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Mon, 11 Nov 2024 10:34:32 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v18] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Added more comments around queue implementation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/9f96cc0c..027a7e34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=16-17 Stats: 35 lines in 1 file changed: 23 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From azafari at openjdk.org Mon Nov 11 10:40:05 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 11 Nov 2024 10:40:05 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v2] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. > - Adding a runtime flag for selecting the old or new version can be added later. > - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - added some descriptions of how VMT works. - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - fixes after merge with use_tag_inplace - fixed merged glitches. - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - snaphot thread stack updated and tested. - removed unnecessary line from visit committed region function. - fixed hpp gaurd of vmtCommon. - ... and 34 more: https://git.openjdk.org/jdk/compare/cbe8448f...52631e4d ------------- Changes: https://git.openjdk.org/jdk/pull/20425/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=01 Stats: 3294 lines in 55 files changed: 1520 ins; 1525 del; 249 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From ayang at openjdk.org Mon Nov 11 11:10:28 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 11 Nov 2024 11:10:28 GMT Subject: RFR: 8343931: Removed unused code in CompressedKlassPointers::initialize_for_given_encoding Message-ID: Trivial removing dead code. ------------- Commit messages: - trivial Changes: https://git.openjdk.org/jdk/pull/22007/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22007&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343931 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22007.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22007/head:pull/22007 PR: https://git.openjdk.org/jdk/pull/22007 From azafari at openjdk.org Mon Nov 11 11:55:12 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 11 Nov 2024 11:55:12 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v3] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. > - Adding a runtime flag for selecting the old or new version can be added later. > - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: gc/x directory removed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20425/files - new: https://git.openjdk.org/jdk/pull/20425/files/52631e4d..7bd065ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=01-02 Stats: 207 lines in 1 file changed: 0 ins; 207 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From jbechberger at openjdk.org Mon Nov 11 12:01:27 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Mon, 11 Nov 2024 12:01:27 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v19] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Don't walk continuations in signal handler ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/027a7e34..32d8e642 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=17-18 Stats: 11 lines in 3 files changed: 1 ins; 3 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From jbechberger at openjdk.org Mon Nov 11 12:01:27 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Mon, 11 Nov 2024 12:01:27 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v4] In-Reply-To: References: <2NwYW96LtQYBAH_mSxlo24yxc5IWMcy9Mql1TKTLpIs=.a8c69824-c239-473f-bec6-bbb678a90c39@github.com> Message-ID: On Wed, 6 Nov 2024 13:47:36 GMT, Johannes Bechberger wrote: >> That is both interesting (and worrying). I'm going to write a test for the latter issue. > >> NoHandleMark will not work with with continuations. Please see how we do it in JfrStackTrace::record() > > Thank you. > >> This indicates that the event is turned on, despite "enabled" being false. Is there a bug in the control / enable setting mechanism? > > I was unable to reproduce the issue but I removed the control attribute because I don't think that users would expect CPU sampling to be enabled when they set `method-sampling-enabled`. This hopefully solves your issue. As pointed out by @apangin, the `HandleMark` can not be used in the signal handler. I therefore use `NoHandleMark` and added a parameter to vframestream to be able to disable walking continuations in the CPU time sampler. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1836559860 From chagedorn at openjdk.org Mon Nov 11 13:00:27 2024 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 11 Nov 2024 13:00:27 GMT Subject: RFR: 8343931: Removed unused code in CompressedKlassPointers::initialize_for_given_encoding In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 11:04:30 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. Looks good and trivial. ------------- Marked as reviewed by chagedorn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22007#pullrequestreview-2427229608 From jbechberger at openjdk.org Mon Nov 11 13:37:49 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Mon, 11 Nov 2024 13:37:49 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v20] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Fix ActiveSetting event for CPUTimeSamples ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/32d8e642..26615497 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=18-19 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From cnorrbin at openjdk.org Mon Nov 11 13:59:36 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 11 Nov 2024 13:59:36 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v5] In-Reply-To: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: > Hi everyone, > > String interning can be done on 4 different types of strings: > - oop-strings (unicode) > - oop-strings (latin1) > - Symbols (non-null-terminated utf8) > - null-terminated utf8 char arrays > > Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table. > > This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation. > > This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations. > > Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build) > > 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types. > Also tested and passes tiers 1-3. Casper Norrbin has updated the pull request incrementally with 834 additional commits since the last revision: - missed cast - size field moved to string wrapper - 8341408: Implement JEP 488: Primitive Types in Patterns, instanceof, and switch (Second Preview) Reviewed-by: vromero, jlahoda - 8341834: C2 compilation fails with "bad AD file" due to Replicate Reviewed-by: kvn, epeter - 8343068: C2: CastX2P Ideal transformation not always applied Reviewed-by: kvn, thartmann - 8339303: C2: dead node after failing to match cloned address expression Reviewed-by: vlivanov, kvn - 8331341: secondary_super_cache does not scale well: C1 and interpreter Reviewed-by: vlivanov, kvn, dlong - 8318442: java/net/httpclient/ManyRequests2.java fails intermittently on Linux Reviewed-by: mdoerr, lucy, dfuchs - 8343502: RISC-V: SIGBUS in updateBytesCRC32 after JDK-8339738 Reviewed-by: mli, fjiang - 8342943: Replace predicate walking and cloning code for main/post loops with a predicate visitor Reviewed-by: roland, kvn - ... and 824 more: https://git.openjdk.org/jdk/compare/cc7530cd...d292368f ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21325/files - new: https://git.openjdk.org/jdk/pull/21325/files/cc7530cd..d292368f Webrevs: - full: Webrev is not available because diff is too large - incr: Webrev is not available because diff is too large Stats: 473839 lines in 4140 files changed: 353094 ins; 85714 del; 35031 mod Patch: https://git.openjdk.org/jdk/pull/21325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21325/head:pull/21325 PR: https://git.openjdk.org/jdk/pull/21325 From vkempik at openjdk.org Mon Nov 11 14:21:17 2024 From: vkempik at openjdk.org (Vladimir Kempik) Date: Mon, 11 Nov 2024 14:21:17 GMT Subject: RFR: 8343827: RISC-V: set AlignVector as false if applicable to enable SLP In-Reply-To: References: Message-ID: <0rUg0wmZafd2bryZhoWsF8J9ErP7ijXZxXw0OwMeoeY=.f0502abe-d80b-40eb-8c4c-a992bea3af9c@github.com> On Fri, 8 Nov 2024 11:40:46 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > SLP vectorization in C2 checks the data alignment optionally, if fast misaliged access is supported by CPU it will skip the alignment check in SLP, this is good for both C2 compile time and run time (as more loops can be potentially vectorized. And the performance of vector implementation is good enough, which was already verified by existing tests (array copy, crc32, ...)). > On the other hand, we have some existing tests which verify that generated IRs should contain some specific Nodes, with the intrdocution of Compact Object Header, some tests related to SLP was observed failure which is due to the data offset change which is due to header change in the JEP, by enabling C2 SLP when fast misaliged access is supported, we should be able to resolve these issues. Although riscv support misaligned access optionally, started from RVA22 it's mandatory. > > Thanks! hello Hamlin, this could to be wrong. for example: kendryte 230 with c908 core with rv64gcv it has fast misaligned access but only for scalars(rv64gc), not for vectors(rvv) i dont know if it's just a corner case or a possible common practice in future. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21974#issuecomment-2468288871 From ayang at openjdk.org Mon Nov 11 14:24:18 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 11 Nov 2024 14:24:18 GMT Subject: RFR: 8343931: Removed unused code in CompressedKlassPointers::initialize_for_given_encoding In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 11:04:30 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. Thanks for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22007#issuecomment-2468294448 From ayang at openjdk.org Mon Nov 11 14:24:18 2024 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 11 Nov 2024 14:24:18 GMT Subject: Integrated: 8343931: Removed unused code in CompressedKlassPointers::initialize_for_given_encoding In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 11:04:30 GMT, Albert Mingkun Yang wrote: > Trivial removing dead code. This pull request has now been integrated. Changeset: babb52a0 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/babb52a08361b00eb4bc6e2e109b1fdc198dbd59 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8343931: Removed unused code in CompressedKlassPointers::initialize_for_given_encoding Reviewed-by: chagedorn ------------- PR: https://git.openjdk.org/jdk/pull/22007 From cnorrbin at openjdk.org Mon Nov 11 14:45:43 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 11 Nov 2024 14:45:43 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v6] In-Reply-To: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: > Hi everyone, > > String interning can be done on 4 different types of strings: > - oop-strings (unicode) > - oop-strings (latin1) > - Symbols (non-null-terminated utf8) > - null-terminated utf8 char arrays > > Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table. > > This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation. > > This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations. > > Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build) > > 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types. > Also tested and passes tiers 1-3. Casper Norrbin 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: size moved to wrapper ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21325/files - new: https://git.openjdk.org/jdk/pull/21325/files/d292368f..2ab24441 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21325&range=05 - incr: Webrev is not available because diff is too large Stats: 473840 lines in 4136 files changed: 85718 ins; 353197 del; 34925 mod Patch: https://git.openjdk.org/jdk/pull/21325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21325/head:pull/21325 PR: https://git.openjdk.org/jdk/pull/21325 From cnorrbin at openjdk.org Mon Nov 11 15:06:15 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 11 Nov 2024 15:06:15 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v6] In-Reply-To: References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: <4u58jdguj3NcAOhDsi3PG2YaEN43swGaxyP7dCCTcK8=.8459716b-069a-4979-9c4a-73b3827241ed@github.com> On Mon, 11 Nov 2024 14:45:43 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> String interning can be done on 4 different types of strings: >> - oop-strings (unicode) >> - oop-strings (latin1) >> - Symbols (non-null-terminated utf8) >> - null-terminated utf8 char arrays >> >> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table. >> >> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation. >> >> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations. >> >> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build) >> >> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types. >> Also tested and passes tiers 1-3. > > Casper Norrbin 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: > > size moved to wrapper After some investigation, I identified that the failing test mentioned above was due to complex strings in classes with older classfile versions not passing the verification check in `create_from_symbol`. The checks assume ?correct UTF8", which older classfile versions do not necessarily conform to. To address this, I re-added the check for valid UTF8 I had before. This issue did not appear previously because the conversion to Unicode bypassed these checks, though the conversion process is functionally identical to that in `create_from_symbol`. To ensure correctness, I re-ran all tests with additional asserts added to confirm that the created string objects match those created by first converting symbols to unicode. All strings were identical, and the observed behaviour was consistent with the previous implementation. Additionally, I updated how string lengths are handled: UTF8/ambigous lengths now use `size_t` and conversions to `int`s are performed when calling external functions requiring Unicode length. The `equals` functions in `CompactHashtable` requires an `int` length, which is incompatible with the larger UTF8 sizes, so I resolved this by storing the length within the string wrapper instead. This change allows us to only pass the wrapped string between functions without the length. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21325#issuecomment-2468390681 From egahlin at openjdk.org Mon Nov 11 15:38:23 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Mon, 11 Nov 2024 15:38:23 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v20] In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 13:37:49 GMT, Johannes Bechberger wrote: >> This is the code for the [JEP draft: CPU Time based profiling for JFR]. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Fix ActiveSetting event for CPUTimeSamples src/jdk.jfr/share/classes/jdk/jfr/internal/util/TimespanRate.java line 50: > 48: return new TimespanRate(Runtime.getRuntime().availableProcessors() / (period / 1_000_000_000.0), false); > 49: } > 50: return new TimespanRate(Rate.of(text).perSecond(), true); What if the rate contained in text is not valid? Shouldn't it be: Rate r = Rate.of(text); return r == null ? null : new TimespanRate(r.perSecond(), true); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1836854538 From jbechberger at openjdk.org Mon Nov 11 16:08:59 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Mon, 11 Nov 2024 16:08:59 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v21] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Make parsing rates safer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/26615497..9cafdbc8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=19-20 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From aivanov at openjdk.org Mon Nov 11 17:43:07 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 11 Nov 2024 17:43:07 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 21:01:57 GMT, Phil Race wrote: >>> I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used. But I don't see a problem with keeping the rest of the test. >> >> @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`? >> >> The [`MultiUIDefaults` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java) is used in `UIManager`: >> >> https://github.com/openjdk/jdk/blob/c82ad845e101bf5d97c0744377d68002907d4a0e/src/java.desktop/share/classes/javax/swing/UIManager.java#L198 > >> > I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used. But I don't see a problem with keeping the rest of the test. >> >> @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`? >> >> The [`MultiUIDefaults` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java) is used in `UIManager`: >> >> https://github.com/openjdk/jdk/blob/c82ad845e101bf5d97c0744377d68002907d4a0e/src/java.desktop/share/classes/javax/swing/UIManager.java#L198 > > I think I was just saying there appeared to be dead code in the test. > > @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`? > > I think I was just saying there appeared to be dead code in the test. Hmm? `createPrivateValue` had been called from the `main` method, so it had been used in the test until it was removed in https://github.com/openjdk/jdk/commit/9eb275c4aaf9a88127c5c33e0bf7ca35125f29ea Since `MultiUIDefaults` is still used in `UIManager` and we're keeping the test, I'm for keeping a test for `createPrivateValue` too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1837009964 From mli at openjdk.org Mon Nov 11 21:34:16 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 11 Nov 2024 21:34:16 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v7] In-Reply-To: <14IasQU3f3Q1Lw__swFWCrX7d0ZpAdX8D_QTBtbHLTo=.4e88a911-e2a2-4934-9013-8a72ffa9c8bc@github.com> References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> <14IasQU3f3Q1Lw__swFWCrX7d0ZpAdX8D_QTBtbHLTo=.4e88a911-e2a2-4934-9013-8a72ffa9c8bc@github.com> Message-ID: <9OaoBC_A_RexPK4vHf_fvJtWySrlhdcuDwVl_8-ECV0=.4e27923a-43b9-467f-96f9-daf23ecfa6db@github.com> On Mon, 11 Nov 2024 02:31:38 GMT, Fei Yang wrote: >> Hi, please consider this cleanup change. >> >> The old trampoline call on linux-riscv64 is disabled by default after: https://bugs.openjdk.org/browse/JDK-8332689. >> And the new solution (load target address from stub and call) has been baked in jdk master for quite some time. >> This propose to remove the old trampoline call related logic so that the code will be cleaner and easier to maintain. >> As we are still using `trampoline_stub_Relocation` for the stub, I kept using the original `emit_trampoline_stub` name. >> >> Testing on linux-riscv64: >> - [x] tier1-tier3 (release) >> - [x] hotspot:tier1 (fastdebug) > > Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - More Comments > - Merge remote-tracking branch 'upstream/master' into JDK-8343430 > - More naming > - More improvements > - Minor > - More comments > - Comment > - Improve > - Code comment > - Merge remote-tracking branch 'upstream/master' into JDK-8343430 > - ... and 1 more: https://git.openjdk.org/jdk/compare/7b0f273e...ad6df2fe Updating also looks good to me. Thanks! ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21822#pullrequestreview-2428209829 From mli at openjdk.org Mon Nov 11 21:34:16 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 11 Nov 2024 21:34:16 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v6] In-Reply-To: References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> Message-ID: On Mon, 11 Nov 2024 02:32:26 GMT, Fei Yang wrote: >> If the above simplication make sense, then what we're doing here is to load from pc as the destination addr, then jump to the addr? I could be misunderstanding. > > Thanks. I removed `distance` and simplified the code as suggested. Note that the use of PC as address here is only temporary. The relocation created while emitting the stub will ensure this call sequence is subsequently patched to call the stub. I have added code comments for to help understand. Thanks for updating and explanation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21822#discussion_r1837230369 From dholmes at openjdk.org Tue Nov 12 00:14:39 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 12 Nov 2024 00:14:39 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v6] In-Reply-To: References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: On Mon, 11 Nov 2024 14:45:43 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> String interning can be done on 4 different types of strings: >> - oop-strings (unicode) >> - oop-strings (latin1) >> - Symbols (non-null-terminated utf8) >> - null-terminated utf8 char arrays >> >> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table. >> >> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation. >> >> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations. >> >> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build) >> >> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types. >> Also tested and passes tiers 1-3. > > Casper Norrbin 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: > > size moved to wrapper Looking good. I like the internalization of the length into StringWrapper. A couple of nits/queries. Thanks src/hotspot/share/classfile/javaClasses.cpp line 393: > 391: #ifdef ASSERT > 392: // This check is too strict on older classfile versions > 393: if (UTF8::is_legal_utf8((const unsigned char*)utf8_str, utf8_len, /*version_leq_47*/false)) I don't see the point of this check. Any validation would/should be done when the Symbol is created, not when it is later used. src/hotspot/share/classfile/javaClasses.hpp line 184: > 182: } > 183: > 184: static unsigned int hash_code(const char *utf8_str, size_t utf8_len) { Suggestion: static unsigned int hash_code(const char* utf8_str, size_t utf8_len) { src/hotspot/share/classfile/stringTable.cpp line 153: > 151: } > 152: > 153: bool StringTable::wrapped_string_equals(oop java_string, StringWrapper wrapped_str, int _) { Not sure what hotspot style rules are for unused parameters. Probably worth a comment as to why this unused parameter exists. src/hotspot/share/classfile/stringTable.cpp line 421: > 419: switch (wrapped_str.type) { > 420: case StringType::UnicodeStr: > 421: return wrapped_str.unicode_str; This doesn't set `len`. src/hotspot/share/classfile/stringTable.cpp line 445: > 443: } > 444: > 445: Handle StringTable::to_handle(StringWrapper wrapped_str, TRAPS) { `to_handle` is a bit too generic - it's like saying `to_pointer`. You are returning the Handle form of a java.lang.String oop. src/hotspot/share/classfile/stringTable.hpp line 83: > 81: typedef struct StringWrapperInternal StringWrapper; > 82: > 83: static bool wrapped_string_equals(oop java_string, StringWrapper wrapped_str, int _ = 0); One thing I can't quite connect the dots on here, is what gets passed as the unused length when this is called from the table code? ------------- PR Review: https://git.openjdk.org/jdk/pull/21325#pullrequestreview-2428231859 PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1837245814 PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1837316465 PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1837247002 PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1837319659 PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1837322352 PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1837325852 From fyang at openjdk.org Tue Nov 12 00:26:07 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 12 Nov 2024 00:26:07 GMT Subject: RFR: 8343827: RISC-V: set AlignVector as false if applicable to enable SLP In-Reply-To: <0rUg0wmZafd2bryZhoWsF8J9ErP7ijXZxXw0OwMeoeY=.f0502abe-d80b-40eb-8c4c-a992bea3af9c@github.com> References: <0rUg0wmZafd2bryZhoWsF8J9ErP7ijXZxXw0OwMeoeY=.f0502abe-d80b-40eb-8c4c-a992bea3af9c@github.com> Message-ID: On Mon, 11 Nov 2024 14:18:28 GMT, Vladimir Kempik wrote: > hello Hamlin, this could to be wrong. for example: kendryte 230 with c908 core with rv64gcv it has fast misaligned access but only for scalars(rv64gc), not for vectors(rvv) i dont know if it's just a corner case or a possible common practice in future. Interesting. Could it be an issue for the kernel running on this platform? I don't understand why it would declare fast misaligned access when it's not the case for the vector part. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21974#issuecomment-2469341899 From dholmes at openjdk.org Tue Nov 12 00:54:51 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 12 Nov 2024 00:54:51 GMT Subject: RFR: 8340212: -Xshare:off -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64 [v2] In-Reply-To: References: Message-ID: On Thu, 24 Oct 2024 22:39:18 GMT, Coleen Phillimore wrote: >> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64. This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated. >> >> Tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > include formatBuffer.hpp ProblemList needs updating when this is fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21695#issuecomment-2469367195 From ysr at openjdk.org Tue Nov 12 02:34:43 2024 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Tue, 12 Nov 2024 02:34:43 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v3] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 22 Oct 2024 17:12:38 GMT, Zhengyu Gu wrote: >> Congratulations! Good to see the great progress. I just built this PR for some testing and found something unexpected. I ran the genshen VS shenandoah(default) with jbb2015 on aarch64 N2 with 8 cores and Xmx8g. The critical-jOPS of genshen(5373) is behind shenandoah(6027). Do I miss something on the options? >> ```java -Xmx8g -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCHeuristics=adaptive -XX:ShenandoahGCMode=generational -Xlog:gc* -XX:MetaspaceSize=1g -jar specjbb2015.jar -m COMPOSITE``` > >> @mmyxym , Thank you for testing this out! I apologize for not responding to your comment sooner. We run specjbb2015 regularly in our integration pipeline. We see a slight improvement with the generational mode; certainly no regression: >> >> ``` >> Shen: RUN RESULT: hbIR (max attempted) = 4701, hbIR (settled) = 3934, max-jOPS = 3620, critical-jOPS = 2375 >> Gen: RUN RESULT: hbIR (max attempted) = 3934, hbIR (settled) = 3295, max-jOPS = 4013, critical-jOPS = 2470 >> Shen: RUN RESULT: hbIR (max attempted) = 4701, hbIR (settled) = 3934, max-jOPS = 3667, critical-jOPS = 2397 >> Gen: RUN RESULT: hbIR (max attempted) = 4701, hbIR (settled) = 3934, max-jOPS = 3996, critical-jOPS = 2414 >> ``` >> >> These results were produced with these arguments: >> >> ``` >> -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticV >> MOptions -XX:-TieredCompilation -XX:-ShenandoahPacing -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -Xmx10g -Xms10g -XX:ShenandoahGCMode=generational >> ``` >> >> These runs executed on a Graviton2 host with 4 cores, 16G. I'll run again on a host with more cores and with your exact command line parameters. > > What's the reason to disable tiered compilation? @zhengyu123 and @shipilev : could you please take another look and leave your review feedback and/or approval? We'd like to land the changes this week if possible. Currently internal testing is in progress after merging with the latest changes from tip. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2469466977 From pchilanomate at openjdk.org Tue Nov 12 02:59:59 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 12 Nov 2024 02:59:59 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v5] In-Reply-To: References: Message-ID: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo 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 'master' into JDK-8338383 - Test StopThreadTest.java: fix operator in condition + improve names - Pass -XX:-UseCompactObjectHeaders in test JNIMonitor.java - Merge branch 'master' into JDK-8338383 - Fix in JvmtiEnvBase::get_locked_objects_in_frame() - Add ObjectWaiter::at_monitorenter - Use get_method_name + copyright revert in jvmtiThreadState.cpp - Merge branch 'master' into JDK-8338383 - Add @requires vm.continuations to CancelTimerWithContention.java - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount - ... and 80 more: https://git.openjdk.org/jdk/compare/babb52a0...0fe60465 ------------- Changes: https://git.openjdk.org/jdk/pull/21565/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=04 Stats: 9984 lines in 249 files changed: 7169 ins; 1629 del; 1186 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From pchilanomate at openjdk.org Tue Nov 12 03:04:35 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 12 Nov 2024 03:04:35 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v5] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 02:59:59 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo 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 'master' into JDK-8338383 > - Test StopThreadTest.java: fix operator in condition + improve names > - Pass -XX:-UseCompactObjectHeaders in test JNIMonitor.java > - Merge branch 'master' into JDK-8338383 > - Fix in JvmtiEnvBase::get_locked_objects_in_frame() > - Add ObjectWaiter::at_monitorenter > - Use get_method_name + copyright revert in jvmtiThreadState.cpp > - Merge branch 'master' into JDK-8338383 > - Add @requires vm.continuations to CancelTimerWithContention.java > - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount > - ... and 80 more: https://git.openjdk.org/jdk/compare/babb52a0...0fe60465 I merged with master, including the changes for [JEP 450](https://github.com/openjdk/jdk/pull/20677), and run it through tiers1-8 in mach5 with no related failures. I would like to integrate tomorrow if I could get some re-approvals. Also, I filed JDK-8343957 to possibly improve the naming of `_lock_id/owner_from` as discussed in some of the comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2469493942 From jwaters at openjdk.org Tue Nov 12 03:33:59 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 12 Nov 2024 03:33:59 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v6] In-Reply-To: References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: On Mon, 11 Nov 2024 21:52:42 GMT, David Holmes wrote: >> Casper Norrbin 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: >> >> size moved to wrapper > > src/hotspot/share/classfile/stringTable.cpp line 153: > >> 151: } >> 152: >> 153: bool StringTable::wrapped_string_equals(oop java_string, StringWrapper wrapped_str, int _) { > > Not sure what hotspot style rules are for unused parameters. Probably worth a comment as to why this unused parameter exists. A quick search of the Style Guide yields nothing. I'd prefer the existing name be kept, but if it really shouldn't be used, then an unnamed parameter will suffice, no need for giving it _ as a name ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1837433599 From dholmes at openjdk.org Tue Nov 12 07:09:12 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 12 Nov 2024 07:09:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v5] In-Reply-To: References: Message-ID: <3vfCjVBL-b8oC8v_8fW5QdXjAT1ssSjfPgFoNL1fNu0=.d7efc5eb-3e84-42b5-b8ce-9c9cc11900bf@github.com> On Tue, 12 Nov 2024 02:59:59 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo 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 'master' into JDK-8338383 > - Test StopThreadTest.java: fix operator in condition + improve names > - Pass -XX:-UseCompactObjectHeaders in test JNIMonitor.java > - Merge branch 'master' into JDK-8338383 > - Fix in JvmtiEnvBase::get_locked_objects_in_frame() > - Add ObjectWaiter::at_monitorenter > - Use get_method_name + copyright revert in jvmtiThreadState.cpp > - Merge branch 'master' into JDK-8338383 > - Add @requires vm.continuations to CancelTimerWithContention.java > - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount > - ... and 80 more: https://git.openjdk.org/jdk/compare/babb52a0...0fe60465 Still good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2428723863 From rehn at openjdk.org Tue Nov 12 07:10:12 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 12 Nov 2024 07:10:12 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v7] In-Reply-To: <14IasQU3f3Q1Lw__swFWCrX7d0ZpAdX8D_QTBtbHLTo=.4e88a911-e2a2-4934-9013-8a72ffa9c8bc@github.com> References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> <14IasQU3f3Q1Lw__swFWCrX7d0ZpAdX8D_QTBtbHLTo=.4e88a911-e2a2-4934-9013-8a72ffa9c8bc@github.com> Message-ID: On Mon, 11 Nov 2024 02:31:38 GMT, Fei Yang wrote: >> Hi, please consider this cleanup change. >> >> The old trampoline call on linux-riscv64 is disabled by default after: https://bugs.openjdk.org/browse/JDK-8332689. >> And the new solution (load target address from stub and call) has been baked in jdk master for quite some time. >> This propose to remove the old trampoline call related logic so that the code will be cleaner and easier to maintain. >> As we are still using `trampoline_stub_Relocation` for the stub, I kept using the original `emit_trampoline_stub` name. >> >> Testing on linux-riscv64: >> - [x] tier1-tier3 (release) >> - [x] hotspot:tier1 (fastdebug) > > Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - More Comments > - Merge remote-tracking branch 'upstream/master' into JDK-8343430 > - More naming > - More improvements > - Minor > - More comments > - Comment > - Improve > - Code comment > - Merge remote-tracking branch 'upstream/master' into JDK-8343430 > - ... and 1 more: https://git.openjdk.org/jdk/compare/7b0f273e...ad6df2fe Marked as reviewed by rehn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21822#pullrequestreview-2428725002 From fyang at openjdk.org Tue Nov 12 07:18:34 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 12 Nov 2024 07:18:34 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v7] In-Reply-To: <14IasQU3f3Q1Lw__swFWCrX7d0ZpAdX8D_QTBtbHLTo=.4e88a911-e2a2-4934-9013-8a72ffa9c8bc@github.com> References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> <14IasQU3f3Q1Lw__swFWCrX7d0ZpAdX8D_QTBtbHLTo=.4e88a911-e2a2-4934-9013-8a72ffa9c8bc@github.com> Message-ID: On Mon, 11 Nov 2024 02:31:38 GMT, Fei Yang wrote: >> Hi, please consider this cleanup change. >> >> The old trampoline call on linux-riscv64 is disabled by default after: https://bugs.openjdk.org/browse/JDK-8332689. >> And the new solution (load target address from stub and call) has been baked in jdk master for quite some time. >> This propose to remove the old trampoline call related logic so that the code will be cleaner and easier to maintain. >> As we are still using `trampoline_stub_Relocation` for the stub, I kept using the original `emit_trampoline_stub` name. >> >> Testing on linux-riscv64: >> - [x] tier1-tier3 (release) >> - [x] hotspot:tier1 (fastdebug) > > Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - More Comments > - Merge remote-tracking branch 'upstream/master' into JDK-8343430 > - More naming > - More improvements > - Minor > - More comments > - Comment > - Improve > - Code comment > - Merge remote-tracking branch 'upstream/master' into JDK-8343430 > - ... and 1 more: https://git.openjdk.org/jdk/compare/7b0f273e...ad6df2fe Thanks. I will wait a while for JEP 491 to land as I see this has conflict with that big change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21822#issuecomment-2469766373 From vkempik at openjdk.org Tue Nov 12 07:46:46 2024 From: vkempik at openjdk.org (Vladimir Kempik) Date: Tue, 12 Nov 2024 07:46:46 GMT Subject: RFR: 8343827: RISC-V: set AlignVector as false if applicable to enable SLP In-Reply-To: References: <0rUg0wmZafd2bryZhoWsF8J9ErP7ijXZxXw0OwMeoeY=.f0502abe-d80b-40eb-8c4c-a992bea3af9c@github.com> Message-ID: On Tue, 12 Nov 2024 00:22:27 GMT, Fei Yang wrote: > > hello Hamlin, this could to be wrong. for example: kendryte 230 with c908 core with rv64gcv it has fast misaligned access but only for scalars(rv64gc), not for vectors(rvv) i dont know if it's just a corner case or a possible common practice in future. > > Interesting. Could it be an issue for the kernel running on this platform? I don't understand why it would declare fast misaligned access when it's not the case for the vector part. for this particular case, it has kernel 5.10 which has no hwprobe. so avoidUnaligned has to be disabled manually. but there are more boards based on c908 core which needs to be checked with this change. while the c908 isnt the thing we should care much about, right now i think boards with c908 are the main test mule to check jdk rvv performance changes ------------- PR Comment: https://git.openjdk.org/jdk/pull/21974#issuecomment-2469809440 From enikitin at openjdk.org Tue Nov 12 08:24:36 2024 From: enikitin at openjdk.org (Evgeny Nikitin) Date: Tue, 12 Nov 2024 08:24:36 GMT Subject: RFR: 8344003: WB: Add option to skip clinit during class loading for testing Message-ID: This PR adds a White-Box controlled option to skip `clinit` methods during class loading. Such a feature would allow for non-executing testing techniques of random and untrusted jars/classes in CI systems without being afraid of breaking or harming the running system. The clinit skipping does not affect core libraries (i.e. those under `java`, `jdk` and `sun` packages), and will only be available in debug builds. ------------- Commit messages: - 8344003: WB: Add option to skip clinit during class loading for testing Changes: https://git.openjdk.org/jdk/pull/22030/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22030&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344003 Stats: 75 lines in 5 files changed: 71 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22030.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22030/head:pull/22030 PR: https://git.openjdk.org/jdk/pull/22030 From mli at openjdk.org Tue Nov 12 09:56:41 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 12 Nov 2024 09:56:41 GMT Subject: RFR: 8343827: RISC-V: set AlignVector as false if applicable to enable SLP In-Reply-To: References: <0rUg0wmZafd2bryZhoWsF8J9ErP7ijXZxXw0OwMeoeY=.f0502abe-d80b-40eb-8c4c-a992bea3af9c@github.com> Message-ID: On Tue, 12 Nov 2024 07:44:34 GMT, Vladimir Kempik wrote: > hello Hamlin, this could to be wrong. for example: kendryte 230 with c908 core with rv64gcv it has fast misaligned access but only for scalars(rv64gc), not for vectors(rvv) i dont know if it's just a corner case or a possible common practice in future. Thanks for bring up this test case. I have the similar question in mind, if a hardware claims to support misaligned fast access, seems it should support both scalar and vector. > for this particular case, it has kernel 5.10 which has no hwprobe. so avoidUnaligned has to be disabled manually. Yes, the default behaviour is to use hwprobe to test the CPU features, so for k 230, the default behaviour should be fine, i.e. both `AlignVector` and `AvoidUnalignedAccesses` would be true, nothing changed. > but there are more boards based on c908 core which needs to be checked with this change. while the c908 isnt the thing we should care much about, right now i think boards with c908 are the main test mule to check jdk rvv performance changes I'm not quite sure if we should test on each of the potential boards, seems to me we should not. What we need do should be to test CPU features based on hwprobe if unaligned fast access is supported or not, and enable/disable JDK features accordingly. In this way, our tests should be easy and get most of performance gain for common cases, and if there is a cornor case (claim to support but does not actaully), then the user could still disable it manually. I'll wait for other tests/comments ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/21974#issuecomment-2470077713 From aboldtch at openjdk.org Tue Nov 12 10:16:15 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 12 Nov 2024 10:16:15 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v5] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 02:59:59 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo 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 'master' into JDK-8338383 > - Test StopThreadTest.java: fix operator in condition + improve names > - Pass -XX:-UseCompactObjectHeaders in test JNIMonitor.java > - Merge branch 'master' into JDK-8338383 > - Fix in JvmtiEnvBase::get_locked_objects_in_frame() > - Add ObjectWaiter::at_monitorenter > - Use get_method_name + copyright revert in jvmtiThreadState.cpp > - Merge branch 'master' into JDK-8338383 > - Add @requires vm.continuations to CancelTimerWithContention.java > - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount > - ... and 80 more: https://git.openjdk.org/jdk/compare/babb52a0...0fe60465 Marked as reviewed by aboldtch (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2429155294 From roland at openjdk.org Tue Nov 12 10:21:48 2024 From: roland at openjdk.org (Roland Westrelin) Date: Tue, 12 Nov 2024 10:21:48 GMT Subject: RFR: 8341411: C2: remove slice parameter from GraphKit::make_load() and GraphKit::store_to_memory() [v5] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 09:16:03 GMT, theoweidmannoracle wrote: >> This patch removes the address type from `GraphKit::make_load()` and `GraphKit::store_to_memory()` >> >> As https://github.com/openjdk/jdk/pull/21303 introduced asserts that check that the address type agrees with `C->get_alias_index(_gvn.type(adr)->isa_ptr()`, passing the address type is redundant and it can be computed internally from the address. > > theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: > > Fix asserts Looks good to me. I'm wondering it we can go further and in: Node* LoadNode::make(PhaseGVN& gvn, Node* ctl, Node* mem, Node* adr, const TypePtr* adr_type, const Type* rt, BasicType bt, MemOrd mo, ControlDependency control_dependency, bool require_atomic_access, bool unaligned, bool mismatched, bool unsafe, uint8_t barrier_data) { remove the adr_type parameter (because it should be `gvn.type(adr)`). Something similar must be possible for `Store`. Then in the gc api: C2AccessValuePtr addr(adr, adr_type); C2ParseAccess access(this, decorators | C2_READ_ACCESS, bt, obj, addr); would we even need to pass `adr_type`? Do we want to file a bug about to, at least, give it a try? ------------- Marked as reviewed by roland (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21834#pullrequestreview-2429164805 From mli at openjdk.org Tue Nov 12 10:21:48 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 12 Nov 2024 10:21:48 GMT Subject: Integrated: 8343600: RISC-V: enable CRC32 intrinsic when either Zba or RVV are supported In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 09:44:21 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > There were 2 intrinsic optimizations, scalar one and vector one, > * plain scalar one optimizes cases when data size is small, scalar one with zba optimizes cases when data size is big; > * vector one optimizes cases when data size is big (better than scalar one with zba). > > With RVV supported, when the size is small it will go to scalar code path, when the size is big it will go to RVV path then scalar path, so that means the RVV itself are sufficient enough to enable the intrinsic even without Zba supported. > > Thanks! This pull request has now been integrated. Changeset: 2c1e4c38 Author: Hamlin Li URL: https://git.openjdk.org/jdk/commit/2c1e4c381615ce52276f4bf331a1e7a845af4b6e Stats: 34 lines in 1 file changed: 18 ins; 16 del; 0 mod 8343600: RISC-V: enable CRC32 intrinsic when either Zba or RVV are supported Reviewed-by: fyang ------------- PR: https://git.openjdk.org/jdk/pull/21897 From mgronlun at openjdk.org Tue Nov 12 10:37:29 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 12 Nov 2024 10:37:29 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v2] In-Reply-To: References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: On Fri, 8 Nov 2024 21:48:25 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> This enhancement adds register printouts on asserts or guarantees into the hs_err_pid.log error reporting files for Windows. >> >> Additionally, it saves an accurate EXCEPTION_RECORD into the hs_err_pid.mdmp file, also for asserts or guarantees, so the assertion context is now easily accessible in Windbg using .ecxr. >> >> For more details on this enhancement, please see the JIRA issue. >> >> Testing: Tier 1,2,3, jdk_jfr >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > initialize report page Perhaps @tstuefe would be kind to take a look? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21994#issuecomment-2470171515 From stuefe at openjdk.org Tue Nov 12 11:44:51 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 12 Nov 2024 11:44:51 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v2] In-Reply-To: References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: On Tue, 12 Nov 2024 10:34:30 GMT, Markus Gr?nlund wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> initialize report page > > Perhaps @tstuefe would be kind to take a look? @mgronlun Sure, I can take a look. Did the POSIX version change at all or is it just code movement? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21994#issuecomment-2470311323 From mullan at openjdk.org Tue Nov 12 13:01:33 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 12 Nov 2024 13:01:33 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v10] In-Reply-To: References: Message-ID: <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com> > This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. > > NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. > > The code changes can be broken down into roughly the following categories: > > 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. > 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. > 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. > 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). > 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. > > There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. > > Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). > > I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f... Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 229 commits: - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 - Merge branch 'master' into jep486 - Move remaining JEP 486 failing tests into correct groups. - Move JEP 486 failing tests into hotspot_runtime group. - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing - ... and 219 more: https://git.openjdk.org/jdk/compare/2ec35808...b7b95a40 ------------- Changes: https://git.openjdk.org/jdk/pull/21498/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=09 Stats: 68915 lines in 1889 files changed: 2475 ins; 62597 del; 3843 mod Patch: https://git.openjdk.org/jdk/pull/21498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498 PR: https://git.openjdk.org/jdk/pull/21498 From szaldana at openjdk.org Tue Nov 12 13:17:35 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 12 Nov 2024 13:17:35 GMT Subject: Integrated: 8300732: Whitebox functions for Metaspace test should use byte size In-Reply-To: References: Message-ID: <8jc5QX1LTjBu285NhrjHkhLKHrgjrSWixt0i44O7Qh8=.5ccd7407-5369-4946-8628-8cc6df8f2d36@github.com> On Thu, 4 Jul 2024 15:18:29 GMT, Sonia Zaldana Calles wrote: > Hi all, > > This PR addresses [8300732](https://bugs.openjdk.org/browse/JDK-8300732) switching Whitebox Metaspace test functions to use bytes as opposed to words. > > Testing: > - [x] `test/hotspot/jtreg/runtime/Metaspace` tests pass. > > Thanks, > Sonia This pull request has now been integrated. Changeset: 50b6e41e Author: Sonia Zaldana Calles URL: https://git.openjdk.org/jdk/commit/50b6e41e0e8d6575061996a48077fb809bede8e4 Stats: 162 lines in 13 files changed: 71 ins; 0 del; 91 mod 8300732: Whitebox functions for Metaspace test should use byte size Reviewed-by: stuefe, asmehra ------------- PR: https://git.openjdk.org/jdk/pull/20039 From kevinw at openjdk.org Tue Nov 12 14:18:27 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 12 Nov 2024 14:18:27 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v10] In-Reply-To: <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com> References: <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com> Message-ID: On Tue, 12 Nov 2024 13:01:33 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 229 commits: > > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Move remaining JEP 486 failing tests into correct groups. > - Move JEP 486 failing tests into hotspot_runtime group. > - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing > - ... and 219 more: https://git.openjdk.org/jdk/compare/2ec35808...b7b95a40 Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429727015 From tanksherman27 at gmail.com Tue Nov 12 14:20:28 2024 From: tanksherman27 at gmail.com (Julian Waters) Date: Tue, 12 Nov 2024 22:20:28 +0800 Subject: Win32AttachOperationRequest seems to be using global new? Message-ID: Hi all, Win32AttachOperationRequest is created via new, but doesn't specify a custom new inside the class definition. The result seems to be that we use global new on Windows: for (int i=0; i f7: IMAGE_REL_AMD64_REL32 operator new(unsigned long long) Stepping away from gcc's objdump and using the Microsoft dumpbin alongside cl.exe instead, the result is this: 0000000000000264: B9 28 0D 00 00 mov ecx,0D28h 0000000000000269: E8 00 00 00 00 call ??2 at YAPEAX_K@Z 000000000000026E: 48 89 44 24 28 mov qword ptr [rsp+28h],rax 0000000000000273: 48 83 7C 24 28 00 cmp qword ptr [rsp+28h],0 0000000000000279: 74 11 je 000000000000028C 000000000000027B: 48 8B 4C 24 28 mov rcx,qword ptr [rsp+28h] 0000000000000280: E8 00 00 00 00 call ??0Win32AttachOperationRequest@@QEAA at XZ undname "??2 at YAPEAX_K@Z" Microsoft (R) C++ Name Undecorator Copyright (C) Microsoft Corporation. All rights reserved. Undecoration of :- "??2 at YAPEAX_K@Z" is :- "void * __ptr64 __cdecl operator new(unsigned __int64)" undname "??0Win32AttachOperationRequest@@QEAA at XZ" Microsoft (R) C++ Name Undecorator Copyright (C) Microsoft Corporation. All rights reserved. Undecoration of :- "??0Win32AttachOperationRequest@@QEAA at XZ" is :- "public: __cdecl Win32AttachOperationRequest::Win32AttachOperationRequest(void) __ptr64" Visual Studio, lacking the nm utility, obviously doesn't catch this. What was more surprising is that the gcc Link Time check also fails to catch it as well. I had to manually check the output of nm after an unrelated failure and happened to stumble across the symbols _Znwy and _ZdlPvy which both correspond to operator new(unsigned long long) operator delete(void*, unsigned long long) The delete can be ignored, it's the result of a bug on my experimental branch (It was first discovered there, then I tested it on master). I'm more interested about the new, since it seems to be violating a HotSpot rule. Is this an intentional exception to the rule, or an oversight? best regards, Julian -------------- next part -------------- An HTML attachment was scrubbed... URL: From rriggs at openjdk.org Tue Nov 12 14:25:10 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 12 Nov 2024 14:25:10 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v10] In-Reply-To: <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com> References: <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com> Message-ID: On Tue, 12 Nov 2024 13:01:33 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 229 commits: > > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Move remaining JEP 486 failing tests into correct groups. > - Move JEP 486 failing tests into hotspot_runtime group. > - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing > - ... and 219 more: https://git.openjdk.org/jdk/compare/2ec35808...b7b95a40 Good to go! ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429741829 From mullan at openjdk.org Tue Nov 12 14:44:55 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 12 Nov 2024 14:44:55 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11] In-Reply-To: References: Message-ID: > This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. > > NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. > > The code changes can be broken down into roughly the following categories: > > 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. > 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. > 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. > 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). > 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. > > There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. > > Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). > > I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f... Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits: - Merge - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 - Merge branch 'master' into jep486 - Move remaining JEP 486 failing tests into correct groups. - Move JEP 486 failing tests into hotspot_runtime group. - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e ------------- Changes: https://git.openjdk.org/jdk/pull/21498/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=10 Stats: 68915 lines in 1889 files changed: 2475 ins; 62597 del; 3843 mod Patch: https://git.openjdk.org/jdk/pull/21498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498 PR: https://git.openjdk.org/jdk/pull/21498 From kevinw at openjdk.org Tue Nov 12 14:48:36 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 12 Nov 2024 14:48:36 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits: > > - Merge > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Move remaining JEP 486 failing tests into correct groups. > - Move JEP 486 failing tests into hotspot_runtime group. > - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429813961 From mgronlun at openjdk.org Tue Nov 12 14:52:55 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 12 Nov 2024 14:52:55 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v2] In-Reply-To: References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: <8_Uo-upq2wVUxaUHG81-WSf-1Liin3conuMQxnh3XPE=.a46d81d5-5519-49ce-bda5-c77ec8e2b94e@github.com> On Tue, 12 Nov 2024 10:34:30 GMT, Markus Gr?nlund wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> initialize report page > > Perhaps @tstuefe would be kind to take a look? > @mgronlun Sure, I can take a look. Did the POSIX version change at all or is it just code movement? The POSIX version have been kept intact, the changes intend to move the usages of OS-specific types (ucontext_t and EXECPTION_POINTERS et al) out from utilities/debug.cpp, to keep it os-agnostic, and let OS specific handlers call into it (for disarm and context save (now os specific)). There are also some simplifications and const-correctness. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21994#issuecomment-2470739266 From rriggs at openjdk.org Tue Nov 12 14:55:29 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 12 Nov 2024 14:55:29 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits: > > - Merge > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Move remaining JEP 486 failing tests into correct groups. > - Move JEP 486 failing tests into hotspot_runtime group. > - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429830332 From cnorrbin at openjdk.org Tue Nov 12 15:01:19 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Tue, 12 Nov 2024 15:01:19 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v7] In-Reply-To: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: > Hi everyone, > > String interning can be done on 4 different types of strings: > - oop-strings (unicode) > - oop-strings (latin1) > - Symbols (non-null-terminated utf8) > - null-terminated utf8 char arrays > > Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table. > > This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation. > > This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations. > > Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build) > > 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types. > Also tested and passes tiers 1-3. Casper Norrbin 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 nine additional commits since the last revision: - more feedback + formatting - Merge branch 'master' into stringtable--intern-refactor - size moved to wrapper - feedback from david - missed cleanup - length param change + feedback - feedback from johan - string conversion + intern tests - multi-type string interning ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21325/files - new: https://git.openjdk.org/jdk/pull/21325/files/2ab24441..4a78433c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21325&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21325&range=05-06 Stats: 489501 lines in 4426 files changed: 364811 ins; 87939 del; 36751 mod Patch: https://git.openjdk.org/jdk/pull/21325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21325/head:pull/21325 PR: https://git.openjdk.org/jdk/pull/21325 From mullan at openjdk.org Tue Nov 12 15:05:09 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 12 Nov 2024 15:05:09 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 18:31:13 GMT, Harshitha Onkar wrote: >> It has a value? when it's mentioned with `@see`, the link is present in the *See Also* section, as you can see in the the specification of [`MouseInfo.getPointerInfo()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/MouseInfo.html#getPointerInfo()). >> >> Without the `@see` tag, one has to read the entire description to find the link. >> >> It looks subtle. We can restore the `@see`-link later if deemed necessary. >> >> Does anyone else have an opinion? > > I can add it back if it is more convenient and readable to have the `@see` tag. This can be taken care of later after integration. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838260852 From mullan at openjdk.org Tue Nov 12 15:05:14 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 12 Nov 2024 15:05:14 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3] In-Reply-To: References: Message-ID: <-KIDgN-bR6eT5GTOj2hiyz0oLJXR7Ewx1taEzXeaRsw=.3d2f141a-8183-4f70-af74-c06b47f29478@github.com> On Thu, 24 Oct 2024 17:03:25 GMT, Alexey Ivanov wrote: >> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits: >> >> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 >> - Merge >> - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module". >> - Remove println about Security Manager. >> - Remove unused static variable NEW_PROXY_IN_PKG. >> - Remove static variable `DEFAULT_POLICY` and unused imports. >> - Remove hasSM() method and code that calls it, and remove comment about >> running test manually with SM. >> - clientlibs: import order >> - warning-string >> - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java >> - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde > > test/jdk/java/beans/Introspector/7084904/Test7084904.java line 31: > >> 29: * @library .. >> 30: * @run main Test7084904 >> 31: * @author Sergey Malenkov > > The test below `Test4683761.java` removes the `@author` tag. Should it be removed here? This can be handled later in a more general cleanup task. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838259103 From mullan at openjdk.org Tue Nov 12 15:05:15 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 12 Nov 2024 15:05:15 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 19:40:03 GMT, Alexey Ivanov wrote: >> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits: >> >> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 >> - Modify three RMI tests to work without the security manager: >> - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java >> - test/jdk/java/rmi/registry/readTest/CodebaseTest.java >> - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java >> Also remove them from the problem list. >> - Remove two obsolete RMI tests: >> - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java >> - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java >> Adjust two tests to run without the Security Manager: >> - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java >> - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java >> Remove all of these tests from the problem list. >> - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows. >> - Added API Notes to ProtectionDomain clarifying that the current policy always >> grants no permissions. A few other small changes to Policy and PD. >> - Merge branch 'master' into jep486 >> - JAXP tests: organize imports of a few tests >> - Improve description of Executors.privilegedThreadFactory >> - rename TestAppletLoggerContext.java as suggested in util test review >> - clientlibs: Javadoc cleanup >> - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b > > test/jdk/javax/sound/midi/Soundbanks/EmptySoundBankTest.java line 1: > >> 1: /* > > I wonder if we should add an Oracle copyright to the update test file. I don't think it is necessary for that small of a change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838256317 From cnorrbin at openjdk.org Tue Nov 12 15:11:11 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Tue, 12 Nov 2024 15:11:11 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v6] In-Reply-To: References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: <2cZau0zoCfliUll_TmzrjcLR3sL-YF5tJhXkYIGO-UA=.b0be3c96-fb51-4dc1-99de-4febca3d1556@github.com> On Tue, 12 Nov 2024 00:04:12 GMT, David Holmes wrote: >> Casper Norrbin 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: >> >> size moved to wrapper > > src/hotspot/share/classfile/stringTable.cpp line 445: > >> 443: } >> 444: >> 445: Handle StringTable::to_handle(StringWrapper wrapped_str, TRAPS) { > > `to_handle` is a bit too generic - it's like saying `to_pointer`. You are returning the Handle form of a java.lang.String oop. Renamed this to `handle_from_wrapped_string`, should be clearer and less ambiguous. > src/hotspot/share/classfile/stringTable.hpp line 83: > >> 81: typedef struct StringWrapperInternal StringWrapper; >> 82: >> 83: static bool wrapped_string_equals(oop java_string, StringWrapper wrapped_str, int _ = 0); > > One thing I can't quite connect the dots on here, is what gets passed as the unused length when this is called from the table code? Inside the hash table, the equals function is called from `lookup`, where the caller passes the length as a parameter. In our case, this is in `lookup_shared`: https://github.com/openjdk/jdk/blob/4a78433cd33530186b7638a6aefd0e73ec50a3d5/src/hotspot/share/classfile/stringTable.cpp?plain=1#L904-L908 I added an explaining comment as to why 0 is passed instead of the actual length. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1838271037 PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1838269438 From pchilanomate at openjdk.org Tue Nov 12 15:16:12 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 12 Nov 2024 15:16:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v5] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 02:59:59 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo 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 'master' into JDK-8338383 > - Test StopThreadTest.java: fix operator in condition + improve names > - Pass -XX:-UseCompactObjectHeaders in test JNIMonitor.java > - Merge branch 'master' into JDK-8338383 > - Fix in JvmtiEnvBase::get_locked_objects_in_frame() > - Add ObjectWaiter::at_monitorenter > - Use get_method_name + copyright revert in jvmtiThreadState.cpp > - Merge branch 'master' into JDK-8338383 > - Add @requires vm.continuations to CancelTimerWithContention.java > - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount > - ... and 80 more: https://git.openjdk.org/jdk/compare/babb52a0...0fe60465 Many thanks to all reviewers and contributors of this JEP! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2470802813 From cnorrbin at openjdk.org Tue Nov 12 15:16:34 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Tue, 12 Nov 2024 15:16:34 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v6] In-Reply-To: References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: On Tue, 12 Nov 2024 03:29:44 GMT, Julian Waters wrote: >> src/hotspot/share/classfile/stringTable.cpp line 153: >> >>> 151: } >>> 152: >>> 153: bool StringTable::wrapped_string_equals(oop java_string, StringWrapper wrapped_str, int _) { >> >> Not sure what hotspot style rules are for unused parameters. Probably worth a comment as to why this unused parameter exists. > > A quick search of the Style Guide yields nothing. I'd prefer the existing name be kept, but if it really shouldn't be used, then an unnamed parameter will suffice, no need for giving it _ as a name The `int` is only there to fit the requirements for `CompactHashtable`. It shouldn't be used as it does nothing. I have now made it an unnamed parameter instead with a comment explaining why its needed: https://github.com/openjdk/jdk/blob/4a78433cd33530186b7638a6aefd0e73ec50a3d5/src/hotspot/share/classfile/stringTable.cpp?plain=1#L153-L154 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1838279090 From rriggs at openjdk.org Tue Nov 12 15:17:10 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 12 Nov 2024 15:17:10 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits: > > - Merge > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Move remaining JEP 486 failing tests into correct groups. > - Move JEP 486 failing tests into hotspot_runtime group. > - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429896801 From aivanov at openjdk.org Tue Nov 12 15:17:10 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 12 Nov 2024 15:17:10 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 15:02:12 GMT, Sean Mullan wrote: >> I can add it back if it is more convenient and readable to have the `@see` tag. > > This can be taken care of later after integration. Agreed! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838282210 From pchilanomate at openjdk.org Tue Nov 12 15:27:02 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 12 Nov 2024 15:27:02 GMT Subject: Integrated: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... This pull request has now been integrated. Changeset: 78b80150 Author: Patricio Chilano Mateo URL: https://git.openjdk.org/jdk/commit/78b80150e009745b8f28d36c3836f18ad0ca921f Stats: 9984 lines in 249 files changed: 7169 ins; 1629 del; 1186 mod 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning Co-authored-by: Patricio Chilano Mateo Co-authored-by: Alan Bateman Co-authored-by: Andrew Haley Co-authored-by: Fei Yang Co-authored-by: Coleen Phillimore Co-authored-by: Richard Reingruber Co-authored-by: Martin Doerr Reviewed-by: aboldtch, dholmes, coleenp, fbredberg, dlong, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/21565 From cnorrbin at openjdk.org Tue Nov 12 15:34:32 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Tue, 12 Nov 2024 15:34:32 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v6] In-Reply-To: References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: On Mon, 11 Nov 2024 21:50:58 GMT, David Holmes wrote: >> Casper Norrbin 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: >> >> size moved to wrapper > > src/hotspot/share/classfile/javaClasses.cpp line 393: > >> 391: #ifdef ASSERT >> 392: // This check is too strict on older classfile versions >> 393: if (UTF8::is_legal_utf8((const unsigned char*)utf8_str, utf8_len, /*version_leq_47*/false)) > > I don't see the point of this check. Any validation would/should be done when the Symbol is created, not when it is later used. The problem is that the string could technically be correct according to its classfile version, but could then fail the checks done here. The older classfile versions had relaxed requirements, and these don't play well the checks here. So when the Symbol is created the string is not technically "wrong", it's just that some functions (like here) assume that the string is correct according to newer definitions of "correct". It is not certain that the checks of these strings would succeed, we can only guarantee that on newer "correct" UTF8. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1838311131 From fyang at openjdk.org Tue Nov 12 15:39:05 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 12 Nov 2024 15:39:05 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v8] In-Reply-To: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> Message-ID: > Hi, please consider this cleanup change. > > The old trampoline call on linux-riscv64 is disabled by default after: https://bugs.openjdk.org/browse/JDK-8332689. > And the new solution (load target address from stub and call) has been baked in jdk master for quite some time. > This propose to remove the old trampoline call related logic so that the code will be cleaner and easier to maintain. > As we are still using `trampoline_stub_Relocation` for the stub, I kept using the original `emit_trampoline_stub` name. > > Testing on linux-riscv64: > - [x] tier1-tier3 (release) > - [x] hotspot:tier1 (fastdebug) Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge remote-tracking branch 'upstream/master' into JDK-8343430 - More Comments - Merge remote-tracking branch 'upstream/master' into JDK-8343430 - More naming - More improvements - Minor - More comments - Comment - Improve - Code comment - ... and 2 more: https://git.openjdk.org/jdk/compare/2989d873...11442458 ------------- Changes: https://git.openjdk.org/jdk/pull/21822/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21822&range=07 Stats: 632 lines in 12 files changed: 9 ins; 546 del; 77 mod Patch: https://git.openjdk.org/jdk/pull/21822.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21822/head:pull/21822 PR: https://git.openjdk.org/jdk/pull/21822 From fyang at openjdk.org Tue Nov 12 15:43:48 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 12 Nov 2024 15:43:48 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v7] In-Reply-To: <9OaoBC_A_RexPK4vHf_fvJtWySrlhdcuDwVl_8-ECV0=.4e27923a-43b9-467f-96f9-daf23ecfa6db@github.com> References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> <14IasQU3f3Q1Lw__swFWCrX7d0ZpAdX8D_QTBtbHLTo=.4e88a911-e2a2-4934-9013-8a72ffa9c8bc@github.com> <9OaoBC_A_RexPK4vHf_fvJtWySrlhdcuDwVl_8-ECV0=.4e27923a-43b9-467f-96f9-daf23ecfa6db@github.com> Message-ID: On Mon, 11 Nov 2024 21:30:58 GMT, Hamlin Li wrote: >> Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: >> >> - More Comments >> - Merge remote-tracking branch 'upstream/master' into JDK-8343430 >> - More naming >> - More improvements >> - Minor >> - More comments >> - Comment >> - Improve >> - Code comment >> - Merge remote-tracking branch 'upstream/master' into JDK-8343430 >> - ... and 1 more: https://git.openjdk.org/jdk/compare/7b0f273e...ad6df2fe > > Updating also looks good to me. Thanks! @Hamlin-Li @robehn : Hello, I just merged with master resolving a trivial conflict in code comment. I think we are still fine. Could you please re-approve this? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21822#issuecomment-2470865802 From coleenp at openjdk.org Tue Nov 12 15:46:44 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 12 Nov 2024 15:46:44 GMT Subject: RFR: 8340212: -Xshare:off -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64 [v3] In-Reply-To: References: Message-ID: > Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64. This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated. > > Tested with tier1-7. Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into decode-mode - include formatBuffer.hpp - 8340212: -Xshare:off -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64 ------------- Changes: https://git.openjdk.org/jdk/pull/21695/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21695&range=02 Stats: 104 lines in 8 files changed: 98 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21695.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21695/head:pull/21695 PR: https://git.openjdk.org/jdk/pull/21695 From coleenp at openjdk.org Tue Nov 12 15:50:47 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 12 Nov 2024 15:50:47 GMT Subject: RFR: 8340212: -Xshare:off -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64 [v3] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 15:46:44 GMT, Coleen Phillimore wrote: >> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64. This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated. >> >> Tested with tier1-7. > > Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into decode-mode > - include formatBuffer.hpp > - 8340212: -Xshare:off -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64 I merged today with CompactObjectHeaders change, and removed the failed tests from the problem list. Tested with tier4 where failures were almost always seen, and tier1-4 all platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21695#issuecomment-2470887039 From never at openjdk.org Tue Nov 12 15:55:52 2024 From: never at openjdk.org (Tom Rodriguez) Date: Tue, 12 Nov 2024 15:55:52 GMT Subject: RFR: 8338007: [JVMCI] ResolvedJavaMethod.reprofile can crash ciMethodData [v3] In-Reply-To: References: <4Hg0HCzLxAyCxPaXI-on0epXvyJY3Ap1DJqNK0WoY5w=.60103e4a-fbcd-4a63-98c9-ec68f527a89b@github.com> Message-ID: On Fri, 8 Nov 2024 16:44:01 GMT, Tom Rodriguez wrote: >> Graal unit testing uses ResolvedJavaMethod.reprofile to reset profiles between test but the current code rewrites the layout in a non-atomic way which can break other readers. Instead perform the reinitialization at a safepoint which should protect all readers from seeing any transient initialization states. > > Tom Rodriguez 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 tkr-mdo-reinitialize > - Review comments > - 8338007: [JVMCI] ResolvedJavaMethod.reprofile can crash ciMethodData The automatic check failure seems to be a configuration problem with macos so that looks good. I reran the mach5 testing against latest master so it all looks good. Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21746#issuecomment-2470900370 From never at openjdk.org Tue Nov 12 15:55:53 2024 From: never at openjdk.org (Tom Rodriguez) Date: Tue, 12 Nov 2024 15:55:53 GMT Subject: Integrated: 8338007: [JVMCI] ResolvedJavaMethod.reprofile can crash ciMethodData In-Reply-To: <4Hg0HCzLxAyCxPaXI-on0epXvyJY3Ap1DJqNK0WoY5w=.60103e4a-fbcd-4a63-98c9-ec68f527a89b@github.com> References: <4Hg0HCzLxAyCxPaXI-on0epXvyJY3Ap1DJqNK0WoY5w=.60103e4a-fbcd-4a63-98c9-ec68f527a89b@github.com> Message-ID: On Mon, 28 Oct 2024 19:13:28 GMT, Tom Rodriguez wrote: > Graal unit testing uses ResolvedJavaMethod.reprofile to reset profiles between test but the current code rewrites the layout in a non-atomic way which can break other readers. Instead perform the reinitialization at a safepoint which should protect all readers from seeing any transient initialization states. This pull request has now been integrated. Changeset: c12b386d Author: Tom Rodriguez URL: https://git.openjdk.org/jdk/commit/c12b386d1916af9a04b4c6698838c2b40c6cdd86 Stats: 43 lines in 4 files changed: 37 ins; 0 del; 6 mod 8338007: [JVMCI] ResolvedJavaMethod.reprofile can crash ciMethodData Reviewed-by: dnsimon, kvn ------------- PR: https://git.openjdk.org/jdk/pull/21746 From lancea at openjdk.org Tue Nov 12 16:00:20 2024 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 12 Nov 2024 16:00:20 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits: > > - Merge > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Move remaining JEP 486 failing tests into correct groups. > - Move JEP 486 failing tests into hotspot_runtime group. > - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e Thank you for all of your hard work on this JEP Sean. ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2430018834 From coffeys at openjdk.org Tue Nov 12 16:03:27 2024 From: coffeys at openjdk.org (Sean Coffey) Date: Tue, 12 Nov 2024 16:03:27 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits: > > - Merge > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Move remaining JEP 486 failing tests into correct groups. > - Move JEP 486 failing tests into hotspot_runtime group. > - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e Marked as reviewed by coffeys (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2430024985 From aivanov at openjdk.org Tue Nov 12 16:11:19 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 12 Nov 2024 16:11:19 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits: > > - Merge > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Move remaining JEP 486 failing tests into correct groups. > - Move JEP 486 failing tests into hotspot_runtime group. > - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2430049235 From aph at redhat.com Tue Nov 12 17:00:11 2024 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 Nov 2024 17:00:11 +0000 Subject: Redesign interface dispatch: progress report Message-ID: <53d0c230-4d07-40a2-b5d9-0c5d71116e9b@redhat.com> I've been trying to improve the way we do invokeinterface dispatch. TL/DR: given current high-end processors it's unlikely that we'll find anything significantly better than what we have now. Even megamorphic interface dispatch is fast, provided the processor accurately predicts the target. I'm writing this partly in order to save anyone else tempted to try it from some effort. In more detail: HotSpot's current implementation of invokeinterface uses techniques such as inlining and specialization in the case where there are only a couple of frequently-used implementations of an interface at a call site, in which case there is no need to do a true multi-way (we call it _megamorphic_) dispatch. Here I'm considering only the megamorphic case, not the special cases that can be inlined. In practice this means three or more implementations, invoked with similar frequency. Megamorphic interface dispatch works by generating itable stubs. Every interface method has an itable index, and every class that implements an interface contains an array that maps an itable index to the appropriate implementation. A class can implement several interfaces, in which case it has an itable for each one of those interfaces. [See https://wiki.openjdk.org/display/HotSpot/InterfaceCalls for more details.] In order to find the appropriate itable, the itable stub first performs a linear search to find an itable, then looks up the implementation in the appropriate itable. What I've tried: I thought that I could improve on the current solution in two different ways. First, get rid of the linear search by using a hash table to do the itable lookup, then dispatching as usual. Secondly, if we could generate a hash map which directly mapped from (interface Method) -> (implementation) then we would be able to avoid the search for any itable altogether. There's a JMH benchmark called InterfaceCalls.java that measures the time to call an interface method. While I was trying hashed dispatch algorithms I ran this benchmark, and discovered that it was unfeasibly fast even with the current implementation, running at about 4-5ns to invoke an interface method. When you consider that a simple memory load from L1 cache takes about 1ns, it's unlikely that this is realistic. So, I looked at the benchmark and wondered that it was perhaps too predictable, and maybe the processor was correctly predicting and prefetching every interface call. Simply randomizing the pattern of interface calls proved that this was indeed the case, and the less predictable benchmark took four times as long to run, on both Intel and Arm processors. This is https://github.com/openjdk/jdk/pull/21581 Using a "fast" (well, the fastest I could think of) hash table instead of a linear search doesn't help unless there are a lot of interfaces, more than normal Java code. Otherwise the resulting hash table is slower or takes up too much memory, even when compressed. I did try piggybacking on the secondary-supers hash table (used by checkcast et al) but that didn't help. It was no faster than a linear search. I also tried a hash structure based on Bagwell's "Ideal Hash Trees" [https://lampwww.epfl.ch/papers/idealhashtrees.pdf] to map directly from (interface Method) -> (implementation). Again, it wasn't any faster than our current solution. Having said all of that, there was one advantage to my experiments: there was only a single stub, rather than an array of them. I'm not sure how important that is, really. In truth, what matters for megamorphic calls on today's Great Big Out-of-Order processors is not really the way that interface method lookup works, but *predictability*. As long as the target of a megamorphic invokeinterface is well predicted, it'll be fast. And if it's truly unpredictable it'll be slow. Abstract superclasses versus interfaces isn't really the issue here, although superclass dispatch, being simpler, may well be more predictable. As Aleksey Shipilev pointed out in 2015, mispredicted branches are the killer. In conclusion: I don't intend to produce a PR from this work. It may be possible to condense the array of itable stubs into a single one, but it's questionable whether it's worth the effort, and the result may run more slowly on some machines. Even though I haven't produced any useful improvement, it was worth a try, and it's always worth writing up negative results. -- 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 mullan at openjdk.org Tue Nov 12 17:20:26 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 12 Nov 2024 17:20:26 GMT Subject: Integrated: 8338411: Implement JEP 486: Permanently Disable the Security Manager In-Reply-To: References: Message-ID: On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote: > This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. > > NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. > > The code changes can be broken down into roughly the following categories: > > 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. > 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. > 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. > 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). > 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. > > There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. > > Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). > > I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f... This pull request has now been integrated. Changeset: db850905 Author: Sean Mullan URL: https://git.openjdk.org/jdk/commit/db85090553ab14a84c3ed0a2604dd56c5b6e6982 Stats: 68914 lines in 1889 files changed: 2475 ins; 62597 del; 3842 mod 8338411: Implement JEP 486: Permanently Disable the Security Manager Co-authored-by: Sean Mullan Co-authored-by: Alan Bateman Co-authored-by: Weijun Wang Co-authored-by: Aleksei Efimov Co-authored-by: Brian Burkhalter Co-authored-by: Daniel Fuchs Co-authored-by: Harshitha Onkar Co-authored-by: Joe Wang Co-authored-by: Jorn Vernee Co-authored-by: Justin Lu Co-authored-by: Kevin Walls Co-authored-by: Lance Andersen Co-authored-by: Naoto Sato Co-authored-by: Roger Riggs Co-authored-by: Brent Christian Co-authored-by: Stuart Marks Co-authored-by: Ian Graves Co-authored-by: Phil Race Co-authored-by: Erik Gahlin Co-authored-by: Jaikiran Pai Reviewed-by: kevinw, aivanov, rriggs, lancea, coffeys, dfuchs, ihse, erikj, cjplummer, coleenp, naoto, mchung, prr, weijun, joehw, azvegint, psadhukhan, bchristi, sundar, attila ------------- PR: https://git.openjdk.org/jdk/pull/21498 From mli at openjdk.org Tue Nov 12 18:16:18 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 12 Nov 2024 18:16:18 GMT Subject: RFR: 8343430: RISC-V: C2: Remove old trampoline call [v8] In-Reply-To: References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> Message-ID: On Tue, 12 Nov 2024 15:39:05 GMT, Fei Yang wrote: >> Hi, please consider this cleanup change. >> >> The old trampoline call on linux-riscv64 is disabled by default after: https://bugs.openjdk.org/browse/JDK-8332689. >> And the new solution (load target address from stub and call) has been baked in jdk master for quite some time. >> This propose to remove the old trampoline call related logic so that the code will be cleaner and easier to maintain. >> As we are still using `trampoline_stub_Relocation` for the stub, I kept using the original `emit_trampoline_stub` name. >> >> Testing on linux-riscv64: >> - [x] tier1-tier3 (release) >> - [x] hotspot:tier1 (fastdebug) > > Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge remote-tracking branch 'upstream/master' into JDK-8343430 > - More Comments > - Merge remote-tracking branch 'upstream/master' into JDK-8343430 > - More naming > - More improvements > - Minor > - More comments > - Comment > - Improve > - Code comment > - ... and 2 more: https://git.openjdk.org/jdk/compare/2989d873...11442458 Still good, Thanks! ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21822#pullrequestreview-2430360416 From duke at openjdk.org Tue Nov 12 23:23:47 2024 From: duke at openjdk.org (duke) Date: Tue, 12 Nov 2024 23:23:47 GMT Subject: RFR: 8343317: Extend test generation tool to handle APX NDD/NF flavor of instructions [v5] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 17:56:08 GMT, hanklo6 wrote: >> Extend test generation tool and gtest (added as part of https://bugs.openjdk.org/browse/JDK-8339507) to handle Intel APX NDD/NF instructions. >> >> Intel Advanced Performance Extensions (APX) adds non destructive destination (NDD) and no flags (NF) flavor for the scalar instructions through EVEX encoding. For more information about APX, see https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html. > > hanklo6 has updated the pull request incrementally with one additional commit since the last revision: > > Align output in assembler test @hanklo6 Your change (at version b8ef01db22e34fdd4d098fcbbcb5bd859c77b53c) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21795#issuecomment-2471823253 From fyang at openjdk.org Wed Nov 13 00:11:29 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 13 Nov 2024 00:11:29 GMT Subject: Integrated: 8343430: RISC-V: C2: Remove old trampoline call In-Reply-To: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> References: <_MLulsIlDuuszoaFgDA7xOk5DhBb-hRgMm2TERV95Uo=.d44330a7-81ab-4043-ab8e-a82cbdffefd8@github.com> Message-ID: On Fri, 1 Nov 2024 12:08:58 GMT, Fei Yang wrote: > Hi, please consider this cleanup change. > > The old trampoline call on linux-riscv64 is disabled by default after: https://bugs.openjdk.org/browse/JDK-8332689. > And the new solution (load target address from stub and call) has been baked in jdk master for quite some time. > This propose to remove the old trampoline call related logic so that the code will be cleaner and easier to maintain. > As we are still using `trampoline_stub_Relocation` for the stub, I kept using the original `emit_trampoline_stub` name. > > Testing on linux-riscv64: > - [x] tier1-tier3 (release) > - [x] hotspot:tier1 (fastdebug) This pull request has now been integrated. Changeset: eb40a88f Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/eb40a88f4076360708402454a494907e8c0c845d Stats: 632 lines in 12 files changed: 9 ins; 546 del; 77 mod 8343430: RISC-V: C2: Remove old trampoline call Reviewed-by: mli, rehn ------------- PR: https://git.openjdk.org/jdk/pull/21822 From dean.long at oracle.com Wed Nov 13 01:11:10 2024 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 12 Nov 2024 17:11:10 -0800 Subject: Redesign interface dispatch: progress report In-Reply-To: <53d0c230-4d07-40a2-b5d9-0c5d71116e9b@redhat.com> References: <53d0c230-4d07-40a2-b5d9-0c5d71116e9b@redhat.com> Message-ID: <9a3bd769-e551-432d-ae19-34b16829509a@oracle.com> This work sounds related to JDK-8221828, which says about interface dispatch: "The proposal for invokeinterface calls is to give each interface method a unique number called "selector", and create a cuckoo-style hash table mapping selectors to code pointers for the concrete implementations of the interface method. The table is embedded straight into the native class. This allows dispatching the majority of the time with one indirect branch and one direct branch (compared to two direct branches for dynamically monomorphic calls today)." dl On 11/12/24 9:00 AM, Andrew Haley wrote: > I've been trying to improve the way we do invokeinterface dispatch. > > TL/DR: given current high-end processors it's unlikely that we'll find > anything significantly better than what we have now. Even megamorphic > interface dispatch is fast, provided the processor accurately predicts > the target. > > I'm writing this partly in order to save anyone else tempted to try it > from some effort. > > In more detail: > > HotSpot's current implementation of invokeinterface uses techniques > such as inlining and specialization in the case where there are only a > couple of frequently-used implementations of an interface at a call > site, in which case there is no need to do a true multi-way (we call > it _megamorphic_) dispatch. Here I'm considering only the megamorphic > case, not the special cases that can be inlined. In practice this > means three or more implementations, invoked with similar frequency. > > Megamorphic interface dispatch works by generating itable stubs. > Every interface method has an itable index, and every class that > implements an interface contains an array that maps an itable index to > the appropriate implementation. A class can implement several > interfaces, in which case it has an itable for each one of those > interfaces. [See > https://wiki.openjdk.org/display/HotSpot/InterfaceCalls for more > details.] > > In order to find the appropriate itable, the itable stub first > performs a linear search to find an itable, then looks up the > implementation in the appropriate itable. > > What I've tried: > > I thought that I could improve on the current solution in two > different ways. First, get rid of the linear search by using a hash > table to do the itable lookup, then dispatching as usual. Secondly, if > we could generate a hash map which directly mapped from (interface > Method) -> (implementation) then we would be able to avoid the search > for any itable altogether. > > There's a JMH benchmark called InterfaceCalls.java that measures the > time to call an interface method. While I was trying hashed dispatch > algorithms I ran this benchmark, and discovered that it was unfeasibly > fast even with the current implementation, running at about 4-5ns to > invoke an interface method. When you consider that a simple memory > load from L1 cache takes about 1ns, it's unlikely that this is > realistic. > > So, I looked at the benchmark and wondered that it was perhaps too > predictable, and maybe the processor was correctly predicting and > prefetching every interface call. Simply randomizing the pattern of > interface calls proved that this was indeed the case, and the less > predictable benchmark took four times as long to run, on both Intel > and Arm processors. This is https://github.com/openjdk/jdk/pull/21581 > > Using a "fast" (well, the fastest I could think of) hash table instead > of a linear search doesn't help unless there are a lot of interfaces, > more than normal Java code. Otherwise the resulting hash table is > slower or takes up too much memory, even when compressed. I did try > piggybacking on the secondary-supers hash table (used by checkcast et > al) but that didn't help. It was no faster than a linear search. > > I also tried a hash structure based on Bagwell's "Ideal Hash Trees" > [https://lampwww.epfl.ch/papers/idealhashtrees.pdf] to map directly > from (interface Method) -> (implementation). Again, it wasn't any > faster than our current solution. > > Having said all of that, there was one advantage to my experiments: > there was only a single stub, rather than an array of them. I'm not > sure how important that is, really. > > In truth, what matters for megamorphic calls on today's Great Big > Out-of-Order processors is not really the way that interface method > lookup works, but *predictability*. As long as the target of a > megamorphic invokeinterface is well predicted, it'll be fast. And if > it's truly unpredictable it'll be slow. Abstract superclasses versus > interfaces isn't really the issue here, although superclass dispatch, > being simpler, may well be more predictable. > > As Aleksey Shipilev pointed out in 2015, mispredicted branches are the > killer. > > In conclusion: > > I don't intend to produce a PR from this work. It may be possible to > condense the array of itable stubs into a single one, but it's > questionable whether it's worth the effort, and the result may run > more slowly on some machines. > > Even though I haven't produced any useful improvement, it was worth a > try, and it's always worth writing up negative results. > From jiangli at openjdk.org Wed Nov 13 01:44:13 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 13 Nov 2024 01:44:13 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v9] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: <4TglRts9KEQcf0NHTe2LvbzxSK9w5PoaEcIQhP-7fD8=.815bf1da-830d-4035-95bf-1916322f9567@github.com> On Mon, 4 Nov 2024 21:30:10 GMT, Magnus Ihse Bursie wrote: >>> I can confirm that with your patch, and clang, and a complete wipe + rebuild, the .java file loading works. I'm currently testing with gcc as well. >> >> Good. >> >> I tested using gcc. > > @jianglizhou Thank you for your assistance in figuring out the problem. I guess I throw out too much code from the hermetic-java-runtime branch when trying to minimize the changes to only build-related stuff. The jimage changes were so busy so I probably ignored them a bit too much. @magicus Just want to check if there's anything that you are waiting from me for this PR. My understanding is that you'll update the PR to fix the incremental build and debuginfo before the last review iteration. Please let me know if there are anything else. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2472135324 From dholmes at openjdk.org Wed Nov 13 05:38:46 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 13 Nov 2024 05:38:46 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v6] In-Reply-To: References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: <1U-_4krWbo71sbCNF-XcE31dv18t-7sakfjB0R7nL_M=.cdf40335-55b8-4963-aa15-d953d1ccdb1c@github.com> On Tue, 12 Nov 2024 15:31:11 GMT, Casper Norrbin wrote: >> src/hotspot/share/classfile/javaClasses.cpp line 393: >> >>> 391: #ifdef ASSERT >>> 392: // This check is too strict on older classfile versions >>> 393: if (UTF8::is_legal_utf8((const unsigned char*)utf8_str, utf8_len, /*version_leq_47*/false)) >> >> I don't see the point of this check. Any validation would/should be done when the Symbol is created, not when it is later used. > > The problem is that the string could technically be correct according to its classfile version, but could then fail the checks done here. The older classfile versions had relaxed requirements, and these don't play well the checks here. > > So when the Symbol is created the string is not technically "wrong", it's just that some functions (like here) assume that the string is correct according to newer definitions of "correct". It is not certain that the checks of these strings would succeed, we can only guarantee that on newer "correct" UTF8. Okay I see why now. I had previously failed to determine where the `version_leq_47` special handling had come from and exactly what it meant. But I think I have now tracked it down to [JDK-4324508](https://bugs.openjdk.org/browse/JDK-4324508). I'm not 100% convinced that we are using `is_legal_utf8` correctly everywhere (in terms of what we pass for `version_leq_47`), or even that we generally handle such old utf8 "strings" correctly, but that is a separate issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1839442334 From dholmes at openjdk.org Wed Nov 13 05:43:48 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 13 Nov 2024 05:43:48 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v7] In-Reply-To: References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: On Tue, 12 Nov 2024 15:01:19 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> String interning can be done on 4 different types of strings: >> - oop-strings (unicode) >> - oop-strings (latin1) >> - Symbols (non-null-terminated utf8) >> - null-terminated utf8 char arrays >> >> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table. >> >> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation. >> >> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations. >> >> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build) >> >> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types. >> Also tested and passes tiers 1-3. > > Casper Norrbin 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 nine additional commits since the last revision: > > - more feedback + formatting > - Merge branch 'master' into stringtable--intern-refactor > - size moved to wrapper > - feedback from david > - missed cleanup > - length param change + feedback > - feedback from johan > - string conversion + intern tests > - multi-type string interning One nit but otherwise this looks good. Thanks for your patience and perseverance on this one. src/hotspot/share/classfile/stringTable.cpp line 426: > 424: case StringType::OopStr: > 425: len = static_cast(wrapped_str.length); > 426: return java_lang_String::as_unicode_string(wrapped_str.oop_str(), len, CHECK_NULL); `as_unicode_string` will set `len`. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21325#pullrequestreview-2431889125 PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1839446209 From duke at openjdk.org Wed Nov 13 06:21:28 2024 From: duke at openjdk.org (Manjunath S Matti.) Date: Wed, 13 Nov 2024 06:21:28 GMT Subject: RFR: 8335367: [s390] Add support for load immediate on condition instructions. Message-ID: <2oJIrDqMf4MYKGz_s1K8D2aNjGwJJ75PY-gUOZwVEU0=.af1d8092-a680-4ea2-adf7-a9c3432509a3@github.com> Add support for load immediate on condition instructions. ------------- Commit messages: - Update - Add support for load immediate on condition instructions Changes: https://git.openjdk.org/jdk/pull/22058/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22058&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335367 Stats: 18 lines in 3 files changed: 15 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22058.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22058/head:pull/22058 PR: https://git.openjdk.org/jdk/pull/22058 From amitkumar at openjdk.org Wed Nov 13 06:29:11 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 13 Nov 2024 06:29:11 GMT Subject: RFR: 8343884: [s390x] Disallow OptoScheduling Message-ID: amit at a3560042:~/jdk$ ./build/linux-s390x-server-fastdebug/jdk/bin/java -XX:+OptoScheduling --version OpenJDK 64-Bit Server VM warning: OptoScheduling is not supported on this CPU. openjdk 24-internal 2025-03-18 OpenJDK Runtime Environment (fastdebug build 24-internal-adhoc.amit.jdk) OpenJDK 64-Bit Server VM (fastdebug build 24-internal-adhoc.amit.jdk, mixed mode) amit at a3560042:~/jdk$ ------------- Commit messages: - disable opto scheduling Changes: https://git.openjdk.org/jdk/pull/22059/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22059&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343884 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22059.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22059/head:pull/22059 PR: https://git.openjdk.org/jdk/pull/22059 From jwaters at openjdk.org Wed Nov 13 06:50:57 2024 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 13 Nov 2024 06:50:57 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 01:17:01 GMT, Julian Waters wrote: > Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely Bumping ------------- PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2472601613 From david.holmes at oracle.com Wed Nov 13 07:11:21 2024 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Nov 2024 17:11:21 +1000 Subject: Win32AttachOperationRequest seems to be using global new? In-Reply-To: References: Message-ID: > Is this an intentional exception to the rule, or an oversight? I think it is an oversight. David On 13/11/2024 12:20 am, Julian Waters wrote: > Hi all, > > Win32AttachOperationRequest is created via new, but doesn't specify a > custom new inside the class definition. The result seems to be that we > use global new on Windows: > > ? for (int i=0; i ? ? Win32AttachOperationRequest* op = new Win32AttachOperationRequest(); > ? ? ? f1: b9 28 0d 00 00 ? ? ? mov ? ?ecx,0xd28 > ? ? ? f6: e8 00 00 00 00 ? ? ? call ? fb > f7: IMAGE_REL_AMD64_REL32 operator new(unsigned long long) > > Stepping away from gcc's objdump and using the Microsoft dumpbin > alongside cl.exe instead, the result is this: > > ? 0000000000000264: B9 28 0D 00 00 ? ? mov ? ? ? ? ecx,0D28h > ? 0000000000000269: E8 00 00 00 00 ? ? call ? ? ? ???2 at YAPEAX_K@Z > ? 000000000000026E: 48 89 44 24 28 ? ? mov ? ? ? ? qword ptr [rsp+28h],rax > ? 0000000000000273: 48 83 7C 24 28 00 ?cmp ? ? ? ? qword ptr [rsp+28h],0 > ? 0000000000000279: 74 11 ? ? ? ? ? ? ?je ? ? ? ? ?000000000000028C > ? 000000000000027B: 48 8B 4C 24 28 ? ? mov ? ? ? ? rcx,qword ptr [rsp+28h] > ? 0000000000000280: E8 00 00 00 00 ? ? call ? ? ? ??? > 0Win32AttachOperationRequest@@QEAA at XZ > > undname "??2 at YAPEAX_K@Z" > Microsoft (R) C++ Name Undecorator > Copyright (C) Microsoft Corporation. All rights reserved. > > Undecoration of :- "??2 at YAPEAX_K@Z" > is :- "void * __ptr64 __cdecl operator new(unsigned __int64)" > > undname "??0Win32AttachOperationRequest@@QEAA at XZ" > Microsoft (R) C++ Name Undecorator > Copyright (C) Microsoft Corporation. All rights reserved. > > Undecoration of :- "??0Win32AttachOperationRequest@@QEAA at XZ" > is :- "public: __cdecl > Win32AttachOperationRequest::Win32AttachOperationRequest(void) __ptr64" > > Visual Studio, lacking the nm utility, obviously doesn't catch this. > What was more surprising is that the gcc Link Time check also fails to > catch it as well. I had to manually check the output of nm after an > unrelated failure and happened to stumble across the symbols?_Znwy > and?_ZdlPvy which both correspond to > > operator new(unsigned long long) > operator delete(void*, unsigned long long) > > The delete can be ignored, it's the result of a bug on my experimental > branch (It was first discovered there, then I tested it on master). I'm > more interested about the new, since it seems to be violating a HotSpot > rule. Is this an intentional exception to the rule, or an oversight? > > best regards, > Julian From jbachorik at openjdk.org Wed Nov 13 08:33:35 2024 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Wed, 13 Nov 2024 08:33:35 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v20] In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 15:32:15 GMT, Erik Gahlin wrote: >> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix ActiveSetting event for CPUTimeSamples > > src/jdk.jfr/share/classes/jdk/jfr/internal/util/TimespanRate.java line 50: > >> 48: return new TimespanRate(Runtime.getRuntime().availableProcessors() / (period / 1_000_000_000.0), false); >> 49: } >> 50: return new TimespanRate(Rate.of(text).perSecond(), true); > > What if the rate contained in text is not valid? Shouldn't it be: > > Rate r = Rate.of(text); > return r == null ? null : new TimespanRate(r.perSecond(), true); This has been fixed in [9cafdbc8fe672020e2c2772b1b3f315bb12a356e](https://github.com/openjdk/jdk/commit/9cafdbc8fe672020e2c2772b1b3f315bb12a356e) by @parttimenerd ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1839735264 From cnorrbin at openjdk.org Wed Nov 13 09:20:13 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 13 Nov 2024 09:20:13 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v8] In-Reply-To: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: <-ffW7HvdRcihUrC9OygWI53M5BnUQjTuWt7OL2DRpOk=.395726e3-d322-4722-947f-d5cc836e38ef@github.com> > Hi everyone, > > String interning can be done on 4 different types of strings: > - oop-strings (unicode) > - oop-strings (latin1) > - Symbols (non-null-terminated utf8) > - null-terminated utf8 char arrays > > Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table. > > This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation. > > This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations. > > Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build) > > 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types. > Also tested and passes tiers 1-3. Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: removed unnecessary len set ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21325/files - new: https://git.openjdk.org/jdk/pull/21325/files/4a78433c..23b5cc08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21325&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21325&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21325/head:pull/21325 PR: https://git.openjdk.org/jdk/pull/21325 From jbachorik at openjdk.org Wed Nov 13 09:21:59 2024 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Wed, 13 Nov 2024 09:21:59 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v21] In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 16:08:59 GMT, Johannes Bechberger wrote: >> This is the code for the [JEP draft: CPU Time based profiling for JFR]. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Make parsing rates safer src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 68: > 66: _reached_root = true; > 67: > 68: JfrVframeStream vfs(jt, frame, false, true, false); Does this mean we are not going to get frames from virtual threads/continuations? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1839782655 From jbechberger at openjdk.org Wed Nov 13 09:21:59 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 13 Nov 2024 09:21:59 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v21] In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 09:00:59 GMT, Jaroslav Bachorik wrote: >> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: >> >> Make parsing rates safer > > src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 68: > >> 66: _reached_root = true; >> 67: >> 68: JfrVframeStream vfs(jt, frame, false, true, false); > > Does this mean we are not going to get frames from virtual threads/continuations? Only the ones that are currently on the stack, as far as I understand. But this change is required, as walking continuations in a signal causes crashes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1839799573 From ihse at openjdk.org Wed Nov 13 09:47:13 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 13 Nov 2024 09:47:13 GMT Subject: Integrated: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie wrote: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. This pull request has now been integrated. Changeset: 79345bbb Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/79345bbbae2564f9f523859d1227a1784293b20f Stats: 1922 lines in 85 files changed: 82 ins; 1573 del; 267 mod 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port Reviewed-by: kbarrett, kvn, stuefe, shade, erikj ------------- PR: https://git.openjdk.org/jdk/pull/21744 From jsjolen at openjdk.org Wed Nov 13 10:23:54 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 13 Nov 2024 10:23:54 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v7] In-Reply-To: References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: On Tue, 12 Nov 2024 15:01:19 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> String interning can be done on 4 different types of strings: >> - oop-strings (unicode) >> - oop-strings (latin1) >> - Symbols (non-null-terminated utf8) >> - null-terminated utf8 char arrays >> >> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table. >> >> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation. >> >> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations. >> >> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build) >> >> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types. >> Also tested and passes tiers 1-3. > > Casper Norrbin 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 nine additional commits since the last revision: > > - more feedback + formatting > - Merge branch 'master' into stringtable--intern-refactor > - size moved to wrapper > - feedback from david > - missed cleanup > - length param change + feedback > - feedback from johan > - string conversion + intern tests > - multi-type string interning Hi, Good job on this, thank you. Also big thanks to David for the excellent review effort on this. LGTM, bar a couple of nits. src/hotspot/share/classfile/javaClasses.hpp line 184: > 182: } > 183: > 184: static unsigned int hash_code(const char* utf8_str, size_t utf8_len) { Why is this inlined but the oop-version isn't? Maybe they should both be in the cpp file? src/hotspot/share/classfile/stringTable.cpp line 62: > 60: #include "utilities/concurrentHashTable.inline.hpp" > 61: #include "utilities/concurrentHashTableTasks.inline.hpp" > 62: #include "utilities/debug.hpp" Is this header actually needed? clangd provides an option to tell you what symbols a header provides for a source file. ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21325#pullrequestreview-2432275169 PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1839733108 PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1839736321 From coleenp at openjdk.org Wed Nov 13 11:47:54 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 13 Nov 2024 11:47:54 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests Message-ID: Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. Tested with tier1-4. ------------- Commit messages: - Remove some more includes. - 8341916: Remove ProtectionDomain related hotspot code and tests Changes: https://git.openjdk.org/jdk/pull/22064/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341916 Stats: 1267 lines in 42 files changed: 1 ins; 1104 del; 162 mod Patch: https://git.openjdk.org/jdk/pull/22064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22064/head:pull/22064 PR: https://git.openjdk.org/jdk/pull/22064 From cnorrbin at openjdk.org Wed Nov 13 11:55:16 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 13 Nov 2024 11:55:16 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v9] In-Reply-To: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: <8wshn-iwsZCsBYSUqwRRhyLPYWUnbFOij_f4BTntChQ=.b74de6d9-73a2-45d6-bb97-b4a15bef9395@github.com> > Hi everyone, > > String interning can be done on 4 different types of strings: > - oop-strings (unicode) > - oop-strings (latin1) > - Symbols (non-null-terminated utf8) > - null-terminated utf8 char arrays > > Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table. > > This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation. > > This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations. > > Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build) > > 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types. > Also tested and passes tiers 1-3. Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: removed unnecessary include ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21325/files - new: https://git.openjdk.org/jdk/pull/21325/files/23b5cc08..d55552d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21325&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21325&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21325/head:pull/21325 PR: https://git.openjdk.org/jdk/pull/21325 From cnorrbin at openjdk.org Wed Nov 13 12:01:39 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 13 Nov 2024 12:01:39 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v7] In-Reply-To: References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: <4Y41M7h2oRzDzPvdvoFT4sGttituuV32ioFw_30djMw=.e3de3881-f668-4836-8e9b-e234aa19b881@github.com> On Wed, 13 Nov 2024 08:29:02 GMT, Johan Sj?len wrote: >> Casper Norrbin 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 nine additional commits since the last revision: >> >> - more feedback + formatting >> - Merge branch 'master' into stringtable--intern-refactor >> - size moved to wrapper >> - feedback from david >> - missed cleanup >> - length param change + feedback >> - feedback from johan >> - string conversion + intern tests >> - multi-type string interning > > src/hotspot/share/classfile/javaClasses.hpp line 184: > >> 182: } >> 183: >> 184: static unsigned int hash_code(const char* utf8_str, size_t utf8_len) { > > Why is this inlined but the oop-version isn't? Maybe they should both be in the cpp file? It's inlined because the hash functions working on unicode are inlined just above it. For the full context: https://github.com/openjdk/jdk/blob/d55552d5323ff8a4ec37c320199b650e63f230b4/src/hotspot/share/classfile/javaClasses.hpp?plain=1#L166-L197 I think these are simple enough to be ok inlined, whereas the oop-versions are more complex and modify the object, so it makes sense that they are not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1840130148 From coleenp at openjdk.org Wed Nov 13 12:22:46 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 13 Nov 2024 12:22:46 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v9] In-Reply-To: <8wshn-iwsZCsBYSUqwRRhyLPYWUnbFOij_f4BTntChQ=.b74de6d9-73a2-45d6-bb97-b4a15bef9395@github.com> References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> <8wshn-iwsZCsBYSUqwRRhyLPYWUnbFOij_f4BTntChQ=.b74de6d9-73a2-45d6-bb97-b4a15bef9395@github.com> Message-ID: On Wed, 13 Nov 2024 11:55:16 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> String interning can be done on 4 different types of strings: >> - oop-strings (unicode) >> - oop-strings (latin1) >> - Symbols (non-null-terminated utf8) >> - null-terminated utf8 char arrays >> >> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table. >> >> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation. >> >> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations. >> >> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build) >> >> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types. >> Also tested and passes tiers 1-3. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > removed unnecessary include Sorry for the late comment. The change looks reasonable but I want it more hidden, if possible. src/hotspot/share/classfile/stringTable.hpp line 89: > 87: static unsigned int hash_wrapped_string(StringWrapper wrapped_str); > 88: static const jchar* to_unicode(StringWrapper wrapped_str, int &len, TRAPS); > 89: static Handle handle_from_wrapped_string(StringWrapper wrapped_str, TRAPS); Why is StringWrapper passed by value not by reference? If it's passed by reference, could you hide this whole class in stringTable.cpp ? ------------- Changes requested by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21325#pullrequestreview-2432934226 PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1840159918 From jsjolen at openjdk.org Wed Nov 13 12:39:19 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 13 Nov 2024 12:39:19 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v7] In-Reply-To: <4Y41M7h2oRzDzPvdvoFT4sGttituuV32ioFw_30djMw=.e3de3881-f668-4836-8e9b-e234aa19b881@github.com> References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> <4Y41M7h2oRzDzPvdvoFT4sGttituuV32ioFw_30djMw=.e3de3881-f668-4836-8e9b-e234aa19b881@github.com> Message-ID: <9Msuf8acbEbuKY6YehJxnL9Gtj0rXCPKnKhlNZTT4EI=.4eee0182-8b24-49aa-b256-89c2529311d6@github.com> On Wed, 13 Nov 2024 11:58:27 GMT, Casper Norrbin wrote: >> src/hotspot/share/classfile/javaClasses.hpp line 184: >> >>> 182: } >>> 183: >>> 184: static unsigned int hash_code(const char* utf8_str, size_t utf8_len) { >> >> Why is this inlined but the oop-version isn't? Maybe they should both be in the cpp file? > > It's inlined because the hash functions working on unicode are inlined just above it. For the full context: > > https://github.com/openjdk/jdk/blob/d55552d5323ff8a4ec37c320199b650e63f230b4/src/hotspot/share/classfile/javaClasses.hpp?plain=1#L166-L197 > > I think these are simple enough to be ok inlined, whereas the oop-versions are more complex and modify the object, so it makes sense that they are not. Aw jeez, my bad :). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1840192094 From shade at openjdk.org Wed Nov 13 12:48:04 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 13 Nov 2024 12:48:04 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Mon, 4 Nov 2024 19:52:30 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 503 commits: > > - Merge openjdk/jdk tip into great-genshen-pr-redux > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge > - 8342861: GenShen: Old generation in unexpected state when abandoning mixed gc candidates > > Reviewed-by: kdnilsen > - 8342734: GenShen: Test failure gc/shenandoah/TestReferenceRefersToShenandoah.java#generational > > Reviewed-by: ysr > - 8342919: GenShen: Fix whitespace > > Reviewed-by: xpeng, kdnilsen > - 8342927: GenShen: Guarantee slices of time for coalesce and filling > > Reviewed-by: kdnilsen > - 8342924: GenShen: Problem list gc/shenandoah/TestReferenceRefersToShenandoah.java > > Reviewed-by: kdnilsen, ysr > - 8342848: Shenandoah: Marking bitmap may not be completely cleared in generational mode > > Reviewed-by: wkemper > - ... and 493 more: https://git.openjdk.org/jdk/compare/1c448347...19b25bc3 I read about half, here is a dump of my current observations. I'll read the second half a bit later. src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp line 474: > 472: // elision safe. > 473: return; > 474: } Why is this safe for Shenandoah? I suspect it needs `CardTableBarrierSet::on_slowpath_allocation_exit` to work. `G1BarrierSetC2` gets it by subclassing `CardTableBarrierSetC2`. But `ShenandoahBarrierSetC2` does not. Should it? src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 67: > 65: _region_data[i].clear(); > 66: } > 67: #endif I understand this is to make sure `union_tag` works well. But why don't we extend `clear` to initialize all fields, and do this block without `ASSERT`? This does not look like frequently used path. Generally, doing these inits only for debug modes might hide some assertion failures that would indicate a problem in product builds. src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 118: > 116: #ifdef ASSERT > 117: assert(_union_tag != is_uninitialized, "Cannot fetch region from uninialized RegionData"); > 118: #endif Style: No point in wrapping single-line `assert`-s in `#ifdef ASSERT`. src/hotspot/share/gc/shenandoah/shenandoahAsserts.hpp line 238: > 236: #define shenandoah_assert_control_or_vm_thread_at_safepoint() > 237: #define shenandoah_assert_generational() > 238: #define shenandoah_assert_generations_reconciled() \ There seems to be dangling `` on this line. src/hotspot/share/gc/shenandoah/shenandoahCardStats.hpp line 47: > 45: CARD_STAT_UPDATE_REFS, > 46: MAX_CARD_STAT_LOG_TYPE > 47: }; These are in global namespace. There is a risk they would clash with some other symbol elsewhere. Do you need them to be global, or can they go into `ShenandoahCardStats`? src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.cpp line 77: > 75: return reinterpret_cast(context); > 76: } else { > 77: if (_heap->is_concurrent_weak_root_in_progress()) { Comprehension check: We flips this because in generational mode we _can_ have both concurrent weak roots and concurrent mark in progress at the same time, and we need to prioritize evacs, right? src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp line 50: > 48: switch (generation_type) { \ > 49: case NON_GEN: \ > 50: return prefix " (NON-GENERATIONAL)" postfix; \ In the interest of keeping the non-generational Shenandoah logging intact, should we drop ` (NON-GENERATIONAL)` here? src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp line 83: > 81: void VM_ShenandoahInitMark::doit() { > 82: ShenandoahGCPauseMark mark(_gc_id, "Init Mark", SvcGCMarker::CONCURRENT); > 83: set_active_generation(); Why is it here, and not down in `entry_*` methods, probably in helper classes? src/hotspot/share/gc/shenandoah/shenandoahVMOperations.hpp line 41: > 39: // - VM_ShenandoahInitUpdateRefs: initiate update references > 40: // - VM_ShenandoahFinalUpdateRefs: finish up update references > 41: // - VM_ShenandoahFinalRoots If we add it here, let's provide a comment: // - VM_ShenandoahFinalRoots: finish up the roots, shortcut cycle src/hotspot/share/jfr/metadata/metadata.xml line 1221: > 1219: > 1220: > 1221: Not sure if we _need_ this JFR event as part of GenShen? This bit is what forces us to do CSR, right? test/hotspot/jtreg/ProblemList.txt line 98: > 96: gc/TestAlwaysPreTouchBehavior.java#Epsilon 8334513 generic-all > 97: gc/stress/gclocker/TestExcessGCLockerCollections.java 8229120 generic-all > 98: This change is unnecessary. test/hotspot/jtreg/gc/shenandoah/oom/TestThreadFailure.java line 61: > 59: // case that the previously instantiated NastyThread accumulated more than SheanndoahNoProgressThreshold > 60: // unproductive GC cycles before failing, the main thread may not try a Full GC before it experiences > 61: // OutOfMemoryError exception. Do you really need comments in this test? ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2429755115 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1839969170 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1839985542 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1840008742 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1840173090 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1840153151 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1840187886 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1840195628 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1840199905 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1840201386 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1840096925 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1838665756 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1838196649 From thartmann at openjdk.org Wed Nov 13 13:17:13 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 13 Nov 2024 13:17:13 GMT Subject: RFR: 8341411: C2: remove slice parameter from GraphKit::make_load() and GraphKit::store_to_memory() [v5] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 09:16:03 GMT, theoweidmannoracle wrote: >> This patch removes the address type from `GraphKit::make_load()` and `GraphKit::store_to_memory()` >> >> As https://github.com/openjdk/jdk/pull/21303 introduced asserts that check that the address type agrees with `C->get_alias_index(_gvn.type(adr)->isa_ptr()`, passing the address type is redundant and it can be computed internally from the address. > > theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: > > Fix asserts Marked as reviewed by thartmann (Reviewer). Looks good to me too. > Do we want to file a bug about to, at least, give it a try? Sounds reasonable, let's file a follow-up RFE for this. ------------- PR Review: https://git.openjdk.org/jdk/pull/21834#pullrequestreview-2433070180 PR Comment: https://git.openjdk.org/jdk/pull/21834#issuecomment-2473586328 From duke at openjdk.org Wed Nov 13 13:17:13 2024 From: duke at openjdk.org (duke) Date: Wed, 13 Nov 2024 13:17:13 GMT Subject: RFR: 8341411: C2: remove slice parameter from GraphKit::make_load() and GraphKit::store_to_memory() [v5] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 09:16:03 GMT, theoweidmannoracle wrote: >> This patch removes the address type from `GraphKit::make_load()` and `GraphKit::store_to_memory()` >> >> As https://github.com/openjdk/jdk/pull/21303 introduced asserts that check that the address type agrees with `C->get_alias_index(_gvn.type(adr)->isa_ptr()`, passing the address type is redundant and it can be computed internally from the address. > > theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: > > Fix asserts @theoweidmannoracle Your change (at version 8d239fdc7dfcf64ed3b6ea5cbae39a9f7df22622) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21834#issuecomment-2473589950 From duke at openjdk.org Wed Nov 13 13:21:40 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Wed, 13 Nov 2024 13:21:40 GMT Subject: RFR: 8341411: C2: remove slice parameter from GraphKit::make_load() and GraphKit::store_to_memory() [v5] In-Reply-To: References: Message-ID: <46gzgWUqSd3pm5b9-gjxvyCfwVH1PVJ2P8kZv3lg5VU=.65e4caac-3002-4979-8c08-6d2e4bdb0525@github.com> On Fri, 8 Nov 2024 09:16:03 GMT, theoweidmannoracle wrote: >> This patch removes the address type from `GraphKit::make_load()` and `GraphKit::store_to_memory()` >> >> As https://github.com/openjdk/jdk/pull/21303 introduced asserts that check that the address type agrees with `C->get_alias_index(_gvn.type(adr)->isa_ptr()`, passing the address type is redundant and it can be computed internally from the address. > > theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: > > Fix asserts Thanks for the reviews. I opened a follow-up RFE: https://bugs.openjdk.org/browse/JDK-8344116 ------------- PR Comment: https://git.openjdk.org/jdk/pull/21834#issuecomment-2473599168 From duke at openjdk.org Wed Nov 13 13:36:50 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Wed, 13 Nov 2024 13:36:50 GMT Subject: Integrated: 8341411: C2: remove slice parameter from GraphKit::make_load() and GraphKit::store_to_memory() In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 14:50:31 GMT, theoweidmannoracle wrote: > This patch removes the address type from `GraphKit::make_load()` and `GraphKit::store_to_memory()` > > As https://github.com/openjdk/jdk/pull/21303 introduced asserts that check that the address type agrees with `C->get_alias_index(_gvn.type(adr)->isa_ptr()`, passing the address type is redundant and it can be computed internally from the address. This pull request has now been integrated. Changeset: 8af304c6 Author: theoweidmannoracle Committer: Tobias Hartmann URL: https://git.openjdk.org/jdk/commit/8af304c60f2758b1a6c6fb53dee6bd66b3d4f6f0 Stats: 96 lines in 10 files changed: 11 ins; 45 del; 40 mod 8341411: C2: remove slice parameter from GraphKit::make_load() and GraphKit::store_to_memory() Reviewed-by: thartmann, roland ------------- PR: https://git.openjdk.org/jdk/pull/21834 From jbechberger at openjdk.org Wed Nov 13 13:38:32 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 13 Nov 2024 13:38:32 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v17] In-Reply-To: References: <8gpM6lOT_ncKkCtMDNlwzkC89K-uxWcvzmkv5xxTeaA=.e97688f7-8c2d-4d8a-8e0b-b467d1de9c0d@github.com> Message-ID: On Fri, 8 Nov 2024 13:44:01 GMT, Andrei Pangin wrote: >> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't treat stackTrace attribute specially for CPUTimeSamples > > src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 58: > >> 56: // This is because RegisterMap uses Handles to support continuations. >> 57: ResetNoHandleMark rnhm; >> 58: HandleMark hm(jt); > > HandleMark cannot be used in async-signal-safe context Is fixed, thank you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1840292314 From cnorrbin at openjdk.org Wed Nov 13 13:42:35 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 13 Nov 2024 13:42:35 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v10] In-Reply-To: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: > Hi everyone, > > String interning can be done on 4 different types of strings: > - oop-strings (unicode) > - oop-strings (latin1) > - Symbols (non-null-terminated utf8) > - null-terminated utf8 char arrays > > Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table. > > This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation. > > This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations. > > Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build) > > 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types. > Also tested and passes tiers 1-3. Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: changed to references and move wrapper to cpp file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21325/files - new: https://git.openjdk.org/jdk/pull/21325/files/d55552d5..cd95cafe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21325&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21325&range=08-09 Stats: 59 lines in 2 files changed: 20 ins; 20 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/21325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21325/head:pull/21325 PR: https://git.openjdk.org/jdk/pull/21325 From cnorrbin at openjdk.org Wed Nov 13 13:42:35 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 13 Nov 2024 13:42:35 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v9] In-Reply-To: References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> <8wshn-iwsZCsBYSUqwRRhyLPYWUnbFOij_f4BTntChQ=.b74de6d9-73a2-45d6-bb97-b4a15bef9395@github.com> Message-ID: On Wed, 13 Nov 2024 12:18:18 GMT, Coleen Phillimore wrote: >> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: >> >> removed unnecessary include > > src/hotspot/share/classfile/stringTable.hpp line 89: > >> 87: static unsigned int hash_wrapped_string(StringWrapper wrapped_str); >> 88: static const jchar* to_unicode(StringWrapper wrapped_str, int &len, TRAPS); >> 89: static Handle handle_from_wrapped_string(StringWrapper wrapped_str, TRAPS); > > Why is StringWrapper passed by value not by reference? If it's passed by reference, could you hide this whole class in stringTable.cpp ? No reason in particular. I changed the functions to use references instead and hid the wrapper away in the .cpp file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1840298623 From cnorrbin at openjdk.org Wed Nov 13 13:47:43 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 13 Nov 2024 13:47:43 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v11] In-Reply-To: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: > Hi everyone, > > String interning can be done on 4 different types of strings: > - oop-strings (unicode) > - oop-strings (latin1) > - Symbols (non-null-terminated utf8) > - null-terminated utf8 char arrays > > Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table. > > This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation. > > This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations. > > Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build) > > 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types. > Also tested and passes tiers 1-3. Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: removed whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21325/files - new: https://git.openjdk.org/jdk/pull/21325/files/cd95cafe..a798d2b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21325&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21325&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21325/head:pull/21325 PR: https://git.openjdk.org/jdk/pull/21325 From stuefe at openjdk.org Wed Nov 13 13:51:04 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 13 Nov 2024 13:51:04 GMT Subject: RFR: 8343699: [aarch64] Bug in MacroAssembler::klass_decode_mode() Message-ID: In `MacroAssembler::klass_decode_mode(),` there is a subtle bug in the xor part. if (operand_valid_for_logical_immediate( /*is32*/false, (uint64_t)CompressedKlassPointers::base())) { (1) const size_t range = CompressedKlassPointers::klass_range_end() - CompressedKlassPointers::base(); (2) const uint64_t range_mask = (1ULL << log2i(range)) - 1; (3) if (((uint64_t)CompressedKlassPointers::base() & range_mask) == 0) { log_debug(metaspace)("MacroAssembler::klass_decode_mode xor"); return (_klass_decode_mode = KlassDecodeXor); } } We first determine if the encoding base is encodable as immediate. If it is, then we check if it intersects with the value range of a narrow Klass ID. (Note: the code ignores encoding shift since the XOR will be applied to the pre-shifted narrow Klass value later.) The test is done by 1) calculating the range the encoding needs to cover 2) calculating a corresponding bit mask 3) checking that this mask does not intersect with the encoding base. (2) contains a wrongness: `range_mask = (1ULL << log2i(range)) - 1` . `log2i` returns the largest log2 value *smaller* or equal to input. So, for `range` values that are not a pow2 value, the resulting mask will be one bit too short. As an effect, the code may chose XOR for cases where the lowest encoding base bit can intersect the highest narrow Klass ID bit, thus making the xor lossy. ---- Example: Let range be 80MB (`-XX:CompressedClassSpaceSize=80m -Xshare:off`). Then, range_mask = `1 << log2i(80m) - 1` => `(1 << 26) - 1` => `0x3ff_ffff` The largest possible nKlass value, however, sits just below 80MB => `0x500_0000`. As we see, the mask does not cover the full extent of the narrow Klass ID value range (bit 26 is not covered). Hence, if we have a base with bit 26 set, its bit 26 intersects a possible bit 26 in high-value narrow Klass ID. The xor would not be lossless. ---- The error is very unlikely because - we try to reserve the klass range at addresses that are guaranteed not to intersect with the narrow Klass range. Only if that fails - very unlikely - we use whatever address the OS gives us. Only then could we end up with such an address. - The class space is rarely filled so high that the highest bit of a narrowKlass ID is `1`. ---- Reproduce: java -XX:CompressedClassSpaceBaseAddress=0x1Fc000000 -XX:CompressedClassSpaceSize=80m -Xlog:metaspace* -Xshare:off it does not reproduce an error, but causes the JVM to start in XOR mode with an encoding base of `0x1fc000000` and a narrow Klass ID range of `[0 .. 0x5000000)` - bit 26 interleaves. The fixed JVM, with this patch, will correctly refuse to use XOR mode, and since MOVK is also not an option, will assert. Note that this is correct behavior: the encoding base `0x1Fc000000` had not been valid to begin with. There is a patch in work by Coleen that will change this assert to an early exit-due-to-invalid-input (https://bugs.openjdk.org/browse/JDK-8340212). ------------- Commit messages: - Merge branch 'openjdk:master' into JDK-8343699-aarch64-Bug-in-MacroAssembler-klass_decode_mode - Merge branch 'openjdk:master' into JDK-8343699-aarch64-Bug-in-MacroAssembler-klass_decode_mode - JDK-8343699-aarch64-Bug-in-MacroAssembler-klass_decode_mode Changes: https://git.openjdk.org/jdk/pull/21932/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21932&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343699 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21932.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21932/head:pull/21932 PR: https://git.openjdk.org/jdk/pull/21932 From aph at openjdk.org Wed Nov 13 13:51:04 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 13 Nov 2024 13:51:04 GMT Subject: RFR: 8343699: [aarch64] Bug in MacroAssembler::klass_decode_mode() In-Reply-To: References: Message-ID: <3JTQ-7PHzjjc6KWlu_36B7E2byS7hG1vuN_xx32cQXs=.e50d5461-5d3a-453c-bc78-fdb4e0c8e3eb@github.com> On Wed, 6 Nov 2024 15:34:49 GMT, Thomas Stuefe wrote: > In `MacroAssembler::klass_decode_mode(),` there is a subtle bug in the xor part. > > > if (operand_valid_for_logical_immediate( > /*is32*/false, (uint64_t)CompressedKlassPointers::base())) { > (1) const size_t range = CompressedKlassPointers::klass_range_end() - CompressedKlassPointers::base(); > (2) const uint64_t range_mask = (1ULL << log2i(range)) - 1; > (3) if (((uint64_t)CompressedKlassPointers::base() & range_mask) == 0) { > log_debug(metaspace)("MacroAssembler::klass_decode_mode xor"); > return (_klass_decode_mode = KlassDecodeXor); > } > } > > > We first determine if the encoding base is encodable as immediate. If it is, then we check if it intersects with the value range of a narrow Klass ID. > > (Note: the code ignores encoding shift since the XOR will be applied to the pre-shifted narrow Klass value later.) > > The test is done by > 1) calculating the range the encoding needs to cover > 2) calculating a corresponding bit mask > 3) checking that this mask does not intersect with the encoding base. > > (2) contains a wrongness: `range_mask = (1ULL << log2i(range)) - 1` . `log2i` returns the largest log2 value *smaller* or equal to input. So, for `range` values that are not a pow2 value, the resulting mask will be one bit too short. As an effect, the code may chose XOR for cases where the lowest encoding base bit can intersect the highest narrow Klass ID bit, thus making the xor lossy. > > ---- > > Example: > > Let range be 80MB (`-XX:CompressedClassSpaceSize=80m -Xshare:off`). > > Then, range_mask = `1 << log2i(80m) - 1` => `(1 << 26) - 1` => `0x3ff_ffff` > The largest possible nKlass value, however, sits just below 80MB => `0x500_0000`. As we see, the mask does not cover the full extent of the narrow Klass ID value range (bit 26 is not covered). > Hence, if we have a base with bit 26 set, its bit 26 intersects a possible bit 26 in high-value narrow Klass ID. The xor would not be lossless. > > ---- > > The error is very unlikely because > - we try to reserve the klass range at addresses that are guaranteed not to intersect with the narrow Klass range. Only if that fails - very unlikely - we use whatever address the OS gives us. Only then could we end up with such an address. > - The class space is rarely filled so high that the highest bit of a narrowKlass ID is `1`. > > ---- > > Reproduce: > > > java -XX:CompressedClassSpaceBaseAddress=0x1Fc000000 -XX:CompressedClassSpaceSize=80m -Xlog:metaspace* -Xshare:off > > > it does not reproduce an error, but causes the JVM to start in XOR mode with an enc... I can confess that I never even knew a non-power-of-2 was a possibility. Good catch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21932#issuecomment-2460399635 From stuefe at openjdk.org Wed Nov 13 14:32:35 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 13 Nov 2024 14:32:35 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v2] In-Reply-To: References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: On Fri, 8 Nov 2024 21:48:25 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> This enhancement adds register printouts on asserts or guarantees into the hs_err_pid.log error reporting files for Windows. >> >> Additionally, it saves an accurate EXCEPTION_RECORD into the hs_err_pid.mdmp file, also for asserts or guarantees, so the assertion context is now easily accessible in Windbg using .ecxr. >> >> For more details on this enhancement, please see the JIRA issue. >> >> Testing: Tier 1,2,3, jdk_jfr >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > initialize report page I think this is mostly fine. I did look over the Windows implementation, but did not check it (I assume you did). Did you check for both architectures? One problem we have on Posix platforms is that ucontext_t was not meant to be copied around. IIRC, on some platforms (eg PPC), it is mother structure with a bunch of daughter structures that need to be copied too. Hope Windows is simpler. src/hotspot/share/utilities/debug.cpp line 192: > 190: #ifdef CAN_SHOW_REGISTERS_ON_ASSERT > 191: if (os::current_thread_id() == g_asserting_thread) { > 192: context = os::get_saved_assert_context(&siginfo); I would leave the `g_assertion_context != nullptr` in. It should not happen, but its defensive and a bug at this point is difficult to figure out (because you just don't get a hs-err file) src/hotspot/share/utilities/debug.hpp line 41: > 39: #define CAN_SHOW_REGISTERS_ON_ASSERT > 40: extern char* g_assert_poison; > 41: extern const char* g_assert_poison_page_for_reporting; This g_assert_poison_page_for_reporting only exists to recognize assert poison crash when the assert poison itself is disarmed, right? So, during error reporting? Makes sense but proposal for simplification: - have two pointers initialized to the poison at arm time. E.g. "g_assert_poison" (the real one) and "g_assert_poison_copy" - on disarm, switch g_assert_poison but leave the other unchanged - when checking, always check against the copy - it never changes - now you can unify the several code pieces that do `if ((si->si_signo == SIGSEGV || si->si_signo == SIGBUS) && si->si_addr == g_assert_poison_copy)` to something like `bool VMError::was_assertion_poison_crash(siginfo)` ------------- PR Review: https://git.openjdk.org/jdk/pull/21994#pullrequestreview-2433304994 PR Review Comment: https://git.openjdk.org/jdk/pull/21994#discussion_r1840335300 PR Review Comment: https://git.openjdk.org/jdk/pull/21994#discussion_r1840352286 From aph-open at littlepinkcloud.com Wed Nov 13 14:59:09 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Wed, 13 Nov 2024 14:59:09 +0000 Subject: Redesign interface dispatch: progress report In-Reply-To: <9a3bd769-e551-432d-ae19-34b16829509a@oracle.com> References: <53d0c230-4d07-40a2-b5d9-0c5d71116e9b@redhat.com> <9a3bd769-e551-432d-ae19-34b16829509a@oracle.com> Message-ID: <48ea7e83-d459-40fb-acd7-fd65e93ca6f9@littlepinkcloud.com> On 11/13/24 01:11, dean.long at oracle.com wrote: > This work sounds related to JDK-8221828, which says about interface > dispatch: > > "The proposal for invokeinterface calls is to give each interface > method a unique number called "selector", and create a cuckoo-style > hash table mapping selectors to code pointers for the concrete > implementations of the interface method. The table is embedded > straight into the native class. This allows dispatching the majority > of the time with one indirect branch and one direct branch (compared > to two direct branches for dynamically monomorphic calls today)." Thank you for that reference. I discussed this at some length with Erik, the author of 8221828, at the time. The work I've been doing is a follow-on from his. I believe this result is more general than just testing one particular way of hashed lookup. Exactly what kind of hashing you do, as long as it isn't bad, doesn't matter much. Maybe it would be possible to shave a nanosecond in the predictable case, but that's it. Misprediction would be always slow. The more complex your hash function is, no matter how theoretically good, the harder it is for branch prediction. The current linear probe works remarkably well, probably because it is very simple. 8221828's proposal is similar to what I did, and I believe it would have similar performance. For this exercise, I used a small (16-way) embedded hash table in the Klass itself, with collisions handled by compressed hash tables. With a small number of interface methods we get few collisions, so its performance is very similar to any good hash table. I did consider global numbering, but went for a 64-bit hash function based on the full name of the method. Simply using the address of the Method as a key would be the same as a global number in its runtime complexity. The problem with embedding the entire hash table in a Klass is that of Klass size. I think it would be possible to compress code pointers to 32 bits, and also use 32-bit indexes, which would get that space back. But there is more pressure today, because of Liliput, on Klass size. Cuckoo hashing is a nice trick, but it has its own problems. To begin with, there are two possible table entries for each target. Also, Cuckoo needs multiple hash functions and fallbacks for when hashing fails, which isn't ideal for a generic hash table like we need here. What really matters is predictability, and that is more a function of user code. If the target of a megamorphic call really is random, that's going to hurt. -- 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 szaldana at openjdk.org Wed Nov 13 15:33:48 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Wed, 13 Nov 2024 15:33:48 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly Message-ID: Hi all, This PR addresses [8343700](https://bugs.openjdk.org/browse/JDK-8343700) where ceil_log2 looped endlessly if the input value has the highest bit set. I also dealt with the case where we try to find ceil_log2(1) which would've returned 1 as opposed to 0. Cheers, Sonia ------------- Commit messages: - 8343700: ceil_log2 should not loop endlessly Changes: https://git.openjdk.org/jdk/pull/22074/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22074&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343700 Stats: 24 lines in 2 files changed: 22 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22074.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22074/head:pull/22074 PR: https://git.openjdk.org/jdk/pull/22074 From aph at openjdk.org Wed Nov 13 16:16:37 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 13 Nov 2024 16:16:37 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 14:28:37 GMT, Sonia Zaldana Calles wrote: > Hi all, > > This PR addresses [8343700](https://bugs.openjdk.org/browse/JDK-8343700) where ceil_log2 looped endlessly if the input value has the highest bit set. > > I also dealt with the case where we try to find ceil_log2(1) which would've returned 1 as opposed to 0. > > Cheers, > Sonia Marked as reviewed by aph (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22074#pullrequestreview-2433734092 From duke at openjdk.org Wed Nov 13 16:24:00 2024 From: duke at openjdk.org (hanklo6) Date: Wed, 13 Nov 2024 16:24:00 GMT Subject: Integrated: 8343317: Extend test generation tool to handle APX NDD/NF flavor of instructions In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 20:57:37 GMT, hanklo6 wrote: > Extend test generation tool and gtest (added as part of https://bugs.openjdk.org/browse/JDK-8339507) to handle Intel APX NDD/NF instructions. > > Intel Advanced Performance Extensions (APX) adds non destructive destination (NDD) and no flags (NF) flavor for the scalar instructions through EVEX encoding. For more information about APX, see https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html. This pull request has now been integrated. Changeset: 916694f2 Author: hanklo6 Committer: Sandhya Viswanathan URL: https://git.openjdk.org/jdk/commit/916694f2c1e7fc8d6a88e7026bc2d29ba2923849 Stats: 3216 lines in 5 files changed: 2068 ins; 115 del; 1033 mod 8343317: Extend test generation tool to handle APX NDD/NF flavor of instructions Reviewed-by: sviswanathan, sparasa ------------- PR: https://git.openjdk.org/jdk/pull/21795 From coleenp at openjdk.org Wed Nov 13 16:32:13 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 13 Nov 2024 16:32:13 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v11] In-Reply-To: References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: On Wed, 13 Nov 2024 13:47:43 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> String interning can be done on 4 different types of strings: >> - oop-strings (unicode) >> - oop-strings (latin1) >> - Symbols (non-null-terminated utf8) >> - null-terminated utf8 char arrays >> >> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table. >> >> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation. >> >> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations. >> >> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build) >> >> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types. >> Also tested and passes tiers 1-3. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > removed whitespace src/hotspot/share/classfile/stringTable.hpp line 69: > 67: static unsigned int hash_wrapped_string(StringWrapper& wrapped_str); > 68: static const jchar* to_unicode(StringWrapper& wrapped_str, int &len, TRAPS); > 69: static Handle handle_from_wrapped_string(StringWrapper& wrapped_str, TRAPS); One last thing, should the be const references? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1840757711 From bstafford at openjdk.org Wed Nov 13 17:20:57 2024 From: bstafford at openjdk.org (Brian Stafford) Date: Wed, 13 Nov 2024 17:20:57 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 16:05:41 GMT, Saint Wesonga wrote: >> Bumping > >> Bumping > > Reviewing this change today. cc @brianjstafford @swesonga is out of office this week and will resume looking into this when he's back. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2474257928 From mgronlun at openjdk.org Wed Nov 13 17:21:57 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 13 Nov 2024 17:21:57 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v2] In-Reply-To: References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: On Wed, 13 Nov 2024 14:00:10 GMT, Thomas Stuefe wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> initialize report page > > src/hotspot/share/utilities/debug.cpp line 192: > >> 190: #ifdef CAN_SHOW_REGISTERS_ON_ASSERT >> 191: if (os::current_thread_id() == g_asserting_thread) { >> 192: context = os::get_saved_assert_context(&siginfo); > > I would leave the `g_assertion_context != nullptr` in. It should not happen, but its defensive and a bug at this point is difficult to figure out (because you just don't get a hs-err file) The g_assertion_context is a ucontext_t, which is why it cannot be in debug.cpp. The same test for nullptr exist in the os::get_saved_assert_context(), i.e. if the ucVoid came in as nullptr, then it is not saved, _has_saved_context == false. But if ucVoid came in as nullptr, then also os::current_thread_id() != g_asserting_thread, so I think it is sufficient. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21994#discussion_r1840862225 From mgronlun at openjdk.org Wed Nov 13 17:25:10 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 13 Nov 2024 17:25:10 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v2] In-Reply-To: References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: On Wed, 13 Nov 2024 14:07:24 GMT, Thomas Stuefe wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> initialize report page > > src/hotspot/share/utilities/debug.hpp line 41: > >> 39: #define CAN_SHOW_REGISTERS_ON_ASSERT >> 40: extern char* g_assert_poison; >> 41: extern const char* g_assert_poison_page_for_reporting; > > This g_assert_poison_page_for_reporting only exists to recognize assert poison crash when the assert poison itself is disarmed, right? So, during error reporting? > > Makes sense but proposal for simplification: > - have two pointers initialized to the poison at arm time. E.g. "g_assert_poison" (the real one) and "g_assert_poison_copy" > - on disarm, switch g_assert_poison but leave the other unchanged > - when checking, always check against the copy - it never changes > - now you can unify the several code pieces that do `if ((si->si_signo == SIGSEGV || si->si_signo == SIGBUS) && si->si_addr == g_assert_poison_copy)` to something like `bool VMError::was_assertion_poison_crash(siginfo)` void disarm_assert_poison() { g_assert_poison_page_for_reporting = g_assert_poison; g_assert_poison = &g_dummy; } Its only initialized when the real page deactivates. The purpose here for deactivation is to not get more traps, i.e. during further reporting? g_assert_poison_page_for_reporting is only used in print_siginfo() to skip printing the sigInfo, only applies on Windows, I believe. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21994#discussion_r1840870438 From coleenp at openjdk.org Wed Nov 13 17:26:22 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 13 Nov 2024 17:26:22 GMT Subject: RFR: 8344032: InterpreterRuntime::verify_mdp() missing lock while printing MethodData on failure Message-ID: Added locking. I injected some MethodData printing with logging to test this to verify that there wasn't a lock ranking assert. Tested with tier1-4. ------------- Commit messages: - 8344032: InterpreterRuntime::verify_mdp() missing lock while printing MethodData on failure Changes: https://git.openjdk.org/jdk/pull/22082/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22082&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344032 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22082.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22082/head:pull/22082 PR: https://git.openjdk.org/jdk/pull/22082 From mgronlun at openjdk.org Wed Nov 13 17:38:20 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 13 Nov 2024 17:38:20 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v2] In-Reply-To: References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: On Wed, 13 Nov 2024 14:10:28 GMT, Thomas Stuefe wrote: > I think this is mostly fine. I did look over the Windows implementation, but did not check it (I assume you did). Did you check for both architectures? > > One problem we have on Posix platforms is that ucontext_t was not meant to be copied around. IIRC, on some platforms (eg PPC), it is mother structure with a bunch of daughter structures that need to be copied too. Hope Windows is simpler. Have only checked Windows x64. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21994#issuecomment-2474297372 From szaldana at openjdk.org Wed Nov 13 18:29:04 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Wed, 13 Nov 2024 18:29:04 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v2] In-Reply-To: References: Message-ID: > Hi all, > > This PR addresses [8343700](https://bugs.openjdk.org/browse/JDK-8343700) where ceil_log2 looped endlessly if the input value has the highest bit set. > > I also dealt with the case where we try to find ceil_log2(1) which would've returned 1 as opposed to 0. > > Cheers, > Sonia Sonia Zaldana Calles 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 'openjdk:master' into JDK-8343700 - 8343700: ceil_log2 should not loop endlessly ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22074/files - new: https://git.openjdk.org/jdk/pull/22074/files/229441a6..0dd27068 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22074&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22074&range=00-01 Stats: 100572 lines in 2730 files changed: 23208 ins; 68851 del; 8513 mod Patch: https://git.openjdk.org/jdk/pull/22074.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22074/head:pull/22074 PR: https://git.openjdk.org/jdk/pull/22074 From shade at openjdk.org Wed Nov 13 18:38:57 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 13 Nov 2024 18:38:57 GMT Subject: RFR: 8344032: InterpreterRuntime::verify_mdp() missing lock while printing MethodData on failure In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 17:20:48 GMT, Coleen Phillimore wrote: > Added locking. I injected some MethodData printing with logging to test this to verify that there wasn't a lock ranking assert. > > Tested with tier1-4. src/hotspot/share/oops/methodData.cpp line 1561: > 1559: > 1560: void MethodData::print_data_on(outputStream* st) const { > 1561: MutexLocker ml(extra_data_lock(), Mutex::_no_safepoint_check_flag); Are we sure nothing calls this method when lock is already held? Safer to use `ConditionalMutexLocker` with self-locked check? src/hotspot/share/oops/methodData.hpp line 2514: > 2512: void clean_method_data(bool always_clean); > 2513: void clean_weak_method_links(); > 2514: Mutex* extra_data_lock() const { return const_cast(&_extra_data_lock); } Not sure what this const-ness gains us :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22082#discussion_r1840981366 PR Review Comment: https://git.openjdk.org/jdk/pull/22082#discussion_r1840981990 From shade at openjdk.org Wed Nov 13 18:39:00 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 13 Nov 2024 18:39:00 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v2] In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 18:29:04 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8343700](https://bugs.openjdk.org/browse/JDK-8343700) where ceil_log2 looped endlessly if the input value has the highest bit set. >> >> I also dealt with the case where we try to find ceil_log2(1) which would've returned 1 as opposed to 0. >> >> Cheers, >> Sonia > > Sonia Zaldana Calles 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 'openjdk:master' into JDK-8343700 > - 8343700: ceil_log2 should not loop endlessly src/hotspot/share/utilities/powerOfTwo.hpp line 127: > 125: inline T ceil_log2(T value) { > 126: assert(value > 0, "Invalid value"); > 127: if (value == 1) return 0; Is this the same as starting the loop from `ret = 0`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22074#discussion_r1840980246 From wkemper at openjdk.org Wed Nov 13 19:32:53 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 13 Nov 2024 19:32:53 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: > This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: - Merge branch 'merge-latest' into great-genshen-pr-redux - Use new CompactHeader forwarding APIs in generational mode - Merge remote-tracking branch 'jdk/master' into merge-latest - Merge - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines Reviewed-by: wkemper - Merge - 8343227: GenShen: Fold resource mark into management of preselected regions Reviewed-by: kdnilsen - Merge openjdk/jdk tip into great-genshen-pr-redux - Merge remote-tracking branch 'jdk/master' into merge-latest - Merge remote-tracking branch 'jdk/master' into merge-latest - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 ------------- Changes: https://git.openjdk.org/jdk/pull/21273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=06 Stats: 22977 lines in 231 files changed: 21234 ins; 886 del; 857 mod Patch: https://git.openjdk.org/jdk/pull/21273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21273/head:pull/21273 PR: https://git.openjdk.org/jdk/pull/21273 From coleenp at openjdk.org Wed Nov 13 19:53:04 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 13 Nov 2024 19:53:04 GMT Subject: RFR: 8344032: InterpreterRuntime::verify_mdp() missing lock while printing MethodData on failure [v2] In-Reply-To: References: Message-ID: > Added locking. I injected some MethodData printing with logging to test this to verify that there wasn't a lock ranking assert. > > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Use ConditionalMutexLocker instead. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22082/files - new: https://git.openjdk.org/jdk/pull/22082/files/f338305e..0eeb1415 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22082&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22082&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22082.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22082/head:pull/22082 PR: https://git.openjdk.org/jdk/pull/22082 From coleenp at openjdk.org Wed Nov 13 19:53:04 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 13 Nov 2024 19:53:04 GMT Subject: RFR: 8344032: InterpreterRuntime::verify_mdp() missing lock while printing MethodData on failure [v2] In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 19:49:34 GMT, Coleen Phillimore wrote: >> Added locking. I injected some MethodData printing with logging to test this to verify that there wasn't a lock ranking assert. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use ConditionalMutexLocker instead. Thanks for looking at this. ------------- PR Review: https://git.openjdk.org/jdk/pull/22082#pullrequestreview-2434268674 From coleenp at openjdk.org Wed Nov 13 19:53:04 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 13 Nov 2024 19:53:04 GMT Subject: RFR: 8344032: InterpreterRuntime::verify_mdp() missing lock while printing MethodData on failure [v2] In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 18:36:01 GMT, Aleksey Shipilev wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Use ConditionalMutexLocker instead. > > src/hotspot/share/oops/methodData.cpp line 1561: > >> 1559: >> 1560: void MethodData::print_data_on(outputStream* st) const { >> 1561: MutexLocker ml(extra_data_lock(), Mutex::_no_safepoint_check_flag); > > Are we sure nothing calls this method when lock is already held? Safer to use `ConditionalMutexLocker` with self-locked check? I don't really like ConditionalMutexLocker because it feels like a hack when we don't understand the control flow, but that said, there was a case I found with ciMethodData printing that already has the lock. It would have failed if any tests hit it. > src/hotspot/share/oops/methodData.hpp line 2514: > >> 2512: void clean_method_data(bool always_clean); >> 2513: void clean_weak_method_links(); >> 2514: Mutex* extra_data_lock() const { return const_cast(&_extra_data_lock); } > > Not sure what this const-ness gains us :) It gets us to compile line 1561 above in the print function which is const. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22082#discussion_r1841071283 PR Review Comment: https://git.openjdk.org/jdk/pull/22082#discussion_r1841071839 From szaldana at openjdk.org Wed Nov 13 19:58:32 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Wed, 13 Nov 2024 19:58:32 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v3] In-Reply-To: References: Message-ID: > Hi all, > > This PR addresses [8343700](https://bugs.openjdk.org/browse/JDK-8343700) where ceil_log2 looped endlessly if the input value has the highest bit set. > > I also dealt with the case where we try to find ceil_log2(1) which would've returned 1 as opposed to 0. > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: Starting ret at 0 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22074/files - new: https://git.openjdk.org/jdk/pull/22074/files/0dd27068..f82cc31d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22074&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22074&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22074.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22074/head:pull/22074 PR: https://git.openjdk.org/jdk/pull/22074 From shade at openjdk.org Wed Nov 13 19:58:32 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 13 Nov 2024 19:58:32 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v3] In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 19:55:16 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8343700](https://bugs.openjdk.org/browse/JDK-8343700) where ceil_log2 looped endlessly if the input value has the highest bit set. >> >> I also dealt with the case where we try to find ceil_log2(1) which would've returned 1 as opposed to 0. >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Starting ret at 0 Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22074#pullrequestreview-2434282264 From szaldana at openjdk.org Wed Nov 13 19:58:34 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Wed, 13 Nov 2024 19:58:34 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v2] In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 18:35:01 GMT, Aleksey Shipilev wrote: >> Sonia Zaldana Calles 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 'openjdk:master' into JDK-8343700 >> - 8343700: ceil_log2 should not loop endlessly > > src/hotspot/share/utilities/powerOfTwo.hpp line 127: > >> 125: inline T ceil_log2(T value) { >> 126: assert(value > 0, "Invalid value"); >> 127: if (value == 1) return 0; > > Is this the same as starting the loop from `ret = 0`? Yeah, I think so. Pushed an update since I agree it reads better that way. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22074#discussion_r1841076334 From shade at openjdk.org Wed Nov 13 20:02:14 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 13 Nov 2024 20:02:14 GMT Subject: RFR: 8344032: InterpreterRuntime::verify_mdp() missing lock while printing MethodData on failure [v2] In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 19:53:04 GMT, Coleen Phillimore wrote: >> Added locking. I injected some MethodData printing with logging to test this to verify that there wasn't a lock ranking assert. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use ConditionalMutexLocker instead. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22082#pullrequestreview-2434283099 From coleenp at openjdk.org Wed Nov 13 20:02:14 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 13 Nov 2024 20:02:14 GMT Subject: RFR: 8344032: InterpreterRuntime::verify_mdp() missing lock while printing MethodData on failure [v2] In-Reply-To: References: Message-ID: <16u9lb6TSlsz3NLkakFIy4GYgkz5Nvu7jkorOWlNSy8=.927abf2a-0a0d-4f56-a01c-130013d24ad8@github.com> On Wed, 13 Nov 2024 19:53:04 GMT, Coleen Phillimore wrote: >> Added locking. I injected some MethodData printing with logging to test this to verify that there wasn't a lock ranking assert. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use ConditionalMutexLocker instead. Thanks Aleksey. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22082#issuecomment-2474653074 From shade at openjdk.org Wed Nov 13 20:02:14 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 13 Nov 2024 20:02:14 GMT Subject: RFR: 8344032: InterpreterRuntime::verify_mdp() missing lock while printing MethodData on failure [v2] In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 19:48:37 GMT, Coleen Phillimore wrote: >> src/hotspot/share/oops/methodData.hpp line 2514: >> >>> 2512: void clean_method_data(bool always_clean); >>> 2513: void clean_weak_method_links(); >>> 2514: Mutex* extra_data_lock() const { return const_cast(&_extra_data_lock); } >> >> Not sure what this const-ness gains us :) > > It gets us to compile line 1561 above in the print function which is const. Ah, right. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22082#discussion_r1841080075 From iklam at openjdk.org Wed Nov 13 21:23:37 2024 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 13 Nov 2024 21:23:37 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v11] In-Reply-To: References: Message-ID: > This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). > > ---- > Note: this is a combined PR of the following individual PRs > - https://github.com/openjdk/jdk/pull/20516 > - https://github.com/openjdk/jdk/pull/20517 > - https://github.com/openjdk/jdk/pull/20843 > - https://github.com/openjdk/jdk/pull/20958 > - https://github.com/openjdk/jdk/pull/20959 > - https://github.com/openjdk/jdk/pull/21049 > - https://github.com/openjdk/jdk/pull/21143 Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 178 commits: - Merge branch 'master' into jep-483-candidate - fixed merge with UseCompactObjectHeaders - Merge branch 'master' into jep-483-candidate - fixed merge - Merge branch 'master' of https://github.com/openjdk/jdk into merge-mainline - @DanHeidinga comment -- exit VM when runtimeSetup() fails - fixed merge - Merge branch 'master' into jep-483-candidate - 8343493: Perform module checks during MetaspaceShared::map_archives() - reverted changes in modules.cpp to make it easy to merge with mainline - ... and 168 more: https://git.openjdk.org/jdk/compare/5e01c40b...fc86c00e ------------- Changes: https://git.openjdk.org/jdk/pull/21642/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=10 Stats: 7192 lines in 107 files changed: 6358 ins; 513 del; 321 mod Patch: https://git.openjdk.org/jdk/pull/21642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642 PR: https://git.openjdk.org/jdk/pull/21642 From gziemski at openjdk.org Wed Nov 13 22:21:12 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 13 Nov 2024 22:21:12 GMT Subject: RFR: 8328944: NMT reports "unknown" memory In-Reply-To: References: Message-ID: <0P1eFuX2RUUcKEhqyjZwvOOh8t2fz_mkM0zHTuM78Zc=.93971045-a0fd-4972-946d-160dfc3e0f42@github.com> On Fri, 1 Nov 2024 20:44:50 GMT, Gerard Ziemski wrote: > We use mtNone value in several functions default parameters, which may show up in NMT reports. > > We address this, by removing the default value and forcing, where possible, for the callers to declare NMT tag that reflects the usage. > > Eventually the goal would be not to use mtNone anywhere, but we are not there quite yet. > > TODO: update copyrights. > > Testing: undergoing MARCH5 tier1-5 ... Thank you very much everyone for feedback, and especially Thomas for so much details. I'm working through the feedback, but have some thoughts on the subject of tags that I would like to share. Here is how I would love to see NMT tags used: - An object starts its life with "mtNone" tag. I probably would prefer to call it "mtUnset" or "mtNull", but "mtNone" is OK too. - When the type is known at the allocation time, then use the corresponding tag and we are done. - When the type is NOT known at the allocation time, then we set the tag to a new tag named "mtAllocated", "mtUnknown" or "mtTransition" or something like that. Later, when we know exactly who owns such tagged memory object, we set it to its final value. This way we avoid the overloaded meaning of "mtNone" we have right now - either unset or truly unknown, or developer unfamiliar with NMT to know (or just plain too lazy) to propgate the tag value down. In this fix I'm not trying to fix all of it, I'm just trying to fix the particular case in the issue and further clean up the code a bit to make it one step closer towards the ultimate goal - making sure that we tag memory (if it's reasonable to figure it out). Last general thought on the tag transition from one value to another (not to be addressed here, but later), which we currently allow. It would be nice to have a general NMT API that controls how the tag values are allowed to change (similar to VirtualMemoryTracker::add_reserved_region). So instead of "mtAllocated" (as proposed) or "mtNone" (as we currently have), we would use a union of the subset of the tags, where the final value can be only one out of the union value (suddenly there is a use case here for tags to be "real" logical flags) - Currently we have: "mtNone" (which currently means both unset and unknown) allowed to be changed to any tag. - Partial fix, that I could do in this change: "mtNone" allowed to be changed to final tag, or to "mtAllocated". "mtAllocated" is allowed to be changed to any tag (this addresses the duality of "mtNone") - Ultimate fix (to be addressed in a followup): "mtNone" allowed to be changed to final tag, or to "mtAllocated" (if final tag could be anything), or to some union tag (if the final tag is expected to be one of a subset). Union tag can only be changed to one member of the uinion members. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21843#issuecomment-2474934177 From iklam at openjdk.org Wed Nov 13 22:33:23 2024 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 13 Nov 2024 22:33:23 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 11:42:11 GMT, Coleen Phillimore wrote: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. LGTM. Good to see all this code deleted. ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22064#pullrequestreview-2434607860 From wkemper at openjdk.org Wed Nov 13 23:10:51 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 13 Nov 2024 23:10:51 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Tue, 12 Nov 2024 14:25:30 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 503 commits: >> >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8342861: GenShen: Old generation in unexpected state when abandoning mixed gc candidates >> >> Reviewed-by: kdnilsen >> - 8342734: GenShen: Test failure gc/shenandoah/TestReferenceRefersToShenandoah.java#generational >> >> Reviewed-by: ysr >> - 8342919: GenShen: Fix whitespace >> >> Reviewed-by: xpeng, kdnilsen >> - 8342927: GenShen: Guarantee slices of time for coalesce and filling >> >> Reviewed-by: kdnilsen >> - 8342924: GenShen: Problem list gc/shenandoah/TestReferenceRefersToShenandoah.java >> >> Reviewed-by: kdnilsen, ysr >> - 8342848: Shenandoah: Marking bitmap may not be completely cleared in generational mode >> >> Reviewed-by: wkemper >> - ... and 493 more: https://git.openjdk.org/jdk/compare/1c448347...19b25bc3 > > test/hotspot/jtreg/gc/shenandoah/oom/TestThreadFailure.java line 61: > >> 59: // case that the previously instantiated NastyThread accumulated more than SheanndoahNoProgressThreshold >> 60: // unproductive GC cycles before failing, the main thread may not try a Full GC before it experiences >> 61: // OutOfMemoryError exception. > > Do you really need comments in this test? This test was a sore spot for us and we spent quite some time to make it pass. I don't think the code is very clear on its face about what the test expects, so I'd prefer to keep this comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841302676 From wkemper at openjdk.org Wed Nov 13 23:24:32 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 13 Nov 2024 23:24:32 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Wed, 13 Nov 2024 12:23:26 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 503 commits: >> >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8342861: GenShen: Old generation in unexpected state when abandoning mixed gc candidates >> >> Reviewed-by: kdnilsen >> - 8342734: GenShen: Test failure gc/shenandoah/TestReferenceRefersToShenandoah.java#generational >> >> Reviewed-by: ysr >> - 8342919: GenShen: Fix whitespace >> >> Reviewed-by: xpeng, kdnilsen >> - 8342927: GenShen: Guarantee slices of time for coalesce and filling >> >> Reviewed-by: kdnilsen >> - 8342924: GenShen: Problem list gc/shenandoah/TestReferenceRefersToShenandoah.java >> >> Reviewed-by: kdnilsen, ysr >> - 8342848: Shenandoah: Marking bitmap may not be completely cleared in generational mode >> >> Reviewed-by: wkemper >> - ... and 493 more: https://git.openjdk.org/jdk/compare/1c448347...19b25bc3 > > src/hotspot/share/gc/shenandoah/shenandoahAsserts.hpp line 238: > >> 236: #define shenandoah_assert_control_or_vm_thread_at_safepoint() >> 237: #define shenandoah_assert_generational() >> 238: #define shenandoah_assert_generations_reconciled() \ > > There seems to be dangling `` on this line. Good catch. > src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.cpp line 77: > >> 75: return reinterpret_cast(context); >> 76: } else { >> 77: if (_heap->is_concurrent_weak_root_in_progress()) { > > Comprehension check: We flips this because in generational mode we _can_ have both concurrent weak roots and concurrent mark in progress at the same time, and we need to prioritize evacs, right? Correct. Although no old marking threads will ever run during a young collection. > src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp line 50: > >> 48: switch (generation_type) { \ >> 49: case NON_GEN: \ >> 50: return prefix " (NON-GENERATIONAL)" postfix; \ > > In the interest of keeping the non-generational Shenandoah logging intact, should we drop ` (NON-GENERATIONAL)` here? No objections here. @ysramakrishna , @kdnilsen ? > src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp line 83: > >> 81: void VM_ShenandoahInitMark::doit() { >> 82: ShenandoahGCPauseMark mark(_gc_id, "Init Mark", SvcGCMarker::CONCURRENT); >> 83: set_active_generation(); > > Why is it here, and not down in `entry_*` methods, probably in helper classes? I think it's here for the same reason `propagate_gc_state_to_java_threads` is here. Having it here makes it easier to see that this critical synchronization step happens for every safepoint. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841308265 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841308915 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841310699 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841313192 From mgronlun at openjdk.org Wed Nov 13 23:35:22 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 13 Nov 2024 23:35:22 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v3] In-Reply-To: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: > Greetings, > > This enhancement adds register printouts on asserts or guarantees into the hs_err_pid.log error reporting files for Windows. > > Additionally, it saves an accurate EXCEPTION_RECORD into the hs_err_pid.mdmp file, also for asserts or guarantees, so the assertion context is now easily accessible in Windbg using .ecxr. > > For more details on this enhancement, please see the JIRA issue. > > Testing: Tier 1,2,3, jdk_jfr > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: refactor into VMError::was_assert_poison_crash ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21994/files - new: https://git.openjdk.org/jdk/pull/21994/files/9b80c688..1d37eb48 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21994&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21994&range=01-02 Stats: 52 lines in 7 files changed: 31 ins; 11 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/21994.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21994/head:pull/21994 PR: https://git.openjdk.org/jdk/pull/21994 From mgronlun at openjdk.org Wed Nov 13 23:35:23 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 13 Nov 2024 23:35:23 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v2] In-Reply-To: References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: <7ikHOD2Te76vTtOGiiq-sr_xJnZpfk3OCTOsQ_8alrc=.61e502c0-400e-46eb-9639-3c02e591a94e@github.com> On Wed, 13 Nov 2024 17:22:24 GMT, Markus Gr?nlund wrote: >> src/hotspot/share/utilities/debug.hpp line 41: >> >>> 39: #define CAN_SHOW_REGISTERS_ON_ASSERT >>> 40: extern char* g_assert_poison; >>> 41: extern const char* g_assert_poison_page_for_reporting; >> >> This g_assert_poison_page_for_reporting only exists to recognize assert poison crash when the assert poison itself is disarmed, right? So, during error reporting? >> >> Makes sense but proposal for simplification: >> - have two pointers initialized to the poison at arm time. E.g. "g_assert_poison" (the real one) and "g_assert_poison_copy" >> - on disarm, switch g_assert_poison but leave the other unchanged >> - when checking, always check against the copy - it never changes >> - now you can unify the several code pieces that do `if ((si->si_signo == SIGSEGV || si->si_signo == SIGBUS) && si->si_addr == g_assert_poison_copy)` to something like `bool VMError::was_assertion_poison_crash(siginfo)` > > void disarm_assert_poison() { > g_assert_poison_page_for_reporting = g_assert_poison; > g_assert_poison = &g_dummy; > } > > Its only initialized when the real page deactivates. > > g_assert_poison_page_for_reporting is only used in print_siginfo() to skip printing the sigInfo, and it only applies on Windows, I believe. > > I will try to see if there is value in attempting to put something consolidated into VMError. I think it turned out better. Thanks for the tip, Thomas. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21994#discussion_r1841320054 From wkemper at openjdk.org Wed Nov 13 23:35:28 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 13 Nov 2024 23:35:28 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Wed, 13 Nov 2024 23:14:23 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahAsserts.hpp line 238: >> >>> 236: #define shenandoah_assert_control_or_vm_thread_at_safepoint() >>> 237: #define shenandoah_assert_generational() >>> 238: #define shenandoah_assert_generations_reconciled() \ >> >> There seems to be dangling `` on this line. > > Good catch. https://bugs.openjdk.org/browse/JDK-8344151 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841320809 From wkemper at openjdk.org Wed Nov 13 23:35:29 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 13 Nov 2024 23:35:29 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Tue, 12 Nov 2024 19:41:14 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > test/hotspot/jtreg/ProblemList.txt line 98: > >> 96: gc/TestAlwaysPreTouchBehavior.java#Epsilon 8334513 generic-all >> 97: gc/stress/gclocker/TestExcessGCLockerCollections.java 8229120 generic-all >> 98: > > This change is unnecessary. https://bugs.openjdk.org/browse/JDK-8344151 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841321018 From wkemper at openjdk.org Wed Nov 13 23:35:28 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 13 Nov 2024 23:35:28 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Wed, 13 Nov 2024 11:01:59 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 503 commits: >> >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8342861: GenShen: Old generation in unexpected state when abandoning mixed gc candidates >> >> Reviewed-by: kdnilsen >> - 8342734: GenShen: Test failure gc/shenandoah/TestReferenceRefersToShenandoah.java#generational >> >> Reviewed-by: ysr >> - 8342919: GenShen: Fix whitespace >> >> Reviewed-by: xpeng, kdnilsen >> - 8342927: GenShen: Guarantee slices of time for coalesce and filling >> >> Reviewed-by: kdnilsen >> - 8342924: GenShen: Problem list gc/shenandoah/TestReferenceRefersToShenandoah.java >> >> Reviewed-by: kdnilsen, ysr >> - 8342848: Shenandoah: Marking bitmap may not be completely cleared in generational mode >> >> Reviewed-by: wkemper >> - ... and 493 more: https://git.openjdk.org/jdk/compare/1c448347...19b25bc3 > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 118: > >> 116: #ifdef ASSERT >> 117: assert(_union_tag != is_uninitialized, "Cannot fetch region from uninialized RegionData"); >> 118: #endif > > Style: No point in wrapping single-line `assert`-s in `#ifdef ASSERT`. https://bugs.openjdk.org/browse/JDK-8344151 > src/hotspot/share/gc/shenandoah/shenandoahVMOperations.hpp line 41: > >> 39: // - VM_ShenandoahInitUpdateRefs: initiate update references >> 40: // - VM_ShenandoahFinalUpdateRefs: finish up update references >> 41: // - VM_ShenandoahFinalRoots > > If we add it here, let's provide a comment: > > > // - VM_ShenandoahFinalRoots: finish up the roots, shortcut cycle https://bugs.openjdk.org/browse/JDK-8344151 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841320875 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841320596 From wkemper at openjdk.org Wed Nov 13 23:44:43 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 13 Nov 2024 23:44:43 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Wed, 13 Nov 2024 10:57:08 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 503 commits: >> >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8342861: GenShen: Old generation in unexpected state when abandoning mixed gc candidates >> >> Reviewed-by: kdnilsen >> - 8342734: GenShen: Test failure gc/shenandoah/TestReferenceRefersToShenandoah.java#generational >> >> Reviewed-by: ysr >> - 8342919: GenShen: Fix whitespace >> >> Reviewed-by: xpeng, kdnilsen >> - 8342927: GenShen: Guarantee slices of time for coalesce and filling >> >> Reviewed-by: kdnilsen >> - 8342924: GenShen: Problem list gc/shenandoah/TestReferenceRefersToShenandoah.java >> >> Reviewed-by: kdnilsen, ysr >> - 8342848: Shenandoah: Marking bitmap may not be completely cleared in generational mode >> >> Reviewed-by: wkemper >> - ... and 493 more: https://git.openjdk.org/jdk/compare/1c448347...19b25bc3 > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 67: > >> 65: _region_data[i].clear(); >> 66: } >> 67: #endif > > I understand this is to make sure `union_tag` works well. But why don't we extend `clear` to initialize all fields, and do this block without `ASSERT`? This does not look like frequently used path. Generally, doing these inits only for debug modes might hide some assertion failures that would indicate a problem in product builds. https://bugs.openjdk.org/browse/JDK-8344152 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841326159 From dholmes at openjdk.org Thu Nov 14 02:20:08 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Nov 2024 02:20:08 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v11] In-Reply-To: References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: On Wed, 13 Nov 2024 13:47:43 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> String interning can be done on 4 different types of strings: >> - oop-strings (unicode) >> - oop-strings (latin1) >> - Symbols (non-null-terminated utf8) >> - null-terminated utf8 char arrays >> >> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table. >> >> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation. >> >> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations. >> >> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build) >> >> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types. >> Also tested and passes tiers 1-3. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > removed whitespace Still good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21325#pullrequestreview-2434889767 From fyang at openjdk.org Thu Nov 14 02:38:21 2024 From: fyang at openjdk.org (Fei Yang) Date: Thu, 14 Nov 2024 02:38:21 GMT Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well: C1 and interpreter In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 10:33:55 GMT, Gui Cao wrote: > Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter. > > ### Testing > - [x] Run tier1-3 tests on SOPHON SG2042 (release) Hi, as the JDK 24 RDP 1 is near, I would suggest we postpone this non-trivial optimization to JDK 25. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21922#issuecomment-2475290508 From prr at openjdk.org Thu Nov 14 04:37:13 2024 From: prr at openjdk.org (Phil Race) Date: Thu, 14 Nov 2024 04:37:13 GMT Subject: RFR: 8343490: Update copyright year for JDK-8341692 In-Reply-To: <2BwWuKdm5FwggsXPwo3P2xRD6CGr5QDdn3gVG5x5fo0=.41d944e6-6737-4d7d-8654-986149b41c9d@github.com> References: <2BwWuKdm5FwggsXPwo3P2xRD6CGr5QDdn3gVG5x5fo0=.41d944e6-6737-4d7d-8654-986149b41c9d@github.com> Message-ID: <9R5gF8dIqwO0TbBhICMDC7c2g4gvY0tXA82LcvmAEpI=.4159e63b-4899-48d9-9829-0f13c6307446@github.com> On Tue, 5 Nov 2024 01:41:00 GMT, SendaoYan wrote: > Hi all, > The copyright year of some files which has been changed by [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692) wasn't update correctly. This PR update the copyright year of [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692). Trivial fix, no risk. FWIW this whole PR seems like a waste of a bug id. Copyright year is implied anyway. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21891#issuecomment-2475394959 From swen at openjdk.org Thu Nov 14 05:47:12 2024 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 14 Nov 2024 05:47:12 GMT Subject: RFR: 8344168: Change Unsafe base offset from int to long Message-ID: The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed. @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea. ------------- Commit messages: - long Unsafe offset Changes: https://git.openjdk.org/jdk/pull/22095/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22095&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344168 Stats: 70 lines in 21 files changed: 0 ins; 0 del; 70 mod Patch: https://git.openjdk.org/jdk/pull/22095.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22095/head:pull/22095 PR: https://git.openjdk.org/jdk/pull/22095 From amitkumar at openjdk.org Thu Nov 14 05:50:51 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 14 Nov 2024 05:50:51 GMT Subject: RFR: 8327652: S390x: Implements SLP support [v12] In-Reply-To: References: Message-ID: On Mon, 14 Oct 2024 09:07:53 GMT, Sidraya Jayagond wrote: >> This PR Adds SIMD support on s390x. > > Sidraya Jayagond has updated the pull request incrementally with one additional commit since the last revision: > > Disable vector instructions from string intrinsics > > Address Lutz's comments. > Disable vector instructions from string intrinsics will be > enabled once PR to JDK-8336356 gets integrates. I ran [tests again](https://github.com/offamitkumar/OpenJDK-s390x-Reports/commit/9a7c2a7405a54ee3f049ad6a4ccf2133cb8b12b3#diff-8dbf1c6ef429df6da64729101a6f4a0c573712068bd9e79cf755ec6ab0aab5ca) and no regression I have seen. Also intrinsics are disabled now. Looks good. ------------- Marked as reviewed by amitkumar (Committer). PR Review: https://git.openjdk.org/jdk/pull/18162#pullrequestreview-2435098533 From amitkumar at openjdk.org Thu Nov 14 05:50:52 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 14 Nov 2024 05:50:52 GMT Subject: RFR: 8327652: S390x: Implements SLP support [v7] In-Reply-To: References: Message-ID: On Tue, 20 Aug 2024 17:32:23 GMT, Lutz Schmidt wrote: >> Sidraya Jayagond has updated the pull request incrementally with one additional commit since the last revision: >> >> PopCountVI supported by z14 onwards. > > Hi Amit, > > the function prototype now reads > uint MachSpillCopyNode::implementation(C2_MacroAssembler *masm, PhaseRegAlloc *ra_, bool do_size, outputStream *os) const { > > There is no cbuf argument anymore. > > Side note: I would prefer to see > If (masm != nullprt) > Instead of > If (masm) > > Thanks, > Lutz > > From: Amit Kumar ***@***.***> > Date: Tuesday, 20. August 2024 at 18:26 > To: openjdk/jdk ***@***.***> > Cc: Schmidt, Lutz ***@***.***>, Mention ***@***.***> > Subject: Re: [openjdk/jdk] 8327652: S390x: Implements SLP support (PR #18162) > > There is another problem, Build is broken with these changes. > > If we just pull the changes from this PR and do a build, this is the error I was getting: > > /home/amit/jdk/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java warning: [dangling-doc-comments] documentation comment is not attached to any declaration > > Then I thought maybe any dependency is causing issue and might have pick the latest changes; So I rebased it with head stream and was welcomed by this error: > > * For target hotspot_variant-server_libjvm_objs_ad_s390.o: > > /home/amit/jdk/src/hotspot/cpu/s390/s390.ad: In member function 'uint MachSpillCopyNode::implementation(C2_MacroAssembler*, PhaseRegAlloc*, bool, outputStream*) const': > > /home/amit/jdk/src/hotspot/cpu/s390/s390.ad:1153:11: error: 'cbuf' was not declared in this scope > > 1153 | if (cbuf) { > > | ^~~~ > > /home/amit/jdk/src/hotspot/cpu/s390/s390.ad:1160:11: error: 'cbuf' was not declared in this scope > > 1160 | if (cbuf) { > > | ^~~~ > > /home/amit/jdk/src/hotspot/cpu/s390/s390.ad:1167:11: error: 'cbuf' was not declared in this scope > > 1167 | if (cbuf) { > > | ^~~~ > > /home/amit/jdk/src/hotspot/cpu/s390/s390.ad:1175:11: error: 'cbuf' was not declared in this scope > > 1175 | if (cbuf) { > > | ^~~~ > > Weird thing is that initially it was building fine with all of the VMs (fastdebug, slowdebug, release). > > ? > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you were mentioned.Message ID: ***@***.***> @RealLucy Would you take another look and check if it?s ready to be shipped? ------------- PR Comment: https://git.openjdk.org/jdk/pull/18162#issuecomment-2475469958 From syan at openjdk.org Thu Nov 14 06:16:22 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 14 Nov 2024 06:16:22 GMT Subject: Withdrawn: 8343490: Update copyright year for JDK-8341692 In-Reply-To: <2BwWuKdm5FwggsXPwo3P2xRD6CGr5QDdn3gVG5x5fo0=.41d944e6-6737-4d7d-8654-986149b41c9d@github.com> References: <2BwWuKdm5FwggsXPwo3P2xRD6CGr5QDdn3gVG5x5fo0=.41d944e6-6737-4d7d-8654-986149b41c9d@github.com> Message-ID: On Tue, 5 Nov 2024 01:41:00 GMT, SendaoYan wrote: > Hi all, > The copyright year of some files which has been changed by [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692) wasn't update correctly. This PR update the copyright year of [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692). Trivial fix, no risk. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/21891 From dholmes at openjdk.org Thu Nov 14 06:20:03 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Nov 2024 06:20:03 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 11:42:11 GMT, Coleen Phillimore wrote: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. @coleenp it is great to see all this code go but I'm unclear about the uses of "protection domain" that have been removed, compared to those that still remain in the hotspot code in particular how CDS still uses it. To be fair I'm unclear what role PD still plays on the JDK side and would not be surprised if it is destined for removal at some point. How do we recognise that the remaining uses of and reference to the PD are still needed and not something we could now delete? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2475502902 From alanb at openjdk.org Thu Nov 14 07:05:23 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 14 Nov 2024 07:05:23 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: Message-ID: <9odgI41Erhmy3c5sk7YgS_NR61BaYO933G0HwPHRJNw=.54e7cb3b-98bf-4ec8-94f7-8032b52eb773@github.com> On Thu, 14 Nov 2024 06:16:56 GMT, David Holmes wrote: > To be fair I'm unclear what role PD still plays on the JDK side and would not be surprised if it is destined for removal at some point. PD is not deprecated as PD::getCodeSource is widely used. It may be that an alternative means is introduced in the future to expose the code location but nothing specific at this time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2475563544 From enikitin at openjdk.org Thu Nov 14 07:08:39 2024 From: enikitin at openjdk.org (Evgeny Nikitin) Date: Thu, 14 Nov 2024 07:08:39 GMT Subject: RFR: 8344003: WB: Add option to skip clinit during class loading for testing In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 08:18:48 GMT, Evgeny Nikitin wrote: > This PR adds a White-Box controlled option to skip `clinit` methods during class loading. > Such a feature would allow for non-executing testing techniques of random and untrusted jars/classes in CI systems without being afraid of breaking or harming the running system. > > The clinit skipping does not affect core libraries (i.e. those under `java`, `jdk` and `sun` packages), and will only be available in debug builds. The solution is not enough to ensure security due to static fields initialization (which may have its own code). Withdrawing for now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22030#issuecomment-2475570538 From enikitin at openjdk.org Thu Nov 14 07:08:40 2024 From: enikitin at openjdk.org (Evgeny Nikitin) Date: Thu, 14 Nov 2024 07:08:40 GMT Subject: Withdrawn: 8344003: WB: Add option to skip clinit during class loading for testing In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 08:18:48 GMT, Evgeny Nikitin wrote: > This PR adds a White-Box controlled option to skip `clinit` methods during class loading. > Such a feature would allow for non-executing testing techniques of random and untrusted jars/classes in CI systems without being afraid of breaking or harming the running system. > > The clinit skipping does not affect core libraries (i.e. those under `java`, `jdk` and `sun` packages), and will only be available in debug builds. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22030 From stuefe at openjdk.org Thu Nov 14 07:10:08 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 14 Nov 2024 07:10:08 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v3] In-Reply-To: References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: On Wed, 13 Nov 2024 23:35:22 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> This enhancement adds register printouts on asserts or guarantees into the hs_err_pid.log error reporting files for Windows. >> >> Additionally, it saves an accurate EXCEPTION_RECORD into the hs_err_pid.mdmp file, also for asserts or guarantees, so the assertion context is now easily accessible in Windbg using .ecxr. >> >> For more details on this enhancement, please see the JIRA issue. >> >> Testing: Tier 1,2,3, jdk_jfr >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > refactor into VMError::was_assert_poison_crash Looks good. Would it be possible for you to extend the test a bit, at least for x64, to test for registers to have appeared? E.g. RIP or RAX. ------------- PR Review: https://git.openjdk.org/jdk/pull/21994#pullrequestreview-2435209337 From stuefe at openjdk.org Thu Nov 14 07:16:45 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 14 Nov 2024 07:16:45 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v3] In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 19:58:32 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8343700](https://bugs.openjdk.org/browse/JDK-8343700) where ceil_log2 looped endlessly if the input value has the highest bit set. >> >> I also dealt with the case where we try to find ceil_log2(1) which would've returned 1 as opposed to 0. >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Starting ret at 0 +1 ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22074#pullrequestreview-2435217253 From tanksherman27 at gmail.com Thu Nov 14 07:33:04 2024 From: tanksherman27 at gmail.com (Julian Waters) Date: Thu, 14 Nov 2024 15:33:04 +0800 Subject: Win32AttachOperationRequest seems to be using global new? In-Reply-To: References: Message-ID: Bumping, I'm still curious about this issue best regards, Julian On Tue, Nov 12, 2024 at 10:20?PM Julian Waters wrote: > > Hi all, > > Win32AttachOperationRequest is created via new, but doesn't specify a custom new inside the class definition. The result seems to be that we use global new on Windows: > > for (int i=0; i Win32AttachOperationRequest* op = new Win32AttachOperationRequest(); > f1: b9 28 0d 00 00 mov ecx,0xd28 > f6: e8 00 00 00 00 call fb > f7: IMAGE_REL_AMD64_REL32 operator new(unsigned long long) > > Stepping away from gcc's objdump and using the Microsoft dumpbin alongside cl.exe instead, the result is this: > > 0000000000000264: B9 28 0D 00 00 mov ecx,0D28h > 0000000000000269: E8 00 00 00 00 call ??2 at YAPEAX_K@Z > 000000000000026E: 48 89 44 24 28 mov qword ptr [rsp+28h],rax > 0000000000000273: 48 83 7C 24 28 00 cmp qword ptr [rsp+28h],0 > 0000000000000279: 74 11 je 000000000000028C > 000000000000027B: 48 8B 4C 24 28 mov rcx,qword ptr [rsp+28h] > 0000000000000280: E8 00 00 00 00 call ??0Win32AttachOperationRequest@@QEAA at XZ > > undname "??2 at YAPEAX_K@Z" > Microsoft (R) C++ Name Undecorator > Copyright (C) Microsoft Corporation. All rights reserved. > > Undecoration of :- "??2 at YAPEAX_K@Z" > is :- "void * __ptr64 __cdecl operator new(unsigned __int64)" > > undname "??0Win32AttachOperationRequest@@QEAA at XZ" > Microsoft (R) C++ Name Undecorator > Copyright (C) Microsoft Corporation. All rights reserved. > > Undecoration of :- "??0Win32AttachOperationRequest@@QEAA at XZ" > is :- "public: __cdecl Win32AttachOperationRequest::Win32AttachOperationRequest(void) __ptr64" > > Visual Studio, lacking the nm utility, obviously doesn't catch this. What was more surprising is that the gcc Link Time check also fails to catch it as well. I had to manually check the output of nm after an unrelated failure and happened to stumble across the symbols _Znwy and _ZdlPvy which both correspond to > > operator new(unsigned long long) > operator delete(void*, unsigned long long) > > The delete can be ignored, it's the result of a bug on my experimental branch (It was first discovered there, then I tested it on master). I'm more interested about the new, since it seems to be violating a HotSpot rule. Is this an intentional exception to the rule, or an oversight? > > best regards, > Julian From dholmes at openjdk.org Thu Nov 14 07:44:30 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Nov 2024 07:44:30 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 11:42:11 GMT, Coleen Phillimore wrote: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. This is a great cleanup! I may have missed something, but it seems to me that `java_security_AccessControlContext` is all dead code now too. Thanks src/hotspot/share/ci/ciEnv.cpp line 1613: > 1611: > 1612: // The very first entry is the InstanceKlass of the root method of the current compilation in order to get the right > 1613: // (class loader???) protection domain to load subsequent classes during replay compilation. Suggestion: simply have: // The very first entry is the InstanceKlass of the root method of the current compilation . The rest of the comment doesn't really make sense even before your change as this method basically just prints the class name src/hotspot/share/classfile/dictionary.cpp line 80: > 78: > 79: void Dictionary::Config::free_node(void* context, void* memory, Value const& value) { > 80: delete value; // Call DictionaryEntry destructor `using Value = XXX` seems like an unwanted/unnecessary abstraction in this code, because depending on what `XX` is you either will or won't need to call `delete`. That is a more general cleanup though. src/hotspot/share/classfile/javaClasses.hpp line 1545: > 1543: static int _static_security_offset; > 1544: static int _static_allow_security_offset; > 1545: static int _static_never_offset; Guess these were missed by the main PR as they are unused. :) src/hotspot/share/classfile/systemDictionary.hpp line 239: > 237: // compute java_mirror (java.lang.Class instance) for a type ("I", "[[B", "LFoo;", etc.) > 238: // Either the accessing_klass or the CL can be non-null, but not both. > 239: // callee will fill in CL from AK, if they are needed Suggestion: // Callee will fill in CL from accessing_klass, if they are needed. src/hotspot/share/logging/logTag.hpp line 163: > 161: LOG_TAG(preview) /* Trace loading of preview feature types */ \ > 162: LOG_TAG(promotion) \ > 163: LOG_TAG(protectiondomain) /* "Trace protection domain verification" */ \ Not 100% sure about this. We don't really have a policy for "deprecating" or removing log tags. I think it unlikely anyone enables this logging "just because", so it seems okay for this case. ------------- PR Review: https://git.openjdk.org/jdk/pull/22064#pullrequestreview-2435096096 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1841595529 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1841597831 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1841688595 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1841691487 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1841698260 From fyang at openjdk.org Thu Nov 14 07:48:37 2024 From: fyang at openjdk.org (Fei Yang) Date: Thu, 14 Nov 2024 07:48:37 GMT Subject: RFR: 8344169: RISC-V: Use more meaningful frame::metadata_words where possible Message-ID: <9XNv_0zgwAVjUaUjVSxFFkwvzUFp3f2Lu8MvPyFv8l8=.d6d9457a-e737-4169-a198-7ea88cfde0db@github.com> Hello, please review this RISC-V specific change which improves code readability. Some background to help understand. We have following frame enumerations in file frame_riscv.hpp: enum { link_offset = -2, return_addr_offset = -1, sender_sp_offset = 0 }; The values are compatible with the platform ABI and are different from the other platforms like x64 or aarch64. Especially, `sender_sp_offset` is 0 for RISC-V compared to 2 for the other platforms. As a result, there exists some differences in places where code uses value of `sender_sp_offset` as an sp offset when fp is needed. For RISC-V, we used constant number 2 instead of `sender_sp_offset` as the sp offset. But the code will be more readable if we use `frame::metadata_words` which has the same value. Testing on linux-riscv64: - [x] "hotspot_loom jdk_loom" (release & fastdebug) ------------- Commit messages: - 8344169: RISC-V: Use more meaningful frame::metadata_words where possible Changes: https://git.openjdk.org/jdk/pull/22096/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22096&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344169 Stats: 27 lines in 7 files changed: 5 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/22096.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22096/head:pull/22096 PR: https://git.openjdk.org/jdk/pull/22096 From dholmes at openjdk.org Thu Nov 14 07:56:15 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Nov 2024 07:56:15 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: <9odgI41Erhmy3c5sk7YgS_NR61BaYO933G0HwPHRJNw=.54e7cb3b-98bf-4ec8-94f7-8032b52eb773@github.com> References: <9odgI41Erhmy3c5sk7YgS_NR61BaYO933G0HwPHRJNw=.54e7cb3b-98bf-4ec8-94f7-8032b52eb773@github.com> Message-ID: On Thu, 14 Nov 2024 07:01:54 GMT, Alan Bateman wrote: > > To be fair I'm unclear what role PD still plays on the JDK side and would not be surprised if it is destined for removal at some point. > > PD is not deprecated as PD::getCodeSource is widely used. It may be that an alternative means is introduced in the future to expose the code location but nothing specific at this time. Okay but I still remain unclear about the role of PD in the VM, in particular how CDS is using it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2475647661 From dholmes at openjdk.org Thu Nov 14 08:02:30 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Nov 2024 08:02:30 GMT Subject: RFR: 8344032: InterpreterRuntime::verify_mdp() missing lock while printing MethodData on failure [v2] In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 19:53:04 GMT, Coleen Phillimore wrote: >> Added locking. I injected some MethodData printing with logging to test this to verify that there wasn't a lock ranking assert. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use ConditionalMutexLocker instead. LGTM2 Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22082#pullrequestreview-2435294789 From tschatzl at openjdk.org Thu Nov 14 08:18:49 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 14 Nov 2024 08:18:49 GMT Subject: RFR: 8344032: InterpreterRuntime::verify_mdp() missing lock while printing MethodData on failure [v2] In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 19:53:04 GMT, Coleen Phillimore wrote: >> Added locking. I injected some MethodData printing with logging to test this to verify that there wasn't a lock ranking assert. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use ConditionalMutexLocker instead. Thanks, fixes the issue. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22082#pullrequestreview-2435326686 From david.holmes at oracle.com Thu Nov 14 08:24:09 2024 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Nov 2024 18:24:09 +1000 Subject: Win32AttachOperationRequest seems to be using global new? In-Reply-To: References: Message-ID: <8ec38c62-69d5-4821-b160-0148c41581ea@oracle.com> It was added by JDK-8339289 so cc'ing Alex. David On 14/11/2024 5:33 pm, Julian Waters wrote: > Bumping, I'm still curious about this issue > > best regards, > Julian > > On Tue, Nov 12, 2024 at 10:20?PM Julian Waters wrote: >> Hi all, >> >> Win32AttachOperationRequest is created via new, but doesn't specify a custom new inside the class definition. The result seems to be that we use global new on Windows: >> >> for (int i=0; i> Win32AttachOperationRequest* op = new Win32AttachOperationRequest(); >> f1: b9 28 0d 00 00 mov ecx,0xd28 >> f6: e8 00 00 00 00 call fb >> f7: IMAGE_REL_AMD64_REL32 operator new(unsigned long long) >> >> Stepping away from gcc's objdump and using the Microsoft dumpbin alongside cl.exe instead, the result is this: >> >> 0000000000000264: B9 28 0D 00 00 mov ecx,0D28h >> 0000000000000269: E8 00 00 00 00 call ??2 at YAPEAX_K@Z >> 000000000000026E: 48 89 44 24 28 mov qword ptr [rsp+28h],rax >> 0000000000000273: 48 83 7C 24 28 00 cmp qword ptr [rsp+28h],0 >> 0000000000000279: 74 11 je 000000000000028C >> 000000000000027B: 48 8B 4C 24 28 mov rcx,qword ptr [rsp+28h] >> 0000000000000280: E8 00 00 00 00 call ??0Win32AttachOperationRequest@@QEAA at XZ >> >> undname "??2 at YAPEAX_K@Z" >> Microsoft (R) C++ Name Undecorator >> Copyright (C) Microsoft Corporation. All rights reserved. >> >> Undecoration of :- "??2 at YAPEAX_K@Z" >> is :- "void * __ptr64 __cdecl operator new(unsigned __int64)" >> >> undname "??0Win32AttachOperationRequest@@QEAA at XZ" >> Microsoft (R) C++ Name Undecorator >> Copyright (C) Microsoft Corporation. All rights reserved. >> >> Undecoration of :- "??0Win32AttachOperationRequest@@QEAA at XZ" >> is :- "public: __cdecl Win32AttachOperationRequest::Win32AttachOperationRequest(void) __ptr64" >> >> Visual Studio, lacking the nm utility, obviously doesn't catch this. What was more surprising is that the gcc Link Time check also fails to catch it as well. I had to manually check the output of nm after an unrelated failure and happened to stumble across the symbols _Znwy and _ZdlPvy which both correspond to >> >> operator new(unsigned long long) >> operator delete(void*, unsigned long long) >> >> The delete can be ignored, it's the result of a bug on my experimental branch (It was first discovered there, then I tested it on master). I'm more interested about the new, since it seems to be violating a HotSpot rule. Is this an intentional exception to the rule, or an oversight? >> >> best regards, >> Julian From david.holmes at oracle.com Thu Nov 14 08:28:15 2024 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Nov 2024 18:28:15 +1000 Subject: Win32AttachOperationRequest seems to be using global new? In-Reply-To: <8ec38c62-69d5-4821-b160-0148c41581ea@oracle.com> References: <8ec38c62-69d5-4821-b160-0148c41581ea@oracle.com> Message-ID: That didn't work so cc'ing serviceability-dev I think it was just an oversight. David On 14/11/2024 6:24 pm, David Holmes wrote: > It was added by JDK-8339289 so cc'ing Alex. > > David > > On 14/11/2024 5:33 pm, Julian Waters wrote: >> Bumping, I'm still curious about this issue >> >> best regards, >> Julian >> >> On Tue, Nov 12, 2024 at 10:20?PM Julian Waters >> wrote: >>> Hi all, >>> >>> Win32AttachOperationRequest is created via new, but doesn't specify a >>> custom new inside the class definition. The result seems to be that >>> we use global new on Windows: >>> >>> ?? for (int i=0; i>> ???? Win32AttachOperationRequest* op = new >>> Win32AttachOperationRequest(); >>> ?????? f1: b9 28 0d 00 00?????? mov??? ecx,0xd28 >>> ?????? f6: e8 00 00 00 00?????? call?? fb >>> >>> f7: IMAGE_REL_AMD64_REL32 operator new(unsigned long long) >>> >>> Stepping away from gcc's objdump and using the Microsoft dumpbin >>> alongside cl.exe instead, the result is this: >>> >>> ?? 0000000000000264: B9 28 0D 00 00???? mov???????? ecx,0D28h >>> ?? 0000000000000269: E8 00 00 00 00???? call??????? ??2 at YAPEAX_K@Z >>> ?? 000000000000026E: 48 89 44 24 28???? mov???????? qword ptr >>> [rsp+28h],rax >>> ?? 0000000000000273: 48 83 7C 24 28 00? cmp???????? qword ptr >>> [rsp+28h],0 >>> ?? 0000000000000279: 74 11????????????? je????????? 000000000000028C >>> ?? 000000000000027B: 48 8B 4C 24 28???? mov???????? rcx,qword ptr >>> [rsp+28h] >>> ?? 0000000000000280: E8 00 00 00 00???? call??????? ?? >>> 0Win32AttachOperationRequest@@QEAA at XZ >>> >>> undname "??2 at YAPEAX_K@Z" >>> Microsoft (R) C++ Name Undecorator >>> Copyright (C) Microsoft Corporation. All rights reserved. >>> >>> Undecoration of :- "??2 at YAPEAX_K@Z" >>> is :- "void * __ptr64 __cdecl operator new(unsigned __int64)" >>> >>> undname "??0Win32AttachOperationRequest@@QEAA at XZ" >>> Microsoft (R) C++ Name Undecorator >>> Copyright (C) Microsoft Corporation. All rights reserved. >>> >>> Undecoration of :- "??0Win32AttachOperationRequest@@QEAA at XZ" >>> is :- "public: __cdecl >>> Win32AttachOperationRequest::Win32AttachOperationRequest(void) __ptr64" >>> >>> Visual Studio, lacking the nm utility, obviously doesn't catch this. >>> What was more surprising is that the gcc Link Time check also fails >>> to catch it as well. I had to manually check the output of nm after >>> an unrelated failure and happened to stumble across the symbols _Znwy >>> and _ZdlPvy which both correspond to >>> >>> operator new(unsigned long long) >>> operator delete(void*, unsigned long long) >>> >>> The delete can be ignored, it's the result of a bug on my >>> experimental branch (It was first discovered there, then I tested it >>> on master). I'm more interested about the new, since it seems to be >>> violating a HotSpot rule. Is this an intentional exception to the >>> rule, or an oversight? >>> >>> best regards, >>> Julian From alanb at openjdk.org Thu Nov 14 08:31:32 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 14 Nov 2024 08:31:32 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 11:42:11 GMT, Coleen Phillimore wrote: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. @coleenp Do you plan a follow-up to purge the remaining refs to AccessController and AccessControlContext? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2475708718 From kbarrett at openjdk.org Thu Nov 14 08:37:16 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 14 Nov 2024 08:37:16 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v3] In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 19:58:32 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8343700](https://bugs.openjdk.org/browse/JDK-8343700) where ceil_log2 looped endlessly if the input value has the highest bit set. >> >> I also dealt with the case where we try to find ceil_log2(1) which would've returned 1 as opposed to 0. >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > Starting ret at 0 Changes requested by kbarrett (Reviewer). src/hotspot/share/utilities/powerOfTwo.hpp line 125: > 123: // Find log2 value greater than this input > 124: template ::value)> > 125: inline T ceil_log2(T value) { Pre-existing: It's a mistake that this function's return type is T. It should be int, like all the other log2 variants in this file. Maybe it should be near those. src/hotspot/share/utilities/powerOfTwo.hpp line 126: > 124: template ::value)> > 125: inline T ceil_log2(T value) { > 126: assert(value > 0, "Invalid value"); This assert doesn't help when T is an unsigned type. ------------- PR Review: https://git.openjdk.org/jdk/pull/22074#pullrequestreview-2435354618 PR Review Comment: https://git.openjdk.org/jdk/pull/22074#discussion_r1841765688 PR Review Comment: https://git.openjdk.org/jdk/pull/22074#discussion_r1841763247 From stuefe at openjdk.org Thu Nov 14 09:21:22 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 14 Nov 2024 09:21:22 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v3] In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 08:30:49 GMT, Kim Barrett wrote: >> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: >> >> Starting ret at 0 > > src/hotspot/share/utilities/powerOfTwo.hpp line 125: > >> 123: // Find log2 value greater than this input >> 124: template ::value)> >> 125: inline T ceil_log2(T value) { > > Pre-existing: It's a mistake that this function's return type is T. It should be int, like all the other log2 > variants in this file. Maybe it should be near those. I agree, see JBS text ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22074#discussion_r1841837930 From cnorrbin at openjdk.org Thu Nov 14 10:00:35 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 14 Nov 2024 10:00:35 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v12] In-Reply-To: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: > Hi everyone, > > String interning can be done on 4 different types of strings: > - oop-strings (unicode) > - oop-strings (latin1) > - Symbols (non-null-terminated utf8) > - null-terminated utf8 char arrays > > Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table. > > This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation. > > This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations. > > Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build) > > 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types. > Also tested and passes tiers 1-3. Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: changed to const references ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21325/files - new: https://git.openjdk.org/jdk/pull/21325/files/a798d2b3..1219ec63 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21325&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21325&range=10-11 Stats: 19 lines in 2 files changed: 0 ins; 0 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/21325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21325/head:pull/21325 PR: https://git.openjdk.org/jdk/pull/21325 From cnorrbin at openjdk.org Thu Nov 14 10:00:37 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 14 Nov 2024 10:00:37 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v11] In-Reply-To: References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: On Wed, 13 Nov 2024 16:29:09 GMT, Coleen Phillimore wrote: >> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: >> >> removed whitespace > > src/hotspot/share/classfile/stringTable.hpp line 69: > >> 67: static unsigned int hash_wrapped_string(StringWrapper& wrapped_str); >> 68: static const jchar* to_unicode(StringWrapper& wrapped_str, int &len, TRAPS); >> 69: static Handle handle_from_wrapped_string(StringWrapper& wrapped_str, TRAPS); > > One last thing, should the be const references? You're right, fixed now! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21325#discussion_r1841903339 From shade at openjdk.org Thu Nov 14 10:43:15 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 14 Nov 2024 10:43:15 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Wed, 13 Nov 2024 23:07:02 GMT, William Kemper wrote: >> test/hotspot/jtreg/gc/shenandoah/oom/TestThreadFailure.java line 61: >> >>> 59: // case that the previously instantiated NastyThread accumulated more than SheanndoahNoProgressThreshold >>> 60: // unproductive GC cycles before failing, the main thread may not try a Full GC before it experiences >>> 61: // OutOfMemoryError exception. >> >> Do you really need comments in this test? > > This test was a sore spot for us and we spent quite some time to make it pass. I don't think the code is very clear on its face about what the test expects, so I'd prefer to keep this comment. OK, fine! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841996383 From coleenp at openjdk.org Thu Nov 14 11:49:15 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 11:49:15 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v12] In-Reply-To: References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: On Thu, 14 Nov 2024 10:00:35 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> String interning can be done on 4 different types of strings: >> - oop-strings (unicode) >> - oop-strings (latin1) >> - Symbols (non-null-terminated utf8) >> - null-terminated utf8 char arrays >> >> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table. >> >> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation. >> >> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations. >> >> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build) >> >> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types. >> Also tested and passes tiers 1-3. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > changed to const references Nice work! ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21325#pullrequestreview-2435860436 From adinn at openjdk.org Thu Nov 14 11:59:31 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 14 Nov 2024 11:59:31 GMT Subject: RFR: 8343699: [aarch64] Bug in MacroAssembler::klass_decode_mode() In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 15:34:49 GMT, Thomas Stuefe wrote: > In `MacroAssembler::klass_decode_mode(),` there is a subtle bug in the xor part. > > > if (operand_valid_for_logical_immediate( > /*is32*/false, (uint64_t)CompressedKlassPointers::base())) { > (1) const size_t range = CompressedKlassPointers::klass_range_end() - CompressedKlassPointers::base(); > (2) const uint64_t range_mask = (1ULL << log2i(range)) - 1; > (3) if (((uint64_t)CompressedKlassPointers::base() & range_mask) == 0) { > log_debug(metaspace)("MacroAssembler::klass_decode_mode xor"); > return (_klass_decode_mode = KlassDecodeXor); > } > } > > > We first determine if the encoding base is encodable as immediate. If it is, then we check if it intersects with the value range of a narrow Klass ID. > > (Note: the code ignores encoding shift since the XOR will be applied to the pre-shifted narrow Klass value later.) > > The test is done by > 1) calculating the range the encoding needs to cover > 2) calculating a corresponding bit mask > 3) checking that this mask does not intersect with the encoding base. > > (2) contains a wrongness: `range_mask = (1ULL << log2i(range)) - 1` . `log2i` returns the largest log2 value *smaller* or equal to input. So, for `range` values that are not a pow2 value, the resulting mask will be one bit too short. As an effect, the code may chose XOR for cases where the lowest encoding base bit can intersect the highest narrow Klass ID bit, thus making the xor lossy. > > ---- > > Example: > > Let range be 80MB (`-XX:CompressedClassSpaceSize=80m -Xshare:off`). > > Then, range_mask = `1 << log2i(80m) - 1` => `(1 << 26) - 1` => `0x3ff_ffff` > The largest possible nKlass value, however, sits just below 80MB => `0x500_0000`. As we see, the mask does not cover the full extent of the narrow Klass ID value range (bit 26 is not covered). > Hence, if we have a base with bit 26 set, its bit 26 intersects a possible bit 26 in high-value narrow Klass ID. The xor would not be lossless. > > ---- > > The error is very unlikely because > - we try to reserve the klass range at addresses that are guaranteed not to intersect with the narrow Klass range. Only if that fails - very unlikely - we use whatever address the OS gives us. Only then could we end up with such an address. > - The class space is rarely filled so high that the highest bit of a narrowKlass ID is `1`. > > ---- > > Reproduce: > > > java -XX:CompressedClassSpaceBaseAddress=0x1Fc000000 -XX:CompressedClassSpaceSize=80m -Xlog:metaspace* -Xshare:off > > > it does not reproduce an error, but causes the JVM to start in XOR mode with an enc... Yes, well caught! ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21932#pullrequestreview-2435881298 From jbechberger at openjdk.org Thu Nov 14 12:16:48 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 14 Nov 2024 12:16:48 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v22] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Improve Throttling test case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/9cafdbc8..207f221c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=20-21 Stats: 25 lines in 1 file changed: 8 ins; 5 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From coleenp at openjdk.org Thu Nov 14 12:26:58 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 12:26:58 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 11:42:11 GMT, Coleen Phillimore wrote: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. Thanks for looking through these changes. Thanks @AlanBateman for answering the question about remaining uses of protection domain. When we create an instance of java.lang.Class, the VM stores the protection domain given in resolve_from_stream. I may have already said this somewhere. So we need to pass it through that path. ------------- PR Review: https://git.openjdk.org/jdk/pull/22064#pullrequestreview-2435924412 From coleenp at openjdk.org Thu Nov 14 12:26:58 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 12:26:58 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 08:28:14 GMT, Alan Bateman wrote: > Do you plan a follow-up to purge the remaining refs to AccessController and AccessControlContext? I was unclear if they were still needed in the places they appear. Maybe I should do a follow-up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2476223492 From coleenp at openjdk.org Thu Nov 14 12:26:58 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 12:26:58 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 05:42:51 GMT, David Holmes wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > src/hotspot/share/ci/ciEnv.cpp line 1613: > >> 1611: >> 1612: // The very first entry is the InstanceKlass of the root method of the current compilation in order to get the right >> 1613: // (class loader???) protection domain to load subsequent classes during replay compilation. > > Suggestion: simply have: > > // The very first entry is the InstanceKlass of the root method of the current compilation . > > The rest of the comment doesn't really make sense even before your change as this method basically just prints the class name Thanks for noticing this. Updated comment that didn't make sense to me either. > src/hotspot/share/classfile/javaClasses.hpp line 1545: > >> 1543: static int _static_security_offset; >> 1544: static int _static_allow_security_offset; >> 1545: static int _static_never_offset; > > Guess these were missed by the main PR as they are unused. :) Yes, they are dead code. > src/hotspot/share/classfile/systemDictionary.hpp line 239: > >> 237: // compute java_mirror (java.lang.Class instance) for a type ("I", "[[B", "LFoo;", etc.) >> 238: // Either the accessing_klass or the CL can be non-null, but not both. >> 239: // callee will fill in CL from AK, if they are needed > > Suggestion: > > // Callee will fill in CL from accessing_klass, if they are needed. fixed. All these comments could use capitalization, but I won't do that here. > src/hotspot/share/logging/logTag.hpp line 163: > >> 161: LOG_TAG(preview) /* Trace loading of preview feature types */ \ >> 162: LOG_TAG(promotion) \ >> 163: LOG_TAG(protectiondomain) /* "Trace protection domain verification" */ \ > > Not 100% sure about this. We don't really have a policy for "deprecating" or removing log tags. I think it unlikely anyone enables this logging "just because", so it seems okay for this case. Given that I'm probably the only one that has ever used this tag (or maybe also Ioi), I think it's safe to remove. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1842123715 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1842124581 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1842126691 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1842127430 From coleenp at openjdk.org Thu Nov 14 12:42:02 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 12:42:02 GMT Subject: RFR: 8344032: InterpreterRuntime::verify_mdp() missing lock while printing MethodData on failure [v2] In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 19:53:04 GMT, Coleen Phillimore wrote: >> Added locking. I injected some MethodData printing with logging to test this to verify that there wasn't a lock ranking assert. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Use ConditionalMutexLocker instead. Thanks Thomas, David and Aleksey. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22082#issuecomment-2476251220 From coleenp at openjdk.org Thu Nov 14 12:42:02 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 12:42:02 GMT Subject: Integrated: 8344032: InterpreterRuntime::verify_mdp() missing lock while printing MethodData on failure In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 17:20:48 GMT, Coleen Phillimore wrote: > Added locking. I injected some MethodData printing with logging to test this to verify that there wasn't a lock ranking assert. > > Tested with tier1-4. This pull request has now been integrated. Changeset: 8ccc48c9 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/8ccc48c9c899192524c6095db31c856260d57176 Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod 8344032: InterpreterRuntime::verify_mdp() missing lock while printing MethodData on failure Reviewed-by: shade, dholmes, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/22082 From mbaesken at openjdk.org Thu Nov 14 12:53:03 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 14 Nov 2024 12:53:03 GMT Subject: RFR: 8342893: Highlight special values in hserr file printing [v4] In-Reply-To: References: Message-ID: > There are some special values indicating memory corruption or problematic states. Those should be highlighted / pointed out in some way when printing parts of the hserr / hsinfo file (like register values or locations), Matthias Baesken 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 remote-tracking branch 'origin/master' into JDK-8342893 - Introduce badResourceValueWord variable - compile error on Linux x86 and arm 32bit - do checks in debug - JDK-8342893 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21811/files - new: https://git.openjdk.org/jdk/pull/21811/files/1336334c..bf772fca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21811&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21811&range=02-03 Stats: 163422 lines in 1663 files changed: 125590 ins; 14639 del; 23193 mod Patch: https://git.openjdk.org/jdk/pull/21811.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21811/head:pull/21811 PR: https://git.openjdk.org/jdk/pull/21811 From coleenp at openjdk.org Thu Nov 14 13:02:22 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 13:02:22 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v2] In-Reply-To: References: Message-ID: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: - More purging of AccessController, AccessControlContext and some stackwalking questions. - David comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22064/files - new: https://git.openjdk.org/jdk/pull/22064/files/c7b5fd13..79831e0d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=00-01 Stats: 79 lines in 8 files changed: 3 ins; 73 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22064/head:pull/22064 PR: https://git.openjdk.org/jdk/pull/22064 From mbaesken at openjdk.org Thu Nov 14 13:07:40 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 14 Nov 2024 13:07:40 GMT Subject: RFR: 8342893: Highlight special values in hserr file printing [v5] In-Reply-To: References: Message-ID: > There are some special values indicating memory corruption or problematic states. Those should be highlighted / pointed out in some way when printing parts of the hserr / hsinfo file (like register values or locations), Matthias Baesken has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge master - Merge remote-tracking branch 'origin/master' into JDK-8342893 - Introduce badResourceValueWord variable - compile error on Linux x86 and arm 32bit - do checks in debug - JDK-8342893 ------------- Changes: https://git.openjdk.org/jdk/pull/21811/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21811&range=04 Stats: 224 lines in 10 files changed: 60 ins; 69 del; 95 mod Patch: https://git.openjdk.org/jdk/pull/21811.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21811/head:pull/21811 PR: https://git.openjdk.org/jdk/pull/21811 From coleenp at openjdk.org Thu Nov 14 13:11:13 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 13:11:13 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 08:28:14 GMT, Alan Bateman wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > @coleenp Do you plan a follow-up to purge the remaining refs to AccessController and AccessControlContext? @AlanBateman there was that AccessControlContext in the stack that I asked about in the main review that I can't find the answer to. Is it obsolete now? See the change for where I asked this question. Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2476311805 From coleenp at openjdk.org Thu Nov 14 13:11:14 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 13:11:14 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v2] In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 13:02:22 GMT, Coleen Phillimore wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: > > - More purging of AccessController, AccessControlContext and some stackwalking questions. > - David comments. hotspot/share/include/jvm.h:JVM_GetClassContext(JNIEnv *env); I think this is obsolete too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2476314927 From alanb at openjdk.org Thu Nov 14 13:23:29 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 14 Nov 2024 13:23:29 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v2] In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 13:07:55 GMT, Coleen Phillimore wrote: > hotspot/share/include/jvm.h:JVM_GetClassContext(JNIEnv *env); > > I think this is obsolete too. As part of the JEP 486 work, I changed SecurityManager::getClassContext to use StackWalker, the native method that called into JVM_GetClassContext is removed. So more cleanup here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2476341813 From alanb at openjdk.org Thu Nov 14 13:27:18 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 14 Nov 2024 13:27:18 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v2] In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 13:20:23 GMT, Alan Bateman wrote: >> hotspot/share/include/jvm.h:JVM_GetClassContext(JNIEnv *env); >> >> I think this is obsolete too. > >> hotspot/share/include/jvm.h:JVM_GetClassContext(JNIEnv *env); >> >> I think this is obsolete too. > > As part of the JEP 486 work, I changed SecurityManager::getClassContext to use StackWalker, the native method that called into JVM_GetClassContext is removed. So more cleanup here. > @AlanBateman there was that AccessControlContext in the stack that I asked about in the main review that I can't find the answer to. Is it obsolete now? See the change for where I asked this question. Thank you! The stack walk that stopped when it found a privileged frame is removed. I can't think of any scenario now where the VM will be interested in the AccessControlContext. Also AccessController is re-implemented to just invoke the actions so there should be no reason for the VM to know about AccessController either. Note that we need to keep JVM_EnsureMaterializedForStackWalk as that is needed for ScopedValue when recovering from SOE. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2476351280 From coleenp at openjdk.org Thu Nov 14 13:40:22 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 13:40:22 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v3] In-Reply-To: References: Message-ID: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Found more obsolete security manager code. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22064/files - new: https://git.openjdk.org/jdk/pull/22064/files/79831e0d..11337a0e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=01-02 Stats: 50 lines in 4 files changed: 0 ins; 49 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22064/head:pull/22064 PR: https://git.openjdk.org/jdk/pull/22064 From mgronlun at openjdk.org Thu Nov 14 13:53:19 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 14 Nov 2024 13:53:19 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v4] In-Reply-To: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: > Greetings, > > This enhancement adds register printouts on asserts or guarantees into the hs_err_pid.log error reporting files for Windows. > > Additionally, it saves an accurate EXCEPTION_RECORD into the hs_err_pid.mdmp file, also for asserts or guarantees, so the assertion context is now easily accessible in Windbg using .ecxr. > > For more details on this enhancement, please see the JIRA issue. > > Testing: Tier 1,2,3, jdk_jfr > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: extended test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21994/files - new: https://git.openjdk.org/jdk/pull/21994/files/1d37eb48..8f0b34b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21994&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21994&range=02-03 Stats: 14 lines in 1 file changed: 14 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21994.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21994/head:pull/21994 PR: https://git.openjdk.org/jdk/pull/21994 From mgronlun at openjdk.org Thu Nov 14 13:53:20 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 14 Nov 2024 13:53:20 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v3] In-Reply-To: References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: On Thu, 14 Nov 2024 07:06:19 GMT, Thomas Stuefe wrote: > Looks good. > > Would it be possible for you to extend the test a bit, at least for x64, to test for registers to have appeared? E.g. RIP or RAX. Yes, please take a look. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21994#issuecomment-2476404724 From coleenp at openjdk.org Thu Nov 14 14:03:50 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 14:03:50 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v4] In-Reply-To: References: Message-ID: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: More obsolete code. Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS). ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22064/files - new: https://git.openjdk.org/jdk/pull/22064/files/11337a0e..ca34fc5b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=02-03 Stats: 23 lines in 3 files changed: 0 ins; 18 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/22064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22064/head:pull/22064 PR: https://git.openjdk.org/jdk/pull/22064 From coleenp at openjdk.org Thu Nov 14 14:03:50 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 14:03:50 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v3] In-Reply-To: References: Message-ID: <_S0DqGV0FJQFKuv9ynZDQZOfMLy8Ab6vE0mlwuKSLmw=.44646b28-d183-4209-8e2e-55afd28bf024@github.com> On Thu, 14 Nov 2024 13:40:22 GMT, Coleen Phillimore wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Found more obsolete security manager code. The stack walk ignoring AccessControlContext was in some logging code, so now removed. Also, I saw that getClassContext was rewritten, so removed that bit too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2476430158 From jbechberger at openjdk.org Thu Nov 14 14:40:58 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 14 Nov 2024 14:40:58 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v23] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Obtain minimal period via the CONFIG_HZ parameter of the kernel ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/207f221c..6bc66b9c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=21-22 Stats: 60 lines in 1 file changed: 59 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From alanb at openjdk.org Thu Nov 14 14:45:29 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 14 Nov 2024 14:45:29 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v4] In-Reply-To: References: Message-ID: <2sSkqM0XA_sKandGlnJJDEjBzCSQuaOj4UTHQVEbBII=.6a6ea3c3-2c01-447f-8cbf-cc70dbc6df04@github.com> On Thu, 14 Nov 2024 14:03:50 GMT, Coleen Phillimore wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > More obsolete code. Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS). I see a few left over refs to SecurityManager in vmSymbols.hpp, vmClassMacros.hpp, and a comment in logDiagnosticCommand.hpp. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2476531284 From jbechberger at openjdk.org Thu Nov 14 14:45:38 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 14 Nov 2024 14:45:38 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v23] In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 14:40:58 GMT, Johannes Bechberger wrote: >> This is the code for the [JEP draft: CPU Time based profiling for JFR]. > > Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: > > Obtain minimal period via the CONFIG_HZ parameter of the kernel The user provided interval is not compared with the minimal possible interval with stems from the kernels `CONFIG_HZ` property. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2476529452 From fjiang at openjdk.org Thu Nov 14 15:03:02 2024 From: fjiang at openjdk.org (Feilong Jiang) Date: Thu, 14 Nov 2024 15:03:02 GMT Subject: RFR: 8344169: RISC-V: Use more meaningful frame::metadata_words where possible In-Reply-To: <9XNv_0zgwAVjUaUjVSxFFkwvzUFp3f2Lu8MvPyFv8l8=.d6d9457a-e737-4169-a198-7ea88cfde0db@github.com> References: <9XNv_0zgwAVjUaUjVSxFFkwvzUFp3f2Lu8MvPyFv8l8=.d6d9457a-e737-4169-a198-7ea88cfde0db@github.com> Message-ID: On Thu, 14 Nov 2024 07:00:55 GMT, Fei Yang wrote: > Hello, please review this RISC-V specific change which improves code readability. > > Some background to help understand. We have following frame enumerations in file frame_riscv.hpp: > > enum { > link_offset = -2, > return_addr_offset = -1, > sender_sp_offset = 0 > }; > > The values are compatible with the platform ABI and are different from other platforms like x64 and aarch64. Especially, `sender_sp_offset` is 0 for RISC-V compared to 2 for x64 and aarch64. As a result, there exists some differences in places where code calculates fp through offseting pointer sp by value `sender_sp_offset`. For RISC-V, we used constant number 2 instead of `sender_sp_offset` as the pointer offset. But the code will be more readable if we use `frame::metadata_words` which has the same value. This change would not affect correctness or functionality in theory. > > Testing on linux-riscv64: > - [x] "hotspot_loom jdk_loom" (release & fastdebug) Marked as reviewed by fjiang (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22096#pullrequestreview-2436339140 From lucy at openjdk.org Thu Nov 14 15:54:24 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Thu, 14 Nov 2024 15:54:24 GMT Subject: RFR: 8327652: S390x: Implements SLP support [v12] In-Reply-To: References: Message-ID: On Mon, 14 Oct 2024 09:07:53 GMT, Sidraya Jayagond wrote: >> This PR Adds SIMD support on s390x. > > Sidraya Jayagond has updated the pull request incrementally with one additional commit since the last revision: > > Disable vector instructions from string intrinsics > > Address Lutz's comments. > Disable vector instructions from string intrinsics will be > enabled once PR to JDK-8336356 gets integrates. Looks good. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18162#pullrequestreview-2436478216 From coleenp at openjdk.org Thu Nov 14 16:02:56 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 16:02:56 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v5] In-Reply-To: References: Message-ID: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Purge last references to SecurityManager. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22064/files - new: https://git.openjdk.org/jdk/pull/22064/files/ca34fc5b..aee8efd3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=03-04 Stats: 4 lines in 3 files changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22064/head:pull/22064 PR: https://git.openjdk.org/jdk/pull/22064 From jbechberger at openjdk.org Thu Nov 14 16:41:52 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 14 Nov 2024 16:41:52 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v24] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Making queue processing only stoppable in debug builds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/6bc66b9c..2f462fe2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=22-23 Stats: 30 lines in 5 files changed: 24 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From coleenp at openjdk.org Thu Nov 14 17:02:33 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 17:02:33 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v4] In-Reply-To: <2sSkqM0XA_sKandGlnJJDEjBzCSQuaOj4UTHQVEbBII=.6a6ea3c3-2c01-447f-8cbf-cc70dbc6df04@github.com> References: <2sSkqM0XA_sKandGlnJJDEjBzCSQuaOj4UTHQVEbBII=.6a6ea3c3-2c01-447f-8cbf-cc70dbc6df04@github.com> Message-ID: On Thu, 14 Nov 2024 14:42:30 GMT, Alan Bateman wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> More obsolete code. Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS). > > I see a few left over refs to SecurityManager in vmSymbols.hpp, vmClassMacros.hpp, and a comment in logDiagnosticCommand.hpp. Thanks @AlanBateman There's a DCmd permissions() function that talks about DiagnosticCommandMBean security. I don't know what that is so I'm leaving it. Edit: appears unrelated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2476948391 From jbachorik at openjdk.org Thu Nov 14 17:42:38 2024 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Thu, 14 Nov 2024 17:42:38 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v21] In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 09:11:46 GMT, Johannes Bechberger wrote: >> src/hotspot/share/jfr/recorder/stacktrace/jfrAsyncStackTrace.cpp line 68: >> >>> 66: _reached_root = true; >>> 67: >>> 68: JfrVframeStream vfs(jt, frame, false, true, false); >> >> Does this mean we are not going to get frames from virtual threads/continuations? > > Only the ones that are currently on the stack, as far as I understand. > > But this change is required, as walking continuations in a signal causes crashes. Ok. This is benign then. Since the carrier thread is being executed the virtual thread frames (if any is mounted) will be on stack. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1842644581 From iklam at openjdk.org Thu Nov 14 18:07:16 2024 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 14 Nov 2024 18:07:16 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: <9odgI41Erhmy3c5sk7YgS_NR61BaYO933G0HwPHRJNw=.54e7cb3b-98bf-4ec8-94f7-8032b52eb773@github.com> Message-ID: On Thu, 14 Nov 2024 07:53:32 GMT, David Holmes wrote: > > > To be fair I'm unclear what role PD still plays on the JDK side and would not be surprised if it is destined for removal at some point. > > > > > > PD is not deprecated as PD::getCodeSource is widely used. It may be that an alternative means is introduced in the future to expose the code location but nothing specific at this time. > > Okay but I still remain unclear about the role of PD in the VM, in particular how CDS is using it. CDS just emulates what the Java code does -- to ensure that Class.getProtectionDomain() would get the same answer as if the class was loaded from bytecodes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2477083960 From shade at openjdk.org Thu Nov 14 19:34:14 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 14 Nov 2024 19:34:14 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Wed, 13 Nov 2024 23:17:44 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp line 50: >> >>> 48: switch (generation_type) { \ >>> 49: case NON_GEN: \ >>> 50: return prefix " (NON-GENERATIONAL)" postfix; \ >> >> In the interest of keeping the non-generational Shenandoah logging intact, should we drop ` (NON-GENERATIONAL)` here? > > No objections here. @ysramakrishna , @kdnilsen ? See, with current code, default Shenandoah prints this: [0.025s][info][gc] GC(0) Concurrent reset (NON-GENERATIONAL) (unload classes) 0.135ms [0.025s][info][gc] GC(0) Pause Init Mark (NON-GENERATIONAL) (unload classes) 0.018ms [0.025s][info][gc] GC(0) Concurrent marking roots 0.097ms [0.029s][info][gc] GC(0) Concurrent marking (NON-GENERATIONAL) (unload classes) 4.050ms [0.029s][info][gc] GC(0) Pause Final Mark (NON-GENERATIONAL) (unload classes) 0.123ms [0.029s][info][gc] GC(0) Concurrent thread roots 0.205ms [0.029s][info][gc] GC(0) Concurrent weak references (NON-GENERATIONAL) (unload classes) 0.014ms [0.029s][info][gc] GC(0) Concurrent weak roots (NON-GENERATIONAL) (unload classes) 0.047ms [0.029s][info][gc] GC(0) Concurrent cleanup (NON-GENERATIONAL) (unload classes) 40M->40M(2064M) 0.006ms [0.029s][info][gc] GC(0) Concurrent class unloading 0.035ms [0.029s][info][gc] GC(0) Concurrent strong roots 0.119ms This is not great: experimental GenShen should not affect the logging for current product code. There is a risk we would be breaking some GC parsers if we change it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1842764603 From shade at openjdk.org Thu Nov 14 19:34:15 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 14 Nov 2024 19:34:15 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Thu, 14 Nov 2024 19:12:25 GMT, Aleksey Shipilev wrote: >> No objections here. @ysramakrishna , @kdnilsen ? > > See, with current code, default Shenandoah prints this: > > > [0.025s][info][gc] GC(0) Concurrent reset (NON-GENERATIONAL) (unload classes) 0.135ms > [0.025s][info][gc] GC(0) Pause Init Mark (NON-GENERATIONAL) (unload classes) 0.018ms > [0.025s][info][gc] GC(0) Concurrent marking roots 0.097ms > [0.029s][info][gc] GC(0) Concurrent marking (NON-GENERATIONAL) (unload classes) 4.050ms > [0.029s][info][gc] GC(0) Pause Final Mark (NON-GENERATIONAL) (unload classes) 0.123ms > [0.029s][info][gc] GC(0) Concurrent thread roots 0.205ms > [0.029s][info][gc] GC(0) Concurrent weak references (NON-GENERATIONAL) (unload classes) 0.014ms > [0.029s][info][gc] GC(0) Concurrent weak roots (NON-GENERATIONAL) (unload classes) 0.047ms > [0.029s][info][gc] GC(0) Concurrent cleanup (NON-GENERATIONAL) (unload classes) 40M->40M(2064M) 0.006ms > [0.029s][info][gc] GC(0) Concurrent class unloading 0.035ms > [0.029s][info][gc] GC(0) Concurrent strong roots 0.119ms > > > This is not great: experimental GenShen should not affect the logging for current product code. There is a risk we would be breaking some GC parsers if we change it. While we are at it, we should probably replace `YOUNG` -> `Young`, etc, and figure out if `Transition from`, `Heuristics request`, and ` Periodic Sample:` should be in `gc=debug`, so logs are cleaner: [7.514s][info][gc] Transition from: normal to: idle [7.617s][info][gc] Trigger (YOUNG): Average GC time (123.52 ms) is above the time for average allocation rate (2868 MB/s) to deplete free headroom (350M) (margin of error = 1.79) [7.617s][info][gc] Transition from: idle to: normal [7.617s][info][gc] Heuristics request for young collection accepted [7.618s][info][gc] GC(31) Concurrent reset (YOUNG) 1.095ms [7.618s][info][gc] GC(31) Pause Init Mark (YOUNG) 0.026ms [7.618s][info][gc] GC(31) Concurrent remembered set scanning 0.148ms [7.618s][info][gc] GC(31) Concurrent marking roots 0.217ms [7.680s][info][gc] GC(31) Concurrent marking (YOUNG) 61.990ms [7.681s][info][gc] GC(31) Transfer 1 region(s) from OLD to YOUNG, yielding increased size: 1021M [7.681s][info][gc] GC(31) Transfer 1 region(s) from YOUNG to OLD, yielding increased size: 3584K [7.681s][info][gc] GC(31) Pause Final Mark (YOUNG) 0.246ms [7.681s][info][gc] GC(31) Concurrent thread roots 0.041ms [7.728s][info][gc] GC(31) Concurrent weak references (YOUNG) 47.278ms [7.728s][info][gc] GC(31) Concurrent weak roots (YOUNG) 0.114ms [7.728s][info][gc] GC(31) Concurrent cleanup (YOUNG) 674M->658M(1024M) 0.014ms [7.728s][info][gc] GC(31) Concurrent strong roots 0.217ms [7.730s][info][gc] GC(31) Concurrent evacuation 1.879ms [7.730s][info][gc] GC(31) Pause Init Update Refs 0.010ms [7.730s][info][gc] GC(31) Transfer 1 region(s) from OLD to YOUNG, yielding increased size: 1021M [7.739s][info][gc] GC(31) Concurrent update references 8.651ms [7.739s][info][gc] GC(31) Concurrent update thread roots 0.069ms [7.739s][info][gc] GC(31) Transfer 1 region(s) from YOUNG to OLD, yielding increased size: 3584K [7.739s][info][gc] GC(31) Pause Final Update Refs 0.076ms [7.739s][info][gc] GC(31) Concurrent cleanup (YOUNG) 690M->135M(1024M) 0.078ms ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1842769207 From shade at openjdk.org Thu Nov 14 19:34:13 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 14 Nov 2024 19:34:13 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: > > - Merge branch 'merge-latest' into great-genshen-pr-redux > - Use new CompactHeader forwarding APIs in generational mode > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge > - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines > > Reviewed-by: wkemper > - Merge > - 8343227: GenShen: Fold resource mark into management of preselected regions > > Reviewed-by: kdnilsen > - Merge openjdk/jdk tip into great-genshen-pr-redux > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge remote-tracking branch 'jdk/master' into merge-latest > - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 More reviews... src/hotspot/share/gc/shenandoah/shenandoahGenerationSizer.cpp line 141: > 139: dst->increase_capacity(bytes_to_transfer); > 140: const size_t new_size = dst->max_capacity(); > 141: log_info(gc)("Transfer " SIZE_FORMAT " region(s) from %s to %s, yielding increased size: " PROPERFMT, This should not be `log_info(gc)`. In fact, please look at other places where you print logging. Generally, `log_info(gc)` should provide _only_ the high-level GC info: which phases were running. Everything else should go under `log_debug(gc)`. src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp line 140: > 138: break; > 139: } > 140: case OLD: Are we not doing OLD STW mark? Deserves a comment. src/hotspot/share/gc/shenandoah/shenandoahYoungGeneration.hpp line 54: > 52: void parallel_heap_region_iterate(ShenandoahHeapRegionClosure* cl) override; > 53: > 54: void parallel_region_iterate_free(ShenandoahHeapRegionClosure* cl) override; Is this a sibling of `parallel_heap_region_iterate`? Shouldn't these be called `parallel_heap_region_iterate_free`? ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2436882261 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1842779639 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1842701030 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1842704295 From mark.reinhold at oracle.com Thu Nov 14 21:27:42 2024 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Thu, 14 Nov 2024 21:27:42 +0000 Subject: New candidate JEP: 501: Deprecate the 32-bit x86 Port for Removal Message-ID: <20241114212740.7F702781BE5@eggemoggin.niobe.net> https://openjdk.org/jeps/501 Summary: Deprecate the 32-bit x86 port, with the intent to remove it in a future release. This will thereby deprecate the Linux 32-bit x86 port, which is the only 32-bit x86 port remaining in the JDK. It will also, effectively, deprecate any remaining downstream 32-bit x86 ports. After the 32-bit x86 port is removed, the architecture-agnostic Zero port will be the only way to run Java programs on 32-bit x86 processors. - Mark From dholmes at openjdk.org Thu Nov 14 21:36:14 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Nov 2024 21:36:14 GMT Subject: RFR: 8344250: Obsolete the DontYieldALot flag Message-ID: Please review this simple fix to remove all code related to the deprecated `DontYieldALot` flag, which is obsoleted in JDK 24. Testing - GHA (in progress) - tiers 1-3 (in progress) Thanks ------------- Commit messages: - 8344250: Obsolete the DontYieldALot flag Changes: https://git.openjdk.org/jdk/pull/22120/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22120&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344250 Stats: 44 lines in 18 files changed: 0 ins; 32 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/22120.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22120/head:pull/22120 PR: https://git.openjdk.org/jdk/pull/22120 From darcy at openjdk.org Thu Nov 14 21:36:14 2024 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 14 Nov 2024 21:36:14 GMT Subject: RFR: 8344250: Obsolete the DontYieldALot flag In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 21:28:19 GMT, David Holmes wrote: > Please review this simple fix to remove all code related to the deprecated `DontYieldALot` flag, which is obsoleted in JDK 24. > > Testing > - GHA (in progress) > - tiers 1-3 (in progress) > > Thanks Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22120#pullrequestreview-2437240786 From matsaave at openjdk.org Thu Nov 14 21:54:19 2024 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 14 Nov 2024 21:54:19 GMT Subject: RFR: 8344250: Obsolete the DontYieldALot flag In-Reply-To: References: Message-ID: <8ZuR_yhUQualdCGhyKMCDgEoC2vubwlgiNb5pB2GVCc=.3d95bec3-06c2-4dda-9b3f-cff71919fb0c@github.com> On Thu, 14 Nov 2024 21:28:19 GMT, David Holmes wrote: > Please review this simple fix to remove all code related to the deprecated `DontYieldALot` flag, which is obsoleted in JDK 24. > > Testing > - GHA (in progress) > - tiers 1-3 (in progress) > > Thanks Looks good, thanks! ------------- Marked as reviewed by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22120#pullrequestreview-2437269115 From iklam at openjdk.org Thu Nov 14 21:54:20 2024 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 14 Nov 2024 21:54:20 GMT Subject: RFR: 8344250: Obsolete the DontYieldALot flag In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 21:28:19 GMT, David Holmes wrote: > Please review this simple fix to remove all code related to the deprecated `DontYieldALot` flag, which is obsoleted in JDK 24. > > Testing > - GHA (in progress) > - tiers 1-3 (in progress) > > Thanks LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22120#pullrequestreview-2437270895 From dholmes at openjdk.org Thu Nov 14 21:57:55 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Nov 2024 21:57:55 GMT Subject: RFR: 8344250: Obsolete the DontYieldALot flag In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 21:31:52 GMT, Joe Darcy wrote: >> Please review this simple fix to remove all code related to the deprecated `DontYieldALot` flag, which is obsoleted in JDK 24. >> >> Testing >> - GHA (in progress) >> - tiers 1-3 (in progress) >> >> Thanks > > Marked as reviewed by darcy (Reviewer). Thanks for the reviews @jddarcy , @matias9927 and @iklam !' Just waiting for testing to complete ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/22120#issuecomment-2477483765 From dholmes at openjdk.org Thu Nov 14 22:26:21 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Nov 2024 22:26:21 GMT Subject: Integrated: 8344250: Obsolete the DontYieldALot flag In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 21:28:19 GMT, David Holmes wrote: > Please review this simple fix to remove all code related to the deprecated `DontYieldALot` flag, which is obsoleted in JDK 24. > > Testing > - GHA (in progress) > - tiers 1-3 (in progress) > > Thanks This pull request has now been integrated. Changeset: db56266a Author: David Holmes URL: https://git.openjdk.org/jdk/commit/db56266ad164b4ecae59451dc0a832097dbfbd8e Stats: 44 lines in 18 files changed: 0 ins; 32 del; 12 mod 8344250: Obsolete the DontYieldALot flag Reviewed-by: darcy, matsaave, iklam ------------- PR: https://git.openjdk.org/jdk/pull/22120 From pchilanomate at openjdk.org Thu Nov 14 22:51:18 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 14 Nov 2024 22:51:18 GMT Subject: RFR: 8344247: Move objectWaiter field to VirtualThread instance Message-ID: Small follow-up change after JDK-8338383. This moves the `objectWaiter` field from the stackChunk to the VirtualThread instance. Only the top stackChunk uses this field so we could save some memory by just saving it in the virtual thread instance instead. Also, related methods `stackChunkOopDesc::current_pending_monitor` and `stackChunkOopDesc::current_waiting_monitor` are moved to the `java_lang_VirtualThread` class where they naturally belong, since these are the equivalent of the JavaThread methods but for an unmounted vthread. Tested by running mach5 tiers1-3. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.org/jdk/pull/22124/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22124&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344247 Stats: 115 lines in 12 files changed: 39 ins; 62 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/22124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22124/head:pull/22124 PR: https://git.openjdk.org/jdk/pull/22124 From davidalayachew at gmail.com Thu Nov 14 23:18:35 2024 From: davidalayachew at gmail.com (David Alayachew) Date: Thu, 14 Nov 2024 18:18:35 -0500 Subject: New candidate JEP: 501: Deprecate the 32-bit x86 Port for Removal In-Reply-To: <20241114212740.7F702781BE5@eggemoggin.niobe.net> References: <20241114212740.7F702781BE5@eggemoggin.niobe.net> Message-ID: That Zero port appears to be a very fair compromise, ty for doing this. Where can I go to learn more about it? The link on the left hand side only links to a mailing list and a blog. On Thu, Nov 14, 2024, 4:28?PM Mark Reinhold wrote: > https://openjdk.org/jeps/501 > > Summary: Deprecate the 32-bit x86 port, with the intent to remove it > in a future release. This will thereby deprecate the Linux 32-bit x86 > port, which is the only 32-bit x86 port remaining in the JDK. It will > also, effectively, deprecate any remaining downstream 32-bit x86 ports. > After the 32-bit x86 port is removed, the architecture-agnostic > Zero port will be the only way to run Java programs on 32-bit x86 > processors. > > - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Thu Nov 14 23:27:17 2024 From: davidalayachew at gmail.com (David Alayachew) Date: Thu, 14 Nov 2024 18:27:17 -0500 Subject: New candidate JEP: 501: Deprecate the 32-bit x86 Port for Removal In-Reply-To: References: <20241114212740.7F702781BE5@eggemoggin.niobe.net> Message-ID: Or where to download and test it out for that matter. Also, the FAQ link is dead. On Thu, Nov 14, 2024, 6:18?PM David Alayachew wrote: > That Zero port appears to be a very fair compromise, ty for doing this. > > Where can I go to learn more about it? The link on the left hand side only > links to a mailing list and a blog. > > On Thu, Nov 14, 2024, 4:28?PM Mark Reinhold > wrote: > >> https://openjdk.org/jeps/501 >> >> Summary: Deprecate the 32-bit x86 port, with the intent to remove it >> in a future release. This will thereby deprecate the Linux 32-bit x86 >> port, which is the only 32-bit x86 port remaining in the JDK. It will >> also, effectively, deprecate any remaining downstream 32-bit x86 ports. >> After the 32-bit x86 port is removed, the architecture-agnostic >> Zero port will be the only way to run Java programs on 32-bit x86 >> processors. >> >> - Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdoerr at openjdk.org Thu Nov 14 23:43:50 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 14 Nov 2024 23:43:50 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: <2m-YJkwNcpIEDdVElZOw2uqbTD6eOoBM0cRGoSFdADM=.86118c91-b8dd-4da9-b691-5ffe0643f51d@github.com> On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: > > - Merge branch 'merge-latest' into great-genshen-pr-redux > - Use new CompactHeader forwarding APIs in generational mode > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge > - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines > > Reviewed-by: wkemper > - Merge > - 8343227: GenShen: Fold resource mark into management of preselected regions > > Reviewed-by: kdnilsen > - Merge openjdk/jdk tip into great-genshen-pr-redux > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge remote-tracking branch 'jdk/master' into merge-latest > - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 The new test TestAllocOutOfMemory.java#large failed on some PPC64 machines: Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main" java.lang.RuntimeException: 'java.lang.OutOfMemoryError: Java heap space' missing from stdout/stderr Probably not a show-stopper. Should the test be adapted or disabled for this platform? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2477628609 From wkemper at openjdk.org Fri Nov 15 00:15:59 2024 From: wkemper at openjdk.org (William Kemper) Date: Fri, 15 Nov 2024 00:15:59 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: <2m-YJkwNcpIEDdVElZOw2uqbTD6eOoBM0cRGoSFdADM=.86118c91-b8dd-4da9-b691-5ffe0643f51d@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <2m-YJkwNcpIEDdVElZOw2uqbTD6eOoBM0cRGoSFdADM=.86118c91-b8dd-4da9-b691-5ffe0643f51d@github.com> Message-ID: On Thu, 14 Nov 2024 23:39:08 GMT, Martin Doerr wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > The new test TestAllocOutOfMemory.java#large failed on some PPC64 machines: > > Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main" > > java.lang.RuntimeException: 'java.lang.OutOfMemoryError: Java heap space' missing from stdout/stderr > > Probably not a show-stopper. Should the test be adapted or disabled for this platform? @TheRealMDoerr - do you have the logs from the test failure? If so, could you open a ticket with them in JBS? Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2477671400 From wkemper at openjdk.org Fri Nov 15 01:27:59 2024 From: wkemper at openjdk.org (William Kemper) Date: Fri, 15 Nov 2024 01:27:59 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Thu, 14 Nov 2024 19:26:12 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahGenerationSizer.cpp line 141: > >> 139: dst->increase_capacity(bytes_to_transfer); >> 140: const size_t new_size = dst->max_capacity(); >> 141: log_info(gc)("Transfer " SIZE_FORMAT " region(s) from %s to %s, yielding increased size: " PROPERFMT, > > This should not be `log_info(gc)`. In fact, please look at other places where you print logging. Generally, `log_info(gc)` should provide _only_ the high-level GC info: which phases were running. Everything else should go under `log_debug(gc)`. https://bugs.openjdk.org/browse/JDK-8344263 > src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp line 140: > >> 138: break; >> 139: } >> 140: case OLD: > > Are we not doing OLD STW mark? Deserves a comment. https://bugs.openjdk.org/browse/JDK-8344264 > src/hotspot/share/gc/shenandoah/shenandoahYoungGeneration.hpp line 54: > >> 52: void parallel_heap_region_iterate(ShenandoahHeapRegionClosure* cl) override; >> 53: >> 54: void parallel_region_iterate_free(ShenandoahHeapRegionClosure* cl) override; > > Is this a sibling of `parallel_heap_region_iterate`? Shouldn't these be called `parallel_heap_region_iterate_free`? https://bugs.openjdk.org/browse/JDK-8344264 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843073877 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843075157 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843075212 From wkemper at openjdk.org Fri Nov 15 01:28:00 2024 From: wkemper at openjdk.org (William Kemper) Date: Fri, 15 Nov 2024 01:28:00 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: <9UFMM5ji_G1XTowN-oY6n3JS5Enw_IFv9x8JShC1yhQ=.26f05071-7945-4268-8932-3486c319c139@github.com> On Thu, 14 Nov 2024 19:16:30 GMT, Aleksey Shipilev wrote: >> See, with current code, default Shenandoah prints this: >> >> >> [0.025s][info][gc] GC(0) Concurrent reset (NON-GENERATIONAL) (unload classes) 0.135ms >> [0.025s][info][gc] GC(0) Pause Init Mark (NON-GENERATIONAL) (unload classes) 0.018ms >> [0.025s][info][gc] GC(0) Concurrent marking roots 0.097ms >> [0.029s][info][gc] GC(0) Concurrent marking (NON-GENERATIONAL) (unload classes) 4.050ms >> [0.029s][info][gc] GC(0) Pause Final Mark (NON-GENERATIONAL) (unload classes) 0.123ms >> [0.029s][info][gc] GC(0) Concurrent thread roots 0.205ms >> [0.029s][info][gc] GC(0) Concurrent weak references (NON-GENERATIONAL) (unload classes) 0.014ms >> [0.029s][info][gc] GC(0) Concurrent weak roots (NON-GENERATIONAL) (unload classes) 0.047ms >> [0.029s][info][gc] GC(0) Concurrent cleanup (NON-GENERATIONAL) (unload classes) 40M->40M(2064M) 0.006ms >> [0.029s][info][gc] GC(0) Concurrent class unloading 0.035ms >> [0.029s][info][gc] GC(0) Concurrent strong roots 0.119ms >> >> >> This is not great: experimental GenShen should not affect the logging for current product code. There is a risk we would be breaking some GC parsers if we change it. > > While we are at it, we should probably replace `YOUNG` -> `Young`, etc, and figure out if `Transition from`, `Heuristics request`, and ` Periodic Sample:` should be in `gc=debug`, so logs are cleaner: > > > [7.514s][info][gc] Transition from: normal to: idle > [7.617s][info][gc] Trigger (YOUNG): Average GC time (123.52 ms) is above the time for average allocation rate (2868 MB/s) to deplete free headroom (350M) (margin of error = 1.79) > [7.617s][info][gc] Transition from: idle to: normal > [7.617s][info][gc] Heuristics request for young collection accepted > [7.618s][info][gc] GC(31) Concurrent reset (YOUNG) 1.095ms > [7.618s][info][gc] GC(31) Pause Init Mark (YOUNG) 0.026ms > [7.618s][info][gc] GC(31) Concurrent remembered set scanning 0.148ms > [7.618s][info][gc] GC(31) Concurrent marking roots 0.217ms > [7.680s][info][gc] GC(31) Concurrent marking (YOUNG) 61.990ms > [7.681s][info][gc] GC(31) Transfer 1 region(s) from OLD to YOUNG, yielding increased size: 1021M > [7.681s][info][gc] GC(31) Transfer 1 region(s) from YOUNG to OLD, yielding increased size: 3584K > [7.681s][info][gc] GC(31) Pause Final Mark (YOUNG) 0.246ms > [7.681s][info][gc] GC(31) Concurrent thread roots 0.041ms > [7.728s][info][gc] GC(31) Concurrent weak references (YOUNG) 47.278ms > [7.728s][info][gc] GC(31) Concurrent weak roots (YOUNG) 0.114ms > [7.728s][info][gc] GC(31) Concurrent cleanup (YOUNG) 674M->658M(1024M) 0.014ms > [7.728s][info][gc] GC(31) Concurrent strong roots 0.217ms > [7.730s][info][gc] GC(31) Concurrent evacuation 1.879ms > [7.730s][info][gc] GC(31) Pause Init Update Refs 0.010ms > [7.730s][info][gc] GC(31) Transfer 1 region(s) from OLD to YOUNG, yielding increased size: 1021M > [7.739s][info][gc] GC(31) Concurrent update references 8.651ms > [7.739s][info][gc] GC(31) Concurrent update thread roots 0.069ms > [7.739s][info][gc] GC(31) Transfer 1 region(s) from YOUNG to OLD, yielding increased size: 3584K > [7.739s][info][gc] GC(31) Pause Final Update Refs 0.076ms > [7.739s][info][gc] GC(31) Concurrent cleanup (YOUNG) 690M->135M(1024M) 0.078ms https://bugs.openjdk.org/browse/JDK-8344263 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843074126 From dholmes at openjdk.org Fri Nov 15 01:46:44 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 15 Nov 2024 01:46:44 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v12] In-Reply-To: References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: On Thu, 14 Nov 2024 10:00:35 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> String interning can be done on 4 different types of strings: >> - oop-strings (unicode) >> - oop-strings (latin1) >> - Symbols (non-null-terminated utf8) >> - null-terminated utf8 char arrays >> >> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table. >> >> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation. >> >> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations. >> >> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build) >> >> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types. >> Also tested and passes tiers 1-3. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > changed to const references Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21325#pullrequestreview-2437507656 From alexey.menkov at oracle.com Fri Nov 15 02:10:59 2024 From: alexey.menkov at oracle.com (Alexey Menkov) Date: Fri, 15 Nov 2024 02:10:59 +0000 Subject: Win32AttachOperationRequest seems to be using global new? In-Reply-To: References: <8ec38c62-69d5-4821-b160-0148c41581ea@oracle.com> Message-ID: <1eae0151-9904-49f2-b595-3d7e9d5b5964@oracle.com> Sorry, didn't noticed the message before. Yes, this is oversight. Filed https://bugs.openjdk.org/browse/JDK-8344262 Thank you for the finding Julian. --alex On 14.11.2024 0:28, David Holmes wrote: > That didn't work so cc'ing serviceability-dev > > I think it was just an oversight. > > David > > > On 14/11/2024 6:24 pm, David Holmes wrote: >> It was added by JDK-8339289 so cc'ing Alex. >> >> David >> >> On 14/11/2024 5:33 pm, Julian Waters wrote: >>> Bumping, I'm still curious about this issue >>> >>> best regards, >>> Julian >>> >>> On Tue, Nov 12, 2024 at 10:20?PM Julian Waters >>> wrote: >>>> Hi all, >>>> >>>> Win32AttachOperationRequest is created via new, but doesn't specify >>>> a custom new inside the class definition. The result seems to be >>>> that we use global new on Windows: >>>> >>>> ?? for (int i=0; i>>> ???? Win32AttachOperationRequest* op = new >>>> Win32AttachOperationRequest(); >>>> ?????? f1: b9 28 0d 00 00?????? mov??? ecx,0xd28 >>>> ?????? f6: e8 00 00 00 00?????? call?? fb >>>> >>>> f7: IMAGE_REL_AMD64_REL32 operator new(unsigned long long) >>>> >>>> Stepping away from gcc's objdump and using the Microsoft dumpbin >>>> alongside cl.exe instead, the result is this: >>>> >>>> ?? 0000000000000264: B9 28 0D 00 00???? mov???????? ecx,0D28h >>>> ?? 0000000000000269: E8 00 00 00 00???? call??????? ??2 at YAPEAX_K@Z >>>> ?? 000000000000026E: 48 89 44 24 28???? mov???????? qword ptr >>>> [rsp+28h],rax >>>> ?? 0000000000000273: 48 83 7C 24 28 00? cmp???????? qword ptr >>>> [rsp+28h],0 >>>> ?? 0000000000000279: 74 11????????????? je????????? 000000000000028C >>>> ?? 000000000000027B: 48 8B 4C 24 28???? mov???????? rcx,qword ptr >>>> [rsp+28h] >>>> ?? 0000000000000280: E8 00 00 00 00???? call??????? ?? >>>> 0Win32AttachOperationRequest@@QEAA at XZ >>>> >>>> undname "??2 at YAPEAX_K@Z" >>>> Microsoft (R) C++ Name Undecorator >>>> Copyright (C) Microsoft Corporation. All rights reserved. >>>> >>>> Undecoration of :- "??2 at YAPEAX_K@Z" >>>> is :- "void * __ptr64 __cdecl operator new(unsigned __int64)" >>>> >>>> undname "??0Win32AttachOperationRequest@@QEAA at XZ" >>>> Microsoft (R) C++ Name Undecorator >>>> Copyright (C) Microsoft Corporation. All rights reserved. >>>> >>>> Undecoration of :- "??0Win32AttachOperationRequest@@QEAA at XZ" >>>> is :- "public: __cdecl >>>> Win32AttachOperationRequest::Win32AttachOperationRequest(void) __ptr64" >>>> >>>> Visual Studio, lacking the nm utility, obviously doesn't catch this. >>>> What was more surprising is that the gcc Link Time check also fails >>>> to catch it as well. I had to manually check the output of nm after >>>> an unrelated failure and happened to stumble across the symbols >>>> _Znwy and _ZdlPvy which both correspond to >>>> >>>> operator new(unsigned long long) >>>> operator delete(void*, unsigned long long) >>>> >>>> The delete can be ignored, it's the result of a bug on my >>>> experimental branch (It was first discovered there, then I tested it >>>> on master). I'm more interested about the new, since it seems to be >>>> violating a HotSpot rule. Is this an intentional exception to the >>>> rule, or an oversight? >>>> >>>> best regards, >>>> Julian > From dholmes at openjdk.org Fri Nov 15 02:52:30 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 15 Nov 2024 02:52:30 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v5] In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 16:02:56 GMT, Coleen Phillimore wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Purge last references to SecurityManager. src/hotspot/share/classfile/javaClasses.cpp line 1617: > 1615: macro(_holder_offset, k, "holder", thread_fieldholder_signature, false); \ > 1616: macro(_name_offset, k, vmSymbols::name_name(), string_signature, false); \ > 1617: macro(_contextClassLoader_offset, k, "contextClassLoader", classloader_signature, false); \ I didn't think the context class loader was related to SM in any way. ?? src/hotspot/share/logging/logDiagnosticCommand.hpp line 62: > 60: } > 61: > 62: static const JavaPermission permission() { Is any of this permission stuff still relevant? I couldn't figure out what ultimately looks at them. ?? src/hotspot/share/prims/jvm.cpp line 154: > 152: */ > 153: > 154: extern void trace_class_resolution(Klass* to_class) { why `extern` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1843117025 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1843121894 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1843122642 From dholmes at openjdk.org Fri Nov 15 04:52:04 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 15 Nov 2024 04:52:04 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b test/hotspot/jtreg/gtest/MetaspaceUtilsGtests.java line 1: This file was reduced to empty but not actually deleted. Can you fix it please. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1843185719 From tanksherman27 at gmail.com Fri Nov 15 05:36:45 2024 From: tanksherman27 at gmail.com (Julian Waters) Date: Fri, 15 Nov 2024 13:36:45 +0800 Subject: Win32AttachOperationRequest seems to be using global new? In-Reply-To: <1eae0151-9904-49f2-b595-3d7e9d5b5964@oracle.com> References: <8ec38c62-69d5-4821-b160-0148c41581ea@oracle.com> <1eae0151-9904-49f2-b595-3d7e9d5b5964@oracle.com> Message-ID: Hi Alex, Thanks for creating the bug, I can take it on, but I'm not sure how this should be fixed. Should it be a subclass of any of the allocation.hpp classes or be allocated with CHeapObj, or should it just have operator new defined in it directly as some classes do? (UnstableIfTrap from C2 is one such example) best regards, Julian On Fri, Nov 15, 2024 at 10:11?AM Alexey Menkov wrote: > > Sorry, didn't noticed the message before. > > Yes, this is oversight. > Filed https://bugs.openjdk.org/browse/JDK-8344262 > Thank you for the finding Julian. > > --alex > > On 14.11.2024 0:28, David Holmes wrote: > > That didn't work so cc'ing serviceability-dev > > > > I think it was just an oversight. > > > > David > > > > > > On 14/11/2024 6:24 pm, David Holmes wrote: > >> It was added by JDK-8339289 so cc'ing Alex. > >> > >> David > >> > >> On 14/11/2024 5:33 pm, Julian Waters wrote: > >>> Bumping, I'm still curious about this issue > >>> > >>> best regards, > >>> Julian > >>> > >>> On Tue, Nov 12, 2024 at 10:20?PM Julian Waters > >>> wrote: > >>>> Hi all, > >>>> > >>>> Win32AttachOperationRequest is created via new, but doesn't specify > >>>> a custom new inside the class definition. The result seems to be > >>>> that we use global new on Windows: > >>>> > >>>> for (int i=0; i >>>> Win32AttachOperationRequest* op = new > >>>> Win32AttachOperationRequest(); > >>>> f1: b9 28 0d 00 00 mov ecx,0xd28 > >>>> f6: e8 00 00 00 00 call fb > >>>> > >>>> f7: IMAGE_REL_AMD64_REL32 operator new(unsigned long long) > >>>> > >>>> Stepping away from gcc's objdump and using the Microsoft dumpbin > >>>> alongside cl.exe instead, the result is this: > >>>> > >>>> 0000000000000264: B9 28 0D 00 00 mov ecx,0D28h > >>>> 0000000000000269: E8 00 00 00 00 call ??2 at YAPEAX_K@Z > >>>> 000000000000026E: 48 89 44 24 28 mov qword ptr > >>>> [rsp+28h],rax > >>>> 0000000000000273: 48 83 7C 24 28 00 cmp qword ptr > >>>> [rsp+28h],0 > >>>> 0000000000000279: 74 11 je 000000000000028C > >>>> 000000000000027B: 48 8B 4C 24 28 mov rcx,qword ptr > >>>> [rsp+28h] > >>>> 0000000000000280: E8 00 00 00 00 call ?? > >>>> 0Win32AttachOperationRequest@@QEAA at XZ > >>>> > >>>> undname "??2 at YAPEAX_K@Z" > >>>> Microsoft (R) C++ Name Undecorator > >>>> Copyright (C) Microsoft Corporation. All rights reserved. > >>>> > >>>> Undecoration of :- "??2 at YAPEAX_K@Z" > >>>> is :- "void * __ptr64 __cdecl operator new(unsigned __int64)" > >>>> > >>>> undname "??0Win32AttachOperationRequest@@QEAA at XZ" > >>>> Microsoft (R) C++ Name Undecorator > >>>> Copyright (C) Microsoft Corporation. All rights reserved. > >>>> > >>>> Undecoration of :- "??0Win32AttachOperationRequest@@QEAA at XZ" > >>>> is :- "public: __cdecl > >>>> Win32AttachOperationRequest::Win32AttachOperationRequest(void) __ptr64" > >>>> > >>>> Visual Studio, lacking the nm utility, obviously doesn't catch this. > >>>> What was more surprising is that the gcc Link Time check also fails > >>>> to catch it as well. I had to manually check the output of nm after > >>>> an unrelated failure and happened to stumble across the symbols > >>>> _Znwy and _ZdlPvy which both correspond to > >>>> > >>>> operator new(unsigned long long) > >>>> operator delete(void*, unsigned long long) > >>>> > >>>> The delete can be ignored, it's the result of a bug on my > >>>> experimental branch (It was first discovered there, then I tested it > >>>> on master). I'm more interested about the new, since it seems to be > >>>> violating a HotSpot rule. Is this an intentional exception to the > >>>> rule, or an oversight? > >>>> > >>>> best regards, > >>>> Julian > > > From iklam at openjdk.org Fri Nov 15 05:48:27 2024 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 15 Nov 2024 05:48:27 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v12] In-Reply-To: References: Message-ID: > This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). > > ---- > Note: this is a combined PR of the following individual PRs > - https://github.com/openjdk/jdk/pull/20516 > - https://github.com/openjdk/jdk/pull/20517 > - https://github.com/openjdk/jdk/pull/20843 > - https://github.com/openjdk/jdk/pull/20958 > - https://github.com/openjdk/jdk/pull/20959 > - https://github.com/openjdk/jdk/pull/21049 > - https://github.com/openjdk/jdk/pull/21143 Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 179 commits: - Merge branch 'master' into jep-483-candidate - Merge branch 'master' into jep-483-candidate - fixed merge with UseCompactObjectHeaders - Merge branch 'master' into jep-483-candidate - fixed merge - Merge branch 'master' of https://github.com/openjdk/jdk into merge-mainline - @DanHeidinga comment -- exit VM when runtimeSetup() fails - fixed merge - Merge branch 'master' into jep-483-candidate - 8343493: Perform module checks during MetaspaceShared::map_archives() - ... and 169 more: https://git.openjdk.org/jdk/compare/db56266a...77b253cf ------------- Changes: https://git.openjdk.org/jdk/pull/21642/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=11 Stats: 7192 lines in 107 files changed: 6358 ins; 513 del; 321 mod Patch: https://git.openjdk.org/jdk/pull/21642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642 PR: https://git.openjdk.org/jdk/pull/21642 From lliu at openjdk.org Fri Nov 15 07:10:09 2024 From: lliu at openjdk.org (Liming Liu) Date: Fri, 15 Nov 2024 07:10:09 GMT Subject: RFR: 8343978: Update the default value of CodeEntryAlignment for Ampere-1A and 1B Message-ID: This PR updates the default value of CodeEntryAlignment for Ampere-1A and 1B from 64 to 32. The microbenchmark CodeCacheStress shows that frontend stall becomes ~21% smaller by the change, and IPC increases by ~2.8%. The benefits persist after CodeCacheSegmentSize changes from 64 back to 128. Ran JTReg tier1 on Ampere-1A and no new issues were found. ------------- Commit messages: - Untabify - Set CodeEntryAlignment to 32 for Ampere-1A/1B Changes: https://git.openjdk.org/jdk/pull/22134/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22134&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343978 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22134.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22134/head:pull/22134 PR: https://git.openjdk.org/jdk/pull/22134 From jrose at openjdk.org Fri Nov 15 07:19:52 2024 From: jrose at openjdk.org (John R Rose) Date: Fri, 15 Nov 2024 07:19:52 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v12] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 05:48:27 GMT, Ioi Lam wrote: >> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). >> >> ---- >> Note: this is a combined PR of the following individual PRs >> - https://github.com/openjdk/jdk/pull/20516 >> - https://github.com/openjdk/jdk/pull/20517 >> - https://github.com/openjdk/jdk/pull/20843 >> - https://github.com/openjdk/jdk/pull/20958 >> - https://github.com/openjdk/jdk/pull/20959 >> - https://github.com/openjdk/jdk/pull/21049 >> - https://github.com/openjdk/jdk/pull/21143 > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 179 commits: > > - Merge branch 'master' into jep-483-candidate > - Merge branch 'master' into jep-483-candidate > - fixed merge with UseCompactObjectHeaders > - Merge branch 'master' into jep-483-candidate > - fixed merge > - Merge branch 'master' of https://github.com/openjdk/jdk into merge-mainline > - @DanHeidinga comment -- exit VM when runtimeSetup() fails > - fixed merge > - Merge branch 'master' into jep-483-candidate > - 8343493: Perform module checks during MetaspaceShared::map_archives() > - ... and 169 more: https://git.openjdk.org/jdk/compare/db56266a...77b253cf Re-reviewed. I compared the current diffs with the diffs from my last review. All new changes look good. Lilliput conflict resolution looks good. I assume we test that path. Nice work. One typo in `make/RunTests.gmk`: > The AOT cache file to be usd to wun the test with ------------- Marked as reviewed by jrose (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2437843167 From erik.osterlund at oracle.com Fri Nov 15 09:33:38 2024 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Fri, 15 Nov 2024 09:33:38 +0000 Subject: Redesign interface dispatch: progress report In-Reply-To: <48ea7e83-d459-40fb-acd7-fd65e93ca6f9@littlepinkcloud.com> References: <53d0c230-4d07-40a2-b5d9-0c5d71116e9b@redhat.com> <9a3bd769-e551-432d-ae19-34b16829509a@oracle.com> <48ea7e83-d459-40fb-acd7-fd65e93ca6f9@littlepinkcloud.com> Message-ID: Hi Andrew, When I investigated this, my main driver really was to solve some bad interactions between concurrent GC, concurrent code sweeping and the ICStubs of inline caches. My first stab at this was to flatten all the tables and try to make invocations as fast as possible so we could remove inline caches altogether, which seemed to play a central role. It worked but was rather complex and sensitive to startup performance. In the end I solved my problems by deleting the ICStubs and the sweeper instead. With them both gone, I did feel mostly happy about the state of things as all the bad interactions that motivated my work had been dealt with. But I have wondered if there was a missed opportunity to make megamorphic calls faster. So a big thank you to you for picking this up and thoroughly investigating it. The answer seems to be that there is no such missed opportunity, at this time. To me, your negative result is very important. I think the key takeaway is that unpredictable call patterns are going to fundamentally cause performance trouble anyway, making even the most carefully tuned instruction sequences slow, because of the inherent unpredictability that hardware can?t cope with very well. Regarding 32 bit code pointers, I sort of tried that actually. If memory serves right, I had support for a few more bits than 32, which I borrowed from the selector number space. This way I could pack selector + code pointer in a 64 bit word still. It was fairly compact really. But in the end, for megamorphic calls, the inherent unpredictability is likely to still be painful, in terms of potential for accelerating megamorphic calls. Thanks, /Erik > On 13 Nov 2024, at 15:59, Andrew Haley wrote: > > On 11/13/24 01:11, dean.long at oracle.com wrote: > > This work sounds related to JDK-8221828, which says about interface > > dispatch: > > > > "The proposal for invokeinterface calls is to give each interface > > method a unique number called "selector", and create a cuckoo-style > > hash table mapping selectors to code pointers for the concrete > > implementations of the interface method. The table is embedded > > straight into the native class. This allows dispatching the majority > > of the time with one indirect branch and one direct branch (compared > > to two direct branches for dynamically monomorphic calls today)." > > Thank you for that reference. I discussed this at some length with > Erik, the author of 8221828, at the time. The work I've been doing is > a follow-on from his. > > I believe this result is more general than just testing one particular > way of hashed lookup. Exactly what kind of hashing you do, as long as > it isn't bad, doesn't matter much. Maybe it would be possible to shave > a nanosecond in the predictable case, but that's it. Misprediction > would be always slow. The more complex your hash function is, no > matter how theoretically good, the harder it is for branch prediction. > The current linear probe works remarkably well, probably because it is > very simple. > > 8221828's proposal is similar to what I did, and I believe it would > have similar performance. For this exercise, I used a small (16-way) > embedded hash table in the Klass itself, with collisions handled by > compressed hash tables. With a small number of interface methods we > get few collisions, so its performance is very similar to any good > hash table. > > I did consider global numbering, but went for a 64-bit hash function > based on the full name of the method. Simply using the address of the > Method as a key would be the same as a global number in its runtime > complexity. > > The problem with embedding the entire hash table in a Klass is that of > Klass size. I think it would be possible to compress code pointers to > 32 bits, and also use 32-bit indexes, which would get that space back. > But there is more pressure today, because of Liliput, on Klass size. > > Cuckoo hashing is a nice trick, but it has its own problems. To begin > with, there are two possible table entries for each target. Also, > Cuckoo needs multiple hash functions and fallbacks for when hashing > fails, which isn't ideal for a generic hash table like we need here. > > What really matters is predictability, and that is more a function of > user code. If the target of a megamorphic call really is random, > that's going to hurt. > > -- > 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 jsjolen at openjdk.org Fri Nov 15 09:37:06 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 15 Nov 2024 09:37:06 GMT Subject: Withdrawn: 8335701: Make GrowableArray templated by an Index In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 11:34:23 GMT, Johan Sj?len wrote: > Hi, > > Today the GrowableArray has a set index type of `int`, this PR makes it so that you can set your own index type through a template parameter. > > This opens up for a few new design choices: > > - Do you know that you have a very small array? Use an `uint8_t` for len and cap, each. > - Do you have a very large one? Use an `uint64_t`. > > The code has opted for `int` being default, as to keep identical semantics for all existing code and to let users not have to worry about the index if they don't care. > > One "major" change that I don't want to get lost in the review: I've changed the mid-point calculation to be overflow insensitive without casting. > > > > // Old > mid = ((max + min) / 2); > // New > mid = min + ((max - min) / 2); > > Some semi-rigorous thinking: > min \in [0, len) > max \in [0, len) > min <= max > max - min / 2 \in [0, len/2) > Maximizing min and max => len + 0 > Maximizing max, minimizing min => len/2 > Minimizing max, maximizing min => max = min => min > > > // Proof that they're identical when m, h, l \in N > (1) m = l + (h - l) / 2 <=> > 2m = 2l + h - l = h + l > > (2) m = (h + l) / 2 <=> > 2m = h + l > (1) = (2) > QED This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/20031 From jbechberger at openjdk.org Fri Nov 15 10:26:19 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Fri, 15 Nov 2024 10:26:19 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v25] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Compute actual sampling period via si_overrun ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/2f462fe2..fef22ffd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=23-24 Stats: 71 lines in 2 files changed: 3 ins; 60 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From cnorrbin at openjdk.org Fri Nov 15 10:38:20 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Fri, 15 Nov 2024 10:38:20 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v12] In-Reply-To: References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: On Thu, 14 Nov 2024 10:00:35 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> String interning can be done on 4 different types of strings: >> - oop-strings (unicode) >> - oop-strings (latin1) >> - Symbols (non-null-terminated utf8) >> - null-terminated utf8 char arrays >> >> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table. >> >> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation. >> >> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations. >> >> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build) >> >> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types. >> Also tested and passes tiers 1-3. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > changed to const references Thank you everyone for the reviews, and especially thank you to David for your effort and patience with all this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21325#issuecomment-2478516417 From duke at openjdk.org Fri Nov 15 10:38:20 2024 From: duke at openjdk.org (duke) Date: Fri, 15 Nov 2024 10:38:20 GMT Subject: RFR: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) [v12] In-Reply-To: References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: On Thu, 14 Nov 2024 10:00:35 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> String interning can be done on 4 different types of strings: >> - oop-strings (unicode) >> - oop-strings (latin1) >> - Symbols (non-null-terminated utf8) >> - null-terminated utf8 char arrays >> >> Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table. >> >> This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation. >> >> This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations. >> >> Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build) >> >> 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types. >> Also tested and passes tiers 1-3. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > changed to const references @caspernorrbin Your change (at version 1219ec63298a0dcec89a035aad46e6fa57a56e83) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21325#issuecomment-2478519176 From jbechberger at openjdk.org Fri Nov 15 10:48:47 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Fri, 15 Nov 2024 10:48:47 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v26] In-Reply-To: References: Message-ID: <1gFDxWcqQJJHwZ11s2yljd4HHXvd1toyIM3fTEZ04C8=.cd9d9be8-47fc-4435-a8b6-4d86173b364c@github.com> > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 152 commits: - Merge remote-tracking branch 'origin' into parttimenerd_jfr_cpu_time_sampler4 - Compute actual sampling period via si_overrun - Making queue processing only stoppable in debug builds - Obtain minimal period via the CONFIG_HZ parameter of the kernel - Improve Throttling test case - Make parsing rates safer - Fix ActiveSetting event for CPUTimeSamples - Don't walk continuations in signal handler - Added more comments around queue implementation - Don't treat stackTrace attribute specially for CPUTimeSamples - ... and 142 more: https://git.openjdk.org/jdk/compare/3eece6e9...f7f8de0b ------------- Changes: https://git.openjdk.org/jdk/pull/20752/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=25 Stats: 2624 lines in 52 files changed: 2419 ins; 176 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From jbechberger at openjdk.org Fri Nov 15 11:28:16 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Fri, 15 Nov 2024 11:28:16 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v27] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Simplify #ifdefs to fix minimal and zero builds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/f7f8de0b..46995b6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=25-26 Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From cnorrbin at openjdk.org Fri Nov 15 11:31:03 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Fri, 15 Nov 2024 11:31:03 GMT Subject: Integrated: 8327156: Avoid copying in StringTable::intern(oop, TRAPS) In-Reply-To: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> References: <5bykMKJ4hddwnbJb3X3XNXA4E4-E49IY_jYsz-G0Ee8=.e905b5d8-808b-4ef8-bc72-906852abd873@github.com> Message-ID: <4MtMQDq3V4zEh9p5QrZlQWKw4lOMH0WD8cc4_xU-zhQ=.88964082-2346-4b88-bbdb-e2b150300b2b@github.com> On Thu, 3 Oct 2024 13:54:02 GMT, Casper Norrbin wrote: > Hi everyone, > > String interning can be done on 4 different types of strings: > - oop-strings (unicode) > - oop-strings (latin1) > - Symbols (non-null-terminated utf8) > - null-terminated utf8 char arrays > > Currently, when doing interning, all 4 types are first converted to unicode and copied to a jchar array. This array is used when looking in the CDS- and interning tables. If an existing string does not exist, this array is converted to a new string object, which is then inserted into the interning table. > > This is less efficient than it has to be. As strings are likely to exist in the table(s), it would be beneficial to avoid the initial jchar array allocation. When inserting into the interning table, there is also a possibility to reuse the original string object, avoiding another allocation. > > This change makes it possible to search in the tables using the different string types, avoiding that initial allocation. This is done by wrapping the string and tagging it with a type, with helper functions directing to the correct hashing/lookup/equal functions. When inserting into the table, we can now reuse the original object or go directly from the input type to an object. To do this, functionality had to be added to hash utf8-strings and to compare oop-strings with utf8. These convert utf8 into unicode character by character and operates on those, thus avoiding needing extra allocations. > > Some quick rudimentary JMH benchmarks show a ~20% increase in throughput when interning the same string repeatedly, and a ~5% increase in throughput interning only unique strings. (Only tested on my local mac aarch debug build) > > 2 new tests have also been added. The first test tests that hash codes and string equality remain consistent when converting between different string types. The second test tests that string interning works as expected when equal strings are interned from different string types. > Also tested and passes tiers 1-3. This pull request has now been integrated. Changeset: 75c651f8 Author: Casper Norrbin URL: https://git.openjdk.org/jdk/commit/75c651f859c1372175040a06c68a08298d4da0f1 Stats: 578 lines in 6 files changed: 493 ins; 30 del; 55 mod 8327156: Avoid copying in StringTable::intern(oop, TRAPS) 8326865: Avoid copying in StringTable::intern(Symbol*, TRAPS) 8327825: StringTable::intern is slow Reviewed-by: dholmes, coleenp, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/21325 From coleenp at openjdk.org Fri Nov 15 12:08:50 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 15 Nov 2024 12:08:50 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v5] In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 05:45:48 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Purge last references to SecurityManager. > > src/hotspot/share/classfile/dictionary.cpp line 80: > >> 78: >> 79: void Dictionary::Config::free_node(void* context, void* memory, Value const& value) { >> 80: delete value; // Call DictionaryEntry destructor > > `using Value = XXX` seems like an unwanted/unnecessary abstraction in this code, because depending on what `XX` is you either will or won't need to call `delete`. That is a more general cleanup though. This is sort of the standard way we use the CHT. > src/hotspot/share/classfile/javaClasses.cpp line 1617: > >> 1615: macro(_holder_offset, k, "holder", thread_fieldholder_signature, false); \ >> 1616: macro(_name_offset, k, vmSymbols::name_name(), string_signature, false); \ >> 1617: macro(_contextClassLoader_offset, k, "contextClassLoader", classloader_signature, false); \ > > I didn't think the context class loader was related to SM in any way. ?? It isn't. This symbol was near the ones I deleted, and I deleted it by mistake, so I moved it here. > src/hotspot/share/logging/logDiagnosticCommand.hpp line 62: > >> 60: } >> 61: >> 62: static const JavaPermission permission() { > > Is any of this permission stuff still relevant? I couldn't figure out what ultimately looks at them. ?? I don't know that. It is passed by the MBean code. It might be another (different) opportunity for a cleanup if the MBean code doesn't use it anymore. > src/hotspot/share/prims/jvm.cpp line 154: > >> 152: */ >> 153: >> 154: extern void trace_class_resolution(Klass* to_class) { > > why `extern` ? jni.cpp functions call this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1843665871 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1843668071 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1843668939 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1843667220 From ihse at openjdk.org Fri Nov 15 12:49:19 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 15 Nov 2024 12:49:19 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b test/hotspot/jtreg/runtime/FieldLayout/ArrayBaseOffsets.java line 1: > 1: /* This file too suffered the same fate; all contents were removed but the file was not deleted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1843710074 From rehn at openjdk.org Fri Nov 15 13:06:19 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 15 Nov 2024 13:06:19 GMT Subject: RFR: 8344010: RISC-V: Zacas do not work with LW locking Message-ID: <9zxKdn73DHLKXicGNz8Wygje-qKJMlvy4sTcKz3che8=.ee30bec8-f557-4436-9e77-70d5a06e3590@github.com> Hi all, please consider. Light weight locking fails: - We need to add cas acquire. - Register _result_ may shadow _new_val_ (same register). (NOTE this second item can effect many other cases, unclear) As the code becomes much cleaner by calling amocas_d/w directly I removed the aliases. Which fixes the first issue with cas acquire. By using t0 instead of _result_ we fix the other issue. This is a short bugfix, there are so many dragons here that I do not want to address them while fixing the bug. There are also several performance optimizations we can do here, specially for LR/SC case. So I'll do a couple of more iterations of this code in seperate PR's. Testing a bunch of local cherry-picked tests which failed. I'll start tier1 over the weekend. Thanks, Robbin ------------- Commit messages: - 8344010 fixed Changes: https://git.openjdk.org/jdk/pull/22149/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22149&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344010 Stats: 104 lines in 2 files changed: 17 ins; 79 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/22149.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22149/head:pull/22149 PR: https://git.openjdk.org/jdk/pull/22149 From coleenp at openjdk.org Fri Nov 15 13:48:44 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 15 Nov 2024 13:48:44 GMT Subject: RFR: 8343699: [aarch64] Bug in MacroAssembler::klass_decode_mode() In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 15:34:49 GMT, Thomas Stuefe wrote: > In `MacroAssembler::klass_decode_mode(),` there is a subtle bug in the xor part. > > > if (operand_valid_for_logical_immediate( > /*is32*/false, (uint64_t)CompressedKlassPointers::base())) { > (1) const size_t range = CompressedKlassPointers::klass_range_end() - CompressedKlassPointers::base(); > (2) const uint64_t range_mask = (1ULL << log2i(range)) - 1; > (3) if (((uint64_t)CompressedKlassPointers::base() & range_mask) == 0) { > log_debug(metaspace)("MacroAssembler::klass_decode_mode xor"); > return (_klass_decode_mode = KlassDecodeXor); > } > } > > > We first determine if the encoding base is encodable as immediate. If it is, then we check if it intersects with the value range of a narrow Klass ID. > > (Note: the code ignores encoding shift since the XOR will be applied to the pre-shifted narrow Klass value later.) > > The test is done by > 1) calculating the range the encoding needs to cover > 2) calculating a corresponding bit mask > 3) checking that this mask does not intersect with the encoding base. > > (2) contains a wrongness: `range_mask = (1ULL << log2i(range)) - 1` . `log2i` returns the largest log2 value *smaller* or equal to input. So, for `range` values that are not a pow2 value, the resulting mask will be one bit too short. As an effect, the code may chose XOR for cases where the lowest encoding base bit can intersect the highest narrow Klass ID bit, thus making the xor lossy. > > ---- > > Example: > > Let range be 80MB (`-XX:CompressedClassSpaceSize=80m -Xshare:off`). > > Then, range_mask = `1 << log2i(80m) - 1` => `(1 << 26) - 1` => `0x3ff_ffff` > The largest possible nKlass value, however, sits just below 80MB => `0x500_0000`. As we see, the mask does not cover the full extent of the narrow Klass ID value range (bit 26 is not covered). > Hence, if we have a base with bit 26 set, its bit 26 intersects a possible bit 26 in high-value narrow Klass ID. The xor would not be lossless. > > ---- > > The error is very unlikely because > - we try to reserve the klass range at addresses that are guaranteed not to intersect with the narrow Klass range. Only if that fails - very unlikely - we use whatever address the OS gives us. Only then could we end up with such an address. > - The class space is rarely filled so high that the highest bit of a narrowKlass ID is `1`. > > ---- > > Reproduce: > > > java -XX:CompressedClassSpaceBaseAddress=0x1Fc000000 -XX:CompressedClassSpaceSize=80m -Xlog:metaspace* -Xshare:off > > > it does not reproduce an error, but causes the JVM to start in XOR mode with an enc... Thank you for figuring this out. I'll merge with your code in my PR. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21932#pullrequestreview-2438606142 From alanb at openjdk.org Fri Nov 15 13:53:53 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 15 Nov 2024 13:53:53 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v4] In-Reply-To: <2sSkqM0XA_sKandGlnJJDEjBzCSQuaOj4UTHQVEbBII=.6a6ea3c3-2c01-447f-8cbf-cc70dbc6df04@github.com> References: <2sSkqM0XA_sKandGlnJJDEjBzCSQuaOj4UTHQVEbBII=.6a6ea3c3-2c01-447f-8cbf-cc70dbc6df04@github.com> Message-ID: On Thu, 14 Nov 2024 14:42:30 GMT, Alan Bateman wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> More obsolete code. Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS). > > I see a few left over refs to SecurityManager in vmSymbols.hpp, vmClassMacros.hpp, and a comment in logDiagnosticCommand.hpp. > Thanks @AlanBateman There's a DCmd permissions() function that talks about DiagnosticCommandMBean security. I don't know what that is so I'm leaving it. Edit: appears unrelated. Right, no need to change anything there. MBeanServer's spec was changed by JEP 486 to still allow a security exception when access is not authorized. DiagnosticCommandMBean still supports permissions. Kevin Walls is doing a clean-up pass over the java.management and jdk.management to remove vestiges of the security manager but I don't know if he plans to check the VM code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2478883319 From shade at openjdk.org Fri Nov 15 14:49:11 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 15 Nov 2024 14:49:11 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: > > - Merge branch 'merge-latest' into great-genshen-pr-redux > - Use new CompactHeader forwarding APIs in generational mode > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge > - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines > > Reviewed-by: wkemper > - Merge > - 8343227: GenShen: Fold resource mark into management of preselected regions > > Reviewed-by: kdnilsen > - Merge openjdk/jdk tip into great-genshen-pr-redux > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge remote-tracking branch 'jdk/master' into merge-latest > - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 Sonar findings: src/hotspot/share/gc/shenandoah/shenandoahEvacTracker.cpp line 39: > 37: if (_use_age_table) { > 38: _age_table = new AgeTable(false); > 39: } Sonar caught it: Initialize `_age_table` to `nullptr` for extra safety. Current uses seem to be gated by `_use_age_table`, though. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1505: > 1503: size_t transferred_regions = 0; > 1504: ShenandoahLeftRightIterator iterator(&_partitions, which_collector, true); > 1505: idx_t rightmost = _partitions.rightmost_empty(which_collector); Sonar: `rightmost` is not used. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1567: > 1565: <= _partitions.rightmost(ShenandoahFreeSetPartitionId::Collector))) { > 1566: ShenandoahHeapLocker locker(_heap->lock()); > 1567: max_xfer_regions -= Sonar: Value stored to `max_xfer_regions` here is not used. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1856: > 1854: size_t consumed_old_collector = 0; > 1855: size_t consumed_mutator = 0; > 1856: size_t available_old = 0; Sonar: `available_old` is not used. `available_young` is not used. src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 380: > 378: > 379: size_t old_evacuated = collection_set->get_old_bytes_reserved_for_evacuation(); > 380: size_t old_evacuated_committed = (size_t) (ShenandoahOldEvacWaste * old_evacuated); Sonar: implicit conversion from 'size_t' (aka 'unsigned long') to 'double' may lose precision Not sure if it breaks any math. src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 455: > 453: // excess_old < unaffiliated old: we can give back MIN(excess_old/region_size_bytes, unaffiliated_old_regions) > 454: size_t excess_regions = excess_old / region_size_bytes; > 455: size_t regions_to_xfer = MIN2(excess_regions, unaffiliated_old_regions); Sonar: Value stored to 'regions_to_xfer' during its initialization is never read src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 549: > 547: } > 548: if (r->age() >= tenuring_threshold) { > 549: if ((r->garbage() < old_garbage_threshold)) { Sonar: double parentheses. src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 276: > 274: // where abundance is defined as >= ShenGenHeap::plab_min_size(). In the former case, we try shrinking the > 275: // desired PLAB size to the minimum and retry PLAB allocation to avoid cascading of shared memory allocations. > 276: if (plab->words_remaining() < plab_min_size()) { Sonar caught it: There is a `plab != nullptr` check above at L267, which implies `plab` can be `nullptr` here? This would SEGV. src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 656: > 654: // may not evacuate the entirety of unprocessed candidates in a single mixed evacuation. > 655: const size_t max_evac_need = (size_t) > 656: (old_generation()->unprocessed_collection_candidates_live_memory() * ShenandoahOldEvacWaste); Sonar: implicit conversion from 'size_t' (aka 'unsigned long') to 'double' may lose precision Since this is a heuristics calculation, should we be precise here? src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 1003: > 1001: } > 1002: > 1003: namespace ShenandoahCompositeRegionClosure { We usually avoid `namespace`-s. See Hotspot style guide: https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#namespaces src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 89: > 87: } > 88: > 89: HeapWord* ShenandoahHeapRegion::allocate(size_t size, ShenandoahAllocRequest req) { Sonar caught it: `ShenandoahAllocRequest` should be passed by reference here? src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.hpp line 99: > 97: size_t region_size, size_t protocolVersion); > 98: > 99: uint _count = 0; Sonar caught it: this `_count` field does not seem to be used. src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 157: > 155: size_t card_at_start = _rs->card_index_for_addr(address); > 156: HeapWord* card_start_address = _rs->addr_for_card_index(card_at_start); > 157: uint8_t offset_in_card = address - card_start_address; Sonar: implicit conversion loses integer precision: 'long' to 'uint8_t' (aka 'unsigned char'). This looks risky. Should probably be `checked_cast(pointer_delta(address, card_start_address, 1))`? src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 889: > 887: size_t previous_group_span = _group_entries[0] * _group_chunk_size[0]; > 888: for (size_t i = 1; i < _num_groups; i++) { > 889: size_t previous_group_entries = (i == 1)? _group_entries[0]: (_group_entries[i-1] - _group_entries[i-2]); Sonar: Value stored to `previous_group_entries` during its initialization is never read ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2438690431 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843878467 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843904346 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843905277 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843912193 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843933121 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843906258 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843898116 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843857836 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843931737 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843872870 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843886835 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843892961 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843928920 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843907601 From mli at openjdk.org Fri Nov 15 14:52:18 2024 From: mli at openjdk.org (Hamlin Li) Date: Fri, 15 Nov 2024 14:52:18 GMT Subject: RFR: 8344169: RISC-V: Use more meaningful frame::metadata_words where possible In-Reply-To: <9XNv_0zgwAVjUaUjVSxFFkwvzUFp3f2Lu8MvPyFv8l8=.d6d9457a-e737-4169-a198-7ea88cfde0db@github.com> References: <9XNv_0zgwAVjUaUjVSxFFkwvzUFp3f2Lu8MvPyFv8l8=.d6d9457a-e737-4169-a198-7ea88cfde0db@github.com> Message-ID: On Thu, 14 Nov 2024 07:00:55 GMT, Fei Yang wrote: > Hello, please review this RISC-V specific change which improves code readability. > > Some background to help understand. We have following frame enumerations in file frame_riscv.hpp: > > enum { > link_offset = -2, > return_addr_offset = -1, > sender_sp_offset = 0 > }; > > The values are compatible with the platform ABI and are different from other platforms like x64 and aarch64. Especially, `sender_sp_offset` is 0 for RISC-V compared to 2 for x64 and aarch64. As a result, there exists some differences in places where code calculates fp through offseting pointer sp by value `sender_sp_offset`. For RISC-V, we used constant number 2 instead of `sender_sp_offset` as the pointer offset. But the code will be more readable if we use `frame::metadata_words` which has the same value. This change would not affect correctness or functionality in theory. > > Testing on linux-riscv64: > - [x] hotspot:tier1 (release) > - [x] hotspot_loom & jdk_loom (release & fastdebug) Thanks for trying to make it more readable! And sorry for the late review. Some minor comments below. src/hotspot/cpu/riscv/frame_riscv.cpp line 156: > 154: > 155: sender_unextended_sp = sender_sp; > 156: sender_pc = (address) *(sender_sp - 1); We have `-1` here, and below `-2` is replaced as frame::metadata_words, seems it's still bit confusing to me. Similar comments to several other places. But I'm not quite sure what should be the better way to fix it. ------------- PR Review: https://git.openjdk.org/jdk/pull/22096#pullrequestreview-2438809876 PR Review Comment: https://git.openjdk.org/jdk/pull/22096#discussion_r1843940515 From mdoerr at openjdk.org Fri Nov 15 15:18:09 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 15 Nov 2024 15:18:09 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: <2m-YJkwNcpIEDdVElZOw2uqbTD6eOoBM0cRGoSFdADM=.86118c91-b8dd-4da9-b691-5ffe0643f51d@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <2m-YJkwNcpIEDdVElZOw2uqbTD6eOoBM0cRGoSFdADM=.86118c91-b8dd-4da9-b691-5ffe0643f51d@github.com> Message-ID: On Thu, 14 Nov 2024 23:39:08 GMT, Martin Doerr wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > The new test TestAllocOutOfMemory.java#large failed on some PPC64 machines: > > Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main" > > java.lang.RuntimeException: 'java.lang.OutOfMemoryError: Java heap space' missing from stdout/stderr > > Probably not a show-stopper. Should the test be adapted or disabled for this platform? > @TheRealMDoerr - do you have the logs from the test failure? If so, could you open a ticket with them in JBS? Thank you! Filed [JDK-8344312](https://bugs.openjdk.org/browse/JDK-8344312). In addition, we see the following tests failing with "java.lang.OutOfMemoryError: Java heap space" on all Shenandoah platforms: gc/stress/jfr/TestStressBigAllocationGCEventsWithShenandoah.java#default gc/stress/jfr/TestStressBigAllocationGCEventsWithShenandoah.java#generational Can you reproduce those? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2479110413 From shade at openjdk.org Fri Nov 15 15:18:09 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 15 Nov 2024 15:18:09 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: > > - Merge branch 'merge-latest' into great-genshen-pr-redux > - Use new CompactHeader forwarding APIs in generational mode > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge > - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines > > Reviewed-by: wkemper > - Merge > - 8343227: GenShen: Fold resource mark into management of preselected regions > > Reviewed-by: kdnilsen > - Merge openjdk/jdk tip into great-genshen-pr-redux > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge remote-tracking branch 'jdk/master' into merge-latest > - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 361: > 359: // frequently than last byte. This is true when number of clean cards is greater than number of dirty cards. > 360: static const uint16_t ObjectStartsInCardRegion = 0x80; > 361: static const uint16_t FirstStartBits = 0x7f; I see these are used to do operations against `uint8_t` (`....offsets.first`). Any reason why these should not be `uint8_t`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843980993 From ihse at openjdk.org Fri Nov 15 15:37:01 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 15 Nov 2024 15:37:01 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v11] In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'master' into static-jdk-image - Merge branch 'master' into static-jdk-image - Merge branch 'master' into static-jdk-image - Fix bug in filtering out -Wl,--exclude-libs,ALL - Don't hardcode server variant - Setup LDFLAGS_STATIC_JDK - Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check - Add lookup asserts - Remove superfluous SRC. - Merge branch 'master' into static-jdk-image - ... and 2 more: https://git.openjdk.org/jdk/compare/40a055eb...0e5ff083 ------------- Changes: https://git.openjdk.org/jdk/pull/20837/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=10 Stats: 446 lines in 26 files changed: 367 ins; 5 del; 74 mod Patch: https://git.openjdk.org/jdk/pull/20837.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837 PR: https://git.openjdk.org/jdk/pull/20837 From iklam at openjdk.org Fri Nov 15 16:02:46 2024 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 15 Nov 2024 16:02:46 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v13] In-Reply-To: References: Message-ID: > This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). > > ---- > Note: this is a combined PR of the following individual PRs > - https://github.com/openjdk/jdk/pull/20516 > - https://github.com/openjdk/jdk/pull/20517 > - https://github.com/openjdk/jdk/pull/20843 > - https://github.com/openjdk/jdk/pull/20958 > - https://github.com/openjdk/jdk/pull/20959 > - https://github.com/openjdk/jdk/pull/21049 > - https://github.com/openjdk/jdk/pull/21143 Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 181 commits: - Merge branch 'master' into jep-483-candidate - fixed typo in make/RunTests.gmk comments - Merge branch 'master' into jep-483-candidate - Merge branch 'master' into jep-483-candidate - fixed merge with UseCompactObjectHeaders - Merge branch 'master' into jep-483-candidate - fixed merge - Merge branch 'master' of https://github.com/openjdk/jdk into merge-mainline - @DanHeidinga comment -- exit VM when runtimeSetup() fails - fixed merge - ... and 171 more: https://git.openjdk.org/jdk/compare/40a055eb...b317b4b5 ------------- Changes: https://git.openjdk.org/jdk/pull/21642/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=12 Stats: 7192 lines in 107 files changed: 6358 ins; 513 del; 321 mod Patch: https://git.openjdk.org/jdk/pull/21642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642 PR: https://git.openjdk.org/jdk/pull/21642 From iklam at openjdk.org Fri Nov 15 16:38:20 2024 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 15 Nov 2024 16:38:20 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v14] In-Reply-To: References: Message-ID: > This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). > > ---- > Note: this is a combined PR of the following individual PRs > - https://github.com/openjdk/jdk/pull/20516 > - https://github.com/openjdk/jdk/pull/20517 > - https://github.com/openjdk/jdk/pull/20843 > - https://github.com/openjdk/jdk/pull/20958 > - https://github.com/openjdk/jdk/pull/20959 > - https://github.com/openjdk/jdk/pull/21049 > - https://github.com/openjdk/jdk/pull/21143 Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed test after security manager removal ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21642/files - new: https://git.openjdk.org/jdk/pull/21642/files/b317b4b5..5d9a6677 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=12-13 Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/21642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642 PR: https://git.openjdk.org/jdk/pull/21642 From jrose at openjdk.org Fri Nov 15 17:04:59 2024 From: jrose at openjdk.org (John R Rose) Date: Fri, 15 Nov 2024 17:04:59 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v14] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 16:38:20 GMT, Ioi Lam wrote: >> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). >> >> ---- >> Note: this is a combined PR of the following individual PRs >> - https://github.com/openjdk/jdk/pull/20516 >> - https://github.com/openjdk/jdk/pull/20517 >> - https://github.com/openjdk/jdk/pull/20843 >> - https://github.com/openjdk/jdk/pull/20958 >> - https://github.com/openjdk/jdk/pull/20959 >> - https://github.com/openjdk/jdk/pull/21049 >> - https://github.com/openjdk/jdk/pull/21143 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test after security manager removal Reviewed again. ------------- Marked as reviewed by jrose (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2439181309 From wkemper at openjdk.org Fri Nov 15 17:20:11 2024 From: wkemper at openjdk.org (William Kemper) Date: Fri, 15 Nov 2024 17:20:11 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Fri, 15 Nov 2024 14:05:51 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 276: > >> 274: // where abundance is defined as >= ShenGenHeap::plab_min_size(). In the former case, we try shrinking the >> 275: // desired PLAB size to the minimum and retry PLAB allocation to avoid cascading of shared memory allocations. >> 276: if (plab->words_remaining() < plab_min_size()) { > > Sonar caught it: There is a `plab != nullptr` check above at L267, which implies `plab` can be `nullptr` here? This would SEGV. https://bugs.openjdk.org/browse/JDK-8344320 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844209761 From wkemper at openjdk.org Fri Nov 15 17:29:08 2024 From: wkemper at openjdk.org (William Kemper) Date: Fri, 15 Nov 2024 17:29:08 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Fri, 15 Nov 2024 14:11:10 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahEvacTracker.cpp line 39: > >> 37: if (_use_age_table) { >> 38: _age_table = new AgeTable(false); >> 39: } > > Sonar caught it: Initialize `_age_table` to `nullptr` for extra safety. Current uses seem to be gated by `_use_age_table`, though. https://bugs.openjdk.org/browse/JDK-8344321 > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1856: > >> 1854: size_t consumed_old_collector = 0; >> 1855: size_t consumed_mutator = 0; >> 1856: size_t available_old = 0; > > Sonar: `available_old` is not used. `available_young` is not used. https://bugs.openjdk.org/browse/JDK-8344321 > src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 380: > >> 378: >> 379: size_t old_evacuated = collection_set->get_old_bytes_reserved_for_evacuation(); >> 380: size_t old_evacuated_committed = (size_t) (ShenandoahOldEvacWaste * old_evacuated); > > Sonar: implicit conversion from 'size_t' (aka 'unsigned long') to 'double' may lose precision > > Not sure if it breaks any math. https://bugs.openjdk.org/browse/JDK-8344321 > src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 656: > >> 654: // may not evacuate the entirety of unprocessed candidates in a single mixed evacuation. >> 655: const size_t max_evac_need = (size_t) >> 656: (old_generation()->unprocessed_collection_candidates_live_memory() * ShenandoahOldEvacWaste); > > Sonar: implicit conversion from 'size_t' (aka 'unsigned long') to 'double' may lose precision > > Since this is a heuristics calculation, should we be precise here? https://bugs.openjdk.org/browse/JDK-8344321 > src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 89: > >> 87: } >> 88: >> 89: HeapWord* ShenandoahHeapRegion::allocate(size_t size, ShenandoahAllocRequest req) { > > Sonar caught it: `ShenandoahAllocRequest` should be passed by reference here? https://bugs.openjdk.org/browse/JDK-8344321 > src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.hpp line 99: > >> 97: size_t region_size, size_t protocolVersion); >> 98: >> 99: uint _count = 0; > > Sonar caught it: this `_count` field does not seem to be used. https://bugs.openjdk.org/browse/JDK-8344321 > src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 157: > >> 155: size_t card_at_start = _rs->card_index_for_addr(address); >> 156: HeapWord* card_start_address = _rs->addr_for_card_index(card_at_start); >> 157: uint8_t offset_in_card = address - card_start_address; > > Sonar: implicit conversion loses integer precision: 'long' to 'uint8_t' (aka 'unsigned char'). > > This looks risky. Should probably be `checked_cast(pointer_delta(address, card_start_address, 1))`? https://bugs.openjdk.org/browse/JDK-8344321 > src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 889: > >> 887: size_t previous_group_span = _group_entries[0] * _group_chunk_size[0]; >> 888: for (size_t i = 1; i < _num_groups; i++) { >> 889: size_t previous_group_entries = (i == 1)? _group_entries[0]: (_group_entries[i-1] - _group_entries[i-2]); > > Sonar: Value stored to `previous_group_entries` during its initialization is never read https://bugs.openjdk.org/browse/JDK-8344321 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844218002 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844219136 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844219821 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844219644 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844218123 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844218269 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844219351 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844219014 From szaldana at openjdk.org Fri Nov 15 17:41:59 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Fri, 15 Nov 2024 17:41:59 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v4] In-Reply-To: References: Message-ID: <2RlwGn6xZtLLOm9KMHFdbS3qU8bMTiEfpLlUX8wIyIs=.7f8535e3-29f1-4860-be54-162b6499a349@github.com> > Hi all, > > This PR addresses [8343700](https://bugs.openjdk.org/browse/JDK-8343700) where ceil_log2 looped endlessly if the input value has the highest bit set. > > I also dealt with the case where we try to find ceil_log2(1) which would've returned 1 as opposed to 0. > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: Changing return type to int. Also handling unsigned values ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22074/files - new: https://git.openjdk.org/jdk/pull/22074/files/f82cc31d..e47bdb8a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22074&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22074&range=02-03 Stats: 26 lines in 3 files changed: 14 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/22074.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22074/head:pull/22074 PR: https://git.openjdk.org/jdk/pull/22074 From szaldana at openjdk.org Fri Nov 15 17:42:00 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Fri, 15 Nov 2024 17:42:00 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v3] In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 08:34:12 GMT, Kim Barrett wrote: >> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: >> >> Starting ret at 0 > > Changes requested by kbarrett (Reviewer). Thanks for the comments @kimbarrett, @tstuefe. I made some updates and added test cases for max values too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22074#issuecomment-2479557185 From szaldana at openjdk.org Fri Nov 15 18:06:06 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Fri, 15 Nov 2024 18:06:06 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v5] In-Reply-To: References: Message-ID: > Hi all, > > This PR addresses [8343700](https://bugs.openjdk.org/browse/JDK-8343700) where ceil_log2 looped endlessly if the input value has the highest bit set. > > I also dealt with the case where we try to find ceil_log2(1) which would've returned 1 as opposed to 0. > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: fixing assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22074/files - new: https://git.openjdk.org/jdk/pull/22074/files/e47bdb8a..8b251d1f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22074&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22074&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22074.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22074/head:pull/22074 PR: https://git.openjdk.org/jdk/pull/22074 From lmesnik at openjdk.org Fri Nov 15 20:55:06 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 15 Nov 2024 20:55:06 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks Message-ID: Hi Could you please "pre-review" this fix that add locks information. I want to get some preliminary feedback before completing the changes. Here is the motivation for this rfe and explanation why I add it into SA now. The information about current owners of Hotspot Mutex is often very useful for dealock investigations. The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. Also the debugger solution is OS specifc. The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. The example of output: [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 Attaching to process ID 1620533, please wait... Debugger attached successfully. Server compiler detected. JVM version is 24-internal-adhoc.lmesnik.open Deadlock Detection: No deadlocks found. Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 ----------------- 1620559 ----------------- "C1 CompilerThread4" #28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_blocked 0x00007f8cff11e88d syscall + 0x1d 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b ..... ----------------- 1620554 ----------------- "LockerThread" #31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition [0x00007f8cc1dfe000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_blocked 0x00007f8cff091117 __GI___futex_abstimed_wait_cancelable64 + 0xe7 0x00007f8cff093a41 __GI___pthread_cond_wait + 0x211 ------------- Commit messages: - years updated - fixed spaces - Merge branch 'master' of https://github.com/openjdk/jdk into sa-lock - Merge branch 'sa-lock' of https://github.com/lmesnik/jdk into sa-lock - Merge branch 'master' into sa-lock - spaces fixed - fixed product builds - updated test - ident - polish - ... and 10 more: https://git.openjdk.org/jdk/compare/c388455d...606dcc03 Changes: https://git.openjdk.org/jdk/pull/21943/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21943&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343741 Stats: 457 lines in 14 files changed: 383 ins; 69 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21943.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21943/head:pull/21943 PR: https://git.openjdk.org/jdk/pull/21943 From sspitsyn at openjdk.org Fri Nov 15 20:55:06 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 15 Nov 2024 20:55:06 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 01:11:14 GMT, Leonid Mesnik wrote: > Hi > Could you please "pre-review" this fix that add locks information. I want to get some preliminary feedback before completing the changes. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" #28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" #31 prio=5 tid=0x00007f8cf8309a00 nid=16... src/hotspot/share/runtime/mutex.cpp line 270: > 268: } > 269: > 270: static const int MAX_NUM_MUTEX = 1204; Q: Is the number `1204` intentional or it was supposed to be `1024`? :) src/hotspot/share/runtime/mutex.cpp line 275: > 273: int Mutex::_num_mutex = 0; > 274: > 275: void Mutex::add_mutex(Mutex* var) { Nit: Why `var` but not `arg`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21943#discussion_r1839729824 PR Review Comment: https://git.openjdk.org/jdk/pull/21943#discussion_r1839731580 From lmesnik at openjdk.org Fri Nov 15 20:55:06 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 15 Nov 2024 20:55:06 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 08:26:57 GMT, Serguei Spitsyn wrote: >> Hi >> Could you please "pre-review" this fix that add locks information. I want to get some preliminary feedback before completing the changes. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" #28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> -------... > > src/hotspot/share/runtime/mutex.cpp line 270: > >> 268: } >> 269: >> 270: static const int MAX_NUM_MUTEX = 1204; > > Q: Is the number `1204` intentional or it was supposed to be `1024`? :) This codes with MAX_NUM_MUTEX = 1204 and void Mutex::add_mutex(Mutex* var) { has been just moved from mutexLocker. I haven't changed it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21943#discussion_r1841198179 From lmesnik at openjdk.org Fri Nov 15 21:28:42 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 15 Nov 2024 21:28:42 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v2] In-Reply-To: References: Message-ID: > Hi > Could you please review this fix that add locks information. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" #28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" #31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition [0x00007f8cc1dfe000] > java.lang.Thread.State: RU... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: test updated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21943/files - new: https://git.openjdk.org/jdk/pull/21943/files/606dcc03..4fcd6eeb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21943&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21943&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21943.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21943/head:pull/21943 PR: https://git.openjdk.org/jdk/pull/21943 From lmesnik at openjdk.org Fri Nov 15 21:28:43 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 15 Nov 2024 21:28:43 GMT Subject: Withdrawn: 8343741: SA jstack --mixed should print information about VM locks In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 01:11:14 GMT, Leonid Mesnik wrote: > Hi > Could you please review this fix that add locks information. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" #28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" #31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition [0x00007f8cc1dfe000] > java.lang.Thread.State: RU... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/21943 From iklam at openjdk.org Fri Nov 15 22:22:49 2024 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 15 Nov 2024 22:22:49 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v14] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 16:38:20 GMT, Ioi Lam wrote: >> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). >> >> ---- >> Note: this is a combined PR of the following individual PRs >> - https://github.com/openjdk/jdk/pull/20516 >> - https://github.com/openjdk/jdk/pull/20517 >> - https://github.com/openjdk/jdk/pull/20843 >> - https://github.com/openjdk/jdk/pull/20958 >> - https://github.com/openjdk/jdk/pull/20959 >> - https://github.com/openjdk/jdk/pull/21049 >> - https://github.com/openjdk/jdk/pull/21143 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test after security manager removal Thanks everyone for the review and support! I ran tiers 1~8 several times in the past few days when merging with mainline. No regressions found. GHA error is timeout and seems to be unrelated. Integrating now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2480037673 From iklam at openjdk.org Fri Nov 15 22:31:55 2024 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 15 Nov 2024 22:31:55 GMT Subject: Integrated: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking In-Reply-To: References: Message-ID: <4xos88WJsJcF3QMs1xI1sEacUTohEe70qrJZQHEczXY=.05b9a85a-2a2e-40bc-aeac-fb682fff88ff@github.com> On Tue, 22 Oct 2024 16:19:48 GMT, Ioi Lam wrote: > This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). > > ---- > Note: this is a combined PR of the following individual PRs > - https://github.com/openjdk/jdk/pull/20516 > - https://github.com/openjdk/jdk/pull/20517 > - https://github.com/openjdk/jdk/pull/20843 > - https://github.com/openjdk/jdk/pull/20958 > - https://github.com/openjdk/jdk/pull/20959 > - https://github.com/openjdk/jdk/pull/21049 > - https://github.com/openjdk/jdk/pull/21143 This pull request has now been integrated. Changeset: 41a2d49f Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/41a2d49f0a1ed298b8ab023ce634335464454fe7 Stats: 7188 lines in 107 files changed: 6354 ins; 513 del; 321 mod 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking Reviewed-by: jrose, kvn, heidinga, asmehra, vlivanov ------------- PR: https://git.openjdk.org/jdk/pull/21642 From lmesnik at openjdk.org Fri Nov 15 23:41:13 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 15 Nov 2024 23:41:13 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks Message-ID: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Hi Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. Here is the motivation for this rfe and explanation why I add it into SA now. The information about current owners of Hotspot Mutex is often very useful for dealock investigations. The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. Also the debugger solution is OS specifc. The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. The example of output: [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 Attaching to process ID 1620533, please wait... Debugger attached successfully. Server compiler detected. JVM version is 24-internal-adhoc.lmesnik.open Deadlock Detection: No deadlocks found. Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 ----------------- 1620559 ----------------- "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_blocked 0x00007f8cff11e88d syscall + 0x1d 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b ..... ----------------- 1620554 ----------------- "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition [0x00007f8cc1dfe000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_blocked 0x00007f8cff091117 __GI___futex_abstimed_wait_cancelable64 + 0xe7 0x00007f8cff093a41 __GI___pthread_cond_wait + 0x211 ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/22171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343741 Stats: 452 lines in 14 files changed: 379 ins; 69 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From coleenp at openjdk.org Fri Nov 15 23:43:33 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 15 Nov 2024 23:43:33 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v6] In-Reply-To: References: Message-ID: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - Handle merge conflicts in new resolve_instance_class calls. - Merge branch 'master' into protection-domain - Purge last references to SecurityManager. - More obsolete code. Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS). - Found more obsolete security manager code. - More purging of AccessController, AccessControlContext and some stackwalking questions. - David comments. - Remove some more includes. - 8341916: Remove ProtectionDomain related hotspot code and tests ------------- Changes: https://git.openjdk.org/jdk/pull/22064/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=05 Stats: 1416 lines in 48 files changed: 1 ins; 1245 del; 170 mod Patch: https://git.openjdk.org/jdk/pull/22064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22064/head:pull/22064 PR: https://git.openjdk.org/jdk/pull/22064 From iklam at openjdk.org Fri Nov 15 23:46:49 2024 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 15 Nov 2024 23:46:49 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v6] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 23:43:33 GMT, Coleen Phillimore wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Handle merge conflicts in new resolve_instance_class calls. > - Merge branch 'master' into protection-domain > - Purge last references to SecurityManager. > - More obsolete code. Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS). > - Found more obsolete security manager code. > - More purging of AccessController, AccessControlContext and some stackwalking questions. > - David comments. > - Remove some more includes. > - 8341916: Remove ProtectionDomain related hotspot code and tests LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22064#pullrequestreview-2439937392 From kbarrett at openjdk.org Fri Nov 15 23:53:46 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 15 Nov 2024 23:53:46 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v5] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 18:06:06 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8343700](https://bugs.openjdk.org/browse/JDK-8343700) where ceil_log2 looped endlessly if the input value has the highest bit set. >> >> I also dealt with the case where we try to find ceil_log2(1) which would've returned 1 as opposed to 0. >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > fixing assert Changes requested by kbarrett (Reviewer). src/hotspot/share/classfile/dictionary.cpp line 59: > 57: : _number_of_entries(0), _loader_data(loader_data) { > 58: > 59: size_t start_size_log_2 = MAX2((size_t)ceil_log2(table_size), (size_t)2); // 2 is minimum size even though some dictionaries only have one entry Rather than adding a cast, remove the other (probably changing literal to `2u`). The implicit conversion of uint => size_t at the end is not a problem. src/hotspot/share/utilities/powerOfTwo.hpp line 124: > 122: > 123: // Find log2 value greater than this input > 124: template ::type, ENABLE_IF(std::is_integral::value)> U doesn't need to be a template parameter. Make it a function-local type alias. src/hotspot/share/utilities/powerOfTwo.hpp line 125: > 123: // Find log2 value greater than this input > 124: template ::type, ENABLE_IF(std::is_integral::value)> > 125: inline int ceil_log2(T value) { Pre-existing: I think this should have been called `log2i_ceil`, with a description something like: // Ceiling of log2 of a positive, integral value, i.e., smallest i such that value <= 2^i. And move it near the other log2i variants. This could be done as a followup, to keep this PR focused on the issue at hand. src/hotspot/share/utilities/powerOfTwo.hpp line 128: > 126: assert(value > 0, "Invalid value"); > 127: U unsigned_value = static_cast(value); > 128: int max_bits = sizeof(U) * 8; Use BitsPerByte instead of `8`. src/hotspot/share/utilities/powerOfTwo.hpp line 134: > 132: break; > 133: } > 134: } But I think this could all be much "simpler"? I think this works: template::value)> int ceil_log2(T value) { assert(value > T(0), "Invalid value"); return log2i_graceful(value - 1) + 1; } ------------- PR Review: https://git.openjdk.org/jdk/pull/22074#pullrequestreview-2439858700 PR Review Comment: https://git.openjdk.org/jdk/pull/22074#discussion_r1844616579 PR Review Comment: https://git.openjdk.org/jdk/pull/22074#discussion_r1844651668 PR Review Comment: https://git.openjdk.org/jdk/pull/22074#discussion_r1844651693 PR Review Comment: https://git.openjdk.org/jdk/pull/22074#discussion_r1844650960 PR Review Comment: https://git.openjdk.org/jdk/pull/22074#discussion_r1844680497 From wkemper at openjdk.org Fri Nov 15 23:55:08 2024 From: wkemper at openjdk.org (William Kemper) Date: Fri, 15 Nov 2024 23:55:08 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <2m-YJkwNcpIEDdVElZOw2uqbTD6eOoBM0cRGoSFdADM=.86118c91-b8dd-4da9-b691-5ffe0643f51d@github.com> Message-ID: On Fri, 15 Nov 2024 15:12:30 GMT, Martin Doerr wrote: >> The new test TestAllocOutOfMemory.java#large failed on some PPC64 machines: >> >> Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main" >> >> java.lang.RuntimeException: 'java.lang.OutOfMemoryError: Java heap space' missing from stdout/stderr >> >> Probably not a show-stopper. Should the test be adapted or disabled for this platform? > >> @TheRealMDoerr - do you have the logs from the test failure? If so, could you open a ticket with them in JBS? Thank you! > > Filed [JDK-8344312](https://bugs.openjdk.org/browse/JDK-8344312). > > In addition, we see the following tests failing with "java.lang.OutOfMemoryError: Java heap space" on all Shenandoah platforms: > gc/stress/jfr/TestStressBigAllocationGCEventsWithShenandoah.java#default > gc/stress/jfr/TestStressBigAllocationGCEventsWithShenandoah.java#generational > Can you reproduce those? @TheRealMDoerr - Yes, those tests failed for me. I'll look into them. I'm also working to get my hands on a PPC64 machine to investigate [JDK-8344312](https://bugs.openjdk.org/browse/JDK-8344312). We appreciate your help here! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2480152786 From vaivanov at openjdk.org Sat Nov 16 00:41:20 2024 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Sat, 16 Nov 2024 00:41:20 GMT Subject: RFR: 8341481: [perf] vframeStreamCommon constructor may be optimized Message-ID: Optimize constructor to skip extra copy for registers. The tier1 tests are OK. The Specjvm2008 benchmark reports ~1% improvement. ------------- Commit messages: - 8341481: [perf] vframeStreamCommon constructor may be optimized - 8341481 [Perf] vframeStreamCommon constructor may be optimized Changes: https://git.openjdk.org/jdk/pull/22173/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22173&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341481 Stats: 31 lines in 5 files changed: 11 ins; 1 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/22173.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22173/head:pull/22173 PR: https://git.openjdk.org/jdk/pull/22173 From gziemski at openjdk.org Sat Nov 16 02:42:56 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Sat, 16 Nov 2024 02:42:56 GMT Subject: RFR: 8328944: NMT reports "unknown" memory In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 07:18:02 GMT, Thomas Stuefe wrote: >> We use mtNone value in several functions default parameters, which may show up in NMT reports. >> >> We address this, by removing the default value and forcing, where possible, for the callers to declare NMT tag that reflects the usage. >> >> Eventually the goal would be not to use mtNone anywhere, but we are not there quite yet. >> >> TODO: update copyrights. >> >> Testing: undergoing MARCH5 tier1-5 ... > > src/hotspot/cpu/aarch64/compressedKlass_aarch64.cpp line 72: > >> 70: assert(immediate > 0 && Assembler::operand_valid_for_logical_immediate(/*is32*/false, immediate), >> 71: "Invalid immediate %d " UINT64_FORMAT, index, immediate); >> 72: result = os::attempt_reserve_memory_at((char*)immediate, size, false, mtMetaspace); > > mtMetaspace is wrong. There is no right tag apart from mtNone, since this address range is a combination of mtClass+mtClassShared, depending on how class space is configured. mtNone signals "will be set later", which is the correct course here IHMO. > > The tag is set later, see metaspace.cpp and metaspaceShared.cpp Can we introduce `mtAllocated` and use it here instead of `mtNone` and keep `mtNone` only as the initial "unassigned" state? > src/hotspot/os/bsd/gc/z/zPhysicalMemoryBacking_bsd.cpp line 82: > >> 80: >> 81: // Reserve address space for backing memory >> 82: _base = (uintptr_t)os::reserve_memory(max_capacity, false, mtGC); > > This is Java heap. Fixed. > src/hotspot/share/cds/archiveBuilder.cpp line 330: > >> 328: size_t buffer_size = estimate_archive_size(); >> 329: ReservedSpace rs(buffer_size, MetaspaceShared::core_region_alignment(), >> 330: os::vm_page_size(), nullptr, mtMetaspace); > > This is not Metaspace. Possibly mtClassShared, though that one is reserved for the runtime mapping of the CDS archive; this is the dumptime image. mtInternal would be the best fit, IMHO. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844882191 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844882271 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844882386 From lmesnik at openjdk.org Sat Nov 16 02:49:35 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 16 Nov 2024 02:49:35 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v2] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: added short sleep into the loop. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/c302f918..93229db3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From jrose at openjdk.org Sat Nov 16 02:50:58 2024 From: jrose at openjdk.org (John R Rose) Date: Sat, 16 Nov 2024 02:50:58 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v6] In-Reply-To: References: Message-ID: <7I8Yw-5pVWAHnlsEIVKq54gRMuLHd0K3l7zSdKJH9L8=.5ab13bd7-9c27-4bda-9a60-8bd30c9a6fd6@github.com> On Fri, 15 Nov 2024 23:43:33 GMT, Coleen Phillimore wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Handle merge conflicts in new resolve_instance_class calls. > - Merge branch 'master' into protection-domain > - Purge last references to SecurityManager. > - More obsolete code. Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS). > - Found more obsolete security manager code. > - More purging of AccessController, AccessControlContext and some stackwalking questions. > - David comments. > - Remove some more includes. > - 8341916: Remove ProtectionDomain related hotspot code and tests Changes requested by jrose (Reviewer). src/hotspot/share/classfile/systemDictionary.hpp line 41: > 39: // represented as null. > 40: > 41: // The underlying data structure is an concurrent hash table (Dictionary) per typo: s/an concurrent/a concurrent/ src/hotspot/share/classfile/systemDictionary.hpp line 245: > 243: // compute java_mirror (java.lang.Class instance) for a type ("I", "[[B", "LFoo;", etc.) > 244: // Either the accessing_klass or the CL can be non-null, but not both. > 245: // Callee will fill in CL from the accessing klass, if they are needed. The two comment lines ("Either ? Callee ?") should be one line: + // Callee will fill in CL from the accessing klass, if the CL is needed. src/hotspot/share/prims/jvm.cpp line 169: > 167: while (!vfst.at_end()) { > 168: Method* m = vfst.method(); > 169: if (!vfst.method()->method_holder()->is_subclass_of(vmClasses::ClassLoader_klass())) { We are no longer skipping AC frames, but user code will continue to use AC calls, even if they are silly. Will this affect any existing caller-sensitive calculations? The failure mode would be that a "get-caller-class" query would return AC.class, not the caller of the AC method. ------------- PR Review: https://git.openjdk.org/jdk/pull/22064#pullrequestreview-2440266470 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1844882878 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1844883410 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1844884671 From gziemski at openjdk.org Sat Nov 16 02:57:54 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Sat, 16 Nov 2024 02:57:54 GMT Subject: RFR: 8328944: NMT reports "unknown" memory In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 07:38:24 GMT, Thomas Stuefe wrote: >> We use mtNone value in several functions default parameters, which may show up in NMT reports. >> >> We address this, by removing the default value and forcing, where possible, for the callers to declare NMT tag that reflects the usage. >> >> Eventually the goal would be not to use mtNone anywhere, but we are not there quite yet. >> >> TODO: update copyrights. >> >> Testing: undergoing MARCH5 tier1-5 ... > > src/hotspot/share/cds/metaspaceShared.cpp line 1387: > >> 1385: total_space_rs = ReservedSpace(total_range_size, base_address_alignment, >> 1386: os::vm_page_size(), (char*)base_address, mtClass); >> 1387: } else { > > All the changes here in `MetaspaceShared::reserve_address_space_for_archives` are unnecessary; we tag the address region already. No need to do this multiple times, and in every case branch. The ReservedSpace objects here are not used for much and mostly ephemeral anyway - they are only used to reserve memory here, but after that have not much meaning, and apart from the class space rs don't even survive the invocation. ReservedSpace() requires the client to pass in the `mem_tag` and I think it would be a mistake to allow a default `mtNone` tag here just to avoid setting it. It might be ephemeral, but technically we can and should set it if it's known. > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 249: > >> 247: _bitmap_bytes_per_slice, bitmap_page_size); >> 248: >> 249: ReservedSpace bitmap(_bitmap_size, bitmap_page_size, mtGC); > > remove nmt registration below? Fixed. > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 269: > >> 267: >> 268: if (ShenandoahVerify) { >> 269: ReservedSpace verify_bitmap(_bitmap_size, bitmap_page_size, mtGC); > > remove nmt registration below? Fixed. > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 288: > >> 286: >> 287: ReservedSpace aux_bitmap(_bitmap_size, aux_bitmap_page_size, mtGC); >> 288: os::trace_page_sizes_for_requested_size("Aux Bitmap", > > remove nmt registration below? Fixed. > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 306: > >> 304: >> 305: ReservedSpace region_storage(region_storage_size, region_page_size, mtGC); >> 306: os::trace_page_sizes_for_requested_size("Region Storage", > > remove nmt registration below? Fixed. > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 340: > >> 338: >> 339: if (_collection_set == nullptr) { >> 340: cset_rs = ReservedSpace(cset_size, cset_align, os::vm_page_size(), nullptr, mtGC); > > remove NMT registration in ShenandoahCollectionSet? Fixed. > src/hotspot/share/jfr/recorder/storage/jfrVirtualMemory.cpp line 107: > >> 105: _rs = ReservedSpace(reservation_size_request_bytes, >> 106: os::vm_allocation_granularity(), os::vm_page_size(), >> 107: nullptr, mtTracing); > > remove NMT registraton? Fixed. > src/hotspot/share/memory/heap.cpp line 231: > >> 229: // reserve space for _segmap >> 230: ReservedSpace seg_rs(reserved_segments_size, mtCode); >> 231: if (!_segmap.initialize(seg_rs, committed_segments_size)) { > > remove NMT registration Fixed. > src/hotspot/share/memory/metaspace.cpp line 605: > >> 603: assert(is_aligned(result, Metaspace::reserve_alignment()), "Alignment too small for metaspace"); >> 604: rs = ReservedSpace::space_for_range(result, size, Metaspace::reserve_alignment(), >> 605: os::vm_page_size(), false, false, mtMetaspace); > > Please revert to mtNone; same reason as given in metaspaceShared.cpp. You can add a comment that tags are adjusted afterward, when the distribution of mtClass and mtClassShared is clear. Can we use `mtAllocated` used here? > src/hotspot/share/memory/metaspace.cpp line 746: > >> 744: } >> 745: rs = ReservedSpace(size, Metaspace::reserve_alignment(), >> 746: os::vm_page_size() /* large */, (char*)base, mtMetaspace); > > mtClass, but actually not needed, since we set mtClass below. Again, not necessary to do this for every branch individually we take here when reserving class space memory. Fixed. Since ReservedSpace requires `mem_tag` we need to pass it. > src/hotspot/share/memory/metaspace.cpp line 775: > >> 773: >> 774: // Mark metaspace as such >> 775: MemTracker::record_virtual_memory_tag((address)rs.base(), mtMetaspace); > > No, please revert. mtClass is correct here. Removed `MemTracker::record_virtual_memory_tag()` > src/hotspot/share/memory/metaspace/testHelpers.cpp line 82: > >> 80: // have reserve limit -> non-expandable context >> 81: _rs = ReservedSpace(reserve_limit * BytesPerWord, Metaspace::reserve_alignment(), >> 82: os::vm_page_size(), nullptr, MemTag::mtMetaspace); > > Give this mtTest Fixed. > src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp line 258: > >> 256: ReservedSpace rs(word_size * BytesPerWord, >> 257: Settings::virtual_space_node_reserve_alignment_words() * BytesPerWord, >> 258: os::vm_page_size(), nullptr, mtMetaspace); > > remove tracking below. > > This is actually wrong, and only works out of accident correctly, since this constructor just happens to be called for mtMetaspace; more correct would be to hand in the tag. This is on my plate, there is a JBS issue somewhere. Fixed. > src/hotspot/share/memory/virtualspace.hpp line 50: > >> 48: // ReservedSpace >> 49: ReservedSpace(char* base, size_t size, size_t alignment, >> 50: size_t page_size, bool special, bool executable, MemTag mem_tag); > > The growth in complexity is unfortunate. I think the cost is worth the fact that we mark the memory with a tag as soon as possible, so that we don't catch NMT with its trousers down. > src/hotspot/share/memory/virtualspace.hpp line 67: > >> 65: >> 66: void reserve(size_t size, size_t alignment, size_t page_size, >> 67: char* requested_address, bool executable, MemTag mem_tag); > > Why do the instance methods get MemTag? Why is MemTag not stored as a (const) attribute of ReservedSpace? > > But then, we would have double accounting - we'd store the tag both in NMT and in ReservedSpace instances. If we change them post-reservation, we would need to change both. Sigh. > > So we pass in MemTag just for the ReservedSpace to pass it into os::reserve_memory. Seeing how often ReservedSpace is used in situations where the tag is not clear at reservation time, I wonder whether we are not better off letting the user of ReservedSpace register the NMT tag post reservation like they do today. I like the simplicity of not having to deal with changing the tag afterwards personally. Does anyone else have an opinion here? > src/hotspot/share/nmt/memReporter.cpp line 83: > >> 81: if (mem_tag != mtNone) { >> 82: out->print("(%s" SIZE_FORMAT "%s type=%u", alloc_type, >> 83: amount_in_current_scale(amount), scale, (unsigned)mem_tag); > > No, please revert. Why? Seeing it as a string makes it more human readable. Are we thinking that this output is parsed by tools? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844883480 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844883500 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844883510 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844883526 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844883544 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844883562 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844883605 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844883613 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844884091 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844884520 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844884665 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844884842 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844885543 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844888407 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844888178 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844888695 From fyang at openjdk.org Sat Nov 16 03:00:46 2024 From: fyang at openjdk.org (Fei Yang) Date: Sat, 16 Nov 2024 03:00:46 GMT Subject: RFR: 8344169: RISC-V: Use more meaningful frame::metadata_words where possible In-Reply-To: References: <9XNv_0zgwAVjUaUjVSxFFkwvzUFp3f2Lu8MvPyFv8l8=.d6d9457a-e737-4169-a198-7ea88cfde0db@github.com> Message-ID: On Fri, 15 Nov 2024 14:47:14 GMT, Hamlin Li wrote: >> Hello, please review this RISC-V specific change which improves code readability. >> >> Some background to help understand. We have following frame enumerations in file frame_riscv.hpp: >> >> enum { >> link_offset = -2, >> return_addr_offset = -1, >> sender_sp_offset = 0 >> }; >> >> The values are compatible with the platform ABI and are different from other platforms like x64 and aarch64. Especially, `sender_sp_offset` is 0 for RISC-V compared to 2 for x64 and aarch64. As a result, there exists some differences in places where code calculates fp through offseting pointer sp by value `sender_sp_offset`. For RISC-V, we need to use constant number 2 instead of `sender_sp_offset` as the pointer offset. But the code will be more readable if we use `frame::metadata_words` which has the same value. This change would not affect correctness or functionality in theory. >> >> Testing on linux-riscv64: >> - [x] hotspot:tier1 (release) >> - [x] hotspot_loom & jdk_loom (release & fastdebug) > > src/hotspot/cpu/riscv/frame_riscv.cpp line 156: > >> 154: >> 155: sender_unextended_sp = sender_sp; >> 156: sender_pc = (address) *(sender_sp - 1); > > We have `-1` here, and below `-2` is replaced as frame::metadata_words, seems it's still bit confusing to me. Similar comments to several other places. > But I'm not quite sure what should be the better way to fix it. Thanks for having a look. Yeah, I also witnessed that when making this change and that's also partially the reason why I used constant number 2 instead of `frame::metadata_words` before. But I didn't touch this `-1` in this PR as similar issue is also there for aarch64 and x86 platforms and there doesn't seem to be a proper enum for this purpose. Maybe a separate PR if we want to fix this `-1` for all? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22096#discussion_r1844888709 From gziemski at openjdk.org Sat Nov 16 03:07:45 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Sat, 16 Nov 2024 03:07:45 GMT Subject: RFR: 8328944: NMT reports "unknown" memory In-Reply-To: References: Message-ID: <9g7xAohk4P0MsFU2U319Jp00W-lH6B5BkHFCJwkudc4=.389a332d-64a1-47f8-adab-4373cf1c92cd@github.com> On Mon, 4 Nov 2024 08:23:13 GMT, Thomas Stuefe wrote: >> We use mtNone value in several functions default parameters, which may show up in NMT reports. >> >> We address this, by removing the default value and forcing, where possible, for the callers to declare NMT tag that reflects the usage. >> >> Eventually the goal would be not to use mtNone anywhere, but we are not there quite yet. >> >> TODO: update copyrights. >> >> Testing: undergoing MARCH5 tier1-5 ... > > src/hotspot/share/nmt/memReporter.cpp line 252: > >> 250: // report malloc'd memory >> 251: if (amount_in_current_scale(MAX2(malloc_memory->malloc_size(), pk_malloc)) > 0) { >> 252: print_malloc(malloc_memory->malloc_counter(), mtNMT); > > Please revert, the original was correct. print_malloc is used for both summary and detail reports; for summary, we pass in mtNone deliberately since the report happens under a common tag. I need to look into this further, but I think "mtAllocated" would be better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844890055 From gziemski at openjdk.org Sat Nov 16 03:29:27 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Sat, 16 Nov 2024 03:29:27 GMT Subject: RFR: 8328944: NMT reports "unknown" memory In-Reply-To: References: Message-ID: <22YzSj5_JK4_OVNjoKOSD-kfuEOH78MzSMPJNpkDCaA=.e35389cc-47a4-4780-ab40-a44d681e3ba0@github.com> On Fri, 1 Nov 2024 20:44:50 GMT, Gerard Ziemski wrote: > We use mtNone value in several functions default parameters, which may show up in NMT reports. > > We address this, by removing the default value and forcing, where possible, for the callers to declare NMT tag that reflects the usage. > > Eventually the goal would be not to use mtNone anywhere, but we are not there quite yet. > > TODO: update copyrights. > > Testing: undergoing MARCH5 tier1-5 ... I'm going to put it into draft, since there are things that I need to follow up on, but would like to push my partial changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21843#issuecomment-2480362444 From gziemski at openjdk.org Sat Nov 16 03:29:30 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Sat, 16 Nov 2024 03:29:30 GMT Subject: RFR: 8328944: NMT reports "unknown" memory In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 08:28:29 GMT, Thomas Stuefe wrote: >> We use mtNone value in several functions default parameters, which may show up in NMT reports. >> >> We address this, by removing the default value and forcing, where possible, for the callers to declare NMT tag that reflects the usage. >> >> Eventually the goal would be not to use mtNone anywhere, but we are not there quite yet. >> >> TODO: update copyrights. >> >> Testing: undergoing MARCH5 tier1-5 ... > > src/hotspot/share/nmt/virtualMemoryTracker.cpp line 364: > >> 362: // thread does not detach from VM before exits, and leads to >> 363: // leak JavaThread object >> 364: if ((reserved_rgn->mem_tag() == mtThreadStack) && (reserved_rgn->mem_tag() == mem_tag)) { > > Please explain the changes in this function, especially the changed conditions. The added conditions for tag equality seem wrong to me. Sorry, I think this was just a debugging code that I left it by mistake - I was testing whether we can tighten up the logic of when we allow the tags to be allowed to change, but this looks indeed wrong, since nothing would change. Reverted. > src/hotspot/share/runtime/safepointMechanism.cpp line 61: > >> 59: const size_t page_size = os::vm_page_size(); >> 60: const size_t allocation_size = 2 * page_size; >> 61: char* polling_page = os::reserve_memory(allocation_size, false, mtSafepoint); > > remove registration Fixed. > src/hotspot/share/utilities/debug.cpp line 712: > >> 710: >> 711: void initialize_assert_poison() { >> 712: char* page = os::reserve_memory(os::vm_page_size(), false, mtInternal); > > remove registration Fixed. > test/hotspot/jtreg/runtime/NMT/MallocRoundingReportTest.java line 60: > >> 58: NMTTestUtils.runJcmdSummaryReportAndCheckOutput( >> 59: "Test (reserved=" + numKB + "KB, committed=" + numKB + "KB)", >> 60: "(malloc=" + numKB + "KB type=12 #1) (at peak)" > > Again, this is wrong. The memory had not been reserved for NMT usage, so it should not be tagged with mtNMT (12) Looking into it... > test/hotspot/jtreg/runtime/NMT/MallocRoundingReportTest.java line 68: > >> 66: NMTTestUtils.runJcmdSummaryReportAndCheckOutput( >> 67: "Test (reserved=0KB, committed=0KB)", >> 68: "(malloc=0KB type=12) (peak=" + numKB + "KB #1)" > > ditto Looking into it... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844890480 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844890575 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844890617 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844890676 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1844890710 From jrose at openjdk.org Sat Nov 16 03:29:32 2024 From: jrose at openjdk.org (John R Rose) Date: Sat, 16 Nov 2024 03:29:32 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v6] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 23:43:33 GMT, Coleen Phillimore wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Handle merge conflicts in new resolve_instance_class calls. > - Merge branch 'master' into protection-domain > - Purge last references to SecurityManager. > - More obsolete code. Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS). > - Found more obsolete security manager code. > - More purging of AccessController, AccessControlContext and some stackwalking questions. > - David comments. > - Remove some more includes. > - 8341916: Remove ProtectionDomain related hotspot code and tests Except for a couple of suggested tweaks to comments, it all looks correct. Thanks! ------------- Marked as reviewed by jrose (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22064#pullrequestreview-2440284811 From jrose at openjdk.org Sat Nov 16 03:29:33 2024 From: jrose at openjdk.org (John R Rose) Date: Sat, 16 Nov 2024 03:29:33 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v6] In-Reply-To: <7I8Yw-5pVWAHnlsEIVKq54gRMuLHd0K3l7zSdKJH9L8=.5ab13bd7-9c27-4bda-9a60-8bd30c9a6fd6@github.com> References: <7I8Yw-5pVWAHnlsEIVKq54gRMuLHd0K3l7zSdKJH9L8=.5ab13bd7-9c27-4bda-9a60-8bd30c9a6fd6@github.com> Message-ID: On Sat, 16 Nov 2024 02:48:09 GMT, John R Rose wrote: >> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: >> >> - Handle merge conflicts in new resolve_instance_class calls. >> - Merge branch 'master' into protection-domain >> - Purge last references to SecurityManager. >> - More obsolete code. Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS). >> - Found more obsolete security manager code. >> - More purging of AccessController, AccessControlContext and some stackwalking questions. >> - David comments. >> - Remove some more includes. >> - 8341916: Remove ProtectionDomain related hotspot code and tests > > src/hotspot/share/prims/jvm.cpp line 169: > >> 167: while (!vfst.at_end()) { >> 168: Method* m = vfst.method(); >> 169: if (!vfst.method()->method_holder()->is_subclass_of(vmClasses::ClassLoader_klass())) { > > We are no longer skipping AC frames, but user code will continue to use AC calls, even if they are silly. Will this affect any existing caller-sensitive calculations? The failure mode would be that a "get-caller-class" query would return AC.class, not the caller of the AC method. (Wait, I think my comment is in the wrong place. This is just tracing code, but I thought I saw a similar change for the general walker code?) Right, cancel the previous comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1844892667 From lmesnik at openjdk.org Sat Nov 16 05:21:40 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 16 Nov 2024 05:21:40 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v3] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: make test more robust ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/93229db3..0fb641c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=01-02 Stats: 35 lines in 3 files changed: 21 ins; 1 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From coleenp at openjdk.org Sat Nov 16 14:25:30 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 16 Nov 2024 14:25:30 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v7] In-Reply-To: References: Message-ID: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22064/files - new: https://git.openjdk.org/jdk/pull/22064/files/14e11e59..dd1766ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=05-06 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22064/head:pull/22064 PR: https://git.openjdk.org/jdk/pull/22064 From coleenp at openjdk.org Sat Nov 16 14:25:32 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 16 Nov 2024 14:25:32 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v6] In-Reply-To: <7I8Yw-5pVWAHnlsEIVKq54gRMuLHd0K3l7zSdKJH9L8=.5ab13bd7-9c27-4bda-9a60-8bd30c9a6fd6@github.com> References: <7I8Yw-5pVWAHnlsEIVKq54gRMuLHd0K3l7zSdKJH9L8=.5ab13bd7-9c27-4bda-9a60-8bd30c9a6fd6@github.com> Message-ID: On Sat, 16 Nov 2024 02:41:59 GMT, John R Rose wrote: >> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: >> >> - Handle merge conflicts in new resolve_instance_class calls. >> - Merge branch 'master' into protection-domain >> - Purge last references to SecurityManager. >> - More obsolete code. Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS). >> - Found more obsolete security manager code. >> - More purging of AccessController, AccessControlContext and some stackwalking questions. >> - David comments. >> - Remove some more includes. >> - 8341916: Remove ProtectionDomain related hotspot code and tests > > src/hotspot/share/classfile/systemDictionary.hpp line 41: > >> 39: // represented as null. >> 40: >> 41: // The underlying data structure is an concurrent hash table (Dictionary) per > > typo: s/an concurrent/a concurrent/ Fixed. > src/hotspot/share/classfile/systemDictionary.hpp line 245: > >> 243: // compute java_mirror (java.lang.Class instance) for a type ("I", "[[B", "LFoo;", etc.) >> 244: // Either the accessing_klass or the CL can be non-null, but not both. >> 245: // Callee will fill in CL from the accessing klass, if they are needed. > > The two comment lines ("Either ? Callee ?") should be one line: > > > + // Callee will fill in CL from the accessing klass, if the CL is needed. One line would be too long and the comment doesn't make any sense anyway. The accessing_klass is never null and the callee doesn't do anything with the class loader, ie it doesn't pass it in. So I deleted the last two comment lines. We should clean this up later to reflect reality. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1844986641 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1844986893 From coleenp at openjdk.org Sat Nov 16 14:25:33 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 16 Nov 2024 14:25:33 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v6] In-Reply-To: References: <7I8Yw-5pVWAHnlsEIVKq54gRMuLHd0K3l7zSdKJH9L8=.5ab13bd7-9c27-4bda-9a60-8bd30c9a6fd6@github.com> Message-ID: On Sat, 16 Nov 2024 03:22:01 GMT, John R Rose wrote: >> src/hotspot/share/prims/jvm.cpp line 169: >> >>> 167: while (!vfst.at_end()) { >>> 168: Method* m = vfst.method(); >>> 169: if (!vfst.method()->method_holder()->is_subclass_of(vmClasses::ClassLoader_klass())) { >> >> We are no longer skipping AC frames, but user code will continue to use AC calls, even if they are silly. Will this affect any existing caller-sensitive calculations? The failure mode would be that a "get-caller-class" query would return AC.class, not the caller of the AC method. > > (Wait, I think my comment is in the wrong place. This is just tracing code, but I thought I saw a similar change for the general walker code?) > > Right, cancel the previous comment. Yes, we still have the security stack walk without this using the caller sensitive mechanism. This was only for logging. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1844986976 From kdnilsen at openjdk.org Sat Nov 16 17:57:01 2024 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sat, 16 Nov 2024 17:57:01 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Wed, 13 Nov 2024 23:21:24 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp line 83: >> >>> 81: void VM_ShenandoahInitMark::doit() { >>> 82: ShenandoahGCPauseMark mark(_gc_id, "Init Mark", SvcGCMarker::CONCURRENT); >>> 83: set_active_generation(); >> >> Why is it here, and not down in `entry_*` methods, probably in helper classes? > > I think it's here for the same reason `propagate_gc_state_to_java_threads` is here. Having it here makes it easier to see that this critical synchronization step happens for every safepoint. I'm inclined to leave as is, not wanting to disrupt stability of code that is known to be working. But if there is strong preference otherwise, we can make a change... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1845149976 From syan at openjdk.org Sun Nov 17 01:57:50 2024 From: syan at openjdk.org (SendaoYan) Date: Sun, 17 Nov 2024 01:57:50 GMT Subject: RFR: 8340969: jdk/jfr/startupargs/TestStartDuration.java should be marked as flagless In-Reply-To: References: Message-ID: On Sat, 28 Sep 2024 01:02:12 GMT, Leonid Mesnik wrote: > Test jdk/jfr/startupargs/TestStartDuration.java > checks duration, the time might be too small for stress options like Xcomp. > So it makes sense to mark it as flaglesss. Marked as reviewed by syan (Committer). We observed the same failure by [dragonwell17](https://github.com/dragonwell-project/dragonwell17/issues/171) ------------- PR Review: https://git.openjdk.org/jdk/pull/21237#pullrequestreview-2440836022 PR Comment: https://git.openjdk.org/jdk/pull/21237#issuecomment-2480886977 From fyang at openjdk.org Mon Nov 18 03:02:53 2024 From: fyang at openjdk.org (Fei Yang) Date: Mon, 18 Nov 2024 03:02:53 GMT Subject: RFR: 8344010: RISC-V: Zacas do not work with LW locking In-Reply-To: <9zxKdn73DHLKXicGNz8Wygje-qKJMlvy4sTcKz3che8=.ee30bec8-f557-4436-9e77-70d5a06e3590@github.com> References: <9zxKdn73DHLKXicGNz8Wygje-qKJMlvy4sTcKz3che8=.ee30bec8-f557-4436-9e77-70d5a06e3590@github.com> Message-ID: On Fri, 15 Nov 2024 13:01:37 GMT, Robbin Ehn wrote: > Hi all, please consider. > > Light weight locking fails: > - We need to add cas acquire. > - Register _result_ may shadow _new_val_ (same register). > (NOTE this second item can effect many other cases, unclear) > > As the code becomes much cleaner by calling amocas_d/w directly I removed the aliases. > Which fixes the first issue with cas acquire. > > By using t0 instead of _result_ we fix the other issue. > > This is a short bugfix, there are so many dragons here that I do not want to address them while fixing the bug. > There are also several performance optimizations we can do here, specially for LR/SC case. > So I'll do a couple of more iterations of this code in seperate PR's. > > Testing a bunch of local cherry-picked tests which failed. > I'll start tier1 over the weekend. > > Thanks, Robbin Good catch. Thanks for carrying out the test. Looks good modulo one minor question. src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 3533: > 3531: cmpxchg(addr, expected, new_val, size, acquire, release, result, true); > 3532: return; > 3533: } Question: Should we move the code after the three assertions? I see same assertions are there in `MacroAssembler::cmpxchg` as well. Even though they are the same for now, I assume they are targeting different code and are submit to change in the future. ------------- PR Review: https://git.openjdk.org/jdk/pull/22149#pullrequestreview-2441399914 PR Review Comment: https://git.openjdk.org/jdk/pull/22149#discussion_r1845788735 From dholmes at openjdk.org Mon Nov 18 03:04:48 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 18 Nov 2024 03:04:48 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v7] In-Reply-To: References: Message-ID: On Sat, 16 Nov 2024 14:25:30 GMT, Coleen Phillimore wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments. Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22064#pullrequestreview-2441407116 From dholmes at openjdk.org Mon Nov 18 03:04:49 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 18 Nov 2024 03:04:49 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v5] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 12:04:37 GMT, Coleen Phillimore wrote: >> src/hotspot/share/prims/jvm.cpp line 154: >> >>> 152: */ >>> 153: >>> 154: extern void trace_class_resolution(Klass* to_class) { >> >> why `extern` ? > > jni.cpp functions call this. I don't see any difference in the callers in relation to this PR and the function is not presently declared `extern`. ?? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1845791576 From dholmes at openjdk.org Mon Nov 18 05:37:55 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 18 Nov 2024 05:37:55 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v3] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: On Sat, 16 Nov 2024 05:21:40 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > make test more robust Just a couple of drive-by comments/suggestions. The functionality seems like a reasonable addition. Thanks src/hotspot/share/prims/whitebox.cpp line 190: > 188: WB_END > 189: > 190: WB_ENTRY(jint, WB_LockAndStuckInSafepoint(JNIEnv* env, jobject wb)) Suggestion: WB_ENTRY(jint, WB_TakeLockAndHangInSafepoint(JNIEnv* env, jobject wb)) src/hotspot/share/runtime/vmOperations.hpp line 64: > 62: > 63: // used by whitebox API to emulate VM issues > 64: // when VM can't operate and doesn't respond to jcm Suggestion: // when VM can't operate and doesn't respond to jcmd src/hotspot/share/runtime/vmOperations.hpp line 65: > 63: // used by whitebox API to emulate VM issues > 64: // when VM can't operate and doesn't respond to jcm > 65: class VM_ForceSafepointStuck: public VM_Operation { Suggestion: class VM_HangInSafepoint: public VM_Operation { src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Mutex.java line 70: > 68: public String name() { return CStringUtilities.getString(addr.getAddressAt(nameFieldOffset)); } > 69: > 70: public Address owner() { return addr.getAddressAt(ownerFieldOffset); } Printing the `osThread()->thread_id()` might be more useful than printing the address. ------------- PR Review: https://git.openjdk.org/jdk/pull/22171#pullrequestreview-2441565041 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1845903441 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1845900385 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1845900921 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1845902671 From dholmes at openjdk.org Mon Nov 18 05:43:44 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 18 Nov 2024 05:43:44 GMT Subject: RFR: 8344247: Move objectWaiter field to VirtualThread instance In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 22:34:24 GMT, Patricio Chilano Mateo wrote: > Small follow-up change after JDK-8338383. This moves the `objectWaiter` field from the stackChunk to the VirtualThread instance. Only the top stackChunk uses this field so we could save some memory by just saving it in the virtual thread instance instead. Also, related methods `stackChunkOopDesc::current_pending_monitor` and `stackChunkOopDesc::current_waiting_monitor` are moved to the `java_lang_VirtualThread` class where they naturally belong, since these are the equivalent of the JavaThread methods but for an unmounted vthread. > Tested by running mach5 tiers1-3. > > Thanks, > Patricio LGTM! Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22124#pullrequestreview-2441576476 From sjayagond at openjdk.org Mon Nov 18 06:12:00 2024 From: sjayagond at openjdk.org (Sidraya Jayagond) Date: Mon, 18 Nov 2024 06:12:00 GMT Subject: RFR: 8327652: S390x: Implements SLP support [v12] In-Reply-To: References: Message-ID: On Mon, 14 Oct 2024 09:07:53 GMT, Sidraya Jayagond wrote: >> This PR Adds SIMD support on s390x. > > Sidraya Jayagond has updated the pull request incrementally with one additional commit since the last revision: > > Disable vector instructions from string intrinsics > > Address Lutz's comments. > Disable vector instructions from string intrinsics will be > enabled once PR to JDK-8336356 gets integrates. Thank you for the reviews. I am integrating now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18162#issuecomment-2482035171 From duke at openjdk.org Mon Nov 18 06:12:00 2024 From: duke at openjdk.org (duke) Date: Mon, 18 Nov 2024 06:12:00 GMT Subject: RFR: 8327652: S390x: Implements SLP support [v12] In-Reply-To: References: Message-ID: On Mon, 14 Oct 2024 09:07:53 GMT, Sidraya Jayagond wrote: >> This PR Adds SIMD support on s390x. > > Sidraya Jayagond has updated the pull request incrementally with one additional commit since the last revision: > > Disable vector instructions from string intrinsics > > Address Lutz's comments. > Disable vector instructions from string intrinsics will be > enabled once PR to JDK-8336356 gets integrates. @sid8606 Your change (at version 8a96bf73baba57ab000a31dbdb5a5ac3756cc31d) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18162#issuecomment-2482037753 From sjayagond at openjdk.org Mon Nov 18 06:53:56 2024 From: sjayagond at openjdk.org (Sidraya Jayagond) Date: Mon, 18 Nov 2024 06:53:56 GMT Subject: Integrated: 8327652: S390x: Implements SLP support In-Reply-To: References: Message-ID: <_5qZGglSqEjtdquqAQuj5WN1HYbPehCNDcJewwhrh7Y=.7caf896b-4f96-45bd-beff-ccf0b63a4836@github.com> On Fri, 8 Mar 2024 05:05:31 GMT, Sidraya Jayagond wrote: > This PR Adds SIMD support on s390x. This pull request has now been integrated. Changeset: 92b26317 Author: Sidraya Jayagond URL: https://git.openjdk.org/jdk/commit/92b26317d444fc63c8b229dfabd2cddd838b9fe4 Stats: 1162 lines in 17 files changed: 1072 ins; 14 del; 76 mod 8327652: S390x: Implements SLP support Reviewed-by: amitkumar, lucy, mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/18162 From rehn at openjdk.org Mon Nov 18 07:23:54 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 18 Nov 2024 07:23:54 GMT Subject: RFR: 8344010: RISC-V: Zacas do not work with LW locking In-Reply-To: References: <9zxKdn73DHLKXicGNz8Wygje-qKJMlvy4sTcKz3che8=.ee30bec8-f557-4436-9e77-70d5a06e3590@github.com> Message-ID: <6Zq1Wrq3yMbCbcge6AzickFhY9pRDo0E6UchPlKJtQ0=.ec6c17fa-fb1e-467c-9a80-00d0d445d6f4@github.com> On Mon, 18 Nov 2024 02:57:39 GMT, Fei Yang wrote: >> Hi all, please consider. >> >> Light weight locking fails: >> - We need to add cas acquire. >> - Register _result_ may shadow _new_val_ (same register). >> (NOTE this second item can effect many other cases, unclear) >> >> As the code becomes much cleaner by calling amocas_d/w directly I removed the aliases. >> Which fixes the first issue with cas acquire. >> >> By using t0 instead of _result_ we fix the other issue. >> >> This is a short bugfix, there are so many dragons here that I do not want to address them while fixing the bug. >> There are also several performance optimizations we can do here, specially for LR/SC case. >> So I'll do a couple of more iterations of this code in seperate PR's. >> >> Testing a bunch of local cherry-picked tests which failed. >> I'll start tier1 over the weekend. >> >> Thanks, Robbin > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 3533: > >> 3531: cmpxchg(addr, expected, new_val, size, acquire, release, result, true); >> 3532: return; >> 3533: } > > Question: Should we move the code after the three assertions? I see same assertions are there in `MacroAssembler::cmpxchg` as well. Even though they are the same for now, I assume they are targeting different code and are submit to change in the future. The reason to move it after is readability. By having the zacas code before the asserts you think the implied contract the asserts states do not apply to zacas case. Meaning that, at least I, read the code as addr, expected, new_val may be t0 when UseZacas is true. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22149#discussion_r1845999549 From rehn at openjdk.org Mon Nov 18 07:27:56 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 18 Nov 2024 07:27:56 GMT Subject: RFR: 8344010: RISC-V: Zacas do not work with LW locking In-Reply-To: References: <9zxKdn73DHLKXicGNz8Wygje-qKJMlvy4sTcKz3che8=.ee30bec8-f557-4436-9e77-70d5a06e3590@github.com> Message-ID: On Mon, 18 Nov 2024 02:59:18 GMT, Fei Yang wrote: > Good catch. Thanks for carrying out the test. Looks good modulo one minor question. Thanks! I found some failures in testing, investigating. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22149#issuecomment-2482143963 From xpeng at openjdk.org Mon Nov 18 08:55:20 2024 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 18 Nov 2024 08:55:20 GMT Subject: RFR: 8343541: C1: Plain memory accesses are emitted with membars with +AlwaysAtomicAccesses Message-ID: C1 and C2 has quite difference implementation for `+AlwaysAtomicAccesses`, [C2 impl](https://github.com/openjdk/jdk/blob/4a7ce1d7c1bd4b751063b98cf8bedcd27055760b/src/hotspot/share/gc/shared/c2/barrierSetC2.cpp#L410) only guarantee atomicity hence no membars are emitted, but C1 treats it same as volatile access hence it emits membars. The change remove the unnecessary membars in C1 for `+AlwaysAtomicAccesses`. The test have been verified by very simple JMH benchmarks to measure the latency of reading/writing long/volatile long variable 10000 times, and run with VM option `-XX:TieredStopAtLevel=3 -XX:+UnlockExperimentalVMOptions -XX:+AlwaysAtomicAccesses`: Before the fix: Benchmark Mode Cnt Score Error Units AlwaysAtomicAccesses.testReadLong avgt 5 58711.131 ? 716.940 ns/op AlwaysAtomicAccesses.testReadVolatileLong avgt 5 59014.735 ? 675.354 ns/op AlwaysAtomicAccesses.testWriteLong avgt 5 115817.978 ? 302.089 ns/op AlwaysAtomicAccesses.testWriteVolatileLong avgt 5 116317.835 ? 1451.365 ns/op After the fix: Benchmark Mode Cnt Score Error Units AlwaysAtomicAccesses.testReadLong avgt 5 49651.527 ? 159.948 ns/op AlwaysAtomicAccesses.testReadVolatileLong avgt 5 58668.844 ? 316.029 ns/op AlwaysAtomicAccesses.testWriteLong avgt 5 23008.361 ? 10.947 ns/op AlwaysAtomicAccesses.testWriteVolatileLong avgt 5 116440.017 ? 1240.832 ns/op ------------- Commit messages: - 8343541: C1: Plain memory accesses are emitted with membars with +AlwaysAtomicAccesses Changes: https://git.openjdk.org/jdk/pull/22191/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22191&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343541 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22191.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22191/head:pull/22191 PR: https://git.openjdk.org/jdk/pull/22191 From shade at openjdk.org Mon Nov 18 09:21:42 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 18 Nov 2024 09:21:42 GMT Subject: RFR: 8343541: C1: Plain memory accesses are emitted with membars with +AlwaysAtomicAccesses In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 07:27:03 GMT, Xiaolong Peng wrote: > C1 and C2 has different implementations for `+AlwaysAtomicAccesses`, [C2 impl](https://github.com/openjdk/jdk/blob/4a7ce1d7c1bd4b751063b98cf8bedcd27055760b/src/hotspot/share/gc/shared/c2/barrierSetC2.cpp#L410) only guarantees atomicity hence no membars are emitted for plain memory access, but C1 treats it same as volatile access hence it emits membars. The change removes the unnecessary membars in C1 for `+AlwaysAtomicAccesses`. > > The test have been verified by very simple JMH benchmarks to measure the latency of reading/writing long/volatile long variable 10000 times, and run with VM option `-XX:TieredStopAtLevel=3 -XX:+UnlockExperimentalVMOptions -XX:+AlwaysAtomicAccesses`: > > Before the fix: > > Benchmark Mode Cnt Score Error Units > AlwaysAtomicAccesses.testReadLong avgt 5 58711.131 ? 716.940 ns/op > AlwaysAtomicAccesses.testReadVolatileLong avgt 5 59014.735 ? 675.354 ns/op > AlwaysAtomicAccesses.testWriteLong avgt 5 115817.978 ? 302.089 ns/op > AlwaysAtomicAccesses.testWriteVolatileLong avgt 5 116317.835 ? 1451.365 ns/op > > > After the fix: > > Benchmark Mode Cnt Score Error Units > AlwaysAtomicAccesses.testReadLong avgt 5 49651.527 ? 159.948 ns/op > AlwaysAtomicAccesses.testReadVolatileLong avgt 5 58668.844 ? 316.029 ns/op > AlwaysAtomicAccesses.testWriteLong avgt 5 23008.361 ? 10.947 ns/op > AlwaysAtomicAccesses.testWriteVolatileLong avgt 5 116440.017 ? 1240.832 ns/op It is a bit sad that we call `volatile_field_*` when we really mean atomic. But renaming that would lead to much deeper changes. So I am okay with doing just this, thanks. src/hotspot/share/gc/shared/c1/barrierSetC1.cpp line 144: > 142: DecoratorSet decorators = access.decorators(); > 143: bool is_volatile = (decorators & MO_SEQ_CST) != 0; > 144: bool is_atomic_access = is_volatile || AlwaysAtomicAccesses; Can be just `is_atomic`, I think. ------------- PR Review: https://git.openjdk.org/jdk/pull/22191#pullrequestreview-2441950318 PR Review Comment: https://git.openjdk.org/jdk/pull/22191#discussion_r1846146160 From xpeng at openjdk.org Mon Nov 18 09:30:54 2024 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 18 Nov 2024 09:30:54 GMT Subject: RFR: 8343541: C1: Plain memory accesses are emitted with membars with +AlwaysAtomicAccesses [v2] In-Reply-To: References: Message-ID: <9sZDi_ahHbkCWc7QRukVh7m8bvWbkRUvbtbG7FgkSc4=.714aac97-ace8-4357-846f-ed2e2b1f176d@github.com> > C1 and C2 has different implementations for `+AlwaysAtomicAccesses`, [C2 impl](https://github.com/openjdk/jdk/blob/4a7ce1d7c1bd4b751063b98cf8bedcd27055760b/src/hotspot/share/gc/shared/c2/barrierSetC2.cpp#L410) only guarantees atomicity hence no membars are emitted for plain memory access, but C1 treats it same as volatile access hence it emits membars. The change removes the unnecessary membars in C1 for `+AlwaysAtomicAccesses`. > > The test have been verified by very simple JMH benchmarks to measure the latency of reading/writing long/volatile long variable 10000 times, and run with VM option `-XX:TieredStopAtLevel=3 -XX:+UnlockExperimentalVMOptions -XX:+AlwaysAtomicAccesses`: > > Before the fix: > > Benchmark Mode Cnt Score Error Units > AlwaysAtomicAccesses.testReadLong avgt 5 58711.131 ? 716.940 ns/op > AlwaysAtomicAccesses.testReadVolatileLong avgt 5 59014.735 ? 675.354 ns/op > AlwaysAtomicAccesses.testWriteLong avgt 5 115817.978 ? 302.089 ns/op > AlwaysAtomicAccesses.testWriteVolatileLong avgt 5 116317.835 ? 1451.365 ns/op > > > After the fix: > > Benchmark Mode Cnt Score Error Units > AlwaysAtomicAccesses.testReadLong avgt 5 49651.527 ? 159.948 ns/op > AlwaysAtomicAccesses.testReadVolatileLong avgt 5 58668.844 ? 316.029 ns/op > AlwaysAtomicAccesses.testWriteLong avgt 5 23008.361 ? 10.947 ns/op > AlwaysAtomicAccesses.testWriteVolatileLong avgt 5 116440.017 ? 1240.832 ns/op Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: renaming ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22191/files - new: https://git.openjdk.org/jdk/pull/22191/files/8a532737..df0fc908 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22191&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22191&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22191.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22191/head:pull/22191 PR: https://git.openjdk.org/jdk/pull/22191 From xpeng at openjdk.org Mon Nov 18 09:30:55 2024 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 18 Nov 2024 09:30:55 GMT Subject: RFR: 8343541: C1: Plain memory accesses are emitted with membars with +AlwaysAtomicAccesses [v2] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 09:16:05 GMT, Aleksey Shipilev wrote: >> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> renaming > > src/hotspot/share/gc/shared/c1/barrierSetC1.cpp line 144: > >> 142: DecoratorSet decorators = access.decorators(); >> 143: bool is_volatile = (decorators & MO_SEQ_CST) != 0; >> 144: bool is_atomic_access = is_volatile || AlwaysAtomicAccesses; > > Can be just `is_atomic`, I think. Thanks, fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22191#discussion_r1846164694 From xpeng at openjdk.org Mon Nov 18 09:33:10 2024 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 18 Nov 2024 09:33:10 GMT Subject: RFR: 8343541: C1: Plain memory accesses are emitted with membars with +AlwaysAtomicAccesses [v2] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 09:18:19 GMT, Aleksey Shipilev wrote: > It is a bit sad that we call `volatile_field_*` when we really mean atomic. But renaming that would lead to much deeper changes. So I am okay with doing just this, thanks. I'll fix it, it is not too deep, and they are only used by barrierSetC1.cpp ------------- PR Comment: https://git.openjdk.org/jdk/pull/22191#issuecomment-2482407035 From shade at openjdk.org Mon Nov 18 09:39:58 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 18 Nov 2024 09:39:58 GMT Subject: RFR: 8343541: C1: Plain memory accesses are emitted with membars with +AlwaysAtomicAccesses [v2] In-Reply-To: <9sZDi_ahHbkCWc7QRukVh7m8bvWbkRUvbtbG7FgkSc4=.714aac97-ace8-4357-846f-ed2e2b1f176d@github.com> References: <9sZDi_ahHbkCWc7QRukVh7m8bvWbkRUvbtbG7FgkSc4=.714aac97-ace8-4357-846f-ed2e2b1f176d@github.com> Message-ID: On Mon, 18 Nov 2024 09:30:54 GMT, Xiaolong Peng wrote: >> C1 and C2 has different implementations for `+AlwaysAtomicAccesses`, [C2 impl](https://github.com/openjdk/jdk/blob/4a7ce1d7c1bd4b751063b98cf8bedcd27055760b/src/hotspot/share/gc/shared/c2/barrierSetC2.cpp#L410) only guarantees atomicity hence no membars are emitted for plain memory access, but C1 treats it same as volatile access hence it emits membars. The change removes the unnecessary membars in C1 for `+AlwaysAtomicAccesses`. >> >> The test have been verified by very simple JMH benchmarks to measure the latency of reading/writing long/volatile long variable 10000 times, and run with VM option `-XX:TieredStopAtLevel=3 -XX:+UnlockExperimentalVMOptions -XX:+AlwaysAtomicAccesses`: >> >> Before the fix: >> >> Benchmark Mode Cnt Score Error Units >> AlwaysAtomicAccesses.testReadLong avgt 5 58711.131 ? 716.940 ns/op >> AlwaysAtomicAccesses.testReadVolatileLong avgt 5 59014.735 ? 675.354 ns/op >> AlwaysAtomicAccesses.testWriteLong avgt 5 115817.978 ? 302.089 ns/op >> AlwaysAtomicAccesses.testWriteVolatileLong avgt 5 116317.835 ? 1451.365 ns/op >> >> >> After the fix: >> >> Benchmark Mode Cnt Score Error Units >> AlwaysAtomicAccesses.testReadLong avgt 5 49651.527 ? 159.948 ns/op >> AlwaysAtomicAccesses.testReadVolatileLong avgt 5 58668.844 ? 316.029 ns/op >> AlwaysAtomicAccesses.testWriteLong avgt 5 23008.361 ? 10.947 ns/op >> AlwaysAtomicAccesses.testWriteVolatileLong avgt 5 116440.017 ? 1240.832 ns/op > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > renaming ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22191#pullrequestreview-2442001373 From shade at openjdk.org Mon Nov 18 09:39:58 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 18 Nov 2024 09:39:58 GMT Subject: RFR: 8343541: C1: Plain memory accesses are emitted with membars with +AlwaysAtomicAccesses [v2] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 09:30:25 GMT, Xiaolong Peng wrote: > > It is a bit sad that we call `volatile_field_*` when we really mean atomic. But renaming that would lead to much deeper changes. So I am okay with doing just this, thanks. > > I'll fix it, it is not too deep, and they are only used by barrierSetC1.cpp No need. If we go down that road, we also want to rename `lir_move_volatile` and all that jazz, which would probably entail a few rounds of careful looking. Submit a follow-up issue for it instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22191#issuecomment-2482422228 From xpeng at openjdk.org Mon Nov 18 09:39:59 2024 From: xpeng at openjdk.org (Xiaolong Peng) Date: Mon, 18 Nov 2024 09:39:59 GMT Subject: RFR: 8343541: C1: Plain memory accesses are emitted with membars with +AlwaysAtomicAccesses [v2] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 09:36:51 GMT, Aleksey Shipilev wrote: > > It is a bit sad that we call `volatile_field_*` when we really mean atomic. But renaming that would lead to much deeper changes. So I am okay with doing just this, thanks. > > I'll fix it, it is not too deep, and they are only used by barrierSetC1.cpp You are right, checked the related code, need to update the chain deep to LIR_Assembler, I'll leave them unchanged except if it is really necessary. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22191#issuecomment-2482422778 From ihse at openjdk.org Mon Nov 18 10:25:56 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 18 Nov 2024 10:25:56 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v11] In-Reply-To: <2EQObSBYG9ZtB0qDRKvYjERfxkYKTlGAlQ9JVEj9zYg=.61c7c77a-746a-4c30-9c58-dfb564ecf24d@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com> <2PNXRviwavdaWvhjoHUOC8iwQzeF7zub2JoHjfj9wiI=.f502c575-ffc7-4570-891e-4c61b89c1cf4@github.com> <2EQObSBYG9ZtB0qDRKvYjERfxkYKTlGAlQ9JVEj9zYg=.61c7c77a-746a-4c30-9c58-dfb564ecf24d@github.com> Message-ID: <9hxLf3Da2FuthkQQ_rWuy15NcB6mv8qN6a0H2Figd54=.e6f301da-8351-4aa7-acf3-533e6cdf5857@github.com> On Wed, 16 Oct 2024 07:39:06 GMT, Magnus Ihse Bursie wrote: >> Yes, I just pushed a commit that does that. I have manually inspected the values and it looks sane, but I need to verify it on our CI system as well. The reasoning for us setting some of the ld flags are less than clear, so it is a bit hard to tell if they should be included or not. > > This change started to expose some other problems as well. I'll need to work a bit more on getting this right. The "other problems" I noted where not related to the `LDFLAGS_STATIC_JDK` fix, so this part should be okay now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1846311675 From ihse at openjdk.org Mon Nov 18 10:42:33 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 18 Nov 2024 10:42:33 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v12] In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: <90EUZdTLd7PXDJxlcyHtNLEmLffK7xQoKCs7qWZM858=.599310f0-d23f-4cbc-bd26-5eb7d857638d@github.com> > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary change for macOS in java_md.c ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20837/files - new: https://git.openjdk.org/jdk/pull/20837/files/0e5ff083..922d7e76 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=10-11 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20837.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837 PR: https://git.openjdk.org/jdk/pull/20837 From ihse at openjdk.org Mon Nov 18 10:42:33 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 18 Nov 2024 10:42:33 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v7] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: <9DaE4BsBl9ygp4bZVE1owYJVc129QRVFgXX3ZGC_sqs=.e6358bb4-2e36-43dd-ade9-fb8ef0f3c775@github.com> On Mon, 21 Oct 2024 13:07:34 GMT, Magnus Ihse Bursie wrote: >> src/java.base/unix/native/libjli/java_md.c line 279: >> >>> 277: char jvmpath[], jint so_jvmpath, >>> 278: char jvmcfg[], jint so_jvmcfg) { >>> 279: /* Compute/set the name of the executable. This is needed for macOS. */ >> >> But this file is not used when on macOS, is it? (cfr java_md_macosx.m) ) > > Hm. I think both are used? I'll need to double-check that. You are right. Don't know how this got in here, I must have thought it needed at some point when trying to get this to work on macOS. This really is a sign that I've been doing cargo-cult programming. The entire JDK bootstrapping mechanism is so spread-out and difficult to follow that it ends up being more "poke a bit here and see if it works" kind of programming instead of understanding what needs to be done and doing it. We should really make a follow-up refactoring on this to get it to a better state, across all modules and components... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1846348477 From amitkumar at openjdk.org Mon Nov 18 10:47:19 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 18 Nov 2024 10:47:19 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known Message-ID: Adds SaveLiveRegister portion for vector registers also. Depends on https://github.com/openjdk/jdk/pull/22190. Once that PR gets integrated, will rebase and mark it ready for review. ------------- Commit messages: - no more ignoring vector registers Changes: https://git.openjdk.org/jdk/pull/22197/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22197&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344381 Stats: 15 lines in 1 file changed: 11 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22197.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22197/head:pull/22197 PR: https://git.openjdk.org/jdk/pull/22197 From ihse at openjdk.org Mon Nov 18 10:49:49 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 18 Nov 2024 10:49:49 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v9] In-Reply-To: <4TglRts9KEQcf0NHTe2LvbzxSK9w5PoaEcIQhP-7fD8=.815bf1da-830d-4035-95bf-1916322f9567@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> <4TglRts9KEQcf0NHTe2LvbzxSK9w5PoaEcIQhP-7fD8=.815bf1da-830d-4035-95bf-1916322f9567@github.com> Message-ID: <8pjs3UQ6kUD7MB-FwKrINVyKt2iqHPvpB_Wo3pGuDg0=.0fddc8b7-0985-4e0b-8ee2-26bbb0cc75c9@github.com> On Wed, 13 Nov 2024 01:40:23 GMT, Jiangli Zhou wrote: >> @jianglizhou Thank you for your assistance in figuring out the problem. I guess I throw out too much code from the hermetic-java-runtime branch when trying to minimize the changes to only build-related stuff. The jimage changes were so busy so I probably ignored them a bit too much. > > @magicus Just want to check if there's anything that you are waiting from me for this PR. My understanding is that you'll update the PR to fix the incremental build and debuginfo before the last review iteration. Please let me know if there are anything else. Thanks! @jianglizhou > I think we would need to decide what is the dll_dir with the static JDK support and hermetic support. >From my understanding, `_sun_boot_library_path` does not have any meaning when running with static builds. As I said before, I think we really ought to take a step back, consider the wider picture, and refactor the way we interact with internal native libraries. Determining how to handle `_sun_boot_library_path` for static builds are definitely part of that work. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2482664528 From mgronlun at openjdk.org Mon Nov 18 10:56:00 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 18 Nov 2024 10:56:00 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v2] In-Reply-To: References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: On Tue, 12 Nov 2024 11:41:49 GMT, Thomas Stuefe wrote: >> Perhaps @tstuefe would be kind to take a look? > > @mgronlun Sure, I can take a look. Did the POSIX version change at all or is it just code movement? @tstuefe you ok with this, Thomas? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21994#issuecomment-2482677295 From ihse at openjdk.org Mon Nov 18 11:10:08 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 18 Nov 2024 11:10:08 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v13] In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Also include information about where generated data is consumed. - Document how and why we keep track of native libraries per module ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20837/files - new: https://git.openjdk.org/jdk/pull/20837/files/922d7e76..d491b481 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=11-12 Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20837.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837 PR: https://git.openjdk.org/jdk/pull/20837 From ihse at openjdk.org Mon Nov 18 11:10:09 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 18 Nov 2024 11:10:09 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v13] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: <2AuWIwJHwHeyLprvYcjNGSdmVM4cH39VOrMVhnnxmBE=.c85a7591-6644-4200-bc56-cfa37028a752@github.com> On Tue, 3 Sep 2024 19:51:39 GMT, Erik Joelsson wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - Also include information about where generated data is consumed. >> - Document how and why we keep track of native libraries per module > > make/ModuleWrapper.gmk line 59: > >> 57: endif >> 58: endif >> 59: > > This part looks a bit convoluted. It would be nice with a comment explaining what it does, where `$($(MODULE)_JDK_LIBS)` is coming from and what consumes the module-libs.txt. Fixed. > make/common/JdkNativeCompilation.gmk line 310: > >> 308: $$(MODULE)_JDK_LIBS += $$($1_NAME) >> 309: endif >> 310: endif > > Same, here as in ModuleWrapper.gmk, I think we need a comment explaining how this is consumed. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1846394969 PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1846398235 From ihse at openjdk.org Mon Nov 18 11:21:09 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 18 Nov 2024 11:21:09 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v14] In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: <7K6aTd3mVPdWmwPwNeW6AYlK7a1MnTXgLBs3cMCnizA=.9ae66afa-0240-44e8-9b09-db13b6dc7031@github.com> > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). Magnus Ihse Bursie 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' into static-jdk-image - Also include information about where generated data is consumed. - Document how and why we keep track of native libraries per module - Remove unnecessary change for macOS in java_md.c - Merge branch 'master' into static-jdk-image - Merge branch 'master' into static-jdk-image - Merge branch 'master' into static-jdk-image - Fix bug in filtering out -Wl,--exclude-libs,ALL - Don't hardcode server variant - Setup LDFLAGS_STATIC_JDK - ... and 6 more: https://git.openjdk.org/jdk/compare/b8b70c8b...783f34d3 ------------- Changes: https://git.openjdk.org/jdk/pull/20837/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=13 Stats: 453 lines in 26 files changed: 374 ins; 5 del; 74 mod Patch: https://git.openjdk.org/jdk/pull/20837.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837 PR: https://git.openjdk.org/jdk/pull/20837 From fyang at openjdk.org Mon Nov 18 11:32:33 2024 From: fyang at openjdk.org (Fei Yang) Date: Mon, 18 Nov 2024 11:32:33 GMT Subject: RFR: 8344393: RISC-V: Remove option UseRVVForBigIntegerShiftIntrinsics Message-ID: <1RvfDgpq--6vlc20BhLEcEEHvSu0CrFkAy4_8mhAqUU=.70da8c54-e487-4967-be8f-f9368dfb240b@github.com> Seem that it's more reasonable to control BigInteger shift intrinsics with`UseRVV` option. I witnessed performance benefit on BPI-F3 with the RISC-V vector extension. And it's still possible to disable these two intrinsics with `-XX:DisableIntrinsic` option. JMH on BPI-F3 (has vector 1.0) for reference: Without instrinsic: BigIntegers.testLeftShift N/A avgt 15 4083.865 ? 224.139 ns/op BigIntegers.testRightShift N/A avgt 15 1745.833 ? 44.855 ns/op With instrinsic: BigIntegers.testLeftShift N/A avgt 15 2243.095 ? 24.821 ns/op BigIntegers.testRightShift N/A avgt 15 1558.770 ? 36.191 ns/op ------------- Commit messages: - 8344393: RISC-V: Remove option UseRVVForBigIntegerShiftIntrinsics Changes: https://git.openjdk.org/jdk/pull/22202/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22202&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344393 Stats: 4 lines in 3 files changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22202.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22202/head:pull/22202 PR: https://git.openjdk.org/jdk/pull/22202 From fyang at openjdk.org Mon Nov 18 11:33:44 2024 From: fyang at openjdk.org (Fei Yang) Date: Mon, 18 Nov 2024 11:33:44 GMT Subject: RFR: 8344010: RISC-V: Zacas do not work with LW locking In-Reply-To: <9zxKdn73DHLKXicGNz8Wygje-qKJMlvy4sTcKz3che8=.ee30bec8-f557-4436-9e77-70d5a06e3590@github.com> References: <9zxKdn73DHLKXicGNz8Wygje-qKJMlvy4sTcKz3che8=.ee30bec8-f557-4436-9e77-70d5a06e3590@github.com> Message-ID: On Fri, 15 Nov 2024 13:01:37 GMT, Robbin Ehn wrote: > Hi all, please consider. > > Light weight locking fails: > - We need to add cas acquire. > - Register _result_ may shadow _new_val_ (same register). > (NOTE this second item can effect many other cases, unclear) > > As the code becomes much cleaner by calling amocas_d/w directly I removed the aliases. > Which fixes the first issue with cas acquire. > > By using t0 instead of _result_ we fix the other issue. > > This is a short bugfix, there are so many dragons here that I do not want to address them while fixing the bug. > There are also several performance optimizations we can do here, specially for LR/SC case. > So I'll do a couple of more iterations of this code in seperate PR's. > > Testing a bunch of local cherry-picked tests which failed. > I'll start tier1 over the weekend. > > Thanks, Robbin Marked as reviewed by fyang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22149#pullrequestreview-2442363959 From fyang at openjdk.org Mon Nov 18 11:33:46 2024 From: fyang at openjdk.org (Fei Yang) Date: Mon, 18 Nov 2024 11:33:46 GMT Subject: RFR: 8344010: RISC-V: Zacas do not work with LW locking In-Reply-To: <6Zq1Wrq3yMbCbcge6AzickFhY9pRDo0E6UchPlKJtQ0=.ec6c17fa-fb1e-467c-9a80-00d0d445d6f4@github.com> References: <9zxKdn73DHLKXicGNz8Wygje-qKJMlvy4sTcKz3che8=.ee30bec8-f557-4436-9e77-70d5a06e3590@github.com> <6Zq1Wrq3yMbCbcge6AzickFhY9pRDo0E6UchPlKJtQ0=.ec6c17fa-fb1e-467c-9a80-00d0d445d6f4@github.com> Message-ID: On Mon, 18 Nov 2024 07:20:55 GMT, Robbin Ehn wrote: >> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 3533: >> >>> 3531: cmpxchg(addr, expected, new_val, size, acquire, release, result, true); >>> 3532: return; >>> 3533: } >> >> Question: Should we move the code after the three assertions? I see same assertions are there in `MacroAssembler::cmpxchg` as well. Even though they are the same for now, I assume they are targeting different code and are submit to change in the future. > > The reason to move it after is readability. > By having the zacas code before the asserts you think the implied contract the asserts states do not apply to zacas case. Meaning that, at least I, read the code as addr, expected, new_val may be t0 when UseZacas is true. Make sense in that respect. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22149#discussion_r1846429219 From ihse at openjdk.org Mon Nov 18 11:38:07 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 18 Nov 2024 11:38:07 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v15] In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix incremental builds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20837/files - new: https://git.openjdk.org/jdk/pull/20837/files/783f34d3..a6c61140 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=13-14 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20837.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837 PR: https://git.openjdk.org/jdk/pull/20837 From mli at openjdk.org Mon Nov 18 11:51:57 2024 From: mli at openjdk.org (Hamlin Li) Date: Mon, 18 Nov 2024 11:51:57 GMT Subject: RFR: 8344393: RISC-V: Remove option UseRVVForBigIntegerShiftIntrinsics In-Reply-To: <1RvfDgpq--6vlc20BhLEcEEHvSu0CrFkAy4_8mhAqUU=.70da8c54-e487-4967-be8f-f9368dfb240b@github.com> References: <1RvfDgpq--6vlc20BhLEcEEHvSu0CrFkAy4_8mhAqUU=.70da8c54-e487-4967-be8f-f9368dfb240b@github.com> Message-ID: <4hV0ieiN1HmDSVbAstGYj_YH7NcmuJ9DhzjvDDeUiWk=.c32fdaa3-8f43-4464-8e7c-a342f6898c18@github.com> On Mon, 18 Nov 2024 11:25:15 GMT, Fei Yang wrote: > Seem that it's more reasonable to control BigInteger shift intrinsics with`UseRVV` option. > I witnessed performance benefit on BPI-F3 with the RISC-V vector extension. And it's still > possible to disable these two intrinsics with `-XX:DisableIntrinsic` option if we want. > > JMH on BPI-F3 (has vector 1.0) for reference: > > Without instrinsic: > BigIntegers.testLeftShift N/A avgt 15 4083.865 ? 224.139 ns/op > BigIntegers.testRightShift N/A avgt 15 1745.833 ? 44.855 ns/op > > With instrinsic: > BigIntegers.testLeftShift N/A avgt 15 2243.095 ? 24.821 ns/op > BigIntegers.testRightShift N/A avgt 15 1558.770 ? 36.191 ns/op Make sense to me. Thanks! ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22202#pullrequestreview-2442401523 From fjiang at openjdk.org Mon Nov 18 12:00:47 2024 From: fjiang at openjdk.org (Feilong Jiang) Date: Mon, 18 Nov 2024 12:00:47 GMT Subject: RFR: 8344393: RISC-V: Remove option UseRVVForBigIntegerShiftIntrinsics In-Reply-To: <1RvfDgpq--6vlc20BhLEcEEHvSu0CrFkAy4_8mhAqUU=.70da8c54-e487-4967-be8f-f9368dfb240b@github.com> References: <1RvfDgpq--6vlc20BhLEcEEHvSu0CrFkAy4_8mhAqUU=.70da8c54-e487-4967-be8f-f9368dfb240b@github.com> Message-ID: On Mon, 18 Nov 2024 11:25:15 GMT, Fei Yang wrote: > Seem that it's more reasonable to control BigInteger shift intrinsics with`UseRVV` option. > I witnessed performance benefit on BPI-F3 with the RISC-V vector extension. And it's still > possible to disable these two intrinsics with `-XX:DisableIntrinsic` option if we want. > > JMH on BPI-F3 (has vector 1.0) for reference: > > Without instrinsic: > BigIntegers.testLeftShift N/A avgt 15 4083.865 ? 224.139 ns/op > BigIntegers.testRightShift N/A avgt 15 1745.833 ? 44.855 ns/op > > With instrinsic: > BigIntegers.testLeftShift N/A avgt 15 2243.095 ? 24.821 ns/op > BigIntegers.testRightShift N/A avgt 15 1558.770 ? 36.191 ns/op Looks good? ------------- Marked as reviewed by fjiang (Committer). PR Review: https://git.openjdk.org/jdk/pull/22202#pullrequestreview-2442420892 From amitkumar at openjdk.org Mon Nov 18 12:01:47 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 18 Nov 2024 12:01:47 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 10:17:12 GMT, Amit Kumar wrote: > Adds SaveLiveRegister portion for vector registers also. > > Depends on https://github.com/openjdk/jdk/pull/22190. Once that PR gets integrated, will rebase and mark it ready for review. I got only test failure : `java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java` which seems to generic issue [JDK-8344253](https://bugs.openjdk.org/browse/JDK-8344253) @RealLucy can you take a look at this one. I guess this also can be treated as trivial. It will good if you can see if the register preserved for float & general register are also okay. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22197#issuecomment-2482833576 PR Comment: https://git.openjdk.org/jdk/pull/22197#issuecomment-2482838311 From coleenp at openjdk.org Mon Nov 18 12:41:52 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 18 Nov 2024 12:41:52 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v5] In-Reply-To: References: Message-ID: <44duw-bwTlAaNhATsWQA0Fn13fAK0gaCTCsrSGBzibg=.eb7fbcdf-6229-4d13-a3d8-0df6a948c4f5@github.com> On Mon, 18 Nov 2024 03:00:36 GMT, David Holmes wrote: >> jni.cpp functions call this. > > I don't see any difference in the callers in relation to this PR and the function is not presently declared `extern`. ?? There was an extern trace_class_resolution() function that called this _impl function that I removed, so renamed this impl function to trace_class_resolution(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1846515884 From coleenp at openjdk.org Mon Nov 18 12:52:01 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 18 Nov 2024 12:52:01 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v7] In-Reply-To: References: Message-ID: On Sat, 16 Nov 2024 14:25:30 GMT, Coleen Phillimore wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments. Thanks for the reviews, Ioi, John and David. Thanks also for the comments and more code deletion suggestions, Alan. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2482948507 PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2482949665 From coleenp at openjdk.org Mon Nov 18 12:52:02 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 18 Nov 2024 12:52:02 GMT Subject: Integrated: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 11:42:11 GMT, Coleen Phillimore wrote: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. This pull request has now been integrated. Changeset: dfddbcaa Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/dfddbcaab886b9baa731cd748bb7f547e1903b64 Stats: 1415 lines in 48 files changed: 0 ins; 1246 del; 169 mod 8341916: Remove ProtectionDomain related hotspot code and tests Reviewed-by: dholmes, iklam, jrose ------------- PR: https://git.openjdk.org/jdk/pull/22064 From mdoerr at openjdk.org Mon Nov 18 13:27:57 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 18 Nov 2024 13:27:57 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 10:17:12 GMT, Amit Kumar wrote: > Adds SaveLiveRegister portion for vector registers also. > > Depends on https://github.com/openjdk/jdk/pull/22190. Once that PR gets integrated, will rebase and mark it ready for review. Looks basically good. I think that the instructions can encode the maximum frame size. src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp line 280: > 278: } > 279: } > 280: } else if (vm_reg->is_VectorRegister()){ There should be a space before `{`. src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp line 284: > 282: if (vs_reg->encoding() >= Z_V2->encoding() && vs_reg->encoding() <= Z_V31->encoding()) { > 283: reg_save_index += 2; > 284: Register spill_addr = Z_R0; Unused. ------------- PR Review: https://git.openjdk.org/jdk/pull/22197#pullrequestreview-2442600844 PR Review Comment: https://git.openjdk.org/jdk/pull/22197#discussion_r1846572377 PR Review Comment: https://git.openjdk.org/jdk/pull/22197#discussion_r1846572890 From amitkumar at openjdk.org Mon Nov 18 13:32:59 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 18 Nov 2024 13:32:59 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known [v2] In-Reply-To: References: Message-ID: <-JQWB9KRz1XLoT9GYTJhK5cqSWDxsmd7sjcVrYbCXHk=.650dabd7-65bc-4c8c-af86-b175a1102891@github.com> > Adds SaveLiveRegister portion for vector registers also. > > Depends on https://github.com/openjdk/jdk/pull/22190. Once that PR gets integrated, will rebase and mark it ready for review. Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: suggestion from martin ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22197/files - new: https://git.openjdk.org/jdk/pull/22197/files/6645f7b2..c6928c4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22197&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22197&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22197.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22197/head:pull/22197 PR: https://git.openjdk.org/jdk/pull/22197 From amitkumar at openjdk.org Mon Nov 18 13:32:59 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 18 Nov 2024 13:32:59 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known [v2] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 13:20:31 GMT, Martin Doerr wrote: >> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> suggestion from martin > > src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp line 284: > >> 282: if (vs_reg->encoding() >= Z_V2->encoding() && vs_reg->encoding() <= Z_V31->encoding()) { >> 283: reg_save_index += 2; >> 284: Register spill_addr = Z_R0; > > Unused. Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22197#discussion_r1846587368 From amitkumar at openjdk.org Mon Nov 18 13:43:10 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 18 Nov 2024 13:43:10 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known [v2] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 13:24:59 GMT, Martin Doerr wrote: >I think that the instructions can encode the maximum frame size. both of the instruction support displacement up to `12bit unsigned integer`, which should give us flexibility of around 4000byte So I guess we should be fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22197#issuecomment-2483078644 From ihse at openjdk.org Mon Nov 18 13:57:29 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 18 Nov 2024 13:57:29 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v16] In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: <7AJAaqfu2qc0QX0p2WYUzB73rSbPZeOwUwFAEHl0irI=.0fb2ef18-e16d-4563-98d1-2610c6f21916@github.com> > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Restore SetExecname in java_md.c ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20837/files - new: https://git.openjdk.org/jdk/pull/20837/files/a6c61140..de243c34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=14-15 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20837.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837 PR: https://git.openjdk.org/jdk/pull/20837 From epeter at openjdk.org Mon Nov 18 14:08:18 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 14:08:18 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: <_8-9ZYtVnjHTl3zce1wjZUCJZ6j1I5LgVfmUT4VKkm8=.74799b71-4c26-4c6c-8299-2efd02292548@github.com> On Fri, 8 Nov 2024 17:42:24 GMT, Roman Kennke wrote: >> Could you please cherry pick https://github.com/mur47x111/jdk/commit/c45ebc2a89d0b25a3dd8cc46386e37a635ff9af2 for the JVMCI support? > > @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-) @rkennke I have now looked more into the SuperWord collateral damage: [JDK-8340010](https://bugs.openjdk.org/browse/JDK-8340010): Fix vectorization tests with compact headers Do we care about `AlignVector` and `UseCompactObjectHeaders` enabled together? If so, we have a serious issue with mixed type examples. There are actually now some failing cases: Failed IR Rules (3) of Methods (3) ---------------------------------- 1) Method "public char[] compiler.vectorization.runner.ArrayTypeConvertTest.convertFloatToChar()" - [Failed IR rules: 1]: * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"asimd", "true", "avx2", "true"}, counts={"_#V#VECTOR_CAST_F2S#_", "_ at min(max_float, max_char)", ">0"}, applyIfPlatform={}, applyIfPlatformOr={}, failOn={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\\d+(\\s){2}(VectorCastF2X.*)+(\\s){2}===.*vector[A-Za-z])" - Failed comparison: [found] 0 > 0 [given] - No nodes matched! 2) Method "public short[] compiler.vectorization.runner.ArrayTypeConvertTest.convertFloatToShort()" - [Failed IR rules: 1]: * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"asimd", "true", "avx2", "true"}, counts={"_#V#VECTOR_CAST_F2S#_", "_ at min(max_float, max_short)", ">0"}, applyIfPlatform={}, applyIfPlatformOr={}, failOn={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\\d+(\\s){2}(VectorCastF2X.*)+(\\s){2}===.*vector[A-Za-z])" - Failed comparison: [found] 0 > 0 [given] - No nodes matched! 3) Method "public float[] compiler.vectorization.runner.ArrayTypeConvertTest.convertShortToFloat()" - [Failed IR rules: 1]: * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"asimd", "true", "avx2", "true"}, counts={"_#V#VECTOR_CAST_S2F#_", "_ at min(max_short, max_float)", ">0"}, applyIfPlatform={}, applyIfPlatformOr={}, failOn={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\\d+(\\s){2}(VectorCastS2X.*)+(\\s){2}===.*vector[A-Za-z])" - Failed comparison: [found] 0 > 0 [given] - No nodes matched! Let me explain: If we enable AlignVector, we need 8-byte alignment. As long as `UseCompactObjectHeaders` is disabled, all of these are `=16`: UNSAFE.ARRAY_BYTE_BASE_OFFSET UNSAFE.ARRAY_SHORT_BASE_OFFSET UNSAFE.ARRAY_CHAR_BASE_OFFSET UNSAFE.ARRAY_INT_BASE_OFFSET UNSAFE.ARRAY_LONG_BASE_OFFSET UNSAFE.ARRAY_FLOAT_BASE_OFFSET UNSAFE.ARRAY_DOUBLE_BASE_OFFSET However, with `UseCompactObjectHeaders` endabled, these are now 12: UNSAFE.ARRAY_BYTE_BASE_OFFSET UNSAFE.ARRAY_SHORT_BASE_OFFSET UNSAFE.ARRAY_CHAR_BASE_OFFSET UNSAFE.ARRAY_INT_BASE_OFFSET UNSAFE.ARRAY_FLOAT_BASE_OFFSET And these still 16: UNSAFE.ARRAY_LONG_BASE_OFFSET UNSAFE.ARRAY_DOUBLE_BASE_OFFSET Now let's try to get that 8-byte alignment in some example, one from the above: public short[] convertFloatToShort() { short[] res = new short[SIZE]; for (int i = 0; i < SIZE; i++) { res[i] = (short) floats[i]; } return res; } Let's look at the two addresses with `UseCompactObjectHeaders=false`, where we **can** vectorize: F_adr = base + 16 + 4 * i -> aligned for: i % 2 = 0 S_adr = base + 16 + 2 * i -> aligned for: i % 4 = 0 -> solution for both: i % 4 = 0, i.e. we have alignment for both vector accesses every 4th iteration. Let's look at the two addresses with `UseCompactObjectHeaders=true`, where we **cannot** vectorize: F_adr = base + 12 + 4 * i -> aligned for: i % 2 = 1 S_adr = base + 12 + 2 * i -> aligned for: i % 4 = 2 -> There is no solution to satisfy both alignment constraints! It's a little sad that I only just realized this now... but oh well. The issue is that we apparently did not run testing for these examples, so I did not see the impact immediately. So my question: do we care about `UseCompactObjectHeaders` and `AlignVector` enabled at the same time? If so, we have to accept that some examples with mixed types simply will not vectorize. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483138198 From epeter at openjdk.org Mon Nov 18 14:12:21 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 14:12:21 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 17:42:24 GMT, Roman Kennke wrote: >> Could you please cherry pick https://github.com/mur47x111/jdk/commit/c45ebc2a89d0b25a3dd8cc46386e37a635ff9af2 for the JVMCI support? > > @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-) @rkennke How important is the 4-byte saving on `byte, char, short, int, float` arrays? I'd assume they are not generally that small, at least a few elements? So could we make an exception, and have a `16-byte` offset to the payload of all these primitive (and maybe all) arrays, at least under `AlignVector`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483153279 From lucy at openjdk.org Mon Nov 18 14:14:48 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Mon, 18 Nov 2024 14:14:48 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known [v2] In-Reply-To: <-JQWB9KRz1XLoT9GYTJhK5cqSWDxsmd7sjcVrYbCXHk=.650dabd7-65bc-4c8c-af86-b175a1102891@github.com> References: <-JQWB9KRz1XLoT9GYTJhK5cqSWDxsmd7sjcVrYbCXHk=.650dabd7-65bc-4c8c-af86-b175a1102891@github.com> Message-ID: <3j215YdXLWTLeV6hLIoidiURd63G0MDQGzboeVjtXzY=.2b798690-c6ca-42ac-94bc-5ce8b2a889d1@github.com> On Mon, 18 Nov 2024 13:32:59 GMT, Amit Kumar wrote: >> Adds SaveLiveRegister portion for vector registers also. >> >> Depends on https://github.com/openjdk/jdk/pull/22190. Once that PR gets integrated, will rebase and mark it ready for review. > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > suggestion from martin Looks good. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22197#pullrequestreview-2442743569 From lucy at openjdk.org Mon Nov 18 14:14:49 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Mon, 18 Nov 2024 14:14:49 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known [v2] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 13:39:46 GMT, Amit Kumar wrote: > > I think that the instructions can encode the maximum frame size. > > both of the instruction support displacement up to `12bit unsigned integer`, which should give us flexibility of around 4000byte So I guess we should be fine. Instead of speculation: - GPRs: 16 registers, 8 bytes each -> 128 bytes - FPRs: 16 registers, 8 bytes each -> 128 bytes - VRs: 32 registers, 16 bytes each -> 512 bytes - In total: 768 bytes. This is an easy fit into uimm12. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22197#issuecomment-2483158154 From rkennke at openjdk.org Mon Nov 18 14:16:26 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 18 Nov 2024 14:16:26 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 17:42:24 GMT, Roman Kennke wrote: >> Could you please cherry pick https://github.com/mur47x111/jdk/commit/c45ebc2a89d0b25a3dd8cc46386e37a635ff9af2 for the JVMCI support? > > @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-) > @rkennke How important is the 4-byte saving on `byte, char, short, int, float` arrays? I'd assume they are not generally that small, at least a few elements? So could we make an exception, and have a `16-byte` offset to the payload of all these primitive (and maybe all) arrays, at least under `AlignVector`? For byte[] and to some extend for char[] it is quite important, because those are the backing types for String and related classes, and Java apps often have *many* of them, and also quite small. I would not want to to sacrifize them for vectorization, especially not for the relatively uncommon (I think) case of mixed type access. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483162512 From epeter at openjdk.org Mon Nov 18 14:20:20 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 14:20:20 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: <55hlCTAhtpoZT9LDQUkHwPQ5UUTylLzfNDYiFaBTXes=.9d9d6874-2f59-4833-9226-9e7f6410ca8d@github.com> On Mon, 18 Nov 2024 14:13:17 GMT, Roman Kennke wrote: >> @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-) > >> @rkennke How important is the 4-byte saving on `byte, char, short, int, float` arrays? I'd assume they are not generally that small, at least a few elements? So could we make an exception, and have a `16-byte` offset to the payload of all these primitive (and maybe all) arrays, at least under `AlignVector`? > > For byte[] and to some extend for char[] it is quite important, because those are the backing types for String and related classes, and Java apps often have *many* of them, and also quite small. I would not want to to sacrifize them for vectorization, especially not for the relatively uncommon (I think) case of mixed type access. @rkennke Ok, fair enough. As far as I know, we at Oracle do not super care about strict alignment `AlignVector`. But maybe other people care, and have to make that tradeoff between vectorization and small object headers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483170957 From rkennke at openjdk.org Mon Nov 18 14:28:20 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 18 Nov 2024 14:28:20 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 14:13:17 GMT, Roman Kennke wrote: >> @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-) > >> @rkennke How important is the 4-byte saving on `byte, char, short, int, float` arrays? I'd assume they are not generally that small, at least a few elements? So could we make an exception, and have a `16-byte` offset to the payload of all these primitive (and maybe all) arrays, at least under `AlignVector`? > > For byte[] and to some extend for char[] it is quite important, because those are the backing types for String and related classes, and Java apps often have *many* of them, and also quite small. I would not want to to sacrifize them for vectorization, especially not for the relatively uncommon (I think) case of mixed type access. > @rkennke Ok, fair enough. As far as I know, we at Oracle do not super care about strict alignment `AlignVector`. But maybe other people care, and have to make that tradeoff between vectorization and small object headers. BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. What is the failure mode, though? When running with -UCOH and +AlignVector, would it crash or misbehave? Or would it (silently?) not vectorize? I think we could live with the latter, but not with the former. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483195304 From epeter at openjdk.org Mon Nov 18 14:28:20 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 14:28:20 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 14:23:24 GMT, Roman Kennke wrote: >>> @rkennke How important is the 4-byte saving on `byte, char, short, int, float` arrays? I'd assume they are not generally that small, at least a few elements? So could we make an exception, and have a `16-byte` offset to the payload of all these primitive (and maybe all) arrays, at least under `AlignVector`? >> >> For byte[] and to some extend for char[] it is quite important, because those are the backing types for String and related classes, and Java apps often have *many* of them, and also quite small. I would not want to to sacrifize them for vectorization, especially not for the relatively uncommon (I think) case of mixed type access. > >> @rkennke Ok, fair enough. As far as I know, we at Oracle do not super care about strict alignment `AlignVector`. But maybe other people care, and have to make that tradeoff between vectorization and small object headers. > > BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. > > What is the failure mode, though? When running with -UCOH and +AlignVector, would it crash or misbehave? Or would it (silently?) not vectorize? I think we could live with the latter, but not with the former. @rkennke It just will (silently) not vectorize, thus running slower but still correct. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483202341 From mdoerr at openjdk.org Mon Nov 18 14:35:17 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 18 Nov 2024 14:35:17 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known [v2] In-Reply-To: <-JQWB9KRz1XLoT9GYTJhK5cqSWDxsmd7sjcVrYbCXHk=.650dabd7-65bc-4c8c-af86-b175a1102891@github.com> References: <-JQWB9KRz1XLoT9GYTJhK5cqSWDxsmd7sjcVrYbCXHk=.650dabd7-65bc-4c8c-af86-b175a1102891@github.com> Message-ID: <8rJm-SGh6DJyX-CsK_NcuU0EqStWHXWCermTPlg0SeY=.f303839d-8082-4479-a9a4-68cf02f8a0bf@github.com> On Mon, 18 Nov 2024 13:32:59 GMT, Amit Kumar wrote: >> Adds SaveLiveRegister portion for vector registers also. >> >> Depends on https://github.com/openjdk/jdk/pull/22190. Once that PR gets integrated, will rebase and mark it ready for review. > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > suggestion from martin Thanks for the update. Now, I only wonder about the `>= Z_V2` condition. How does this fit to https://github.com/openjdk/jdk/blob/dfddbcaab886b9baa731cd748bb7f547e1903b64/src/hotspot/cpu/s390/s390.ad#L745? ------------- PR Review: https://git.openjdk.org/jdk/pull/22197#pullrequestreview-2442796010 From ihse at openjdk.org Mon Nov 18 14:40:03 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 18 Nov 2024 14:40:03 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v14] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 16:38:20 GMT, Ioi Lam wrote: >> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). >> >> ---- >> Note: this is a combined PR of the following individual PRs >> - https://github.com/openjdk/jdk/pull/20516 >> - https://github.com/openjdk/jdk/pull/20517 >> - https://github.com/openjdk/jdk/pull/20843 >> - https://github.com/openjdk/jdk/pull/20958 >> - https://github.com/openjdk/jdk/pull/20959 >> - https://github.com/openjdk/jdk/pull/21049 >> - https://github.com/openjdk/jdk/pull/21143 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test after security manager removal make/RunTests.gmk line 706: > 704: endef > 705: > 706: This PR was not tagged with the `build` label, and was therefore not brought to the attention of the build team. This file contains a large number of unacceptable changes. :-( It would under no circumstance have been approved as it looks. Please make sure that the Github labels actually matches the set of files that are changed in the PR. Skara tooling will assist in this, but the ultimate responsibility lies with the Author and Reviewers of the PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1846696988 From epeter at openjdk.org Mon Nov 18 14:41:21 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 14:41:21 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> On Mon, 18 Nov 2024 14:23:24 GMT, Roman Kennke wrote: >>> @rkennke How important is the 4-byte saving on `byte, char, short, int, float` arrays? I'd assume they are not generally that small, at least a few elements? So could we make an exception, and have a `16-byte` offset to the payload of all these primitive (and maybe all) arrays, at least under `AlignVector`? >> >> For byte[] and to some extend for char[] it is quite important, because those are the backing types for String and related classes, and Java apps often have *many* of them, and also quite small. I would not want to to sacrifize them for vectorization, especially not for the relatively uncommon (I think) case of mixed type access. > >> @rkennke Ok, fair enough. As far as I know, we at Oracle do not super care about strict alignment `AlignVector`. But maybe other people care, and have to make that tradeoff between vectorization and small object headers. > > BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. > > What is the failure mode, though? When running with -UCOH and +AlignVector, would it crash or misbehave? Or would it (silently?) not vectorize? I think we could live with the latter, but not with the former. @rkennke > BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. Sure. But I guess some people will want to run both `AlignVector` and `UseCompactObjectHeaders` in the future. Some machines simply do require strict alignment. So they will have to live with that tradeoff. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483225393 From qamai at openjdk.org Mon Nov 18 14:41:21 2024 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 18 Nov 2024 14:41:21 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> References: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> Message-ID: On Mon, 18 Nov 2024 14:31:52 GMT, Emanuel Peter wrote: >>> @rkennke Ok, fair enough. As far as I know, we at Oracle do not super care about strict alignment `AlignVector`. But maybe other people care, and have to make that tradeoff between vectorization and small object headers. >> >> BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. >> >> What is the failure mode, though? When running with -UCOH and +AlignVector, would it crash or misbehave? Or would it (silently?) not vectorize? I think we could live with the latter, but not with the former. > > @rkennke >> BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. > > Sure. But I guess some people will want to run both `AlignVector` and `UseCompactObjectHeaders` in the future. Some machines simply do require strict alignment. So they will have to live with that tradeoff. @eme64 Tbh I don't see how `AlignVector` can mitigate the issue if strict alignment is required unless the object base is guaranteed to be aligned at least as much as the vector length. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483230986 From rkennke at openjdk.org Mon Nov 18 14:41:21 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 18 Nov 2024 14:41:21 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 14:23:24 GMT, Roman Kennke wrote: >>> @rkennke How important is the 4-byte saving on `byte, char, short, int, float` arrays? I'd assume they are not generally that small, at least a few elements? So could we make an exception, and have a `16-byte` offset to the payload of all these primitive (and maybe all) arrays, at least under `AlignVector`? >> >> For byte[] and to some extend for char[] it is quite important, because those are the backing types for String and related classes, and Java apps often have *many* of them, and also quite small. I would not want to to sacrifize them for vectorization, especially not for the relatively uncommon (I think) case of mixed type access. > >> @rkennke Ok, fair enough. As far as I know, we at Oracle do not super care about strict alignment `AlignVector`. But maybe other people care, and have to make that tradeoff between vectorization and small object headers. > > BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. > > What is the failure mode, though? When running with -UCOH and +AlignVector, would it crash or misbehave? Or would it (silently?) not vectorize? I think we could live with the latter, but not with the former. > @rkennke It just will (silently) not vectorize, thus running slower but still correct. Ok, I think we can live with that for now. As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away. The tests need fixing, though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483234723 From epeter at openjdk.org Mon Nov 18 14:41:21 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 14:41:21 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> Message-ID: On Mon, 18 Nov 2024 14:34:13 GMT, Quan Anh Mai wrote: >> @rkennke >>> BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. >> >> Sure. But I guess some people will want to run both `AlignVector` and `UseCompactObjectHeaders` in the future. Some machines simply do require strict alignment. So they will have to live with that tradeoff. > > @eme64 Tbh I don't see how `AlignVector` can mitigate the issue if strict alignment is required unless the object base is guaranteed to be aligned at least as much as the vector length. @merykitty the object base is always at least `8-byte` aligned, see `ObjectAlignmentInBytes` - this also holds for all arrays. But the issue is the offset from the object base to the array payload. @rkennke yes, working on fixing the tests :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483236250 From qamai at openjdk.org Mon Nov 18 14:41:21 2024 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 18 Nov 2024 14:41:21 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> Message-ID: On Mon, 18 Nov 2024 14:36:17 GMT, Emanuel Peter wrote: >> @eme64 Tbh I don't see how `AlignVector` can mitigate the issue if strict alignment is required unless the object base is guaranteed to be aligned at least as much as the vector length. > > @merykitty the object base is always at least `8-byte` aligned, see `ObjectAlignmentInBytes` - this also holds for all arrays. But the issue is the offset from the object base to the array payload. > > @rkennke yes, working on fixing the tests :) @eme64 Please correct me if I'm wrong but the issue is you need the base to be aligned at 32 bytes on AVX2 machines for any alignment for vector instruction to be meaningful, so I don't see the value of vector alignment at all. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483241445 From epeter at openjdk.org Mon Nov 18 14:41:22 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 14:41:22 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 14:35:41 GMT, Roman Kennke wrote: >>> @rkennke Ok, fair enough. As far as I know, we at Oracle do not super care about strict alignment `AlignVector`. But maybe other people care, and have to make that tradeoff between vectorization and small object headers. >> >> BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. >> >> What is the failure mode, though? When running with -UCOH and +AlignVector, would it crash or misbehave? Or would it (silently?) not vectorize? I think we could live with the latter, but not with the former. > >> @rkennke It just will (silently) not vectorize, thus running slower but still correct. > > Ok, I think we can live with that for now. > > As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away. > > The tests need fixing, though. @rkennke > As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away. Ah. So we would eventually have not a `12-byte` but `8-byte` offset from base to payload? Would that happen in all cases? And could that happen before `UseCompactObjectHeaders` leaves experimental status? Because it is going to be a little annoying to adjust all vectorization tests for the special case of `UseCompactObjectHeaders + AlignVector`. Though I can surely do it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483242899 From epeter at openjdk.org Mon Nov 18 14:44:19 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 14:44:19 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> Message-ID: On Mon, 18 Nov 2024 14:38:20 GMT, Quan Anh Mai wrote: >> @merykitty the object base is always at least `8-byte` aligned, see `ObjectAlignmentInBytes` - this also holds for all arrays. But the issue is the offset from the object base to the array payload. >> >> @rkennke yes, working on fixing the tests :) > > @eme64 Please correct me if I'm wrong but the issue is you need the base to be aligned at 32 bytes on AVX2 machines for any alignment for vector instruction to be meaningful, so I don't see the value of vector alignment at all. @merykitty > Please correct me if I'm wrong but the issue is you need the base to be aligned at 32 bytes on AVX2 machines for any alignment for vector instruction to be meaningful, so I don't see the value of vector alignment at all. First: without `AlignVector`, the vector instructions can have completely free alignment. On x64 and aarch64 generally I think most machines do not need alignment at all. And as far as I know there is also no performance penalty on modern CPUs for misalignment. I could be wrong here. On older CPUs alignment was important for performance though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483249163 From qamai at openjdk.org Mon Nov 18 14:56:28 2024 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 18 Nov 2024 14:56:28 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> Message-ID: On Mon, 18 Nov 2024 14:41:25 GMT, Emanuel Peter wrote: >> @eme64 Please correct me if I'm wrong but the issue is you need the base to be aligned at 32 bytes on AVX2 machines for any alignment for vector instruction to be meaningful, so I don't see the value of vector alignment at all. > > @merykitty >> Please correct me if I'm wrong but the issue is you need the base to be aligned at 32 bytes on AVX2 machines for any alignment for vector instruction to be meaningful, so I don't see the value of vector alignment at all. > > First: without `AlignVector`, the vector instructions can have completely free alignment. On x64 and aarch64 generally I think most machines do not need alignment at all. And as far as I know there is also no performance penalty on modern CPUs for misalignment. I could be wrong here. On older CPUs alignment was important for performance though. @eme64 You will need the alignment for the whole vector (which means 32 bytes for a `ymm` load), not alignment only on its elements. Vector element is the artefact of ALU units, not the load/store units that actually care about alignment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483255086 From epeter at openjdk.org Mon Nov 18 14:56:28 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 14:56:28 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> Message-ID: <7h8Il7V3a1tbo_U2y2GyUY2tH8UPXtKc3we3ZZi47d4=.4a4cbe88-92a5-43cf-a6a9-48d0bed41cf7@github.com> On Mon, 18 Nov 2024 14:43:48 GMT, Quan Anh Mai wrote: >> @merykitty >>> Please correct me if I'm wrong but the issue is you need the base to be aligned at 32 bytes on AVX2 machines for any alignment for vector instruction to be meaningful, so I don't see the value of vector alignment at all. >> >> First: without `AlignVector`, the vector instructions can have completely free alignment. On x64 and aarch64 generally I think most machines do not need alignment at all. And as far as I know there is also no performance penalty on modern CPUs for misalignment. I could be wrong here. On older CPUs alignment was important for performance though. > > @eme64 You will need the alignment for the whole vector (which means 32 bytes for a `ymm` load), not alignment only on its elements. Vector element is the artefact of ALU units, not the load/store units that actually care about alignment. @merykitty I don't think I understand. When and for what do I need the full 32-byte alignment? @merykitty In `AlignmentSolver::solve` / `src/hotspot/share/opto/vectorization.cpp` you can see how I compute if vectors can be aligned. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483261148 PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483266962 From qamai at openjdk.org Mon Nov 18 14:56:28 2024 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 18 Nov 2024 14:56:28 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: <7h8Il7V3a1tbo_U2y2GyUY2tH8UPXtKc3we3ZZi47d4=.4a4cbe88-92a5-43cf-a6a9-48d0bed41cf7@github.com> References: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> <7h8Il7V3a1tbo_U2y2GyUY2tH8UPXtKc3we3ZZi47d4=.4a4cbe88-92a5-43cf-a6a9-48d0bed41cf7@github.com> Message-ID: <6rwCNBLV4-VemVsKR8KWYEgSIKfHQxS_RuxsPwX7TZo=.5fe167a3-1f97-408d-9d41-23d4d0fb42df@github.com> On Mon, 18 Nov 2024 14:48:22 GMT, Emanuel Peter wrote: >> @eme64 You will need the alignment for the whole vector (which means 32 bytes for a `ymm` load), not alignment only on its elements. Vector element is the artefact of ALU units, not the load/store units that actually care about alignment. > > @merykitty In `AlignmentSolver::solve` / `src/hotspot/share/opto/vectorization.cpp` you can see how I compute if vectors can be aligned. @eme64 If you load a 32-byte (256-bit) vector, then the load is aligned if the address is divisible by 32, otherwise the load is misaligned. That's why [`vmovdqua`](https://www.felixcloutier.com/x86/movdqa:vmovdqa32:vmovdqa64) requires 16-byte alignment for 16-byte loads/stores, 32-byte alignment for 32-byte loads/stores, 64-byte alignment for 64-byte loads/stores. As a result, I don't see how you can align a vector load/store if the object base is only guaranteed to align at 8-byte boundaries. I mean there is no use trying to align an access if you cannot align it at the access size, the access is going to be misaligned anyway. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483275575 From rkennke at openjdk.org Mon Nov 18 15:04:25 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 18 Nov 2024 15:04:25 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 14:35:41 GMT, Roman Kennke wrote: >>> @rkennke Ok, fair enough. As far as I know, we at Oracle do not super care about strict alignment `AlignVector`. But maybe other people care, and have to make that tradeoff between vectorization and small object headers. >> >> BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. >> >> What is the failure mode, though? When running with -UCOH and +AlignVector, would it crash or misbehave? Or would it (silently?) not vectorize? I think we could live with the latter, but not with the former. > >> @rkennke It just will (silently) not vectorize, thus running slower but still correct. > > Ok, I think we can live with that for now. > > As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away. > > The tests need fixing, though. > @rkennke > > > As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away. > > Ah. So we would eventually have not a `12-byte` but `8-byte` offset from base to payload? Would that happen in all cases? And could that happen before `UseCompactObjectHeaders` leaves experimental status? Because it is going to be a little annoying to adjust all vectorization tests for the special case of `UseCompactObjectHeaders + AlignVector`. Though I can surely do it. I am not sure if and when this is going to happen. When I presented the idea at JVMLS, I got some resistance. I am also not sure if we first leave experimental status for UCOH, and then introduce 4-byte headers under a new flag (or no flag?), or if we first do 4-byte headers and only leave experimental status once that is done. The latter sounds more reasonable to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483304257 From epeter at openjdk.org Mon Nov 18 15:04:25 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 15:04:25 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: <6rwCNBLV4-VemVsKR8KWYEgSIKfHQxS_RuxsPwX7TZo=.5fe167a3-1f97-408d-9d41-23d4d0fb42df@github.com> References: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> <7h8Il7V3a1tbo_U2y2GyUY2tH8UPXtKc3we3ZZi47d4=.4a4cbe88-92a5-43cf-a6a9-48d0bed41cf7@github.com> <6rwCNBLV4-VemVsKR8KWYEgSIKfHQxS_RuxsPwX7TZo=.5fe167a3-1f97-408d-9d41-23d4d0fb42df@github.com> Message-ID: On Mon, 18 Nov 2024 14:50:51 GMT, Quan Anh Mai wrote: >> @merykitty In `AlignmentSolver::solve` / `src/hotspot/share/opto/vectorization.cpp` you can see how I compute if vectors can be aligned. > > @eme64 If you load a 32-byte (256-bit) vector, then the load is aligned if the address is divisible by 32, otherwise the load is misaligned. That's why [`vmovdqua`](https://www.felixcloutier.com/x86/movdqa:vmovdqa32:vmovdqa64) requires 16-byte alignment for 16-byte loads/stores, 32-byte alignment for 32-byte loads/stores, 64-byte alignment for 64-byte loads/stores. > > As a result, I don't see how you can align a vector load/store if the object base is only guaranteed to align at 8-byte boundaries. I mean there is no use trying to align an access if you cannot align it at the access size, the access is going to be misaligned anyway. @merykitty I guess we can always use [vmovdqu](https://www.felixcloutier.com/x86/movdqu:vmovdqu8:vmovdqu16:vmovdqu32:vmovdqu64). And in fact that is exactly what we do: public class Test { static int RANGE = 1024*1024; public static void main(String[] args) { byte[] aB = new byte[RANGE]; byte[] bB = new byte[RANGE]; for (int i = 0; i < 100_000; i++) { test1(aB, bB); } } static void test1(byte[] a, byte[] b) { for (int i = 0; i < RANGE; i++) { a[i] = b[i]; } } } `../java -XX:CompileCommand=compileonly,Test::test* -XX:CompileCommand=printcompilation,Test::test* -XX:+TraceLoopOpts -XX:-TraceSuperWord -XX:+TraceNewVectors -Xbatch -XX:+AlignVector -XX:CompileCommand=compileonly,Test::test* -XX:CompileCommand=printassembly,Test::test* Test.java` ;; B20: # out( B20 B21 ) <- in( B19 B20 ) Loop( B20-B20 inner main of N178 strip mined) Freq: 8.13586e+09 0x00007fc3a4bb0780: movslq %ebx,%rdi 0x00007fc3a4bb0783: movslq %ebx,%r14 0x00007fc3a4bb0786: vmovdqu32 0x10(%r13,%r14,1),%zmm1 0x00007fc3a4bb0791: vmovdqu32 %zmm1,0x10(%r9,%r14,1) 0x00007fc3a4bb079c: vmovdqu32 0x50(%r13,%rdi,1),%zmm1 0x00007fc3a4bb07a7: vmovdqu32 %zmm1,0x50(%r9,%rdi,1) 0x00007fc3a4bb07b2: vmovdqu32 0x90(%r13,%rdi,1),%zmm1 0x00007fc3a4bb07bd: vmovdqu32 %zmm1,0x90(%r9,%rdi,1) 0x00007fc3a4bb07c8: vmovdqu32 0xd0(%r13,%rdi,1),%zmm1 0x00007fc3a4bb07d3: vmovdqu32 %zmm1,0xd0(%r9,%rdi,1) 0x00007fc3a4bb07de: vmovdqu32 0x110(%r13,%rdi,1),%zmm1 0x00007fc3a4bb07e9: vmovdqu32 %zmm1,0x110(%r9,%rdi,1) 0x00007fc3a4bb07f4: vmovdqu32 0x150(%r13,%rdi,1),%zmm1 0x00007fc3a4bb07ff: vmovdqu32 %zmm1,0x150(%r9,%rdi,1) 0x00007fc3a4bb080a: vmovdqu32 0x190(%r13,%rdi,1),%zmm1 0x00007fc3a4bb0815: vmovdqu32 %zmm1,0x190(%r9,%rdi,1) 0x00007fc3a4bb0820: vmovdqu32 0x1d0(%r13,%rdi,1),%zmm1 0x00007fc3a4bb082b: vmovdqu32 %zmm1,0x1d0(%r9,%rdi,1) ;*bastore {reexecute=0 rethrow=0 return_oop=0} ; - Test::test1 at 14 (line 14) 0x00007fc3a4bb0836: add $0x200,%ebx ;*iinc {reexecute=0 rethrow=0 return_oop=0} ; - Test::test1 at 15 (line 13) 0x00007fc3a4bb083c: cmp %r11d,%ebx 0x00007fc3a4bb083f: jl 0x00007fc3a4bb0780 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483305049 From ihse at openjdk.org Mon Nov 18 15:12:12 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 18 Nov 2024 15:12:12 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v17] In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Copy debuginfo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20837/files - new: https://git.openjdk.org/jdk/pull/20837/files/de243c34..41d37075 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=15-16 Stats: 53 lines in 3 files changed: 31 ins; 21 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20837.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837 PR: https://git.openjdk.org/jdk/pull/20837 From ihse at openjdk.org Mon Nov 18 15:12:12 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 18 Nov 2024 15:12:12 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v16] In-Reply-To: <7AJAaqfu2qc0QX0p2WYUzB73rSbPZeOwUwFAEHl0irI=.0fb2ef18-e16d-4563-98d1-2610c6f21916@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> <7AJAaqfu2qc0QX0p2WYUzB73rSbPZeOwUwFAEHl0irI=.0fb2ef18-e16d-4563-98d1-2610c6f21916@github.com> Message-ID: On Mon, 18 Nov 2024 13:57:29 GMT, Magnus Ihse Bursie wrote: >> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. >> >> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. >> >> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Restore SetExecname in java_md.c I think I have addressed all known outstanding issues with this PR, and that it is ready for final review and integration. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2483323302 From qamai at openjdk.org Mon Nov 18 15:23:34 2024 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 18 Nov 2024 15:23:34 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> <7h8Il7V3a1tbo_U2y2GyUY2tH8UPXtKc3we3ZZi47d4=.4a4cbe88-92a5-43cf-a6a9-48d0bed41cf7@github.com> <6rwCNBLV4-VemVsKR8KWYEgSIKfHQxS_RuxsPwX7TZo=.5fe167a3-1f97-408d-9d41-23d4d0fb42df@github.com> Message-ID: On Mon, 18 Nov 2024 15:01:09 GMT, Emanuel Peter wrote: >> @eme64 If you load a 32-byte (256-bit) vector, then the load is aligned if the address is divisible by 32, otherwise the load is misaligned. That's why [`vmovdqua`](https://www.felixcloutier.com/x86/movdqa:vmovdqa32:vmovdqa64) requires 16-byte alignment for 16-byte loads/stores, 32-byte alignment for 32-byte loads/stores, 64-byte alignment for 64-byte loads/stores. >> >> As a result, I don't see how you can align a vector load/store if the object base is only guaranteed to align at 8-byte boundaries. I mean there is no use trying to align an access if you cannot align it at the access size, the access is going to be misaligned anyway. > > @merykitty I guess we can always use [vmovdqu](https://www.felixcloutier.com/x86/movdqu:vmovdqu8:vmovdqu16:vmovdqu32:vmovdqu64). > > And in fact that is exactly what we do: > > public class Test { > static int RANGE = 1024*1024; > > public static void main(String[] args) { > byte[] aB = new byte[RANGE]; > byte[] bB = new byte[RANGE]; > for (int i = 0; i < 100_000; i++) { > test1(aB, bB); > } > } > > static void test1(byte[] a, byte[] b) { > for (int i = 0; i < RANGE; i++) { > a[i] = b[i]; > } > } > } > > `../java -XX:CompileCommand=compileonly,Test::test* -XX:CompileCommand=printcompilation,Test::test* -XX:+TraceLoopOpts -XX:-TraceSuperWord -XX:+TraceNewVectors -Xbatch -XX:+AlignVector -XX:CompileCommand=compileonly,Test::test* -XX:CompileCommand=printassembly,Test::test* Test.java` > > > ;; B20: # out( B20 B21 ) <- in( B19 B20 ) Loop( B20-B20 inner main of N178 strip mined) Freq: 8.13586e+09 > 0x00007fc3a4bb0780: movslq %ebx,%rdi > 0x00007fc3a4bb0783: movslq %ebx,%r14 > 0x00007fc3a4bb0786: vmovdqu32 0x10(%r13,%r14,1),%zmm1 > 0x00007fc3a4bb0791: vmovdqu32 %zmm1,0x10(%r9,%r14,1) > 0x00007fc3a4bb079c: vmovdqu32 0x50(%r13,%rdi,1),%zmm1 > 0x00007fc3a4bb07a7: vmovdqu32 %zmm1,0x50(%r9,%rdi,1) > 0x00007fc3a4bb07b2: vmovdqu32 0x90(%r13,%rdi,1),%zmm1 > 0x00007fc3a4bb07bd: vmovdqu32 %zmm1,0x90(%r9,%rdi,1) > 0x00007fc3a4bb07c8: vmovdqu32 0xd0(%r13,%rdi,1),%zmm1 > 0x00007fc3a4bb07d3: vmovdqu32 %zmm1,0xd0(%r9,%rdi,1) > 0x00007fc3a4bb07de: vmovdqu32 0x110(%r13,%rdi,1),%zmm1 > 0x00007fc3a4bb07e9: vmovdqu32 %zmm1,0x110(%r9,%rdi,1) > 0x00007fc3a4bb07f4: vmovdqu32 0x150(%r13,%rdi,1),%zmm1 > 0x00007fc3a4bb07ff: vmovdqu32 %zmm1,0x150(%r9,%rdi,1) > 0x00007fc3a4bb080a: vmovdqu32 0x190(%r13,%rdi,1),%zmm1 > 0x00007fc3a4bb0815: vmovdqu32 %zmm1,0x190(%r9,%rdi,1) > 0x00007fc3a4bb0820: vmovdqu32 0x1d0(%r13,%rdi,1),%zmm1 > 0x00007fc3a4bb082b: vmovdqu32 %zmm1,0x1d0(%r9,%rdi,1) ;*bastore {reexecute=0 rethrow=0 return_oop=0} > ; - Test::test1 at 14 (line 14) > 0x00007fc3a4bb0836: add $0x200,%ebx ;*iinc {reexecute=0 rethrow=0 return_oop=0} > ; - Test::test1 at 15 (line 13) > 0x00007fc3a4bb083c: c... @eme64 What I mean here is that `AlignVector` seems useless because the accesses are going to be misaligned either way. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483356306 From ihse at openjdk.org Mon Nov 18 15:32:21 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 18 Nov 2024 15:32:21 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 04:49:51 GMT, David Holmes wrote: >> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: >> >> - Merge branch 'master' into JDK-8305895-v4 >> - Merge tag 'jdk-25+23' into JDK-8305895-v4 >> >> Added tag jdk-24+23 for changeset c0e6c3b9 >> - Fix gen-ZGC removal >> - Merge tag 'jdk-24+22' into JDK-8305895-v4 >> >> Added tag jdk-24+22 for changeset 388d44fb >> - Enable riscv in CompressedClassPointersEncodingScheme test >> - s390 port >> - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test >> - Update copyright >> - Avoid assert/endless-loop in JFR code >> - Update copyright headers >> - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b > > test/hotspot/jtreg/gtest/MetaspaceUtilsGtests.java line 1: > > > This file was reduced to empty but not actually deleted. Can you fix it please. @rkennke Just making sure this is not being missed. Can you please open a JBS issue to correct this and the file below? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1846790097 From aph-open at littlepinkcloud.com Mon Nov 18 15:47:54 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Mon, 18 Nov 2024 15:47:54 +0000 Subject: Redesign interface dispatch: Coda In-Reply-To: References: <53d0c230-4d07-40a2-b5d9-0c5d71116e9b@redhat.com> <9a3bd769-e551-432d-ae19-34b16829509a@oracle.com> <48ea7e83-d459-40fb-acd7-fd65e93ca6f9@littlepinkcloud.com> Message-ID: <78d93a7f-431b-4928-8d81-20919dc65c49@littlepinkcloud.com> On 11/15/24 09:33, Erik Osterlund wrote: > So a big thank you to you for picking this up and thoroughly > investigating it. The answer seems to be that there is no such > missed opportunity, at this time. To me, your negative result is > very important. I think the key takeaway is that unpredictable call > patterns are going to fundamentally cause performance trouble > anyway, making even the most carefully tuned instruction sequences > slow, because of the inherent unpredictability that hardware can?t > cope with very well. Indeed so, and as hardware gets wider and wider the gap between predictable and unpredictable code performance continues to increase. Given that we can execute up to 10 instructions in parallel on some modern processors, and in practice sustain 6-7 instructions per clock on some, the gap must continue to widen. I was wondering what the fastest possible sequence of instructions to execute this benchmark might be, and I think I've found it. This is the standard benchmark, running on an 8-wide Apple M1 processor: [1] @Benchmark public int test1stInt5Types() { FirstInterface ai = as[step(asLength)]; return ai.getIntFirst(); } Benchmark (randomized) Mode Cnt Score Error Units test1stInt5Types false avgt 4 3.755 ? 0.016 ns/op test1stInt5Types:IPC false avgt 6.581 insns/clk test1stInt5Types:cycles:u false avgt 12.013 #/op test1stInt5Types:instructions:u false avgt 79.058 #/op test1stInt5Types true avgt 4 19.408 ? 0.041 ns/op test1stInt5Types:IPC true avgt 1.324 insns/clk test1stInt5Types:cycles:u true avgt 62.222 #/op test1stInt5Types:instructions:u true avgt 82.378 #/op Performance is very good when well predicted, 6.5 ish IPC. 1.3 IPC (very bad) when mispredicted. (Adbout 6.5 IPC seems to the limit on this CPU; at least I've never seen anything faster.) We can transform the benchmark to this, based on the types of the operands: @Benchmark public int test1stInt5TypesSwitch() { FirstInterface ai = as[step(asLength)]; return switch(ai) { case FirstClass o -> o.getIntFirst(); case SecondClass o -> o.getIntFirst(); case ThirdClass o -> o.getIntFirst(); case FourthClass o -> o.getIntFirst(); case FifthClass o -> o.getIntFirst(); default -> ai.getIntFirst(); }; } C2 generates excellent code for this version of the benchmark. Everything is inlined, so there is no call sequence, spills and fills, stubs, entry or exit barriers, no post-call NOPS, and so on: Benchmark (randomized) Mode Cnt Score Error Units Int5TypesSwitch false avgt 4 3.124 ? 0.068 ns/op Int5TypesSwitch:cycles: false avgt 9.987 #/op Int5TypesSwitch:IPC false avgt 4.850 insns/clk Int5TypesSwitch:instructions:u false avgt 48.443 #/op Int5TypesSwitch true avgt 4 13.128 ? 0.052 ns/op Int5TypesSwitch:cycles:u true avgt 42.037 #/op Int5TypesSwitch:IPC true avgt 1.201 insns/clk Int5TypesSwitch:instructions:u true avgt 50.482 #/op The really interesting thing for me, though, is that there is almost no difference in execution time between the two versions despite the switch version of the benchmark's greatly reduced instruction count - 79 versus 48.5. Despite executing far fewer instructions, the time per iteration is only reduced from 12 cycles to 10 cycles. This result answers a mystery that has been bothering me. Why, despite the substantial increase in per-call overhead over the last couple of years (entry and exit barriers + post-call NOPs) have we not seen a deterioration in performance? This is why. When we have added all that overhead, processors execute it in slots that would otherwise have nothing to do. (As Feynman put it in perhaps the greatest mic-drop moment ever, "I believe that has some significance for our problem.") It also answers another thing I've noticed several times. Why, sometimes, are JMH warmup times (mostly C1-compiled) faster than C2-compiled? I strongly suspect it's because stupid C1-compiled sequences may sometimes be more predictable than clever C2-compiled sequences. Finally, a note of caution. We can't keep adding overhead without seeing real-world performance degrade, because we'll run out of parallel resources. I don't know when that will be. [1] See https://x.com/Cardyak/status/1375164173282377730/photo/1 for more details about the architecture of the CPU. -- 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 ihse at openjdk.org Mon Nov 18 15:51:57 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 18 Nov 2024 15:51:57 GMT Subject: Withdrawn: 8333268: Fixes for static build In-Reply-To: References: Message-ID: On Thu, 30 May 2024 13:00:21 GMT, Magnus Ihse Bursie wrote: > This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will: > > 1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions). > > 2) Remove the work-arounds to exclude duplicated symbols. > > 3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher. > > The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/19478 From epeter at openjdk.org Mon Nov 18 16:20:34 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 16:20:34 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> <7h8Il7V3a1tbo_U2y2GyUY2tH8UPXtKc3we3ZZi47d4=.4a4cbe88-92a5-43cf-a6a9-48d0bed41cf7@github.com> <6rwCNBLV4-VemVsKR8KWYEgSIKfHQxS_RuxsPwX7TZo=.5fe167a3-1f97-408d-9d41-23d4d0fb42df@github.com> Message-ID: <-uhyD7i_oXhrCIMqAvFf7nt6DsjM6OY-_erP6UDAitg=.bb94ed2c-75f1-4d7a-b45a-113a5886a268@github.com> On Mon, 18 Nov 2024 15:20:17 GMT, Quan Anh Mai wrote: >> @merykitty I guess we can always use [vmovdqu](https://www.felixcloutier.com/x86/movdqu:vmovdqu8:vmovdqu16:vmovdqu32:vmovdqu64). >> >> And in fact that is exactly what we do: >> >> public class Test { >> static int RANGE = 1024*1024; >> >> public static void main(String[] args) { >> byte[] aB = new byte[RANGE]; >> byte[] bB = new byte[RANGE]; >> for (int i = 0; i < 100_000; i++) { >> test1(aB, bB); >> } >> } >> >> static void test1(byte[] a, byte[] b) { >> for (int i = 0; i < RANGE; i++) { >> a[i] = b[i]; >> } >> } >> } >> >> `../java -XX:CompileCommand=compileonly,Test::test* -XX:CompileCommand=printcompilation,Test::test* -XX:+TraceLoopOpts -XX:-TraceSuperWord -XX:+TraceNewVectors -Xbatch -XX:+AlignVector -XX:CompileCommand=compileonly,Test::test* -XX:CompileCommand=printassembly,Test::test* Test.java` >> >> >> ;; B20: # out( B20 B21 ) <- in( B19 B20 ) Loop( B20-B20 inner main of N178 strip mined) Freq: 8.13586e+09 >> 0x00007fc3a4bb0780: movslq %ebx,%rdi >> 0x00007fc3a4bb0783: movslq %ebx,%r14 >> 0x00007fc3a4bb0786: vmovdqu32 0x10(%r13,%r14,1),%zmm1 >> 0x00007fc3a4bb0791: vmovdqu32 %zmm1,0x10(%r9,%r14,1) >> 0x00007fc3a4bb079c: vmovdqu32 0x50(%r13,%rdi,1),%zmm1 >> 0x00007fc3a4bb07a7: vmovdqu32 %zmm1,0x50(%r9,%rdi,1) >> 0x00007fc3a4bb07b2: vmovdqu32 0x90(%r13,%rdi,1),%zmm1 >> 0x00007fc3a4bb07bd: vmovdqu32 %zmm1,0x90(%r9,%rdi,1) >> 0x00007fc3a4bb07c8: vmovdqu32 0xd0(%r13,%rdi,1),%zmm1 >> 0x00007fc3a4bb07d3: vmovdqu32 %zmm1,0xd0(%r9,%rdi,1) >> 0x00007fc3a4bb07de: vmovdqu32 0x110(%r13,%rdi,1),%zmm1 >> 0x00007fc3a4bb07e9: vmovdqu32 %zmm1,0x110(%r9,%rdi,1) >> 0x00007fc3a4bb07f4: vmovdqu32 0x150(%r13,%rdi,1),%zmm1 >> 0x00007fc3a4bb07ff: vmovdqu32 %zmm1,0x150(%r9,%rdi,1) >> 0x00007fc3a4bb080a: vmovdqu32 0x190(%r13,%rdi,1),%zmm1 >> 0x00007fc3a4bb0815: vmovdqu32 %zmm1,0x190(%r9,%rdi,1) >> 0x00007fc3a4bb0820: vmovdqu32 0x1d0(%r13,%rdi,1),%zmm1 >> 0x00007fc3a4bb082b: vmovdqu32 %zmm1,0x1d0(%r9,%rdi,1) ;*bastore {reexecute=0 rethrow=0 return_oop=0} >> ; - Test::test1 at 14 (line 14) >> 0x00007fc3a4bb0836: add $0x200,%ebx ;*iinc {reexecute=0 rethrow=0 return_oop=0} >> ... > > @eme64 What I mean here is that `AlignVector` seems useless because the accesses are going to be misaligned either way. @merykitty FYI: `src/hotspot/share/opto/vectorization.hpp: static bool vectors_should_be_aligned() { return !Matcher::misaligned_vectors_ok() || AlignVector; }` The relevant code: src/hotspot/cpu/x86/matcher_x86.hpp: static constexpr bool misaligned_vectors_ok() { // x86 supports misaligned vectors store/load. static constexpr bool misaligned_vectors_ok() { return true; } src/hotspot/cpu/ppc/matcher_ppc.hpp: static constexpr bool misaligned_vectors_ok() { // PPC implementation uses VSX load/store instructions (if // SuperwordUseVSX) which support 4 byte but not arbitrary alignment static constexpr bool misaligned_vectors_ok() { return false; } src/hotspot/cpu/aarch64/matcher_aarch64.hpp: static constexpr bool misaligned_vectors_ok() { // aarch64 supports misaligned vectors store/load. static constexpr bool misaligned_vectors_ok() { return true; } src/hotspot/cpu/s390/matcher_s390.hpp: static constexpr bool misaligned_vectors_ok() { // z/Architecture does support misaligned store/load at minimal extra cost. static constexpr bool misaligned_vectors_ok() { return true; } src/hotspot/cpu/arm/matcher_arm.hpp: static constexpr bool misaligned_vectors_ok() { // ARM doesn't support misaligned vectors store/load. static constexpr bool misaligned_vectors_ok() { return false; } src/hotspot/cpu/riscv/matcher_riscv.hpp: static constexpr bool misaligned_vectors_ok() { // riscv supports misaligned vectors store/load. static constexpr bool misaligned_vectors_ok() { return true; } We can see that only PPC and ARM32 have such strict alignment requirements. And it turns out that PPC only needs 4-byte alignment, and ARM32 is fine with 8-byte alignment. So all of our platforms do not necessarily need full vector-width alignment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483505834 From amitkumar at openjdk.org Mon Nov 18 16:26:04 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 18 Nov 2024 16:26:04 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known [v2] In-Reply-To: <8rJm-SGh6DJyX-CsK_NcuU0EqStWHXWCermTPlg0SeY=.f303839d-8082-4479-a9a4-68cf02f8a0bf@github.com> References: <-JQWB9KRz1XLoT9GYTJhK5cqSWDxsmd7sjcVrYbCXHk=.650dabd7-65bc-4c8c-af86-b175a1102891@github.com> <8rJm-SGh6DJyX-CsK_NcuU0EqStWHXWCermTPlg0SeY=.f303839d-8082-4479-a9a4-68cf02f8a0bf@github.com> Message-ID: <0WVzowjsWXIUaeZyiw834AWw98Uv7syR5J2s4ChevAM=.476228a6-18f5-49db-8f90-dfedeebd9654@github.com> On Mon, 18 Nov 2024 14:31:51 GMT, Martin Doerr wrote: > Thanks for the update. Now, I only wonder about the `>= Z_V2` condition. How does this fit to > > https://github.com/openjdk/jdk/blob/dfddbcaab886b9baa731cd748bb7f547e1903b64/src/hotspot/cpu/s390/s390.ad#L745 > > ? I didn't get the question actually. You mean that why didn't preserve `Z_VR0` and `Z_VR1` ? Or why we are preserving vector register `VR16` to `VR31` ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22197#issuecomment-2483518051 From epeter at openjdk.org Mon Nov 18 16:32:28 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 16:32:28 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b Ah there are some exceptions: x86: `src/hotspot/cpu/x86/vm_version_x86.cpp: AlignVector = !UseUnalignedLoadStores;` if (supports_sse4_2()) { // new ZX cpus if (FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { UseUnalignedLoadStores = true; // use movdqu on newest ZX cpus } } So I suppose some older platforms may be affected, though I have not seen one yet. They would have to be missing the unaligned `movdqu` instructions. aarch64: `src/hotspot/cpu/aarch64/vm_version_aarch64.cpp: AlignVector = AvoidUnalignedAccesses;` // Ampere eMAG if (_cpu == CPU_AMCC && (_model == CPU_MODEL_EMAG) && (_variant == 0x3)) { if (FLAG_IS_DEFAULT(AvoidUnalignedAccesses)) { FLAG_SET_DEFAULT(AvoidUnalignedAccesses, true); } and // ThunderX if (_cpu == CPU_CAVIUM && (_model == 0xA1)) { guarantee(_variant != 0, "Pre-release hardware no longer supported."); if (FLAG_IS_DEFAULT(AvoidUnalignedAccesses)) { FLAG_SET_DEFAULT(AvoidUnalignedAccesses, true); } and // ThunderX2 if ((_cpu == CPU_CAVIUM && (_model == 0xAF)) || (_cpu == CPU_BROADCOM && (_model == 0x516))) { if (FLAG_IS_DEFAULT(AvoidUnalignedAccesses)) { FLAG_SET_DEFAULT(AvoidUnalignedAccesses, true); } and // HiSilicon TSV110 if (_cpu == CPU_HISILICON && _model == 0xd01) { if (FLAG_IS_DEFAULT(AvoidUnalignedAccesses)) { FLAG_SET_DEFAULT(AvoidUnalignedAccesses, true); } So yes, some platforms are affected. But they seem to be the exception. And again: we have only had `ObjectAlignmentInBytes=8` alignment for vectors since forever - and no platform vendor has ever complained about that. Arrays never had a stronger alignment guarantee than that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483528037 PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483531916 From mdoerr at openjdk.org Mon Nov 18 16:33:59 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 18 Nov 2024 16:33:59 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known [v2] In-Reply-To: <0WVzowjsWXIUaeZyiw834AWw98Uv7syR5J2s4ChevAM=.476228a6-18f5-49db-8f90-dfedeebd9654@github.com> References: <-JQWB9KRz1XLoT9GYTJhK5cqSWDxsmd7sjcVrYbCXHk=.650dabd7-65bc-4c8c-af86-b175a1102891@github.com> <8rJm-SGh6DJyX-CsK_NcuU0EqStWHXWCermTPlg0SeY=.f303839d-8082-4479-a9a4-68cf02f8a0bf@github.com> <0WVzowjsWXIUaeZyiw834AWw98Uv7syR5J2s4ChevAM=.476228a6-18f5-49db-8f90-dfedeebd9654@github.com> Message-ID: On Mon, 18 Nov 2024 16:22:36 GMT, Amit Kumar wrote: > > Thanks for the update. Now, I only wonder about the `>= Z_V2` condition. How does this fit to > > https://github.com/openjdk/jdk/blob/dfddbcaab886b9baa731cd748bb7f547e1903b64/src/hotspot/cpu/s390/s390.ad#L745 > > > > ? > > I didn't get the question actually. You mean that why didn't preserve `Z_VR0` and `Z_VR1` ? Or why we are preserving vector register `VR16` to `VR31` ? What's the reason for choosing `Z_V2`? Why are `Z_VR0` and `Z_VR1` excluded? Do `Z_VR0` to `Z_VR15` match the FP registers? If so, why are you saving and restoring `Z_V2` to `Z_V15` twice? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22197#issuecomment-2483538186 From amitkumar at openjdk.org Mon Nov 18 16:37:54 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 18 Nov 2024 16:37:54 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known [v2] In-Reply-To: References: <-JQWB9KRz1XLoT9GYTJhK5cqSWDxsmd7sjcVrYbCXHk=.650dabd7-65bc-4c8c-af86-b175a1102891@github.com> <8rJm-SGh6DJyX-CsK_NcuU0EqStWHXWCermTPlg0SeY=.f303839d-8082-4479-a9a4-68cf02f8a0bf@github.com> <0WVzowjsWXIUaeZyiw834AWw98Uv7syR5J2s4ChevAM=.476228a6-18f5-49db-8f90-dfedeebd9654@github.com> Message-ID: On Mon, 18 Nov 2024 16:31:05 GMT, Martin Doerr wrote: > Do Z_VR0 to Z_VR15 match the FP registers? Yes they do override. > If so, why are you saving and restoring Z_V2 to Z_V15 twice? Right, so register allocator will not use them, as it is not allowed to, So no need to preserve the 2nd-half. Right. Even if we use them manually we can preserve them ourselves. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22197#issuecomment-2483547656 From mdoerr at openjdk.org Mon Nov 18 16:51:44 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 18 Nov 2024 16:51:44 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known [v2] In-Reply-To: <-JQWB9KRz1XLoT9GYTJhK5cqSWDxsmd7sjcVrYbCXHk=.650dabd7-65bc-4c8c-af86-b175a1102891@github.com> References: <-JQWB9KRz1XLoT9GYTJhK5cqSWDxsmd7sjcVrYbCXHk=.650dabd7-65bc-4c8c-af86-b175a1102891@github.com> Message-ID: On Mon, 18 Nov 2024 13:32:59 GMT, Amit Kumar wrote: >> Adds SaveLiveRegister portion for vector registers also. >> >> Depends on https://github.com/openjdk/jdk/pull/22190. Once that PR gets integrated, will rebase and mark it ready for review. > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > suggestion from martin `Z_V16` to `Z_V31` should be preserved. Also see PPC64 implementation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22197#issuecomment-2483579067 From epeter at openjdk.org Mon Nov 18 16:52:22 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 16:52:22 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 15:00:51 GMT, Roman Kennke wrote: >>> @rkennke It just will (silently) not vectorize, thus running slower but still correct. >> >> Ok, I think we can live with that for now. >> >> As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away. >> >> The tests need fixing, though. > >> @rkennke >> >> > As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away. >> >> Ah. So we would eventually have not a `12-byte` but `8-byte` offset from base to payload? Would that happen in all cases? And could that happen before `UseCompactObjectHeaders` leaves experimental status? Because it is going to be a little annoying to adjust all vectorization tests for the special case of `UseCompactObjectHeaders + AlignVector`. Though I can surely do it. > > I am not sure if and when this is going to happen. When I presented the idea at JVMLS, I got some resistance. I am also not sure if we first leave experimental status for UCOH, and then introduce 4-byte headers under a new flag (or no flag?), or if we first do 4-byte headers and only leave experimental status once that is done. The latter sounds more reasonable to me. @rkennke Filed a bug to track this (we may close it as NotAnIssue, but this way people are aware / can find the analysis): [JDK-8344424](https://bugs.openjdk.org/browse/JDK-8344424): C2 SuperWord: mixed type loops do not vectorize with UseCompactObjectHeaders and AlignVector ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483579571 From rkennke at openjdk.org Mon Nov 18 17:00:24 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 18 Nov 2024 17:00:24 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 15:30:14 GMT, Magnus Ihse Bursie wrote: >> test/hotspot/jtreg/gtest/MetaspaceUtilsGtests.java line 1: >> >> >> This file was reduced to empty but not actually deleted. Can you fix it please. > > @rkennke Just making sure this is not being missed. Can you please open a JBS issue to correct this and the file below? I filed: https://bugs.openjdk.org/browse/JDK-8344425 @tstuefe is working on it (mostly checking that nothing important has been removed) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1846945329 From rkennke at openjdk.org Mon Nov 18 17:09:24 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 18 Nov 2024 17:09:24 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 15:00:51 GMT, Roman Kennke wrote: >>> @rkennke It just will (silently) not vectorize, thus running slower but still correct. >> >> Ok, I think we can live with that for now. >> >> As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away. >> >> The tests need fixing, though. > >> @rkennke >> >> > As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away. >> >> Ah. So we would eventually have not a `12-byte` but `8-byte` offset from base to payload? Would that happen in all cases? And could that happen before `UseCompactObjectHeaders` leaves experimental status? Because it is going to be a little annoying to adjust all vectorization tests for the special case of `UseCompactObjectHeaders + AlignVector`. Though I can surely do it. > > I am not sure if and when this is going to happen. When I presented the idea at JVMLS, I got some resistance. I am also not sure if we first leave experimental status for UCOH, and then introduce 4-byte headers under a new flag (or no flag?), or if we first do 4-byte headers and only leave experimental status once that is done. The latter sounds more reasonable to me. > @rkennke Filed a bug to track this (we may close it as NotAnIssue, but this way people are aware / can find the analysis): [JDK-8344424](https://bugs.openjdk.org/browse/JDK-8344424): C2 SuperWord: mixed type loops do not vectorize with UseCompactObjectHeaders and AlignVector Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483619681 From coleenp at openjdk.org Mon Nov 18 17:58:42 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 18 Nov 2024 17:58:42 GMT Subject: RFR: 8344247: Move objectWaiter field to VirtualThread instance In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 22:34:24 GMT, Patricio Chilano Mateo wrote: > Small follow-up change after JDK-8338383. This moves the `objectWaiter` field from the stackChunk to the VirtualThread instance. Only the top stackChunk uses this field so we could save some memory by just saving it in the virtual thread instance instead. Also, related methods `stackChunkOopDesc::current_pending_monitor` and `stackChunkOopDesc::current_waiting_monitor` are moved to the `java_lang_VirtualThread` class where they naturally belong, since these are the equivalent of the JavaThread methods but for an unmounted vthread. > Tested by running mach5 tiers1-3. > > Thanks, > Patricio This is a nice cleanup. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22124#pullrequestreview-2443328377 From szaldana at openjdk.org Mon Nov 18 19:02:15 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Mon, 18 Nov 2024 19:02:15 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v6] In-Reply-To: References: Message-ID: > Hi all, > > This PR addresses [8343700](https://bugs.openjdk.org/browse/JDK-8343700) where ceil_log2 looped endlessly if the input value has the highest bit set. > > I also dealt with the case where we try to find ceil_log2(1) which would've returned 1 as opposed to 0. > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: simpler ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22074/files - new: https://git.openjdk.org/jdk/pull/22074/files/8b251d1f..f9bac907 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22074&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22074&range=04-05 Stats: 12 lines in 2 files changed: 0 ins; 8 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22074.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22074/head:pull/22074 PR: https://git.openjdk.org/jdk/pull/22074 From szaldana at openjdk.org Mon Nov 18 19:02:15 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Mon, 18 Nov 2024 19:02:15 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v5] In-Reply-To: References: Message-ID: <7uXfTfJwpgKaUUc3PPuTpDxGASo4RcwPjpzmUtVI0mA=.3bc5d7e2-23ce-4c14-a715-d22a4d41e618@github.com> On Fri, 15 Nov 2024 23:50:19 GMT, Kim Barrett wrote: >> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: >> >> fixing assert > > src/hotspot/share/utilities/powerOfTwo.hpp line 134: > >> 132: break; >> 133: } >> 134: } > > But I think this could all be much "simpler"? I think this works: > > template::value)> > int ceil_log2(T value) { > assert(value > T(0), "Invalid value"); > return log2i_graceful(value - 1) + 1; > } Sure, I updated to your suggestion instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22074#discussion_r1847103282 From lmesnik at openjdk.org Mon Nov 18 19:53:30 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 18 Nov 2024 19:53:30 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v4] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/runtime/vmOperations.hpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/0fb641c9..55f0682c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From lmesnik at openjdk.org Mon Nov 18 20:00:09 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 18 Nov 2024 20:00:09 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v5] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: added printing of native id, renamed variables ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/55f0682c..2f1e3d71 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=03-04 Stats: 18 lines in 5 files changed: 10 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From lmesnik at openjdk.org Mon Nov 18 20:00:10 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 18 Nov 2024 20:00:10 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v3] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: On Mon, 18 Nov 2024 05:32:52 GMT, David Holmes wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> make test more robust > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Mutex.java line 70: > >> 68: public String name() { return CStringUtilities.getString(addr.getAddressAt(nameFieldOffset)); } >> 69: >> 70: public Address owner() { return addr.getAddressAt(ownerFieldOffset); } > > Printing the `osThread()->thread_id()` might be more useful than printing the address. sa updated to print native id for all threads, and address ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1847167169 From duke at openjdk.org Mon Nov 18 20:10:00 2024 From: duke at openjdk.org (Saint Wesonga) Date: Mon, 18 Nov 2024 20:10:00 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken In-Reply-To: References: <9C3_nSzX9UY6959Q1mpv1JpE7MMQ8l9JvRWUWSOuRQY=.e8928e43-8664-4de1-b240-3dca1f4ab4af@github.com> <31Dtdw2Xv9w5M6KbSN4lkHhpflbU3Nw123ZincFNHuk=.0c68c7e0-797b-4185-b59b-de2a49d29bd9@github.com> Message-ID: On Fri, 8 Nov 2024 09:43:47 GMT, Julian Waters wrote: >> If it's needed on AArch64 too, this should move to something in `os/windows` as David said. >> >> However, judging from the comment in https://github.com/openjdk/jdk/blob/c40bb7621c0e49581dac587b6900b6d281572813/src/hotspot/os/windows/sharedRuntimeRem.cpp#L34-L38 this workaround might not be needed anymore. The minimum version required for Windows-AArch64 is VS2017 (or even VS2019?), and for Windows-X64 apparently VS2022 is used (not sure what the minimum is): https://github.com/openjdk/jdk/blob/c40bb7621c0e49581dac587b6900b6d281572813/make/conf/jib-profiles.js#L1105 >> >> >> So maybe this can be removed altogether? Someone needs to check if this assumption is still true today. >> >> Alas I don't have a Windows setup anymore. @karianna who is the local HotSpot Windows expert these days who could have a look at this? ? > > I don't think this workaround was intended for ARM64 in the first place, it explicitly mentions that it was written for x64, and the ifdef mess that resulted in this bug ended up bringing it over to ARM64 @TheShermanTanker - this workaround is still needed on Windows AArch64. I haved filed https://developercommunity.visualstudio.com/t/fmod-incorrectly-returns-NaN-on-certain-/10793176 to track a fix for the underlying fmod bug. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1847195717 From coleenp at openjdk.org Mon Nov 18 20:42:15 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 18 Nov 2024 20:42:15 GMT Subject: RFR: 8344445: MethodCounters don't need a vptr Message-ID: <0WPjPOxGnTB0Ba_IcWxUr6oa4ClIOca7PV0G6kHVQ6g=.f1093c4e-03d7-4b77-8a0e-81d64d76dbf8@github.com> This is a somewhat trivial change to make MethodCounters inherit from MetaspaceObj so that they don't have any virtual functions (and vptrs). They're just a bunch of ints. Tested with tier1-4. ------------- Commit messages: - 8344445: MethodCounters don't need a vptr Changes: https://git.openjdk.org/jdk/pull/22220/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22220&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344445 Stats: 14 lines in 3 files changed: 3 ins; 5 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/22220.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22220/head:pull/22220 PR: https://git.openjdk.org/jdk/pull/22220 From pchilanomate at openjdk.org Mon Nov 18 20:51:47 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 18 Nov 2024 20:51:47 GMT Subject: RFR: 8344247: Move objectWaiter field to VirtualThread instance In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 22:34:24 GMT, Patricio Chilano Mateo wrote: > Small follow-up change after JDK-8338383. This moves the `objectWaiter` field from the stackChunk to the VirtualThread instance. Only the top stackChunk uses this field so we could save some memory by just saving it in the virtual thread instance instead. Also, related methods `stackChunkOopDesc::current_pending_monitor` and `stackChunkOopDesc::current_waiting_monitor` are moved to the `java_lang_VirtualThread` class where they naturally belong, since these are the equivalent of the JavaThread methods but for an unmounted vthread. > Tested by running mach5 tiers1-3. > > Thanks, > Patricio Thanks for the reviews David and Coleen! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22124#issuecomment-2484098204 From pchilanomate at openjdk.org Mon Nov 18 20:51:47 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 18 Nov 2024 20:51:47 GMT Subject: Integrated: 8344247: Move objectWaiter field to VirtualThread instance In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 22:34:24 GMT, Patricio Chilano Mateo wrote: > Small follow-up change after JDK-8338383. This moves the `objectWaiter` field from the stackChunk to the VirtualThread instance. Only the top stackChunk uses this field so we could save some memory by just saving it in the virtual thread instance instead. Also, related methods `stackChunkOopDesc::current_pending_monitor` and `stackChunkOopDesc::current_waiting_monitor` are moved to the `java_lang_VirtualThread` class where they naturally belong, since these are the equivalent of the JavaThread methods but for an unmounted vthread. > Tested by running mach5 tiers1-3. > > Thanks, > Patricio This pull request has now been integrated. Changeset: f6366748 Author: Patricio Chilano Mateo URL: https://git.openjdk.org/jdk/commit/f636674889f925d4feb9a8d2be811e66f9b3a0ac Stats: 115 lines in 12 files changed: 39 ins; 62 del; 14 mod 8344247: Move objectWaiter field to VirtualThread instance Reviewed-by: dholmes, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/22124 From lmesnik at openjdk.org Mon Nov 18 20:56:27 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 18 Nov 2024 20:56:27 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v6] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: tests using osthread fixed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/2f1e3d71..056ec87a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=04-05 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From wkemper at openjdk.org Mon Nov 18 22:32:02 2024 From: wkemper at openjdk.org (William Kemper) Date: Mon, 18 Nov 2024 22:32:02 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <2m-YJkwNcpIEDdVElZOw2uqbTD6eOoBM0cRGoSFdADM=.86118c91-b8dd-4da9-b691-5ffe0643f51d@github.com> Message-ID: On Fri, 15 Nov 2024 15:12:30 GMT, Martin Doerr wrote: >> The new test TestAllocOutOfMemory.java#large failed on some PPC64 machines: >> >> Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main" >> >> java.lang.RuntimeException: 'java.lang.OutOfMemoryError: Java heap space' missing from stdout/stderr >> >> Probably not a show-stopper. Should the test be adapted or disabled for this platform? > >> @TheRealMDoerr - do you have the logs from the test failure? If so, could you open a ticket with them in JBS? Thank you! > > Filed [JDK-8344312](https://bugs.openjdk.org/browse/JDK-8344312). > > In addition, we see the following tests failing with "java.lang.OutOfMemoryError: Java heap space" on all Shenandoah platforms: > gc/stress/jfr/TestStressBigAllocationGCEventsWithShenandoah.java#default > gc/stress/jfr/TestStressBigAllocationGCEventsWithShenandoah.java#generational > Can you reproduce those? @TheRealMDoerr , it looks like @ysramakrishna has [filed a ticket already](https://bugs.openjdk.org/browse/JDK-8342786) for the `TestStressBigAllocationGCEventsWithShenandoah` failures. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2484266111 From vlivanov at openjdk.org Tue Nov 19 00:07:50 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 19 Nov 2024 00:07:50 GMT Subject: RFR: 8343541: C1: Plain memory accesses are emitted with membars with +AlwaysAtomicAccesses [v2] In-Reply-To: <9sZDi_ahHbkCWc7QRukVh7m8bvWbkRUvbtbG7FgkSc4=.714aac97-ace8-4357-846f-ed2e2b1f176d@github.com> References: <9sZDi_ahHbkCWc7QRukVh7m8bvWbkRUvbtbG7FgkSc4=.714aac97-ace8-4357-846f-ed2e2b1f176d@github.com> Message-ID: On Mon, 18 Nov 2024 09:30:54 GMT, Xiaolong Peng wrote: >> C1 and C2 has different implementations for `+AlwaysAtomicAccesses`, [C2 impl](https://github.com/openjdk/jdk/blob/4a7ce1d7c1bd4b751063b98cf8bedcd27055760b/src/hotspot/share/gc/shared/c2/barrierSetC2.cpp#L410) only guarantees atomicity hence no membars are emitted for plain memory access, but C1 treats it same as volatile access hence it emits membars. The change removes the unnecessary membars in C1 for `+AlwaysAtomicAccesses`. >> >> The test have been verified by very simple JMH benchmarks to measure the latency of reading/writing long/volatile long variable 10000 times, and run with VM option `-XX:TieredStopAtLevel=3 -XX:+UnlockExperimentalVMOptions -XX:+AlwaysAtomicAccesses`: >> >> Before the fix: >> >> Benchmark Mode Cnt Score Error Units >> AlwaysAtomicAccesses.testReadLong avgt 5 58711.131 ? 716.940 ns/op >> AlwaysAtomicAccesses.testReadVolatileLong avgt 5 59014.735 ? 675.354 ns/op >> AlwaysAtomicAccesses.testWriteLong avgt 5 115817.978 ? 302.089 ns/op >> AlwaysAtomicAccesses.testWriteVolatileLong avgt 5 116317.835 ? 1451.365 ns/op >> >> >> After the fix: >> >> Benchmark Mode Cnt Score Error Units >> AlwaysAtomicAccesses.testReadLong avgt 5 49651.527 ? 159.948 ns/op >> AlwaysAtomicAccesses.testReadVolatileLong avgt 5 58668.844 ? 316.029 ns/op >> AlwaysAtomicAccesses.testWriteLong avgt 5 23008.361 ? 10.947 ns/op >> AlwaysAtomicAccesses.testWriteVolatileLong avgt 5 116440.017 ? 1240.832 ns/op > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > renaming Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22191#pullrequestreview-2444025605 From fyang at openjdk.org Tue Nov 19 00:24:14 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 19 Nov 2024 00:24:14 GMT Subject: RFR: 8344393: RISC-V: Remove option UseRVVForBigIntegerShiftIntrinsics [v2] In-Reply-To: <1RvfDgpq--6vlc20BhLEcEEHvSu0CrFkAy4_8mhAqUU=.70da8c54-e487-4967-be8f-f9368dfb240b@github.com> References: <1RvfDgpq--6vlc20BhLEcEEHvSu0CrFkAy4_8mhAqUU=.70da8c54-e487-4967-be8f-f9368dfb240b@github.com> Message-ID: > Seem that it's more reasonable to control BigInteger shift intrinsics with`UseRVV` option. > I witnessed performance benefit on BPI-F3 with the RISC-V vector extension. And it's still > possible to disable these two intrinsics with `-XX:DisableIntrinsic` option if we want. > > JMH on BPI-F3 (has vector 1.0) for reference: > > Without instrinsic: > BigIntegers.testLeftShift N/A avgt 15 4083.865 ? 224.139 ns/op > BigIntegers.testRightShift N/A avgt 15 1745.833 ? 44.855 ns/op > > With instrinsic: > BigIntegers.testLeftShift N/A avgt 15 2243.095 ? 24.821 ns/op > BigIntegers.testRightShift N/A avgt 15 1558.770 ? 36.191 ns/op Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Remove jvmci use cases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22202/files - new: https://git.openjdk.org/jdk/pull/22202/files/95043a3b..987a535f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22202&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22202&range=00-01 Stats: 6 lines in 3 files changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22202.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22202/head:pull/22202 PR: https://git.openjdk.org/jdk/pull/22202 From fyang at openjdk.org Tue Nov 19 00:27:45 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 19 Nov 2024 00:27:45 GMT Subject: RFR: 8344393: RISC-V: Remove option UseRVVForBigIntegerShiftIntrinsics [v2] In-Reply-To: <4hV0ieiN1HmDSVbAstGYj_YH7NcmuJ9DhzjvDDeUiWk=.c32fdaa3-8f43-4464-8e7c-a342f6898c18@github.com> References: <1RvfDgpq--6vlc20BhLEcEEHvSu0CrFkAy4_8mhAqUU=.70da8c54-e487-4967-be8f-f9368dfb240b@github.com> <4hV0ieiN1HmDSVbAstGYj_YH7NcmuJ9DhzjvDDeUiWk=.c32fdaa3-8f43-4464-8e7c-a342f6898c18@github.com> Message-ID: On Mon, 18 Nov 2024 11:49:05 GMT, Hamlin Li wrote: >> Fei Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove jvmci use cases > > Make sense to me. Thanks! @Hamlin-Li @feilongjiang : Thanks for the review! I just found occurrences of this option in jvmci and added a bit more change to clean it up. Still looks good to you? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22202#issuecomment-2484449790 From fjiang at openjdk.org Tue Nov 19 02:33:55 2024 From: fjiang at openjdk.org (Feilong Jiang) Date: Tue, 19 Nov 2024 02:33:55 GMT Subject: RFR: 8344393: RISC-V: Remove option UseRVVForBigIntegerShiftIntrinsics [v2] In-Reply-To: References: <1RvfDgpq--6vlc20BhLEcEEHvSu0CrFkAy4_8mhAqUU=.70da8c54-e487-4967-be8f-f9368dfb240b@github.com> Message-ID: On Tue, 19 Nov 2024 00:24:14 GMT, Fei Yang wrote: >> Seem that it's more reasonable to control BigInteger shift intrinsics with`UseRVV` option. >> I witnessed performance benefit on BPI-F3 with the RISC-V vector extension. And it's still >> possible to disable these two intrinsics with `-XX:DisableIntrinsic` option if we want. >> >> JMH on BPI-F3 (has vector 1.0) for reference: >> >> Without instrinsic: >> BigIntegers.testLeftShift N/A avgt 15 4083.865 ? 224.139 ns/op >> BigIntegers.testRightShift N/A avgt 15 1745.833 ? 44.855 ns/op >> >> With instrinsic: >> BigIntegers.testLeftShift N/A avgt 15 2243.095 ? 24.821 ns/op >> BigIntegers.testRightShift N/A avgt 15 1558.770 ? 36.191 ns/op > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Remove jvmci use cases Marked as reviewed by fjiang (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22202#pullrequestreview-2444160013 From dlong at openjdk.org Tue Nov 19 02:59:43 2024 From: dlong at openjdk.org (Dean Long) Date: Tue, 19 Nov 2024 02:59:43 GMT Subject: RFR: 8344445: MethodCounters don't need a vptr In-Reply-To: <0WPjPOxGnTB0Ba_IcWxUr6oa4ClIOca7PV0G6kHVQ6g=.f1093c4e-03d7-4b77-8a0e-81d64d76dbf8@github.com> References: <0WPjPOxGnTB0Ba_IcWxUr6oa4ClIOca7PV0G6kHVQ6g=.f1093c4e-03d7-4b77-8a0e-81d64d76dbf8@github.com> Message-ID: On Mon, 18 Nov 2024 20:37:45 GMT, Coleen Phillimore wrote: > This is a somewhat trivial change to make MethodCounters inherit from MetaspaceObj so that they don't have any virtual functions (and vptrs). They're just a bunch of ints. > > Tested with tier1-4. Marked as reviewed by dlong (Reviewer). src/hotspot/share/oops/methodCounters.hpp line 61: > 59: void deallocate_contents(ClassLoaderData* loader_data) {} > 60: > 61: void metaspace_pointers_do(MetaspaceClosure* it) { return; } Does it change the behavior if we remove this along with ` it->push(&_method_counters);` in Method::metaspace_pointers_do? ------------- PR Review: https://git.openjdk.org/jdk/pull/22220#pullrequestreview-2444181429 PR Review Comment: https://git.openjdk.org/jdk/pull/22220#discussion_r1847569440 From amitkumar at openjdk.org Tue Nov 19 03:51:43 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 19 Nov 2024 03:51:43 GMT Subject: RFR: 8343884: [s390x] Disallow OptoScheduling In-Reply-To: References: Message-ID: <_E9CPZJbsG21B4BWbbhJpOAuYWcEaCg0tDQP1DA2YkI=.b83a5dcc-9a6d-41b6-b5c7-6f664d0bcd9b@github.com> On Wed, 13 Nov 2024 06:19:44 GMT, Amit Kumar wrote: > amit at a3560042:~/jdk$ ./build/linux-s390x-server-fastdebug/jdk/bin/java -XX:+OptoScheduling --version > OpenJDK 64-Bit Server VM warning: OptoScheduling is not supported on this CPU. > openjdk 24-internal 2025-03-18 > OpenJDK Runtime Environment (fastdebug build 24-internal-adhoc.amit.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 24-internal-adhoc.amit.jdk, mixed mode) > amit at a3560042:~/jdk$ @RealLucy another trivial change :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/22059#issuecomment-2484649614 From amitkumar at openjdk.org Tue Nov 19 05:24:26 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 19 Nov 2024 05:24:26 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known [v3] In-Reply-To: References: Message-ID: > Adds SaveLiveRegister portion for vector registers also. > > Depends on https://github.com/openjdk/jdk/pull/22190. Once that PR gets integrated, will rebase and mark it ready for review. Amit Kumar 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 v_test_failure_v0 - additional changes - suggestion from martin - no more ignoring vector registers fix' ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22197/files - new: https://git.openjdk.org/jdk/pull/22197/files/c6928c4b..b7b00aaa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22197&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22197&range=01-02 Stats: 4527 lines in 204 files changed: 106 ins; 3465 del; 956 mod Patch: https://git.openjdk.org/jdk/pull/22197.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22197/head:pull/22197 PR: https://git.openjdk.org/jdk/pull/22197 From amitkumar at openjdk.org Tue Nov 19 05:24:26 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 19 Nov 2024 05:24:26 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known [v2] In-Reply-To: <-JQWB9KRz1XLoT9GYTJhK5cqSWDxsmd7sjcVrYbCXHk=.650dabd7-65bc-4c8c-af86-b175a1102891@github.com> References: <-JQWB9KRz1XLoT9GYTJhK5cqSWDxsmd7sjcVrYbCXHk=.650dabd7-65bc-4c8c-af86-b175a1102891@github.com> Message-ID: On Mon, 18 Nov 2024 13:32:59 GMT, Amit Kumar wrote: >> Adds SaveLiveRegister portion for vector registers also. >> >> Depends on https://github.com/openjdk/jdk/pull/22190. Once that PR gets integrated, will rebase and mark it ready for review. > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > suggestion from martin I looked ppc-abi and your changes. I want to push some additional changes: diff --git a/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp b/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp index 57d38170a4d..3fff500e47c 100644 --- a/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp +++ b/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp @@ -240,6 +240,7 @@ int SaveLiveRegisters::iterate_over_register_mask(IterationAction action, int of int reg_save_index = 0; RegMaskIterator live_regs_iterator(_reg_mask); + // Going to preserve the volatile registers which can be used by Register Allocator. while(live_regs_iterator.has_next()) { const OptoReg::Name opto_reg = live_regs_iterator.next(); @@ -251,8 +252,10 @@ int SaveLiveRegisters::iterate_over_register_mask(IterationAction action, int of const VMReg vm_reg = OptoReg::as_VMReg(opto_reg); if (vm_reg->is_Register()) { Register std_reg = vm_reg->as_Register(); - - if (std_reg->encoding() >= Z_R2->encoding() && std_reg->encoding() <= Z_R15->encoding()) { + // Z_R0 and Z_R1 will not be allocated by the register allocator, see s390.ad (Integer Register Classes) + // Z_R6 to Z_R15 are saved registers, except Z_R14 (see Z-Abi) + if (std_reg->encoding() == Z_R14->encoding() + || (std_reg->encoding() >= Z_R2->encoding() && std_reg->encoding() <= Z_R5->encoding())) { reg_save_index++; if (action == ACTION_SAVE) { @@ -265,7 +268,8 @@ int SaveLiveRegisters::iterate_over_register_mask(IterationAction action, int of } } else if (vm_reg->is_FloatRegister()) { FloatRegister fp_reg = vm_reg->as_FloatRegister(); - if (fp_reg->encoding() >= Z_F0->encoding() && fp_reg->encoding() <= Z_F15->encoding() + // Z_R1 will not be allocated by the register allocator, see s390.ad (Float Register Classes) + if (fp_reg->encoding() >= Z_F0->encoding() && fp_reg->encoding() <= Z_F7->encoding() && fp_reg->encoding() != Z_F1->encoding()) { reg_save_index++; @@ -279,7 +283,8 @@ int SaveLiveRegisters::iterate_over_register_mask(IterationAction action, int of } } else if (vm_reg->is_VectorRegister()) { VectorRegister vs_reg = vm_reg->as_VectorRegister(); - if (vs_reg->encoding() >= Z_V2->encoding() && vs_reg->encoding() <= Z_V31->encoding()) { + // Z_V0 to Z_V15 will not be allocated by the register allocator, see s390.ad (reg class z_v_reg) + if (vs_reg->encoding() >= Z_V16->encoding() && vs_reg->encoding() <= Z_V31->encoding()) { reg_save_index += 2; if (action == ACTION_SAVE) { __ z_vst(vs_reg, Address(Z_SP, offset - reg_save_index * BytesPerWord)); z_abi Does these seem any good ? I guess I have preserved many already-saved-registers. Maybe we can get rid of that ? Tier1 test are clean. We are ready for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22197#issuecomment-2483653718 PR Comment: https://git.openjdk.org/jdk/pull/22197#issuecomment-2484732180 From mdoerr at openjdk.org Tue Nov 19 05:24:26 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 19 Nov 2024 05:24:26 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known [v2] In-Reply-To: <-JQWB9KRz1XLoT9GYTJhK5cqSWDxsmd7sjcVrYbCXHk=.650dabd7-65bc-4c8c-af86-b175a1102891@github.com> References: <-JQWB9KRz1XLoT9GYTJhK5cqSWDxsmd7sjcVrYbCXHk=.650dabd7-65bc-4c8c-af86-b175a1102891@github.com> Message-ID: On Mon, 18 Nov 2024 13:32:59 GMT, Amit Kumar wrote: >> Adds SaveLiveRegister portion for vector registers also. >> >> Depends on https://github.com/openjdk/jdk/pull/22190. Once that PR gets integrated, will rebase and mark it ready for review. > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > suggestion from martin This makes sense. Only volatile registers which are allocated need to be saved and restored. You could also use `is_volatile()` functions from the `Register` class. The registers which are not allocated should not show up here because we get them from `live_regs_iterator.next()`. So, I think there's no need to filter them out. But you can filter them out. I have no objects. I had basically asked because of readability reasons. Sorry if my question was a bit confusing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22197#issuecomment-2484150790 From amitkumar at openjdk.org Tue Nov 19 05:24:26 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 19 Nov 2024 05:24:26 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known [v2] In-Reply-To: References: <-JQWB9KRz1XLoT9GYTJhK5cqSWDxsmd7sjcVrYbCXHk=.650dabd7-65bc-4c8c-af86-b175a1102891@github.com> Message-ID: On Mon, 18 Nov 2024 21:18:03 GMT, Martin Doerr wrote: > This makes sense. Only volatile registers which are allocated need to be saved and restored. You could also use `is_volatile()` functions from the `Register` class. The registers which are not allocated should not show up here because we get them from `live_regs_iterator.next()`. So, I think there's no need to filter them out. But you can filter them out. I have no objects. I had basically asked because of readability reasons. Sorry if my question was a bit confusing. No I guess your question was perfectly correct. My concept for "which register needs to be preserved" was a bit on the loose. But now I got idea. So thanks for that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22197#issuecomment-2484655449 From amitkumar at openjdk.org Tue Nov 19 05:24:27 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 19 Nov 2024 05:24:27 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known [v2] In-Reply-To: References: <-JQWB9KRz1XLoT9GYTJhK5cqSWDxsmd7sjcVrYbCXHk=.650dabd7-65bc-4c8c-af86-b175a1102891@github.com> Message-ID: On Tue, 19 Nov 2024 03:56:23 GMT, Amit Kumar wrote: >You could also use is_volatile() functions from the Register class. I tried to look, and see only case of `Z_R14` seems valid. Because that is the exception there (volatile and sandwiched between saved registers). In Float & Vector registers we have "almost" continuous register, except `Z_F1` but there `is_volatile()` method will do no good, because `Z_F1` is indeed volatile and not used by Register Allocator. So I dropped the use for `is_volatile()`. And kept the changes same. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22197#issuecomment-2484694165 From jwaters at openjdk.org Tue Nov 19 05:28:59 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 19 Nov 2024 05:28:59 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken In-Reply-To: References: <9C3_nSzX9UY6959Q1mpv1JpE7MMQ8l9JvRWUWSOuRQY=.e8928e43-8664-4de1-b240-3dca1f4ab4af@github.com> <31Dtdw2Xv9w5M6KbSN4lkHhpflbU3Nw123ZincFNHuk=.0c68c7e0-797b-4185-b59b-de2a49d29bd9@github.com> Message-ID: On Mon, 18 Nov 2024 20:06:54 GMT, Saint Wesonga wrote: >> I don't think this workaround was intended for ARM64 in the first place, it explicitly mentions that it was written for x64, and the ifdef mess that resulted in this bug ended up bringing it over to ARM64 > > @TheShermanTanker - this workaround is still needed on Windows AArch64. I haved filed https://developercommunity.visualstudio.com/t/fmod-incorrectly-returns-NaN-on-certain-/10793176 to track a fix for the underlying fmod bug. I'm astounded by how this happy accident looped all the way back around to being needed for ARM64, truly one of the funniest coincidences of all time ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1847662986 From jwaters at openjdk.org Tue Nov 19 05:34:34 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 19 Nov 2024 05:34:34 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v2] In-Reply-To: References: Message-ID: > Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely Julian Waters has updated the pull request incrementally with two additional commits since the last revision: - Revert sharedRuntime.cpp - Revert sharedRuntime_x86.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21627/files - new: https://git.openjdk.org/jdk/pull/21627/files/541d4f89..12e82f68 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=00-01 Stats: 62 lines in 2 files changed: 31 ins; 31 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21627.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21627/head:pull/21627 PR: https://git.openjdk.org/jdk/pull/21627 From dholmes at openjdk.org Tue Nov 19 07:08:53 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 19 Nov 2024 07:08:53 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v5] In-Reply-To: <44duw-bwTlAaNhATsWQA0Fn13fAK0gaCTCsrSGBzibg=.eb7fbcdf-6229-4d13-a3d8-0df6a948c4f5@github.com> References: <44duw-bwTlAaNhATsWQA0Fn13fAK0gaCTCsrSGBzibg=.eb7fbcdf-6229-4d13-a3d8-0df6a948c4f5@github.com> Message-ID: On Mon, 18 Nov 2024 12:39:32 GMT, Coleen Phillimore wrote: >> I don't see any difference in the callers in relation to this PR and the function is not presently declared `extern`. ?? > > There was an extern trace_class_resolution() function that called this _impl function that I removed, so renamed this impl function to trace_class_resolution(). > It's declared extern in jvm.hp file, and this 'extern' qualifier is added so it's easy to see that this is used externally. Sorry but not seeing that. It is declared in `jvm_misc.hpp` but not as `extern`. The original version was not `extern`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1847747913 From dholmes at openjdk.org Tue Nov 19 07:24:45 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 19 Nov 2024 07:24:45 GMT Subject: RFR: 8343541: C1: Plain memory accesses are emitted with membars with +AlwaysAtomicAccesses [v2] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 09:36:51 GMT, Aleksey Shipilev wrote: >>> It is a bit sad that we call `volatile_field_*` when we really mean atomic. But renaming that would lead to much deeper changes. So I am okay with doing just this, thanks. >> >> I'll fix it, it is not too deep, and they are only used by barrierSetC1.cpp > >> > It is a bit sad that we call `volatile_field_*` when we really mean atomic. But renaming that would lead to much deeper changes. So I am okay with doing just this, thanks. >> >> I'll fix it, it is not too deep, and they are only used by barrierSetC1.cpp > > No need. If we go down that road, we also want to rename `lir_move_volatile` and all that jazz, which would probably entail a few rounds of careful looking. Submit a follow-up issue for it instead. I guess @shipilev is the authorative source here, but my reading of JDK-8033380 is that it intended for all long/double accesses to be treated just like volatile double/long accesses - and hence wanted atomicity and membars. That said here we are 10 years down the track and the JMM update never eventuated. Is this code even still warranted? Does this mean the JMM update efforts are reviving? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22191#issuecomment-2484879745 From dholmes at openjdk.org Tue Nov 19 07:34:57 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 19 Nov 2024 07:34:57 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v6] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: <2L7z3oaJ_Dqa2Zx675YdrECyfC-8ZzfoGLPsl33dTyA=.d2c5df4f-74bf-4274-ae75-a8cb134f5664@github.com> On Mon, 18 Nov 2024 20:56:27 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > tests using osthread fixed Thanks for updates. svc folk will need to do actual Review though. ------------- PR Review: https://git.openjdk.org/jdk/pull/22171#pullrequestreview-2444494159 From shade at openjdk.org Tue Nov 19 07:40:42 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 19 Nov 2024 07:40:42 GMT Subject: RFR: 8343541: C1: Plain memory accesses are emitted with membars with +AlwaysAtomicAccesses [v2] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 09:36:51 GMT, Aleksey Shipilev wrote: >>> It is a bit sad that we call `volatile_field_*` when we really mean atomic. But renaming that would lead to much deeper changes. So I am okay with doing just this, thanks. >> >> I'll fix it, it is not too deep, and they are only used by barrierSetC1.cpp > >> > It is a bit sad that we call `volatile_field_*` when we really mean atomic. But renaming that would lead to much deeper changes. So I am okay with doing just this, thanks. >> >> I'll fix it, it is not too deep, and they are only used by barrierSetC1.cpp > > No need. If we go down that road, we also want to rename `lir_move_volatile` and all that jazz, which would probably entail a few rounds of careful looking. Submit a follow-up issue for it instead. > I guess @shipilev is the authorative source here, but my reading of JDK-8033380 is that it intended for all long/double accesses to be treated just like volatile double/long accesses - and hence wanted atomicity and membars. Atomic here means single-copy atomicity, not memory ordering. So this PR does the semantics right. > That said here we are 10 years down the track and the JMM update never eventuated. Is this code even still warranted? Does this mean the JMM update efforts are reviving? Context: one of our high-load services uses `long` counters, and we are looking for the ways to guarantee single-copy atomicity for them without going for `volatile long`. It "kinda" works that way on 64-bit platforms, but we want to be extra sure. If that project ran on JDK 9+ language level, we would have used `VarHandle.(get|set)Opaque`. On JDK 8 language level, we could use `LongAdder` if we could have accepted the larger per-counter footprint. But when we cannot afford `LongAdder`, then on modern JVM we can use plain `long` field with `-XX:+AlwaysAtomicAccesses`. So this option is still marginally useful, albeit in darker corner cases :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/22191#issuecomment-2484898519 From kbarrett at openjdk.org Tue Nov 19 08:16:45 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 19 Nov 2024 08:16:45 GMT Subject: RFR: 8344445: MethodCounters don't need a vptr In-Reply-To: <0WPjPOxGnTB0Ba_IcWxUr6oa4ClIOca7PV0G6kHVQ6g=.f1093c4e-03d7-4b77-8a0e-81d64d76dbf8@github.com> References: <0WPjPOxGnTB0Ba_IcWxUr6oa4ClIOca7PV0G6kHVQ6g=.f1093c4e-03d7-4b77-8a0e-81d64d76dbf8@github.com> Message-ID: On Mon, 18 Nov 2024 20:37:45 GMT, Coleen Phillimore wrote: > This is a somewhat trivial change to make MethodCounters inherit from MetaspaceObj so that they don't have any virtual functions (and vptrs). They're just a bunch of ints. > > Tested with tier1-4. Changes requested by kbarrett (Reviewer). src/hotspot/share/oops/methodCounters.hpp line 66: > 64: return align_up((int)sizeof(MethodCounters), wordSize) / wordSize; > 65: } > 66: int size() const { size() could be static (MetaspaceObj description allows this), with method_counters_size impl moved here. Then remove method_counters_size and update the two calls to MethodCounters::size(). ------------- PR Review: https://git.openjdk.org/jdk/pull/22220#pullrequestreview-2444650825 PR Review Comment: https://git.openjdk.org/jdk/pull/22220#discussion_r1847864553 From kbarrett at openjdk.org Tue Nov 19 08:16:45 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 19 Nov 2024 08:16:45 GMT Subject: RFR: 8344445: MethodCounters don't need a vptr In-Reply-To: References: <0WPjPOxGnTB0Ba_IcWxUr6oa4ClIOca7PV0G6kHVQ6g=.f1093c4e-03d7-4b77-8a0e-81d64d76dbf8@github.com> Message-ID: On Tue, 19 Nov 2024 02:55:32 GMT, Dean Long wrote: >> This is a somewhat trivial change to make MethodCounters inherit from MetaspaceObj so that they don't have any virtual functions (and vptrs). They're just a bunch of ints. >> >> Tested with tier1-4. > > src/hotspot/share/oops/methodCounters.hpp line 61: > >> 59: void deallocate_contents(ClassLoaderData* loader_data) {} >> 60: >> 61: void metaspace_pointers_do(MetaspaceClosure* it) { return; } > > Does it change the behavior if we remove this along with > ` it->push(&_method_counters);` > in Method::metaspace_pointers_do? That would violate the contract for MetaspaceObj. https://github.com/openjdk/jdk/blob/499186be0fa70dba4b008cdafb72aba6addb2965/src/hotspot/share/memory/allocation.hpp#L247-L261 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22220#discussion_r1847855702 From kbarrett at openjdk.org Tue Nov 19 08:34:46 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 19 Nov 2024 08:34:46 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v5] In-Reply-To: <7uXfTfJwpgKaUUc3PPuTpDxGASo4RcwPjpzmUtVI0mA=.3bc5d7e2-23ce-4c14-a715-d22a4d41e618@github.com> References: <7uXfTfJwpgKaUUc3PPuTpDxGASo4RcwPjpzmUtVI0mA=.3bc5d7e2-23ce-4c14-a715-d22a4d41e618@github.com> Message-ID: On Mon, 18 Nov 2024 18:58:45 GMT, Sonia Zaldana Calles wrote: >> src/hotspot/share/utilities/powerOfTwo.hpp line 134: >> >>> 132: break; >>> 133: } >>> 134: } >> >> But I think this could all be much "simpler"? I think this works: >> >> template::value)> >> int ceil_log2(T value) { >> assert(value > T(0), "Invalid value"); >> return log2i_graceful(value - 1) + 1; >> } > > Sure, I updated to your suggestion instead. The use of `T(0)` in the assert isn't necessary; just use `0`. Sorry about that. Note that I didn't actually test that suggestion, just pencil and paper hand checked it. It looks like the new tests cover the needed values though. Except shouldn't there be a death test for 0? Just one, I don't think you need to death-test all covered types; death tests are kind of expensive to execute, since they need their own VM. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22074#discussion_r1847892247 From aph at openjdk.org Tue Nov 19 09:45:24 2024 From: aph at openjdk.org (Andrew Haley) Date: Tue, 19 Nov 2024 09:45:24 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b > So yes, some platforms [have alignment requirements for vectors]. But they seem to be the exception. All AArch64 implementations work with unaligned vectors ? that's in the architecture spec ? but some designs thaht were made years ago performed badly. It's not a problem with new designs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2485185002 From mli at openjdk.org Tue Nov 19 09:46:45 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 19 Nov 2024 09:46:45 GMT Subject: RFR: 8344393: RISC-V: Remove option UseRVVForBigIntegerShiftIntrinsics [v2] In-Reply-To: References: <1RvfDgpq--6vlc20BhLEcEEHvSu0CrFkAy4_8mhAqUU=.70da8c54-e487-4967-be8f-f9368dfb240b@github.com> Message-ID: On Tue, 19 Nov 2024 00:24:14 GMT, Fei Yang wrote: >> Seem that it's more reasonable to control BigInteger shift intrinsics with`UseRVV` option. >> I witnessed performance benefit on BPI-F3 with the RISC-V vector extension. And it's still >> possible to disable these two intrinsics with `-XX:DisableIntrinsic` option if we want. >> >> JMH on BPI-F3 (has vector 1.0) for reference: >> >> Without instrinsic: >> BigIntegers.testLeftShift N/A avgt 15 4083.865 ? 224.139 ns/op >> BigIntegers.testRightShift N/A avgt 15 1745.833 ? 44.855 ns/op >> >> With instrinsic: >> BigIntegers.testLeftShift N/A avgt 15 2243.095 ? 24.821 ns/op >> BigIntegers.testRightShift N/A avgt 15 1558.770 ? 36.191 ns/op >> >> >> Test on linux-riscv64 platform: >> - [x] tier1 (release) > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Remove jvmci use cases Still good. Thanks! ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22202#pullrequestreview-2444891588 From stefank at openjdk.org Tue Nov 19 10:06:46 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 19 Nov 2024 10:06:46 GMT Subject: RFR: 8340422: ZGC: TestAllocateHeapAt.java should not run with transparent hugepages [v3] In-Reply-To: References: <7DtNgJ7IORWdKXdZwQsKuWLDG8uZJmGLAQaoFbGcg9I=.95486530-8384-4f65-b0a4-8793139078dd@github.com> Message-ID: On Mon, 4 Nov 2024 14:28:45 GMT, Axel Boldt-Christmas wrote: >> Similarly to [JDK-8340146](https://bugs.openjdk.org/browse/JDK-8340146) / #21127 does not work well with transparent hugepages. >> >> Because a machine may be configured in such a way that UseTransperetHugePages option gets ignored, the test driver must also check if it will be. As such I extracted the `test/hotspot/jtreg/runtime/os/HugePageConfiguration.java` utility into shared test library. >> >> On none linux machines the `vm.opt.final.UseTransparentHugePages` will be null, but the test checks `os.family == "linux"` first. I have not observed an issue with the JTREG filter on none linux machines. But will double check that it does not cause an issue. > > Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8340422 > - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8340422 > - 8340422: ZGC: TestAllocateHeapAt.java should not run with transparent hugepages Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21129#pullrequestreview-2444943900 From lucy at openjdk.org Tue Nov 19 10:07:49 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Tue, 19 Nov 2024 10:07:49 GMT Subject: RFR: 8343884: [s390x] Disallow OptoScheduling In-Reply-To: References: Message-ID: <1mM1OBiF2DVDPoYnLsYhNtcIiNBx7KC3wE2scR5qp_c=.389a4e7a-98e5-446f-9e92-3daf3859480b@github.com> On Wed, 13 Nov 2024 06:19:44 GMT, Amit Kumar wrote: > amit at a3560042:~/jdk$ ./build/linux-s390x-server-fastdebug/jdk/bin/java -XX:+OptoScheduling --version > OpenJDK 64-Bit Server VM warning: OptoScheduling is not supported on this CPU. > openjdk 24-internal 2025-03-18 > OpenJDK Runtime Environment (fastdebug build 24-internal-adhoc.amit.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 24-internal-adhoc.amit.jdk, mixed mode) > amit at a3560042:~/jdk$ This one looks good, and is trivial and helpful. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22059#pullrequestreview-2444946406 From amitkumar at openjdk.org Tue Nov 19 10:19:58 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 19 Nov 2024 10:19:58 GMT Subject: RFR: 8343884: [s390x] Disallow OptoScheduling In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 06:19:44 GMT, Amit Kumar wrote: > amit at a3560042:~/jdk$ ./build/linux-s390x-server-fastdebug/jdk/bin/java -XX:+OptoScheduling --version > OpenJDK 64-Bit Server VM warning: OptoScheduling is not supported on this CPU. > openjdk 24-internal 2025-03-18 > OpenJDK Runtime Environment (fastdebug build 24-internal-adhoc.amit.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 24-internal-adhoc.amit.jdk, mixed mode) > amit at a3560042:~/jdk$ Thank you Lutz. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22059#issuecomment-2485265452 From amitkumar at openjdk.org Tue Nov 19 10:19:58 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 19 Nov 2024 10:19:58 GMT Subject: Integrated: 8343884: [s390x] Disallow OptoScheduling In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 06:19:44 GMT, Amit Kumar wrote: > amit at a3560042:~/jdk$ ./build/linux-s390x-server-fastdebug/jdk/bin/java -XX:+OptoScheduling --version > OpenJDK 64-Bit Server VM warning: OptoScheduling is not supported on this CPU. > openjdk 24-internal 2025-03-18 > OpenJDK Runtime Environment (fastdebug build 24-internal-adhoc.amit.jdk) > OpenJDK 64-Bit Server VM (fastdebug build 24-internal-adhoc.amit.jdk, mixed mode) > amit at a3560042:~/jdk$ This pull request has now been integrated. Changeset: 7540fa21 Author: Amit Kumar URL: https://git.openjdk.org/jdk/commit/7540fa2147ff8fc9c652ef13548f72f27e2809a8 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod 8343884: [s390x] Disallow OptoScheduling Reviewed-by: lucy ------------- PR: https://git.openjdk.org/jdk/pull/22059 From fyang at openjdk.org Tue Nov 19 10:23:51 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 19 Nov 2024 10:23:51 GMT Subject: RFR: 8344393: RISC-V: Remove option UseRVVForBigIntegerShiftIntrinsics [v2] In-Reply-To: References: <1RvfDgpq--6vlc20BhLEcEEHvSu0CrFkAy4_8mhAqUU=.70da8c54-e487-4967-be8f-f9368dfb240b@github.com> Message-ID: On Tue, 19 Nov 2024 02:30:51 GMT, Feilong Jiang wrote: >> Fei Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove jvmci use cases > > Marked as reviewed by fjiang (Committer). @feilongjiang @Hamlin-Li : Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22202#issuecomment-2485278128 From fyang at openjdk.org Tue Nov 19 10:23:52 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 19 Nov 2024 10:23:52 GMT Subject: Integrated: 8344393: RISC-V: Remove option UseRVVForBigIntegerShiftIntrinsics In-Reply-To: <1RvfDgpq--6vlc20BhLEcEEHvSu0CrFkAy4_8mhAqUU=.70da8c54-e487-4967-be8f-f9368dfb240b@github.com> References: <1RvfDgpq--6vlc20BhLEcEEHvSu0CrFkAy4_8mhAqUU=.70da8c54-e487-4967-be8f-f9368dfb240b@github.com> Message-ID: On Mon, 18 Nov 2024 11:25:15 GMT, Fei Yang wrote: > Seem that it's more reasonable to control BigInteger shift intrinsics with`UseRVV` option. > I witnessed performance benefit on BPI-F3 with the RISC-V vector extension. And it's still > possible to disable these two intrinsics with `-XX:DisableIntrinsic` option if we want. > > JMH on BPI-F3 (has vector 1.0) for reference: > > Without instrinsic: > BigIntegers.testLeftShift N/A avgt 15 4083.865 ? 224.139 ns/op > BigIntegers.testRightShift N/A avgt 15 1745.833 ? 44.855 ns/op > > With instrinsic: > BigIntegers.testLeftShift N/A avgt 15 2243.095 ? 24.821 ns/op > BigIntegers.testRightShift N/A avgt 15 1558.770 ? 36.191 ns/op > > > Test on linux-riscv64 platform: > - [x] tier1 (release) This pull request has now been integrated. Changeset: 0d666891 Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/0d66689177b880035e4047399e3e64f461713562 Stats: 10 lines in 6 files changed: 0 ins; 8 del; 2 mod 8344393: RISC-V: Remove option UseRVVForBigIntegerShiftIntrinsics Reviewed-by: mli, fjiang ------------- PR: https://git.openjdk.org/jdk/pull/22202 From amitkumar at openjdk.org Tue Nov 19 11:39:45 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 19 Nov 2024 11:39:45 GMT Subject: RFR: 8335367: [s390] Add support for load immediate on condition instructions. In-Reply-To: <2oJIrDqMf4MYKGz_s1K8D2aNjGwJJ75PY-gUOZwVEU0=.af1d8092-a680-4ea2-adf7-a9c3432509a3@github.com> References: <2oJIrDqMf4MYKGz_s1K8D2aNjGwJJ75PY-gUOZwVEU0=.af1d8092-a680-4ea2-adf7-a9c3432509a3@github.com> Message-ID: On Wed, 13 Nov 2024 06:16:23 GMT, Manjunath S Matti. wrote: > Add support for load immediate on condition instructions. minor nits to do, otherwise looks good. src/hotspot/cpu/s390/assembler_s390.hpp line 2076: > 2074: inline void z_lochi(Register r1, int64_t i2, branch_condition m3); // load immediate r1[32-64] = i2_imm16 ; int32 <- int16 > 2075: inline void z_lochhi(Register r1, int64_t i2, branch_condition m3); // load immediate r1[ 0-31] = i2_imm16 ; int32 <- int16 > 2076: inline void z_locghi(Register r1, int64_t i2, branch_condition m3); // load immediate r1[ 0-63] = i2_imm16 ; int64 <- int16 Suggestion: inline void z_lochi(Register r1, int64_t i2, branch_condition m3); // load immediate r1[32-63] = i2_simm16 ; int32 <- int16 inline void z_lochhi(Register r1, int64_t i2, branch_condition m3); // load immediate r1[ 0-31] = i2_simm16 ; int32 <- int16 inline void z_locghi(Register r1, int64_t i2, branch_condition m3); // load immediate r1[ 0-63] = i2_simm16 ; int64 <- int16 ------------- Changes requested by amitkumar (Committer). PR Review: https://git.openjdk.org/jdk/pull/22058#pullrequestreview-2445183949 PR Review Comment: https://git.openjdk.org/jdk/pull/22058#discussion_r1848184321 From coleenp at openjdk.org Tue Nov 19 12:23:08 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 19 Nov 2024 12:23:08 GMT Subject: RFR: 8344445: MethodCounters don't need a vptr [v2] In-Reply-To: <0WPjPOxGnTB0Ba_IcWxUr6oa4ClIOca7PV0G6kHVQ6g=.f1093c4e-03d7-4b77-8a0e-81d64d76dbf8@github.com> References: <0WPjPOxGnTB0Ba_IcWxUr6oa4ClIOca7PV0G6kHVQ6g=.f1093c4e-03d7-4b77-8a0e-81d64d76dbf8@github.com> Message-ID: > This is a somewhat trivial change to make MethodCounters inherit from MetaspaceObj so that they don't have any virtual functions (and vptrs). They're just a bunch of ints. > > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Remove method_pointers_size() in favor of static size(). ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22220/files - new: https://git.openjdk.org/jdk/pull/22220/files/fafb86ff..f0a55222 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22220&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22220&range=00-01 Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22220.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22220/head:pull/22220 PR: https://git.openjdk.org/jdk/pull/22220 From coleenp at openjdk.org Tue Nov 19 12:23:08 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 19 Nov 2024 12:23:08 GMT Subject: RFR: 8344445: MethodCounters don't need a vptr [v2] In-Reply-To: References: <0WPjPOxGnTB0Ba_IcWxUr6oa4ClIOca7PV0G6kHVQ6g=.f1093c4e-03d7-4b77-8a0e-81d64d76dbf8@github.com> Message-ID: On Tue, 19 Nov 2024 08:07:39 GMT, Kim Barrett wrote: >> src/hotspot/share/oops/methodCounters.hpp line 61: >> >>> 59: void deallocate_contents(ClassLoaderData* loader_data) {} >>> 60: >>> 61: void metaspace_pointers_do(MetaspaceClosure* it) { return; } >> >> Does it change the behavior if we remove this along with >> ` it->push(&_method_counters);` >> in Method::metaspace_pointers_do? > > That would violate the contract for MetaspaceObj. > https://github.com/openjdk/jdk/blob/499186be0fa70dba4b008cdafb72aba6addb2965/src/hotspot/share/memory/allocation.hpp#L247-L261 Yes it's a metaspace pointer. It's zeroed and not saved in the archive but it still needs to call this function in case it's not zeroed and someday called. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22220#discussion_r1848250136 From coleenp at openjdk.org Tue Nov 19 12:23:09 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 19 Nov 2024 12:23:09 GMT Subject: RFR: 8344445: MethodCounters don't need a vptr [v2] In-Reply-To: References: <0WPjPOxGnTB0Ba_IcWxUr6oa4ClIOca7PV0G6kHVQ6g=.f1093c4e-03d7-4b77-8a0e-81d64d76dbf8@github.com> Message-ID: On Tue, 19 Nov 2024 08:12:22 GMT, Kim Barrett wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove method_pointers_size() in favor of static size(). > > src/hotspot/share/oops/methodCounters.hpp line 66: > >> 64: return align_up((int)sizeof(MethodCounters), wordSize) / wordSize; >> 65: } >> 66: int size() const { > > size() could be static (MetaspaceObj description allows this), with method_counters_size impl moved > here. Then remove method_counters_size and update the two calls to MethodCounters::size(). Thanks - this is a nice cleanup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22220#discussion_r1848249238 From coleenp at openjdk.org Tue Nov 19 12:25:56 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 19 Nov 2024 12:25:56 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v5] In-Reply-To: References: <44duw-bwTlAaNhATsWQA0Fn13fAK0gaCTCsrSGBzibg=.eb7fbcdf-6229-4d13-a3d8-0df6a948c4f5@github.com> Message-ID: <61JEPJpF_UdZN0n4kaX5N6uYuD7iVsTunoGZFjJdWcE=.a48a091c-bbb3-4a23-95cc-305a948e7a93@github.com> On Tue, 19 Nov 2024 07:06:15 GMT, David Holmes wrote: >> There was an extern trace_class_resolution() function that called this _impl function that I removed, so renamed this impl function to trace_class_resolution(). >> It's declared extern in jvm.hp file, and this 'extern' qualifier is added so it's easy to see that this is used externally. > > Sorry but not seeing that. It is declared in `jvm_misc.hpp` but not as `extern`. The original version was not `extern`. You're right, it has extern linkage but not declared with extern. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1848255968 From mdoerr at openjdk.org Tue Nov 19 12:57:44 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 19 Nov 2024 12:57:44 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known [v3] In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 05:24:26 GMT, Amit Kumar wrote: >> Adds SaveLiveRegister portion for vector registers also. >> >> Depends on https://github.com/openjdk/jdk/pull/22190. Once that PR gets integrated, will rebase and mark it ready for review. > > Amit Kumar 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 v_test_failure_v0 > - additional changes > - suggestion from martin > - no more ignoring vector registers > > fix' Looks correct to me. I would probably not exclude F1. But if the decision not to use it for allocation is fixed, ok. @RealLucy: Please take a 2nd look. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22197#pullrequestreview-2445392827 From aturbanov at openjdk.org Tue Nov 19 13:29:49 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 19 Nov 2024 13:29:49 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v6] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: On Mon, 18 Nov 2024 20:56:27 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > tests using osthread fixed src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Mutex.java line 39: > 37: > 38: private static AddressField mutex_array; > 39: private static int maxNum; Let's align with `mutex_array` src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Mutex.java line 52: > 50: > 51: private static synchronized void initialize(TypeDataBase db) throws WrongTypeException { > 52: Type type = db.lookupType("Mutex"); Suggestion: Type type = db.lookupType("Mutex"); src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Mutex.java line 60: > 58: ownerFieldOffset = f.getOffset(); > 59: mutex_array = type.getAddressField("_mutex_array"); > 60: maxNum = type.getCIntegerField("_num_mutex").getJInt(); Suggestion: maxNum = type.getCIntegerField("_num_mutex").getJInt(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1848364844 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1848365330 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1848365177 From jbechberger at openjdk.org Tue Nov 19 14:30:23 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Tue, 19 Nov 2024 14:30:23 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v28] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Fix zero build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/46995b6a..7fff875c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=26-27 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From luhenry at openjdk.org Tue Nov 19 15:09:48 2024 From: luhenry at openjdk.org (Ludovic Henry) Date: Tue, 19 Nov 2024 15:09:48 GMT Subject: RFR: 8343827: RISC-V: set AlignVector as false if applicable to enable SLP In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 11:40:46 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > SLP vectorization in C2 checks the data alignment optionally, if fast misaliged access is supported by CPU it will skip the alignment check in SLP, this is good for both C2 compile time and run time (as more loops can be potentially vectorized. And the performance of vector implementation is good enough, which was already verified by existing tests (array copy, crc32, ...)). > On the other hand, we have some existing tests which verify that generated IRs should contain some specific Nodes, with the intrdocution of Compact Object Header, some tests related to SLP was observed failure which is due to the data offset change which is due to header change in the JEP, by enabling C2 SLP when fast misaliged access is supported, we should be able to resolve these issues. Although riscv support misaligned access optionally, started from RVA22 it's mandatory. > > Thanks! Marked as reviewed by luhenry (Committer). src/hotspot/cpu/riscv/vm_version_riscv.cpp line 174: > 172: > 173: if (FLAG_IS_DEFAULT(AlignVector)) { > 174: AlignVector = AvoidUnalignedAccesses; Nit: Should that be `FLAG_SET_DEFAULT(AlignVector, AvoidUnalignedAccesses)`? ------------- PR Review: https://git.openjdk.org/jdk/pull/21974#pullrequestreview-2445754560 PR Review Comment: https://git.openjdk.org/jdk/pull/21974#discussion_r1848532762 From luhenry at openjdk.org Tue Nov 19 15:09:49 2024 From: luhenry at openjdk.org (Ludovic Henry) Date: Tue, 19 Nov 2024 15:09:49 GMT Subject: RFR: 8343827: RISC-V: set AlignVector as false if applicable to enable SLP In-Reply-To: References: <0rUg0wmZafd2bryZhoWsF8J9ErP7ijXZxXw0OwMeoeY=.f0502abe-d80b-40eb-8c4c-a992bea3af9c@github.com> Message-ID: On Tue, 12 Nov 2024 09:52:51 GMT, Hamlin Li wrote: > > for this particular case, it has kernel 5.10 which has no hwprobe. so avoidUnaligned has to be disabled manually. > > Yes, the default behaviour is to use hwprobe to test the CPU features, so for k 230, the default behaviour should be fine, i.e. both AlignVector and AvoidUnalignedAccesses would be true, nothing changed. Should we argue that hwprobe should have two flags, one for scalar and one for vector? We can talk to some hardware folks for that ------------- PR Comment: https://git.openjdk.org/jdk/pull/21974#issuecomment-2485973418 From szaldana at openjdk.org Tue Nov 19 15:39:30 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 19 Nov 2024 15:39:30 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v7] In-Reply-To: References: Message-ID: > Hi all, > > This PR addresses [8343700](https://bugs.openjdk.org/browse/JDK-8343700) where ceil_log2 looped endlessly if the input value has the highest bit set. > > I also dealt with the case where we try to find ceil_log2(1) which would've returned 1 as opposed to 0. > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: More test cases and removing T(0) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22074/files - new: https://git.openjdk.org/jdk/pull/22074/files/f9bac907..9e4c99fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22074&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22074&range=05-06 Stats: 6 lines in 2 files changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22074.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22074/head:pull/22074 PR: https://git.openjdk.org/jdk/pull/22074 From szaldana at openjdk.org Tue Nov 19 15:39:30 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 19 Nov 2024 15:39:30 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v5] In-Reply-To: References: <7uXfTfJwpgKaUUc3PPuTpDxGASo4RcwPjpzmUtVI0mA=.3bc5d7e2-23ce-4c14-a715-d22a4d41e618@github.com> Message-ID: <6rMvLUi8vmMKEbNrr2pNaAB6snOjqrcZSHPvtdVGwxc=.18859212-ec84-4241-a53e-99d29c3b85a3@github.com> On Tue, 19 Nov 2024 08:32:43 GMT, Kim Barrett wrote: >> Sure, I updated to your suggestion instead. > > The use of `T(0)` in the assert isn't necessary; just use `0`. Sorry about that. > > Note that I didn't actually test that suggestion, just pencil and paper hand checked it. It looks like the new tests > cover the needed values though. Except shouldn't there be a death test for 0? Just one, I don't think you need > to death-test all covered types; death tests are kind of expensive to execute, since they need their own VM. I had tested your implementation but I added a few more test cases for peace of mind :-) I don't think we can do a death test because that would only get triggered for debug builds. I can't seem to find any in the code base either. Also fixed the T(0) issue. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22074#discussion_r1848590389 From kbarrett at openjdk.org Tue Nov 19 15:41:57 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 19 Nov 2024 15:41:57 GMT Subject: RFR: 8344445: MethodCounters don't need a vptr [v2] In-Reply-To: References: <0WPjPOxGnTB0Ba_IcWxUr6oa4ClIOca7PV0G6kHVQ6g=.f1093c4e-03d7-4b77-8a0e-81d64d76dbf8@github.com> Message-ID: On Tue, 19 Nov 2024 12:23:08 GMT, Coleen Phillimore wrote: >> This is a somewhat trivial change to make MethodCounters inherit from MetaspaceObj so that they don't have any virtual functions (and vptrs). They're just a bunch of ints. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove method_pointers_size() in favor of static size(). Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22220#pullrequestreview-2445857742 From kbarrett at openjdk.org Tue Nov 19 15:51:48 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 19 Nov 2024 15:51:48 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v5] In-Reply-To: <6rMvLUi8vmMKEbNrr2pNaAB6snOjqrcZSHPvtdVGwxc=.18859212-ec84-4241-a53e-99d29c3b85a3@github.com> References: <7uXfTfJwpgKaUUc3PPuTpDxGASo4RcwPjpzmUtVI0mA=.3bc5d7e2-23ce-4c14-a715-d22a4d41e618@github.com> <6rMvLUi8vmMKEbNrr2pNaAB6snOjqrcZSHPvtdVGwxc=.18859212-ec84-4241-a53e-99d29c3b85a3@github.com> Message-ID: On Tue, 19 Nov 2024 15:35:37 GMT, Sonia Zaldana Calles wrote: >> The use of `T(0)` in the assert isn't necessary; just use `0`. Sorry about that. >> >> Note that I didn't actually test that suggestion, just pencil and paper hand checked it. It looks like the new tests >> cover the needed values though. Except shouldn't there be a death test for 0? Just one, I don't think you need >> to death-test all covered types; death tests are kind of expensive to execute, since they need their own VM. > > I had tested your implementation but I added a few more test cases for peace of mind :-) > > I don't think we can do a death test because that would only get triggered for debug builds. I can't seem to find any in the code base either. > > Also fixed the T(0) issue. Thanks! Regarding death tests - look for tests using of `TEST_VM_ASSERT` and `TEST_VM_ASSERT_MSG`. They are only available in debug builds, and uses are wrapped in `#ifdef ASSERT`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22074#discussion_r1848614308 From mli at openjdk.org Tue Nov 19 16:01:04 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 19 Nov 2024 16:01:04 GMT Subject: RFR: 8343827: RISC-V: set AlignVector as false if applicable to enable SLP [v2] In-Reply-To: References: Message-ID: > Hi, > Can you help to review this patch? > > SLP vectorization in C2 checks the data alignment optionally, if fast misaliged access is supported by CPU it will skip the alignment check in SLP, this is good for both C2 compile time and run time (as more loops can be potentially vectorized. And the performance of vector implementation is good enough, which was already verified by existing tests (array copy, crc32, ...)). > On the other hand, we have some existing tests which verify that generated IRs should contain some specific Nodes, with the intrdocution of Compact Object Header, some tests related to SLP was observed failure which is due to the data offset change which is due to header change in the JEP, by enabling C2 SLP when fast misaliged access is supported, we should be able to resolve these issues. Although riscv support misaligned access optionally, started from RVA22 it's mandatory. > > Thanks! Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: refine code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21974/files - new: https://git.openjdk.org/jdk/pull/21974/files/696972ec..f13c006c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21974&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21974&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21974.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21974/head:pull/21974 PR: https://git.openjdk.org/jdk/pull/21974 From mli at openjdk.org Tue Nov 19 16:01:05 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 19 Nov 2024 16:01:05 GMT Subject: RFR: 8343827: RISC-V: set AlignVector as false if applicable to enable SLP In-Reply-To: References: <0rUg0wmZafd2bryZhoWsF8J9ErP7ijXZxXw0OwMeoeY=.f0502abe-d80b-40eb-8c4c-a992bea3af9c@github.com> Message-ID: On Tue, 19 Nov 2024 15:06:04 GMT, Ludovic Henry wrote: > Should we argue that hwprobe should have two flags, one for scalar and one for vector? We can talk to some hardware folks for that Good question, let's discuss later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21974#issuecomment-2486105865 From mli at openjdk.org Tue Nov 19 16:01:06 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 19 Nov 2024 16:01:06 GMT Subject: RFR: 8343827: RISC-V: set AlignVector as false if applicable to enable SLP In-Reply-To: References: <0rUg0wmZafd2bryZhoWsF8J9ErP7ijXZxXw0OwMeoeY=.f0502abe-d80b-40eb-8c4c-a992bea3af9c@github.com> Message-ID: On Tue, 12 Nov 2024 00:22:27 GMT, Fei Yang wrote: >> hello Hamlin, this could to be wrong. >> for example: kendryte 230 with c908 core with rv64gcv >> it has fast misaligned access but only for scalars(rv64gc), not for vectors(rvv) >> i dont know if it's just a corner case or a possible common practice in future. > >> hello Hamlin, this could to be wrong. for example: kendryte 230 with c908 core with rv64gcv it has fast misaligned access but only for scalars(rv64gc), not for vectors(rvv) i dont know if it's just a corner case or a possible common practice in future. > > Interesting. Could it be an issue for the kernel running on this platform? I don't understand why it would declare fast misaligned access when it's not the case for the vector part. @RealFYang @luhenry just made a minor improvement, can you take another look? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21974#issuecomment-2486107707 From mli at openjdk.org Tue Nov 19 16:01:07 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 19 Nov 2024 16:01:07 GMT Subject: RFR: 8343827: RISC-V: set AlignVector as false if applicable to enable SLP [v2] In-Reply-To: References: Message-ID: <8qEKpRmdVwz09Lvq4wvGlMHYU3oHw0viIV7CGMHOrqQ=.f56eb109-facd-4c39-8b44-88976feb7a38@github.com> On Tue, 19 Nov 2024 15:04:10 GMT, Ludovic Henry wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> refine code > > src/hotspot/cpu/riscv/vm_version_riscv.cpp line 174: > >> 172: >> 173: if (FLAG_IS_DEFAULT(AlignVector)) { >> 174: AlignVector = AvoidUnalignedAccesses; > > Nit: Should that be `FLAG_SET_DEFAULT(AlignVector, AvoidUnalignedAccesses)`? It makes sense to me, fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21974#discussion_r1848624405 From szaldana at openjdk.org Tue Nov 19 16:05:10 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 19 Nov 2024 16:05:10 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v8] In-Reply-To: References: Message-ID: > Hi all, > > This PR addresses [8343700](https://bugs.openjdk.org/browse/JDK-8343700) where ceil_log2 looped endlessly if the input value has the highest bit set. > > I also dealt with the case where we try to find ceil_log2(1) which would've returned 1 as opposed to 0. > > Cheers, > Sonia Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: death test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22074/files - new: https://git.openjdk.org/jdk/pull/22074/files/9e4c99fd..66407706 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22074&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22074&range=06-07 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22074.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22074/head:pull/22074 PR: https://git.openjdk.org/jdk/pull/22074 From szaldana at openjdk.org Tue Nov 19 16:05:10 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 19 Nov 2024 16:05:10 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v5] In-Reply-To: References: <7uXfTfJwpgKaUUc3PPuTpDxGASo4RcwPjpzmUtVI0mA=.3bc5d7e2-23ce-4c14-a715-d22a4d41e618@github.com> <6rMvLUi8vmMKEbNrr2pNaAB6snOjqrcZSHPvtdVGwxc=.18859212-ec84-4241-a53e-99d29c3b85a3@github.com> Message-ID: <5fpStbna2eQY684fXrpT3qk4fu0pCrCYBPKutChWHjU=.caf052ce-2b11-4965-9c88-5c172e93ed84@github.com> On Tue, 19 Nov 2024 15:49:15 GMT, Kim Barrett wrote: >> I had tested your implementation but I added a few more test cases for peace of mind :-) >> >> I don't think we can do a death test because that would only get triggered for debug builds. I can't seem to find any in the code base either. >> >> Also fixed the T(0) issue. Thanks! > > Regarding death tests - look for tests using of `TEST_VM_ASSERT` and `TEST_VM_ASSERT_MSG`. > They are only available in debug builds, and uses are wrapped in `#ifdef ASSERT`. Ah my bad. I was looking for ASSERT_DEATH. I added a death test for 0. Thanks for the pointer! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22074#discussion_r1848636135 From shade at openjdk.org Tue Nov 19 16:08:32 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 19 Nov 2024 16:08:32 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: > > - Merge branch 'merge-latest' into great-genshen-pr-redux > - Use new CompactHeader forwarding APIs in generational mode > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge > - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines > > Reviewed-by: wkemper > - Merge > - 8343227: GenShen: Fold resource mark into management of preselected regions > > Reviewed-by: kdnilsen > - Merge openjdk/jdk tip into great-genshen-pr-redux > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge remote-tracking branch 'jdk/master' into merge-latest > - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 Some more stuff. 180/230 files done %) src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 420: > 418: } > 419: int gc_state = _heap->gc_state(); > 420: if ((gc_state & ShenandoahHeap::YOUNG_MARKING) != 0) { It is not very clear this works fine with single-gen mode. Does `MARKING` imply `YOUNG_MARKING` in single-gen mode? I think we better make it abundantly clear with `is_generational()` checks. src/hotspot/share/gc/shenandoah/shenandoahCollectionSetPreselector.hpp line 34: > 32: ShenandoahCollectionSet* _cset; > 33: bool* _pset; > 34: ResourceMark _rm; Not necessarily for this PR, but something to rectify going forward. It is generally not safe to hide `ResourceMark`-s like this in the objects. Sometimes the callers return stuff allocated in resource area, and if the object like this leaves the scope, it would corrupt the memory. Normally, when we develop resource-area-returning paths, we look around near `ResourceMark`-s to see is any thing fishy is going on. It does not help when `RM` is hidden in the object like this. src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 276: > 274: log_info(gc)("GC cancellation took %.3fs", cancel_time); > 275: _cancel_requested_time = 0; > 276: } Do we need this? Is this useful? src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.cpp line 49: > 47: const char* cns = PerfDataManager::name_space("shenandoah", "regions"); > 48: _name_space = NEW_C_HEAP_ARRAY(char, strlen(cns)+1, mtGC); > 49: strcpy(_name_space, cns); // copy cns into _name_space Suggestion: strcpy(_name_space, cns); (The comment is self-obvious) src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.cpp line 57: > 55: PerfDataManager::create_constant(SUN_GC, cname, PerfData::U_None, num_regions, CHECK); > 56: > 57: cname = PerfDataManager::counter_name(_name_space, "protocol_version"); //creating new protocol_version Suggestion: cname = PerfDataManager::counter_name(_name_space, "protocol_version"); src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp line 193: > 191: Phase phase = Phase(pi); > 192: if (is_worker_phase(phase)) { > 193: double sum = uninitialized(); I think you can avoid changing this method to limit the churn. src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp line 455: > 453: // Note: would be sufficient to mark only the card that holds the start of this Reference object. > 454: heap->old_generation()->card_scan()->mark_range_as_dirty(cast_from_oop(reference), reference->size()); > 455: } Two things: a) This sounds like `card_table_barrier(reference, raw_referent)`? Since this code is getting called for every dropped reference, just checking a `ShenandoahCardBarrier` flag sounds more efficient. b) Is there a point in dirtying up to `reference->size()`? src/hotspot/share/gc/shenandoah/shenandoahSharedVariables.hpp line 125: > 123: ShenandoahSharedValue ov = Atomic::load_acquire(&value); > 124: // We require all bits of mask_val to be set > 125: if ((ov & mask_val) == mask_val) { This looks like a pre-existing bug, right? I assume this does not affect current Shenandoah, since we do not set multiple bits. I am fine with doing this in this PR, but it would probably be good to backport this fix in earlier releases too. ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2439178281 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1848286637 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1846888999 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844183614 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844187355 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844186936 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1846892659 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1846923725 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1848264678 From coleenp at openjdk.org Tue Nov 19 16:15:57 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 19 Nov 2024 16:15:57 GMT Subject: RFR: 8344445: MethodCounters don't need a vptr [v2] In-Reply-To: References: <0WPjPOxGnTB0Ba_IcWxUr6oa4ClIOca7PV0G6kHVQ6g=.f1093c4e-03d7-4b77-8a0e-81d64d76dbf8@github.com> Message-ID: On Tue, 19 Nov 2024 12:23:08 GMT, Coleen Phillimore wrote: >> This is a somewhat trivial change to make MethodCounters inherit from MetaspaceObj so that they don't have any virtual functions (and vptrs). They're just a bunch of ints. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove method_pointers_size() in favor of static size(). Thank you Kim and Dean. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22220#issuecomment-2486147034 From coleenp at openjdk.org Tue Nov 19 16:15:58 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 19 Nov 2024 16:15:58 GMT Subject: Integrated: 8344445: MethodCounters don't need a vptr In-Reply-To: <0WPjPOxGnTB0Ba_IcWxUr6oa4ClIOca7PV0G6kHVQ6g=.f1093c4e-03d7-4b77-8a0e-81d64d76dbf8@github.com> References: <0WPjPOxGnTB0Ba_IcWxUr6oa4ClIOca7PV0G6kHVQ6g=.f1093c4e-03d7-4b77-8a0e-81d64d76dbf8@github.com> Message-ID: On Mon, 18 Nov 2024 20:37:45 GMT, Coleen Phillimore wrote: > This is a somewhat trivial change to make MethodCounters inherit from MetaspaceObj so that they don't have any virtual functions (and vptrs). They're just a bunch of ints. > > Tested with tier1-4. This pull request has now been integrated. Changeset: d4cd27e8 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/d4cd27e875ba7d44b0c614d48888340990b94169 Stats: 19 lines in 3 files changed: 3 ins; 7 del; 9 mod 8344445: MethodCounters don't need a vptr Reviewed-by: kbarrett, dlong ------------- PR: https://git.openjdk.org/jdk/pull/22220 From kbarrett at openjdk.org Tue Nov 19 16:17:57 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 19 Nov 2024 16:17:57 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v8] In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 16:05:10 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8343700](https://bugs.openjdk.org/browse/JDK-8343700) where ceil_log2 looped endlessly if the input value has the highest bit set. >> >> I also dealt with the case where we try to find ceil_log2(1) which would've returned 1 as opposed to 0. >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > death test Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22074#pullrequestreview-2445953338 From shade at openjdk.org Tue Nov 19 16:17:58 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 19 Nov 2024 16:17:58 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v8] In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 16:05:10 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8343700](https://bugs.openjdk.org/browse/JDK-8343700) where ceil_log2 looped endlessly if the input value has the highest bit set. >> >> I also dealt with the case where we try to find ceil_log2(1) which would've returned 1 as opposed to 0. >> >> Cheers, >> Sonia > > Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: > > death test Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22074#pullrequestreview-2445961105 From fbredberg at openjdk.org Tue Nov 19 16:38:24 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Tue, 19 Nov 2024 16:38:24 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing Message-ID: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> @dcubed-ojdk is too busy, so I was asked to take over [https://github.com/openjdk/jdk/pull/18664](https://github.com/openjdk/jdk/pull/18664) and finish it. That old PR contains all the details and also got some review comments, which I have tried to address in this new PR. Tests run without failures on supported platforms. ------------- Commit messages: - Made changes based on old review comments - 8329351: Add recursive Java monitor stress testing Changes: https://git.openjdk.org/jdk/pull/22238/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22238&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8329351 Stats: 770 lines in 3 files changed: 770 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22238.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22238/head:pull/22238 PR: https://git.openjdk.org/jdk/pull/22238 From rkennke at openjdk.org Tue Nov 19 16:52:55 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 19 Nov 2024 16:52:55 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing In-Reply-To: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: On Tue, 19 Nov 2024 13:09:22 GMT, Fredrik Bredberg wrote: > @dcubed-ojdk is too busy, so I was asked to take over [https://github.com/openjdk/jdk/pull/18664](https://github.com/openjdk/jdk/pull/18664) and finish it. > > That old PR contains all the details and also got some review comments, which I have tried to address in this new PR. > > Tests run without failures on supported platforms. I haven't looked at all the context, yet. But have you checked test/hotspot/jtreg/runtime/locking/TestRecursiveMonitorChurn.java ? Maybe one can subsume the other? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22238#issuecomment-2486238842 From jiangli at openjdk.org Tue Nov 19 16:55:14 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 19 Nov 2024 16:55:14 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v9] In-Reply-To: <4TglRts9KEQcf0NHTe2LvbzxSK9w5PoaEcIQhP-7fD8=.815bf1da-830d-4035-95bf-1916322f9567@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> <4TglRts9KEQcf0NHTe2LvbzxSK9w5PoaEcIQhP-7fD8=.815bf1da-830d-4035-95bf-1916322f9567@github.com> Message-ID: On Wed, 13 Nov 2024 01:40:23 GMT, Jiangli Zhou wrote: >> @jianglizhou Thank you for your assistance in figuring out the problem. I guess I throw out too much code from the hermetic-java-runtime branch when trying to minimize the changes to only build-related stuff. The jimage changes were so busy so I probably ignored them a bit too much. > > @magicus Just want to check if there's anything that you are waiting from me for this PR. My understanding is that you'll update the PR to fix the incremental build and debuginfo before the last review iteration. Please let me know if there are anything else. Thanks! > @jianglizhou > > > I think we would need to decide what is the dll_dir with the static JDK support and hermetic support. > > From my understanding, `_sun_boot_library_path` does not have any meaning when running with static builds. As I said before, I think we really ought to take a step back, consider the wider picture, and refactor the way we interact with internal native libraries. Determining how to handle `_sun_boot_library_path` for static builds are definitely part of that work. There might still be some usages of `_sun_boot_library_path` with static JDK. I recently made changes (in our local copy and not yet in https://github.com/openjdk/leyden/tree/hermetic-java-runtime) to use `_sun_boot_library_path` to locate the `jspawnhelper` in `/lib` when spawning child process is needed, for supporting specific hermetic Java testing mode (without building a full hermetic image). At some point, we want to call out the supported execution modes (e.g. hermetic mode, dynamic/tradition mode, hermetic testing mode, etc) in https://docs.google.com/document/d/1LWy9vFDis5-hbJwrFUBH1rc8w8f3oL6O3sOzQXjXVUM/edit?usp=sharing as part of the ongoing discussions with Alan, Ron and others. Agreed that `_sun_boot_library_path` should be part of the bigger picture design/discussion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2486244160 From lucy at openjdk.org Tue Nov 19 16:56:55 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Tue, 19 Nov 2024 16:56:55 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known [v3] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 14:11:24 GMT, Lutz Schmidt wrote: >>>I think that the instructions can encode the maximum frame size. >> >> both of the instruction support displacement up to `12bit unsigned integer`, which should give us flexibility of around 4000byte So I guess we should be fine. > >> > I think that the instructions can encode the maximum frame size. >> >> both of the instruction support displacement up to `12bit unsigned integer`, which should give us flexibility of around 4000byte So I guess we should be fine. > > Instead of speculation: > - GPRs: 16 registers, 8 bytes each -> 128 bytes > - FPRs: 16 registers, 8 bytes each -> 128 bytes > - VRs: 32 registers, 16 bytes each -> 512 bytes > - In total: 768 bytes. > > This is an easy fit into uimm12. > Looks correct to me. I would probably not exclude F1. But if the decision not to use it for allocation is fixed, ok. @RealLucy: Please take a 2nd look. Wasn't F1 used as float function return value register? If so, exclusion is very helpful. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22197#issuecomment-2486247637 From lmesnik at openjdk.org Tue Nov 19 16:57:59 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 19 Nov 2024 16:57:59 GMT Subject: RFR: 8318098: Update jfr tests with corresponding requires flags Message-ID: <8s_n2j62lexzKj2qM6w7JMMAngbXqstCW-ta5iGBgEU=.013471ef-46ce-40de-b4fb-312f333a138c@github.com> There are few JFR tests are failing with -Xcomp and compiler stress flags. I added requires tag when tests are incompatible with corresponding mode: 1) huge stacks and DeoptimieALot cause timeout 2) WB controlled compilation doesn't work with Xcomp 3) Arguments tests might be sensitive to aby flags and should be flagless and excluded a 2 groups of tests failing with Xcomp for further invesitigation. So now jfr tests support all flags used for testing in CI with them. The bug https://bugs.openjdk.org/browse/JDK-8318098 has a linked all the product issues found by running JFR tests with flags and explanation why is it needed. ------------- Commit messages: - 8318098: Update jfr tests with corresponding requires flags - Merge branch 'master' of https://github.com/lmesnik/jdk - 8344051 Changes: https://git.openjdk.org/jdk/pull/22249/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22249&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318098 Stats: 22 lines in 9 files changed: 22 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22249.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22249/head:pull/22249 PR: https://git.openjdk.org/jdk/pull/22249 From coleenp at openjdk.org Tue Nov 19 17:08:51 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 19 Nov 2024 17:08:51 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing In-Reply-To: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: On Tue, 19 Nov 2024 13:09:22 GMT, Fredrik Bredberg wrote: > @dcubed-ojdk is too busy, so I was asked to take over [https://github.com/openjdk/jdk/pull/18664](https://github.com/openjdk/jdk/pull/18664) and finish it. > > That old PR contains all the details and also got some review comments, which I have tried to address in this new PR. > > Tests run without failures on supported platforms. Thank you for taking over this work. We've found this test to be really valuable, so good to have in our test system even if it functionally overlaps with other tests. See two questions. test/hotspot/jtreg/TEST.groups line 604: > 602: -runtime/CompressedOops/UseCompressedOops.java \ > 603: -runtime/InvocationTests \ > 604: -runtime/Monitor/StressWrapper_TestRecursiveLocking_36M.java \ Does runtime/Monitor/TestRecursiveLocking.java need to be added in here too? test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 465: > 463: syncObj.runAlternateABTest(); > 464: break; > 465: I was wondering if this test could be reduced to run both modes in one execution, one after the other? ------------- PR Review: https://git.openjdk.org/jdk/pull/22238#pullrequestreview-2446093004 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1848739091 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1848738342 From lmesnik at openjdk.org Tue Nov 19 17:09:00 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 19 Nov 2024 17:09:00 GMT Subject: RFR: 8318098: Update jfr tests with corresponding requires flags [v2] In-Reply-To: <8s_n2j62lexzKj2qM6w7JMMAngbXqstCW-ta5iGBgEU=.013471ef-46ce-40de-b4fb-312f333a138c@github.com> References: <8s_n2j62lexzKj2qM6w7JMMAngbXqstCW-ta5iGBgEU=.013471ef-46ce-40de-b4fb-312f333a138c@github.com> Message-ID: > There are few JFR tests are failing with -Xcomp and compiler stress flags. > I added requires tag when tests are incompatible with corresponding mode: > 1) huge stacks and DeoptimieALot cause timeout > 2) WB controlled compilation doesn't work with Xcomp > 3) Arguments tests might be sensitive to aby flags and should be flagless > and excluded a 2 groups of tests failing with Xcomp for further invesitigation. > > The drivers for these are following bug escapes because of JFR was not tested with VM flags: > https://bugs.openjdk.org/browse/JDK-8340586 > https://bugs.openjdk.org/browse/JDK-8344199 > https://bugs.openjdk.org/browse/JDK-8340826 > https://bugs.openjdk.org/browse/JDK-8343893 > > > So now jfr tests support all flags used for testing in CI with them. > The bug > https://bugs.openjdk.org/browse/JDK-8318098 > has a linked all the product issues found by running JFR tests with flags and explanation why is it needed. Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' of https://github.com/openjdk/jdk into 8318098 - 8318098: Update jfr tests with corresponding requires flags - Merge branch 'master' of https://github.com/lmesnik/jdk - 8344051 ------------- Changes: https://git.openjdk.org/jdk/pull/22249/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22249&range=01 Stats: 22 lines in 9 files changed: 22 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22249.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22249/head:pull/22249 PR: https://git.openjdk.org/jdk/pull/22249 From lucy at openjdk.org Tue Nov 19 17:11:04 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Tue, 19 Nov 2024 17:11:04 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known [v3] In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 05:24:26 GMT, Amit Kumar wrote: >> Adds SaveLiveRegister portion for vector registers also. >> >> Depends on https://github.com/openjdk/jdk/pull/22190. Once that PR gets integrated, will rebase and mark it ready for review. > > Amit Kumar 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 v_test_failure_v0 > - additional changes > - suggestion from martin > - no more ignoring vector registers > > fix' Looks even better after the additional changes. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22197#pullrequestreview-2446096756 From amitkumar at openjdk.org Tue Nov 19 17:11:04 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 19 Nov 2024 17:11:04 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known [v3] In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 16:53:15 GMT, Lutz Schmidt wrote: > > Looks correct to me. I would probably not exclude F1. But if the decision not to use it for allocation is fixed, ok. @RealLucy: Please take a 2nd look. > > Wasn't F1 used as float function return value register? If so, exclusion is very helpful. That is F0, I have added a screenshot up for such occasions? Moreover `z_dbl_reg` class comments out `F1` register and `z_rscratch1_dbl_reg` class has not a single use. So seems like register allocator will never use `Z_F1`. That's why I excluded it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22197#issuecomment-2486282622 From mgronlun at openjdk.org Tue Nov 19 17:36:45 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 19 Nov 2024 17:36:45 GMT Subject: RFR: 8318098: Update jfr tests with corresponding requires flags [v2] In-Reply-To: References: <8s_n2j62lexzKj2qM6w7JMMAngbXqstCW-ta5iGBgEU=.013471ef-46ce-40de-b4fb-312f333a138c@github.com> Message-ID: On Tue, 19 Nov 2024 17:09:00 GMT, Leonid Mesnik wrote: >> There are few JFR tests are failing with -Xcomp and compiler stress flags. >> I added requires tag when tests are incompatible with corresponding mode: >> 1) huge stacks and DeoptimieALot cause timeout >> 2) WB controlled compilation doesn't work with Xcomp >> 3) Arguments tests might be sensitive to aby flags and should be flagless >> and excluded a 2 groups of tests failing with Xcomp for further invesitigation. >> >> The drivers for these are following bug escapes because of JFR was not tested with VM flags: >> https://bugs.openjdk.org/browse/JDK-8340586 >> https://bugs.openjdk.org/browse/JDK-8344199 >> https://bugs.openjdk.org/browse/JDK-8340826 >> https://bugs.openjdk.org/browse/JDK-8343893 >> >> >> So now jfr tests support all flags used for testing in CI with them. >> The bug >> https://bugs.openjdk.org/browse/JDK-8318098 >> has a linked all the product issues found by running JFR tests with flags and explanation why is it needed. > > Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge branch 'master' of https://github.com/openjdk/jdk into 8318098 > - 8318098: Update jfr tests with corresponding requires flags > - Merge branch 'master' of https://github.com/lmesnik/jdk > - 8344051 The intent of all JFR tests was NOT to run in every kind of conceivable combination. That was the whole purpose of the jfr jtreg keyword, when we introduced it: to not accept outside parameters. Our tests are unit tests carefully designed to test a specific part of JFR. They are not integration tests and may not work under all compiler and GC combinations. It has been this way for over 10 years - why is this changing now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22249#issuecomment-2486339277 From coleenp at openjdk.org Tue Nov 19 17:40:58 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 19 Nov 2024 17:40:58 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing In-Reply-To: References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: On Tue, 19 Nov 2024 17:04:58 GMT, Coleen Phillimore wrote: >> @dcubed-ojdk is too busy, so I was asked to take over [https://github.com/openjdk/jdk/pull/18664](https://github.com/openjdk/jdk/pull/18664) and finish it. >> >> That old PR contains all the details and also got some review comments, which I have tried to address in this new PR. >> >> Tests run without failures on supported platforms. > > test/hotspot/jtreg/TEST.groups line 604: > >> 602: -runtime/CompressedOops/UseCompressedOops.java \ >> 603: -runtime/InvocationTests \ >> 604: -runtime/Monitor/StressWrapper_TestRecursiveLocking_36M.java \ > > Does runtime/Monitor/TestRecursiveLocking.java need to be added in here too? OH I see there's a minus sign here too for tier2, so I assume it'll run in tier3? But the 5 second one will run in tier2. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1848790013 From lmesnik at openjdk.org Tue Nov 19 18:14:55 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 19 Nov 2024 18:14:55 GMT Subject: RFR: 8318098: Update jfr tests with corresponding requires flags [v2] In-Reply-To: References: <8s_n2j62lexzKj2qM6w7JMMAngbXqstCW-ta5iGBgEU=.013471ef-46ce-40de-b4fb-312f333a138c@github.com> Message-ID: <3lP5QAVmGNrN8J-A-1BuhbRSf_xjEDfVETuEMug0eUs=.2b8103e2-8bd2-47d8-ac41-f05e217c4be8@github.com> On Tue, 19 Nov 2024 17:09:00 GMT, Leonid Mesnik wrote: >> There are few JFR tests are failing with -Xcomp and compiler stress flags. >> I added requires tag when tests are incompatible with corresponding mode: >> 1) huge stacks and DeoptimieALot cause timeout >> 2) WB controlled compilation doesn't work with Xcomp >> 3) Arguments tests might be sensitive to aby flags and should be flagless >> and excluded a 2 groups of tests failing with Xcomp for further invesitigation. >> >> The drivers for these are following bug escapes because of JFR was not tested with VM flags: >> https://bugs.openjdk.org/browse/JDK-8340586 >> https://bugs.openjdk.org/browse/JDK-8344199 >> https://bugs.openjdk.org/browse/JDK-8340826 >> https://bugs.openjdk.org/browse/JDK-8343893 >> >> >> So now jfr tests support all flags used for testing in CI with them. >> The bug >> https://bugs.openjdk.org/browse/JDK-8318098 >> has a linked all the product issues found by running JFR tests with flags and explanation why is it needed. > > Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge branch 'master' of https://github.com/openjdk/jdk into 8318098 > - 8318098: Update jfr tests with corresponding requires flags > - Merge branch 'master' of https://github.com/lmesnik/jdk > - 8344051 The jfr keyword has been used by internal Oracle system only because there were now way to control VM flags by jtreg 10 years ago. This is why I haven't mentioned it in the PR. There is a requires tag has been introduced to mark the tests that don't accept certain or any vm flags. It is used in many areas to mark flags sensitive tests so they are not executed for some or any combinations. So anyone who executes openjdk jtreg tests, either in Adhoc/locally or using their CI expects that tests are correctly configured and incompatible options are not selected.The only exception is JFR tests . The 'jfr' keyword is not documented and there is no formal and easy way saying to run all SVC tests with ZGC. So using requires tag just makes jfr test consistent with all other JDK tests. Most of JFR tests don't set very specific combinations and might be executed with all VM flags. So need to mark on incompatible combination. There is no requirement to spent a lot of time trying to improve test for all Compiler/GC combinations, just mark tests that are too specific. And as I mention in the description there are real Hotspot issues that were found by running jfr tests with different options. Saying that I believe it makes sense to change how we run JFR tests. So we have the same way for ALL JDK tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22249#issuecomment-2486417959 From lmesnik at openjdk.org Tue Nov 19 18:30:37 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 19 Nov 2024 18:30:37 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v7] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fixed spaces ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/056ec87a..0fbafab4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=05-06 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From mgronlun at openjdk.org Tue Nov 19 18:55:48 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 19 Nov 2024 18:55:48 GMT Subject: RFR: 8318098: Update jfr tests with corresponding requires flags [v2] In-Reply-To: <3lP5QAVmGNrN8J-A-1BuhbRSf_xjEDfVETuEMug0eUs=.2b8103e2-8bd2-47d8-ac41-f05e217c4be8@github.com> References: <8s_n2j62lexzKj2qM6w7JMMAngbXqstCW-ta5iGBgEU=.013471ef-46ce-40de-b4fb-312f333a138c@github.com> <3lP5QAVmGNrN8J-A-1BuhbRSf_xjEDfVETuEMug0eUs=.2b8103e2-8bd2-47d8-ac41-f05e217c4be8@github.com> Message-ID: On Tue, 19 Nov 2024 18:11:39 GMT, Leonid Mesnik wrote: > The jfr keyword has been used by internal Oracle system only because there were now way to control VM flags by jtreg 10 years ago. This is why I haven't mentioned it in the PR. > > There is a requires tag has been introduced to mark the tests that don't accept certain or any vm flags. It is used in many areas to mark flags sensitive tests so they are not executed for some or any combinations. > > So anyone who executes openjdk jtreg tests, either in Adhoc/locally or using their CI expects that tests are correctly configured and incompatible options are not selected.The only exception is JFR tests . The 'jfr' keyword is not documented and there is no formal and easy way saying to run all SVC tests with ZGC. > > So using requires tag just makes jfr test consistent with all other JDK tests. > > Most of JFR tests don't set very specific combinations and might be executed with all VM flags. So need to mark on incompatible combination. There is no requirement to spent a lot of time trying to improve test for all Compiler/GC combinations, just mark tests that are too specific. And as I mention in the description there are real Hotspot issues that were found by running jfr tests with different options. > > Saying that I believe it makes sense to change how we run JFR tests. So we have the same way for ALL JDK tests. Why not put vm.flagless on everything then? Else we find ourselves in situations like the following: TestPromotionEventWithG1.java @requires vm.compMode != "Xcomp" Why is vm.compMode now all of a sudden a requirement for this test? How was it determined that Xcomp should be excluded for this test that tests a PromotionEvent for G1? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22249#issuecomment-2486493883 From lmesnik at openjdk.org Tue Nov 19 19:11:46 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 19 Nov 2024 19:11:46 GMT Subject: RFR: 8318098: Update jfr tests with corresponding requires flags [v2] In-Reply-To: References: <8s_n2j62lexzKj2qM6w7JMMAngbXqstCW-ta5iGBgEU=.013471ef-46ce-40de-b4fb-312f333a138c@github.com> <3lP5QAVmGNrN8J-A-1BuhbRSf_xjEDfVETuEMug0eUs=.2b8103e2-8bd2-47d8-ac41-f05e217c4be8@github.com> Message-ID: <6GjLaoTx7O7dfjJfZmTp2AAzCnBSXRO2Ge9N65GPP2Q=.c51cf3f6-d64b-438f-9c21-6cd77b922143@github.com> On Tue, 19 Nov 2024 18:51:46 GMT, Markus Gr?nlund wrote: > Why not put vm.flagless on everything then? > Although it makes the test compliant, it significantly reduce coverage. I provide examples of the issues that were already found. The issue https://bugs.openjdk.org/browse/JDK-8344199 Incorrect excluded field value set by getEventWriter intrinsic is observed only when we run tests with Xcomp. Otherwise neither of JFR code is compiled and the C2-path is not executed. Unfortunately, there are no tests for this and the easiest way to test is just to run all existing tests with forced C2. > Else we find ourselves in situations like the following: > > TestPromotionEventWithG1.java @requires vm.compMode != "Xcomp" > > Why is vm.compMode now all of a sudden a requirement for this test? How was it determined that Xcomp should be excluded for this test that tests a PromotionEvent for G1? The requirement for JDK tests is to reject incompatible options used during testing. I excluded the test TestPromotionEventWithG1 because it failing with Xcomp. Looking on the test that configure * @run main/othervm -Xmx32m -Xms32m -Xmn12m -XX:+UseG1GC -XX:-UseStringDeduplication -XX:MaxTenuringThreshold=5 -XX:InitialTenuringThreshold=5 jdk.jfr.event.gc.detailed.TestPromotionEventWithG1 * @run main/othervm -Xmx32m -Xms32m -Xmn12m -XX:AllocatePrefetchLines=1 -XX:AllocateInstancePrefetchLines=1 -XX:AllocatePrefetchStepSize=16 -XX:AllocatePrefetchDistance=1 -XX:+UseG1GC * -XX:-UseStringDeduplication -Xlog:os+cpu=info -XX:MaxTenuringThreshold=5 -XX:InitialTenuringThreshold=5 -XX:MinTLABSize=768 -XX:TLABSize=768 jdk.jfr.event.gc.detailed.TestPromotionEventWithG1 it is clear that test might be too specific to use any additional VM flags. Such tests are indeed good candidate to be marked as a flagless from the beginning. You might just use 'vm.flagless' for unit tests, however for tests that don't need very specific setup it is better to allow to run different combinations. It helps to better test how JFR is not broken in different modes. No need to test all those thing before push, unless you have a reasons to believe that test is specific to some modes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22249#issuecomment-2486530617 From szaldana at openjdk.org Tue Nov 19 19:15:57 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 19 Nov 2024 19:15:57 GMT Subject: Integrated: 8343700: ceil_log2 should not loop endlessly In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 14:28:37 GMT, Sonia Zaldana Calles wrote: > Hi all, > > This PR addresses [8343700](https://bugs.openjdk.org/browse/JDK-8343700) where ceil_log2 looped endlessly if the input value has the highest bit set. > > I also dealt with the case where we try to find ceil_log2(1) which would've returned 1 as opposed to 0. > > Cheers, > Sonia This pull request has now been integrated. Changeset: 3328b4ec Author: Sonia Zaldana Calles URL: https://git.openjdk.org/jdk/commit/3328b4ecf225f95edfce6ab848dcfb62ddc1aaff Stats: 48 lines in 3 files changed: 41 ins; 1 del; 6 mod 8343700: ceil_log2 should not loop endlessly Reviewed-by: shade, kbarrett, aph, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/22074 From szaldana at openjdk.org Tue Nov 19 19:19:53 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 19 Nov 2024 19:19:53 GMT Subject: RFR: 8343700: ceil_log2 should not loop endlessly [v5] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 23:08:59 GMT, Kim Barrett wrote: >> Sonia Zaldana Calles has updated the pull request incrementally with one additional commit since the last revision: >> >> fixing assert > > src/hotspot/share/utilities/powerOfTwo.hpp line 125: > >> 123: // Find log2 value greater than this input >> 124: template ::type, ENABLE_IF(std::is_integral::value)> >> 125: inline int ceil_log2(T value) { > > Pre-existing: I think this should have been called `log2i_ceil`, with a description something like: > > // Ceiling of log2 of a positive, integral value, i.e., smallest i such that value <= 2^i. > > And move it near the other log2i variants. > > This could be done as a followup, to keep this PR focused on the issue at hand. FYI, I filed [8344568](https://bugs.openjdk.org/browse/JDK-8344568) to track this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22074#discussion_r1848932955 From wkemper at openjdk.org Tue Nov 19 19:57:07 2024 From: wkemper at openjdk.org (William Kemper) Date: Tue, 19 Nov 2024 19:57:07 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Fri, 15 Nov 2024 17:01:29 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 276: > >> 274: log_info(gc)("GC cancellation took %.3fs", cancel_time); >> 275: _cancel_requested_time = 0; >> 276: } > > Do we need this? Is this useful? We could log this at debug? I believe it is useful because this time (currently) is not accounted for in the heuristic's notion of 'cycle time'. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1848979381 From jbhateja at openjdk.org Tue Nov 19 19:57:09 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 19 Nov 2024 19:57:09 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations Message-ID: Hi All, This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) Following is the summary of changes included with this patch:- 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF 6. Auto-vectorization of newly supported scalar operations. 7. X86 and AARCH64 backend implementation for all supported intrinsics. 9. Functional and Performance validation tests. **Missing Pieces:-** **- AARCH64 Backend.** Kindly review and share your feedback. Best Regards, Jatin ------------- Commit messages: - Code styling changes - Review comments resoultion. - Jcheck and build fixes - New halffloat type 'TypeH' and associated changes - Merge branch 'master' of http://github.com/openjdk/jdk into float16_support - Jcheck cleanup - Review comments and tests cleanup. - Annotating Float16 as a ValueBased class - Merge branch 'master' of http://github.com/openjdk/jdk into float16_support - Merge branch 'master' of http://github.com/openjdk/jdk into float16_support - ... and 6 more: https://git.openjdk.org/jdk/compare/2c509a15...132878ba Changes: https://git.openjdk.org/jdk/pull/21490/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21490&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342103 Stats: 3055 lines in 58 files changed: 2974 ins; 0 del; 81 mod Patch: https://git.openjdk.org/jdk/pull/21490.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21490/head:pull/21490 PR: https://git.openjdk.org/jdk/pull/21490 From bkilambi at openjdk.org Tue Nov 19 19:57:13 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Tue, 19 Nov 2024 19:57:13 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja wrote: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 6. Auto-vectorization of newly supported scalar operations. > 7. X86 and AARCH64 backend implementation for all supported intrinsics. > 9. Functional and Performance validation tests. > > **Missing Pieces:-** > **- AARCH64 Backend.** > > Kindly review and share your feedback. > > Best Regards, > Jatin Can we add the JMH micro benchmark that you added recently for FP16 as well ? or has it intentionally not been included? Hi Jatin, could you also include the idealization tests here - test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java and ConvF2HFIdealizationTests.java in this PR? src/hotspot/share/opto/addnode.hpp line 445: > 443: MinHFNode(Node* in1, Node* in2) : MaxNode(in1, in2) {} > 444: virtual int Opcode() const; > 445: virtual const Type *add_ring(const Type*, const Type*) const; `Type* ` ? to align with the style used in the constructor. src/hotspot/share/opto/divnode.cpp line 752: > 750: //============================================================================= > 751: //------------------------------Value------------------------------------------ > 752: // An DivFNode divides its inputs. The third input is a Control input, used to DivHFNode? src/hotspot/share/opto/divnode.cpp line 775: > 773: } > 774: > 775: if( t2 == TypeH::ONE ) should if condition be styled as - `if ()` ? or is this to align with already existing float routines? src/hotspot/share/opto/mulnode.cpp line 558: > 556: } > 557: > 558: // Compute the product type of two double ranges into this node. of two *half-float* ranges? src/hotspot/share/opto/node.cpp line 1600: > 1598: > 1599: // Get a half float constant from a ConstNode. > 1600: // Returns the constant if it is a float ConstNode half float ConstNode? src/hotspot/share/opto/type.hpp line 530: > 528: }; > 529: > 530: // Class of Float-Constant Types. Class of Half-float constant Types? test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java line 122: > 120: public static final String VECTOR_SIZE_64 = VECTOR_SIZE + "64"; > 121: > 122: private static final String TYPE_BYTE = "byte"; Hi Jatin, why have these changes been made? The PrintIdeal output still prints the vector size of the node in this format - `#vectord`. This test - `test/hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java` was failing due to this mismatch .. test/jdk/java/lang/Float/FP16ReductionOperations.java line 25: > 23: > 24: /* > 25: * @test Hi Jatin, is there any reason why these have been kept under the `Float` folder and not a separate `Float16` folder? test/jdk/jdk/incubator/vector/ScalarFloat16OperationsTest.java line 334: > 332: > 333: @Test(dataProvider = "ternaryOpProvider") > 334: public static void minTest(Object input1, Object input2, Object input3) { `fmaTest` ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2411381410 PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2411607884 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1848152453 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1848128281 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1848135401 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1848112186 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1848195342 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847971311 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1803209988 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1802767337 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1848388981 From darcy at openjdk.org Tue Nov 19 19:57:14 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 19 Nov 2024 19:57:14 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Mon, 14 Oct 2024 16:42:24 GMT, Paul Sandoz wrote: > We should move the `Float16` class to `jdk.incubator.vector` and relevant intrinsic stuff to `jdk.internal.vm.vector`, and we don't need the changes to `BigDecimal` and `BigInteger`. To expand on that point, a few weeks back I took a look at what porting Float16 from java.lang in the lworld+fp16 branch of Valhalla to the jdk.incubator.vector package in JDK 24 would look like: the result were favorable and the diffs are attached to JDK-8341260. Before the work in this PR proceeds, I think the java.lang -> jdk.incubator.vector move of Float16 should occur first. This will allow leaner reviews and better API separation. I can get an updated PR of the move prepared within the next few days. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2420616927 From psandoz at openjdk.org Tue Nov 19 19:57:14 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 19 Nov 2024 19:57:14 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja wrote: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 6. Auto-vectorization of newly supported scalar operations. > 7. X86 and AARCH64 backend implementation for all supported intrinsics. > 9. Functional and Performance validation tests. > > **Missing Pieces:-** > **- AARCH64 Backend.** > > Kindly review and share your feedback. > > Best Regards, > Jatin We should move the `Float16` class to `jdk.incubator.vector` and relevant intrinsic stuff to `jdk.internal.vm.vector`, and we don't need the changes to `BigDecimal` and `BigInteger`. make/modules/jdk.incubator.vector/Java.gmk line 30: > 28: DOCLINT += -Xdoclint:all/protected > 29: > 30: JAVAC_FLAGS += --add-exports=java.base/jdk.internal=jdk.incubator.vector Please remove this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2411758902 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1845208651 From psandoz at openjdk.org Tue Nov 19 19:57:14 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 19 Nov 2024 19:57:14 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 21:33:03 GMT, Joe Darcy wrote: > > Before the work in this PR proceeds, I think the java.lang -> jdk.incubator.vector move of Float16 should occur first. This will allow leaner reviews and better API separation. I can get an updated PR of the move prepared within the next few days. Good point, we should separate the Java changes from the intrinsic + HotSpot changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2420632074 From darcy at openjdk.org Tue Nov 19 19:57:14 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 19 Nov 2024 19:57:14 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 21:35:40 GMT, Paul Sandoz wrote: > > Before the work in this PR proceeds, I think the java.lang -> jdk.incubator.vector move of Float16 should occur first. This will allow leaner reviews and better API separation. I can get an updated PR of the move prepared within the next few days. > > Good point, we should separate the Java changes from the intrinsic + HotSpot changes. PS Along those lines, see https://github.com/openjdk/jdk/pull/21574 for a non-intrinsified port of Float16 to the vector API. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2420926866 From jrose at openjdk.org Tue Nov 19 19:57:14 2024 From: jrose at openjdk.org (John R Rose) Date: Tue, 19 Nov 2024 19:57:14 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja wrote: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 6. Auto-vectorization of newly supported scalar operations. > 7. X86 and AARCH64 backend implementation for all supported intrinsics. > 9. Functional and Performance validation tests. > > **Missing Pieces:-** > **- AARCH64 Backend.** > > Kindly review and share your feedback. > > Best Regards, > Jatin As I noted on Joe's PR, I like the fact that the intrinsics are decoupled from the box class. I'm now wondering if there is another simplification possible (as I claimed to Joe!) which is to reduce the number of intrinsics, ideally down to conversions (to and from HF). For example, `sqrt_float16` is an intrinsic, but I think it could be just an invisible IR node. After inlining the Java definition, you start with an IR graph that mentions `sqrtD` and is surrounded by conversion nodes. Then you refactor the IR graph to use `sqrt_float16` directly, presumably with fewer conversions (and/or reinterprets). Same argument for max, min, add, mul, etc. I'm not saying the current PR is wrong, but I would like to know if it could be simplified, either now or later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2424373685 From jbhateja at openjdk.org Tue Nov 19 19:57:14 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 19 Nov 2024 19:57:14 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja wrote: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 6. Auto-vectorization of newly supported scalar operations. > 7. X86 and AARCH64 backend implementation for all supported intrinsics. > 9. Functional and Performance validation tests. > > **Missing Pieces:-** > **- AARCH64 Backend.** > > Kindly review and share your feedback. > > Best Regards, > Jatin Extending on John's thoughts. ![image](https://github.com/user-attachments/assets/c795e79f-a857-4991-9b8a-c36d8525ba73) ![image](https://github.com/user-attachments/assets/264eeeea-86a0-43ed-a365-88b91e85d9cc) There are two possibilities of a pattern match here, one rooted at node **A** and other at **B** With pattern match rooted at **A**, we will need to inject additional ConvHF2F after replacing AddF with AddHF to preserve the type semantics of IR graph, [significand bit preservation constraints](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Float.java#L1103) for NaN value imposed by Float.float16ToFloat API makes the idealization toward the end infeasible, thereby reducing the operating vector size for FP16 operation to half of what can be possible, as depicted by following Ideal graph fragment. ![image](https://github.com/user-attachments/assets/0094e613-2c11-40db-b2bb-84ddf6b251f2) Thus only feasible match is the one rooted at node **B** ![image](https://github.com/user-attachments/assets/22576617-9533-40e2-94f0-dd6048e295dd) Please consider Java side implimentation of Float16.sqrt Float16 sqrt(Float16 radicand) { return valueOf(Math.sqrt(radicand.doubleValue())); } Here, radicand is first upcasted to doubelValue, following 2P+2 rule of IEEE 754, square root computed at double precision is not subjected to double rounding penalty when final results is down casted to Float16 value. Following is the C2 IR for above Java implementation. T0 = Param0 (TypeInt::SHORT) T1 = CastHF2F T0 T2 = CastF2D T1 T3 = SqrtD T2 T4 = ConvD2F T3 T5 = CastF2HF T4 To replace SqrtD with SqrtHF, we need following IR modifications. T0 = Param0 (TypeInt::SHORT) // Replacing IR T1-T3 in original fragment with following IR T1-T6. T1 = ReinterpretS2HF T0 T3 = SqrtHF T1 T4 = ReinterpretHF2S T3 T5 = ConvHF2F T4 T6 = ConvF2D T5 T7 = ConvD2F T6 T5 = CastF2HF T4 Simplified IR after applying Identity rules , T0 = Param0 (TypeInt::SHORT) // Replacing IR T1-T3 in original fragment with following IR T1-T6. T1 = ReinterpretS2HF T0 T3 = SqrtHF T1 T4 = ReinterpretHF2S T3 While above transformation are valid replacements for current intrinsic approach which uses explicit entry points in newly defined Float16Math helper class, they deviate from implementation of several j.l intrinsified methods which could be replaced by pattern matches e.g. https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Math.java#L2022 https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Math.java#L2116 I think we need to carefully pick pattern match over intrinsification if former handles more general cases. If our intention is to capture various Float16 operation patterns in user's code which does not directly uses Float16 API then pattern matching looks appealing, but APIs like SQRT and FMA are very carefully drafted keeping in view rounding impact, and such patterns will be hard to find, thus it should be ok to take intrinsic route for them, simpler cases like add / sub / mul /div / max / min can be handled through a pattern matching approach. There are also some issues around VM symbol creations for intrinsic entries defined in non-java.base modules which did not surface with then Float16 and Float16Math were part of java.base module. For this PR taking hybrid approach comprising of both pattern match and intensification looks reasonable to me. Please let me know if you have any comments. Some FAQs on the newly added ideal type for half-float IR nodes:- Q. Why do we not use existing TypeInt::SHORT instead of creating a new TypeH type? A. Newly defined half float type named TypeH is special as its basictype is T_SHORT while its ideal type is RegF. Thus, the C2 type system views its associated IR node as a 16-bit short value while the register allocator assigns it a floating point register. Q. Problem with ConF? A. During Auto-Vectorization, ConF replication constrains the operational vector lane count to half of what can otherwise be used for regular Float16 operation i.e. only 16 floats can be accommodated into a 512-bit vector thereby limiting the lane count of vectors in its use-def chain, one possible way to address it is through a kludge in auto-vectorizer to cast them to a 16 bits constant by analyzing its context. Newly defined Float16 constant nodes 'ConH' are inherently 16-bit encoded IEEE 754 FP16 values and can be efficiently packed to leverage full target vector width. All Float16 IR nodes now carry newly defined Type::HALF_FLOAT type instead of Type::FLOAT, thus we no longer need special handling in auto-vectorizer to prune their container type to short. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2425873278 PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2482867818 From jbhateja at openjdk.org Tue Nov 19 19:57:14 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 19 Nov 2024 19:57:14 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Mon, 14 Oct 2024 15:32:41 GMT, Bhavana Kilambi wrote: > Hi Jatin, could you also include the idealization tests here - test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java and ConvF2HFIdealizationTests.java in this PR? Hi @Bhavana-Kilambi , I am in process of refining existing patch, tests and benchmark, will update the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2436821263 From darcy at openjdk.org Tue Nov 19 19:57:14 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 19 Nov 2024 19:57:14 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja wrote: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 6. Auto-vectorization of newly supported scalar operations. > 7. X86 and AARCH64 backend implementation for all supported intrinsics. > 9. Functional and Performance validation tests. > > **Missing Pieces:-** > **- AARCH64 Backend.** > > Kindly review and share your feedback. > > Best Regards, > Jatin FYI, https://github.com/openjdk/jdk/pull/21574 has been pushed, adding Float16 to the incubating vector package. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2475035058 From bkilambi at openjdk.org Tue Nov 19 19:57:14 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Tue, 19 Nov 2024 19:57:14 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 04:46:52 GMT, Jatin Bhateja wrote: >> Hi Jatin, could you also include the idealization tests here - test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java and ConvF2HFIdealizationTests.java in this PR? > >> Hi Jatin, could you also include the idealization tests here - test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java and ConvF2HFIdealizationTests.java in this PR? > > Hi @Bhavana-Kilambi , > I am in process of refining existing patch, tests and benchmark, will update the PR. Hi @jatin-bhateja , could you also please merge my patch which adds aarch64 backend for these operations here - https://github.com/jatin-bhateja/jdk/pull/6 If you feel there needs to be any changes made before you'd like to merge it, please do let me know and I'll do it. Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2476695747 From psandoz at openjdk.org Tue Nov 19 19:57:14 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 19 Nov 2024 19:57:14 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 04:46:52 GMT, Jatin Bhateja wrote: >> Hi Jatin, could you also include the idealization tests here - test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java and ConvF2HFIdealizationTests.java in this PR? > >> Hi Jatin, could you also include the idealization tests here - test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java and ConvF2HFIdealizationTests.java in this PR? > > Hi @Bhavana-Kilambi , > I am in process of refining existing patch, tests and benchmark, will update the PR. @jatin-bhateja i commented directly on code in the commit entitled "Annotating Float16 as a ValueBased class" but i don't see it. This is not the right way to it, see my [comment](https://github.com/openjdk/jdk/pull/21574#discussion_r1841020576) related to this on Joe's FLoat16 PR. We should address it as a separate PR for ease of review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2476891427 From sviswanathan at openjdk.org Tue Nov 19 19:57:19 2024 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 19 Nov 2024 19:57:19 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja wrote: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 6. Auto-vectorization of newly supported scalar operations. > 7. X86 and AARCH64 backend implementation for all supported intrinsics. > 9. Functional and Performance validation tests. > > **Missing Pieces:-** > **- AARCH64 Backend.** > > Kindly review and share your feedback. > > Best Regards, > Jatin src/hotspot/cpu/x86/assembler_x86.cpp line 3481: > 3479: void Assembler::vmovw(XMMRegister dst, Register src) { > 3480: assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16"); > 3481: InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false); It will be good to have the second argument with comment as "/* vex_w */ false". src/hotspot/cpu/x86/assembler_x86.cpp line 3483: > 3481: InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false); > 3482: attributes.set_is_evex_instruction(); > 3483: int encode = vex_prefix_and_encode(dst->encoding(), 0, src->encoding(), VEX_SIMD_66, VEX_OPCODE_MAP5, &attributes); I think we need to change this to: int encode = vex_prefix_and_encode(dst->encoding(), 0, src->encoding(), VEX_SIMD_66, VEX_OPCODE_MAP5, &attributes, true); Please note the last argument for APX encoding when src is in higher register bank. src/hotspot/cpu/x86/assembler_x86.cpp line 3489: > 3487: void Assembler::vmovw(Register dst, XMMRegister src) { > 3488: assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16"); > 3489: InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false); It will be good to have the second argument with comment as "/* vex_w */ false". src/hotspot/cpu/x86/assembler_x86.cpp line 3491: > 3489: InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false); > 3490: attributes.set_is_evex_instruction(); > 3491: int encode = vex_prefix_and_encode(src->encoding(), 0, dst->encoding(), VEX_SIMD_66, VEX_OPCODE_MAP5, &attributes); I think we need to change this to: int encode = vex_prefix_and_encode(src->encoding(), 0, dst->encoding(), VEX_SIMD_66, VEX_OPCODE_MAP5, &attributes, true); Please note the last argument for APX encoding when dst is in higher register bank. src/hotspot/cpu/x86/assembler_x86.cpp line 8464: > 8462: void Assembler::evaddph(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) { > 8463: assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16"); > 8464: InstructionAttr attributes(vector_len, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true); It will be good to have the second argument with comment as "/* vex_w */ false". src/hotspot/cpu/x86/assembler_x86.cpp line 8483: > 8481: void Assembler::evsubph(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) { > 8482: assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16"); > 8483: InstructionAttr attributes(vector_len, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true); It will be good to have the second argument with comment as "/* vex_w */ false" src/hotspot/cpu/x86/assembler_x86.cpp line 8502: > 8500: void Assembler::evmulph(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) { > 8501: assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16"); > 8502: InstructionAttr attributes(vector_len, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true); It will be good to have the second argument with comment as "/* vex_w */ false" src/hotspot/cpu/x86/assembler_x86.cpp line 8521: > 8519: void Assembler::evminph(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) { > 8520: assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16"); > 8521: InstructionAttr attributes(vector_len, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true); It will be good to have the second argument with comment as "/* vex_w */ false" src/hotspot/cpu/x86/assembler_x86.cpp line 8540: > 8538: void Assembler::evmaxph(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) { > 8539: assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16"); > 8540: InstructionAttr attributes(vector_len, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true); It will be good to have the second argument with comment as "/* vex_w */ false" src/hotspot/cpu/x86/assembler_x86.cpp line 8559: > 8557: void Assembler::evdivph(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) { > 8558: assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16"); > 8559: InstructionAttr attributes(vector_len, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true); It will be good to have the second argument with comment as "/* vex_w */ false" src/hotspot/cpu/x86/assembler_x86.cpp line 8576: > 8574: } > 8575: > 8576: void Assembler::evsqrtph(XMMRegister dst, XMMRegister src1, int vector_len) { A nitpick src1 could be src :). src/hotspot/cpu/x86/assembler_x86.cpp line 8614: > 8612: } > 8613: > 8614: void Assembler::eaddsh(XMMRegister dst, XMMRegister nds, XMMRegister src) { This should be vaddsh. src/hotspot/cpu/x86/assembler_x86.cpp line 8616: > 8614: void Assembler::eaddsh(XMMRegister dst, XMMRegister nds, XMMRegister src) { > 8615: assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16"); > 8616: InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false); It will be good to have the second argument with comment as "/* vex_w */ false" src/hotspot/cpu/x86/assembler_x86.cpp line 8622: > 8620: } > 8621: > 8622: void Assembler::esubsh(XMMRegister dst, XMMRegister nds, XMMRegister src) { This should be vsubsh. src/hotspot/cpu/x86/assembler_x86.cpp line 8624: > 8622: void Assembler::esubsh(XMMRegister dst, XMMRegister nds, XMMRegister src) { > 8623: assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16"); > 8624: InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false); It will be good to have the second argument with comment as "/* vex_w */ false" src/hotspot/cpu/x86/assembler_x86.cpp line 8630: > 8628: } > 8629: > 8630: void Assembler::edivsh(XMMRegister dst, XMMRegister nds, XMMRegister src) { This should be vdivsh. src/hotspot/cpu/x86/assembler_x86.cpp line 8632: > 8630: void Assembler::edivsh(XMMRegister dst, XMMRegister nds, XMMRegister src) { > 8631: assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16"); > 8632: InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false); It will be good to have the second argument with comment as "/* vex_w */ false" src/hotspot/cpu/x86/assembler_x86.cpp line 8638: > 8636: } > 8637: > 8638: void Assembler::emulsh(XMMRegister dst, XMMRegister nds, XMMRegister src) { This should be vmulsh. src/hotspot/cpu/x86/assembler_x86.cpp line 8640: > 8638: void Assembler::emulsh(XMMRegister dst, XMMRegister nds, XMMRegister src) { > 8639: assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16"); > 8640: InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false); It will be good to have the second argument with comment as "/* vex_w */ false" src/hotspot/cpu/x86/assembler_x86.cpp line 8646: > 8644: } > 8645: > 8646: void Assembler::emaxsh(XMMRegister dst, XMMRegister nds, XMMRegister src) { This should be vmaxsh. src/hotspot/cpu/x86/assembler_x86.cpp line 8648: > 8646: void Assembler::emaxsh(XMMRegister dst, XMMRegister nds, XMMRegister src) { > 8647: assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16"); > 8648: InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false); It will be good to have the second argument with comment as "/* vex_w */ false" src/hotspot/cpu/x86/assembler_x86.cpp line 8654: > 8652: } > 8653: > 8654: void Assembler::eminsh(XMMRegister dst, XMMRegister nds, XMMRegister src) { This should be vminsh. src/hotspot/cpu/x86/assembler_x86.cpp line 8656: > 8654: void Assembler::eminsh(XMMRegister dst, XMMRegister nds, XMMRegister src) { > 8655: assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16"); > 8656: InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false); It will be good to have the second argument with comment as "/* vex_w */ false" src/hotspot/cpu/x86/assembler_x86.cpp line 8662: > 8660: } > 8661: > 8662: void Assembler::esqrtsh(XMMRegister dst, XMMRegister src) { This should be vsqrtsh. src/hotspot/cpu/x86/assembler_x86.cpp line 8664: > 8662: void Assembler::esqrtsh(XMMRegister dst, XMMRegister src) { > 8663: assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16"); > 8664: InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false); It will be good to have the second argument with comment as "/* vex_w */ false" src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3974: > 3972: generate_libm_stubs(); > 3973: > 3974: StubRoutines::_fmod = generate_libmFmod(); // from stubGenerator_x86_64_fmod.cpp Good to retain the is_intrinsic_available checks. src/hotspot/cpu/x86/x86.ad line 4518: > 4516: #ifdef _LP64 > 4517: instruct ReplS_imm(vec dst, immH con, rRegI rtmp) %{ > 4518: predicate(VM_Version::supports_avx512_fp16() && Matcher::vector_element_basic_type(n) == T_SHORT); I have a question about the predicate for ReplS_imm. What happens if the predicate is false? There doesn't seem to be any other instruct rule to cover that situation. Also I don't see any check in match rule supported on Replicate node. src/hotspot/cpu/x86/x86.ad line 10895: > 10893: format %{ "esqrtsh $dst, $src" %} > 10894: ins_encode %{ > 10895: int opcode = this->ideal_Opcode(); opcode is unused. src/hotspot/cpu/x86/x86.ad line 10936: > 10934: ins_encode %{ > 10935: int vlen_enc = vector_length_encoding(this); > 10936: int opcode = this->ideal_Opcode(); opcode unused later. src/hotspot/cpu/x86/x86.ad line 10949: > 10947: ins_encode %{ > 10948: int vlen_enc = vector_length_encoding(this); > 10949: int opcode = this->ideal_Opcode(); opcode unused later. src/hotspot/cpu/x86/x86.ad line 10964: > 10962: match(Set dst (SubVHF src1 src2)); > 10963: format %{ "evbinopfp16_reg $dst, $src1, $src2" %} > 10964: ins_cost(450); Why ins_cost 450 here for reg version and 150 for mem version of binOps? Whereas sqrt above has 150 cost for both reg and mem version. Good to be consistent. src/hotspot/cpu/x86/x86.ad line 11012: > 11010: effect(DEF dst); > 11011: format %{ "evfmaph_reg $dst, $src1, $src2\t# $dst = $dst * $src1 + $src2 fma packedH" %} > 11012: ins_cost(450); Good to be consistent with ins_cost for reg vs mem version. src/hotspot/cpu/x86/x86.ad line 11015: > 11013: ins_encode %{ > 11014: int vlen_enc = vector_length_encoding(this); > 11015: __ evfmadd132ph($dst$$XMMRegister, $src2$$XMMRegister, $src1$$XMMRegister, vlen_enc); Wondering if for auto vectorization the natural fma form is dst = dst + src1 * src2 i.e. match(Set dst (FmaVHF dst (Binary src1 src2))); which then leads to fmadd231. src/hotspot/share/adlc/output_h.cpp line 1298: > 1296: case Form::idealD: type = "Type::DOUBLE"; break; > 1297: case Form::idealL: type = "TypeLong::LONG"; break; > 1298: case Form::idealH: type = "Type::HALF_LONG"; break; This should be Type::HALF_FLOAT src/hotspot/share/classfile/vmSymbols.hpp line 143: > 141: template(java_util_DualPivotQuicksort, "java/util/DualPivotQuicksort") \ > 142: template(jdk_internal_misc_Signal, "jdk/internal/misc/Signal") \ > 143: template(jdk_internal_math_Float16Math, "jdk/internal/math/Float16Math") \ This seems to be leftover template. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843870304 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843899813 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843870852 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843902337 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843871328 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843906656 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843908957 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843910609 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843912897 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843914392 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843916999 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843922125 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843922490 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843923239 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843924299 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843925126 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843925319 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843926551 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843926789 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843928252 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843928447 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843929519 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843929686 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843930969 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843931641 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847403451 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847400518 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1844234786 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1844237825 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1844238487 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1844244532 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847443990 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847448109 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847470619 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847475384 From jbhateja at openjdk.org Tue Nov 19 19:57:19 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 19 Nov 2024 19:57:19 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 23:11:20 GMT, Sandhya Viswanathan wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 6. Auto-vectorization of newly supported scalar operations. >> 7. X86 and AARCH64 backend implementation for all supported intrinsics. >> 9. Functional and Performance validation tests. >> >> **Missing Pieces:-** >> **- AARCH64 Backend.** >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3974: > >> 3972: generate_libm_stubs(); >> 3973: >> 3974: StubRoutines::_fmod = generate_libmFmod(); // from stubGenerator_x86_64_fmod.cpp > > Good to retain the is_intrinsic_available checks. I reinstantiated it, it was an artifact of my commit. > src/hotspot/cpu/x86/x86.ad line 4518: > >> 4516: #ifdef _LP64 >> 4517: instruct ReplS_imm(vec dst, immH con, rRegI rtmp) %{ >> 4518: predicate(VM_Version::supports_avx512_fp16() && Matcher::vector_element_basic_type(n) == T_SHORT); > > I have a question about the predicate for ReplS_imm. What happens if the predicate is false? There doesn't seem to be any other instruct rule to cover that situation. Also I don't see any check in match rule supported on Replicate node. We only create Half Float constants (ConH) if the target supports FP16 ISA. These constants are generated by Value transforms associated with FP16-specific IR, whose creation is guarded by target-specific match rule supported checks. > src/hotspot/cpu/x86/x86.ad line 10964: > >> 10962: match(Set dst (SubVHF src1 src2)); >> 10963: format %{ "evbinopfp16_reg $dst, $src1, $src2" %} >> 10964: ins_cost(450); > > Why ins_cost 450 here for reg version and 150 for mem version of binOps? Whereas sqrt above has 150 cost for both reg and mem version. Good to be consistent. Cost does not play much role here, removed it for consistency, matching algorithm is a BURS style two pass algorithm, binary state tree construction is done during a bottom-up walk of expressions, each state captures the cost associated with different reductions, actual selection is done through top down walk of the state tree, it is during this stage we pick the reduction with minimum cost from the set of reductions generating same kinds of result operand, once selected, matcher then follows the low-cost path of the state tree, associating cost guide the selector in choosing from the set of active reducitions. in general it's advisable to assign lower cost to memory variant patterns on CISC targets since this way we can save emitting explicit load. > src/hotspot/cpu/x86/x86.ad line 11015: > >> 11013: ins_encode %{ >> 11014: int vlen_enc = vector_length_encoding(this); >> 11015: __ evfmadd132ph($dst$$XMMRegister, $src2$$XMMRegister, $src1$$XMMRegister, vlen_enc); > > Wondering if for auto vectorization the natural fma form is dst = dst + src1 * src2 i.e. > match(Set dst (FmaVHF dst (Binary src1 src2))); > which then leads to fmadd231. ISA supports multiple flavors, the current scheme is in line with the wiring of inputs done before matching. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847906271 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847906153 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847907028 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847906530 From sviswanathan at openjdk.org Tue Nov 19 19:57:19 2024 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 19 Nov 2024 19:57:19 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: <3vPdEXbVVSjvDf_JAaLRwBTsYCBuD631lPgFz6pIkV4=.65022b33-9275-41ba-83e0-64df0b07f31b@github.com> On Tue, 19 Nov 2024 00:29:42 GMT, Sandhya Viswanathan wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 6. Auto-vectorization of newly supported scalar operations. >> 7. X86 and AARCH64 backend implementation for all supported intrinsics. >> 9. Functional and Performance validation tests. >> >> **Missing Pieces:-** >> **- AARCH64 Backend.** >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > src/hotspot/share/classfile/vmSymbols.hpp line 143: > >> 141: template(java_util_DualPivotQuicksort, "java/util/DualPivotQuicksort") \ >> 142: template(jdk_internal_misc_Signal, "jdk/internal/misc/Signal") \ >> 143: template(jdk_internal_math_Float16Math, "jdk/internal/math/Float16Math") \ > > This seems to be leftover template. I don't see use of this one, you have another one with jdk_internal_vm_vector_Float16Math which is being used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1848295979 From sviswanathan at openjdk.org Tue Nov 19 19:57:19 2024 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 19 Nov 2024 19:57:19 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 08:43:06 GMT, Jatin Bhateja wrote: >> src/hotspot/cpu/x86/x86.ad line 11015: >> >>> 11013: ins_encode %{ >>> 11014: int vlen_enc = vector_length_encoding(this); >>> 11015: __ evfmadd132ph($dst$$XMMRegister, $src2$$XMMRegister, $src1$$XMMRegister, vlen_enc); >> >> Wondering if for auto vectorization the natural fma form is dst = dst + src1 * src2 i.e. >> match(Set dst (FmaVHF dst (Binary src1 src2))); >> which then leads to fmadd231. > > ISA supports multiple flavors, the current scheme is in line with the wiring of inputs done before matching. You could save some reg/reg movs with 231 flavor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1848290834 From bkilambi at openjdk.org Tue Nov 19 19:57:19 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Tue, 19 Nov 2024 19:57:19 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Wed, 16 Oct 2024 14:19:40 GMT, Bhavana Kilambi wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 6. Auto-vectorization of newly supported scalar operations. >> 7. X86 and AARCH64 backend implementation for all supported intrinsics. >> 9. Functional and Performance validation tests. >> >> **Missing Pieces:-** >> **- AARCH64 Backend.** >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java line 122: > >> 120: public static final String VECTOR_SIZE_64 = VECTOR_SIZE + "64"; >> 121: >> 122: private static final String TYPE_BYTE = "byte"; > > Hi Jatin, why have these changes been made? The PrintIdeal output still prints the vector size of the node in this format - `#vectord`. This test - `test/hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java` was failing due to this mismatch .. Infact many tests under test/hotspot fail due to this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1804557172 From shade at openjdk.org Tue Nov 19 20:18:20 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 19 Nov 2024 20:18:20 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: > > - Merge branch 'merge-latest' into great-genshen-pr-redux > - Use new CompactHeader forwarding APIs in generational mode > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge > - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines > > Reviewed-by: wkemper > - Merge > - 8343227: GenShen: Fold resource mark into management of preselected regions > > Reviewed-by: kdnilsen > - Merge openjdk/jdk tip into great-genshen-pr-redux > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge remote-tracking branch 'jdk/master' into merge-latest > - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 Dropping the rest of my comments from today's read before I sign off. I have reviewed 200/230 files, will continue tomorrow. src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.hpp line 76: > 74: void vmop_entry_final_roots(); > 75: > 76: private: Feel free to just make all these `protected`. It is more fuzz to try to provide the minimal possible visibility, especially if it gives the ragged visibility blocks in source. The real reason these are `private` is to protect them from accidental external use. `protected` is also good for this. src/hotspot/share/gc/shenandoah/shenandoahMarkClosures.hpp line 34: > 32: class ShenandoahHeapRegion; > 33: > 34: class ShenandoahFinalMarkUpdateRegionStateClosure : public ShenandoahHeapRegionClosure { There is the `shenandoahHeapRegionClosures.hpp` for these, no? src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp line 44: > 42: for (size_t idx = 0; idx < num_regions; idx++) { > 43: ShenandoahHeapRegion* r = heap->get_region(idx); > 44: if (r->is_affiliated() && heap->is_bitmap_slice_committed(r) && !is_bitmap_clear_range(r->bottom(), r->end())) { I don't understand this for single gen mode. In that mode `is_affiliated() == false` always, right? So this check never passes, and `is_bitmap_clear` always returns `true`? src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 657: > 655: _generation(nullptr) { > 656: if (_options._verify_marked == ShenandoahVerifier::_verify_marked_complete_satb_empty) { > 657: Threads::change_thread_claim_token(); It is fairly odd to see Verifier touching the claim token, since the bug _may be_ somewhere in parallel thread oop iteration infra. I think it is fine to just use `Threads::threads_do` (non-parallel version), which AFAIU does not require token modifications. ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2445988182 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1848675048 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1848786419 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1848781508 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1848711178 From jbhateja at openjdk.org Tue Nov 19 20:39:00 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 19 Nov 2024 20:39:00 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 12:41:46 GMT, Sandhya Viswanathan wrote: >> ISA supports multiple flavors, the current scheme is in line with the wiring of inputs done before matching. > > You could save some reg/reg movs with 231 flavor. It will depend on the live ranges of the three inputs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1849024128 From erikj at openjdk.org Tue Nov 19 20:41:22 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 19 Nov 2024 20:41:22 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v17] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Mon, 18 Nov 2024 15:12:12 GMT, Magnus Ihse Bursie wrote: >> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. >> >> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. >> >> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Copy debuginfo make/StaticLibs.gmk line 67: > 65: # BitmapToYXBandedRectangles, so we exclude it for now. > 66: BROKEN_STATIC_LIBS += splashscreen > 67: # windowsaccessbridge-64 has multiple collisions and conflicts I don't think we will ever include the accessbridge libraries. Those are never loaded by the JDK itself. They are meant to be loaded by other applications to interact with the JDK. So instead of classifying them as "broken", I think they should just be permanently excluded for a valid reason. make/autoconf/buildjdk-spec.gmk.template line 80: > 78: CXXFLAGS_JDKEXE := @OPENJDK_BUILD_CXXFLAGS_JDKEXE@ > 79: LDFLAGS_JDKEXE := @OPENJDK_BUILD_LDFLAGS_JDKEXE@ > 80: LDFLAGS_STATIC_JDK := @OPENJDK_BUILD_LDFLAGS_STATIC_JDK@ Do we really expect to ever build a static-jdk as buildjdk? make/common/JdkNativeCompilation.gmk line 313: > 311: # created libraries, and is read by ModuleWrapper. > 312: ifneq ($$($1_EXCLUDE_FROM_STATIC_LIBS), true) > 313: $$(MODULE)_JDK_LIBS += $$($1_NAME) This variable is used to track libraries that should be included in static libs. Perhaps the name should include the word "static" to make this clearer? Otherwise it doesn't make sense to exclude libraries like this from this list. make/modules/java.desktop/lib/ClientLibraries.gmk line 166: > 164: jfdctflt.o jfdctfst.o jfdctint.o jidctflt.o jidctfst.o jidctint.o \ > 165: jidctred.o jmemmgr.o jmemnobs.o jpegdecoder.o jquant1.o jquant2.o \ > 166: jutils.o If libsplashscreen is already excluded in StaticLibs.gmk, why do we need to exclude obj files here? Would it be possible to generate this list? I assume it's all the src files in libjavajpeg, but with the object file suffix. make/modules/java.desktop/lib/ClientLibraries.gmk line 180: > 178: deflate.o Deflater.o Inflater.o gzclose.o gzlib.o gzread.o gzwrite.o \ > 179: infback.o inffast.o inflate.o inftrees.o trees.o uncompr.o zadler32.o \ > 180: zcrc32.o zip_util.o zutil.o Same as above. make/modules/jdk.accessibility/Lib.gmk line 77: > 75: VERSIONINFO_RESOURCE := \ > 76: $(ACCESSIBILITY_SRCDIR)/common/AccessBridgeStatusWindow.rc, \ > 77: STATIC_LIB_EXCLUDE_OBJS := AccessBridgeDebug.obj AccessBridgeMessages.obj, \ Again, the accessbridge libraries aren't loaded by the JDK, so it doesn't really make sense to include them in a single static launcher. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1848957096 PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1849009531 PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1849016315 PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1849022738 PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1849023239 PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1849026904 From mli at openjdk.org Tue Nov 19 20:57:50 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 19 Nov 2024 20:57:50 GMT Subject: RFR: 8344010: RISC-V: Zacas do not work with LW locking In-Reply-To: <9zxKdn73DHLKXicGNz8Wygje-qKJMlvy4sTcKz3che8=.ee30bec8-f557-4436-9e77-70d5a06e3590@github.com> References: <9zxKdn73DHLKXicGNz8Wygje-qKJMlvy4sTcKz3che8=.ee30bec8-f557-4436-9e77-70d5a06e3590@github.com> Message-ID: On Fri, 15 Nov 2024 13:01:37 GMT, Robbin Ehn wrote: > Hi all, please consider. > > Light weight locking fails: > - We need to add cas acquire. > - Register _result_ may shadow _new_val_ (same register). > (NOTE this second item can effect many other cases, unclear) > > As the code becomes much cleaner by calling amocas_d/w directly I removed the aliases. > Which fixes the first issue with cas acquire. > > By using t0 instead of _result_ we fix the other issue. > > This is a short bugfix, there are so many dragons here that I do not want to address them while fixing the bug. > There are also several performance optimizations we can do here, specially for LR/SC case. > So I'll do a couple of more iterations of this code in seperate PR's. > > Testing a bunch of local cherry-picked tests which failed. > I'll start tier1 over the weekend. > > Thanks, Robbin Nice catch and cleanup, looks much better! Just one minor comment. src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 3488: > 3486: } else { > 3487: mv(t0, expected); > 3488: atomic_cas(t0, new_val, addr, size, acquire, release); Not sure if I understand this correctly. Could it be better to tell if `result` == `new_val`? If false, then we don't need the extra `mv`. ------------- PR Review: https://git.openjdk.org/jdk/pull/22149#pullrequestreview-2446635561 PR Review Comment: https://git.openjdk.org/jdk/pull/22149#discussion_r1849044858 From dcubed at openjdk.org Tue Nov 19 21:00:56 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 19 Nov 2024 21:00:56 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing In-Reply-To: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: <_Cl08mVfRxZKcnvhcAceCFi1hU255fNyFcDoWqT2KCk=.f9007475-f7b4-4c21-a0d9-0b2795dc4544@github.com> On Tue, 19 Nov 2024 13:09:22 GMT, Fredrik Bredberg wrote: > @dcubed-ojdk is too busy, so I was asked to take over [https://github.com/openjdk/jdk/pull/18664](https://github.com/openjdk/jdk/pull/18664) and finish it. > > That old PR contains all the details and also got some review comments, which I have tried to address in this new PR. > > Tests run without failures on supported platforms. Thumbs up. I have only editorial type questions/comments. test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 230: > 228: counter++; > 229: > 230: // Legacy mode has no lock stack. I.e. there is no limit nit grammar/typography: s/. I.e. there/, i.e., there test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 238: > 236: } > 237: > 238: // We havn't reached the stack lock capasity (recursion nit typo: s/capasity/capacity/ test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 270: > 268: } > 269: > 270: // This test nests x recurcive locks of INNER, in x recursive nit typo: s/recurcive/recursive/ test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 271: > 269: > 270: // This test nests x recurcive locks of INNER, in x recursive > 271: // locks of OUTER. The number x is taken from the max number nit spacing: s/OUTER. The/OUTER. The/ test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 316: > 314: } else { > 315: // Second time we want to lock A, the lock stack > 316: // looks like this [A, B]. Lightweight locking nit spacing: s/B]. Lightweight/B]. Lightweight/ test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 318: > 316: // looks like this [A, B]. Lightweight locking > 317: // doesn't allow interleaving ([A, B, A]), instead > 318: // it inflates A and removed it from the lock nit typo: s/removed/removes/ test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 375: > 373: } > 374: // Implied else: for LM_MONITOR or LM_LIGHTWEIGHT it can be > 375: // either inflated or not point because A is not locked anymore nit typo: s/either inflated or not point because/either inflated or not because/ test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 399: > 397: System.err.println("where:"); > 398: System.err.println(" n_secs ::= > 0"); > 399: System.err.println(" Default n_secs is 15."); Based on L408 below, it looks like default n_secs is now `30`. test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 402: > 400: System.err.println(" mode ::= 1 - outer and inner"); > 401: System.err.println(" ::= 2 - alternate A and B"); > 402: System.err.println(" Default mode is 1."); Based on L407 below, it looks like default mode is now `2`. test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 503: > 501: waiter.wait(); > 502: } catch (InterruptedException ie) { > 503: } Do you want to add this: // This should not happen. ie.printStackTrace(); here also? test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 541: > 539: waiter.wait(); > 540: } catch (InterruptedException ie) { > 541: } Do you want to add this: // This should not happen. ie.printStackTrace(); here also? test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 556: > 554: waiter.wait(); > 555: } catch (InterruptedException ie) { > 556: } Do you want to add this: // This should not happen. ie.printStackTrace(); here also? ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22238#pullrequestreview-2446595738 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1849021244 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1849020338 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1849022916 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1849023663 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1849026085 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1849026539 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1849030340 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1849032905 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1849033663 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1849040443 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1849041350 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1849042052 From dcubed at openjdk.org Tue Nov 19 21:00:57 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 19 Nov 2024 21:00:57 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing In-Reply-To: References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: On Tue, 19 Nov 2024 17:04:22 GMT, Coleen Phillimore wrote: >> @dcubed-ojdk is too busy, so I was asked to take over [https://github.com/openjdk/jdk/pull/18664](https://github.com/openjdk/jdk/pull/18664) and finish it. >> >> That old PR contains all the details and also got some review comments, which I have tried to address in this new PR. >> >> Tests run without failures on supported platforms. > > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 465: > >> 463: syncObj.runAlternateABTest(); >> 464: break; >> 465: > > I was wondering if this test could be reduced to run both modes in one execution, one after the other? The configurability was intentional so that specific modes could be exercised independently. Also adding additional modes in the future is/was planned. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1849036833 From xpeng at openjdk.org Tue Nov 19 21:33:57 2024 From: xpeng at openjdk.org (Xiaolong Peng) Date: Tue, 19 Nov 2024 21:33:57 GMT Subject: RFR: 8343541: C1: Plain memory accesses are emitted with membars with +AlwaysAtomicAccesses [v2] In-Reply-To: <9sZDi_ahHbkCWc7QRukVh7m8bvWbkRUvbtbG7FgkSc4=.714aac97-ace8-4357-846f-ed2e2b1f176d@github.com> References: <9sZDi_ahHbkCWc7QRukVh7m8bvWbkRUvbtbG7FgkSc4=.714aac97-ace8-4357-846f-ed2e2b1f176d@github.com> Message-ID: On Mon, 18 Nov 2024 09:30:54 GMT, Xiaolong Peng wrote: >> C1 and C2 has different implementations for `+AlwaysAtomicAccesses`, [C2 impl](https://github.com/openjdk/jdk/blob/4a7ce1d7c1bd4b751063b98cf8bedcd27055760b/src/hotspot/share/gc/shared/c2/barrierSetC2.cpp#L410) only guarantees atomicity hence no membars are emitted for plain memory access, but C1 treats it same as volatile access hence it emits membars. The change removes the unnecessary membars in C1 for `+AlwaysAtomicAccesses`. >> >> The test have been verified by very simple JMH benchmarks to measure the latency of reading/writing long/volatile long variable 10000 times, and run with VM option `-XX:TieredStopAtLevel=3 -XX:+UnlockExperimentalVMOptions -XX:+AlwaysAtomicAccesses`: >> >> Before the fix: >> >> Benchmark Mode Cnt Score Error Units >> AlwaysAtomicAccesses.testReadLong avgt 5 58711.131 ? 716.940 ns/op >> AlwaysAtomicAccesses.testReadVolatileLong avgt 5 59014.735 ? 675.354 ns/op >> AlwaysAtomicAccesses.testWriteLong avgt 5 115817.978 ? 302.089 ns/op >> AlwaysAtomicAccesses.testWriteVolatileLong avgt 5 116317.835 ? 1451.365 ns/op >> >> >> After the fix: >> >> Benchmark Mode Cnt Score Error Units >> AlwaysAtomicAccesses.testReadLong avgt 5 49651.527 ? 159.948 ns/op >> AlwaysAtomicAccesses.testReadVolatileLong avgt 5 58668.844 ? 316.029 ns/op >> AlwaysAtomicAccesses.testWriteLong avgt 5 23008.361 ? 10.947 ns/op >> AlwaysAtomicAccesses.testWriteVolatileLong avgt 5 116440.017 ? 1240.832 ns/op > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > renaming Thanks all for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22191#issuecomment-2486793350 From duke at openjdk.org Tue Nov 19 21:33:57 2024 From: duke at openjdk.org (duke) Date: Tue, 19 Nov 2024 21:33:57 GMT Subject: RFR: 8343541: C1: Plain memory accesses are emitted with membars with +AlwaysAtomicAccesses [v2] In-Reply-To: <9sZDi_ahHbkCWc7QRukVh7m8bvWbkRUvbtbG7FgkSc4=.714aac97-ace8-4357-846f-ed2e2b1f176d@github.com> References: <9sZDi_ahHbkCWc7QRukVh7m8bvWbkRUvbtbG7FgkSc4=.714aac97-ace8-4357-846f-ed2e2b1f176d@github.com> Message-ID: On Mon, 18 Nov 2024 09:30:54 GMT, Xiaolong Peng wrote: >> C1 and C2 has different implementations for `+AlwaysAtomicAccesses`, [C2 impl](https://github.com/openjdk/jdk/blob/4a7ce1d7c1bd4b751063b98cf8bedcd27055760b/src/hotspot/share/gc/shared/c2/barrierSetC2.cpp#L410) only guarantees atomicity hence no membars are emitted for plain memory access, but C1 treats it same as volatile access hence it emits membars. The change removes the unnecessary membars in C1 for `+AlwaysAtomicAccesses`. >> >> The test have been verified by very simple JMH benchmarks to measure the latency of reading/writing long/volatile long variable 10000 times, and run with VM option `-XX:TieredStopAtLevel=3 -XX:+UnlockExperimentalVMOptions -XX:+AlwaysAtomicAccesses`: >> >> Before the fix: >> >> Benchmark Mode Cnt Score Error Units >> AlwaysAtomicAccesses.testReadLong avgt 5 58711.131 ? 716.940 ns/op >> AlwaysAtomicAccesses.testReadVolatileLong avgt 5 59014.735 ? 675.354 ns/op >> AlwaysAtomicAccesses.testWriteLong avgt 5 115817.978 ? 302.089 ns/op >> AlwaysAtomicAccesses.testWriteVolatileLong avgt 5 116317.835 ? 1451.365 ns/op >> >> >> After the fix: >> >> Benchmark Mode Cnt Score Error Units >> AlwaysAtomicAccesses.testReadLong avgt 5 49651.527 ? 159.948 ns/op >> AlwaysAtomicAccesses.testReadVolatileLong avgt 5 58668.844 ? 316.029 ns/op >> AlwaysAtomicAccesses.testWriteLong avgt 5 23008.361 ? 10.947 ns/op >> AlwaysAtomicAccesses.testWriteVolatileLong avgt 5 116440.017 ? 1240.832 ns/op > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > renaming @pengxiaolong Your change (at version df0fc9085e88b7fa3cec8c38fd15b30754112e43) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22191#issuecomment-2486795047 From coleenp at openjdk.org Tue Nov 19 21:46:49 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 19 Nov 2024 21:46:49 GMT Subject: RFR: 8344579: Clean up forward declarations Message-ID: I was looking through the sources for something and found these forward declarations that should be removed. Please review this trivial change. Sanity tested with tier1. Will also verify GHA pass. ------------- Commit messages: - 8344579: Clean up forward declarations Changes: https://git.openjdk.org/jdk/pull/22258/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22258&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344579 Stats: 8 lines in 4 files changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22258.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22258/head:pull/22258 PR: https://git.openjdk.org/jdk/pull/22258 From gziemski at openjdk.org Tue Nov 19 22:01:13 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 19 Nov 2024 22:01:13 GMT Subject: RFR: 8328944: NMT reports "unknown" memory [v2] In-Reply-To: References: Message-ID: <6Up1fGCFJl2HAUGl6IBKEDRodItQLn5TigHJEdzZpbU=.5f5ae17c-edc4-4dd8-ae09-8e8ae8567354@github.com> > We use `mtNone` value in several functions default parameters, which may show up in NMT reports. > > We address this, by avoiding using `mtNone`. > > Eventually the goal would be to eliminate using `mtNone` whenever possible. > TODO: update copyrights. > > Testing: undergoing MARCH5 tier1-5 ... Gerard Ziemski 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: - avoid using mtNone - Merge remote-tracking branch 'upstream/master' into JDK-8328944 - revert, we will re-do with a smaller change - remove more mtNone - remove API that allows to change the mem_tag for virtual memory, feedback - do not allow default parameter for mtNone ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21843/files - new: https://git.openjdk.org/jdk/pull/21843/files/483e08c2..33dbafdc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21843&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21843&range=00-01 Stats: 317732 lines in 4373 files changed: 167679 ins; 118575 del; 31478 mod Patch: https://git.openjdk.org/jdk/pull/21843.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21843/head:pull/21843 PR: https://git.openjdk.org/jdk/pull/21843 From jsjolen at openjdk.org Tue Nov 19 22:01:14 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 19 Nov 2024 22:01:14 GMT Subject: RFR: 8328944: NMT reports "unknown" memory [v2] In-Reply-To: <6Up1fGCFJl2HAUGl6IBKEDRodItQLn5TigHJEdzZpbU=.5f5ae17c-edc4-4dd8-ae09-8e8ae8567354@github.com> References: <6Up1fGCFJl2HAUGl6IBKEDRodItQLn5TigHJEdzZpbU=.5f5ae17c-edc4-4dd8-ae09-8e8ae8567354@github.com> Message-ID: <9xoUh9CZ5_j-7NY_SEyCdBNRKoa2sh0Kjvvc2GqkPlM=.51706e78-822d-4c9e-a486-d4a839366854@github.com> On Tue, 19 Nov 2024 21:57:52 GMT, Gerard Ziemski wrote: >> We use `mtNone` value in several functions default parameters, which may show up in NMT reports. >> >> We address this, by avoiding using `mtNone`. >> >> Eventually the goal would be to eliminate using `mtNone` whenever possible. >> TODO: update copyrights. >> >> Testing: undergoing MARCH5 tier1-5 ... > > Gerard Ziemski 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: > > - avoid using mtNone > - Merge remote-tracking branch 'upstream/master' into JDK-8328944 > - revert, we will re-do with a smaller change > - remove more mtNone > - remove API that allows to change the mem_tag for virtual memory, feedback > - do not allow default parameter for mtNone Why should we supplement `mtNone` with `mtAllocated`? Is one indicative of a failure mode? src/hotspot/share/nmt/virtualMemoryTracker.hpp line 389: > 387: static bool remove_released_region (address base_addr, size_t size); > 388: static bool remove_released_region (ReservedMemoryRegion* rgn); > 389: static void set_reserved_region_type (address addr, MemTag mem_tag); I don't think that we should remove this API. It may very well need to be used, even if its usage should be minimized. src/hotspot/share/runtime/os.hpp line 460: > 458: // Attempts to reserve the virtual memory at [addr, addr + bytes). > 459: // Does not overwrite existing mappings. > 460: static char* attempt_reserve_memory_at(char* addr, size_t bytes, bool executable, MemTag mem_tag); Is it worth adding an overload: `reserve_memory(bytes, mem_tag)` where `executable` is implicitly `false`? test/hotspot/gtest/memory/test_virtualspace.cpp line 374: > 372: alignment, // alignment > 373: page_size, // page size > 374: (char *)nullptr, // requested_address Style fix: Remove space between `char` and `*` ------------- PR Review: https://git.openjdk.org/jdk/pull/21843#pullrequestreview-2442231730 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1846345086 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1846346929 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1846350091 From gziemski at openjdk.org Tue Nov 19 22:01:14 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 19 Nov 2024 22:01:14 GMT Subject: RFR: 8328944: NMT reports "unknown" memory In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 20:44:50 GMT, Gerard Ziemski wrote: > We use `mtNone` value in several functions default parameters, which may show up in NMT reports. > > We address this, by avoiding using `mtNone`. > > Eventually the goal would be to eliminate using `mtNone` whenever possible. > TODO: update copyrights. > > Testing: undergoing MARCH5 tier1-5 ... I re-did this fix from scratch, making sure that we do not loose Thomas'es expert knowledge, which he shared in his feedback. This fix focuses on fixing the cases in the issue. The more general approach to limit `mtNone` usage is left for a followup. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21843#issuecomment-2486834505 From gziemski at openjdk.org Tue Nov 19 22:01:14 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 19 Nov 2024 22:01:14 GMT Subject: RFR: 8328944: NMT reports "unknown" memory [v2] In-Reply-To: <9xoUh9CZ5_j-7NY_SEyCdBNRKoa2sh0Kjvvc2GqkPlM=.51706e78-822d-4c9e-a486-d4a839366854@github.com> References: <6Up1fGCFJl2HAUGl6IBKEDRodItQLn5TigHJEdzZpbU=.5f5ae17c-edc4-4dd8-ae09-8e8ae8567354@github.com> <9xoUh9CZ5_j-7NY_SEyCdBNRKoa2sh0Kjvvc2GqkPlM=.51706e78-822d-4c9e-a486-d4a839366854@github.com> Message-ID: On Mon, 18 Nov 2024 10:42:59 GMT, Johan Sj?len wrote: > Why should we supplement `mtNone` with `mtAllocated`? Is one indicative of a failure mode? That is the general idea, if we see `mtNone` in a report we know we missed something. `mtAllocated` would be the one indicating that we are "in transition". But I put it back into draft mode to experiment and get a better picture on how to proceed. > src/hotspot/share/nmt/virtualMemoryTracker.hpp line 389: > >> 387: static bool remove_released_region (address base_addr, size_t size); >> 388: static bool remove_released_region (ReservedMemoryRegion* rgn); >> 389: static void set_reserved_region_type (address addr, MemTag mem_tag); > > I don't think that we should remove this API. It may very well need to be used, even if its usage should be minimized. If there is currently no-one using it, then we should remove it. We can add it back, once we need it. > src/hotspot/share/runtime/os.hpp line 460: > >> 458: // Attempts to reserve the virtual memory at [addr, addr + bytes). >> 459: // Does not overwrite existing mappings. >> 460: static char* attempt_reserve_memory_at(char* addr, size_t bytes, bool executable, MemTag mem_tag); > > Is it worth adding an overload: `reserve_memory(bytes, mem_tag)` where `executable` is implicitly `false`? I would want that myself too, but that requires that we put it at the end, which I did in fact had at one point, but didn't like the parameters call order - the mem_tag is usually the very last one. > test/hotspot/gtest/memory/test_virtualspace.cpp line 374: > >> 372: alignment, // alignment >> 373: page_size, // page size >> 374: (char *)nullptr, // requested_address > > Style fix: Remove space between `char` and `*` Fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21843#issuecomment-2483404110 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1847064817 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1846811525 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1847065123 From coleenp at openjdk.org Tue Nov 19 22:17:56 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 19 Nov 2024 22:17:56 GMT Subject: RFR: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf [v2] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 09:02:10 GMT, David Holmes wrote: >> This is mostly an audit of the callers of `Exceptions::fthrow` to ensure unbounded strings can't appear. >> >> There is a code change in DiagnosticCmd parsing to extend the string length limit already used in part of that code. >> >> Testing: >> - tier 1-3 (sanity) >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Restore previous behaviour for zero length strings Okay, I understand the change now. Looks good. src/hotspot/share/interpreter/linkResolver.cpp line 328: > 326: > 327: // Names are all known to be < 64k so we know this formatted message is not excessively large. > 328: Can you move this comment to before the first fthrow call at 331? The other fthrow has a msg so doesn't really apply and the comment looks better as just one line like the other places. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21867#pullrequestreview-2446760257 PR Review Comment: https://git.openjdk.org/jdk/pull/21867#discussion_r1849122316 From stefank at openjdk.org Tue Nov 19 22:48:14 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 19 Nov 2024 22:48:14 GMT Subject: RFR: 8344579: Clean up forward declarations and includes In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 21:42:07 GMT, Coleen Phillimore wrote: > I was looking through the sources for something and found these forward declarations that should be removed. Please review this trivial change. > > Sanity tested with tier1. Will also verify GHA pass. Looks good. You do change includes as well, so the bug name could be better. Marked as reviewed by stefank (Reviewer). ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22258#pullrequestreview-2446782709 PR Review: https://git.openjdk.org/jdk/pull/22258#pullrequestreview-2446790997 From coleenp at openjdk.org Tue Nov 19 22:48:17 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 19 Nov 2024 22:48:17 GMT Subject: RFR: 8344579: Clean up forward declarations and includes In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 21:42:07 GMT, Coleen Phillimore wrote: > I was looking through the sources for something and found these forward declarations that should be removed. Please review this trivial change. > > Sanity tested with tier1. Will also verify GHA pass. Thanks Stefan, I also changed the titles. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22258#issuecomment-2486885188 From wkemper at openjdk.org Tue Nov 19 23:02:22 2024 From: wkemper at openjdk.org (William Kemper) Date: Tue, 19 Nov 2024 23:02:22 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Mon, 18 Nov 2024 16:22:31 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp line 193: > >> 191: Phase phase = Phase(pi); >> 192: if (is_worker_phase(phase)) { >> 193: double sum = uninitialized(); > > I think you can avoid changing this method to limit the churn. Hmm, I find the version in the PR much more readable. How about we upstream these changes separately? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849160336 From wkemper at openjdk.org Tue Nov 19 23:10:34 2024 From: wkemper at openjdk.org (William Kemper) Date: Tue, 19 Nov 2024 23:10:34 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 19 Nov 2024 17:31:15 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp line 44: > >> 42: for (size_t idx = 0; idx < num_regions; idx++) { >> 43: ShenandoahHeapRegion* r = heap->get_region(idx); >> 44: if (r->is_affiliated() && heap->is_bitmap_slice_committed(r) && !is_bitmap_clear_range(r->bottom(), r->end())) { > > I don't understand this for single gen mode. In that mode `is_affiliated() == false` always, right? So this check never passes, and `is_bitmap_clear` always returns `true`? No, in single gen mode regions that are not `FREE` are affiliated with `YOUNG`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849165775 From wkemper at openjdk.org Tue Nov 19 23:20:39 2024 From: wkemper at openjdk.org (William Kemper) Date: Tue, 19 Nov 2024 23:20:39 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 19 Nov 2024 17:35:14 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahMarkClosures.hpp line 34: > >> 32: class ShenandoahHeapRegion; >> 33: >> 34: class ShenandoahFinalMarkUpdateRegionStateClosure : public ShenandoahHeapRegionClosure { > > There is the `shenandoahHeapRegionClosures.hpp` for these, no? It wasn't the intention that `shenandoahHeapRegionClosures.hpp` should become home to all of the `*HeapRegionClosures`. `ShenandoahFinalMarkUpdateRegionStateClosure` is shared in a couple of implementation files, but not the same as the ones using `shenandoahHeapRegionClosures.hpp`. I think `ShenandoahUpdateCensusZeroCohortClosure` should be moved into the only implementation file that uses it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849213506 From sviswanathan at openjdk.org Tue Nov 19 23:25:20 2024 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 19 Nov 2024 23:25:20 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: <7pJQGLP9E-cCKTxiOJTIxdbGaUjRtbNWYOb-NlymDfI=.fed0c520-4406-4ca0-90a1-3cdd9565aa7d@github.com> On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja wrote: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 6. Auto-vectorization of newly supported scalar operations. > 7. X86 and AARCH64 backend implementation for all supported intrinsics. > 9. Functional and Performance validation tests. > > **Missing Pieces:-** > **- AARCH64 Backend.** > > Kindly review and share your feedback. > > Best Regards, > Jatin x86 changes look good to me. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21490#pullrequestreview-2446932147 From wkemper at openjdk.org Tue Nov 19 23:50:38 2024 From: wkemper at openjdk.org (William Kemper) Date: Tue, 19 Nov 2024 23:50:38 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: <9VBIb_uybg8Or00efuFMAfa2JbZ3RVzE6avnR5u3mBs=.bcd6bf33-b37c-4c9f-aa4b-5d540c258fdd@github.com> On Mon, 18 Nov 2024 16:20:09 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahCollectionSetPreselector.hpp line 34: > >> 32: ShenandoahCollectionSet* _cset; >> 33: bool* _pset; >> 34: ResourceMark _rm; > > Not necessarily for this PR, but something to rectify going forward. It is generally not safe to hide `ResourceMark`-s like this in the objects. Sometimes the callers return stuff allocated in resource area, and if the object like this leaves the scope, it would corrupt the memory. Normally, when we develop resource-area-returning paths, we look around near `ResourceMark`-s to see is any thing fishy is going on. It does not help when `RM` is hidden in the object like this. Understood. This change was requested earlier in the PR. > src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.hpp line 76: > >> 74: void vmop_entry_final_roots(); >> 75: >> 76: private: > > Feel free to just make all these `protected`. It is more fuzz to try to provide the minimal possible visibility, especially if it gives the ragged visibility blocks in source. The real reason these are `private` is to protect them from accidental external use. `protected` is also good for this. https://bugs.openjdk.org/browse/JDK-8344592 > src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.cpp line 49: > >> 47: const char* cns = PerfDataManager::name_space("shenandoah", "regions"); >> 48: _name_space = NEW_C_HEAP_ARRAY(char, strlen(cns)+1, mtGC); >> 49: strcpy(_name_space, cns); // copy cns into _name_space > > Suggestion: > > strcpy(_name_space, cns); > > > (The comment is self-obvious) https://bugs.openjdk.org/browse/JDK-8344592 > src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.cpp line 57: > >> 55: PerfDataManager::create_constant(SUN_GC, cname, PerfData::U_None, num_regions, CHECK); >> 56: >> 57: cname = PerfDataManager::counter_name(_name_space, "protocol_version"); //creating new protocol_version > > Suggestion: > > cname = PerfDataManager::counter_name(_name_space, "protocol_version"); https://bugs.openjdk.org/browse/JDK-8344592 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849309543 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849308822 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849309104 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849309202 From wkemper at openjdk.org Tue Nov 19 23:59:36 2024 From: wkemper at openjdk.org (William Kemper) Date: Tue, 19 Nov 2024 23:59:36 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Mon, 18 Nov 2024 16:42:50 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp line 455: > >> 453: // Note: would be sufficient to mark only the card that holds the start of this Reference object. >> 454: heap->old_generation()->card_scan()->mark_range_as_dirty(cast_from_oop(reference), reference->size()); >> 455: } > > Two things: > a) This sounds like `card_table_barrier(reference, raw_referent)`? Since this code is getting called for every dropped reference, just checking a `ShenandoahCardBarrier` flag sounds more efficient. > b) Is there a point in dirtying up to `reference->size()`? Will test this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849315332 From dholmes at openjdk.org Wed Nov 20 00:03:14 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Nov 2024 00:03:14 GMT Subject: RFR: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf [v2] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 05:16:47 GMT, David Holmes wrote: >> src/hotspot/share/utilities/exceptions.cpp line 264: >> >>> 262: // will be within reasonable limits - specifically we will never hit the INT_MAX limit >>> 263: // of os::vsnprintf when it tries to report how big a buffer is needed. Even so we >>> 264: // further limit the formatted output to 1024 characters. >> >> If we're chopping off the message at 1024 characters, why do we have to audit the callers? Is it because vsnprintf will overflow before truncating the message? Seems like it could be easy to add a caller that breaks this. There's no way to check here? > > Thanks for looking at this @coleenp . > > Yes it is because vsnprintf will try to tell you how big a buffer you would actually need when you pass a smaller size buffer. > > There is no way to know how big the formatted message would be without actually expanding it - which of course is only done by vsnprintf. > > So this comes down to doing a basic audit like this and then remembering to pay attention with new code. > > The alternative would be to define some global max string size, like the 1024 used here, and then have every caller of `fthrow` use `%*s` passing that max. But that is extremely intrusive if you look at how we end up calling `fthrow`. We have code in the classfile parser/error code where one function creates the message with the `%s` and a lower function actually supplies the argument. It is doable, but it is a lot of code churn to put up a safety rail that this code can't run into anyway. I've updated the description to clarify the problem. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21867#discussion_r1849317566 From ysr at openjdk.org Wed Nov 20 00:04:40 2024 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Wed, 20 Nov 2024 00:04:40 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: <0FH7N5Xa3DLDGZcWdxwWQHivNSTxGj9w3p-hWFSgMIs=.654c7bd9-90bb-436d-aedd-08d9fa77efc8@github.com> On Wed, 13 Nov 2024 10:51:48 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 503 commits: >> >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8342861: GenShen: Old generation in unexpected state when abandoning mixed gc candidates >> >> Reviewed-by: kdnilsen >> - 8342734: GenShen: Test failure gc/shenandoah/TestReferenceRefersToShenandoah.java#generational >> >> Reviewed-by: ysr >> - 8342919: GenShen: Fix whitespace >> >> Reviewed-by: xpeng, kdnilsen >> - 8342927: GenShen: Guarantee slices of time for coalesce and filling >> >> Reviewed-by: kdnilsen >> - 8342924: GenShen: Problem list gc/shenandoah/TestReferenceRefersToShenandoah.java >> >> Reviewed-by: kdnilsen, ysr >> - 8342848: Shenandoah: Marking bitmap may not be completely cleared in generational mode >> >> Reviewed-by: wkemper >> - ... and 493 more: https://git.openjdk.org/jdk/compare/1c448347...19b25bc3 > > src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp line 474: > >> 472: // elision safe. >> 473: return; >> 474: } > > Why is this safe for Shenandoah? I suspect it needs `CardTableBarrierSet::on_slowpath_allocation_exit` to work. `G1BarrierSetC2` gets it by subclassing `CardTableBarrierSetC2`. But `ShenandoahBarrierSetC2` does not. Should it? Good question. I'm tracking at https://bugs.openjdk.org/browse/JDK-8344593 , and will follow up there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849318244 From wkemper at openjdk.org Wed Nov 20 00:16:36 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 20 Nov 2024 00:16:36 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 19 Nov 2024 12:38:59 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 420: > >> 418: } >> 419: int gc_state = _heap->gc_state(); >> 420: if ((gc_state & ShenandoahHeap::YOUNG_MARKING) != 0) { > > It is not very clear this works fine with single-gen mode. Does `MARKING` imply `YOUNG_MARKING` in single-gen mode? I think we better make it abundantly clear with `is_generational()` checks. Yes, in single gen mode we set `MARKING` and `YOUNG_MARKING` together. See https://github.com/openjdk/shenandoah/blob/master/src/hotspot/share/gc/shenandoah/shenandoahGlobalGeneration.cpp#L81 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849325345 From wkemper at openjdk.org Wed Nov 20 00:22:40 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 20 Nov 2024 00:22:40 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 19 Nov 2024 16:46:36 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 657: > >> 655: _generation(nullptr) { >> 656: if (_options._verify_marked == ShenandoahVerifier::_verify_marked_complete_satb_empty) { >> 657: Threads::change_thread_claim_token(); > > It is fairly odd to see Verifier touching the claim token, since the bug _may be_ somewhere in parallel thread oop iteration infra. I think it is fine to just use `Threads::threads_do` (non-parallel version), which AFAIU does not require token modifications. Will test this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849329578 From dholmes at openjdk.org Wed Nov 20 00:33:31 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Nov 2024 00:33:31 GMT Subject: RFR: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf [v3] In-Reply-To: References: Message-ID: > This is mostly an audit of the callers of `Exceptions::fthrow` to ensure unbounded strings can't appear. > > There is a code change in DiagnosticCmd parsing to extend the string length limit already used in part of that code. > > Just to clarify the issue. The size 1024 is an internal buffer limit that `fthrow` uses - it is an implementation detail and not something the caller should think about. It is also not relevant to the underlying problem, which is the size of the buffer needed for the fully expanded format string, which `os::vsnprintf` will try to calculate and report. The intent is to check callers can't hit that underlying `vsnprintf` INT_MAX limit. When your format string only deals with a few symbols and symbols are always < 64K then we know we are nowhere near that INT_MAX limit. If your format string can take a potentially arbitrary (usually from outside) string then it needs to put its own size guard in place using `%*s`. > > Testing: > - tier 1-3 (sanity) > > Thanks David Holmes 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 8339134-fthrow - Restore previous behaviour for zero length strings - 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21867/files - new: https://git.openjdk.org/jdk/pull/21867/files/f0e285da..acff14ad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21867&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21867&range=01-02 Stats: 316694 lines in 4333 files changed: 167153 ins; 118341 del; 31200 mod Patch: https://git.openjdk.org/jdk/pull/21867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21867/head:pull/21867 PR: https://git.openjdk.org/jdk/pull/21867 From ccheung at openjdk.org Wed Nov 20 00:42:57 2024 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 20 Nov 2024 00:42:57 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs Message-ID: Currently, when retrieving a ClassFileStream during runtime, we call into the zip library to retrieve the stream based only on a class name. This doesn't work well if the class is in a multi-release jar under a versioned directory such as `META-INF/versions/9/Foo.class`. To address this issue, this change calls the java api `ClassLoader.getResourceAsStream()` to retrieve the stream. Passed tiers 1 - 4 testing. ------------- Commit messages: - 8343427: Class file load hook crashes on archived classes from multi-release JARs Changes: https://git.openjdk.org/jdk/pull/22262/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22262&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343427 Stats: 239 lines in 7 files changed: 238 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22262.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22262/head:pull/22262 PR: https://git.openjdk.org/jdk/pull/22262 From fyang at openjdk.org Wed Nov 20 01:21:16 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 20 Nov 2024 01:21:16 GMT Subject: RFR: 8343827: RISC-V: set AlignVector as false if applicable to enable SLP [v2] In-Reply-To: References: Message-ID: <6LOxlb57sJiE5OVXcBdNLocjLQpD3vauO3xl4c93nmg=.b8469082-0cc5-4f8c-8ae2-deb8988609c1@github.com> On Tue, 19 Nov 2024 16:01:04 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> SLP vectorization in C2 checks the data alignment optionally, if fast misaliged access is supported by CPU it will skip the alignment check in SLP, this is good for both C2 compile time and run time (as more loops can be potentially vectorized. And the performance of vector implementation is good enough, which was already verified by existing tests (array copy, crc32, ...)). >> On the other hand, we have some existing tests which verify that generated IRs should contain some specific Nodes, with the intrdocution of Compact Object Header, some tests related to SLP was observed failure which is due to the data offset change which is due to header change in the JEP, by enabling C2 SLP when fast misaliged access is supported, we should be able to resolve these issues. Although riscv support misaligned access optionally, started from RVA22 it's mandatory. >> >> Thanks! > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine code Marked as reviewed by fyang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21974#pullrequestreview-2447140023 From cjplummer at openjdk.org Wed Nov 20 05:44:18 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 20 Nov 2024 05:44:18 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v7] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: On Tue, 19 Nov 2024 18:30:37 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed spaces > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. Can you explain what the issue was? For the most part what I can tell is you moved a lot of code from MutexLocker to Mutex, but the reason isn't clear. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22171#issuecomment-2487500151 From cjplummer at openjdk.org Wed Nov 20 05:50:18 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 20 Nov 2024 05:50:18 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v7] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: On Tue, 19 Nov 2024 18:30:37 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed spaces src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Mutex.java line 58: > 56: > 57: f = type.getField("_owner"); > 58: ownerFieldOffset = f.getOffset(); Rather than repurpose `f` I could suggest declaring nameField and ownerField. Makes the code a bit easier to read. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Mutex.java line 61: > 59: mutex_array = type.getAddressField("_mutex_array"); > 60: maxNum = type.getCIntegerField("_num_mutex").getJInt(); > 61: empty line not needed. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Mutex.java line 76: > 74: public static int maxNum() { return maxNum; } > 75: > 76: empty lines not needed src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMLocksPrinter.java line 54: > 52: if (thread.getAddress().equals(addr)) { > 53: return thread.getThreadName(); > 54: } Instead of searching for the thread address in the list of threads, can't you just create a JavaThread using Threads.createJavaThreadWrapper(addr) and directly fetch the thread name from it? src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMLocksPrinter.java line 58: > 56: return "Unknown thread"; > 57: } > 58: public void printVMLocks() { Add newline before this line. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java line 85: > 83: > 84: VMLocksPrinter vmLocksPrinter = new VMLocksPrinter(out); > 85: vmLocksPrinter.printVMLocks(); It would be best to catch all exceptions here and continue on after a warning message. We do the same in the loop below as we iterate over each thread. This is a safety net in case some structures are currently in an inconsistent state. test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java line 32: > 30: /** > 31: * @test > 32: * @summary Test verifies that jstack --mixed print information about VM locks Suggestion: * @summary Test verifies that jstack --mixed prints information about VM locks test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java line 50: > 48: try { > 49: theApp = new LingeredAppWithLockInVM(); > 50: String classPath = System.getProperty("test.class.path"); Unused test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java line 51: > 49: theApp = new LingeredAppWithLockInVM(); > 50: String classPath = System.getProperty("test.class.path"); > 51: LingeredApp.startAppExactJvmOpts(theApp, Why use startAppExactJvmOpts and limit testing to just this one config (with vm.flagless)? Can't these be added arguments? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1849552939 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1849553124 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1849553513 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1849559366 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1849559568 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1849549464 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1849565537 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1849571429 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1849570238 From rehn at openjdk.org Wed Nov 20 06:28:15 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 20 Nov 2024 06:28:15 GMT Subject: RFR: 8344010: RISC-V: Zacas do not work with LW locking In-Reply-To: References: <9zxKdn73DHLKXicGNz8Wygje-qKJMlvy4sTcKz3che8=.ee30bec8-f557-4436-9e77-70d5a06e3590@github.com> Message-ID: On Tue, 19 Nov 2024 20:55:17 GMT, Hamlin Li wrote: >> Hi all, please consider. >> >> Light weight locking fails: >> - We need to add cas acquire. >> - Register _result_ may shadow _new_val_ (same register). >> (NOTE this second item can effect many other cases, unclear) >> >> As the code becomes much cleaner by calling amocas_d/w directly I removed the aliases. >> Which fixes the first issue with cas acquire. >> >> By using t0 instead of _result_ we fix the other issue. >> >> This is a short bugfix, there are so many dragons here that I do not want to address them while fixing the bug. >> There are also several performance optimizations we can do here, specially for LR/SC case. >> So I'll do a couple of more iterations of this code in seperate PR's. >> >> Testing a bunch of local cherry-picked tests which failed. >> I'll start tier1 over the weekend. >> >> Thanks, Robbin > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 3488: > >> 3486: } else { >> 3487: mv(t0, expected); >> 3488: atomic_cas(t0, new_val, addr, size, acquire, release); > > Not sure if I understand this correctly. > Could it be better to tell if `result` == `new_val`? If false, then we don't need the extra `mv`. The "mv()" check that for you, so an e.g. mv(a0, a0) will never emit an instruction. OT NOTE: If you are in an InCompressableRegion this will still not emit an instruction so your offsets may be wrong. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22149#discussion_r1849621841 From rehn at openjdk.org Wed Nov 20 06:28:16 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 20 Nov 2024 06:28:16 GMT Subject: RFR: 8344010: RISC-V: Zacas do not work with LW locking In-Reply-To: References: <9zxKdn73DHLKXicGNz8Wygje-qKJMlvy4sTcKz3che8=.ee30bec8-f557-4436-9e77-70d5a06e3590@github.com> Message-ID: On Wed, 20 Nov 2024 06:24:06 GMT, Robbin Ehn wrote: >> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 3488: >> >>> 3486: } else { >>> 3487: mv(t0, expected); >>> 3488: atomic_cas(t0, new_val, addr, size, acquire, release); >> >> Not sure if I understand this correctly. >> Could it be better to tell if `result` == `new_val`? If false, then we don't need the extra `mv`. > > The "mv()" check that for you, so an e.g. mv(a0, a0) will never emit an instruction. > > OT NOTE: > If you are in an InCompressableRegion this will still not emit an instruction so your offsets may be wrong. Oh, sorry I now see what you mean. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22149#discussion_r1849623426 From rehn at openjdk.org Wed Nov 20 06:33:19 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 20 Nov 2024 06:33:19 GMT Subject: RFR: 8344010: RISC-V: Zacas do not work with LW locking In-Reply-To: References: <9zxKdn73DHLKXicGNz8Wygje-qKJMlvy4sTcKz3che8=.ee30bec8-f557-4436-9e77-70d5a06e3590@github.com> Message-ID: On Tue, 19 Nov 2024 20:55:33 GMT, Hamlin Li wrote: > Nice catch and cleanup, looks much better! Just one minor comment. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22149#issuecomment-2487610039 From duke at openjdk.org Wed Nov 20 06:53:21 2024 From: duke at openjdk.org (Yuri Gaevsky) Date: Wed, 20 Nov 2024 06:53:21 GMT Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic In-Reply-To: References: Message-ID: On Wed, 7 Feb 2024 14:35:55 GMT, Yuri Gaevsky wrote: > Hello All, > > Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported. > > Thank you, > -Yuri Gaevsky > > **Correctness checks:** > hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4. . ------------- PR Comment: https://git.openjdk.org/jdk/pull/17750#issuecomment-2487637904 From aboldtch at openjdk.org Wed Nov 20 07:15:21 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 20 Nov 2024 07:15:21 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing In-Reply-To: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: <9Df-jZQYisR2XMuwGVI3tgDzMwOPAN8vA7Bfzhl8zFE=.b7d69d77-9234-4a2b-bd4d-5d23ebc4068c@github.com> On Tue, 19 Nov 2024 13:09:22 GMT, Fredrik Bredberg wrote: > @dcubed-ojdk is too busy, so I was asked to take over [https://github.com/openjdk/jdk/pull/18664](https://github.com/openjdk/jdk/pull/18664) and finish it. > > That old PR contains all the details and also got some review comments, which I have tried to address in this new PR. > > Tests run without failures on supported platforms. lgtm. ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22238#pullrequestreview-2447619286 From qpzhang at openjdk.org Wed Nov 20 07:56:31 2024 From: qpzhang at openjdk.org (Patrick Zhang) Date: Wed, 20 Nov 2024 07:56:31 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4] In-Reply-To: <6hpEaT7qf_Mo8eyeDiu6_UvBy0J4TBkdB2aETVt0Axw=.4e2dbd36-d14a-4e53-b6ea-88e60594a139@github.com> References: <1knXD7Wc8heH83BTJEguqmlTAa70oXDw_nWI0hBjAm0=.bcf88238-2b63-4d14-b3a3-94eabca69586@github.com> <77VcfKMeUXxKjoQ3zeEcBJfDQYhPRSt08OXMqg9rQDo=.de753f60-5568-4dec-9b86-2ba86acebfaa@github.com> <1w4y8kdPpONt2iyrqFdjmpDcqwVBoQfiOgK6J5cmFV4=.9cecfe26-6586-4a53-926c-4203b52260d8@github.com> <9H3PBcqWAZevaB5KU1_Lh5ptj1f365-iLiIyaBMnNyE=.ce6f80fb-4fe8-4cf4-b58e-456238637b1f@github.com> <6hpEaT7qf_Mo8eyeDiu6_UvBy0J4TBkdB2aETVt0Axw=.4e2dbd36-d14a-4e53-b6ea-88e60594a139@github.com> Message-ID: On Fri, 22 Mar 2024 15:30:35 GMT, Hamlin Li wrote: > > > Ah, it'll only be the redirect library that's compiled with -march=armv8-a+sve Forget that. > > > > > > But that raises an interesting question. What happens if you try to load a library compiled with `-march=armv8-a+sve` on a non-SVE system? Is the ELF flagged to require SVE so it will fail to load? I'm hoping this is the case -- if so, everything will work as it should in this PR, but I honestly don't know. (After spending like 10 years working with building, I still discover things I need to learn...). > > I think we can handle it, when a jdk built with sve support runs on a non-sve machine, the sve related code will not be executed with the protection of UseSVE vm flag which is detected at runtime startup. I think we should not have specified any `-march=Xxx` option here in `make/autoconf/flags-cflags.m4` under `AC_DEFUN([FLAGS_SETUP_CFLAGS_CPU_DEP]`. It generates conflicts when a user builds JDK with relevant flags in `--with-extra-cflags=-march=Xxx`. Moreover, above `-march=armv8-a+sve` can accidentally overwrite `-mcpu=Xxx` or `-mtune=Xxx` contents if a user specified in configure cmdline, because `-march` is of higher priority for a toolchain deciding what uarch/cost-model/instructions would be used. The configure sequence can be briefly described as below: > 1. FLAGS_PRE_TOOLCHAIN -> > FLAGS_SETUP_USER_SUPPLIED_FLAGS > AC_ARG_WITH(extra-cflags, [AS_HELP_STRING([--with-extra-cflags], [extra flags to be used when compiling jdk c-files])]) > (For example, we specify **--with-extra-cflags="-march=armv8.2a+fp16"**) > > 2. FLAGS_SETUP_FLAGS > -> FLAGS_SETUP_CFLAGS > -> FLAGS_SETUP_CFLAGS_CPU_DEP > CFLAGS="$CFLAGS **-march=armv8-a+sve"** The later one will modify/overwrite the former one that the user is really building for. @Hamlin-Li @magicus @theRealAph ------------- PR Comment: https://git.openjdk.org/jdk/pull/18294#issuecomment-2487793664 From amitkumar at openjdk.org Wed Nov 20 08:28:22 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 20 Nov 2024 08:28:22 GMT Subject: RFR: 8344381: [s390x] Test failures with error: Register type is not known [v3] In-Reply-To: References: Message-ID: <-hILhZPnxdQSoEkdsg8Zm_VKoiqz5H8GAKvRwI7Rlxk=.35769080-953e-47f3-baeb-51129530059b@github.com> On Tue, 19 Nov 2024 05:24:26 GMT, Amit Kumar wrote: >> Adds SaveLiveRegister portion for vector registers also. >> >> Depends on https://github.com/openjdk/jdk/pull/22190. Once that PR gets integrated, will rebase and mark it ready for review. > > Amit Kumar 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 v_test_failure_v0 > - additional changes > - suggestion from martin > - no more ignoring vector registers > > fix' OCA label ???? Thanks for reviews Lutz, Martin ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22197#issuecomment-2487865951 From amitkumar at openjdk.org Wed Nov 20 08:28:23 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 20 Nov 2024 08:28:23 GMT Subject: Integrated: 8344381: [s390x] Test failures with error: Register type is not known In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 10:17:12 GMT, Amit Kumar wrote: > Adds SaveLiveRegister portion for vector registers also. > > Depends on https://github.com/openjdk/jdk/pull/22190. Once that PR gets integrated, will rebase and mark it ready for review. This pull request has now been integrated. Changeset: 189fc8dd Author: Amit Kumar URL: https://git.openjdk.org/jdk/commit/189fc8ddeffb4dd595ccd8ad3ca53a0ed4cee91f Stats: 26 lines in 1 file changed: 18 ins; 0 del; 8 mod 8344381: [s390x] Test failures with error: Register type is not known Reviewed-by: mdoerr, lucy ------------- PR: https://git.openjdk.org/jdk/pull/22197 From jwaters at openjdk.org Wed Nov 20 08:42:09 2024 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 20 Nov 2024 08:42:09 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v3] In-Reply-To: References: Message-ID: <_0gxH1uRPsMvgG_p1zP0iuwvQ9FVNFtSpAvCeU0g8ws=.14ba0bc0-a81b-4bab-80b7-411e86d96e8b@github.com> > Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely Julian Waters 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 'openjdk:master' into hotspot - Revert sharedRuntime.cpp - Revert sharedRuntime_x86.cpp - 8342769 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21627/files - new: https://git.openjdk.org/jdk/pull/21627/files/12e82f68..fb171a43 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=01-02 Stats: 487892 lines in 5573 files changed: 189586 ins; 262181 del; 36125 mod Patch: https://git.openjdk.org/jdk/pull/21627.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21627/head:pull/21627 PR: https://git.openjdk.org/jdk/pull/21627 From qpzhang at openjdk.org Wed Nov 20 08:42:33 2024 From: qpzhang at openjdk.org (Patrick Zhang) Date: Wed, 20 Nov 2024 08:42:33 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: <1knXD7Wc8heH83BTJEguqmlTAa70oXDw_nWI0hBjAm0=.bcf88238-2b63-4d14-b3a3-94eabca69586@github.com> <77VcfKMeUXxKjoQ3zeEcBJfDQYhPRSt08OXMqg9rQDo=.de753f60-5568-4dec-9b86-2ba86acebfaa@github.com> <1w4y8kdPpONt2iyrqFdjmpDcqwVBoQfiOgK6J5cmFV4=.9cecfe26-6586-4a53-926c-4203b52260d8@github.com> <9H3PBcqWAZevaB5KU1_Lh5ptj1f365-iLiIyaBMnNyE=.ce6f80fb-4fe8-4cf4-b58e-456238637b1f@github.com> <6hpEaT7qf_Mo8eyeDiu6_UvBy0J4TBkdB2aETVt0Axw=.4e2dbd36-d14a-4e53-b6ea-88e60594a139@github.com> Message-ID: On Wed, 20 Nov 2024 07:53:45 GMT, Patrick Zhang wrote: > > > > Ah, it'll only be the redirect library that's compiled with -march=armv8-a+sve Forget that. > > > > > > > > > But that raises an interesting question. What happens if you try to load a library compiled with `-march=armv8-a+sve` on a non-SVE system? Is the ELF flagged to require SVE so it will fail to load? I'm hoping this is the case -- if so, everything will work as it should in this PR, but I honestly don't know. (After spending like 10 years working with building, I still discover things I need to learn...). > > > > > > I think we can handle it, when a jdk built with sve support runs on a non-sve machine, the sve related code will not be executed with the protection of UseSVE vm flag which is detected at runtime startup. > > I think we should not have specified any `-march=Xxx` option here in `make/autoconf/flags-cflags.m4` under `AC_DEFUN([FLAGS_SETUP_CFLAGS_CPU_DEP]`. It generates conflicts when a user builds JDK with relevant flags in `--with-extra-cflags=-march=Xxx`. Moreover, above `-march=armv8-a+sve` can accidentally overwrite things specified by `-mcpu=Xxx` or indirectly impact `-mtune=Xxx` if a user specified them in configure cmdline, `-march` is of higher priority than `-mcpu` for a toolchain deciding what isa/cost-model would be used. > > @Hamlin-Li @magicus @theRealAph Removed my previous incorrect comments with regards to the configure sequence on flags. SVE_CFLAGS is only used for sleef library building, so the impact would be limited. While the conflicting concern of `-march=armv8-a+sve` and other `-march=` or `-mcpu` from user inputs is still there. For example, what I captured is: Creating support/modules_libs/jdk.incubator.vector/libsleef.so from 3 file(s) cc1: warning: switch ?-mcpu=ampere1a? conflicts with ?-march=armv8-a+sve? switch A degradation overriding would happen according to https://community.arm.com/arm-community-blogs/b/tools-software-ides-blog/posts/compiler-flags-across-architectures-march-mtune-and-mcpu ------------- PR Comment: https://git.openjdk.org/jdk/pull/18294#issuecomment-2487899668 From mli at openjdk.org Wed Nov 20 08:52:27 2024 From: mli at openjdk.org (Hamlin Li) Date: Wed, 20 Nov 2024 08:52:27 GMT Subject: Integrated: 8343827: RISC-V: set AlignVector as false if applicable to enable SLP In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 11:40:46 GMT, Hamlin Li wrote: > Hi, > Can you help to review this patch? > > SLP vectorization in C2 checks the data alignment optionally, if fast misaliged access is supported by CPU it will skip the alignment check in SLP, this is good for both C2 compile time and run time (as more loops can be potentially vectorized. And the performance of vector implementation is good enough, which was already verified by existing tests (array copy, crc32, ...)). > On the other hand, we have some existing tests which verify that generated IRs should contain some specific Nodes, with the intrdocution of Compact Object Header, some tests related to SLP was observed failure which is due to the data offset change which is due to header change in the JEP, by enabling C2 SLP when fast misaliged access is supported, we should be able to resolve these issues. Although riscv support misaligned access optionally, started from RVA22 it's mandatory. > > Thanks! This pull request has now been integrated. Changeset: 587f2b4b Author: Hamlin Li URL: https://git.openjdk.org/jdk/commit/587f2b4b4dd73733a6ee247200371f8a8d0299c1 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod 8343827: RISC-V: set AlignVector as false if applicable to enable SLP Reviewed-by: fyang, luhenry ------------- PR: https://git.openjdk.org/jdk/pull/21974 From mli at openjdk.org Wed Nov 20 08:52:25 2024 From: mli at openjdk.org (Hamlin Li) Date: Wed, 20 Nov 2024 08:52:25 GMT Subject: RFR: 8343827: RISC-V: set AlignVector as false if applicable to enable SLP [v2] In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 16:01:04 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> >> SLP vectorization in C2 checks the data alignment optionally, if fast misaliged access is supported by CPU it will skip the alignment check in SLP, this is good for both C2 compile time and run time (as more loops can be potentially vectorized. And the performance of vector implementation is good enough, which was already verified by existing tests (array copy, crc32, ...)). >> On the other hand, we have some existing tests which verify that generated IRs should contain some specific Nodes, with the intrdocution of Compact Object Header, some tests related to SLP was observed failure which is due to the data offset change which is due to header change in the JEP, by enabling C2 SLP when fast misaliged access is supported, we should be able to resolve these issues. Although riscv support misaligned access optionally, started from RVA22 it's mandatory. >> >> Thanks! > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine code Thanks for your reviewing! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21974#issuecomment-2487919534 From jwaters at openjdk.org Wed Nov 20 08:52:45 2024 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 20 Nov 2024 08:52:45 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v3] In-Reply-To: <_0gxH1uRPsMvgG_p1zP0iuwvQ9FVNFtSpAvCeU0g8ws=.14ba0bc0-a81b-4bab-80b7-411e86d96e8b@github.com> References: <_0gxH1uRPsMvgG_p1zP0iuwvQ9FVNFtSpAvCeU0g8ws=.14ba0bc0-a81b-4bab-80b7-411e86d96e8b@github.com> Message-ID: On Wed, 20 Nov 2024 08:42:09 GMT, Julian Waters wrote: >> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely > > Julian Waters 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 'openjdk:master' into hotspot > - Revert sharedRuntime.cpp > - Revert sharedRuntime_x86.cpp > - 8342769 I've changed the check to instead define the constants when _M_ARM64 is defined. This is the cleanest approach I can come up with, and doesn't touch the workaround code in frem and drem either ------------- PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2487907476 From jwaters at openjdk.org Wed Nov 20 08:52:41 2024 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 20 Nov 2024 08:52:41 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v4] In-Reply-To: References: Message-ID: > Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely Julian Waters has updated the pull request incrementally with three additional commits since the last revision: - size_t brace initialization instead of unsigned literals in test_os_windows.cpp - size_t brace initialization instead of unsigned literal in test_os.cpp - Check for _M_ARM64 instead of _WIN64 in sharedRuntime.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21627/files - new: https://git.openjdk.org/jdk/pull/21627/files/fb171a43..47810433 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=02-03 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21627.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21627/head:pull/21627 PR: https://git.openjdk.org/jdk/pull/21627 From jbechberger at openjdk.org Wed Nov 20 09:01:51 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 20 Nov 2024 09:01:51 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v29] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 155 commits: - Merge remote-tracking branch 'origin' into parttimenerd_jfr_cpu_time_sampler4 - Fix zero build - Simplify #ifdefs to fix minimal and zero builds - Merge remote-tracking branch 'origin' into parttimenerd_jfr_cpu_time_sampler4 - Compute actual sampling period via si_overrun - Making queue processing only stoppable in debug builds - Obtain minimal period via the CONFIG_HZ parameter of the kernel - Improve Throttling test case - Make parsing rates safer - Fix ActiveSetting event for CPUTimeSamples - ... and 145 more: https://git.openjdk.org/jdk/compare/587f2b4b...af59d3fb ------------- Changes: https://git.openjdk.org/jdk/pull/20752/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=28 Stats: 2622 lines in 52 files changed: 2417 ins; 176 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From aph at openjdk.org Wed Nov 20 09:07:17 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 20 Nov 2024 09:07:17 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v4] In-Reply-To: References: Message-ID: <59WqblNEW-wzd2GO-Onj-jOA5g9syFLg_ovhUFUXuoo=.2ec4d90e-c767-4527-9c3f-73953cfb915d@github.com> On Wed, 20 Nov 2024 08:52:41 GMT, Julian Waters wrote: >> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely > > Julian Waters has updated the pull request incrementally with three additional commits since the last revision: > > - size_t brace initialization instead of unsigned literals in test_os_windows.cpp > - size_t brace initialization instead of unsigned literal in test_os.cpp > - Check for _M_ARM64 instead of _WIN64 in sharedRuntime.cpp Wouldn't it be far easier to handle `fmod` ourselves in the AArch64b back end? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2487957083 From jwaters at openjdk.org Wed Nov 20 09:18:16 2024 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 20 Nov 2024 09:18:16 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v4] In-Reply-To: <59WqblNEW-wzd2GO-Onj-jOA5g9syFLg_ovhUFUXuoo=.2ec4d90e-c767-4527-9c3f-73953cfb915d@github.com> References: <59WqblNEW-wzd2GO-Onj-jOA5g9syFLg_ovhUFUXuoo=.2ec4d90e-c767-4527-9c3f-73953cfb915d@github.com> Message-ID: On Wed, 20 Nov 2024 09:04:49 GMT, Andrew Haley wrote: > Wouldn't it be far easier to handle `fmod` ourselves in the AArch64b back end? You mean like how x86 has its own custom fmod implementation in the assembler? That does sound pretty good to me, then we could get rid of this workaround entirely, but I don't know how to implement this on ARM64 ------------- PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2487984335 From mli at openjdk.org Wed Nov 20 09:56:21 2024 From: mli at openjdk.org (Hamlin Li) Date: Wed, 20 Nov 2024 09:56:21 GMT Subject: RFR: 8344010: RISC-V: Zacas do not work with LW locking In-Reply-To: <9zxKdn73DHLKXicGNz8Wygje-qKJMlvy4sTcKz3che8=.ee30bec8-f557-4436-9e77-70d5a06e3590@github.com> References: <9zxKdn73DHLKXicGNz8Wygje-qKJMlvy4sTcKz3che8=.ee30bec8-f557-4436-9e77-70d5a06e3590@github.com> Message-ID: On Fri, 15 Nov 2024 13:01:37 GMT, Robbin Ehn wrote: > Hi all, please consider. > > Light weight locking fails: > - We need to add cas acquire. > - Register _result_ may shadow _new_val_ (same register). > (NOTE this second item can effect many other cases, unclear) > > As the code becomes much cleaner by calling amocas_d/w directly I removed the aliases. > Which fixes the first issue with cas acquire. > > By using t0 instead of _result_ we fix the other issue. > > This is a short bugfix, there are so many dragons here that I do not want to address them while fixing the bug. > There are also several performance optimizations we can do here, specially for LR/SC case. > So I'll do a couple of more iterations of this code in seperate PR's. > > Testing a bunch of local cherry-picked tests which failed. > I'll start tier1 over the weekend. > > Thanks, Robbin Thanks, current fix looks good! ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22149#pullrequestreview-2448110412 From mli at openjdk.org Wed Nov 20 09:56:22 2024 From: mli at openjdk.org (Hamlin Li) Date: Wed, 20 Nov 2024 09:56:22 GMT Subject: RFR: 8344010: RISC-V: Zacas do not work with LW locking In-Reply-To: References: <9zxKdn73DHLKXicGNz8Wygje-qKJMlvy4sTcKz3che8=.ee30bec8-f557-4436-9e77-70d5a06e3590@github.com> Message-ID: On Wed, 20 Nov 2024 06:25:27 GMT, Robbin Ehn wrote: >> The "mv()" check that for you, so an e.g. mv(a0, a0) will never emit an instruction. >> >> OT NOTE: >> If you are in an InCompressableRegion this will still not emit an instruction so your offsets may be wrong. > > Oh, sorry I now see what you mean. > As the mv is just register rename it make little different and I want to update this code to sort more things out, adding yet another if-statemet just comes in the way. > > I want to clean it up before we micro optimize it. I see, let's do this optimization later after the fixing of these bugs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22149#discussion_r1849987269 From azafari at openjdk.org Wed Nov 20 10:00:28 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 20 Nov 2024 10:00:28 GMT Subject: RFR: 8328944: NMT reports "unknown" memory [v2] In-Reply-To: <6Up1fGCFJl2HAUGl6IBKEDRodItQLn5TigHJEdzZpbU=.5f5ae17c-edc4-4dd8-ae09-8e8ae8567354@github.com> References: <6Up1fGCFJl2HAUGl6IBKEDRodItQLn5TigHJEdzZpbU=.5f5ae17c-edc4-4dd8-ae09-8e8ae8567354@github.com> Message-ID: On Tue, 19 Nov 2024 22:01:13 GMT, Gerard Ziemski wrote: >> We use `mtNone` value in several functions default parameters, which may show up in NMT reports. >> >> We address this, by avoiding using `mtNone`. >> >> Eventually the goal would be to eliminate using `mtNone` whenever possible. >> TODO: update copyrights. >> >> Testing: undergoing MARCH5 tier1-5 ... > > Gerard Ziemski 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: > > - avoid using mtNone > - Merge remote-tracking branch 'upstream/master' into JDK-8328944 > - revert, we will re-do with a smaller change > - remove more mtNone > - remove API that allows to change the mem_tag for virtual memory, feedback > - do not allow default parameter for mtNone src/hotspot/os/bsd/gc/z/zPhysicalMemoryBacking_bsd.cpp line 1: > 1: /* Copyright year to be updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1849994608 From azafari at openjdk.org Wed Nov 20 10:06:25 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 20 Nov 2024 10:06:25 GMT Subject: RFR: 8328944: NMT reports "unknown" memory [v2] In-Reply-To: <6Up1fGCFJl2HAUGl6IBKEDRodItQLn5TigHJEdzZpbU=.5f5ae17c-edc4-4dd8-ae09-8e8ae8567354@github.com> References: <6Up1fGCFJl2HAUGl6IBKEDRodItQLn5TigHJEdzZpbU=.5f5ae17c-edc4-4dd8-ae09-8e8ae8567354@github.com> Message-ID: On Tue, 19 Nov 2024 22:01:13 GMT, Gerard Ziemski wrote: >> We use `mtNone` value in several functions default parameters, which may show up in NMT reports. >> >> We address this, by avoiding using `mtNone`. >> >> Eventually the goal would be to eliminate using `mtNone` whenever possible. >> TODO: update copyrights. >> >> Testing: undergoing MARCH5 tier1-5 ... > > Gerard Ziemski 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: > > - avoid using mtNone > - Merge remote-tracking branch 'upstream/master' into JDK-8328944 > - revert, we will re-do with a smaller change > - remove more mtNone > - remove API that allows to change the mem_tag for virtual memory, feedback > - do not allow default parameter for mtNone src/hotspot/share/memory/virtualspace.hpp line 65: > 63: > 64: void initialize(size_t size, size_t alignment, size_t page_size, > 65: char* requested_address, bool executable, MemTag mem_tag = mtNone); When `mtNone` is default, it is still possible to introduce/create regions of Unknown types. The MemTag arg should be mandatory. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1850003383 From azafari at openjdk.org Wed Nov 20 10:06:26 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 20 Nov 2024 10:06:26 GMT Subject: RFR: 8328944: NMT reports "unknown" memory [v2] In-Reply-To: References: Message-ID: On Sat, 16 Nov 2024 02:52:18 GMT, Gerard Ziemski wrote: >> src/hotspot/share/memory/virtualspace.hpp line 67: >> >>> 65: >>> 66: void reserve(size_t size, size_t alignment, size_t page_size, >>> 67: char* requested_address, bool executable, MemTag mem_tag); >> >> Why do the instance methods get MemTag? Why is MemTag not stored as a (const) attribute of ReservedSpace? >> >> But then, we would have double accounting - we'd store the tag both in NMT and in ReservedSpace instances. If we change them post-reservation, we would need to change both. Sigh. >> >> So we pass in MemTag just for the ReservedSpace to pass it into os::reserve_memory. Seeing how often ReservedSpace is used in situations where the tag is not clear at reservation time, I wonder whether we are not better off letting the user of ReservedSpace register the NMT tag post reservation like they do today. > > I like the simplicity of not having to deal with changing the tag afterwards personally. Does anyone else have an opinion here? We need to keep a member MemTag for ReservedSpace. There are cases in the code where a new copy of a ReservedSpace is to be created. Then, we need to know the original MemTag and pass it again down to the other functions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1850001690 From fbredberg at openjdk.org Wed Nov 20 10:08:24 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 20 Nov 2024 10:08:24 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing In-Reply-To: References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: On Tue, 19 Nov 2024 17:37:58 GMT, Coleen Phillimore wrote: >> test/hotspot/jtreg/TEST.groups line 604: >> >>> 602: -runtime/CompressedOops/UseCompressedOops.java \ >>> 603: -runtime/InvocationTests \ >>> 604: -runtime/Monitor/StressWrapper_TestRecursiveLocking_36M.java \ >> >> Does runtime/Monitor/TestRecursiveLocking.java need to be added in here too? > > OH I see there's a minus sign here too for tier2, so I assume it'll run in tier3? But the 5 second one will run in tier2. Yes. Taken from Dan's original PR: _"The default version of the test is NOT run in Tier1; it is run in Tier2 intentionally since this is a stress test."_ and _"The StressWrapper_TestRecursiveLocking_36M.java version of the test is run in Tier3 and is NOT run in Tier1 or Tier2."_ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850006801 From shade at openjdk.org Wed Nov 20 10:37:35 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 20 Nov 2024 10:37:35 GMT Subject: RFR: 8343541: C1: Plain memory accesses are emitted with membars with +AlwaysAtomicAccesses [v2] In-Reply-To: <9sZDi_ahHbkCWc7QRukVh7m8bvWbkRUvbtbG7FgkSc4=.714aac97-ace8-4357-846f-ed2e2b1f176d@github.com> References: <9sZDi_ahHbkCWc7QRukVh7m8bvWbkRUvbtbG7FgkSc4=.714aac97-ace8-4357-846f-ed2e2b1f176d@github.com> Message-ID: On Mon, 18 Nov 2024 09:30:54 GMT, Xiaolong Peng wrote: >> C1 and C2 has different implementations for `+AlwaysAtomicAccesses`, [C2 impl](https://github.com/openjdk/jdk/blob/4a7ce1d7c1bd4b751063b98cf8bedcd27055760b/src/hotspot/share/gc/shared/c2/barrierSetC2.cpp#L410) only guarantees atomicity hence no membars are emitted for plain memory access, but C1 treats it same as volatile access hence it emits membars. The change removes the unnecessary membars in C1 for `+AlwaysAtomicAccesses`. >> >> The test have been verified by very simple JMH benchmarks to measure the latency of reading/writing long/volatile long variable 10000 times, and run with VM option `-XX:TieredStopAtLevel=3 -XX:+UnlockExperimentalVMOptions -XX:+AlwaysAtomicAccesses`: >> >> Before the fix: >> >> Benchmark Mode Cnt Score Error Units >> AlwaysAtomicAccesses.testReadLong avgt 5 58711.131 ? 716.940 ns/op >> AlwaysAtomicAccesses.testReadVolatileLong avgt 5 59014.735 ? 675.354 ns/op >> AlwaysAtomicAccesses.testWriteLong avgt 5 115817.978 ? 302.089 ns/op >> AlwaysAtomicAccesses.testWriteVolatileLong avgt 5 116317.835 ? 1451.365 ns/op >> >> >> After the fix: >> >> Benchmark Mode Cnt Score Error Units >> AlwaysAtomicAccesses.testReadLong avgt 5 49651.527 ? 159.948 ns/op >> AlwaysAtomicAccesses.testReadVolatileLong avgt 5 58668.844 ? 316.029 ns/op >> AlwaysAtomicAccesses.testWriteLong avgt 5 23008.361 ? 10.947 ns/op >> AlwaysAtomicAccesses.testWriteVolatileLong avgt 5 116440.017 ? 1240.832 ns/op > > Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision: > > renaming Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22191#issuecomment-2488203661 From xpeng at openjdk.org Wed Nov 20 10:37:35 2024 From: xpeng at openjdk.org (Xiaolong Peng) Date: Wed, 20 Nov 2024 10:37:35 GMT Subject: Integrated: 8343541: C1: Plain memory accesses are emitted with membars with +AlwaysAtomicAccesses In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 07:27:03 GMT, Xiaolong Peng wrote: > C1 and C2 has different implementations for `+AlwaysAtomicAccesses`, [C2 impl](https://github.com/openjdk/jdk/blob/4a7ce1d7c1bd4b751063b98cf8bedcd27055760b/src/hotspot/share/gc/shared/c2/barrierSetC2.cpp#L410) only guarantees atomicity hence no membars are emitted for plain memory access, but C1 treats it same as volatile access hence it emits membars. The change removes the unnecessary membars in C1 for `+AlwaysAtomicAccesses`. > > The test have been verified by very simple JMH benchmarks to measure the latency of reading/writing long/volatile long variable 10000 times, and run with VM option `-XX:TieredStopAtLevel=3 -XX:+UnlockExperimentalVMOptions -XX:+AlwaysAtomicAccesses`: > > Before the fix: > > Benchmark Mode Cnt Score Error Units > AlwaysAtomicAccesses.testReadLong avgt 5 58711.131 ? 716.940 ns/op > AlwaysAtomicAccesses.testReadVolatileLong avgt 5 59014.735 ? 675.354 ns/op > AlwaysAtomicAccesses.testWriteLong avgt 5 115817.978 ? 302.089 ns/op > AlwaysAtomicAccesses.testWriteVolatileLong avgt 5 116317.835 ? 1451.365 ns/op > > > After the fix: > > Benchmark Mode Cnt Score Error Units > AlwaysAtomicAccesses.testReadLong avgt 5 49651.527 ? 159.948 ns/op > AlwaysAtomicAccesses.testReadVolatileLong avgt 5 58668.844 ? 316.029 ns/op > AlwaysAtomicAccesses.testWriteLong avgt 5 23008.361 ? 10.947 ns/op > AlwaysAtomicAccesses.testWriteVolatileLong avgt 5 116440.017 ? 1240.832 ns/op This pull request has now been integrated. Changeset: afee7405 Author: Xiaolong Peng Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/afee7405bd13cbe1cb829dd150a9de7e6faf49ae Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod 8343541: C1: Plain memory accesses are emitted with membars with +AlwaysAtomicAccesses Reviewed-by: shade, vlivanov ------------- PR: https://git.openjdk.org/jdk/pull/22191 From aph at openjdk.org Wed Nov 20 10:59:20 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 20 Nov 2024 10:59:20 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v4] In-Reply-To: References: <59WqblNEW-wzd2GO-Onj-jOA5g9syFLg_ovhUFUXuoo=.2ec4d90e-c767-4527-9c3f-73953cfb915d@github.com> Message-ID: On Wed, 20 Nov 2024 09:16:02 GMT, Julian Waters wrote: > > Wouldn't it be far easier to handle `fmod` ourselves in the AArch64b back end? > > You mean like how x86 has its own custom fmod implementation in the assembler? That does sound pretty good to me, then we could get rid of this workaround entirely, but I don't know how to implement this on ARM64 Oh, OK. I'll have a look. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2488262588 From azafari at openjdk.org Wed Nov 20 11:35:27 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 20 Nov 2024 11:35:27 GMT Subject: RFR: 8328944: NMT reports "unknown" memory [v2] In-Reply-To: <6Up1fGCFJl2HAUGl6IBKEDRodItQLn5TigHJEdzZpbU=.5f5ae17c-edc4-4dd8-ae09-8e8ae8567354@github.com> References: <6Up1fGCFJl2HAUGl6IBKEDRodItQLn5TigHJEdzZpbU=.5f5ae17c-edc4-4dd8-ae09-8e8ae8567354@github.com> Message-ID: On Tue, 19 Nov 2024 22:01:13 GMT, Gerard Ziemski wrote: >> We use `mtNone` value in several functions default parameters, which may show up in NMT reports. >> >> We address this, by avoiding using `mtNone`. >> >> Eventually the goal would be to eliminate using `mtNone` whenever possible. >> TODO: update copyrights. >> >> Testing: undergoing MARCH5 tier1-5 ... > > Gerard Ziemski 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: > > - avoid using mtNone > - Merge remote-tracking branch 'upstream/master' into JDK-8328944 > - revert, we will re-do with a smaller change > - remove more mtNone > - remove API that allows to change the mem_tag for virtual memory, feedback > - do not allow default parameter for mtNone Thanks for taking this issue. I add my points here: 1) The `ReservedSpace` objects in these files have to have extra MemTag (`mtTest`) parameter: - test_freeRegionList.cpp - test_virtualspace.cpp - test_virtualMemoryTracker.cpp 2) The `mtNone` as default value for the parameter should be removed from the following functions, otherwise Unknown memory types can still be reported: Source root ? src/hotspot/os/windows/os_windows.cpp: 3239: static char* map_or_reserve_memory_aligned(size_t size, size_t alignment, int file_desc, MemTag mem_tag = mtNone) { 3239 assert(is_aligned(alignment, os::vm_allocation_granularity()), 3240 assert(is_aligned(alignment, os::vm_allocation_granularity()), Source root ? src/hotspot/share/cds/filemap.cpp: 1773 char *addr, size_t bytes, bool read_only, 1774: bool allow_exec, MemTag mem_tag = mtNone) { 1775 char* mem = os::map_memory(fd, file_name, file_offset, addr, bytes, Source root ? src/hotspot/share/memory/virtualspace.hpp: 63 void initialize(size_t size, size_t alignment, size_t page_size, 64 void initialize(size_t size, size_t alignment, size_t page_size, 65: char* requested_address, bool executable, MemTag mem_tag = mtNone); 65 66 Source root ? src/hotspot/share/nmt/memReporter.hpp: 110 void print_total(size_t reserved, size_t committed, size_t peak = 0) const; 111: void print_malloc(const MemoryCounter* c, MemTag mem_tag = mtNone) const; 112 void print_virtual_memory(size_t reserved, size_t committed, size_t peak) const; Source root ? src/hotspot/share/nmt/memTracker.hpp: 123 static inline void record_virtual_memory_reserve(void* addr, size_t size, const NativeCallStack& stack, 124: MemTag mem_tag = mtNone) { 125 assert_post_init(); 149 static inline void record_virtual_memory_reserve_and_commit(void* addr, size_t size, 150: const NativeCallStack& stack, MemTag mem_tag = mtNone) { Source root ? src/hotspot/share/nmt/virtualMemoryTracker.hpp: 299 ReservedMemoryRegion(address base, size_t size, const NativeCallStack& stack, 300: MemTag mem_tag = mtNone) : 383: static bool add_reserved_region (address base_addr, size_t size, const NativeCallStack& stack, MemTag mem_tag = mtNone); 384 Source root ? src/hotspot/share/runtime/os.hpp: 453: static char* reserve_memory(size_t bytes, bool executable = false, MemTag mem_tag = mtNone); 460: static char* attempt_reserve_memory_at(char* addr, size_t bytes, bool executable = false, MemTag mem_tag = mtNone); 512: static char* map_memory_to_file(size_t size, int fd, MemTag mem_tag = mtNone); 513: static char* map_memory_to_file_aligned(size_t size, size_t alignment, int fd, MemTag mem_tag = mtNone); 515: static char* attempt_map_memory_to_file_at(char* base, size_t size, int fd, MemTag mem_tag = mtNone); 519 static char* map_memory(int fd, const char* file_name, size_t file_offset, char *addr, size_t bytes, bool read_only = false, 520 char *addr, size_t bytes, bool read_only = false, 521: bool allow_exec = false, MemTag mem_tag = mtNone); 3) In virtualspace.cpp, the `result` in these functions has `mtNone` tag while the parent may have another tag: ReservedSpace ReservedSpace::first_part(size_t partition_size, size_t alignment) { assert(partition_size <= size(), "partition failed"); ReservedSpace result(base(), partition_size, alignment, page_size(), special(), executable()); return result; } ReservedSpace ReservedSpace::last_part(size_t partition_size, size_t alignment) { assert(partition_size <= size(), "partition failed"); ReservedSpace result(base() + partition_size, size() - partition_size, alignment, page_size(), special(), executable()); return result; } ReservedSpace ReservedSpace::partition(size_t offset, size_t partition_size, size_t alignment) { assert(offset + partition_size <= size(), "partition failed"); ReservedSpace result(base() + offset, partition_size, alignment, page_size(), special(), executable()); return result; } 4) In virtualspace.cpp, the `space` has `mtNone` tag at this function: ReservedSpace ReservedSpace::space_for_range(char* base, size_t size, size_t alignment, size_t page_size, bool special, bool executable) { assert(is_aligned(base, os::vm_allocation_granularity()), "Unaligned base"); assert(is_aligned(size, os::vm_page_size()), "Unaligned size"); assert(os::page_sizes().contains(page_size), "Invalid pagesize"); ReservedSpace space; space.initialize_members(base, size, alignment, page_size, special, executable); return space; } ------------- PR Review: https://git.openjdk.org/jdk/pull/21843#pullrequestreview-2448359154 From dholmes at openjdk.org Wed Nov 20 11:38:48 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Nov 2024 11:38:48 GMT Subject: RFR: 8344621: ProblemList runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java Message-ID: Please review Thanks ------------- Commit messages: - 8344621: ProblemList runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java Changes: https://git.openjdk.org/jdk/pull/22273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22273&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344621 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22273/head:pull/22273 PR: https://git.openjdk.org/jdk/pull/22273 From rehn at openjdk.org Wed Nov 20 11:41:16 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 20 Nov 2024 11:41:16 GMT Subject: RFR: 8344010: RISC-V: Zacas do not work with LW locking In-Reply-To: References: <9zxKdn73DHLKXicGNz8Wygje-qKJMlvy4sTcKz3che8=.ee30bec8-f557-4436-9e77-70d5a06e3590@github.com> Message-ID: On Wed, 20 Nov 2024 09:53:51 GMT, Hamlin Li wrote: > Thanks, current fix looks good! Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22149#issuecomment-2488352396 From rehn at openjdk.org Wed Nov 20 11:41:17 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 20 Nov 2024 11:41:17 GMT Subject: RFR: 8344010: RISC-V: Zacas do not work with LW locking In-Reply-To: References: <9zxKdn73DHLKXicGNz8Wygje-qKJMlvy4sTcKz3che8=.ee30bec8-f557-4436-9e77-70d5a06e3590@github.com> Message-ID: On Wed, 20 Nov 2024 09:53:29 GMT, Hamlin Li wrote: >> Oh, sorry I now see what you mean. >> As the mv is just register rename it make little different and I want to update this code to sort more things out, adding yet another if-statemet just comes in the way. >> >> I want to clean it up before we micro optimize it. > > I see, let's do this optimization later after the fixing of these bugs. Great, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22149#discussion_r1850162698 From jpai at openjdk.org Wed Nov 20 11:48:16 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 20 Nov 2024 11:48:16 GMT Subject: RFR: 8344621: ProblemList runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java In-Reply-To: References: Message-ID: <6NGBEm9o0tLCyL-hI5GGQqZlhEf4XTtg2P89esvxsz8=.66acdd0b-ca7c-439c-9374-360cb7958595@github.com> On Wed, 20 Nov 2024 11:31:15 GMT, David Holmes wrote: > Please review > > Thanks This looks good and trivial to me and should address the failures we are seeing the CI. There are 10 test definitions in that file and all are covered here (0 through 9). ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22273#pullrequestreview-2448395698 From dholmes at openjdk.org Wed Nov 20 11:55:23 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Nov 2024 11:55:23 GMT Subject: RFR: 8344621: ProblemList runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java In-Reply-To: <6NGBEm9o0tLCyL-hI5GGQqZlhEf4XTtg2P89esvxsz8=.66acdd0b-ca7c-439c-9374-360cb7958595@github.com> References: <6NGBEm9o0tLCyL-hI5GGQqZlhEf4XTtg2P89esvxsz8=.66acdd0b-ca7c-439c-9374-360cb7958595@github.com> Message-ID: On Wed, 20 Nov 2024 11:45:45 GMT, Jaikiran Pai wrote: >> Please review >> >> Thanks > > This looks good and trivial to me and should address the failures we are seeing the CI. There are 10 test definitions in that file and all are covered here (0 through 9). Thanks @jaikiran ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22273#issuecomment-2488380280 From dholmes at openjdk.org Wed Nov 20 11:55:23 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Nov 2024 11:55:23 GMT Subject: Integrated: 8344621: ProblemList runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 11:31:15 GMT, David Holmes wrote: > Please review > > Thanks This pull request has now been integrated. Changeset: e2f8f1ad Author: David Holmes URL: https://git.openjdk.org/jdk/commit/e2f8f1aded319034a79fe78af7e011e83df75d62 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod 8344621: ProblemList runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/22273 From rehn at openjdk.org Wed Nov 20 12:08:20 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 20 Nov 2024 12:08:20 GMT Subject: Integrated: 8344010: RISC-V: Zacas do not work with LW locking In-Reply-To: <9zxKdn73DHLKXicGNz8Wygje-qKJMlvy4sTcKz3che8=.ee30bec8-f557-4436-9e77-70d5a06e3590@github.com> References: <9zxKdn73DHLKXicGNz8Wygje-qKJMlvy4sTcKz3che8=.ee30bec8-f557-4436-9e77-70d5a06e3590@github.com> Message-ID: <36wBjVL5iq38rCh-Uh6wQzi_kBzokddwXr-K-m8ydmk=.11da7135-ea94-4ff1-8d95-e54b93123a17@github.com> On Fri, 15 Nov 2024 13:01:37 GMT, Robbin Ehn wrote: > Hi all, please consider. > > Light weight locking fails: > - We need to add cas acquire. > - Register _result_ may shadow _new_val_ (same register). > (NOTE this second item can effect many other cases, unclear) > > As the code becomes much cleaner by calling amocas_d/w directly I removed the aliases. > Which fixes the first issue with cas acquire. > > By using t0 instead of _result_ we fix the other issue. > > This is a short bugfix, there are so many dragons here that I do not want to address them while fixing the bug. > There are also several performance optimizations we can do here, specially for LR/SC case. > So I'll do a couple of more iterations of this code in seperate PR's. > > Testing a bunch of local cherry-picked tests which failed. > I'll start tier1 over the weekend. > > Thanks, Robbin This pull request has now been integrated. Changeset: ea7e722c Author: Robbin Ehn URL: https://git.openjdk.org/jdk/commit/ea7e722ca04752f0b58bf98e0a1907c015644fb5 Stats: 104 lines in 2 files changed: 17 ins; 79 del; 8 mod 8344010: RISC-V: Zacas do not work with LW locking Reviewed-by: fyang, mli ------------- PR: https://git.openjdk.org/jdk/pull/22149 From aph at openjdk.org Wed Nov 20 12:20:18 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 20 Nov 2024 12:20:18 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v4] In-Reply-To: References: <59WqblNEW-wzd2GO-Onj-jOA5g9syFLg_ovhUFUXuoo=.2ec4d90e-c767-4527-9c3f-73953cfb915d@github.com> Message-ID: <74ZhlOx7e3sojf0pEeMlRMtFdIJw2zpEQUcUX1dZ5M8=.ed56ea4c-41b0-4f16-8a5d-1f5f4ff0562f@github.com> On Wed, 20 Nov 2024 10:56:29 GMT, Andrew Haley wrote: > > > Wouldn't it be far easier to handle `fmod` ourselves in the AArch64b back end? > > > > > > You mean like how x86 has its own custom fmod implementation in the assembler? That does sound pretty good to me, then we could get rid of this workaround entirely, but I don't know how to implement this on ARM64 > > Oh, OK. I'll have a look. I had a look at SharedRuntime::fmod_winx64. I'm sure it's fine for AArch64. Just put it in os_windows. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2488434650 From aph at openjdk.org Wed Nov 20 12:20:19 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 20 Nov 2024 12:20:19 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v4] In-Reply-To: References: <9C3_nSzX9UY6959Q1mpv1JpE7MMQ8l9JvRWUWSOuRQY=.e8928e43-8664-4de1-b240-3dca1f4ab4af@github.com> <31Dtdw2Xv9w5M6KbSN4lkHhpflbU3Nw123ZincFNHuk=.0c68c7e0-797b-4185-b59b-de2a49d29bd9@github.com> Message-ID: On Tue, 19 Nov 2024 05:26:29 GMT, Julian Waters wrote: >> @TheShermanTanker - this workaround is still needed on Windows AArch64. I haved filed https://developercommunity.visualstudio.com/t/fmod-incorrectly-returns-NaN-on-certain-/10793176 to track a fix for the underlying fmod bug. > > I'm astounded by how this happy accident looped all the way back around to being needed for ARM64, truly one of the funniest coincidences of all time > I don't think this workaround was intended for ARM64 in the first place, it explicitly mentions that it was written for x64, and the ifdef mess that resulted in this bug ended up bringing it over to ARM64 So what? I'm sure it'll be fine on AArch64. Just use it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1850217070 From coleenp at openjdk.org Wed Nov 20 12:25:20 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 20 Nov 2024 12:25:20 GMT Subject: RFR: 8344579: Clean up forward declarations and includes In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 21:42:07 GMT, Coleen Phillimore wrote: > I was looking through the sources for something and found these forward declarations that should be removed. Please review this trivial change. > > Sanity tested with tier1. Will also verify GHA pass. Thanks for the review Stefan. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22258#issuecomment-2488443523 From coleenp at openjdk.org Wed Nov 20 12:25:21 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 20 Nov 2024 12:25:21 GMT Subject: Integrated: 8344579: Clean up forward declarations and includes In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 21:42:07 GMT, Coleen Phillimore wrote: > I was looking through the sources for something and found these forward declarations that should be removed. Please review this trivial change. > > Sanity tested with tier1. Will also verify GHA pass. This pull request has now been integrated. Changeset: 7bb4474d Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/7bb4474d81a55028de5434f445747c56a8dc333c Stats: 8 lines in 4 files changed: 0 ins; 8 del; 0 mod 8344579: Clean up forward declarations and includes Reviewed-by: stefank ------------- PR: https://git.openjdk.org/jdk/pull/22258 From fbredberg at openjdk.org Wed Nov 20 12:49:31 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 20 Nov 2024 12:49:31 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing In-Reply-To: References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: <8nx0jA7Q46h8zeXHiN-lnNC6L1Btd7eNAZ7P4QTjNMw=.f1b9c58f-602c-49a2-b6f9-a46bbf6c1163@github.com> On Tue, 19 Nov 2024 16:49:22 GMT, Roman Kennke wrote: >> @dcubed-ojdk is too busy, so I was asked to take over [https://github.com/openjdk/jdk/pull/18664](https://github.com/openjdk/jdk/pull/18664) and finish it. >> >> That old PR contains all the details and also got some review comments, which I have tried to address in this new PR. >> >> Tests run without failures on supported platforms. > > I haven't looked at all the context, yet. But have you checked test/hotspot/jtreg/runtime/locking/TestRecursiveMonitorChurn.java ? Maybe one can subsume the other? @rkennke > I haven't looked at all the context, yet. But have you checked test/hotspot/jtreg/runtime/locking/TestRecursiveMonitorChurn.java ? Maybe one can subsume the other? I wasn't aware of `TestRecursiveMonitorChurn.java`. Maybe it's a good idea to let one test subsume the other. I'll discuss it with the team, but I think that will be handled in a separate PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22238#issuecomment-2488494871 From coleenp at openjdk.org Wed Nov 20 13:20:18 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 20 Nov 2024 13:20:18 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing In-Reply-To: References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: On Tue, 19 Nov 2024 20:47:43 GMT, Daniel D. Daugherty wrote: >> @dcubed-ojdk is too busy, so I was asked to take over [https://github.com/openjdk/jdk/pull/18664](https://github.com/openjdk/jdk/pull/18664) and finish it. >> >> That old PR contains all the details and also got some review comments, which I have tried to address in this new PR. >> >> Tests run without failures on supported platforms. > > The configurability was intentional so that specific modes could be exercised independently. Also adding additional modes in the future is/was planned. I think having the separate modes would be useful if you're debugging failures but as a normal test run, doesn't add anything except more runs. But I'll withdraw my suggestion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850300764 From coleenp at openjdk.org Wed Nov 20 13:23:21 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 20 Nov 2024 13:23:21 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing In-Reply-To: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: On Tue, 19 Nov 2024 13:09:22 GMT, Fredrik Bredberg wrote: > @dcubed-ojdk is too busy, so I was asked to take over [https://github.com/openjdk/jdk/pull/18664](https://github.com/openjdk/jdk/pull/18664) and finish it. > > That old PR contains all the details and also got some review comments, which I have tried to address in this new PR. > > Tests run without failures on supported platforms. I think we want this test also since it has all the enumerated configurations. That said, all these tests should be in the same directory as a future improvement. Either runtime/Monitor or runtime/locking. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22238#issuecomment-2488566697 From coleenp at openjdk.org Wed Nov 20 13:28:24 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 20 Nov 2024 13:28:24 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing In-Reply-To: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: On Tue, 19 Nov 2024 13:09:22 GMT, Fredrik Bredberg wrote: > @dcubed-ojdk is too busy, so I was asked to take over [https://github.com/openjdk/jdk/pull/18664](https://github.com/openjdk/jdk/pull/18664) and finish it. > > That old PR contains all the details and also got some review comments, which I have tried to address in this new PR. > > Tests run without failures on supported platforms. This test is a good addition to our locking tests. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22238#pullrequestreview-2448616686 From fbredberg at openjdk.org Wed Nov 20 13:45:39 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 20 Nov 2024 13:45:39 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing [v2] In-Reply-To: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: > @dcubed-ojdk is too busy, so I was asked to take over [https://github.com/openjdk/jdk/pull/18664](https://github.com/openjdk/jdk/pull/18664) and finish it. > > That old PR contains all the details and also got some review comments, which I have tried to address in this new PR. > > Tests run without failures on supported platforms. Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: Update after review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22238/files - new: https://git.openjdk.org/jdk/pull/22238/files/aec44fd7..067f8c1b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22238&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22238&range=00-01 Stats: 21 lines in 1 file changed: 6 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/22238.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22238/head:pull/22238 PR: https://git.openjdk.org/jdk/pull/22238 From fbredberg at openjdk.org Wed Nov 20 13:45:40 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 20 Nov 2024 13:45:40 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing [v2] In-Reply-To: <_Cl08mVfRxZKcnvhcAceCFi1hU255fNyFcDoWqT2KCk=.f9007475-f7b4-4c21-a0d9-0b2795dc4544@github.com> References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> <_Cl08mVfRxZKcnvhcAceCFi1hU255fNyFcDoWqT2KCk=.f9007475-f7b4-4c21-a0d9-0b2795dc4544@github.com> Message-ID: On Tue, 19 Nov 2024 20:33:08 GMT, Daniel D. Daugherty wrote: >> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: >> >> Update after review > > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 230: > >> 228: counter++; >> 229: >> 230: // Legacy mode has no lock stack. I.e. there is no limit > > nit grammar/typography: s/. I.e. there/, i.e., there fixed > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 238: > >> 236: } >> 237: >> 238: // We havn't reached the stack lock capasity (recursion > > nit typo: s/capasity/capacity/ fixed > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 270: > >> 268: } >> 269: >> 270: // This test nests x recurcive locks of INNER, in x recursive > > nit typo: s/recurcive/recursive/ fixed > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 271: > >> 269: >> 270: // This test nests x recurcive locks of INNER, in x recursive >> 271: // locks of OUTER. The number x is taken from the max number > > nit spacing: s/OUTER. The/OUTER. The/ fixed > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 316: > >> 314: } else { >> 315: // Second time we want to lock A, the lock stack >> 316: // looks like this [A, B]. Lightweight locking > > nit spacing: s/B]. Lightweight/B]. Lightweight/ fixed > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 318: > >> 316: // looks like this [A, B]. Lightweight locking >> 317: // doesn't allow interleaving ([A, B, A]), instead >> 318: // it inflates A and removed it from the lock > > nit typo: s/removed/removes/ fixed > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 375: > >> 373: } >> 374: // Implied else: for LM_MONITOR or LM_LIGHTWEIGHT it can be >> 375: // either inflated or not point because A is not locked anymore > > nit typo: s/either inflated or not point because/either inflated or not because/ fixed > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 399: > >> 397: System.err.println("where:"); >> 398: System.err.println(" n_secs ::= > 0"); >> 399: System.err.println(" Default n_secs is 15."); > > Based on L408 below, it looks like default n_secs is now `30`. fixed > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 402: > >> 400: System.err.println(" mode ::= 1 - outer and inner"); >> 401: System.err.println(" ::= 2 - alternate A and B"); >> 402: System.err.println(" Default mode is 1."); > > Based on L407 below, it looks like default mode is now `2`. fixed > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 503: > >> 501: waiter.wait(); >> 502: } catch (InterruptedException ie) { >> 503: } > > Do you want to add this: > > // This should not happen. > ie.printStackTrace(); > > here also? fixed > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 541: > >> 539: waiter.wait(); >> 540: } catch (InterruptedException ie) { >> 541: } > > Do you want to add this: > > // This should not happen. > ie.printStackTrace(); > > here also? fixed > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 556: > >> 554: waiter.wait(); >> 555: } catch (InterruptedException ie) { >> 556: } > > Do you want to add this: > > // This should not happen. > ie.printStackTrace(); > > here also? fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850335375 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850334888 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850336106 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850335585 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850336354 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850340633 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850338178 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850338548 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850338932 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850339155 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850339678 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850339867 From jwaters at openjdk.org Wed Nov 20 14:04:18 2024 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 20 Nov 2024 14:04:18 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v4] In-Reply-To: <74ZhlOx7e3sojf0pEeMlRMtFdIJw2zpEQUcUX1dZ5M8=.ed56ea4c-41b0-4f16-8a5d-1f5f4ff0562f@github.com> References: <59WqblNEW-wzd2GO-Onj-jOA5g9syFLg_ovhUFUXuoo=.2ec4d90e-c767-4527-9c3f-73953cfb915d@github.com> <74ZhlOx7e3sojf0pEeMlRMtFdIJw2zpEQUcUX1dZ5M8=.ed56ea4c-41b0-4f16-8a5d-1f5f4ff0562f@github.com> Message-ID: On Wed, 20 Nov 2024 12:17:30 GMT, Andrew Haley wrote: > > > > Wouldn't it be far easier to handle `fmod` ourselves in the AArch64b back end? > > > > > > > > > You mean like how x86 has its own custom fmod implementation in the assembler? That does sound pretty good to me, then we could get rid of this workaround entirely, but I don't know how to implement this on ARM64 > > > > > > Oh, OK. I'll have a look. > > I had a look at SharedRuntime::fmod_winx64. I'm sure it's fine for AArch64. Just put it in os_windows. I'm not sure I understand - The fix in this Pull Request already uses SharedRuntime::fmod_winx64 (Or more accurately, it doesn't change the existing code that uses it, just makes the ifdef check more accurate). I don't know if moving the implementation from sharedRuntimeRem.cpp to os_windows.cpp gives any benefit, and sharedRuntimeRem.cpp is already under os/windows. I might have misunderstood you earlier, but it sounded as if you were proposing to implement frem and drem in assembly for ARM64 like what is already done for x86 ------------- PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2488663492 From rrich at openjdk.org Wed Nov 20 14:48:33 2024 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 20 Nov 2024 14:48:33 GMT Subject: RFR: 8344609: Check ResourceMark nesting when allocating a GrowableArray on an alternative ResourceArea Message-ID: With this change the GrowableArray nesting check is also performed if allocating from an `Arena` which in fact is a `ResourceArea`. The additional checking can help find issue as [JDK-8328085](https://bugs.openjdk.org/browse/JDK-8328085). More testing is pending. ------------- Commit messages: - Check GrowableArray nesting if allocating on alternative ResourceArea Changes: https://git.openjdk.org/jdk/pull/22269/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22269&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344609 Stats: 18 lines in 2 files changed: 17 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22269.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22269/head:pull/22269 PR: https://git.openjdk.org/jdk/pull/22269 From bkilambi at openjdk.org Wed Nov 20 14:49:29 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Wed, 20 Nov 2024 14:49:29 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja wrote: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 6. Auto-vectorization of newly supported scalar operations. > 7. X86 and AARCH64 backend implementation for all supported intrinsics. > 9. Functional and Performance validation tests. > > **Missing Pieces:-** > **- AARCH64 Backend.** > > Kindly review and share your feedback. > > Best Regards, > Jatin test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java line 44: > 42: @Test > 43: @IR(applyIfCPUFeatureAnd = {"avx512_fp16", "false", "avx512vl", "true"}, counts = {IRNode.VECTOR_CAST_HF2F, IRNode.VECTOR_SIZE_ANY, ">= 1", IRNode.VECTOR_CAST_F2HF, IRNode.VECTOR_SIZE_ANY, " >= 1"}) > 44: @IR(applyIfCPUFeatureAnd = {"avx512_fp16", "false", "f16c", "true"}, counts = {IRNode.VECTOR_CAST_HF2F, IRNode.VECTOR_SIZE_ANY, ">= 1", IRNode.VECTOR_CAST_F2HF, IRNode.VECTOR_SIZE_ANY, " >= 1"}) Wouldn't the Ideal transforms convert the IR for this test case to - ReinterpretS2HF ReinterpretS2HF \ / AddHF | ReinterpretHF2S | ConvHF2F ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1850449500 From gziemski at openjdk.org Wed Nov 20 14:53:25 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 20 Nov 2024 14:53:25 GMT Subject: RFR: 8328944: NMT reports "unknown" memory [v2] In-Reply-To: References: <6Up1fGCFJl2HAUGl6IBKEDRodItQLn5TigHJEdzZpbU=.5f5ae17c-edc4-4dd8-ae09-8e8ae8567354@github.com> Message-ID: On Wed, 20 Nov 2024 10:03:08 GMT, Afshin Zafari wrote: >> Gerard Ziemski 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: >> >> - avoid using mtNone >> - Merge remote-tracking branch 'upstream/master' into JDK-8328944 >> - revert, we will re-do with a smaller change >> - remove more mtNone >> - remove API that allows to change the mem_tag for virtual memory, feedback >> - do not allow default parameter for mtNone > > src/hotspot/share/memory/virtualspace.hpp line 65: > >> 63: >> 64: void initialize(size_t size, size_t alignment, size_t page_size, >> 65: char* requested_address, bool executable, MemTag mem_tag = mtNone); > > When `mtNone` is default, it is still possible to introduce/create regions of Unknown types. The MemTag arg should be mandatory. Sorry Afshin, I didn't mention it in my summary at the top, but the goal in this fix is only to address the cases covered by the issue. I tried fixing all of them in my 1st try, but Thomas had some reservations. The "missing" cases will be addressed in a follow up(s). However, I will copy all your feedback, so we don't loose it. Thank you very much for taking detailed look and providing feedback! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1850456338 From jbhateja at openjdk.org Wed Nov 20 15:00:38 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 20 Nov 2024 15:00:38 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 14:46:46 GMT, Bhavana Kilambi wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 6. Auto-vectorization of newly supported scalar operations. >> 7. X86 and AARCH64 backend implementation for all supported intrinsics. >> 9. Functional and Performance validation tests. >> >> **Missing Pieces:-** >> **- AARCH64 Backend.** >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java line 44: > >> 42: @Test >> 43: @IR(applyIfCPUFeatureAnd = {"avx512_fp16", "false", "avx512vl", "true"}, counts = {IRNode.VECTOR_CAST_HF2F, IRNode.VECTOR_SIZE_ANY, ">= 1", IRNode.VECTOR_CAST_F2HF, IRNode.VECTOR_SIZE_ANY, " >= 1"}) >> 44: @IR(applyIfCPUFeatureAnd = {"avx512_fp16", "false", "f16c", "true"}, counts = {IRNode.VECTOR_CAST_HF2F, IRNode.VECTOR_SIZE_ANY, ">= 1", IRNode.VECTOR_CAST_F2HF, IRNode.VECTOR_SIZE_ANY, " >= 1"}) > > Wouldn't the Ideal transforms convert the IR for this test case to - > > ReinterpretS2HF ReinterpretS2HF > \ / > AddHF > | > ReinterpretHF2S > | > ConvHF2F > > in which case, ConvF2HF won't match? New transforms are guarded by target features checks, the IR test rules are enforced only on non AVX512_FP16 targets. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1850469049 From bkilambi at openjdk.org Wed Nov 20 15:05:20 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Wed, 20 Nov 2024 15:05:20 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 14:57:11 GMT, Jatin Bhateja wrote: >> test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java line 44: >> >>> 42: @Test >>> 43: @IR(applyIfCPUFeatureAnd = {"avx512_fp16", "false", "avx512vl", "true"}, counts = {IRNode.VECTOR_CAST_HF2F, IRNode.VECTOR_SIZE_ANY, ">= 1", IRNode.VECTOR_CAST_F2HF, IRNode.VECTOR_SIZE_ANY, " >= 1"}) >>> 44: @IR(applyIfCPUFeatureAnd = {"avx512_fp16", "false", "f16c", "true"}, counts = {IRNode.VECTOR_CAST_HF2F, IRNode.VECTOR_SIZE_ANY, ">= 1", IRNode.VECTOR_CAST_F2HF, IRNode.VECTOR_SIZE_ANY, " >= 1"}) >> >> Wouldn't the Ideal transforms convert the IR for this test case to - >> >> ReinterpretS2HF ReinterpretS2HF >> \ / >> AddHF >> | >> ReinterpretHF2S >> | >> ConvHF2F >> >> in which case, ConvF2HF won't match? > > New transforms are guarded by target features checks, the IR test rules are enforced only on non AVX512_FP16 targets. Oh right! Sorry misread the IR test rules. Got it now. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1850477856 From adinn at openjdk.org Wed Nov 20 15:28:28 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 20 Nov 2024 15:28:28 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations Message-ID: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Implementation of JDK-8343767 ------------- Commit messages: - locate super lookup stubs in same blob for all arches - do verification under ifdef ASSERT - fix yet more problems with s390 stubs - better error notification - fix more problems with s390 stubs - Verify stubs are generated in correct blob - fix problems with s390 stub address getters - fix problems with s390 stub declaration - correct merge problems - add new file for s390 - ... and 41 more: https://git.openjdk.org/jdk/compare/23597361...1c0766a6 Changes: https://git.openjdk.org/jdk/pull/21957/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343767 Stats: 6934 lines in 57 files changed: 4061 ins; 1535 del; 1338 mod Patch: https://git.openjdk.org/jdk/pull/21957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21957/head:pull/21957 PR: https://git.openjdk.org/jdk/pull/21957 From vlivanov at openjdk.org Wed Nov 20 15:28:29 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 20 Nov 2024 15:28:29 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations In-Reply-To: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: On Thu, 7 Nov 2024 14:54:32 GMT, Andrew Dinn wrote: > Implementation of JDK-8343767 Nice refactoring, Andrew! Very nice! I like how the patch shapes. src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 208: > 206: StubGenStubId stub_id = StubGenStubId::call_stub_id; > 207: const char* stub_name = StubRoutines::get_stub_name(stub_id); > 208: StubCodeMark mark(this, "StubRoutines", stub_name); Cleanup suggestion: `StubGenStubId` could be passed as an argument into `StubCodeMark` constructor and name lookup performed there instead. The pattern is very common. src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 427: > 425: address generate_catch_exception() { > 426: StubGenStubId stub_id = StubGenStubId::catch_exception_id; > 427: StubCodeMark mark(this, stub_id); Stylistic suggestion: for such trivial cases, you can simply pass `StubGenStubId` constant as an argument. No need to declare a local for it. src/hotspot/share/runtime/stubDeclarations.hpp line 738: > 736: do_entry(compiler, bigIntegerLeftShiftWorker, \ > 737: bigIntegerLeftShiftWorker, bigIntegerLeftShift) \ > 738: AARCH64_ONLY( \ It's unfortunate to see platform-specific declarations in `stubDeclarations.hpp`. Any chances to keep them in CPU-specific files (as it is shaped now)? ------------- PR Review: https://git.openjdk.org/jdk/pull/21957#pullrequestreview-2421873447 PR Review: https://git.openjdk.org/jdk/pull/21957#pullrequestreview-2434938472 PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1833200070 PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1841488585 PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1833746698 From adinn at openjdk.org Wed Nov 20 15:28:29 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 20 Nov 2024 15:28:29 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations In-Reply-To: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: On Thu, 7 Nov 2024 14:54:32 GMT, Andrew Dinn wrote: > Implementation of JDK-8343767 So far this includes changes for aarch64 and x86_64/32. Changes for other ports are in progress. n.b.I rebased this to accommodate the newly added cont_preempt stub. I probably should have merged . . . The latest version now appears to be complete for aarch64, x86_64 and x86_32. Once I have prepared declarations and client changes for the other arches I will open this up for verification of those arches via porters plus full review. This PR is now ready for review. I'd be grateful if owners of riscv, ppc, s390 and arm ports could ensure that it passes tests on those platforms -- I don't have the kit to do so. I also noticed 2 failures on macos/x64. They are both CodeBuffer validation errors: # Internal Error (codeBuffer.cpp:1004), pid=33878, tid=28419 # guarantee(sect->end() <= tend) failed: sanity I'm not sure how they relate to this change but I can see that they might be to do with changing the blob names or some inadvertent change to the blob sizes. Unfortunately, I am not able to reproduce them as I don't have the relevant kit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2462444892 PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2476815259 PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2488876361 From adinn at openjdk.org Wed Nov 20 15:28:29 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 20 Nov 2024 15:28:29 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations In-Reply-To: References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: On Thu, 7 Nov 2024 18:54:10 GMT, Vladimir Ivanov wrote: >> Implementation of JDK-8343767 > > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 208: > >> 206: StubGenStubId stub_id = StubGenStubId::call_stub_id; >> 207: const char* stub_name = StubRoutines::get_stub_name(stub_id); >> 208: StubCodeMark mark(this, "StubRoutines", stub_name); > > Cleanup suggestion: `StubGenStubId` could be passed as an argument into `StubCodeMark` constructor and name lookup performed there instead. The pattern is very common. That's a nice idea. I was thinking that when we come to save and restore the code in the AOT cache we would need the name again. However, looking at the prototype I think we can also pass the id to the load and save routines and let them lookup the name when they need it. > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 427: > >> 425: address generate_catch_exception() { >> 426: StubGenStubId stub_id = StubGenStubId::catch_exception_id; >> 427: StubCodeMark mark(this, stub_id); > > Stylistic suggestion: for such trivial cases, you can simply pass `StubGenStubId` constant as an argument. No need to declare a local for it. When we come to add save and restore we will need to have the id to do the AOT cache lookup then generate the stub if not found on a production run as well as to write the stub if this is an assembly run. So, I'll leave this a is for then. Also, at some point I want to add an assert that the stub generator should be 'expecting' this stub which means I will need to pass it this id. A stub generator knows which blob it is writing into (it gets passed the blob id when constructed) and the template macros generate a debug-only method to translate a stub id to the blob (id) named in the stub declaration. So, we can use that to cross-check that the declared blob matches the one the stub gets written to. Quite a few (generic) stubs were being written to different blobs by different arches so it will be good to ensure they end up in the same blob. That's not 100% the full picture just now because we also have StubGenerator instances responsible for writing the icache flush stub and (on x86 only) vm_version stubs and they have no associated blob id. I'd like to fold those stubs and their associated blobs into the declaration structure too at some point. For now I'll make sure they are associated with blob_id == NO_BLOBID. > src/hotspot/share/runtime/stubDeclarations.hpp line 738: > >> 736: do_entry(compiler, bigIntegerLeftShiftWorker, \ >> 737: bigIntegerLeftShiftWorker, bigIntegerLeftShift) \ >> 738: AARCH64_ONLY( \ > > It's unfortunate to see platform-specific declarations in `stubDeclarations.hpp`. Any chances to keep them in CPU-specific files (as it is shaped now)? That's a good question and I believe it is the preferred option. It would certainly be possible to include a per-arch file (stubDeclarations_.hpp) to define a common (per-blob) declaration macro providing the arch-specific declarations. e.g. for x86 the arch file would specify: #define STUBGEN_INITIAL_BLOBS_ARCH_DO(do_arch_blob, do_stub, repeat_stub, do_arch_entry) \ do_arch_blob(initial, 20000 WINDOWS_ONLY(+1000)) \ do_stub(initial, verify_mxcsr) \ do_arch_entry(x86, initial, verify_mxcsr, verify_mxcsr_entry, \ verify_mxcsr_entry) \ . . . #define STUBGEN_FINAL_BLOBS_ARCH_DO(do_arch_blob, do_stub, repeat_stub, do_arch_entry) \ . . . The generic macro would then paste this in place of the AARCH64_ONLY(), X86_ONLY() sections e.g. #define STUBGEN_INITIAL_BLOBS_DO(do_blob, end_blob, \ do_stub, repeat_stub, \ do_entry, do_entry_init, \ do_arch_blob, \ do_arch_entry, do_arch_entry_init) \ do_blob(initial) \ do_stub(initial, call_stub) \ . . . do_entry(initial, dlibm_tan_cot_huge, dlibm_tan_cot_huge, \ dlibm_tan_cot_huge) \ STUBGEN_INITIAL_BLOBS_ARCH_DO(do_arch_blob, do_stub, \ repeat_stub, do_arch_entry) I did originally plan to split the declarations like this. However, I ended up putting the arch declarations into the generic file in this draft for two reasons. The primary one was heuristic: I wanted to make it easy to see the declaration structure I was proposing before we committed to it. However, I also had a niggling concern that when it comes to updating the declarations it may be easier if they are all in the one place, right next to the doc comments that explain what the declaration format is and what gets generated from the declarations. My experience of writing a stub some years back tells me that it is important to make it easy for developers who are not fully familiar with the runtime to see how all the pieces fit together so I put all the pieces in one place. That said, I believe your recommendation to split the declarations is probably better. By the time I have added PPC_ONLY, RISCV_ONLY etc sections whatever transparency is to be gained from keeping declarations together will be lost in the sheer volume of declarations, especially given that a lot of the arch declarations will appear multiple times in different arches. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1836534322 PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1842358211 PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1836534410 From vlivanov at openjdk.org Wed Nov 20 15:28:29 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 20 Nov 2024 15:28:29 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations In-Reply-To: References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: On Thu, 14 Nov 2024 14:50:47 GMT, Andrew Dinn wrote: >> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 427: >> >>> 425: address generate_catch_exception() { >>> 426: StubGenStubId stub_id = StubGenStubId::catch_exception_id; >>> 427: StubCodeMark mark(this, stub_id); >> >> Stylistic suggestion: for such trivial cases, you can simply pass `StubGenStubId` constant as an argument. No need to declare a local for it. > > When we come to add save and restore we will need to have the id to do the AOT cache lookup then generate the stub if not found on a production run as well as to write the stub if this is an assembly run. So, I'll leave this a is for then. > > Also, at some point I want to add an assert that the stub generator should be 'expecting' this stub which means I will need to pass it this id. A stub generator knows which blob it is writing into (it gets passed the blob id when constructed) and the template macros generate a debug-only method to translate a stub id to the blob (id) named in the stub declaration. So, we can use that to cross-check that the declared blob matches the one the stub gets written to. Quite a few (generic) stubs were being written to different blobs by different arches so it will be good to ensure they end up in the same blob. > > That's not 100% the full picture just now because we also have StubGenerator instances responsible for writing the icache flush stub and (on x86 only) vm_version stubs and they have no associated blob id. I'd like to fold those stubs and their associated blobs into the declaration structure too at some point. For now I'll make sure they are associated with blob_id == NO_BLOBID. Ok, it makes sense. As an idea, `StubCodeMark` can be used to hide some of that logic. (As an example, different marks on MacroAssembler mess with its instances to customize their behavior.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1842780446 From stefank at openjdk.org Wed Nov 20 15:38:24 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 20 Nov 2024 15:38:24 GMT Subject: RFR: 8328944: NMT reports "unknown" memory [v2] In-Reply-To: <6Up1fGCFJl2HAUGl6IBKEDRodItQLn5TigHJEdzZpbU=.5f5ae17c-edc4-4dd8-ae09-8e8ae8567354@github.com> References: <6Up1fGCFJl2HAUGl6IBKEDRodItQLn5TigHJEdzZpbU=.5f5ae17c-edc4-4dd8-ae09-8e8ae8567354@github.com> Message-ID: <7UxSMg_or6Avy_wuFlkkuDO0pBpyR5DiKeuY0N4uhVs=.d2c7835f-6e68-4f87-857a-e4fd6eb5f12b@github.com> On Tue, 19 Nov 2024 22:01:13 GMT, Gerard Ziemski wrote: >> We use `mtNone` value in several functions default parameters, which may show up in NMT reports. >> >> We address this, by avoiding using `mtNone`. >> >> This fix only addresses the cases covered by the issue. I am not trying to replace every single `mtNone` here, but eventually the goal would be to do just that. >> >> TODO: update copyrights. >> >> Testing: undergoing MARCH5 tier1-5 ... > > Gerard Ziemski 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: > > - avoid using mtNone > - Merge remote-tracking branch 'upstream/master' into JDK-8328944 > - revert, we will re-do with a smaller change > - remove more mtNone > - remove API that allows to change the mem_tag for virtual memory, feedback > - do not allow default parameter for mtNone src/hotspot/os/linux/os_linux.cpp line 4587: > 4585: char* hint = (char*)(os::Linux::initial_thread_stack_bottom() - > 4586: (StackOverflow::stack_guard_zone_size() + page_size)); > 4587: char* codebuf = os::attempt_reserve_memory_at(hint, page_size, false, mtInternal); Could this be mtThread instead? src/hotspot/os/linux/os_linux.cpp line 4595: > 4593: // map our codebuf, try again at an address one megabyte lower. > 4594: hint -= 1 * M; > 4595: codebuf = os::attempt_reserve_memory_at(hint, page_size, false, mtInternal); Could this be mtThread instead? src/hotspot/share/memory/virtualspace.hpp line 74: > 72: // Initialize the reserved space with the given size. Depending on the size > 73: // a suitable page size and alignment will be used. > 74: explicit ReservedSpace(size_t size, MemTag mem_tag); Suggestion: ReservedSpace(size_t size, MemTag mem_tag); No need for `explicit` when you've added a parameter. src/hotspot/share/runtime/safepointMechanism.cpp line 61: > 59: const size_t page_size = os::vm_page_size(); > 60: const size_t allocation_size = 2 * page_size; > 61: char* polling_page = os::reserve_memory(allocation_size, false, mtSafepoint); Suggestion: char* polling_page = os::reserve_memory(allocation_size, !ExecMem, mtSafepoint); src/hotspot/share/utilities/debug.cpp line 712: > 710: > 711: void initialize_assert_poison() { > 712: char* page = os::reserve_memory(os::vm_page_size(), false, mtInternal); Suggestion: char* page = os::reserve_memory(os::vm_page_size(), !ExecMem, mtTest); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1850535276 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1850535378 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1850543822 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1850541711 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1850541996 From fbredberg at openjdk.org Wed Nov 20 15:43:39 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 20 Nov 2024 15:43:39 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing [v3] In-Reply-To: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: > @dcubed-ojdk is too busy, so I was asked to take over [https://github.com/openjdk/jdk/pull/18664](https://github.com/openjdk/jdk/pull/18664) and finish it. > > That old PR contains all the details and also got some review comments, which I have tried to address in this new PR. > > Tests run without failures on supported platforms. Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: s/removed/removes/ ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22238/files - new: https://git.openjdk.org/jdk/pull/22238/files/067f8c1b..9c635534 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22238&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22238&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22238.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22238/head:pull/22238 PR: https://git.openjdk.org/jdk/pull/22238 From ihse at openjdk.org Wed Nov 20 16:23:32 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 20 Nov 2024 16:23:32 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4] In-Reply-To: <77VcfKMeUXxKjoQ3zeEcBJfDQYhPRSt08OXMqg9rQDo=.de753f60-5568-4dec-9b86-2ba86acebfaa@github.com> References: <1knXD7Wc8heH83BTJEguqmlTAa70oXDw_nWI0hBjAm0=.bcf88238-2b63-4d14-b3a3-94eabca69586@github.com> <77VcfKMeUXxKjoQ3zeEcBJfDQYhPRSt08OXMqg9rQDo=.de753f60-5568-4dec-9b86-2ba86acebfaa@github.com> Message-ID: On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li wrote: >> Hi, >> Can you help to review this patch? >> Thanks >> >> This is a continuation of work based on [1] by @XiaohongGong, most work was done in that pr. In this new pr, just rebased the code in [1], then added some minor changes (renaming of calling method, add libsleef as extra lib in CI cross-build on aarch64 in github workflow); I aslo tested the combination of following scenarios: >> * at build time >> * with/without sleef >> * with/without sve support >> * at runtime >> * with/without sleef >> * with/without sve support >> >> [1] https://github.com/openjdk/jdk/pull/16234 >> >> ## Regression Test >> * test/jdk/jdk/incubator/vector/ >> * test/hotspot/jtreg/compiler/vectorapi/ >> >> ## Performance Test >> Previously, @XiaohongGong has shared the data: https://github.com/openjdk/jdk/pull/16234#issuecomment-1767727028 > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > fix jni includes First of all, building stuff with `--with-extra-cflags` is always at your own peril. It might, or might not, work, partially due to problems such as the one you describe, where the user-added flag somehow conflicts with the existing flag. If you wish to modify the build in ways that is not compatible with the existing build logic, you might end up needed a local patch to be applied, and not just adding the `--with-extra-cflags` command line. With that said, we will try to make it as possible as reasonable to write the build system for flexibility. In this case: what do you propose we would have done instead? My understanding is that the compiler needs to be told about SVE in order to compile libsleef properly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18294#issuecomment-2489025971 From dcubed at openjdk.org Wed Nov 20 16:30:27 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 20 Nov 2024 16:30:27 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing [v3] In-Reply-To: References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: On Wed, 20 Nov 2024 15:43:39 GMT, Fredrik Bredberg wrote: >> @dcubed-ojdk is too busy, so I was asked to take over [https://github.com/openjdk/jdk/pull/18664](https://github.com/openjdk/jdk/pull/18664) and finish it. >> >> That old PR contains all the details and also got some review comments, which I have tried to address in this new PR. >> >> Tests run without failures on supported platforms. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > s/removed/removes/ There are more tweaks needed for the usage() function in order to get correct default output values. test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 230: > 228: counter++; > 229: > 230: // Legacy mode has no lock stack, I.e. there is no limit nit typography: s/stack, I.e. there/stack, i.e., there/ - lower case "i.e." followed by a comma test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 238: > 236: } > 237: > 238: // We havn't reached the stack lock capacity (recursion nit typo: s/havn't/haven't / test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 392: > 390: } > 391: > 392: static void usage(int mode, int n_secs) { Please drop these parameters. test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 399: > 397: System.err.println("where:"); > 398: System.err.println(" n_secs ::= > 0"); > 399: System.err.println(" Default n_secs is " + n_secs + "."); Please change this to: System.err.println(" Default n_secs is " + def_n_secs + "."); test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 402: > 400: System.err.println(" mode ::= 1 - outer and inner"); > 401: System.err.println(" ::= 2 - alternate A and B"); > 402: System.err.println(" Default mode is " + mode + "."); Please change this to: System.err.println(" Default mode is " + def_mode + "."); test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 408: > 406: public static void main(String... argv) throws Exception { > 407: int mode = 2; > 408: int n_secs = 30; Please change this to: static final int def_mode = 2; static final int def_n_secs = 30; int mode = def_mode; int n_secs = def_n_secs; test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 411: > 409: > 410: if (argv.length != 0 && argv.length != 1 && argv.length != 2) { > 411: usage(mode, n_secs); Please drop these parameters. test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 424: > 422: System.err.println("ERROR: '" + argv[0] > 423: + "': invalid n_secs value."); > 424: usage(mode, n_secs); Please drop these parameters. test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 439: > 437: System.err.println("ERROR: '" + argv[1] > 438: + "': invalid mode value."); > 439: usage(mode, n_secs); Please drop these parameters. The reason for adding `def_mode` and `def_n_secs` above is that when this `usage()` call is made, it will print the current `n_secs` value instead of the actual default `n_secs` value. It will also print the `mode` value returned by L429 instead of the actual default `mode` value. ------------- Changes requested by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22238#pullrequestreview-2449093166 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850604654 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850605970 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850618037 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850614564 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850615392 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850613746 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850620329 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850620712 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850624071 From dcubed at openjdk.org Wed Nov 20 16:30:27 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 20 Nov 2024 16:30:27 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing [v3] In-Reply-To: References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: On Wed, 20 Nov 2024 13:17:14 GMT, Coleen Phillimore wrote: >> The configurability was intentional so that specific modes could be exercised independently. Also adding additional modes in the future is/was planned. > > I think having the separate modes would be useful if you're debugging failures but as a normal test run, doesn't add anything except more runs. But I'll withdraw my suggestion. Being able to exercise the modes independently means you don't have to modify the test code to debug... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850626503 From adinn at openjdk.org Wed Nov 20 16:34:26 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 20 Nov 2024 16:34:26 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations In-Reply-To: References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: On Thu, 14 Nov 2024 19:26:54 GMT, Vladimir Ivanov wrote: >> When we come to add save and restore we will need to have the id to do the AOT cache lookup then generate the stub if not found on a production run as well as to write the stub if this is an assembly run. So, I'll leave this a is for then. >> >> Also, at some point I want to add an assert that the stub generator should be 'expecting' this stub which means I will need to pass it this id. A stub generator knows which blob it is writing into (it gets passed the blob id when constructed) and the template macros generate a debug-only method to translate a stub id to the blob (id) named in the stub declaration. So, we can use that to cross-check that the declared blob matches the one the stub gets written to. Quite a few (generic) stubs were being written to different blobs by different arches so it will be good to ensure they end up in the same blob. >> >> That's not 100% the full picture just now because we also have StubGenerator instances responsible for writing the icache flush stub and (on x86 only) vm_version stubs and they have no associated blob id. I'd like to fold those stubs and their associated blobs into the declaration structure too at some point. For now I'll make sure they are associated with blob_id == NO_BLOBID. > > Ok, it makes sense. As an idea, `StubCodeMark` can be used to hide some of that logic. (As an example, different marks on MacroAssembler mess with its instances to customize their behavior.) n.b. the latest version has `StubCodeMark` assert that stub id matches the blob id. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1850635610 From adinn at openjdk.org Wed Nov 20 16:34:27 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 20 Nov 2024 16:34:27 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations In-Reply-To: References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: On Wed, 20 Nov 2024 16:30:50 GMT, Andrew Dinn wrote: >> Ok, it makes sense. As an idea, `StubCodeMark` can be used to hide some of that logic. (As an example, different marks on MacroAssembler mess with its instances to customize their behavior.) > > n.b. the latest version has `StubCodeMark` assert that stub id matches the blob id. I will leave folding in the icache and vm_version blobs for a follow_up PR. This one is already big enough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1850636838 From adinn at openjdk.org Wed Nov 20 16:34:28 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 20 Nov 2024 16:34:28 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations In-Reply-To: References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: <7cMDMGUxI0RLEAyn9_-u9smiSnRfFk3GHiUC5McpO1k=.eb1ae5bd-9d36-4936-8a83-6938462f3c42@github.com> On Mon, 11 Nov 2024 11:35:21 GMT, Andrew Dinn wrote: >> src/hotspot/share/runtime/stubDeclarations.hpp line 738: >> >>> 736: do_entry(compiler, bigIntegerLeftShiftWorker, \ >>> 737: bigIntegerLeftShiftWorker, bigIntegerLeftShift) \ >>> 738: AARCH64_ONLY( \ >> >> It's unfortunate to see platform-specific declarations in `stubDeclarations.hpp`. Any chances to keep them in CPU-specific files (as it is shaped now)? > > That's a good question and I believe it is the preferred option. > > It would certainly be possible to include a per-arch file (stubDeclarations_.hpp) to define a common (per-blob) declaration macro providing the arch-specific declarations. > > e.g. for x86 the arch file would specify: > > #define STUBGEN_INITIAL_BLOBS_ARCH_DO(do_arch_blob, do_stub, repeat_stub, do_arch_entry) \ > do_arch_blob(initial, 20000 WINDOWS_ONLY(+1000)) \ > do_stub(initial, verify_mxcsr) \ > do_arch_entry(x86, initial, verify_mxcsr, verify_mxcsr_entry, \ > verify_mxcsr_entry) \ > . . . > #define STUBGEN_FINAL_BLOBS_ARCH_DO(do_arch_blob, do_stub, repeat_stub, do_arch_entry) \ > . . . > > The generic macro would then paste this in place of the AARCH64_ONLY(), X86_ONLY() sections e.g. > > #define STUBGEN_INITIAL_BLOBS_DO(do_blob, end_blob, \ > do_stub, repeat_stub, \ > do_entry, do_entry_init, \ > do_arch_blob, \ > do_arch_entry, do_arch_entry_init) \ > do_blob(initial) \ > do_stub(initial, call_stub) \ > . . . > do_entry(initial, dlibm_tan_cot_huge, dlibm_tan_cot_huge, \ > dlibm_tan_cot_huge) \ > STUBGEN_INITIAL_BLOBS_ARCH_DO(do_arch_blob, do_stub, \ > repeat_stub, do_arch_entry) > > I did originally plan to split the declarations like this. However, I ended up putting the arch declarations into the generic file in this draft for two reasons. The primary one was heuristic: I wanted to make it easy to see the declaration structure I was proposing before we committed to it. However, I also had a niggling concern that when it comes to updating the declarations it may be easier if they are all in the one place, right next to the doc comments that explain what the declaration format is and what gets generated from the declarations. My experience of writing a stub some years back tells me that it is important to make it easy for developers who are not fully familiar with the runtime to see how all the pieces fit t... Latest version has arch declarations in arch-specific files ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1850632005 From aph at openjdk.org Wed Nov 20 16:48:19 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 20 Nov 2024 16:48:19 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v4] In-Reply-To: References: <59WqblNEW-wzd2GO-Onj-jOA5g9syFLg_ovhUFUXuoo=.2ec4d90e-c767-4527-9c3f-73953cfb915d@github.com> <74ZhlOx7e3sojf0pEeMlRMtFdIJw2zpEQUcUX1dZ5M8=.ed56ea4c-41b0-4f16-8a5d-1f5f4ff0562f@github.com> Message-ID: On Wed, 20 Nov 2024 14:01:15 GMT, Julian Waters wrote: > > I'm not sure I understand - The fix in this Pull Request already uses SharedRuntime::fmod_winx64 (Or more accurately, it doesn't change the existing code that uses it, just makes the ifdef check more accurate). I don't know if moving the implementation from sharedRuntimeRem.cpp to os_windows.cpp gives any benefit, and sharedRuntimeRem.cpp is already under os/windows. I might have misunderstood you earlier, but it sounded as if you were proposing to implement frem and drem in assembly for ARM64 like what is already done for x86 I got horribly confused. I thought about custome asm, but there's little point in doing so because `fmod` is always going to require repeated division and subtraction, so it's going to be slow. What you're doing in this patch looks correct as far as it goes, but `amd64`and `x64` in the comments in `sharedRuntime.[ch]pp` is wrong. Please find and fix those to make it clear we need this function on on AArch64 too. The name of the function `SharedRuntime::fmod_winx64` is at least misleading if not wrong. Maybe `SharedRuntime::fmod_win64`? My apologies for the confusion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2489086948 From fbredberg at openjdk.org Wed Nov 20 17:24:17 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 20 Nov 2024 17:24:17 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing [v3] In-Reply-To: References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: On Wed, 20 Nov 2024 16:23:28 GMT, Daniel D. Daugherty wrote: >> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: >> >> s/removed/removes/ > > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 439: > >> 437: System.err.println("ERROR: '" + argv[1] >> 438: + "': invalid mode value."); >> 439: usage(mode, n_secs); > > Please drop these parameters. > > The reason for adding `def_mode` and `def_n_secs` above is that when this `usage()` call > is made, it will print the current `n_secs` value instead of the actual default `n_secs` value. > It will also print the `mode` value returned by L429 instead of the actual default `mode` value. My bad. I was a bit too quick. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850717286 From fbredberg at openjdk.org Wed Nov 20 18:53:38 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 20 Nov 2024 18:53:38 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing [v3] In-Reply-To: References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: On Wed, 20 Nov 2024 16:11:39 GMT, Daniel D. Daugherty wrote: >> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: >> >> s/removed/removes/ > > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 230: > >> 228: counter++; >> 229: >> 230: // Legacy mode has no lock stack, I.e. there is no limit > > nit typography: s/stack, I.e. there/stack, i.e., there/ > - lower case "i.e." followed by a comma fixed > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 238: > >> 236: } >> 237: >> 238: // We havn't reached the stack lock capacity (recursion > > nit typo: s/havn't/haven't / fixed > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 392: > >> 390: } >> 391: >> 392: static void usage(int mode, int n_secs) { > > Please drop these parameters. fixed > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 399: > >> 397: System.err.println("where:"); >> 398: System.err.println(" n_secs ::= > 0"); >> 399: System.err.println(" Default n_secs is " + n_secs + "."); > > Please change this to: > > System.err.println(" Default n_secs is " + def_n_secs + "."); fixed > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 402: > >> 400: System.err.println(" mode ::= 1 - outer and inner"); >> 401: System.err.println(" ::= 2 - alternate A and B"); >> 402: System.err.println(" Default mode is " + mode + "."); > > Please change this to: > > System.err.println(" Default mode is " + def_mode + "."); fixed > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 408: > >> 406: public static void main(String... argv) throws Exception { >> 407: int mode = 2; >> 408: int n_secs = 30; > > Please change this to: > > static final int def_mode = 2; > static final int def_n_secs = 30; > int mode = def_mode; > int n_secs = def_n_secs; Fixed, but the `static final` ones had to be moved up to get it to compile. > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 411: > >> 409: >> 410: if (argv.length != 0 && argv.length != 1 && argv.length != 2) { >> 411: usage(mode, n_secs); > > Please drop these parameters. fixed > test/hotspot/jtreg/runtime/Monitor/TestRecursiveLocking.java line 424: > >> 422: System.err.println("ERROR: '" + argv[0] >> 423: + "': invalid n_secs value."); >> 424: usage(mode, n_secs); > > Please drop these parameters. fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850821366 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850821614 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850824024 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850823622 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850825642 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850823011 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850824581 PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1850825069 From fbredberg at openjdk.org Wed Nov 20 18:53:37 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 20 Nov 2024 18:53:37 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing [v4] In-Reply-To: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: > @dcubed-ojdk is too busy, so I was asked to take over [https://github.com/openjdk/jdk/pull/18664](https://github.com/openjdk/jdk/pull/18664) and finish it. > > That old PR contains all the details and also got some review comments, which I have tried to address in this new PR. > > Tests run without failures on supported platforms. Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: Update two after review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22238/files - new: https://git.openjdk.org/jdk/pull/22238/files/9c635534..d32b9a0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22238&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22238&range=02-03 Stats: 12 lines in 1 file changed: 2 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/22238.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22238/head:pull/22238 PR: https://git.openjdk.org/jdk/pull/22238 From iklam at openjdk.org Wed Nov 20 19:03:17 2024 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 20 Nov 2024 19:03:17 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs In-Reply-To: References: Message-ID: <9MHc7gnBigXzGrBg0OsMsJy9wzGMoJ29pGYbbd3ODgo=.bef4cf54-97df-4530-b81d-097f5230538f@github.com> On Wed, 20 Nov 2024 00:37:25 GMT, Calvin Cheung wrote: > Currently, when retrieving a ClassFileStream during runtime, we call into the zip library to retrieve the stream based only on a class name. This doesn't work well if the class is in a multi-release jar under a versioned directory such as `META-INF/versions/9/Foo.class`. To address this issue, this change calls the java api `ClassLoader.getResourceAsStream()` to retrieve the stream. > > Passed tiers 1 - 4 testing. Code change looks good. One comment on the test. test/hotspot/jtreg/runtime/cds/appcds/jvmti/CFLH/MultiReleaseJars.java line 151: > 149: // create multi-version.jar which contains Main.class, Foo.class and Bar.class. > 150: // Foo.class has only one version: base version 9. > 151: // Bar.class has two versions: base version 9 and default version. Since there's no default version for Foo, does the class loader try to get the highest version (9 in this case) that's the same or below the current JDK's version? I think such a comment in the test case would be helpful. Also, perhaps the test should look like this: META-INF/versions/9/Foo.class META-INF/versions/11/Foo.class where the different Foo classes print a different string. We should assert that we get version 11 instead of 9. ------------- PR Review: https://git.openjdk.org/jdk/pull/22262#pullrequestreview-2449466092 PR Review Comment: https://git.openjdk.org/jdk/pull/22262#discussion_r1850836615 From wkemper at openjdk.org Wed Nov 20 19:59:42 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 20 Nov 2024 19:59:42 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 19 Nov 2024 23:56:56 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp line 455: >> >>> 453: // Note: would be sufficient to mark only the card that holds the start of this Reference object. >>> 454: heap->old_generation()->card_scan()->mark_range_as_dirty(cast_from_oop(reference), reference->size()); >>> 455: } >> >> Two things: >> a) This sounds like `card_table_barrier(reference, raw_referent)`? Since this code is getting called for every dropped reference, just checking a `ShenandoahCardBarrier` flag sounds more efficient. >> b) Is there a point in dirtying up to `reference->size()`? > > Will test this. https://bugs.openjdk.org/browse/JDK-8344640 >> src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 657: >> >>> 655: _generation(nullptr) { >>> 656: if (_options._verify_marked == ShenandoahVerifier::_verify_marked_complete_satb_empty) { >>> 657: Threads::change_thread_claim_token(); >> >> It is fairly odd to see Verifier touching the claim token, since the bug _may be_ somewhere in parallel thread oop iteration infra. I think it is fine to just use `Threads::threads_do` (non-parallel version), which AFAIU does not require token modifications. > > Will test this. https://bugs.openjdk.org/browse/JDK-8344638 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1850900559 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1850901137 From szaldana at openjdk.org Wed Nov 20 20:01:02 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Wed, 20 Nov 2024 20:01:02 GMT Subject: RFR: 8344568: Renaming ceil_log2 to log2i_ceil Message-ID: Hi all, This PR addresses [8344568](https://bugs.openjdk.org/browse/JDK-8344568). Should be a straightforward rename and cleanup. Thanks, Sonia ------------- Commit messages: - 8344568: Renaming ceil_log2 to log2i_ceil Changes: https://git.openjdk.org/jdk/pull/22279/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22279&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344568 Stats: 43 lines in 7 files changed: 7 ins; 7 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/22279.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22279/head:pull/22279 PR: https://git.openjdk.org/jdk/pull/22279 From shade at openjdk.org Wed Nov 20 20:22:27 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 20 Nov 2024 20:22:27 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: <_9t4lSh7P6yPIZtllm4hVRuZ7kqyhWcyCfrKh37B8fA=.fb510cc5-c9db-4c31-ba90-6189789f10b8@github.com> On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: > > - Merge branch 'merge-latest' into great-genshen-pr-redux > - Use new CompactHeader forwarding APIs in generational mode > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge > - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines > > Reviewed-by: wkemper > - Merge > - 8343227: GenShen: Fold resource mark into management of preselected regions > > Reviewed-by: kdnilsen > - Merge openjdk/jdk tip into great-genshen-pr-redux > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge remote-tracking branch 'jdk/master' into merge-latest > - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 Almost there, 220/230 reviewed. src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 62: > 60: void work(uint worker_id) { > 61: ShenandoahHeap* heap = ShenandoahHeap::heap(); > 62: ShenandoahParallelWorkerSession worker_session(worker_id); Why this needs to be `ShenandoahParallelWorkerSession`, not `ShenandoahConcurrentWorkerSession`? This is a concurrent step, is it? ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2449189030 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1850899803 From shade at openjdk.org Wed Nov 20 20:22:28 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 20 Nov 2024 20:22:28 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: <86FIc0saJkWuxy228AuIYA6VKDYhwQCd5bH31sBK6Ws=.aa86fa8d-6c88-4edb-ac89-c89b68e65f29@github.com> On Tue, 19 Nov 2024 23:07:21 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp line 44: >> >>> 42: for (size_t idx = 0; idx < num_regions; idx++) { >>> 43: ShenandoahHeapRegion* r = heap->get_region(idx); >>> 44: if (r->is_affiliated() && heap->is_bitmap_slice_committed(r) && !is_bitmap_clear_range(r->bottom(), r->end())) { >> >> I don't understand this for single gen mode. In that mode `is_affiliated() == false` always, right? So this check never passes, and `is_bitmap_clear` always returns `true`? > > No, in single gen mode regions that are not `FREE` are affiliated with `YOUNG`. That's weird. We have `Young`, `Old` and `Global` generations. Why affiliation is not `Free`, `Young`, `Old`, and `Global` then? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1850665665 From wkemper at openjdk.org Wed Nov 20 20:22:29 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 20 Nov 2024 20:22:29 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: <86FIc0saJkWuxy228AuIYA6VKDYhwQCd5bH31sBK6Ws=.aa86fa8d-6c88-4edb-ac89-c89b68e65f29@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <86FIc0saJkWuxy228AuIYA6VKDYhwQCd5bH31sBK6Ws=.aa86fa8d-6c88-4edb-ac89-c89b68e65f29@github.com> Message-ID: On Wed, 20 Nov 2024 16:47:20 GMT, Aleksey Shipilev wrote: >> No, in single gen mode regions that are not `FREE` are affiliated with `YOUNG`. > > That's weird. We have `Young`, `Old` and `Global` generations. Why affiliation is not `Free`, `Young`, `Old`, and `Global` then? Yes, it's a little weird. It didn't seem necessary to have a `Global` affiliation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1850927526 From kbarrett at openjdk.org Wed Nov 20 20:55:31 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 20 Nov 2024 20:55:31 GMT Subject: RFR: 8344568: Renaming ceil_log2 to log2i_ceil In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 16:56:11 GMT, Sonia Zaldana Calles wrote: > Hi all, > > This PR addresses [8344568](https://bugs.openjdk.org/browse/JDK-8344568). Should be a straightforward rename and cleanup. > > Thanks, > Sonia Looks good, and trivial. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22279#pullrequestreview-2449677146 From lmesnik at openjdk.org Wed Nov 20 21:50:15 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Nov 2024 21:50:15 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v7] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: <8Mrds88Q8y5Vp8uHxCH226INVFHccBvFvjAsXC6m9Zo=.a157d0f3-600d-46b6-964e-0a8d77e40f18@github.com> On Wed, 20 Nov 2024 05:45:35 GMT, Chris Plummer wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed spaces > > test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java line 51: > >> 49: theApp = new LingeredAppWithLockInVM(); >> 50: String classPath = System.getProperty("test.class.path"); >> 51: LingeredApp.startAppExactJvmOpts(theApp, > > Why use startAppExactJvmOpts and limit testing to just this one config (with vm.flagless)? Can't these be added arguments? Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1851023806 From lmesnik at openjdk.org Wed Nov 20 21:55:00 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Nov 2024 21:55:00 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v8] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: Updates after Chris feeback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/0fbafab4..b85daff7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=06-07 Stats: 21 lines in 3 files changed: 7 ins; 5 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From lmesnik at openjdk.org Wed Nov 20 21:55:00 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Nov 2024 21:55:00 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v7] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: <5PTfFZBfjr_4b__p4LJzXQNtj4FYbXfzpdRJpXK4BgY=.fe38b09f-78b1-46b8-8378-377a2c2d8644@github.com> On Wed, 20 Nov 2024 05:41:23 GMT, Chris Plummer wrote: > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > Can you explain what the issue was? For the most part what I can tell is you moved a lot of code from MutexLocker to Mutex, but the reason isn't clear. IIUC The VMStructs can read classes only, so I moved _mutex_array to be a static member of Mutex. All other refactoring just needed for this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22171#issuecomment-2489610303 From ccheung at openjdk.org Wed Nov 20 22:02:34 2024 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 20 Nov 2024 22:02:34 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v2] In-Reply-To: References: Message-ID: > Currently, when retrieving a ClassFileStream during runtime, we call into the zip library to retrieve the stream based only on a class name. This doesn't work well if the class is in a multi-release jar under a versioned directory such as `META-INF/versions/9/Foo.class`. To address this issue, this change calls the java api `ClassLoader.getResourceAsStream()` to retrieve the stream. > > Passed tiers 1 - 4 testing. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: updated testcase ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22262/files - new: https://git.openjdk.org/jdk/pull/22262/files/d9d70379..96b7945f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22262&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22262&range=00-01 Stats: 37 lines in 1 file changed: 21 ins; 11 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/22262.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22262/head:pull/22262 PR: https://git.openjdk.org/jdk/pull/22262 From ccheung at openjdk.org Wed Nov 20 22:02:35 2024 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 20 Nov 2024 22:02:35 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v2] In-Reply-To: <9MHc7gnBigXzGrBg0OsMsJy9wzGMoJ29pGYbbd3ODgo=.bef4cf54-97df-4530-b81d-097f5230538f@github.com> References: <9MHc7gnBigXzGrBg0OsMsJy9wzGMoJ29pGYbbd3ODgo=.bef4cf54-97df-4530-b81d-097f5230538f@github.com> Message-ID: On Wed, 20 Nov 2024 19:00:48 GMT, Ioi Lam wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> updated testcase > > test/hotspot/jtreg/runtime/cds/appcds/jvmti/CFLH/MultiReleaseJars.java line 151: > >> 149: // create multi-version.jar which contains Main.class, Foo.class and Bar.class. >> 150: // Foo.class has only one version: base version 9. >> 151: // Bar.class has two versions: base version 9 and default version. > > Since there's no default version for Foo, does the class loader try to get the highest version (9 in this case) that's the same or below the current JDK's version? I think such a comment in the test case would be helpful. > > Also, perhaps the test should look like this: > > > META-INF/versions/9/Foo.class > META-INF/versions/11/Foo.class > > > where the different Foo classes print a different string. We should assert that we get version 11 instead of 9. I've updated the test. Instead of version 11, I've used the major JDK version. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22262#discussion_r1851035865 From cjplummer at openjdk.org Wed Nov 20 22:20:05 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 20 Nov 2024 22:20:05 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v7] In-Reply-To: <5PTfFZBfjr_4b__p4LJzXQNtj4FYbXfzpdRJpXK4BgY=.fe38b09f-78b1-46b8-8378-377a2c2d8644@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> <5PTfFZBfjr_4b__p4LJzXQNtj4FYbXfzpdRJpXK4BgY=.fe38b09f-78b1-46b8-8378-377a2c2d8644@github.com> Message-ID: On Wed, 20 Nov 2024 21:50:27 GMT, Leonid Mesnik wrote: > > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > > > > > Can you explain what the issue was? For the most part what I can tell is you moved a lot of code from MutexLocker to Mutex, but the reason isn't clear. > > IIUC The VMStructs can read classes only, so I moved _mutex_array to be a static member of Mutex. All other refactoring just needed for this change. Ok, that makes sense. I remember now you mentioning to me a couple of weeks ago that SA can't access globals via VMStructs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22171#issuecomment-2489627100 From lmesnik at openjdk.org Wed Nov 20 22:20:07 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Nov 2024 22:20:07 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v7] In-Reply-To: <8Mrds88Q8y5Vp8uHxCH226INVFHccBvFvjAsXC6m9Zo=.a157d0f3-600d-46b6-964e-0a8d77e40f18@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> <8Mrds88Q8y5Vp8uHxCH226INVFHccBvFvjAsXC6m9Zo=.a157d0f3-600d-46b6-964e-0a8d77e40f18@github.com> Message-ID: On Wed, 20 Nov 2024 21:47:30 GMT, Leonid Mesnik wrote: >> test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java line 51: >> >>> 49: theApp = new LingeredAppWithLockInVM(); >>> 50: String classPath = System.getProperty("test.class.path"); >>> 51: LingeredApp.startAppExactJvmOpts(theApp, >> >> Why use startAppExactJvmOpts and limit testing to just this one config (with vm.flagless)? Can't these be added arguments? > > Updated. I also changed lock to avoid false positive failures. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1851041298 From kbarrett at openjdk.org Wed Nov 20 23:45:28 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 20 Nov 2024 23:45:28 GMT Subject: RFR: 8344665: Refactor PartialArrayState allocation for reuse Message-ID: This change splits the existing PartialArrayStateAllocator class into an allocator class and a manager class. The allocator class is per worker thread. The manager class provides the memory management context for a group of allocators. This change is in preparation for some other refactorings around partial array state handling. That work is intended to make it easier for various collections to adopt the use of that mechanism for chunking the processing of large objArrays. The new implementation for the memory management context is based on the existing one, with an Arena per worker, now controlled by the manager object. Potential improvements to that can be explored in the future. Some ideas include improvements to the Arena API or a single thread-safe Arena variant (trading slower arena allocation (which is the slow path) for less memory usage). G1 has a single manager, reused by each young/mixed GC. Associated state allocators are nested in the per-worker structures, so deleted at the end of the collection. The manager is reset at the end of the collection to allow the memory to be recycled. It is planned that the STW full collector will also use this manager when converted to use PartialArrayState. So it will be reused by all STW collections. ParallelGC has a single manager, reused by each young collection. Because the per-worker promotion managers are never destroyed, their nested state allocators are never destroyed. So the manager is not reset, instead leaving previously allocated states in the allocator free lists for use by the next collection. This means the full collector won't be able to use the same manager object as the young collectors. Testing: mach5 tier1-5 ------------- Commit messages: - parallel youngen uses new PAS - g1 uses refactored PAS - refactor PAS allocation Changes: https://git.openjdk.org/jdk/pull/22287/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22287&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344665 Stats: 310 lines in 14 files changed: 178 ins; 52 del; 80 mod Patch: https://git.openjdk.org/jdk/pull/22287.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22287/head:pull/22287 PR: https://git.openjdk.org/jdk/pull/22287 From cjplummer at openjdk.org Thu Nov 21 00:00:22 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 21 Nov 2024 00:00:22 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v7] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> <8Mrds88Q8y5Vp8uHxCH226INVFHccBvFvjAsXC6m9Zo=.a157d0f3-600d-46b6-964e-0a8d77e40f18@github.com> Message-ID: On Wed, 20 Nov 2024 22:05:44 GMT, Leonid Mesnik wrote: >> Updated. > > I also changed lock to avoid false positive failures. I think you still need to push your recent changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1851136997 From lmesnik at openjdk.org Thu Nov 21 00:04:52 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Nov 2024 00:04:52 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v9] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: lock changed and flagless requires removed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/b85daff7..4ed1d57e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=07-08 Stats: 7 lines in 2 files changed: 1 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From wkemper at openjdk.org Thu Nov 21 00:36:41 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 00:36:41 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: <_9t4lSh7P6yPIZtllm4hVRuZ7kqyhWcyCfrKh37B8fA=.fb510cc5-c9db-4c31-ba90-6189789f10b8@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <_9t4lSh7P6yPIZtllm4hVRuZ7kqyhWcyCfrKh37B8fA=.fb510cc5-c9db-4c31-ba90-6189789f10b8@github.com> Message-ID: On Wed, 20 Nov 2024 19:55:35 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 62: > >> 60: void work(uint worker_id) { >> 61: ShenandoahHeap* heap = ShenandoahHeap::heap(); >> 62: ShenandoahParallelWorkerSession worker_session(worker_id); > > Why this needs to be `ShenandoahParallelWorkerSession`, not `ShenandoahConcurrentWorkerSession`? This is a concurrent step, is it? Yes, https://bugs.openjdk.org/browse/JDK-8344670 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1851158343 From psandoz at openjdk.org Thu Nov 21 00:42:27 2024 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 21 Nov 2024 00:42:27 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja wrote: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 6. Auto-vectorization of newly supported scalar operations. > 7. X86 and AARCH64 backend implementation for all supported intrinsics. > 9. Functional and Performance validation tests. > > **Missing Pieces:-** > **- AARCH64 Backend.** > > Kindly review and share your feedback. > > Best Regards, > Jatin To make it easier to review this large change i recommend that the aarch64 changes be separated into a dependent PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2489828972 From wkemper at openjdk.org Thu Nov 21 00:59:27 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 00:59:27 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: > This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 524 commits: - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux - 8344670: GenShen: Use concurrent worker session for concurrent mark phase Reviewed-by: kdnilsen - 8344640: GenShen: Reuse existing card mark barrier function when dropping references Reviewed-by: shade, ysr - 8344592: GenShen: Remove unnecessary comments and changes Reviewed-by: kdnilsen - 8344263: GenShen: Reduce extraneous log messages at INFO level Reviewed-by: ysr, shade - 8344638: GenShen: Verifier should not touch claim token Reviewed-by: shade - Merge - 8344320: GenShen: Possible null pointer usage in shGenerationalHeap Reviewed-by: wkemper, ysr - 8344321: GenShen: Fix various sonar scan warnings Reviewed-by: kdnilsen, shade - 8344264: GenShen: Improve comments and method names Reviewed-by: shade - ... and 514 more: https://git.openjdk.org/jdk/compare/95a00f8a...7ab16403 ------------- Changes: https://git.openjdk.org/jdk/pull/21273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=07 Stats: 22960 lines in 230 files changed: 21196 ins; 892 del; 872 mod Patch: https://git.openjdk.org/jdk/pull/21273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21273/head:pull/21273 PR: https://git.openjdk.org/jdk/pull/21273 From cjplummer at openjdk.org Thu Nov 21 01:27:16 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 21 Nov 2024 01:27:16 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v9] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: <4-xJP_OF53uk0Ll2zOCIfCoS0nzDw2choPX7sqDG2NI=.1a439b8e-e965-44e7-8bbb-16d3edbbd41c@github.com> On Thu, 21 Nov 2024 00:04:52 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > lock changed and flagless requires removed Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22171#pullrequestreview-2450033629 From lmesnik at openjdk.org Thu Nov 21 02:35:15 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Nov 2024 02:35:15 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v10] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: updated time between attempts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/4ed1d57e..015546b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From haosun at openjdk.org Thu Nov 21 02:44:22 2024 From: haosun at openjdk.org (Hao Sun) Date: Thu, 21 Nov 2024 02:44:22 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja wrote: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 6. Auto-vectorization of newly supported scalar operations. > 7. X86 and AARCH64 backend implementation for all supported intrinsics. > 9. Functional and Performance validation tests. > > **Missing Pieces:-** > **- AARCH64 Backend.** > > Kindly review and share your feedback. > > Best Regards, > Jatin Hi. Better to update the copyright year to 2024 for the following modified files: src/hotspot/share/adlc/output_h.cpp src/hotspot/share/opto/connode.cpp src/hotspot/share/opto/connode.hpp src/hotspot/share/opto/constantTable.cpp src/hotspot/share/opto/divnode.cpp src/hotspot/share/opto/divnode.hpp src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/amd64/AMD64.java test/hotspot/jtreg/compiler/lib/ir_framework/test/IREncodingPrinter.java ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2489949430 From cjplummer at openjdk.org Thu Nov 21 02:45:15 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 21 Nov 2024 02:45:15 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v10] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: On Thu, 21 Nov 2024 02:35:15 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated time between attempts Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22171#pullrequestreview-2450105729 From amitkumar at openjdk.org Thu Nov 21 04:59:18 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 21 Nov 2024 04:59:18 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations In-Reply-To: References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: <4yPDz6UHerf6A-5iCfPR-bJPLKeVKrO5hTqJHPKpS-o=.3439285d-3df6-40fe-a9a7-3171707d9f58@github.com> On Wed, 20 Nov 2024 15:24:24 GMT, Andrew Dinn wrote: >> Implementation of JDK-8343767 > > This PR is now ready for review. I'd be grateful if owners of riscv, ppc, s390 and arm ports could ensure that it passes tests on those platforms -- I don't have the kit to do so. > > I also noticed 2 failures on macos/x64. They are both CodeBuffer validation errors: > > # Internal Error (codeBuffer.cpp:1004), pid=33878, tid=28419 > # guarantee(sect->end() <= tend) failed: sanity > > I'm not sure how they relate to this change but I can see that they might be to do with changing the blob names or some inadvertent change to the blob sizes. Unfortunately, I am not able to reproduce them as I don't have the relevant kit. @adinn I think there is some issue with s390x. With current changes I got build failure: Error occurred during initialization of boot layer java.lang.module???????????????????????????????????????????????????????????????????????????????????????????????????????????? Caused by: ja??????????????????????????????????????????????????????????????????????????????????????????? gmake[3]: *** [Gendata.gmk:64: /home/amit/jdk/build/linux-s390x-server-fastdebug/buildtools/create_symbols_javac/_the.COMPILE_CREATE_SYMBOLS_batch] Error 1 gmake[2]: *** [make/Main.gmk:139: jdk.compiler-gendata] Error 2 gmake[2]: *** Waiting for unfinished jobs.... ERROR: Build failed for target 'images' in configuration 'linux-s390x-server-fastdebug' (exit code 2) Stopping javac server === Output from failing command(s) repeated here === * For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch: Error occurred during initialization of boot layer java.lang.module???????????????????????????????????????????????????????????????????????????????????????????????????????????? Caused by: ja??????????????????????????????????????????????????????????????????????????????????????????? * All command lines available in /home/amit/jdk/build/linux-s390x-server-fastdebug/make-support/failure-logs. === End of repeated output === Though I don't see any command it ran before running into this failure. without your commits, i.e. on commit `235973615fbad7073df67167ab1cb4d40b6f1ab5` build is fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2490080596 From dholmes at openjdk.org Thu Nov 21 05:06:25 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Nov 2024 05:06:25 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing [v4] In-Reply-To: References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: On Wed, 20 Nov 2024 18:53:37 GMT, Fredrik Bredberg wrote: >> @dcubed-ojdk is too busy, so I was asked to take over [https://github.com/openjdk/jdk/pull/18664](https://github.com/openjdk/jdk/pull/18664) and finish it. >> >> That old PR contains all the details and also got some review comments, which I have tried to address in this new PR. >> >> Tests run without failures on supported platforms. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Update two after review test/hotspot/jtreg/runtime/Monitor/StressWrapper_TestRecursiveLocking_36M.java line 1: > 1: /* What does the `36M` signify? Do we really need it? Could we not just call this `StressTestRecursiveLocking`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1851356369 From lmesnik at openjdk.org Thu Nov 21 05:08:06 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Nov 2024 05:08:06 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v11] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: SA test doesn't work with ZGC ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/015546b4..39b374f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=09-10 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From qpzhang at openjdk.org Thu Nov 21 05:08:36 2024 From: qpzhang at openjdk.org (Patrick Zhang) Date: Thu, 21 Nov 2024 05:08:36 GMT Subject: RFR: 8312425: [vectorapi] AArch64: Optimize vector math operations with SLEEF [v4] In-Reply-To: References: <1knXD7Wc8heH83BTJEguqmlTAa70oXDw_nWI0hBjAm0=.bcf88238-2b63-4d14-b3a3-94eabca69586@github.com> <77VcfKMeUXxKjoQ3zeEcBJfDQYhPRSt08OXMqg9rQDo=.de753f60-5568-4dec-9b86-2ba86acebfaa@github.com> Message-ID: On Wed, 20 Nov 2024 16:20:59 GMT, Magnus Ihse Bursie wrote: > First of all, building stuff with `--with-extra-cflags` is always at your own peril. It might, or might not, work, partially due to problems such as the one you describe, where the user-added flag somehow conflicts with the existing flag. If you wish to modify the build in ways that is not compatible with the existing build logic, you might end up needed a local patch to be applied, and not just adding the `--with-extra-cflags` command line. > > With that said, we will try to make it as possible as reasonable to write the build system for flexibility. > > In this case: what do you propose we would have done instead? My understanding is that the compiler needs to be told about SVE in order to compile libsleef properly. It is right to tell the compiler about `+sve` for libsleef compilation, while the concerning point is `-march=armv8-a`. I agreed that using `armv8-a` could be a safer way to a build-system. However it invalidates the ability of `--with-extra-cflags` of specifying any proper `-march=` or `-mcpu=`. Note that the user knows very well about what to build and where to run, but has no way to change things without modifying sources. For example, if one sets `--with-extra-cflags=-march=armv9.1-a` for any equivalent `-mcpu=`, why libsleef still wants to use `armv8-a` with downgraded version of ISA? I don't think one should use "a local path" here as it would be contrary to the intent of having autoconf and the design of `--with-extra-cflags`. Frankly speaking, no better idea from me either. Trying to update user specified `-march=` might be a way, such as `-march=armv9.1-a+sve` in above example, but perhaps it generates a new violation of the rules - `not to modify user inputs`. Leaving the "cc1: warning" message there for the time being could be also fine as it only impacts libsleef, while it warns the potential issue, for any future resolving. FYI, aarch64 modifiers https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#g_t-march-and--mcpu-Feature-Modifiers arch?value | Architecture | Includes by default -- | -- | -- ?**armv8-a**? | Armv8-A | ?+fp?, ?+simd? ?armv8.1-a? | Armv8.1-A | ?armv8-a?, ?+crc?, ?+lse?, ?+rdma? ?armv8.2-a? | Armv8.2-A | ?armv8.1-a? ?armv8.3-a? | Armv8.3-A | ?armv8.2-a?, ?+pauth? ?armv8.4-a? | Armv8.4-A | ?armv8.3-a?, ?+flagm?, ?+fp16fml?, ?+dotprod? ?armv8.5-a? | Armv8.5-A | ?armv8.4-a?, ?+sb?, ?+ssbs?, ?+predres? ?armv8.6-a? | Armv8.6-A | ?armv8.5-a?, ?+bf16?, ?+i8mm? ?armv8.7-a? | Armv8.7-A | ?armv8.6-a? ?armv8.8-a? | Armv8.8-a | ?armv8.7-a?, ?+mops? ?armv8.9-a? | Armv8.9-a | ?armv8.8-a? ?armv9-a? | Armv9-A | ?armv8.5-a?, ?**+sve**?, ?+sve2? ?armv9.1-a? | Armv9.1-A | ?armv9-a?, ?+bf16?, ?+i8mm? ?armv9.2-a? | Armv9.2-A | ?armv9.1-a? ?armv9.3-a? | Armv9.3-A | ?armv9.2-a?, ?+mops? ?armv9.4-a? | Armv9.4-A | ?armv9.3-a? ?armv8-r? | Armv8-R | ?armv8-r? ------------- PR Comment: https://git.openjdk.org/jdk/pull/18294#issuecomment-2490088547 From iklam at openjdk.org Thu Nov 21 05:32:54 2024 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 21 Nov 2024 05:32:54 GMT Subject: RFR: 8344140: Refactor the discovery of AOT cache artifacts Message-ID: This is a clean up after the initial integration for [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) - Merged 3 loops into 1 for discovering the classes and oops that should be stored in the AOT cache. About 250 lines of code are deleted. - Added comments in aotArtifactFinder.hpp to describe the logic, which is much simpler than before. - Enum classes are no longer unconditionally AOT-initialized -- an Enum class is AOT-initialized only if we find an archived oop of this type. Note to reviewers: One consequence of this refactoring is that archived oops are now discovered (by heapShared.cpp) before the metadata are copied (by ArchiveBuilder). There are some functions that depend on the old order (metadata were copied before oop discovery), so I had to shuffle them around. Examples are `Modules::check_archived_module_oop()`, or the new code in `Klass::remove_java_mirror()`. ------------- Commit messages: - more clean up - tmp - More clean up - Removed unnecessary code - 8344140: Consolidate AOT cache code for artifact discovery Changes: https://git.openjdk.org/jdk/pull/22291/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22291&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344140 Stats: 1301 lines in 29 files changed: 535 ins; 659 del; 107 mod Patch: https://git.openjdk.org/jdk/pull/22291.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22291/head:pull/22291 PR: https://git.openjdk.org/jdk/pull/22291 From dholmes at openjdk.org Thu Nov 21 06:13:15 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Nov 2024 06:13:15 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v2] In-Reply-To: References: Message-ID: <-ItmDmV4oovdAbnojC5s4h3JIKozNKHIMm4SwilR_BE=.9dfbdca7-c435-4c1a-88d6-cd6425bacfb3@github.com> On Wed, 20 Nov 2024 22:02:34 GMT, Calvin Cheung wrote: >> Currently, when retrieving a ClassFileStream during runtime, we call into the zip library to retrieve the stream based only on a class name. This doesn't work well if the class is in a multi-release jar under a versioned directory such as `META-INF/versions/9/Foo.class`. To address this issue, this change calls the java api `ClassLoader.getResourceAsStream()` to retrieve the stream. >> >> Passed tiers 1 - 4 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > updated testcase test/hotspot/jtreg/runtime/cds/appcds/jvmti/CFLH/MultiReleaseJars.java line 48: > 46: static final String MAJOR_VERSION_STRING = String.valueOf(MAJOR_VERSION); > 47: > 48: static String[] getMain() { Can't you just define these as source files in the test directory rather than creating them dynamically? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22262#discussion_r1851413967 From dholmes at openjdk.org Thu Nov 21 06:23:17 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Nov 2024 06:23:17 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v2] In-Reply-To: References: Message-ID: <9xoOh3WCssQTWIZYkytf1O-T7Y80CmirGRm82yCLgJs=.c71429cf-1f71-48e7-a392-11d66294c0c0@github.com> On Wed, 20 Nov 2024 22:02:34 GMT, Calvin Cheung wrote: >> Currently, when retrieving a ClassFileStream during runtime, we call into the zip library to retrieve the stream based only on a class name. This doesn't work well if the class is in a multi-release jar under a versioned directory such as `META-INF/versions/9/Foo.class`. To address this issue, this change calls the java api `ClassLoader.getResourceAsStream()` to retrieve the stream. >> >> Passed tiers 1 - 4 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > updated testcase src/hotspot/share/cds/filemap.cpp line 2705: > 2703: > 2704: // InputStream ClassLoader.getResourceAsStream(String name) > 2705: JavaCalls::call_virtual(&result, Do we really have to make two Java upcalls to do this? What is the performance hit? Can we declare a helper method in ClassLoader that does it in one? Is there any risk of getting into a recursive loop here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22262#discussion_r1851422798 From jwaters at openjdk.org Thu Nov 21 06:34:50 2024 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 21 Nov 2024 06:34:50 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v5] In-Reply-To: References: Message-ID: > Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Revise comment in sharedRuntime.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21627/files - new: https://git.openjdk.org/jdk/pull/21627/files/47810433..967b9606 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=03-04 Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21627.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21627/head:pull/21627 PR: https://git.openjdk.org/jdk/pull/21627 From jwaters at openjdk.org Thu Nov 21 06:41:33 2024 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 21 Nov 2024 06:41:33 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v6] In-Reply-To: References: Message-ID: <43iM4MdPRiY-J59P4ZrvUNOZvRF_SthATx_usTPxgQ4=.dd9c77f8-98f6-4bc9-8d5b-7983fe3816b9@github.com> > Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Revise comment in sharedRuntime.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21627/files - new: https://git.openjdk.org/jdk/pull/21627/files/967b9606..b0083f8c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=04-05 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21627.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21627/head:pull/21627 PR: https://git.openjdk.org/jdk/pull/21627 From cjplummer at openjdk.org Thu Nov 21 07:22:15 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 21 Nov 2024 07:22:15 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v11] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: On Thu, 21 Nov 2024 05:08:06 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > SA test doesn't work with ZGC Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22171#pullrequestreview-2450464051 From fyang at openjdk.org Thu Nov 21 07:50:17 2024 From: fyang at openjdk.org (Fei Yang) Date: Thu, 21 Nov 2024 07:50:17 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations In-Reply-To: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: On Thu, 7 Nov 2024 14:54:32 GMT, Andrew Dinn wrote: > Implementation of JDK-8343767 Hi, Nice work! I am testing this on linux-riscv64 platform. Several minor comments about the riscv part after a cursory look. src/hotspot/cpu/riscv/stubDeclarations_riscv.hpp line 37: > 35: do_arch_entry(riscv, initial, get_previous_sp, \ > 36: get_previous_sp_entry, \ > 37: get_previous_sp_entry) \ `get_previous_sp_entry` has been removed by https://bugs.openjdk.org/browse/JDK-8344265. src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 1117: > 1115: // used by generate_conjoint_int_oop_copy(). > 1116: // > 1117: address generate_disjoint_copy(StubGenStubId stub_id, address* entry) { Preceding code comment needs update to reflect the new parameters. src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 1265: > 1263: // cache line boundaries will still be loaded and stored atomically. > 1264: // > 1265: address generate_conjoint_copy(StubGenStubId stub_id, address nooverlap_target, address *entry) { Preceding code comment needs update to reflect the new parameters. ------------- PR Review: https://git.openjdk.org/jdk/pull/21957#pullrequestreview-2450083528 PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1851489835 PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1851223868 PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1851224210 From bkilambi at openjdk.org Thu Nov 21 08:32:23 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Thu, 21 Nov 2024 08:32:23 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: <5JP6jPC2kBjgbzZa1397E5ROgo5xY9QpusWzUDMN6jg=.c4735599-b1d0-4a02-a5e6-d5f7eeefce8e@github.com> On Thu, 21 Nov 2024 02:41:47 GMT, Hao Sun wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 6. Auto-vectorization of newly supported scalar operations. >> 7. X86 and AARCH64 backend implementation for all supported intrinsics. >> 9. Functional and Performance validation tests. >> >> **Missing Pieces:-** >> **- AARCH64 Backend.** >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Hi, > > Better to update the copyright year to 2024 for the following modified files: > > > src/hotspot/share/adlc/output_h.cpp > src/hotspot/share/opto/connode.cpp > src/hotspot/share/opto/connode.hpp > src/hotspot/share/opto/constantTable.cpp > src/hotspot/share/opto/divnode.cpp > src/hotspot/share/opto/divnode.hpp > src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/amd64/AMD64.java > test/hotspot/jtreg/compiler/lib/ir_framework/test/IREncodingPrinter.java > > > I encountered one JTreg IR failure on AArch64 machine with SVE feature for `test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java` case. Here shows a snippet of the error log. > If AArch64 backend part is not implemented, we'd better skip the IR verification on AArch64+SVE side. > > > One or more @IR rules failed: > > Failed IR Rules (9) of Methods (9) ---------------------------------- > 1) Method "public void compiler.vectorization.TestFloat16VectorOperations.vectorAddFloat16()" - [Failed IR rules: 1]: * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"avx512_fp16", "true", "sve", "true"}, counts={"_#ADD_VHF#_", ">= 1" > }, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > > Phase "PrintIdeal": > - counts: Graph contains wrong number of nodes: > * Constraint 1: "(\d+(\s){2}(AddVHF.*)+(\s){2}===.*)" ... Hi @shqking , thanks for your review. I am currently working on adding the aarch64 port for these operations. It's being done here - https://github.com/jatin-bhateja/jdk/pull/6. Do you think it's ok to keep the code as is for some more time until my patch is rebased and merged? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2490369622 From stefank at openjdk.org Thu Nov 21 08:34:18 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 21 Nov 2024 08:34:18 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v11] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: On Thu, 21 Nov 2024 05:08:06 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > SA test doesn't work with ZGC Instead of putting this inside of Mutex, could you instead create a class that is the container of this array? I think that would make a cleaner split between the code that operates on a specific Mutex vs code that is dealing with the set of registered Mutexes. Maybe name it MutexSet, MutexList, MutexArray, RegisteredMutexes, ...? If you don't like that suggestion I'd prefer if you fixed the nits I mention below. src/hotspot/share/runtime/mutex.cpp line 536: > 534: } > 535: #endif // ASSERT > 536: // Print all mutexes/monitors that are currently owned by a thread; called Please, leave a blank line between the pre-existing functions and the ones you are moving. Suggestion: // Print all mutexes/monitors that are currently owned by a thread; called src/hotspot/share/runtime/mutex.hpp line 54: > 52: class Mutex : public CHeapObj { > 53: > 54: friend class VMStructs; Suggestion: friend class VMStructs; src/hotspot/share/runtime/mutex.hpp line 138: > 136: > 137: public: > 138: static void add_mutex(Mutex* var); This adds a function to a part of the class that previously only held variables. Could this move to a block where we have functions instead? src/hotspot/share/runtime/mutex.hpp line 207: > 205: // by fatal error handler. > 206: static void print_owned_locks_on_error(outputStream* st); > 207: static void print_lock_ranks(outputStream* st); This splits print_on_error from print_on. Could you move this before print_on_err and make sure that there's a blank line before print_on_error. ------------- Changes requested by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22171#pullrequestreview-2450579123 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1851562349 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1851564286 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1851567414 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1851568394 From jbhateja at openjdk.org Thu Nov 21 09:08:22 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 21 Nov 2024 09:08:22 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Thu, 21 Nov 2024 02:41:47 GMT, Hao Sun wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 6. Auto-vectorization of newly supported scalar operations. >> 7. X86 and AARCH64 backend implementation for all supported intrinsics. >> 9. Functional and Performance validation tests. >> >> **Missing Pieces:-** >> **- AARCH64 Backend.** >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Hi, > > Better to update the copyright year to 2024 for the following modified files: > > > src/hotspot/share/adlc/output_h.cpp > src/hotspot/share/opto/connode.cpp > src/hotspot/share/opto/connode.hpp > src/hotspot/share/opto/constantTable.cpp > src/hotspot/share/opto/divnode.cpp > src/hotspot/share/opto/divnode.hpp > src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/amd64/AMD64.java > test/hotspot/jtreg/compiler/lib/ir_framework/test/IREncodingPrinter.java > > > I encountered one JTreg IR failure on AArch64 machine with SVE feature for `test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java` case. Here shows a snippet of the error log. > If AArch64 backend part is not implemented, we'd better skip the IR verification on AArch64+SVE side. > > > One or more @IR rules failed: > > Failed IR Rules (9) of Methods (9) ---------------------------------- > 1) Method "public void compiler.vectorization.TestFloat16VectorOperations.vectorAddFloat16()" - [Failed IR rules: 1]: * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"avx512_fp16", "true", "sve", "true"}, counts={"_#ADD_VHF#_", ">= 1" > }, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > > Phase "PrintIdeal": > - counts: Graph contains wrong number of nodes: > * Constraint 1: "(\d+(\s){2}(AddVHF.*)+(\s){2}===.*)" ... > Hi @shqking , thanks for your review. I am currently working on adding the aarch64 port for these operations. It's being done here - [jatin-bhateja#6](https://github.com/jatin-bhateja/jdk/pull/6). Do you think it's ok to keep the code (regarding aarch64) in this patch as is for some more time until my patch is rebased and merged? Hi @Bhavana-Kilambi , As @PaulSandoz suggested, please file a follow-up PR on top of these changes with AARCH64 backend changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2490445899 From bkilambi at openjdk.org Thu Nov 21 09:54:24 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Thu, 21 Nov 2024 09:54:24 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Thu, 21 Nov 2024 09:05:23 GMT, Jatin Bhateja wrote: >> Hi, >> >> Better to update the copyright year to 2024 for the following modified files: >> >> >> src/hotspot/share/adlc/output_h.cpp >> src/hotspot/share/opto/connode.cpp >> src/hotspot/share/opto/connode.hpp >> src/hotspot/share/opto/constantTable.cpp >> src/hotspot/share/opto/divnode.cpp >> src/hotspot/share/opto/divnode.hpp >> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/amd64/AMD64.java >> test/hotspot/jtreg/compiler/lib/ir_framework/test/IREncodingPrinter.java >> >> >> I encountered one JTreg IR failure on AArch64 machine with SVE feature for `test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java` case. Here shows a snippet of the error log. >> If AArch64 backend part is not implemented, we'd better skip the IR verification on AArch64+SVE side. >> >> >> One or more @IR rules failed: >> >> Failed IR Rules (9) of Methods (9) ---------------------------------- >> 1) Method "public void compiler.vectorization.TestFloat16VectorOperations.vectorAddFloat16()" - [Failed IR rules: 1]: * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"avx512_fp16", "true", "sve", "true"}, counts={"_#ADD_VHF#_", ">= 1" >> }, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" >> > Phase "PrintIdeal": >> - counts: Graph contains wrong number of nodes: >> * Constraint 1: "(\d+(\s){2}(AddVHF.*)+(\s){2}===.*)" ... > >> Hi @shqking , thanks for your review. I am currently working on adding the aarch64 port for these operations. It's being done here - [jatin-bhateja#6](https://github.com/jatin-bhateja/jdk/pull/6). Do you think it's ok to keep the code (regarding aarch64) in this patch as is for some more time until my patch is rebased and merged? > > Hi @Bhavana-Kilambi , As @PaulSandoz suggested, please file a follow-up PR on top of these changes with AARCH64 backend changes. Hi @jatin-bhateja , I am resolving some errors on an aarch64 machine and if I have to raise a separate PR for aarch64, would you please remove all the aarch64 related IR checks until I have added the aarch64 backend? I might take some time to put the changes up for review. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2490607729 From aboldtch at openjdk.org Thu Nov 21 09:57:26 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 21 Nov 2024 09:57:26 GMT Subject: RFR: 8340422: ZGC: TestAllocateHeapAt.java should not run with transparent hugepages [v3] In-Reply-To: References: <7DtNgJ7IORWdKXdZwQsKuWLDG8uZJmGLAQaoFbGcg9I=.95486530-8384-4f65-b0a4-8793139078dd@github.com> Message-ID: <-hukQz-3sm6rWIlFoLWxAClmQ8vdgXRMw0cir0tXRWo=.8932fd93-5940-4b03-a620-abcdab6f46a8@github.com> On Mon, 4 Nov 2024 14:28:45 GMT, Axel Boldt-Christmas wrote: >> Similarly to [JDK-8340146](https://bugs.openjdk.org/browse/JDK-8340146) / #21127 does not work well with transparent hugepages. >> >> Because a machine may be configured in such a way that UseTransperetHugePages option gets ignored, the test driver must also check if it will be. As such I extracted the `test/hotspot/jtreg/runtime/os/HugePageConfiguration.java` utility into shared test library. >> >> On none linux machines the `vm.opt.final.UseTransparentHugePages` will be null, but the test checks `os.family == "linux"` first. I have not observed an issue with the JTREG filter on none linux machines. But will double check that it does not cause an issue. > > Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8340422 > - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8340422 > - 8340422: ZGC: TestAllocateHeapAt.java should not run with transparent hugepages Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21129#issuecomment-2490613013 From aboldtch at openjdk.org Thu Nov 21 09:57:26 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 21 Nov 2024 09:57:26 GMT Subject: Integrated: 8340422: ZGC: TestAllocateHeapAt.java should not run with transparent hugepages In-Reply-To: <7DtNgJ7IORWdKXdZwQsKuWLDG8uZJmGLAQaoFbGcg9I=.95486530-8384-4f65-b0a4-8793139078dd@github.com> References: <7DtNgJ7IORWdKXdZwQsKuWLDG8uZJmGLAQaoFbGcg9I=.95486530-8384-4f65-b0a4-8793139078dd@github.com> Message-ID: On Mon, 23 Sep 2024 07:43:32 GMT, Axel Boldt-Christmas wrote: > Similarly to [JDK-8340146](https://bugs.openjdk.org/browse/JDK-8340146) / #21127 does not work well with transparent hugepages. > > Because a machine may be configured in such a way that UseTransperetHugePages option gets ignored, the test driver must also check if it will be. As such I extracted the `test/hotspot/jtreg/runtime/os/HugePageConfiguration.java` utility into shared test library. > > On none linux machines the `vm.opt.final.UseTransparentHugePages` will be null, but the test checks `os.family == "linux"` first. I have not observed an issue with the JTREG filter on none linux machines. But will double check that it does not cause an issue. This pull request has now been integrated. Changeset: f2b10c6c Author: Axel Boldt-Christmas URL: https://git.openjdk.org/jdk/commit/f2b10c6c228f7be879b3f043accb22e0bc6535d6 Stats: 33 lines in 6 files changed: 30 ins; 0 del; 3 mod 8340422: ZGC: TestAllocateHeapAt.java should not run with transparent hugepages Reviewed-by: stefank, jsikstro ------------- PR: https://git.openjdk.org/jdk/pull/21129 From fbredberg at openjdk.org Thu Nov 21 10:01:19 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Thu, 21 Nov 2024 10:01:19 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing [v4] In-Reply-To: References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: On Thu, 21 Nov 2024 04:56:25 GMT, David Holmes wrote: >> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: >> >> Update two after review > > test/hotspot/jtreg/runtime/Monitor/StressWrapper_TestRecursiveLocking_36M.java line 1: > >> 1: /* > > What does the `36M` signify? Do we really need it? Could we not just call this `StressTestRecursiveLocking`? >From [JDK-8329351](https://bugs.openjdk.org/browse/JDK-8329351): _"`.../StressWrapper_TestRecursiveLocking_36M.java` is a wrapper that executes `.../TestRecursiveLocking.java` for 2 minutes for each of the 18 configs for a total of 36 minutes of execution time..."_ I think there is some value in looking at a test file's name, and thereby know how long it will take to run. @dcubed-ojdk created and named the file, maybe he has an opinion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1851721904 From aph at openjdk.org Thu Nov 21 10:10:25 2024 From: aph at openjdk.org (Andrew Haley) Date: Thu, 21 Nov 2024 10:10:25 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v6] In-Reply-To: <43iM4MdPRiY-J59P4ZrvUNOZvRF_SthATx_usTPxgQ4=.dd9c77f8-98f6-4bc9-8d5b-7983fe3816b9@github.com> References: <43iM4MdPRiY-J59P4ZrvUNOZvRF_SthATx_usTPxgQ4=.dd9c77f8-98f6-4bc9-8d5b-7983fe3816b9@github.com> Message-ID: <_r9ABgVGMI9hlBmV2vWnhY6YNQIQ-7ZwXR8DsfPcrfw=.340b49c9-2273-4abd-a455-39d667223976@github.com> On Thu, 21 Nov 2024 06:41:33 GMT, Julian Waters wrote: >> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Revise comment in sharedRuntime.hpp src/hotspot/share/runtime/sharedRuntime.hpp line 149: > 147: // now needs the workaround, so this is now used > 148: // for Windows ARM64 > 149: static double fmod_winx64(double x, double y); Suggestion: static double fmod_win64(double x, double y); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1851740250 From aph at openjdk.org Thu Nov 21 10:13:16 2024 From: aph at openjdk.org (Andrew Haley) Date: Thu, 21 Nov 2024 10:13:16 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v6] In-Reply-To: <43iM4MdPRiY-J59P4ZrvUNOZvRF_SthATx_usTPxgQ4=.dd9c77f8-98f6-4bc9-8d5b-7983fe3816b9@github.com> References: <43iM4MdPRiY-J59P4ZrvUNOZvRF_SthATx_usTPxgQ4=.dd9c77f8-98f6-4bc9-8d5b-7983fe3816b9@github.com> Message-ID: <7RH8t4s6f9WH00MKVI9eKWuX8C70tzIRWukqTTM1TLw=.d83721e3-0240-4efe-a43f-5cd37fd1e1b8@github.com> On Thu, 21 Nov 2024 06:41:33 GMT, Julian Waters wrote: >> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Revise comment in sharedRuntime.hpp test/hotspot/gtest/runtime/test_os.cpp line 766: > 764: ASSERT_EQ(mapping_info.regions, 1); > 765: ASSERT_EQ(mapping_info.size, total_range_len); > 766: ASSERT_EQ(mapping_info.committed_size, size_t { 0 }); Suggestion: ASSERT_EQ(mapping_info.committed_size, size_t{0}); We don't usually insert extra spaces. Was there a special reason? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1851749057 From adinn at openjdk.org Thu Nov 21 10:58:34 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 21 Nov 2024 10:58:34 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations [v2] In-Reply-To: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: > Implementation of JDK-8343767 Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: fix comments and remove unused stubid on riscv ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21957/files - new: https://git.openjdk.org/jdk/pull/21957/files/1c0766a6..b0680822 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=00-01 Stats: 24 lines in 2 files changed: 10 ins; 3 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/21957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21957/head:pull/21957 PR: https://git.openjdk.org/jdk/pull/21957 From adinn at openjdk.org Thu Nov 21 10:58:34 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 21 Nov 2024 10:58:34 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations [v2] In-Reply-To: References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: On Thu, 21 Nov 2024 07:21:48 GMT, Fei Yang wrote: >> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: >> >> fix comments and remove unused stubid on riscv > > src/hotspot/cpu/riscv/stubDeclarations_riscv.hpp line 37: > >> 35: do_arch_entry(riscv, initial, get_previous_sp, \ >> 36: get_previous_sp_entry, \ >> 37: get_previous_sp_entry) \ > > `get_previous_sp_entry` has been removed by https://bugs.openjdk.org/browse/JDK-8344265. Thanks for spotting this. I missed it when reconciling against your deletion. I think I got lal the others though. Fixed in latest push. > src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 1117: > >> 1115: // used by generate_conjoint_int_oop_copy(). >> 1116: // >> 1117: address generate_disjoint_copy(StubGenStubId stub_id, address* entry) { > > Preceding code comment needs update to reflect the new parameters. Fixed in latest push > src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 1265: > >> 1263: // cache line boundaries will still be loaded and stored atomically. >> 1264: // >> 1265: address generate_conjoint_copy(StubGenStubId stub_id, address nooverlap_target, address *entry) { > > Preceding code comment needs update to reflect the new parameters. Fixed in latest push ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1851831650 PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1851829018 PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1851829441 From adinn at openjdk.org Thu Nov 21 11:03:16 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 21 Nov 2024 11:03:16 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations In-Reply-To: <4yPDz6UHerf6A-5iCfPR-bJPLKeVKrO5hTqJHPKpS-o=.3439285d-3df6-40fe-a9a7-3171707d9f58@github.com> References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> <4yPDz6UHerf6A-5iCfPR-bJPLKeVKrO5hTqJHPKpS-o=.3439285d-3df6-40fe-a9a7-3171707d9f58@github.com> Message-ID: <6ZORN-EtqByWnt1ndtWFNaR7qIFi5cxlbKOVfGd1mvA=.1ec47a4c-30b4-4185-8fa7-f0fd0e221188@github.com> On Thu, 21 Nov 2024 04:56:52 GMT, Amit Kumar wrote: > I think there is some issue with s390x. With current changes I got build failure: @offamitkumar This definitely looks like something is very broken. The error looks to be happening when the exploded image is being run to build the jmods image. Is that where this is going wrong? It may be that the reorg of the code generation has selected generation of the wrong stub generator method or run the right method using an incorrect parameter. Do you get an hs_err file when the failure happens? If so then a stack trace at the point of crash might well help pin down where the problem lies. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2490801639 From amitkumar at openjdk.org Thu Nov 21 11:11:19 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 21 Nov 2024 11:11:19 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations In-Reply-To: <6ZORN-EtqByWnt1ndtWFNaR7qIFi5cxlbKOVfGd1mvA=.1ec47a4c-30b4-4185-8fa7-f0fd0e221188@github.com> References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> <4yPDz6UHerf6A-5iCfPR-bJPLKeVKrO5hTqJHPKpS-o=.3439285d-3df6-40fe-a9a7-3171707d9f58@github.com> <6ZORN-EtqByWnt1ndtWFNaR7qIFi5cxlbKOVfGd1mvA=.1ec47a4c-30b4-4185-8fa7-f0fd0e221188@github.com> Message-ID: On Thu, 21 Nov 2024 11:00:36 GMT, Andrew Dinn wrote: > > I think there is some issue with s390x. With current changes I got build failure: > > @offamitkumar This definitely looks like something is very broken. The error looks to be happening when the exploded image is being run to build the jmods image. Is that where this is going wrong? > > It may be that the reorg of the code generation has selected generation of the wrong stub generator method or run the right method using an incorrect parameter. Do you get an hs_err file when the failure happens? If so then a stack trace at the point of crash might well help pin down where the problem lies. aah, No I don't get any hs_err file. I looked into `build/linux-s390x-server-fastdebug/make-support/failure-logs` directory and only thing I could I find is last command it ran. /home/amit/jdk/build/linux-s390x-server-fastdebug/jdk/bin/javac -J-Djava.io.tmpdir=/home/amit/jdk/build/linux-s390x-server-fastdebug/support/javatmp -g -Xlint:all -source 24 -target 24 -implicit:none -Xprefer:source -XDignore.symbol.file=true -encoding ascii -Werror --add-modules jdk.compiler,jdk.jdeps --add-exports jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED --add-exports jdk.jdeps/com.sun.tools.classfile=ALL-UNNAMED -Xlint:-options -XDmodifiedInputs=/home/amit/jdk/build/linux-s390x-server-fastdebug/buildtools/create_symbols_javac/_the.COMPILE_CREATE_SYMBOLS_batch.modfiles.fixed -d /home/amit/jdk/build/linux-s390x-server-fastdebug/buildtools/create_symbols_javac @/home/amit/jdk/build/linux-s390x-server-fastdebug/buildtools/create_symbols_javac/_the.COMPILE_CREATE_SYMBOLS_batch.filelist After running I get: Error occurred during initialization of boot layer java.lang.module?????????????????????????????????????????????????????????????????????????????????????????????????????????????? Caused by: jav??????????????????????????????????????????????????????????????????????????????????????????? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2490818503 From bkilambi at openjdk.org Thu Nov 21 11:55:24 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Thu, 21 Nov 2024 11:55:24 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: <28lnx2GvWiVFGMw9LSjjwMSeUPNjvqVGpVVQd_WluGI=.f50647e4-0895-462f-9d12-2050a3368088@github.com> On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja wrote: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 6. Auto-vectorization of newly supported scalar operations. > 7. X86 and AARCH64 backend implementation for all supported intrinsics. > 9. Functional and Performance validation tests. > > **Missing Pieces:-** > **- AARCH64 Backend.** > > Kindly review and share your feedback. > > Best Regards, > Jatin src/hotspot/share/opto/convertnode.cpp line 260: > 258: in(1)->in(1)->Opcode() == Op_ConvHF2F && > 259: in(1)->in(2)->Opcode() == Op_ConvHF2F) { > 260: if (Matcher::match_rule_supported(in(1)->Opcode()) && Here `match_rule_supported()` is being called on floating point IR (AddHF etc) but it should be called on the half float IR (AddHF for ex). Maybe add another routine to return the opcode for half float IR and then check if it's supported? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1851914140 From coleenp at openjdk.org Thu Nov 21 12:02:21 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 21 Nov 2024 12:02:21 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing [v4] In-Reply-To: References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: On Thu, 21 Nov 2024 09:59:06 GMT, Fredrik Bredberg wrote: >> test/hotspot/jtreg/runtime/Monitor/StressWrapper_TestRecursiveLocking_36M.java line 1: >> >>> 1: /* >> >> What does the `36M` signify? Do we really need it? Could we not just call this `StressTestRecursiveLocking`? > > From [JDK-8329351](https://bugs.openjdk.org/browse/JDK-8329351): _"`.../StressWrapper_TestRecursiveLocking_36M.java` is a wrapper that executes `.../TestRecursiveLocking.java` for 2 minutes for each of the 18 configs for a total of 36 minutes of execution time..."_ > > I think there is some value in looking at a test file's name, and thereby know how long it will take to run. > > @dcubed-ojdk created and named the file, maybe he has an opinion. There's precedent for this naming in our internal tests (runthese and kitchensink). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1851925495 From bulasevich at openjdk.org Thu Nov 21 12:18:15 2024 From: bulasevich at openjdk.org (Boris Ulasevich) Date: Thu, 21 Nov 2024 12:18:15 GMT Subject: RFR: 8343978: Update the default value of CodeEntryAlignment for Ampere-1A and 1B In-Reply-To: References: Message-ID: <0VpEw-8l8AnoTWMX1K_IOJfeOkTfih6Nl0RDaxdMA14=.cabf595d-9dae-4e57-9aec-140808a6e610@github.com> On Fri, 15 Nov 2024 07:01:23 GMT, Liming Liu wrote: > This PR updates the default value of CodeEntryAlignment for Ampere-1A and 1B from 64 to 32. The microbenchmark CodeCacheStress shows that frontend stall becomes ~21% smaller by the change, and IPC increases by ~2.8%. The benefits persist after CodeCacheSegmentSize changes from 64 back to 128. > > Ran JTReg tier1 on Ampere-1A and no new issues were found. Cool. I like the updates of rusty default settings is going on. On https://github.com/openjdk/jdk/pull/20864 review comments we see that CodeEntryAlignment=16/32 was not good for AMPERE. Did you check both CPU_MODEL_AMPERE_1A/CPU_MODEL_AMPERE_1B CPUs? Are you sure the performance is good on all CPUs with 1A/1B cpu flag? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22134#issuecomment-2490982607 From adinn at openjdk.org Thu Nov 21 13:22:22 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 21 Nov 2024 13:22:22 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations [v2] In-Reply-To: References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: On Thu, 21 Nov 2024 10:58:34 GMT, Andrew Dinn wrote: >> Implementation of JDK-8343767 > > Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: > > fix comments and remove unused stubid on riscv src/hotspot/cpu/s390/stubGenerator_s390.cpp line 630: > 628: > 629: address generate_lookup_secondary_supers_table_stub(u1 super_klass_index) { > 630: StubGenStubId stub_id = (StubGenStubId)(StubGenStubId::partial_subtype_check_id + super_klass_index); @offamitkumar This is clearly a cut and paste error. The base id for the stub should be lookup_secondary_supers_table_id i.e. the above line should be: StubGenStubId stub_id = (StubGenStubId)(StubGenStubId::lookup_secondary_supers_table_id + super_klass_index); src/hotspot/cpu/s390/stubGenerator_s390.cpp line 1279: > 1277: break; > 1278: case arrayof_jbyte_disjoint_arraycopy_id: > 1279: aligned = false; This is another cut and paste error. The arrayof stubs are aligned so they should have: aligned = true; src/hotspot/cpu/s390/stubGenerator_s390.cpp line 1373: > 1371: break; > 1372: case arrayof_jbyte_arraycopy_id: > 1373: aligned = false; Likewise the same error here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1852045544 PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1852047973 PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1852049094 From adinn at openjdk.org Thu Nov 21 13:30:26 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 21 Nov 2024 13:30:26 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations [v3] In-Reply-To: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: <7o2O0FMZmjVeQ0zBvjiKdomFi9vPrkhRyNhlFPAl9wU=.7cff2993-526d-4992-b40e-d0d4323309b6@github.com> > Implementation of JDK-8343767 Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: fix stub is and align flags for s390 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21957/files - new: https://git.openjdk.org/jdk/pull/21957/files/b0680822..bfdfe015 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=01-02 Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/21957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21957/head:pull/21957 PR: https://git.openjdk.org/jdk/pull/21957 From adinn at openjdk.org Thu Nov 21 13:30:26 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 21 Nov 2024 13:30:26 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations In-Reply-To: References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> <4yPDz6UHerf6A-5iCfPR-bJPLKeVKrO5hTqJHPKpS-o=.3439285d-3df6-40fe-a9a7-3171707d9f58@github.com> <6ZORN-EtqByWnt1ndtWFNaR7qIFi5cxlbKOVfGd1mvA=.1ec47a4c-30b4-4185-8fa7-f0fd0e221188@github.com> Message-ID: On Thu, 21 Nov 2024 11:08:14 GMT, Amit Kumar wrote: >>> I think there is some issue with s390x. With current changes I got build failure: >> >> @offamitkumar This definitely looks like something is very broken. The error looks to be happening when the exploded image is being run to build the jmods image. Is that where this is going wrong? >> >> It may be that the reorg of the code generation has selected generation of the wrong stub generator method or run the right method using an incorrect parameter. Do you get an hs_err file when the failure happens? If so then a stack trace at the point of crash might well help pin down where the problem lies. > >> > I think there is some issue with s390x. With current changes I got build failure: >> >> @offamitkumar This definitely looks like something is very broken. The error looks to be happening when the exploded image is being run to build the jmods image. Is that where this is going wrong? >> >> It may be that the reorg of the code generation has selected generation of the wrong stub generator method or run the right method using an incorrect parameter. Do you get an hs_err file when the failure happens? If so then a stack trace at the point of crash might well help pin down where the problem lies. > > aah, No I don't get any hs_err file. I looked into `build/linux-s390x-server-fastdebug/make-support/failure-logs` directory and only thing I could I find is last command it ran. > > /home/amit/jdk/build/linux-s390x-server-fastdebug/jdk/bin/javac -J-Djava.io.tmpdir=/home/amit/jdk/build/linux-s390x-server-fastdebug/support/javatmp -g -Xlint:all -source 24 -target 24 -implicit:none -Xprefer:source -XDignore.symbol.file=true -encoding ascii -Werror --add-modules jdk.compiler,jdk.jdeps --add-exports jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED --add-exports jdk.jdeps/com.sun.tools.classfile=ALL-UNNAMED -Xlint:-options -XDmodifiedInputs=/home/amit/jdk/build/linux-s390x-server-fastdebug/buildtools/create_symbols_javac/_the.COMPILE_CREATE_SYMBOLS_batch.modfiles.fixed -d /home/amit/jdk/build/linux-s390x-server-fastdebug/buildtools/create_symbols_javac @/home/amit/jdk/build/linux-s390x-server-fastdebug/buildtools/create_symbols_javac/_the.COMPILE_CREATE_SYMBOLS_batch.filelist > > > After running I get: > > Error occurred during initialization of boot layer > java.lang.module?????????????????????????????????????????????????????????????????????????????????????????????????????????????? > Caused by: jav??????????????????????????????????????????????????????????????????????????????????????????? @offamitkumar I think the latest version should address the crash and also address the alignment issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2491149661 From adinn at openjdk.org Thu Nov 21 13:30:28 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 21 Nov 2024 13:30:28 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations [v2] In-Reply-To: References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: On Thu, 21 Nov 2024 13:16:40 GMT, Andrew Dinn wrote: >> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: >> >> fix comments and remove unused stubid on riscv > > src/hotspot/cpu/s390/stubGenerator_s390.cpp line 630: > >> 628: >> 629: address generate_lookup_secondary_supers_table_stub(u1 super_klass_index) { >> 630: StubGenStubId stub_id = (StubGenStubId)(StubGenStubId::partial_subtype_check_id + super_klass_index); > > @offamitkumar This is clearly a cut and paste error. The base id for the stub should be lookup_secondary_supers_table_id i.e. the above line should be: > > StubGenStubId stub_id = (StubGenStubId)(StubGenStubId::lookup_secondary_supers_table_id + super_klass_index); Fixed in latest push. > src/hotspot/cpu/s390/stubGenerator_s390.cpp line 1279: > >> 1277: break; >> 1278: case arrayof_jbyte_disjoint_arraycopy_id: >> 1279: aligned = false; > > This is another cut and paste error. The arrayof stubs are aligned so they should have: > aligned = true; Fixed in latest push > src/hotspot/cpu/s390/stubGenerator_s390.cpp line 1373: > >> 1371: break; >> 1372: case arrayof_jbyte_arraycopy_id: >> 1373: aligned = false; > > Likewise the same error here. Fixed in latest push ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1852058617 PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1852058895 PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1852058977 From coleenp at openjdk.org Thu Nov 21 13:34:54 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 21 Nov 2024 13:34:54 GMT Subject: RFR: 8340212: -Xshare:off -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64 [v4] In-Reply-To: References: Message-ID: > Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64. This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated. > > Tested with tier1-7. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Merge with incoming change for PR https://github.com/openjdk/jdk/pull/21932 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21695/files - new: https://git.openjdk.org/jdk/pull/21695/files/550e7344..f2d84ae3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21695&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21695&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21695.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21695/head:pull/21695 PR: https://git.openjdk.org/jdk/pull/21695 From shade at openjdk.org Thu Nov 21 13:57:46 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 21 Nov 2024 13:57:46 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> On Thu, 21 Nov 2024 00:59:27 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 524 commits: > > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - 8344670: GenShen: Use concurrent worker session for concurrent mark phase > > Reviewed-by: kdnilsen > - 8344640: GenShen: Reuse existing card mark barrier function when dropping references > > Reviewed-by: shade, ysr > - 8344592: GenShen: Remove unnecessary comments and changes > > Reviewed-by: kdnilsen > - 8344263: GenShen: Reduce extraneous log messages at INFO level > > Reviewed-by: ysr, shade > - 8344638: GenShen: Verifier should not touch claim token > > Reviewed-by: shade > - Merge > - 8344320: GenShen: Possible null pointer usage in shGenerationalHeap > > Reviewed-by: wkemper, ysr > - 8344321: GenShen: Fix various sonar scan warnings > > Reviewed-by: kdnilsen, shade > - 8344264: GenShen: Improve comments and method names > > Reviewed-by: shade > - ... and 514 more: https://git.openjdk.org/jdk/compare/95a00f8a...7ab16403 229/229 files read! This is an impressive, monumental piece of work, kudos. More comments from this read follow. I am going to circle back to some open threads in this PR. I am also running local tests, and in my ad-hoc performance tests generational mode performs admirably well. src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 881: > 879: // update costs on slow path. > 880: monitoring_support()->notify_heap_changed(); > 881: _heap_changed.set(); Why not leave `try_set` intact? This alleviates contention on the shared counter, AFAICS. src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1972: > 1970: // Check that if concurrent weak root is set then active_gen isn't null > 1971: assert(!is_concurrent_weak_root_in_progress() || active_generation() != nullptr, "Error"); > 1972: shenandoah_assert_generations_reconciled(); Why all of this is checked here? I would have thought `gc_state` machinery should only check things related to gc-state. src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 134: > 132: bool is_thread_safe() override { return true; } > 133: }; > 134: This looks like belonging in one of the `*closures.hpp` header. src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 514: > 512: > 513: public: > 514: ShenandoahController* control_thread() { return _control_thread; } This method and field is probably `controller` then, right? src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 663: > 661: // ---------- CDS archive support > 662: > 663: bool can_load_archived_objects() const override { return !ShenandoahCardBarrier; } This means CDS heap loading is not yet working with generational Shenandoah? This looks OK for the experimental code. Please submit a bug for this and assign it to me. I will take a look at it some time later. src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 754: > 752: oop try_evacuate_object(oop src, Thread* thread, ShenandoahHeapRegion* from_region, ShenandoahAffiliation target_gen); > 753: public: > 754: I think this new line should be before `public:` src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp line 64: > 62: } > 63: } > 64: return _mark_bit_map.is_bitmap_clear_range(start, end); Comprehension check: this seems to bail out the moment it discovers an uncommitted slice. Does it really happen? More worryingly, if there is a mix of committed and uncommitted chunks, this method returns `true`, even if committed chunks are not actually clean? ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2450709063 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852054187 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852075850 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1851646208 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1851763351 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1851761345 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1851765188 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852139996 From rehn at openjdk.org Thu Nov 21 14:01:28 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 21 Nov 2024 14:01:28 GMT Subject: RFR: 8344382: RISC-V: CASandCAEwithNegExpected fails with Zacas Message-ID: Hi, please consider. There are two issues with narrow amocas: - weak_cmpxchg_narrow_value don't load from aligned address. - cmpxchg_narrow_value compared new to loaded value, not to expected value. This addresses these two issues and makes some minor cleanups by: - Weak and strong are now identical for easier debugging (and in feature code sharing). - t1 was set by cmpxchg_narrow_value but not passed. - To free up a register, not_mask is now a scratch registers. Hence thus if amocas fails we need to re-create not mask. - Subjective change: a register containing temporary value is best named scratch, as the register it self is not temporary. Same as other PR, here be dragons. But with a working baseline we can start improving this code. Passes test/hotspot/jtreg/compiler/unsafe/ with +/-UseZacas. And I'm running tier1 +/-UseZacas (I'll run tests over the weekend). Thanks, Robbin ------------- Commit messages: - Init Changes: https://git.openjdk.org/jdk/pull/22293/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22293&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344382 Stats: 81 lines in 2 files changed: 29 ins; 13 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/22293.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22293/head:pull/22293 PR: https://git.openjdk.org/jdk/pull/22293 From amitkumar at openjdk.org Thu Nov 21 14:04:20 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 21 Nov 2024 14:04:20 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations In-Reply-To: References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> <4yPDz6UHerf6A-5iCfPR-bJPLKeVKrO5hTqJHPKpS-o=.3439285d-3df6-40fe-a9a7-3171707d9f58@github.com> <6ZORN-EtqByWnt1ndtWFNaR7qIFi5cxlbKOVfGd1mvA=.1ec47a4c-30b4-4185-8fa7-f0fd0e221188@github.com> Message-ID: On Thu, 21 Nov 2024 11:08:14 GMT, Amit Kumar wrote: >>> I think there is some issue with s390x. With current changes I got build failure: >> >> @offamitkumar This definitely looks like something is very broken. The error looks to be happening when the exploded image is being run to build the jmods image. Is that where this is going wrong? >> >> It may be that the reorg of the code generation has selected generation of the wrong stub generator method or run the right method using an incorrect parameter. Do you get an hs_err file when the failure happens? If so then a stack trace at the point of crash might well help pin down where the problem lies. > >> > I think there is some issue with s390x. With current changes I got build failure: >> >> @offamitkumar This definitely looks like something is very broken. The error looks to be happening when the exploded image is being run to build the jmods image. Is that where this is going wrong? >> >> It may be that the reorg of the code generation has selected generation of the wrong stub generator method or run the right method using an incorrect parameter. Do you get an hs_err file when the failure happens? If so then a stack trace at the point of crash might well help pin down where the problem lies. > > aah, No I don't get any hs_err file. I looked into `build/linux-s390x-server-fastdebug/make-support/failure-logs` directory and only thing I could I find is last command it ran. > > /home/amit/jdk/build/linux-s390x-server-fastdebug/jdk/bin/javac -J-Djava.io.tmpdir=/home/amit/jdk/build/linux-s390x-server-fastdebug/support/javatmp -g -Xlint:all -source 24 -target 24 -implicit:none -Xprefer:source -XDignore.symbol.file=true -encoding ascii -Werror --add-modules jdk.compiler,jdk.jdeps --add-exports jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED --add-exports jdk.jdeps/com.sun.tools.classfile=ALL-UNNAMED -Xlint:-options -XDmodifiedInputs=/home/amit/jdk/build/linux-s390x-server-fastdebug/buildtools/create_symbols_javac/_the.COMPILE_CREATE_SYMBOLS_batch.modfiles.fixed -d /home/amit/jdk/build/linux-s390x-server-fastdebug/buildtools/create_symbols_javac @/home/amit/jdk/build/linux-s390x-server-fastdebug/buildtools/create_symbols_javac/_the.COMPILE_CREATE_SYMBOLS_batch.filelist > > > After running I get: > > Error occurred during initialization of boot layer > java.lang.module?????????????????????????????????????????????????????????????????????????????????????????????????????????????? > Caused by: jav??????????????????????????????????????????????????????????????????????????????????????????? > @offamitkumar I think the latest version should address the crash and also address the alignment issues. Unfortunately, nope. I am still getting the same error, with no hs_err files at all. Compiling up to 4 files for COMPILE_CREATE_SYMBOLS Error occurred during initialization of boot layer java.lang.module.?????????????????????????????????????????????????????????????????????????????????????????????????????????????????? Caused by: jav????????????????????????????????????????????????????????????????????????????????????????????????? gmake[3]: *** [Gendata.gmk:64: /home/amit/jdk/build/linux-s390x-server-fastdebug/buildtools/create_symbols_javac/_the.COMPILE_CREATE_SYMBOLS_batch] Error 1 gmake[2]: *** [make/Main.gmk:139: jdk.compiler-gendata] Error 2 gmake[2]: *** Waiting for unfinished jobs.... ERROR: Build failed for target 'images' in configuration 'linux-s390x-server-fastdebug' (exit code 2) Stopping javac server === Output from failing command(s) repeated here === * For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch: Error occurred during initialization of boot layer java.lang.module.?????????????????????????????????????????????????????????????????????????????????????????????????????????????????? Caused by: jav????????????????????????????????????????????????????????????????????????????????????????????????? * All command lines available in /home/amit/jdk/build/linux-s390x-server-fastdebug/make-support/failure-logs. === End of repeated output === No indication of failed target found. HELP: Try searching the build log for '] Error'. HELP: Run 'make doctor' to diagnose build problems. make[1]: *** [/home/amit/jdk/make/Init.gmk:323: main] Error 2 make: *** [/home/amit/jdk/make/Init.gmk:189: images] Error 2 amit at t8360021:~/jdk$ ------------- PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2491284664 From lmesnik at openjdk.org Thu Nov 21 16:11:45 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Nov 2024 16:11:45 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v12] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: <5aVuHszNeKs5mD74oHjzeVd2raM5dFuPdmmnx4N5ed4=.3dca242b-7667-4a0b-971e-dfa5a1ec9e22@github.com> > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: - Update src/hotspot/share/runtime/mutex.hpp Co-authored-by: Stefan Karlsson - Update src/hotspot/share/runtime/mutex.cpp Co-authored-by: Stefan Karlsson ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/39b374f3..dae3d86d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=10-11 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From lmesnik at openjdk.org Thu Nov 21 16:19:04 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Nov 2024 16:19:04 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v13] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: <40aXhGIn_ZSESqN69PsemM4BKC1MYgH5qso09BExFJY=.398b0609-23e6-4771-9c08-ac97cb500e1a@github.com> > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fixed decl ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/dae3d86d..e0290f7a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=11-12 Stats: 11 lines in 1 file changed: 6 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From adinn at openjdk.org Thu Nov 21 16:24:18 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 21 Nov 2024 16:24:18 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations In-Reply-To: References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> <4yPDz6UHerf6A-5iCfPR-bJPLKeVKrO5hTqJHPKpS-o=.3439285d-3df6-40fe-a9a7-3171707d9f58@github.com> <6ZORN-EtqByWnt1ndtWFNaR7qIFi5cxlbKOVfGd1mvA=.1ec47a4c-30b4-4185-8fa7-f0fd0e221188@github.com> Message-ID: <8Usrl9_NyxpFmQCxloBSoaYjhoMxQbO-X0yqw5Eq0qk=.7293c225-9f9d-418f-acea-b755cd5674a1@github.com> On Thu, 21 Nov 2024 14:01:26 GMT, Amit Kumar wrote: > Unfortunately, nope. I am still getting the same error, with no hs_err files at all. This is happening under System.initPhase2 where it calls ModuleBootstrap.boot(). I am debugging to see where it is going wrong. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2491691535 From gziemski at openjdk.org Thu Nov 21 16:42:30 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 21 Nov 2024 16:42:30 GMT Subject: RFR: 8328944: NMT reports "unknown" memory [v2] In-Reply-To: References: <6Up1fGCFJl2HAUGl6IBKEDRodItQLn5TigHJEdzZpbU=.5f5ae17c-edc4-4dd8-ae09-8e8ae8567354@github.com> Message-ID: On Wed, 20 Nov 2024 09:58:02 GMT, Afshin Zafari wrote: >> Gerard Ziemski 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: >> >> - avoid using mtNone >> - Merge remote-tracking branch 'upstream/master' into JDK-8328944 >> - revert, we will re-do with a smaller change >> - remove more mtNone >> - remove API that allows to change the mem_tag for virtual memory, feedback >> - do not allow default parameter for mtNone > > src/hotspot/os/bsd/gc/z/zPhysicalMemoryBacking_bsd.cpp line 1: > >> 1: /* > > Copyright year to be updated. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1852490749 From adinn at openjdk.org Thu Nov 21 16:54:22 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 21 Nov 2024 16:54:22 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations [v3] In-Reply-To: <7o2O0FMZmjVeQ0zBvjiKdomFi9vPrkhRyNhlFPAl9wU=.7cff2993-526d-4992-b40e-d0d4323309b6@github.com> References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> <7o2O0FMZmjVeQ0zBvjiKdomFi9vPrkhRyNhlFPAl9wU=.7cff2993-526d-4992-b40e-d0d4323309b6@github.com> Message-ID: On Thu, 21 Nov 2024 13:30:26 GMT, Andrew Dinn wrote: >> Implementation of JDK-8343767 > > Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: > > fix stub is and align flags for s390 src/hotspot/cpu/s390/stubGenerator_s390.cpp line 1284: > 1282: case jshort_disjoint_arraycopy_id: > 1283: aligned = false; > 1284: element_size = 1; @offamitkumar The problem looked like a format error when building the jmods which suggests a memory copying failure and here it is. The element sizes are wrong for the non-byte cases here, also in conjoint_nonoop_copy. I'm just rebuilding with the sizes corrected. I'll push a patch if this fixes the problem. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1852511923 From shade at openjdk.org Thu Nov 21 17:02:37 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 21 Nov 2024 17:02:37 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Sat, 16 Nov 2024 17:54:01 GMT, Kelvin Nilsen wrote: >> I think it's here for the same reason `propagate_gc_state_to_java_threads` is here. Having it here makes it easier to see that this critical synchronization step happens for every safepoint. > > I'm inclined to leave as is, not wanting to disrupt stability of code that is known to be working. But if there is strong preference otherwise, we can make a change... OK, but file a bug for it to clean up. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852524191 From liach at openjdk.org Thu Nov 21 17:03:23 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 21 Nov 2024 17:03:23 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v2] In-Reply-To: <-ItmDmV4oovdAbnojC5s4h3JIKozNKHIMm4SwilR_BE=.9dfbdca7-c435-4c1a-88d6-cd6425bacfb3@github.com> References: <-ItmDmV4oovdAbnojC5s4h3JIKozNKHIMm4SwilR_BE=.9dfbdca7-c435-4c1a-88d6-cd6425bacfb3@github.com> Message-ID: On Thu, 21 Nov 2024 06:10:29 GMT, David Holmes wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> updated testcase > > test/hotspot/jtreg/runtime/cds/appcds/jvmti/CFLH/MultiReleaseJars.java line 48: > >> 46: static final String MAJOR_VERSION_STRING = String.valueOf(MAJOR_VERSION); >> 47: >> 48: static String[] getMain() { > > Can't you just define these as source files in the test directory rather than creating them dynamically? I think the concern may be that we want to avoid license headers. However, we should still use text blocks instead of these string arrays for such inlined source files. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22262#discussion_r1852528008 From shade at openjdk.org Thu Nov 21 17:05:44 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 21 Nov 2024 17:05:44 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: <8p63u9MBsujLClN-XXtWMs5OOIUKV4E-foooFIqdyYA=.442aee6c-8733-488e-a050-1c2459d30631@github.com> On Tue, 19 Nov 2024 19:54:45 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 276: >> >>> 274: log_info(gc)("GC cancellation took %.3fs", cancel_time); >>> 275: _cancel_requested_time = 0; >>> 276: } >> >> Do we need this? Is this useful? > > We could log this at debug? I believe it is useful because this time (currently) is not accounted for in the heuristic's notion of 'cycle time'. Yeah, `gc=debug` would be okay for this. >> src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp line 193: >> >>> 191: Phase phase = Phase(pi); >>> 192: if (is_worker_phase(phase)) { >>> 193: double sum = uninitialized(); >> >> I think you can avoid changing this method to limit the churn. > > Hmm, I find the version in the PR much more readable. How about we upstream these changes separately? Yes, let's do that, if you have cycles. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852533117 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852533548 From adinn at openjdk.org Thu Nov 21 17:06:32 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 21 Nov 2024 17:06:32 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations [v4] In-Reply-To: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: <3kCuWfUHmAISyXz2-NPHFke5oLe40_37Rr9Pugm5v7E=.1f9906ba-1c3c-42fb-bf0a-9a4d62331f88@github.com> > Implementation of JDK-8343767 Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: fix element sizes in s390 copy routines ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21957/files - new: https://git.openjdk.org/jdk/pull/21957/files/bfdfe015..0f8eb111 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=02-03 Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/21957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21957/head:pull/21957 PR: https://git.openjdk.org/jdk/pull/21957 From adinn at openjdk.org Thu Nov 21 17:06:32 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 21 Nov 2024 17:06:32 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations In-Reply-To: References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> <4yPDz6UHerf6A-5iCfPR-bJPLKeVKrO5hTqJHPKpS-o=.3439285d-3df6-40fe-a9a7-3171707d9f58@github.com> <6ZORN-EtqByWnt1ndtWFNaR7qIFi5cxlbKOVfGd1mvA=.1ec47a4c-30b4-4185-8fa7-f0fd0e221188@github.com> Message-ID: <_X_V8HOoCTAOJ5aIitRfFLbRP0N_3upzZfSSlU5NshM=.e7836479-7403-4482-8956-87b7bda2e136@github.com> On Thu, 21 Nov 2024 14:01:26 GMT, Amit Kumar wrote: >>> > I think there is some issue with s390x. With current changes I got build failure: >>> >>> @offamitkumar This definitely looks like something is very broken. The error looks to be happening when the exploded image is being run to build the jmods image. Is that where this is going wrong? >>> >>> It may be that the reorg of the code generation has selected generation of the wrong stub generator method or run the right method using an incorrect parameter. Do you get an hs_err file when the failure happens? If so then a stack trace at the point of crash might well help pin down where the problem lies. >> >> aah, No I don't get any hs_err file. I looked into `build/linux-s390x-server-fastdebug/make-support/failure-logs` directory and only thing I could I find is last command it ran. >> >> /home/amit/jdk/build/linux-s390x-server-fastdebug/jdk/bin/javac -J-Djava.io.tmpdir=/home/amit/jdk/build/linux-s390x-server-fastdebug/support/javatmp -g -Xlint:all -source 24 -target 24 -implicit:none -Xprefer:source -XDignore.symbol.file=true -encoding ascii -Werror --add-modules jdk.compiler,jdk.jdeps --add-exports jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED --add-exports jdk.compiler/com.sun.tools.javac.jvm=ALL-UNNAMED --add-exports jdk.jdeps/com.sun.tools.classfile=ALL-UNNAMED -Xlint:-options -XDmodifiedInputs=/home/amit/jdk/build/linux-s390x-server-fastdebug/buildtools/create_symbols_javac/_the.COMPILE_CREATE_SYMBOLS_batch.modfiles.fixed -d /home/amit/jdk/build/linux-s390x-server-fastdebug/buildtools/create_symbols_javac @/home/amit/jdk/build/linux-s390x-server-fastdebug/buildtools/create_symbols_javac/_the.COMPILE_CREATE_SYMBOLS_batch.filelist >> >> >> After running I get: >> >> Error occurred during initialization of boot layer >> java.lang.module?????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> Caused by: jav??????????????????????????????????????????????????????????????????????????????????????????? > >> @offamitkumar I think the latest version should address the crash and also address the alignment issues. > > Unfortunately, nope. I am still getting the same error, with no hs_err files at all. > > Compiling up to 4 files for COMPILE_CREATE_SYMBOLS > Error occurred during initialization of boot layer > java.lang.module.?????????????????????????????????????????????????????????????????????????????????????????????????????????????????? > Caused by: jav????????????????????????????????????????????????????????????????????????????????????????????????? > gmake[3]: *** [Gendata.gmk:64: /home/amit/jdk/build/linux-s390x-server-fastdebug/buildtools/create_symbols_javac/_the.COMPILE_CREATE_SYMBOLS_batch] Error 1 > gmake[2]: *** [make/Main.gmk:139: jdk.compiler-gendata] Error 2 > gmake[2]: *** Waiting for unfinished jobs.... > > ERROR: Build failed for target 'images' in configuration 'linux-s390x-server-fastdebug' (exit code 2) > Stopping javac server > > === Output from failing command(s) repeated here === > * For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch: > Error occurred during initialization of boot layer > java.lang.module.?????????????????????????????????????????????????????????????????????????????????????????????????????????????????? > Caused by: jav????????????????????????????????????????????????????????????????????????????????????????????????? > > * All command lines available in /home/amit/jdk/build/linux-s390x-server-fastdebug/make-support/failure-logs. > === End of repeated output === > > No indication of failed target found. > HELP: Try searching the build log for '] Error'. > HELP: Run 'make doctor' to diagnose build problems. > > make[1]: *** [/home/amit/jdk/make/Init.gmk:323: main] Error 2 > make: *** [/home/amit/jdk/make/Init.gmk:189: images] Error 2 > amit at t8360021:~/jdk$ @offamitkumar I have managed to build a full image now so I think the problem has been fixed. Could you please try to build and run tests. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2491791150 From adinn at openjdk.org Thu Nov 21 17:06:33 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 21 Nov 2024 17:06:33 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations [v3] In-Reply-To: References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> <7o2O0FMZmjVeQ0zBvjiKdomFi9vPrkhRyNhlFPAl9wU=.7cff2993-526d-4992-b40e-d0d4323309b6@github.com> Message-ID: On Thu, 21 Nov 2024 16:52:06 GMT, Andrew Dinn wrote: >> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: >> >> fix stub is and align flags for s390 > > src/hotspot/cpu/s390/stubGenerator_s390.cpp line 1284: > >> 1282: case jshort_disjoint_arraycopy_id: >> 1283: aligned = false; >> 1284: element_size = 1; > > @offamitkumar The problem looked like a format error when building the jmods which suggests a memory copying failure and here it is. The element sizes are wrong for the non-byte cases here, also in conjoint_nonoop_copy. > > I'm just rebuilding with the sizes corrected. I'll push a patch if this fixes the problem. Well, that seems to have done the trick! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1852527568 From gziemski at openjdk.org Thu Nov 21 17:22:55 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 21 Nov 2024 17:22:55 GMT Subject: RFR: 8328944: NMT reports "unknown" memory [v3] In-Reply-To: References: Message-ID: > We use `mtNone` value in several functions default parameters, which may show up in NMT reports. > > We address this, by avoiding using `mtNone`. > > This fix only addresses the cases covered by the issue. I am not trying to replace every single `mtNone` here, but eventually the goal would be to do just that. > > TODO: update copyrights. > > Testing: undergoing MARCH5 tier1-5 ... Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: copyright update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21843/files - new: https://git.openjdk.org/jdk/pull/21843/files/33dbafdc..62a98865 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21843&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21843&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21843.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21843/head:pull/21843 PR: https://git.openjdk.org/jdk/pull/21843 From coleenp at openjdk.org Thu Nov 21 17:36:34 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 21 Nov 2024 17:36:34 GMT Subject: RFR: 8344763: cpCache print_on doesn't handle nulls Message-ID: A change to remove some more security manager code, resulted in java.lang.System not having any more indy instructions so the gtest test_cpCache_output.cpp was crashing because of missing null checks. Please review this trivial change to add in null checks. The test doesn't verify that there are indys so doesn't need to be fixed. Tested with gtest and upcoming security manager change. ------------- Commit messages: - 8344763: cpCache print_on doesn't handle nulls Changes: https://git.openjdk.org/jdk/pull/22298/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22298&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344763 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22298.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22298/head:pull/22298 PR: https://git.openjdk.org/jdk/pull/22298 From matsaave at openjdk.org Thu Nov 21 17:36:34 2024 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 21 Nov 2024 17:36:34 GMT Subject: RFR: 8344763: cpCache print_on doesn't handle nulls In-Reply-To: References: Message-ID: On Thu, 21 Nov 2024 17:30:53 GMT, Coleen Phillimore wrote: > A change to remove some more security manager code, resulted in java.lang.System not having any more indy instructions so the gtest test_cpCache_output.cpp was crashing because of missing null checks. Please review this trivial change to add in null checks. The test doesn't verify that there are indys so doesn't need to be fixed. > > Tested with gtest and upcoming security manager change. Looks good, thanks! ------------- Marked as reviewed by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22298#pullrequestreview-2452194704 From amitkumar at openjdk.org Thu Nov 21 17:39:19 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 21 Nov 2024 17:39:19 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations In-Reply-To: <_X_V8HOoCTAOJ5aIitRfFLbRP0N_3upzZfSSlU5NshM=.e7836479-7403-4482-8956-87b7bda2e136@github.com> References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> <4yPDz6UHerf6A-5iCfPR-bJPLKeVKrO5hTqJHPKpS-o=.3439285d-3df6-40fe-a9a7-3171707d9f58@github.com> <6ZORN-EtqByWnt1ndtWFNaR7qIFi5cxlbKOVfGd1mvA=.1ec47a4c-30b4-4185-8fa7-f0fd0e221188@github.com> <_X_V8HOoCTAOJ5aIitRfFLbRP0N_3upzZfSSlU5NshM=.e7836479-7403-4482-8956-87b7bda2e136@github.com> Message-ID: On Thu, 21 Nov 2024 17:02:22 GMT, Andrew Dinn wrote: >>> @offamitkumar I think the latest version should address the crash and also address the alignment issues. >> >> Unfortunately, nope. I am still getting the same error, with no hs_err files at all. >> >> Compiling up to 4 files for COMPILE_CREATE_SYMBOLS >> Error occurred during initialization of boot layer >> java.lang.module.?????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> Caused by: jav????????????????????????????????????????????????????????????????????????????????????????????????? >> gmake[3]: *** [Gendata.gmk:64: /home/amit/jdk/build/linux-s390x-server-fastdebug/buildtools/create_symbols_javac/_the.COMPILE_CREATE_SYMBOLS_batch] Error 1 >> gmake[2]: *** [make/Main.gmk:139: jdk.compiler-gendata] Error 2 >> gmake[2]: *** Waiting for unfinished jobs.... >> >> ERROR: Build failed for target 'images' in configuration 'linux-s390x-server-fastdebug' (exit code 2) >> Stopping javac server >> >> === Output from failing command(s) repeated here === >> * For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch: >> Error occurred during initialization of boot layer >> java.lang.module.?????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> Caused by: jav????????????????????????????????????????????????????????????????????????????????????????????????? >> >> * All command lines available in /home/amit/jdk/build/linux-s390x-server-fastdebug/make-support/failure-logs. >> === End of repeated output === >> >> No indication of failed target found. >> HELP: Try searching the build log for '] Error'. >> HELP: Run 'make doctor' to diagnose build problems. >> >> make[1]: *** [/home/amit/jdk/make/Init.gmk:323: main] Error 2 >> make: *** [/home/amit/jdk/make/Init.gmk:189: images] Error 2 >> amit at t8360021:~/jdk$ > > @offamitkumar I have managed to build a full image now so I think the problem has been fixed. Could you please try to build and run tests. Thanks! @adinn can we merge master branch changes here ? It would make easy running test if we can get changes from https://github.com/openjdk/jdk/pull/22197 :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2491867164 From adinn at openjdk.org Thu Nov 21 17:46:28 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 21 Nov 2024 17:46:28 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations In-Reply-To: <_X_V8HOoCTAOJ5aIitRfFLbRP0N_3upzZfSSlU5NshM=.e7836479-7403-4482-8956-87b7bda2e136@github.com> References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> <4yPDz6UHerf6A-5iCfPR-bJPLKeVKrO5hTqJHPKpS-o=.3439285d-3df6-40fe-a9a7-3171707d9f58@github.com> <6ZORN-EtqByWnt1ndtWFNaR7qIFi5cxlbKOVfGd1mvA=.1ec47a4c-30b4-4185-8fa7-f0fd0e221188@github.com> <_X_V8HOoCTAOJ5aIitRfFLbRP0N_3upzZfSSlU5NshM=.e7836479-7403-4482-8956-87b7bda2e136@github.com> Message-ID: On Thu, 21 Nov 2024 17:02:22 GMT, Andrew Dinn wrote: >>> @offamitkumar I think the latest version should address the crash and also address the alignment issues. >> >> Unfortunately, nope. I am still getting the same error, with no hs_err files at all. >> >> Compiling up to 4 files for COMPILE_CREATE_SYMBOLS >> Error occurred during initialization of boot layer >> java.lang.module.?????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> Caused by: jav????????????????????????????????????????????????????????????????????????????????????????????????? >> gmake[3]: *** [Gendata.gmk:64: /home/amit/jdk/build/linux-s390x-server-fastdebug/buildtools/create_symbols_javac/_the.COMPILE_CREATE_SYMBOLS_batch] Error 1 >> gmake[2]: *** [make/Main.gmk:139: jdk.compiler-gendata] Error 2 >> gmake[2]: *** Waiting for unfinished jobs.... >> >> ERROR: Build failed for target 'images' in configuration 'linux-s390x-server-fastdebug' (exit code 2) >> Stopping javac server >> >> === Output from failing command(s) repeated here === >> * For target buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch: >> Error occurred during initialization of boot layer >> java.lang.module.?????????????????????????????????????????????????????????????????????????????????????????????????????????????????? >> Caused by: jav????????????????????????????????????????????????????????????????????????????????????????????????? >> >> * All command lines available in /home/amit/jdk/build/linux-s390x-server-fastdebug/make-support/failure-logs. >> === End of repeated output === >> >> No indication of failed target found. >> HELP: Try searching the build log for '] Error'. >> HELP: Run 'make doctor' to diagnose build problems. >> >> make[1]: *** [/home/amit/jdk/make/Init.gmk:323: main] Error 2 >> make: *** [/home/amit/jdk/make/Init.gmk:189: images] Error 2 >> amit at t8360021:~/jdk$ > > @offamitkumar I have managed to build a full image now so I think the problem has been fixed. Could you please try to build and run tests. Thanks! > @adinn can we merge master branch changes here ? It would make easy running test if we can get changes from https://github.com/openjdk/jdk/pull/22197 :-) Sure, I'm happy to merge. However, I'm not sure I'll be able to get it done until Monday. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2491876879 From amitkumar at openjdk.org Thu Nov 21 17:46:29 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 21 Nov 2024 17:46:29 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations In-Reply-To: References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> <4yPDz6UHerf6A-5iCfPR-bJPLKeVKrO5hTqJHPKpS-o=.3439285d-3df6-40fe-a9a7-3171707d9f58@github.com> <6ZORN-EtqByWnt1ndtWFNaR7qIFi5cxlbKOVfGd1mvA=.1ec47a4c-30b4-4185-8fa7-f0fd0e221188@github.com> <_X_V8HOoCTAOJ5aIitRfFLbRP0N_3upzZfSSlU5NshM=.e7836479-7403-4482-8956-87b7bda2e136@github.com> Message-ID: On Thu, 21 Nov 2024 17:41:02 GMT, Andrew Dinn wrote: >> @offamitkumar I have managed to build a full image now so I think the problem has been fixed. Could you please try to build and run tests. Thanks! > >> @adinn can we merge master branch changes here ? It would make easy running test if we can get changes from https://github.com/openjdk/jdk/pull/22197 :-) > > Sure, I'm happy to merge. However, I'm not sure I'll be able to get it done until Monday. > > @adinn can we merge master branch changes here ? It would make easy running test if we can get changes from #22197 :-) > > Sure, I'm happy to merge. However, I'm not sure I'll be able to get it done until Monday. No issues, then I will do it on my branch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2491880829 From adinn at openjdk.org Thu Nov 21 17:50:57 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 21 Nov 2024 17:50:57 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations [v5] In-Reply-To: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: > Implementation of JDK-8343767 Andrew Dinn 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 55 additional commits since the last revision: - Merge branch 'master' into iterate_stubs - fix element sizes in s390 copy routines - fix stub is and align flags for s390 - fix comments and remove unused stubid on riscv - locate super lookup stubs in same blob for all arches - do verification under ifdef ASSERT - fix yet more problems with s390 stubs - better error notification - fix more problems with s390 stubs - Verify stubs are generated in correct blob - ... and 45 more: https://git.openjdk.org/jdk/compare/b619c954...e21268c4 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21957/files - new: https://git.openjdk.org/jdk/pull/21957/files/0f8eb111..e21268c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=03-04 Stats: 13209 lines in 505 files changed: 5122 ins; 5639 del; 2448 mod Patch: https://git.openjdk.org/jdk/pull/21957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21957/head:pull/21957 PR: https://git.openjdk.org/jdk/pull/21957 From adinn at openjdk.org Thu Nov 21 17:50:58 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 21 Nov 2024 17:50:58 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations In-Reply-To: References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> <4yPDz6UHerf6A-5iCfPR-bJPLKeVKrO5hTqJHPKpS-o=.3439285d-3df6-40fe-a9a7-3171707d9f58@github.com> <6ZORN-EtqByWnt1ndtWFNaR7qIFi5cxlbKOVfGd1mvA=.1ec47a4c-30b4-4185-8fa7-f0fd0e221188@github.com> <_X_V8HOoCTAOJ5aIitRfFLbRP0N_3upzZfSSlU5NshM=.e7836479-7403-4482-8956-87b7bda2e136@github.com> Message-ID: On Thu, 21 Nov 2024 17:43:00 GMT, Amit Kumar wrote: >>> @adinn can we merge master branch changes here ? It would make easy running test if we can get changes from https://github.com/openjdk/jdk/pull/22197 :-) >> >> Sure, I'm happy to merge. However, I'm not sure I'll be able to get it done until Monday. > >> > @adinn can we merge master branch changes here ? It would make easy running test if we can get changes from #22197 :-) >> >> Sure, I'm happy to merge. However, I'm not sure I'll be able to get it done until Monday. > > No issues, then I will do it on my branch. @offamitkumar Actually I just checked and it's a really uncontentious merge. So, I'll push now ------------- PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2491889258 From gziemski at openjdk.org Thu Nov 21 18:04:40 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 21 Nov 2024 18:04:40 GMT Subject: RFR: 8328944: NMT reports "unknown" memory [v2] In-Reply-To: <7UxSMg_or6Avy_wuFlkkuDO0pBpyR5DiKeuY0N4uhVs=.d2c7835f-6e68-4f87-857a-e4fd6eb5f12b@github.com> References: <6Up1fGCFJl2HAUGl6IBKEDRodItQLn5TigHJEdzZpbU=.5f5ae17c-edc4-4dd8-ae09-8e8ae8567354@github.com> <7UxSMg_or6Avy_wuFlkkuDO0pBpyR5DiKeuY0N4uhVs=.d2c7835f-6e68-4f87-857a-e4fd6eb5f12b@github.com> Message-ID: On Wed, 20 Nov 2024 15:34:42 GMT, Stefan Karlsson wrote: >> Gerard Ziemski 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: >> >> - avoid using mtNone >> - Merge remote-tracking branch 'upstream/master' into JDK-8328944 >> - revert, we will re-do with a smaller change >> - remove more mtNone >> - remove API that allows to change the mem_tag for virtual memory, feedback >> - do not allow default parameter for mtNone > > src/hotspot/share/memory/virtualspace.hpp line 74: > >> 72: // Initialize the reserved space with the given size. Depending on the size >> 73: // a suitable page size and alignment will be used. >> 74: explicit ReservedSpace(size_t size, MemTag mem_tag); > > Suggestion: > > ReservedSpace(size_t size, MemTag mem_tag); > > No need for `explicit` when you've added a parameter. Fixed. > src/hotspot/share/runtime/safepointMechanism.cpp line 61: > >> 59: const size_t page_size = os::vm_page_size(); >> 60: const size_t allocation_size = 2 * page_size; >> 61: char* polling_page = os::reserve_memory(allocation_size, false, mtSafepoint); > > Suggestion: > > char* polling_page = os::reserve_memory(allocation_size, !ExecMem, mtSafepoint); Fixed. > src/hotspot/share/utilities/debug.cpp line 712: > >> 710: >> 711: void initialize_assert_poison() { >> 712: char* page = os::reserve_memory(os::vm_page_size(), false, mtInternal); > > Suggestion: > > char* page = os::reserve_memory(os::vm_page_size(), !ExecMem, mtTest); Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1852621576 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1852622931 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1852622511 From wkemper at openjdk.org Thu Nov 21 18:12:45 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 18:12:45 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> Message-ID: On Thu, 21 Nov 2024 10:15:27 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 524 commits: >> >> - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux >> - 8344670: GenShen: Use concurrent worker session for concurrent mark phase >> >> Reviewed-by: kdnilsen >> - 8344640: GenShen: Reuse existing card mark barrier function when dropping references >> >> Reviewed-by: shade, ysr >> - 8344592: GenShen: Remove unnecessary comments and changes >> >> Reviewed-by: kdnilsen >> - 8344263: GenShen: Reduce extraneous log messages at INFO level >> >> Reviewed-by: ysr, shade >> - 8344638: GenShen: Verifier should not touch claim token >> >> Reviewed-by: shade >> - Merge >> - 8344320: GenShen: Possible null pointer usage in shGenerationalHeap >> >> Reviewed-by: wkemper, ysr >> - 8344321: GenShen: Fix various sonar scan warnings >> >> Reviewed-by: kdnilsen, shade >> - 8344264: GenShen: Improve comments and method names >> >> Reviewed-by: shade >> - ... and 514 more: https://git.openjdk.org/jdk/compare/95a00f8a...7ab16403 > > src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 663: > >> 661: // ---------- CDS archive support >> 662: >> 663: bool can_load_archived_objects() const override { return !ShenandoahCardBarrier; } > > This means CDS heap loading is not yet working with generational Shenandoah? This looks OK for the experimental code. Please submit a bug for this and assign it to me. I will take a look at it some time later. Yes, we have: https://bugs.openjdk.org/browse/JDK-8339182 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852633232 From gziemski at openjdk.org Thu Nov 21 18:13:36 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 21 Nov 2024 18:13:36 GMT Subject: RFR: 8328944: NMT reports "unknown" memory [v2] In-Reply-To: <7UxSMg_or6Avy_wuFlkkuDO0pBpyR5DiKeuY0N4uhVs=.d2c7835f-6e68-4f87-857a-e4fd6eb5f12b@github.com> References: <6Up1fGCFJl2HAUGl6IBKEDRodItQLn5TigHJEdzZpbU=.5f5ae17c-edc4-4dd8-ae09-8e8ae8567354@github.com> <7UxSMg_or6Avy_wuFlkkuDO0pBpyR5DiKeuY0N4uhVs=.d2c7835f-6e68-4f87-857a-e4fd6eb5f12b@github.com> Message-ID: <5_ysL6UzUTxpXuDqgrEIsxGZbc5LzbOS8HACNE28LfA=.3ebd5b9d-ca74-4d32-a657-ee64739b0103@github.com> On Wed, 20 Nov 2024 15:29:45 GMT, Stefan Karlsson wrote: >> Gerard Ziemski 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: >> >> - avoid using mtNone >> - Merge remote-tracking branch 'upstream/master' into JDK-8328944 >> - revert, we will re-do with a smaller change >> - remove more mtNone >> - remove API that allows to change the mem_tag for virtual memory, feedback >> - do not allow default parameter for mtNone > > src/hotspot/os/linux/os_linux.cpp line 4587: > >> 4585: char* hint = (char*)(os::Linux::initial_thread_stack_bottom() - >> 4586: (StackOverflow::stack_guard_zone_size() + page_size)); >> 4587: char* codebuf = os::attempt_reserve_memory_at(hint, page_size, false, mtInternal); > > Could this be mtThread instead? Makes sense, fixed. > src/hotspot/os/linux/os_linux.cpp line 4595: > >> 4593: // map our codebuf, try again at an address one megabyte lower. >> 4594: hint -= 1 * M; >> 4595: codebuf = os::attempt_reserve_memory_at(hint, page_size, false, mtInternal); > > Could this be mtThread instead? Makes sense, fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1852634508 PR Review Comment: https://git.openjdk.org/jdk/pull/21843#discussion_r1852634648 From wkemper at openjdk.org Thu Nov 21 18:15:42 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 18:15:42 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> Message-ID: <41m15WV5CgJ9hVyFzomp3dsrutwUTkoWsTu95JuYUiI=.6fd92984-1d04-4c78-858b-c16a98fcc382@github.com> On Thu, 21 Nov 2024 10:16:16 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 524 commits: >> >> - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux >> - 8344670: GenShen: Use concurrent worker session for concurrent mark phase >> >> Reviewed-by: kdnilsen >> - 8344640: GenShen: Reuse existing card mark barrier function when dropping references >> >> Reviewed-by: shade, ysr >> - 8344592: GenShen: Remove unnecessary comments and changes >> >> Reviewed-by: kdnilsen >> - 8344263: GenShen: Reduce extraneous log messages at INFO level >> >> Reviewed-by: ysr, shade >> - 8344638: GenShen: Verifier should not touch claim token >> >> Reviewed-by: shade >> - Merge >> - 8344320: GenShen: Possible null pointer usage in shGenerationalHeap >> >> Reviewed-by: wkemper, ysr >> - 8344321: GenShen: Fix various sonar scan warnings >> >> Reviewed-by: kdnilsen, shade >> - 8344264: GenShen: Improve comments and method names >> >> Reviewed-by: shade >> - ... and 514 more: https://git.openjdk.org/jdk/compare/95a00f8a...7ab16403 > > src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 514: > >> 512: >> 513: public: >> 514: ShenandoahController* control_thread() { return _control_thread; } > > This method and field is probably `controller` then, right? Left the accessor and field with the same name to reduce churn. Clients of this method don't really need to change because in most (all?) cases, the public API of `ShenandoahControlThread` is declared in `ShenandoahController`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852636871 From stefank at openjdk.org Thu Nov 21 18:21:20 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 21 Nov 2024 18:21:20 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v13] In-Reply-To: <40aXhGIn_ZSESqN69PsemM4BKC1MYgH5qso09BExFJY=.398b0609-23e6-4771-9c08-ac97cb500e1a@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> <40aXhGIn_ZSESqN69PsemM4BKC1MYgH5qso09BExFJY=.398b0609-23e6-4771-9c08-ac97cb500e1a@github.com> Message-ID: <_o3VptFYU0qOLHN771E5GptH9jhqzRpi3Ov9bkK_MEM=.a5b90653-3a5d-49d1-b396-9debc5eea09e@github.com> On Thu, 21 Nov 2024 16:19:04 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed decl A couple more nits. src/hotspot/share/runtime/mutex.cpp line 592: > 590: #endif // ASSERT > 591: } > 592: Extra blank space Suggestion: src/hotspot/share/runtime/vmStructs.cpp line 1026: > 1024: \ > 1025: nonstatic_field(UpcallStub::FrameData, jfa, JavaFrameAnchor) \ > 1026: nonstatic_field(Mutex, _name, const char*) \ Other classes have their own section. Mutex should also have its own section. Suggestion: nonstatic_field(Mutex, _name, const char*) \ ------------- PR Review: https://git.openjdk.org/jdk/pull/22171#pullrequestreview-2452287831 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1852637155 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1852643301 From coleenp at openjdk.org Thu Nov 21 18:29:21 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 21 Nov 2024 18:29:21 GMT Subject: RFR: 8344763: cpCache print_on doesn't handle nulls In-Reply-To: References: Message-ID: On Thu, 21 Nov 2024 17:30:53 GMT, Coleen Phillimore wrote: > A change to remove some more security manager code, resulted in java.lang.System not having any more indy instructions so the gtest test_cpCache_output.cpp was crashing because of missing null checks. Please review this trivial change to add in null checks. The test doesn't verify that there are indys so doesn't need to be fixed. > > Tested with gtest and upcoming security manager change. Thanks Matias! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22298#issuecomment-2491969649 From coleenp at openjdk.org Thu Nov 21 18:29:22 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 21 Nov 2024 18:29:22 GMT Subject: Integrated: 8344763: cpCache print_on doesn't handle nulls In-Reply-To: References: Message-ID: On Thu, 21 Nov 2024 17:30:53 GMT, Coleen Phillimore wrote: > A change to remove some more security manager code, resulted in java.lang.System not having any more indy instructions so the gtest test_cpCache_output.cpp was crashing because of missing null checks. Please review this trivial change to add in null checks. The test doesn't verify that there are indys so doesn't need to be fixed. > > Tested with gtest and upcoming security manager change. This pull request has now been integrated. Changeset: 93d4ad4d Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/93d4ad4dd4cc4c5700af3453cfb3e21a804c8c14 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod 8344763: cpCache print_on doesn't handle nulls Reviewed-by: matsaave ------------- PR: https://git.openjdk.org/jdk/pull/22298 From lmesnik at openjdk.org Thu Nov 21 18:32:13 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Nov 2024 18:32:13 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v14] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: - Update src/hotspot/share/runtime/mutex.cpp Co-authored-by: Stefan Karlsson - Update src/hotspot/share/runtime/vmStructs.cpp Co-authored-by: Stefan Karlsson ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/e0290f7a..186beb0a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=12-13 Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From shade at openjdk.org Thu Nov 21 18:33:42 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 21 Nov 2024 18:33:42 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Wed, 20 Nov 2024 00:13:13 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 420: >> >>> 418: } >>> 419: int gc_state = _heap->gc_state(); >>> 420: if ((gc_state & ShenandoahHeap::YOUNG_MARKING) != 0) { >> >> It is not very clear this works fine with single-gen mode. Does `MARKING` imply `YOUNG_MARKING` in single-gen mode? I think we better make it abundantly clear with `is_generational()` checks. > > Yes, in single gen mode we set `MARKING` and `YOUNG_MARKING` together. See https://github.com/openjdk/shenandoah/blob/master/src/hotspot/share/gc/shenandoah/shenandoahGlobalGeneration.cpp#L81 We should really either predicate it on generational mode (we already poll it a few lines below) and check for `MARKING` specifically, or assert it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852659199 From wkemper at openjdk.org Thu Nov 21 19:14:39 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 19:14:39 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> Message-ID: On Thu, 21 Nov 2024 09:14:57 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 524 commits: >> >> - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux >> - 8344670: GenShen: Use concurrent worker session for concurrent mark phase >> >> Reviewed-by: kdnilsen >> - 8344640: GenShen: Reuse existing card mark barrier function when dropping references >> >> Reviewed-by: shade, ysr >> - 8344592: GenShen: Remove unnecessary comments and changes >> >> Reviewed-by: kdnilsen >> - 8344263: GenShen: Reduce extraneous log messages at INFO level >> >> Reviewed-by: ysr, shade >> - 8344638: GenShen: Verifier should not touch claim token >> >> Reviewed-by: shade >> - Merge >> - 8344320: GenShen: Possible null pointer usage in shGenerationalHeap >> >> Reviewed-by: wkemper, ysr >> - 8344321: GenShen: Fix various sonar scan warnings >> >> Reviewed-by: kdnilsen, shade >> - 8344264: GenShen: Improve comments and method names >> >> Reviewed-by: shade >> - ... and 514 more: https://git.openjdk.org/jdk/compare/95a00f8a...7ab16403 > > src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 134: > >> 132: bool is_thread_safe() override { return true; } >> 133: }; >> 134: > > This looks like belonging in one of the `*closures.hpp` header. https://bugs.openjdk.org/browse/JDK-8344779 > src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 754: > >> 752: oop try_evacuate_object(oop src, Thread* thread, ShenandoahHeapRegion* from_region, ShenandoahAffiliation target_gen); >> 753: public: >> 754: > > I think this new line should be before `public:` Sneaking this into: https://bugs.openjdk.org/browse/JDK-8344779 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852709552 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852711083 From wkemper at openjdk.org Thu Nov 21 19:14:40 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 19:14:40 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 19 Nov 2024 23:17:48 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahMarkClosures.hpp line 34: >> >>> 32: class ShenandoahHeapRegion; >>> 33: >>> 34: class ShenandoahFinalMarkUpdateRegionStateClosure : public ShenandoahHeapRegionClosure { >> >> There is the `shenandoahHeapRegionClosures.hpp` for these, no? > > It wasn't the intention that `shenandoahHeapRegionClosures.hpp` should become home to all of the `*HeapRegionClosures`. `ShenandoahFinalMarkUpdateRegionStateClosure` is shared in a couple of implementation files, but not the same as the ones using `shenandoahHeapRegionClosures.hpp`. I think `ShenandoahUpdateCensusZeroCohortClosure` should be moved into the only implementation file that uses it. https://bugs.openjdk.org/browse/JDK-8344779 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852709824 From shade at openjdk.org Thu Nov 21 19:33:42 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 21 Nov 2024 19:33:42 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: <41m15WV5CgJ9hVyFzomp3dsrutwUTkoWsTu95JuYUiI=.6fd92984-1d04-4c78-858b-c16a98fcc382@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> <41m15WV5CgJ9hVyFzomp3dsrutwUTkoWsTu95JuYUiI=.6fd92984-1d04-4c78-858b-c16a98fcc382@github.com> Message-ID: <87AIGvZXmJftw8Sj68WTINanxXFtPVb7ITiRQLv1LsU=.68baafe0-87ce-4e4c-b02e-63ac460d7434@github.com> On Thu, 21 Nov 2024 18:12:43 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 514: >> >>> 512: >>> 513: public: >>> 514: ShenandoahController* control_thread() { return _control_thread; } >> >> This method and field is probably `controller` then, right? > > Left the accessor and field with the same name to reduce churn. Clients of this method don't really need to change because in most (all?) cases, the public API of `ShenandoahControlThread` is declared in `ShenandoahController`. OK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852731729 From lmesnik at openjdk.org Thu Nov 21 19:43:40 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Nov 2024 19:43:40 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v15] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: added \ to the line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/186beb0a..45c712b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=13-14 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From wkemper at openjdk.org Thu Nov 21 20:13:44 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 20:13:44 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> Message-ID: On Thu, 21 Nov 2024 13:50:42 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 524 commits: >> >> - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux >> - 8344670: GenShen: Use concurrent worker session for concurrent mark phase >> >> Reviewed-by: kdnilsen >> - 8344640: GenShen: Reuse existing card mark barrier function when dropping references >> >> Reviewed-by: shade, ysr >> - 8344592: GenShen: Remove unnecessary comments and changes >> >> Reviewed-by: kdnilsen >> - 8344263: GenShen: Reduce extraneous log messages at INFO level >> >> Reviewed-by: ysr, shade >> - 8344638: GenShen: Verifier should not touch claim token >> >> Reviewed-by: shade >> - Merge >> - 8344320: GenShen: Possible null pointer usage in shGenerationalHeap >> >> Reviewed-by: wkemper, ysr >> - 8344321: GenShen: Fix various sonar scan warnings >> >> Reviewed-by: kdnilsen, shade >> - 8344264: GenShen: Improve comments and method names >> >> Reviewed-by: shade >> - ... and 514 more: https://git.openjdk.org/jdk/compare/95a00f8a...7ab16403 > > src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp line 64: > >> 62: } >> 63: } >> 64: return _mark_bit_map.is_bitmap_clear_range(start, end); > > Comprehension check: this seems to bail out the moment it discovers an uncommitted slice. Does it really happen? More worryingly, if there is a mix of committed and uncommitted chunks, this method returns `true`, even if committed chunks are not actually clean? In all (3) usages of this method, the `start` and `end` are within the same region, so it isn't really iterating across regions. I'll rewrite it to handle this case more clearly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852802615 From ysr at openjdk.org Thu Nov 21 20:23:40 2024 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 21 Nov 2024 20:23:40 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> Message-ID: On Thu, 21 Nov 2024 13:34:51 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 524 commits: >> >> - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux >> - 8344670: GenShen: Use concurrent worker session for concurrent mark phase >> >> Reviewed-by: kdnilsen >> - 8344640: GenShen: Reuse existing card mark barrier function when dropping references >> >> Reviewed-by: shade, ysr >> - 8344592: GenShen: Remove unnecessary comments and changes >> >> Reviewed-by: kdnilsen >> - 8344263: GenShen: Reduce extraneous log messages at INFO level >> >> Reviewed-by: ysr, shade >> - 8344638: GenShen: Verifier should not touch claim token >> >> Reviewed-by: shade >> - Merge >> - 8344320: GenShen: Possible null pointer usage in shGenerationalHeap >> >> Reviewed-by: wkemper, ysr >> - 8344321: GenShen: Fix various sonar scan warnings >> >> Reviewed-by: kdnilsen, shade >> - 8344264: GenShen: Improve comments and method names >> >> Reviewed-by: shade >> - ... and 514 more: https://git.openjdk.org/jdk/compare/95a00f8a...7ab16403 > > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1972: > >> 1970: // Check that if concurrent weak root is set then active_gen isn't null >> 1971: assert(!is_concurrent_weak_root_in_progress() || active_generation() != nullptr, "Error"); >> 1972: shenandoah_assert_generations_reconciled(); > > Why all of this is checked here? I would have thought `gc_state` machinery should only check things related to gc-state. Likely debugging detritus that I unintentionally left behind. Feel free to delete. I think the `shenandoah_assert_generations_reconciled()` is already checked in a most spots where it's needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852820087 From duke at openjdk.org Thu Nov 21 20:42:27 2024 From: duke at openjdk.org (Robert Toyonaga) Date: Thu, 21 Nov 2024 20:42:27 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v3] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Mon, 11 Nov 2024 11:55:12 GMT, Afshin Zafari wrote: >> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. >> - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. >> - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` >> - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. >> - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. >> - Adding a runtime flag for selecting the old or new version can be added later. >> - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > gc/x directory removed. src/hotspot/share/nmt/regionsTree.hpp line 33: > 31: > 32: // RegionsTree extends VMATree to add some more specific API and also defines a helper > 33: // for processing the tree nodes in a shorter and more menaingful way. Typo: "meaningful" src/hotspot/share/nmt/vmtCommon.cpp line 121: > 119: size_t aligned_stack_size = align_up(stack_size, os::vm_page_size()); > 120: > 121: ReservedMemoryRegion* region = const_cast(rgn); Is this still needed now that you're directly adding committed regions to the tree? I think this was only there before because it was adding committed regions to the `ReservedMemoryRegion`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1852857478 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1852855336 From duke at openjdk.org Thu Nov 21 20:47:24 2024 From: duke at openjdk.org (Robert Toyonaga) Date: Thu, 21 Nov 2024 20:47:24 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v3] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Mon, 11 Nov 2024 11:55:12 GMT, Afshin Zafari wrote: >> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. >> - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. >> - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` >> - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. >> - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. >> - Adding a runtime flag for selecting the old or new version can be added later. >> - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > gc/x directory removed. src/hotspot/share/nmt/vmtCommon.cpp line 133: > 131: committed_size = stack_bottom + stack_size - committed_start; > 132: } > 133: VirtualMemoryTracker::Instance::add_committed_region(committed_start, committed_size, ncs); Is it a problem that it is never recorded that regions are uncommitted? Committed regions are added on-the-fly when reporting data, and those regions persist after reporting is done. So maybe it's possible to report too much committed size on a future report. The old implementation had this characteristic too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1852862428 From gziemski at openjdk.org Thu Nov 21 21:09:33 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Thu, 21 Nov 2024 21:09:33 GMT Subject: RFR: 8328944: NMT reports "unknown" memory [v4] In-Reply-To: References: Message-ID: > We use `mtNone` value in several functions default parameters, which may show up in NMT reports. > > We address this, by avoiding using `mtNone`. > > This fix only addresses the cases covered by the issue. I am not trying to replace every single `mtNone` here, but eventually the goal would be to do just that. > > TODO: update copyrights. > > Testing: undergoing MARCH5 tier1-5 ... Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: Stefan's feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21843/files - new: https://git.openjdk.org/jdk/pull/21843/files/62a98865..42793a9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21843&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21843&range=02-03 Stats: 16 lines in 7 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/21843.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21843/head:pull/21843 PR: https://git.openjdk.org/jdk/pull/21843 From wkemper at openjdk.org Thu Nov 21 21:50:39 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 21:50:39 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> Message-ID: On Thu, 21 Nov 2024 13:22:42 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 524 commits: >> >> - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux >> - 8344670: GenShen: Use concurrent worker session for concurrent mark phase >> >> Reviewed-by: kdnilsen >> - 8344640: GenShen: Reuse existing card mark barrier function when dropping references >> >> Reviewed-by: shade, ysr >> - 8344592: GenShen: Remove unnecessary comments and changes >> >> Reviewed-by: kdnilsen >> - 8344263: GenShen: Reduce extraneous log messages at INFO level >> >> Reviewed-by: ysr, shade >> - 8344638: GenShen: Verifier should not touch claim token >> >> Reviewed-by: shade >> - Merge >> - 8344320: GenShen: Possible null pointer usage in shGenerationalHeap >> >> Reviewed-by: wkemper, ysr >> - 8344321: GenShen: Fix various sonar scan warnings >> >> Reviewed-by: kdnilsen, shade >> - 8344264: GenShen: Improve comments and method names >> >> Reviewed-by: shade >> - ... and 514 more: https://git.openjdk.org/jdk/compare/95a00f8a...7ab16403 > > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 881: > >> 879: // update costs on slow path. >> 880: monitoring_support()->notify_heap_changed(); >> 881: _heap_changed.set(); > > Why not leave `try_set` intact? This alleviates contention on the shared counter, AFAICS. https://bugs.openjdk.org/browse/JDK-8344797 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852952949 From wkemper at openjdk.org Thu Nov 21 21:50:39 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 21:50:39 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> Message-ID: On Thu, 21 Nov 2024 20:20:12 GMT, Y. Srinivas Ramakrishna wrote: >> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1972: >> >>> 1970: // Check that if concurrent weak root is set then active_gen isn't null >>> 1971: assert(!is_concurrent_weak_root_in_progress() || active_generation() != nullptr, "Error"); >>> 1972: shenandoah_assert_generations_reconciled(); >> >> Why all of this is checked here? I would have thought `gc_state` machinery should only check things related to gc-state. > > Likely debugging detritus that I unintentionally left behind. Feel free to delete. > I think the `shenandoah_assert_generations_reconciled()` is already checked in a most spots where it's needed. https://bugs.openjdk.org/browse/JDK-8344797 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852949534 From wkemper at openjdk.org Thu Nov 21 21:50:40 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 21:50:40 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> Message-ID: On Thu, 21 Nov 2024 20:10:20 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp line 64: >> >>> 62: } >>> 63: } >>> 64: return _mark_bit_map.is_bitmap_clear_range(start, end); >> >> Comprehension check: this seems to bail out the moment it discovers an uncommitted slice. Does it really happen? More worryingly, if there is a mix of committed and uncommitted chunks, this method returns `true`, even if committed chunks are not actually clean? > > In all (3) usages of this method, the `start` and `end` are within the same region, so it isn't really iterating across regions. I'll rewrite it to handle this case more clearly. https://bugs.openjdk.org/browse/JDK-8344797 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852949662 From duke at openjdk.org Thu Nov 21 21:51:27 2024 From: duke at openjdk.org (Robert Toyonaga) Date: Thu, 21 Nov 2024 21:51:27 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v3] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Mon, 11 Nov 2024 11:55:12 GMT, Afshin Zafari wrote: >> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. >> - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. >> - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` >> - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. >> - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. >> - Adding a runtime flag for selecting the old or new version can be added later. >> - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > gc/x directory removed. src/hotspot/share/runtime/os.cpp line 2213: > 2211: res = pd_release_memory(addr, bytes); > 2212: if (res) { > 2213: ThreadCritical tc; What is the reason for moving `pd_release_memory` out of the protection of the lock? Wouldn't it be better if the memory operation and the accounting were done together atomically like with [`os::uncommit_memory`](https://github.com/openjdk/jdk/pull/20425/files#diff-c626d392182b0193ad0e754de3f4fd42c98d959edade67490b6e1f24be38efdbR2189) for example. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1852949298 From wkemper at openjdk.org Thu Nov 21 22:14:37 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 22:14:37 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: <8p63u9MBsujLClN-XXtWMs5OOIUKV4E-foooFIqdyYA=.442aee6c-8733-488e-a050-1c2459d30631@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <8p63u9MBsujLClN-XXtWMs5OOIUKV4E-foooFIqdyYA=.442aee6c-8733-488e-a050-1c2459d30631@github.com> Message-ID: On Thu, 21 Nov 2024 17:02:58 GMT, Aleksey Shipilev wrote: >> Hmm, I find the version in the PR much more readable. How about we upstream these changes separately? > > Yes, let's do that, if you have cycles. https://bugs.openjdk.org/browse/JDK-8344797 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852976446 From ccheung at openjdk.org Thu Nov 21 23:14:58 2024 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 21 Nov 2024 23:14:58 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v3] In-Reply-To: References: Message-ID: > Currently, when retrieving a ClassFileStream during runtime, we call into the zip library to retrieve the stream based only on a class name. This doesn't work well if the class is in a multi-release jar under a versioned directory such as `META-INF/versions/9/Foo.class`. To address this issue, this change calls the java api `ClassLoader.getResourceAsStream()` to retrieve the stream. > > Passed tiers 1 - 4 testing. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: @dholmes-ora comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22262/files - new: https://git.openjdk.org/jdk/pull/22262/files/96b7945f..9b2b6552 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22262&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22262&range=01-02 Stats: 68 lines in 5 files changed: 13 ins; 13 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/22262.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22262/head:pull/22262 PR: https://git.openjdk.org/jdk/pull/22262 From ccheung at openjdk.org Thu Nov 21 23:14:58 2024 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 21 Nov 2024 23:14:58 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v2] In-Reply-To: References: <-ItmDmV4oovdAbnojC5s4h3JIKozNKHIMm4SwilR_BE=.9dfbdca7-c435-4c1a-88d6-cd6425bacfb3@github.com> Message-ID: On Thu, 21 Nov 2024 17:00:47 GMT, Chen Liang wrote: >> test/hotspot/jtreg/runtime/cds/appcds/jvmti/CFLH/MultiReleaseJars.java line 48: >> >>> 46: static final String MAJOR_VERSION_STRING = String.valueOf(MAJOR_VERSION); >>> 47: >>> 48: static String[] getMain() { >> >> Can't you just define these as source files in the test directory rather than creating them dynamically? > > I think the concern may be that we want to avoid license headers. > > However, we should still use text blocks instead of these string arrays for such inlined source files. I've changed the code to use text blocks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22262#discussion_r1853068142 From ccheung at openjdk.org Thu Nov 21 23:21:15 2024 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 21 Nov 2024 23:21:15 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v2] In-Reply-To: <9xoOh3WCssQTWIZYkytf1O-T7Y80CmirGRm82yCLgJs=.c71429cf-1f71-48e7-a392-11d66294c0c0@github.com> References: <9xoOh3WCssQTWIZYkytf1O-T7Y80CmirGRm82yCLgJs=.c71429cf-1f71-48e7-a392-11d66294c0c0@github.com> Message-ID: On Thu, 21 Nov 2024 06:20:32 GMT, David Holmes wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> updated testcase > > src/hotspot/share/cds/filemap.cpp line 2705: > >> 2703: >> 2704: // InputStream ClassLoader.getResourceAsStream(String name) >> 2705: JavaCalls::call_virtual(&result, > > Do we really have to make two Java upcalls to do this? What is the performance hit? Can we declare a helper method in ClassLoader that does it in one? Is there any risk of getting into a recursive loop here? I've added the following method in ClassLoader so we only make one Java upcalls: `private byte[] getResourceAsByteArray(String name)` This is a special case of using CDS and CFLH. So I think it can take a bit of performance hit. Better than experiencing a VM crash. Since the new function doesn't have any global state, it should be able to handle recursive call. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22262#discussion_r1853072397 From vlivanov at openjdk.org Fri Nov 22 04:10:30 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 22 Nov 2024 04:10:30 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations [v5] In-Reply-To: References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: On Thu, 21 Nov 2024 17:50:57 GMT, Andrew Dinn wrote: >> Implementation of JDK-8343767 > > Andrew Dinn 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 55 additional commits since the last revision: > > - Merge branch 'master' into iterate_stubs > - fix element sizes in s390 copy routines > - fix stub is and align flags for s390 > - fix comments and remove unused stubid on riscv > - locate super lookup stubs in same blob for all arches > - do verification under ifdef ASSERT > - fix yet more problems with s390 stubs > - better error notification > - fix more problems with s390 stubs > - Verify stubs are generated in correct blob > - ... and 45 more: https://git.openjdk.org/jdk/compare/83ba7fe7...e21268c4 I submitted it for testing and it seems the build is mostly broken on x86 when `UseAVX=3` is set. I even tried to manually build the patch on an AVX512-capable host and it reliably fails early during startup: Error occurred during initialization of boot layer java.lang.module.FindException: Error reading module: /scratch/vlivanov/jdk/build/linux-x64-fastdebug/jdk/modules/java.base Caused by: java.lang.module.InvalidModuleDescriptorException: Bad constant pool entry: 90 ------------- PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2492836027 From fyang at openjdk.org Fri Nov 22 04:27:22 2024 From: fyang at openjdk.org (Fei Yang) Date: Fri, 22 Nov 2024 04:27:22 GMT Subject: RFR: 8344382: RISC-V: CASandCAEwithNegExpected fails with Zacas In-Reply-To: References: Message-ID: On Thu, 21 Nov 2024 13:56:32 GMT, Robbin Ehn wrote: > Hi, please consider. > > There are two issues with narrow amocas: > - weak_cmpxchg_narrow_value don't load from aligned address. > - cmpxchg_narrow_value compared new to loaded value, not to expected value. > > This addresses these two issues and makes some minor cleanups by: > - Weak and strong are now identical for easier debugging (and in feature code sharing). > - t1 was set by cmpxchg_narrow_value but not passed. > - To free up a register, not_mask is now a scratch registers. Hence thus if amocas fails we need to re-create not mask. > - Subjective change: a register containing temporary value is best named scratch, as the register it self is not temporary. > > Same as other PR, here be dragons. > But with a working baseline we can start improving this code. > > Passes test/hotspot/jtreg/compiler/unsafe/ with +/-UseZacas. > And I'm running tier1 +/-UseZacas (I'll run tests over the weekend). > > Thanks, Robbin Nice fix! Now I see what's going on here. Thanks for finding it out. FYI: I also tried the non-zacas code path, seems to work. ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22293#pullrequestreview-2453293026 From rehn at openjdk.org Fri Nov 22 06:16:14 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 22 Nov 2024 06:16:14 GMT Subject: RFR: 8344382: RISC-V: CASandCAEwithNegExpected fails with Zacas In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 04:24:37 GMT, Fei Yang wrote: > Nice fix! Now I see what's going on here. Thanks for finding it out. FYI: I also tried the non-Zacas code path, seems to work. Thanks, great! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22293#issuecomment-2492947516 From lliu at openjdk.org Fri Nov 22 08:14:15 2024 From: lliu at openjdk.org (Liming Liu) Date: Fri, 22 Nov 2024 08:14:15 GMT Subject: RFR: 8343978: Update the default value of CodeEntryAlignment for Ampere-1A and 1B In-Reply-To: <0VpEw-8l8AnoTWMX1K_IOJfeOkTfih6Nl0RDaxdMA14=.cabf595d-9dae-4e57-9aec-140808a6e610@github.com> References: <0VpEw-8l8AnoTWMX1K_IOJfeOkTfih6Nl0RDaxdMA14=.cabf595d-9dae-4e57-9aec-140808a6e610@github.com> Message-ID: On Thu, 21 Nov 2024 12:15:49 GMT, Boris Ulasevich wrote: >> This PR updates the default value of CodeEntryAlignment for Ampere-1A and 1B from 64 to 32. The microbenchmark CodeCacheStress shows that frontend stall becomes ~21% smaller by the change, and IPC increases by ~2.8%. The benefits persist after CodeCacheSegmentSize changes from 64 back to 128. >> >> Ran JTReg tier1 on Ampere-1A and no new issues were found. > > Cool. I like the updates of rusty default settings is going on. > > On https://github.com/openjdk/jdk/pull/20864 review comments we see that CodeEntryAlignment=16/32 was not good for AMPERE. Did you check both CPU_MODEL_AMPERE_1A/CPU_MODEL_AMPERE_1B CPUs? Are you sure the performance is good on all CPUs with 1A/1B cpu flag? Hi, @bulasevich. Ampere CPU mentioned in #20864 is Neoverse-N1, while this pull request is about Ampere-1A/1B. This two architectures prefer 32B alignment for code entries, since we can find that GCC did it for both Ampere-1A [1] and 1B [2], and the microbenchmark also shows IPC increases due to the decreases of frontend stall, which is a strong evidence. 1: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=590a06afbf0e96813b5879742f38f3665512c854;hp=5ba25973e2f403ee48af2ba579af5017b2f650fb 2: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=cbf2369f3b545e0187fe2e659c764fabf75bb479;hp=99d114c15523e0bfe7a89ef1947f82eb5ff0260b ------------- PR Comment: https://git.openjdk.org/jdk/pull/22134#issuecomment-2493129722 From jwaters at openjdk.org Fri Nov 22 08:43:59 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 22 Nov 2024 08:43:59 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v7] In-Reply-To: References: Message-ID: > Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely Julian Waters has updated the pull request incrementally with two additional commits since the last revision: - No spaces in test_os_windows.cpp - No spaces in test/hotspot/gtest/runtime/test_os.cpp Co-authored-by: Andrew Haley ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21627/files - new: https://git.openjdk.org/jdk/pull/21627/files/b0083f8c..8f57d674 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=05-06 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/21627.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21627/head:pull/21627 PR: https://git.openjdk.org/jdk/pull/21627 From jwaters at openjdk.org Fri Nov 22 08:44:00 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 22 Nov 2024 08:44:00 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v6] In-Reply-To: <7RH8t4s6f9WH00MKVI9eKWuX8C70tzIRWukqTTM1TLw=.d83721e3-0240-4efe-a43f-5cd37fd1e1b8@github.com> References: <43iM4MdPRiY-J59P4ZrvUNOZvRF_SthATx_usTPxgQ4=.dd9c77f8-98f6-4bc9-8d5b-7983fe3816b9@github.com> <7RH8t4s6f9WH00MKVI9eKWuX8C70tzIRWukqTTM1TLw=.d83721e3-0240-4efe-a43f-5cd37fd1e1b8@github.com> Message-ID: On Thu, 21 Nov 2024 10:10:33 GMT, Andrew Haley wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> Revise comment in sharedRuntime.hpp > > test/hotspot/gtest/runtime/test_os.cpp line 766: > >> 764: ASSERT_EQ(mapping_info.regions, 1); >> 765: ASSERT_EQ(mapping_info.size, total_range_len); >> 766: ASSERT_EQ(mapping_info.committed_size, size_t { 0 }); > > Suggestion: > > ASSERT_EQ(mapping_info.committed_size, size_t{0}); > > We don't usually insert extra spaces. Was there a special reason? No, there wasn't really a reason other than the formatting looked neater. But since the style is to usually not leave spaces, I'll commit the suggestion and fix the other areas too ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1853497821 From jwaters at openjdk.org Fri Nov 22 08:46:21 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 22 Nov 2024 08:46:21 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v7] In-Reply-To: References: <9C3_nSzX9UY6959Q1mpv1JpE7MMQ8l9JvRWUWSOuRQY=.e8928e43-8664-4de1-b240-3dca1f4ab4af@github.com> <31Dtdw2Xv9w5M6KbSN4lkHhpflbU3Nw123ZincFNHuk=.0c68c7e0-797b-4185-b59b-de2a49d29bd9@github.com> Message-ID: <4v45CSbW_1dp4K5Mc-IL2p-tTPzvJRXU4-D_zINEtHI=.d6f90825-6afa-4216-89c5-d7838efece38@github.com> On Wed, 20 Nov 2024 12:16:14 GMT, Andrew Haley wrote: > > I don't think this workaround was intended for ARM64 in the first place, it explicitly mentions that it was written for x64, and the ifdef mess that resulted in this bug ended up bringing it over to ARM64 > > So what? I'm sure it'll be fine on AArch64. Just use it. This comment was made before Saint Wesonga confirmed that Windows/ARM64 now needed the workaround ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1853508754 From jwaters at openjdk.org Fri Nov 22 09:11:59 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 22 Nov 2024 09:11:59 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v8] In-Reply-To: References: Message-ID: > Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely Julian Waters has updated the pull request incrementally with three additional commits since the last revision: - fmod_win64 in sharedRuntime.cpp - Should only declare fmod_win64 on Windows/ARM64 sharedRuntime.hpp - fmod_win64 in src/hotspot/share/runtime/sharedRuntime.hpp Co-authored-by: Andrew Haley ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21627/files - new: https://git.openjdk.org/jdk/pull/21627/files/8f57d674..6caa759b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=06-07 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/21627.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21627/head:pull/21627 PR: https://git.openjdk.org/jdk/pull/21627 From jwaters at openjdk.org Fri Nov 22 09:17:53 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 22 Nov 2024 09:17:53 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9] In-Reply-To: References: Message-ID: > Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely Julian Waters 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 16 additional commits since the last revision: - Merge branch 'openjdk:master' into hotspot - Reintroduce ifdef removed in the nuking of the Windows 32 bit x86 port in sharedRuntimeRem.cpp - fmod_win64 in sharedRuntime.cpp - Should only declare fmod_win64 on Windows/ARM64 sharedRuntime.hpp - fmod_win64 in src/hotspot/share/runtime/sharedRuntime.hpp Co-authored-by: Andrew Haley - No spaces in test_os_windows.cpp - No spaces in test/hotspot/gtest/runtime/test_os.cpp Co-authored-by: Andrew Haley - Revise comment in sharedRuntime.hpp - Revise comment in sharedRuntime.cpp - size_t brace initialization instead of unsigned literals in test_os_windows.cpp - ... and 6 more: https://git.openjdk.org/jdk/compare/f7b5c841...6cf1c83a ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21627/files - new: https://git.openjdk.org/jdk/pull/21627/files/6caa759b..6cf1c83a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=07-08 Stats: 12468 lines in 381 files changed: 4246 ins; 6419 del; 1803 mod Patch: https://git.openjdk.org/jdk/pull/21627.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21627/head:pull/21627 PR: https://git.openjdk.org/jdk/pull/21627 From jbhateja at openjdk.org Fri Nov 22 10:36:10 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 22 Nov 2024 10:36:10 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations [v2] In-Reply-To: References: Message-ID: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 6. Auto-vectorization of newly supported scalar operations. > 7. X86 and AARCH64 backend implementation for all supported intrinsics. > 9. Functional and Performance validation tests. > > **Missing Pieces:-** > **- AARCH64 Backend.** > > 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: Testpoints for new value transforms + code cleanups ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21490/files - new: https://git.openjdk.org/jdk/pull/21490/files/132878ba..5f58eea6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21490&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21490&range=00-01 Stats: 279 lines in 20 files changed: 140 ins; 64 del; 75 mod Patch: https://git.openjdk.org/jdk/pull/21490.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21490/head:pull/21490 PR: https://git.openjdk.org/jdk/pull/21490 From alanb at openjdk.org Fri Nov 22 11:10:20 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 22 Nov 2024 11:10:20 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v3] In-Reply-To: References: Message-ID: On Thu, 21 Nov 2024 23:14:58 GMT, Calvin Cheung wrote: >> Currently, when retrieving a ClassFileStream during runtime, we call into the zip library to retrieve the stream based only on a class name. This doesn't work well if the class is in a multi-release jar under a versioned directory such as `META-INF/versions/9/Foo.class`. To address this issue, this change calls the java api `ClassLoader.getResourceAsStream()` to retrieve the stream. >> >> Passed tiers 1 - 4 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @dholmes-ora comment src/java.base/share/classes/java/lang/ClassLoader.java line 1689: > 1687: > 1688: /** > 1689: * Called by VM for constructing a ClassFileStream. "ClassFileStream" looks like a Java class name so might confusing readers of this code as it doesn't exist. So maybe adjust this to say that it's for reading class bytes or make it clear that it's for the C++/VM ClassFileStream. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22262#discussion_r1853744359 From dholmes at openjdk.org Fri Nov 22 12:16:17 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 22 Nov 2024 12:16:17 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing [v4] In-Reply-To: References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: On Thu, 21 Nov 2024 11:59:18 GMT, Coleen Phillimore wrote: >> From [JDK-8329351](https://bugs.openjdk.org/browse/JDK-8329351): _"`.../StressWrapper_TestRecursiveLocking_36M.java` is a wrapper that executes `.../TestRecursiveLocking.java` for 2 minutes for each of the 18 configs for a total of 36 minutes of execution time..."_ >> >> I think there is some value in looking at a test file's name, and thereby know how long it will take to run. >> >> @dcubed-ojdk created and named the file, maybe he has an opinion. > > There's precedent for this naming in our internal tests (runthese and kitchensink). Sure but if we add/remove a test case we have to rename the test file. It is not obvious what numbers combine to produce 36M. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1853823517 From kevinw at openjdk.org Fri Nov 22 12:24:42 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 22 Nov 2024 12:24:42 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands Message-ID: Remove redundant SecurityManager Permission references (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). ------------- Commit messages: - 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands Changes: https://git.openjdk.org/jdk/pull/22315/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22315&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334493 Stats: 402 lines in 17 files changed: 0 ins; 386 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/22315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22315/head:pull/22315 PR: https://git.openjdk.org/jdk/pull/22315 From coleenp at openjdk.org Fri Nov 22 12:31:14 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 22 Nov 2024 12:31:14 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 09:14:30 GMT, Kevin Walls wrote: > Remove redundant SecurityManager Permission references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22315#pullrequestreview-2454314366 From thartmann at openjdk.org Fri Nov 22 14:29:44 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 22 Nov 2024 14:29:44 GMT Subject: RFR: 8344861: Disable CheckJNICalls in tests until JDK-8344802 is fixed Message-ID: Some tests specify `-XX:+EnableX86ECoreOpts` which does not work well with `-Xcheck:jni` on Windows. Disable `CheckJNICalls` for now with these tests until [JDK-8344802](https://bugs.openjdk.org/browse/JDK-8344802) is fixed. Thanks, Tobias ------------- Commit messages: - Disable it - 8344861: Disable CheckJNICalls in tests until JDK-8344802 is fixed Changes: https://git.openjdk.org/jdk/pull/22325/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22325&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344861 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22325/head:pull/22325 PR: https://git.openjdk.org/jdk/pull/22325 From coleenp at openjdk.org Fri Nov 22 14:35:15 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 22 Nov 2024 14:35:15 GMT Subject: RFR: 8344861: Disable CheckJNICalls in tests until JDK-8344802 is fixed In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 14:19:57 GMT, Tobias Hartmann wrote: > Some tests specify `-XX:+EnableX86ECoreOpts` which does not work well with `-Xcheck:jni` on Windows. Disable `CheckJNICalls` for now with these tests until [JDK-8344802](https://bugs.openjdk.org/browse/JDK-8344802) is fixed. > > Thanks, > Tobias Ok. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22325#pullrequestreview-2454599787 From thartmann at openjdk.org Fri Nov 22 14:35:16 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 22 Nov 2024 14:35:16 GMT Subject: RFR: 8344861: Disable CheckJNICalls in tests until JDK-8344802 is fixed In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 14:19:57 GMT, Tobias Hartmann wrote: > Some tests specify `-XX:+EnableX86ECoreOpts` which does not work well with `-Xcheck:jni` on Windows. Disable `CheckJNICalls` for now with these tests until [JDK-8344802](https://bugs.openjdk.org/browse/JDK-8344802) is fixed. > > Thanks, > Tobias Thanks Coleen! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22325#issuecomment-2493899485 From thartmann at openjdk.org Fri Nov 22 14:51:23 2024 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 22 Nov 2024 14:51:23 GMT Subject: Integrated: 8344861: Disable CheckJNICalls in tests until JDK-8344802 is fixed In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 14:19:57 GMT, Tobias Hartmann wrote: > Some tests specify `-XX:+EnableX86ECoreOpts` which does not work well with `-Xcheck:jni` on Windows. Disable `CheckJNICalls` for now with these tests until [JDK-8344802](https://bugs.openjdk.org/browse/JDK-8344802) is fixed. > > Thanks, > Tobias This pull request has now been integrated. Changeset: 6d3becb4 Author: Tobias Hartmann URL: https://git.openjdk.org/jdk/commit/6d3becb486ab38c9c2d2a6fbc428bf794375317c Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod 8344861: Disable CheckJNICalls in tests until JDK-8344802 is fixed Reviewed-by: coleenp ------------- PR: https://git.openjdk.org/jdk/pull/22325 From mli at openjdk.org Fri Nov 22 15:02:15 2024 From: mli at openjdk.org (Hamlin Li) Date: Fri, 22 Nov 2024 15:02:15 GMT Subject: RFR: 8344382: RISC-V: CASandCAEwithNegExpected fails with Zacas In-Reply-To: References: Message-ID: On Thu, 21 Nov 2024 13:56:32 GMT, Robbin Ehn wrote: > Hi, please consider. > > There are two issues with narrow amocas: > - weak_cmpxchg_narrow_value don't load from aligned address. > - cmpxchg_narrow_value compared new to loaded value, not to expected value. > > This addresses these two issues and makes some minor cleanups by: > - Weak and strong are now identical for easier debugging (and in futre code sharing). > - t1 was set by cmpxchg_narrow_value_helper but not passed. > - To free up a register, not_mask is now a scratch register. Hence if amocas fails we need to re-create not mask. > - Subjective change: a register containing temporary value is best named scratch, as the register it self is not temporary. > > Same as other PR, here be dragons. > But with a working baseline we can start improving this code. > > Passes test/hotspot/jtreg/compiler/unsafe/ with +/-UseZacas. > And I'm running tier1 +/-UseZacas (I'll run tests over the weekend). > > Thanks, Robbin Nice catch and fix! Thanks! ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22293#pullrequestreview-2454667596 From ccheung at openjdk.org Fri Nov 22 17:25:54 2024 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 22 Nov 2024 17:25:54 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v4] In-Reply-To: References: Message-ID: <00t4bv6pSjmB-nOYziAApdamEvxsXovEzRwdP9yLA7w=.4b1d9289-00a7-4f82-a8f9-6d8d3174f5cd@github.com> > Currently, when retrieving a ClassFileStream during runtime, we call into the zip library to retrieve the stream based only on a class name. This doesn't work well if the class is in a multi-release jar under a versioned directory such as `META-INF/versions/9/Foo.class`. To address this issue, this change calls the java api `ClassLoader.getResourceAsStream()` to retrieve the stream. > > Passed tiers 1 - 4 testing. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: update comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22262/files - new: https://git.openjdk.org/jdk/pull/22262/files/9b2b6552..d0e6eccc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22262&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22262&range=02-03 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22262.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22262/head:pull/22262 PR: https://git.openjdk.org/jdk/pull/22262 From ccheung at openjdk.org Fri Nov 22 17:25:55 2024 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 22 Nov 2024 17:25:55 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v3] In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 11:07:31 GMT, Alan Bateman wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> @dholmes-ora comment > > src/java.base/share/classes/java/lang/ClassLoader.java line 1689: > >> 1687: >> 1688: /** >> 1689: * Called by VM for constructing a ClassFileStream. > > "ClassFileStream" looks like a Java class name so might confusing readers of this code as it doesn't exist. So maybe adjust this to say that it's for reading class bytes or make it clear that it's for the C++/VM ClassFileStream. I've updated the comment as follows: `* Called by VM for reading class bytes.` Also updated some comments in filemap.cpp. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22262#discussion_r1854342438 From drwhite at openjdk.org Fri Nov 22 18:11:17 2024 From: drwhite at openjdk.org (Derek White) Date: Fri, 22 Nov 2024 18:11:17 GMT Subject: RFR: 8341481: [perf] vframeStreamCommon constructor may be optimized In-Reply-To: References: Message-ID: On Sat, 16 Nov 2024 00:20:10 GMT, Vladimir Ivanov wrote: > Optimize constructor to skip extra copy for registers. The tier1 tests are OK. The Specjvm2008 benchmark reports ~1% improvement. @kimbarrett - Hi! This is the issue with copy constructors that I mentioned in the parking lot a while back. The existing code for stack walking by vFrames is allocating multiple KB for 2 temporary RegisterMap structs, and copying between them via default copy constructors. The temps are unnecessary. We believe the performance boost in SPECjbb and SPECjvm:serial are more due to not polluting the L1 cache (improving cache hit rates of other code) than the actual instruction overhead of the copy. I tried to make the RegisterMap copy constructor private so no one would use it, but there are one or two cases that still use the copy constructor that we didn't have a fix for - maybe you'll see something. Oops, I can't find the examples right off. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22173#issuecomment-2494459792 From rehn at openjdk.org Fri Nov 22 18:17:15 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 22 Nov 2024 18:17:15 GMT Subject: RFR: 8344382: RISC-V: CASandCAEwithNegExpected fails with Zacas In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 14:59:19 GMT, Hamlin Li wrote: > Nice catch and fix! Thanks! Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22293#issuecomment-2494473436 From szaldana at openjdk.org Fri Nov 22 18:58:17 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Fri, 22 Nov 2024 18:58:17 GMT Subject: Integrated: 8344568: Renaming ceil_log2 to log2i_ceil In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 16:56:11 GMT, Sonia Zaldana Calles wrote: > Hi all, > > This PR addresses [8344568](https://bugs.openjdk.org/browse/JDK-8344568). Should be a straightforward rename and cleanup. > > Thanks, > Sonia This pull request has now been integrated. Changeset: 079f503d Author: Sonia Zaldana Calles URL: https://git.openjdk.org/jdk/commit/079f503d962ad9e5ae4394c083e6877828c798ec Stats: 43 lines in 7 files changed: 7 ins; 7 del; 29 mod 8344568: Renaming ceil_log2 to log2i_ceil Reviewed-by: kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/22279 From gziemski at openjdk.org Fri Nov 22 19:01:27 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Fri, 22 Nov 2024 19:01:27 GMT Subject: RFR: 8328944: NMT reports "unknown" memory [v4] In-Reply-To: References: Message-ID: On Thu, 21 Nov 2024 21:09:33 GMT, Gerard Ziemski wrote: >> We use `mtNone` value in several functions default parameters, which may show up in NMT reports. >> >> We address this, by avoiding using `mtNone`. >> >> This fix only addresses the cases covered by the issue. I am not trying to replace every single `mtNone` here, but eventually the goal would be to do just that. >> >> Testing: passes MARCH5 tier1-5 > > Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: > > Stefan's feedback Filed [Do not use mtNone if we know the tag type](https://bugs.openjdk.org/browse/JDK-8344883) as a followup to fix the remaining `mtNone` tags. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21843#issuecomment-2494552118 From cjplummer at openjdk.org Fri Nov 22 19:24:32 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 22 Nov 2024 19:24:32 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v15] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: On Thu, 21 Nov 2024 19:43:40 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > added \ to the line Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22171#pullrequestreview-2455458026 From lmesnik at openjdk.org Fri Nov 22 19:24:34 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 22 Nov 2024 19:24:34 GMT Subject: Integrated: 8343741: SA jstack --mixed should print information about VM locks In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: On Fri, 15 Nov 2024 23:36:37 GMT, Leonid Mesnik wrote: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... This pull request has now been integrated. Changeset: 98b66783 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/98b667834c4a8f0d0ab54b8133061bc475674732 Stats: 494 lines in 19 files changed: 415 ins; 70 del; 9 mod 8343741: SA jstack --mixed should print information about VM locks Reviewed-by: cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/22171 From lmesnik at openjdk.org Fri Nov 22 19:43:14 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 22 Nov 2024 19:43:14 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 09:14:30 GMT, Kevin Walls wrote: > Remove redundant SecurityManager Permission references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22315#pullrequestreview-2455494106 From wkemper at openjdk.org Fri Nov 22 22:38:02 2024 From: wkemper at openjdk.org (William Kemper) Date: Fri, 22 Nov 2024 22:38:02 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v9] In-Reply-To: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: <4AQkQIp1NjzLOj76FbXQ8HRcLhkjATlIHV4122VHjSE=.1fd8a480-070c-4133-acfd-0e051e9bdbce@github.com> > This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 528 commits: - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux - Merge - 8344779: GenShen: Consolidate shared heap region closures into one header Reviewed-by: kdnilsen, ysr - 8344797: GenShen: Update and rename confusing method Reviewed-by: ysr, kdnilsen - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux - 8344670: GenShen: Use concurrent worker session for concurrent mark phase Reviewed-by: kdnilsen - 8344640: GenShen: Reuse existing card mark barrier function when dropping references Reviewed-by: shade, ysr - 8344592: GenShen: Remove unnecessary comments and changes Reviewed-by: kdnilsen - 8344263: GenShen: Reduce extraneous log messages at INFO level Reviewed-by: ysr, shade - 8344638: GenShen: Verifier should not touch claim token Reviewed-by: shade - ... and 518 more: https://git.openjdk.org/jdk/compare/4fbf2720...7eea1d5c ------------- Changes: https://git.openjdk.org/jdk/pull/21273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=08 Stats: 22940 lines in 229 files changed: 21170 ins; 911 del; 859 mod Patch: https://git.openjdk.org/jdk/pull/21273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21273/head:pull/21273 PR: https://git.openjdk.org/jdk/pull/21273 From iklam at openjdk.org Sat Nov 23 03:31:03 2024 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 23 Nov 2024 03:31:03 GMT Subject: RFR: 8344904: Interned strings in old classes are not stored in AOT cache Message-ID: Before this fix, CDS will only archive interned strings that are reachable from `ConstantPool::resolved_references()`, which is created only after a class is linked. However, old classes are not linked, so we didn't archive their interned strings. It's possible for the Java mirror of an (unlinked) old class to point to interned strings. E.g., public super class OldClassWithStaticString version 49:0 { public static final Field s:"Ljava/lang/String;" = String "xxxx123yyyy456"; The 's' field is initialized during class file parsing, so we must intern the `"xxxx123yyyy456"` string. The fix is to collect interned strings from the static fields of unlinked classes. ------------- Commit messages: - 8344904: Interned strings in old classes are not stored in AOT cache Changes: https://git.openjdk.org/jdk/pull/22340/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22340&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344904 Stats: 153 lines in 5 files changed: 142 ins; 2 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/22340.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22340/head:pull/22340 PR: https://git.openjdk.org/jdk/pull/22340 From alanb at openjdk.org Sat Nov 23 10:03:31 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 23 Nov 2024 10:03:31 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 09:14:30 GMT, Kevin Walls wrote: > Remove redundant SecurityManager Permission references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). This is a change to the spec of a JDK specific API so I think should be tracked by a CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22315#issuecomment-2495367950 From amitkumar at openjdk.org Sat Nov 23 12:31:24 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Sat, 23 Nov 2024 12:31:24 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter Message-ID: s390x Port for : [JDK-8331341](https://bugs.openjdk.org/browse/JDK-8331341) ------------- Commit messages: - tab to whitespaces - s390x: secondary supers table Changes: https://git.openjdk.org/jdk/pull/22341/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22341&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339983 Stats: 459 lines in 6 files changed: 351 ins; 50 del; 58 mod Patch: https://git.openjdk.org/jdk/pull/22341.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22341/head:pull/22341 PR: https://git.openjdk.org/jdk/pull/22341 From iklam at openjdk.org Sun Nov 24 00:30:38 2024 From: iklam at openjdk.org (Ioi Lam) Date: Sun, 24 Nov 2024 00:30:38 GMT Subject: RFR: 8344140: Refactor the discovery of AOT cache artifacts [v2] In-Reply-To: References: Message-ID: > This is a clean up after the initial integration for [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) > > - Merged 3 loops into 1 for discovering the classes and oops that should be stored in the AOT cache. About 250 lines of code are deleted. > - Added comments in aotArtifactFinder.hpp to describe the logic, which is much simpler than before. > - Enum classes are no longer unconditionally AOT-initialized -- an Enum class is AOT-initialized only if we find an archived oop of this type. > > Note to reviewers: > > One consequence of this refactoring is that archived oops are now discovered (by heapShared.cpp) before the metadata are copied (by ArchiveBuilder). There are some functions that depend on the old order (metadata were copied before oop discovery), so I had to shuffle them around. Examples are `Modules::check_archived_module_oop()`, or the new code in `Klass::remove_java_mirror()`. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixe 32-bit builds; removed unused function ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22291/files - new: https://git.openjdk.org/jdk/pull/22291/files/be0ef2ee..29946dda Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22291&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22291&range=00-01 Stats: 19 lines in 3 files changed: 14 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22291.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22291/head:pull/22291 PR: https://git.openjdk.org/jdk/pull/22291 From kim.barrett at oracle.com Sun Nov 24 08:21:23 2024 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 24 Nov 2024 03:21:23 -0500 Subject: HotSpot doesn't use NULL Message-ID: <0298f200-cdcc-40d0-9926-a5c0436c6092@oracle.com> A reminder that we don't use NULL in HotSpot code anymore. We had a large batch of changes to remove uses of NULL in early 2023 (thanks to Johan Sj?len), and another batch in early 2024 (by various folks). Since then we've had a couple of cleanups of backsliding in this area - JDK-8327171 and JDK-8342860. In the last 2 weeks (since the most recent of those cleanups), it seems we've had a flurry of new uses being introduced - JDK-8344917. Hopefully we'll get a fix for JDK-8343802 soon. From kbarrett at openjdk.org Sun Nov 24 11:32:07 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 24 Nov 2024 11:32:07 GMT Subject: RFR: 8344917: Fix recent NULL usage backsliding Message-ID: Please review this trivial fix of some recently introduced uses of NULL in HotSpot. Testing: mach5 tier1 GHA sanity tests ------------- Commit messages: - fix NULL backsliding Changes: https://git.openjdk.org/jdk/pull/22348/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22348&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344917 Stats: 9 lines in 7 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/22348.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22348/head:pull/22348 PR: https://git.openjdk.org/jdk/pull/22348 From jsjolen at openjdk.org Sun Nov 24 11:59:12 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Sun, 24 Nov 2024 11:59:12 GMT Subject: RFR: 8344917: Fix recent NULL usage backsliding In-Reply-To: References: Message-ID: On Sun, 24 Nov 2024 11:26:25 GMT, Kim Barrett wrote: > Please review this trivial fix of some recently introduced uses of NULL in HotSpot. > > Testing: > mach5 tier1 > GHA sanity tests LGTM and trivial ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22348#pullrequestreview-2456692829 From kbarrett at openjdk.org Sun Nov 24 17:13:21 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 24 Nov 2024 17:13:21 GMT Subject: RFR: 8344917: Fix recent NULL usage backsliding In-Reply-To: References: Message-ID: <89sMSxfwXC6Fl0Xgnoh6XrtccQ_bzSeLY6ayV_m6W8A=.969a077d-0742-4e85-b564-ef7e6aa0bb32@github.com> On Sun, 24 Nov 2024 11:57:06 GMT, Johan Sj?len wrote: >> Please review this trivial fix of some recently introduced uses of NULL in HotSpot. >> >> Testing: >> mach5 tier1 >> GHA sanity tests > > LGTM and trivial Thanks for review @jdksjolen ------------- PR Comment: https://git.openjdk.org/jdk/pull/22348#issuecomment-2496112663 From kbarrett at openjdk.org Sun Nov 24 17:13:21 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 24 Nov 2024 17:13:21 GMT Subject: Integrated: 8344917: Fix recent NULL usage backsliding In-Reply-To: References: Message-ID: On Sun, 24 Nov 2024 11:26:25 GMT, Kim Barrett wrote: > Please review this trivial fix of some recently introduced uses of NULL in HotSpot. > > Testing: > mach5 tier1 > GHA sanity tests This pull request has now been integrated. Changeset: a83cfe26 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/a83cfe26583db078ecd754d9609111c0c6dac6a4 Stats: 9 lines in 7 files changed: 0 ins; 0 del; 9 mod 8344917: Fix recent NULL usage backsliding Reviewed-by: jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/22348 From haosun at openjdk.org Mon Nov 25 01:10:21 2024 From: haosun at openjdk.org (Hao Sun) Date: Mon, 25 Nov 2024 01:10:21 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Thu, 21 Nov 2024 02:41:47 GMT, Hao Sun wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 6. Auto-vectorization of newly supported scalar operations. >> 7. X86 and AARCH64 backend implementation for all supported intrinsics. >> 9. Functional and Performance validation tests. >> >> **Missing Pieces:-** >> **- AARCH64 Backend.** >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Hi, > > Better to update the copyright year to 2024 for the following modified files: > > > src/hotspot/share/adlc/output_h.cpp > src/hotspot/share/opto/connode.cpp > src/hotspot/share/opto/connode.hpp > src/hotspot/share/opto/constantTable.cpp > src/hotspot/share/opto/divnode.cpp > src/hotspot/share/opto/divnode.hpp > src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/amd64/AMD64.java > test/hotspot/jtreg/compiler/lib/ir_framework/test/IREncodingPrinter.java > > > I encountered one JTreg IR failure on AArch64 machine with SVE feature for `test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java` case. Here shows a snippet of the error log. > If AArch64 backend part is not implemented, we'd better skip the IR verification on AArch64+SVE side. > > > One or more @IR rules failed: > > Failed IR Rules (9) of Methods (9) ---------------------------------- > 1) Method "public void compiler.vectorization.TestFloat16VectorOperations.vectorAddFloat16()" - [Failed IR rules: 1]: * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"avx512_fp16", "true", "sve", "true"}, counts={"_#ADD_VHF#_", ">= 1" > }, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > > Phase "PrintIdeal": > - counts: Graph contains wrong number of nodes: > * Constraint 1: "(\d+(\s){2}(AddVHF.*)+(\s){2}===.*)" ... > Hi @shqking , thanks for your review. I am currently working on adding the aarch64 port for these operations. It's being done here - [jatin-bhateja#6](https://github.com/jatin-bhateja/jdk/pull/6). Do you think it's ok to keep the code (regarding aarch64) in this patch as is for some more time until my patch is rebased and merged? Hi @Bhavana-Kilambi , I would suggest making this patch as a clean one, i.e. better to move AArch64 related code to as one separate PR mainly because it may still take some time to review/merge your patch and we'd better **not** merge this PR with known jtreg failure. I noticed @jatin-bhateja has uploaded the cleanup commit and I will check the jtreg test on AArch64+SVE side. Will report the result back when the test finishes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2496479249 From dholmes at openjdk.org Mon Nov 25 01:19:15 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 25 Nov 2024 01:19:15 GMT Subject: RFR: 8344904: Interned strings in old classes are not stored in AOT cache In-Reply-To: References: Message-ID: On Sat, 23 Nov 2024 03:25:44 GMT, Ioi Lam wrote: > Before this fix, CDS will only archive interned strings that are reachable from `ConstantPool::resolved_references()`, which is created only after a class is linked. However, old classes are not linked, so we didn't archive their interned strings. > > It's possible for the Java mirror of an (unlinked) old class to point to interned strings. E.g., > > > public super class OldClassWithStaticString > version 49:0 > { > public static final Field s:"Ljava/lang/String;" = String "xxxx123yyyy456"; > > > The 's' field is initialized during class file parsing, so we must intern the `"xxxx123yyyy456"` string. > > The fix is to collect interned strings from the static fields of unlinked classes. Looks good, just a couple of nits. Plus if this is only about the CDS archive can we say that in the title instead of AOT cache? IIUC this is an existing CDS issue and unrelated to any recent AOT/Leyden integrations - right? Thanks src/hotspot/share/oops/constantPool.cpp line 411: > 409: if (!ik->is_linked()) { > 410: // resolved_references() doesn't exist yet, so we have no resolved CONSTANT_String entries. However, > 411: // Some static final fields may have default values that were initialized when the class was parsed. Suggestion: // some static final fields may have default values that were initialized when the class was parsed. src/hotspot/share/oops/constantPool.cpp line 412: > 410: // resolved_references() doesn't exist yet, so we have no resolved CONSTANT_String entries. However, > 411: // Some static final fields may have default values that were initialized when the class was parsed. > 412: // We need to enter those into the CDS archived strings table. Suggestion: // We need to enter those into the CDS archive strings table. test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/OldClassWithStaticString.jasm line 35: > 33: > 34: public super class OldClassWithStaticString > 35: version 49:0 Is this a jasm file only because we need the version 49? If so please state that somewhere. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22340#pullrequestreview-2456930916 PR Review Comment: https://git.openjdk.org/jdk/pull/22340#discussion_r1855654832 PR Review Comment: https://git.openjdk.org/jdk/pull/22340#discussion_r1855654994 PR Review Comment: https://git.openjdk.org/jdk/pull/22340#discussion_r1855656916 From dholmes at openjdk.org Mon Nov 25 04:18:21 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 25 Nov 2024 04:18:21 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v4] In-Reply-To: <00t4bv6pSjmB-nOYziAApdamEvxsXovEzRwdP9yLA7w=.4b1d9289-00a7-4f82-a8f9-6d8d3174f5cd@github.com> References: <00t4bv6pSjmB-nOYziAApdamEvxsXovEzRwdP9yLA7w=.4b1d9289-00a7-4f82-a8f9-6d8d3174f5cd@github.com> Message-ID: On Fri, 22 Nov 2024 17:25:54 GMT, Calvin Cheung wrote: >> Currently, when retrieving a ClassFileStream during runtime, we call into the zip library to retrieve the stream based only on a class name. This doesn't work well if the class is in a multi-release jar under a versioned directory such as `META-INF/versions/9/Foo.class`. To address this issue, this change calls the java api `ClassLoader.getResourceAsStream()` to retrieve the stream. >> >> Passed tiers 1 - 4 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > update comments src/hotspot/share/cds/filemap.cpp line 2718: > 2716: // The result should be a [B > 2717: assert(obj->is_typeArray(), "just checking"); > 2718: assert(TypeArrayKlass::cast(obj->klass())->element_type() == T_BYTE, "just checking"); This seems unnecessary. What kind of errors are you trying to detect with this? The method signature indicates it returns a byte-array. src/hotspot/share/cds/filemap.cpp line 2728: > 2726: return new ClassFileStream(buffer, > 2727: len, > 2728: cpe->name()); Suggestion: return new ClassFileStream(buffer, len, cpe->name()); src/java.base/share/classes/java/lang/ClassLoader.java line 1698: > 1696: } catch (IOException e) { > 1697: return null; > 1698: } Any `IOException` should just be left pending so that it gets reported eventually. Otherwise you are returning null here but asserting in the VM that null is never returned. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22262#discussion_r1855752520 PR Review Comment: https://git.openjdk.org/jdk/pull/22262#discussion_r1855752795 PR Review Comment: https://git.openjdk.org/jdk/pull/22262#discussion_r1855756738 From iklam at openjdk.org Mon Nov 25 04:23:26 2024 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 25 Nov 2024 04:23:26 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v4] In-Reply-To: <00t4bv6pSjmB-nOYziAApdamEvxsXovEzRwdP9yLA7w=.4b1d9289-00a7-4f82-a8f9-6d8d3174f5cd@github.com> References: <00t4bv6pSjmB-nOYziAApdamEvxsXovEzRwdP9yLA7w=.4b1d9289-00a7-4f82-a8f9-6d8d3174f5cd@github.com> Message-ID: On Fri, 22 Nov 2024 17:25:54 GMT, Calvin Cheung wrote: >> Currently, when retrieving a ClassFileStream during runtime, we call into the zip library to retrieve the stream based only on a class name. This doesn't work well if the class is in a multi-release jar under a versioned directory such as `META-INF/versions/9/Foo.class`. To address this issue, this change calls the java api `ClassLoader.getResourceAsStream()` to retrieve the stream. >> >> Passed tiers 1 - 4 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > update comments LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22262#pullrequestreview-2457107588 From iklam at openjdk.org Mon Nov 25 04:32:22 2024 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 25 Nov 2024 04:32:22 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v2] In-Reply-To: References: <-ItmDmV4oovdAbnojC5s4h3JIKozNKHIMm4SwilR_BE=.9dfbdca7-c435-4c1a-88d6-cd6425bacfb3@github.com> Message-ID: On Thu, 21 Nov 2024 23:11:40 GMT, Calvin Cheung wrote: >> I think the concern may be that we want to avoid license headers. >> >> However, we should still use text blocks instead of these string arrays for such inlined source files. > > I've changed the code to use text blocks. We have two versions of the "Foo" class, but jtreg doesn't support building of classes with the same name. If you look at other multi-release JAR test cases, they all have to build the classes by hand. Embedded the Java sources in the test case is actually simpler than these existing tests: - https://github.com/openjdk/jdk/blob/6f622da7fbae67d8c1cd9e795127adac58a246a9/test/jdk/tools/jar/multiRelease/MRTestBase.java - https://github.com/openjdk/jdk/blob/6f622da7fbae67d8c1cd9e795127adac58a246a9/test/jdk/tools/jar/multiRelease/Basic.java ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22262#discussion_r1855784099 From haosun at openjdk.org Mon Nov 25 06:24:24 2024 From: haosun at openjdk.org (Hao Sun) Date: Mon, 25 Nov 2024 06:24:24 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 01:07:43 GMT, Hao Sun wrote: > > Hi @shqking , thanks for your review. I am currently working on adding the aarch64 port for these operations. It's being done here - [jatin-bhateja#6](https://github.com/jatin-bhateja/jdk/pull/6). Do you think it's ok to keep the code (regarding aarch64) in this patch as is for some more time until my patch is rebased and merged? > > Hi @Bhavana-Kilambi , I would suggest making this patch as a clean one, i.e. better to move AArch64 related code to as one separate PR mainly because it may still take some time to review/merge your patch and we'd better **not** merge this PR with known jtreg failure. I noticed @jatin-bhateja has uploaded the cleanup commit and I will check the jtreg test on AArch64+SVE side. Will report the result back when the test finishes. Previous test failure in file `TestFloat16VectorOperations.java` is gone now. tier1~3 passed on AArch64+SVE side. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2496961595 From epeter at openjdk.org Mon Nov 25 08:05:36 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 25 Nov 2024 08:05:36 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations [v2] In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 10:36:10 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 6. Auto-vectorization of newly supported scalar operations. >> 7. X86 and AARCH64 backend implementation for all supported intrinsics. >> 9. Functional and Performance validation tests. >> >> **Missing Pieces:-** >> **- AARCH64 Backend.** >> >> 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: > > Testpoints for new value transforms + code cleanups Wow, thanks for tackling this! Ok, lots of style comments. But again: I would have loved to see this split up into these parts: - Scalar - Scalar optimizations (value, ideal, identity) - Vector This will again take many many week to get reviewed because it is a 3k+ change with lots of details. Do you have any tests for the scalar constant folding optimizations? I did not find them. src/hotspot/cpu/x86/x86.ad line 10910: > 10908: %} > 10909: > 10910: instruct convF2HFAndS2HF(regF dst, regF src) I'm starting to see that you use sometimes `H` and sometimes `HF`. That needs to be consistent - unless they are 2 different things? src/hotspot/cpu/x86/x86.ad line 10930: > 10928: %} > 10929: > 10930: instruct scalar_sqrt_fp16_reg(regF dst, regF src) Hmm, and them you also use `fp16`... so now we have `H`, `HF` and `fp16`... src/hotspot/share/opto/addnode.cpp line 713: > 711: //------------------------------add_of_identity-------------------------------- > 712: // Check for addition of the identity > 713: const Type *AddHFNode::add_of_identity(const Type *t1, const Type *t2) const { I would generally drop out these comments, unless they actually have something useful to say that the name does not say. You could make a comment why you are returning `nullptr`, i.e. doing nothing. And for style: the `*` belongs with the type ;) Suggestion: const Type* AddHFNode::add_of_identity(const Type* t1, const Type* t2) const { src/hotspot/share/opto/addnode.cpp line 721: > 719: // This also type-checks the inputs for sanity. Guaranteed never to > 720: // be passed a TOP or BOTTOM type, these are filtered out by pre-check. > 721: const Type *AddHFNode::add_ring(const Type *t0, const Type *t1) const { Suggestion: // Supplied function returns the sum of the inputs. // This also type-checks the inputs for sanity. Guaranteed never to // be passed a TOP or BOTTOM type, these are filtered out by pre-check. const Type* AddHFNode::add_ring(const Type* t0, const Type* t1) const { Here the comments are great :) src/hotspot/share/opto/addnode.cpp line 1625: > 1623: > 1624: // handle min of 0.0, -0.0 case. > 1625: return (jint_cast(f0) < jint_cast(f1)) ? r0 : r1; Can you please add some comments for this here? Why is there an int-case on floats? Why not just do the ternary comparison on line 1621: `return f0 < f1 ? r0 : r1;`? src/hotspot/share/opto/addnode.hpp line 179: > 177: virtual Node* Identity(PhaseGVN* phase) { return this; } > 178: virtual uint ideal_reg() const { return Op_RegF; } > 179: }; Please put the `*` with the type everywhere. src/hotspot/share/opto/connode.cpp line 49: > 47: switch( t->basic_type() ) { > 48: case T_INT: return new ConINode( t->is_int() ); > 49: case T_SHORT: return new ConHNode( t->is_half_float_constant() ); That will be quite confusing.... don't you think? src/hotspot/share/opto/connode.hpp line 122: > 120: class ConHNode : public ConNode { > 121: public: > 122: ConHNode( const TypeH *t ) : ConNode(t) {} Suggestion: ConHNode(const TypeH* t) : ConNode(t) {} src/hotspot/share/opto/connode.hpp line 129: > 127: return new ConHNode( TypeH::make(con) ); > 128: } > 129: Suggestion: src/hotspot/share/opto/convertnode.cpp line 256: > 254: //------------------------------Ideal------------------------------------------ > 255: Node* ConvF2HFNode::Ideal(PhaseGVN* phase, bool can_reshape) { > 256: // Optimize pattern - ConvHF2F (FP32BinOp) ConvF2HF ==> ReinterpretS2HF (FP16BinOp) ReinterpretHF2S. This is a little dense and I don't understand your notation. So we are pattern matching: `ConvF2HF( FP32BinOp(ConvHF2F(x), ConvHF2F(y)) )` <- I think that would be more readable. You could also create local variables for `x` and `y`, just so it is more readable. And then instead we generate: `ReinterpretHF2S(FP16BinOp(ReinterpretS2HF(x), ReinterpretS2HF(y)))` Ok, so you are saying why lift to FP32, if we cast down to FP16 anyway... would be nice to have such a comment at the top to motivate the optimization! What confuses me a little here: why do we even have to cast from and to `short` here? Maybe a quick comment about that would also help. src/hotspot/share/opto/convertnode.cpp line 948: > 946: } > 947: > 948: bool Float16NodeFactory::is_binary_oper(int opc) { Suggestion: bool Float16NodeFactory::is_float32_binary_oper(int opc) { Just so it is explicit, since you have the parallel `get_float16_binary_oper` below. src/hotspot/share/opto/convertnode.hpp line 234: > 232: class ReinterpretHF2SNode : public Node { > 233: public: > 234: ReinterpretHF2SNode( Node *in1 ) : Node(0,in1) {} Suggestion: ReinterpretHF2SNode(Node* in1) : Node(0, in1) {} src/hotspot/share/opto/divnode.cpp line 759: > 757: const Type* t2 = phase->type(in(2)); > 758: if(t1 == Type::TOP) return Type::TOP; > 759: if(t2 == Type::TOP) return Type::TOP; Suggestion: if(t1 == Type::TOP) { return Type::TOP; } if(t2 == Type::TOP) { return Type::TOP; } Please use the brackets consistently. src/hotspot/share/opto/divnode.cpp line 765: > 763: if((t1 == bot) || (t2 == bot) || > 764: (t1 == Type::BOTTOM) || (t2 == Type::BOTTOM)) > 765: return bot; Suggestion: if((t1 == bot) || (t2 == bot) || (t1 == Type::BOTTOM) || (t2 == Type::BOTTOM)) { return bot; } Again: please always use brackets. src/hotspot/share/opto/divnode.cpp line 776: > 774: > 775: if(t2 == TypeH::ONE) > 776: return t1; brackets src/hotspot/share/opto/divnode.cpp line 782: > 780: t2->base() == Type::HalfFloatCon && > 781: t2->getf() != 0.0) // could be negative zero > 782: return TypeH::make(t1->getf()/t2->getf()); Suggestion: // If divisor is a constant and not zero, divide the numbers if(t1->base() == Type::HalfFloatCon && t2->base() == Type::HalfFloatCon && t2->getf() != 0.0) { // could be negative zero return TypeH::make(t1->getf() / t2->getf()); } src/hotspot/share/opto/divnode.cpp line 789: > 787: > 788: if(t1 == TypeH::ZERO && !g_isnan(t2->getf()) && t2->getf() != 0.0) > 789: return TypeH::ZERO; brackets for if Ok, why not also do it for negative zero then? src/hotspot/share/opto/divnode.cpp line 797: > 795: //------------------------------isA_Copy--------------------------------------- > 796: // Dividing by self is 1. > 797: // If the divisor is 1, we are an identity on the dividend. Suggestion: // If the divisor is 1, we are an identity on the dividend. `Dividing by self is 1.` That does not seem to apply here. Maybe you meant `dividing by 1 is self`? src/hotspot/share/opto/divnode.cpp line 804: > 802: > 803: //------------------------------Idealize--------------------------------------- > 804: Node *DivHFNode::Ideal(PhaseGVN* phase, bool can_reshape) { Suggestion: Node* DivHFNode::Ideal(PhaseGVN* phase, bool can_reshape) { src/hotspot/share/opto/divnode.cpp line 805: > 803: //------------------------------Idealize--------------------------------------- > 804: Node *DivHFNode::Ideal(PhaseGVN* phase, bool can_reshape) { > 805: if (in(0) && remove_dead_region(phase, can_reshape)) return this; Suggestion: if (in(0) != nullptr && remove_dead_region(phase, can_reshape)) { return this; } brackets for if and no implicit null checks please! src/hotspot/share/opto/divnode.cpp line 814: > 812: > 813: const TypeH* tf = t2->isa_half_float_constant(); > 814: if(!tf) return nullptr; no implicit booleans! src/hotspot/share/opto/divnode.cpp line 836: > 834: > 835: // return multiplication by the reciprocal > 836: return (new MulHFNode(in(1), phase->makecon(TypeH::make(reciprocal)))); Do we have good tests for this optimization? src/hotspot/share/opto/mulnode.cpp line 559: > 557: > 558: // Compute the product type of two half float ranges into this node. > 559: const Type *MulHFNode::mul_ring(const Type *t0, const Type *t1) const { Suggestion: const Type* MulHFNode::mul_ring(const Type* t0, const Type* t1) const { src/hotspot/share/opto/mulnode.cpp line 561: > 559: const Type *MulHFNode::mul_ring(const Type *t0, const Type *t1) const { > 560: if( t0 == Type::HALF_FLOAT || t1 == Type::HALF_FLOAT ) return Type::HALF_FLOAT; > 561: return TypeH::make( t0->getf() * t1->getf() ); I hope that `TypeH::make` handles the overflow cases well... does it? And do we have tests for this? src/hotspot/share/opto/mulnode.cpp line 1945: > 1943: return TypeH::make(fma(f1, f2, f3)); > 1944: #endif > 1945: } I need: - brackets for ifs - all `*` on the left with the type - An explanation what the `ifdef __STDC_IEC_559__` does. src/hotspot/share/opto/mulnode.hpp line 155: > 153: virtual const Type *mul_ring( const Type *, const Type * ) const; > 154: const Type *mul_id() const { return TypeH::ONE; } > 155: const Type *add_id() const { return TypeH::ZERO; } Suggestion: const Type* mul_id() const { return TypeH::ONE; } const Type* add_id() const { return TypeH::ZERO; } src/hotspot/share/opto/mulnode.hpp line 160: > 158: int max_opcode() const { return Op_MaxHF; } > 159: int min_opcode() const { return Op_MinHF; } > 160: const Type *bottom_type() const { return Type::HALF_FLOAT; } Suggestion: const Type* bottom_type() const { return Type::HALF_FLOAT; } src/hotspot/share/opto/subnode.cpp line 1975: > 1973: if( f < 0.0f ) return Type::HALF_FLOAT; > 1974: return TypeH::make( (float)sqrt( (double)f ) ); > 1975: } if brackets and asterisks with types please src/hotspot/share/opto/subnode.hpp line 143: > 141: const Type *bottom_type() const { return Type::HALF_FLOAT; } > 142: virtual uint ideal_reg() const { return Op_RegF; } > 143: }; Suggestion: //------------------------------SubHFNode-------------------------------------- // Subtract 2 half floats class SubHFNode : public SubFPNode { public: SubHFNode(Node* in1, Node* in2) : SubFPNode(in1, in2) {} virtual int Opcode() const; virtual const Type* sub(const Type *, const Type *) const; const Type* add_id() const { return TypeH::ZERO; } const Type* bottom_type() const { return Type::HALF_FLOAT; } virtual uint ideal_reg() const { return Op_RegF; } }; src/hotspot/share/opto/subnode.hpp line 552: > 550: } > 551: virtual int Opcode() const; > 552: const Type *bottom_type() const { return Type::HALF_FLOAT; } Suggestion: const Type* bottom_type() const { return Type::HALF_FLOAT; } src/hotspot/share/opto/type.cpp line 1487: > 1485: typerr(t); > 1486: > 1487: case HalfFloatCon: // Float-constant vs Float-constant? Suggestion: case HalfFloatCon: // Float-constant vs Float-constant? ------------- Changes requested by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21490#pullrequestreview-2457382009 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855943470 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855944584 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855948500 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855950333 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855954166 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855955074 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855958333 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855958773 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855959025 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855977560 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855981273 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855982405 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855984366 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855985484 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855988545 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855989752 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855992127 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855994876 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855995436 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855996454 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1856000589 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1856002336 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1856007382 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1856006524 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1856009749 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1856010212 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1856010391 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1856013278 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1856013945 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1856014893 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1856016525 From epeter at openjdk.org Mon Nov 25 08:05:36 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 25 Nov 2024 08:05:36 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations [v2] In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 07:17:33 GMT, Emanuel Peter wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Testpoints for new value transforms + code cleanups > > src/hotspot/share/opto/connode.cpp line 49: > >> 47: switch( t->basic_type() ) { >> 48: case T_INT: return new ConINode( t->is_int() ); >> 49: case T_SHORT: return new ConHNode( t->is_half_float_constant() ); > > That will be quite confusing.... don't you think? I mean do we need this? We already have `ConHNode::make` below...? > src/hotspot/share/opto/divnode.cpp line 765: > >> 763: if((t1 == bot) || (t2 == bot) || >> 764: (t1 == Type::BOTTOM) || (t2 == Type::BOTTOM)) >> 765: return bot; > > Suggestion: > > if((t1 == bot) || (t2 == bot) || > (t1 == Type::BOTTOM) || (t2 == Type::BOTTOM)) { > return bot; > } > > Again: please always use brackets. Apply the same below. > src/hotspot/share/opto/divnode.cpp line 804: > >> 802: >> 803: //------------------------------Idealize--------------------------------------- >> 804: Node *DivHFNode::Ideal(PhaseGVN* phase, bool can_reshape) { > > Suggestion: > > Node* DivHFNode::Ideal(PhaseGVN* phase, bool can_reshape) { Ok, and please add brackets for all the ifs below! > src/hotspot/share/opto/divnode.cpp line 805: > >> 803: //------------------------------Idealize--------------------------------------- >> 804: Node *DivHFNode::Ideal(PhaseGVN* phase, bool can_reshape) { >> 805: if (in(0) && remove_dead_region(phase, can_reshape)) return this; > > Suggestion: > > if (in(0) != nullptr && remove_dead_region(phase, can_reshape)) { return this; } > > brackets for if and no implicit null checks please! https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md `Do not use ints or pointers as (implicit) booleans with &&, ||, if, while. Instead, compare explicitly, i.e. if (x != 0) or if (ptr != nullptr), etc.` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855959810 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855985811 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855995743 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1855999519 From epeter at openjdk.org Mon Nov 25 08:05:36 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 25 Nov 2024 08:05:36 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations [v2] In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 11:45:34 GMT, Bhavana Kilambi wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Testpoints for new value transforms + code cleanups > > src/hotspot/share/opto/node.cpp line 1600: > >> 1598: >> 1599: // Get a half float constant from a ConstNode. >> 1600: // Returns the constant if it is a float ConstNode > > half float ConstNode? Suggestion: // Returns the constant if it is a half float ConstNode ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1856011460 From jbhateja at openjdk.org Mon Nov 25 08:20:22 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 25 Nov 2024 08:20:22 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations [v2] In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 08:02:55 GMT, Emanuel Peter wrote: > Wow, thanks for tackling this! > > Ok, lots of style comments. > > But again: I would have loved to see this split up into these parts: > > * Scalar > * Scalar optimizations (value, ideal, identity) > * Vector > > This will again take many many week to get reviewed because it is a 3k+ change with lots of details. > > Do you have any tests for the scalar constant folding optimizations? I did not find them. Hey @eme64 , The patch includes IR framework-based scalar constant folding test points. https://github.com/openjdk/jdk/blob/5f58eea62a0f4d2cd731242a0fb264316ff5000d/test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java#L170 Regarding vector operation inferencing, we are taking the standard route by adding new Vector IR and associated VectorNode::Opcode / making routine changes without changing the auto-vectorization core. Each new vector operation is backed by IR framework-based tests. https://github.com/openjdk/jdk/pull/21490/files#diff-30af2f4d6a92733f58967b0feab21ddbc58a8f1ac5d3d5660c0f60220f6fab0dR40 Our target is to get this integrated before JDK24-RDP1, your help and reviews will be highly appreciated. Best Regards ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2497192437 From epeter at openjdk.org Mon Nov 25 08:54:20 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 25 Nov 2024 08:54:20 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations [v2] In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 10:36:10 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 6. Auto-vectorization of newly supported scalar operations. >> 7. X86 and AARCH64 backend implementation for all supported intrinsics. >> 9. Functional and Performance validation tests. >> >> **Missing Pieces:-** >> **- AARCH64 Backend.** >> >> 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: > > Testpoints for new value transforms + code cleanups test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java line 37: > 35: * @modules jdk.incubator.vector > 36: * @library /test/lib / > 37: * @requires vm.compiler2.enabled Is this necessary, to restrict to C2? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1856158768 From epeter at openjdk.org Mon Nov 25 08:59:26 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 25 Nov 2024 08:59:26 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations [v2] In-Reply-To: References: Message-ID: <2t1Bka2nUU4K1Uqe3iy3Q5aFzriK2pTpZYqK9Zjyg0s=.a77d89c2-4edc-4d6c-94a3-5a350c921267@github.com> On Fri, 22 Nov 2024 10:36:10 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 6. Auto-vectorization of newly supported scalar operations. >> 7. X86 and AARCH64 backend implementation for all supported intrinsics. >> 9. Functional and Performance validation tests. >> >> **Missing Pieces:-** >> **- AARCH64 Backend.** >> >> 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: > > Testpoints for new value transforms + code cleanups I heard no argument about why you did not split this up. Please do that in the future. It is hard to review well when there is this much code. If it is really necessary, then sure. Here it does not seem necessary to deliver all at once. > The patch includes IR framework-based scalar constant folding test points. You mention this IR test: https://github.com/openjdk/jdk/pull/21490/files#diff-3f8786f9f62662eda4b4a5c76c01fa04534c94d870d496501bfc20434ad45579R169-R174 Here I only see the use of very trivial values. I think we need more complicated cases. What about these: - Add/Sub/Mul/Div/Min/Max ... with NaN and infinity. - Same where it would overflow the FP16 range. - Negative zero tests. - Division by powers of 2. It would for example be nice if you could iterate over all inputs. FP16 with 2 inputs is only 32bits, that can be iterated in just a few seconds. Then you can run the computation with constants in the interpreter, and compare to the results in compiled code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2497315686 From amitkumar at openjdk.org Mon Nov 25 09:08:19 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 25 Nov 2024 09:08:19 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter In-Reply-To: References: Message-ID: On Sat, 23 Nov 2024 12:24:31 GMT, Amit Kumar wrote: > s390x Port for : [JDK-8331341](https://bugs.openjdk.org/browse/JDK-8331341) src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3218: > 3216: > 3217: assert(i * BytesPerWord + frame::z_abi_160_size == frame_size, "sanity"); > 3218: } push & pop could be moved to new method, likewise done by other archs. I need a second opinion on that as it looks like current solution is also okish. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1856183317 From amitkumar at openjdk.org Mon Nov 25 09:12:16 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 25 Nov 2024 09:12:16 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter In-Reply-To: References: Message-ID: On Sat, 23 Nov 2024 12:24:31 GMT, Amit Kumar wrote: > s390x Port for : [JDK-8331341](https://bugs.openjdk.org/browse/JDK-8331341) > > Tier1 test: > 1. `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` > 2. No flag turn on. i.e. used `UseSecondarySupersCache` by default. > 3. `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` with C1 compiler CC: @RealLucy ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22341#issuecomment-2497347264 From kevinw at openjdk.org Mon Nov 25 09:54:15 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 25 Nov 2024 09:54:15 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands In-Reply-To: References: Message-ID: On Sat, 23 Nov 2024 06:37:23 GMT, Alan Bateman wrote: > This is a change to the spec of a JDK specific API so I think should be tracked by a CSR. OK yes, I was looking for opinions on whether this needed a CSR. To be clear, the interface jdk.management / com.sun.management.DiagnosticCommandMBean has a method getDescriptor() which returns a Descriptor, which "is a collection of fields containing additional meta-data for a JMX element". This unfortunately does not say any of the metadata are optional, so now that a permission is meaningless we want to remove dcmd.permissionName, dcmd.permissionAction, dcmd.arguments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22315#issuecomment-2497457131 From jwaters at openjdk.org Mon Nov 25 10:16:25 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 25 Nov 2024 10:16:25 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9] In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 09:17:53 GMT, Julian Waters wrote: >> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely > > Julian Waters 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 16 additional commits since the last revision: > > - Merge branch 'openjdk:master' into hotspot > - Reintroduce ifdef removed in the nuking of the Windows 32 bit x86 port in sharedRuntimeRem.cpp > - fmod_win64 in sharedRuntime.cpp > - Should only declare fmod_win64 on Windows/ARM64 sharedRuntime.hpp > - fmod_win64 in src/hotspot/share/runtime/sharedRuntime.hpp > > Co-authored-by: Andrew Haley > - No spaces in test_os_windows.cpp > - No spaces in test/hotspot/gtest/runtime/test_os.cpp > > Co-authored-by: Andrew Haley > - Revise comment in sharedRuntime.hpp > - Revise comment in sharedRuntime.cpp > - size_t brace initialization instead of unsigned literals in test_os_windows.cpp > - ... and 6 more: https://git.openjdk.org/jdk/compare/434f4341...6cf1c83a Bump ------------- PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2497526047 From aph at openjdk.org Mon Nov 25 10:22:15 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 25 Nov 2024 10:22:15 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter In-Reply-To: References: Message-ID: On Sat, 23 Nov 2024 12:24:31 GMT, Amit Kumar wrote: > s390x Port for : [JDK-8331341](https://bugs.openjdk.org/browse/JDK-8331341) > > Tier1 test: > 1. `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` > 2. No flag turn on. i.e. used `UseSecondarySupersCache` by default. > 3. `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` with C1 compiler src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3178: > 3176: int slots = 0; > 3177: constexpr int NumRegs = 5; > 3178: Register* regs[NumRegs] = {&temp_reg, &temp2_reg, &temp3_reg, &temp4_reg, &result_reg}; You don't need this array. It contains information that is in `pushed_regs`. Use `pushed_regs.begin()` to create an iterator, which you use like this: int i = 0; for (auto it = pushed_regs.begin(); *it != noreg; ++it, i++) { z_stg(*it++, i * BytesPerWord + frame::z_abi_160_size, Z_SP); } src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3196: > 3194: > 3195: #ifdef ASSERT > 3196: assert(temp_reg != noreg, "temp_reg: sanity"); Suggestion: assert(temp_reg.is_valid(), "temp_reg: sanity"); src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3477: > 3475: z_xilf(slot, (u1)(Klass::SECONDARY_SUPERS_TABLE_SIZE - 1)); // slot ^ 63 === 63 - slot (mod 64) > 3476: z_sllg(r_array_index, r_bitmap, /*d2 = */ 0, /* b2 = */ slot); > 3477: Can you not use` slot xor 63` here? src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3521: > 3519: // So, negate slot and add 64 to it. i.e. 64 + (-slot) > 3520: z_lngr(slot, slot); // slot = -slot > 3521: z_aghi(slot, 64); // slot = slot + 64 And here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1856308683 PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1856314506 PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1856311453 PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1856312178 From rkennke at amazon.de Mon Nov 25 12:16:45 2024 From: rkennke at amazon.de (Kennke, Roman) Date: Mon, 25 Nov 2024 12:16:45 +0000 Subject: HotSpot doesn't use NULL In-Reply-To: <0298f200-cdcc-40d0-9926-a5c0436c6092@oracle.com> References: <0298f200-cdcc-40d0-9926-a5c0436c6092@oracle.com> Message-ID: <8BD53E0B-A928-4F59-AD14-1E8B88F8AE4C@amazon.de> Is it possible - and would it make sense - to mechanically forbit NULL? E.g. by re-defining it in a central place, just like we do for other stuff like constuctors for certain things? > On Nov 24, 2024, at 9:21?AM, Kim Barrett wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > A reminder that we don't use NULL in HotSpot code anymore. > > We had a large batch of changes to remove uses of NULL in early 2023 (thanks > to Johan Sj?len), and another batch in early 2024 (by various folks). Since > then we've had a couple of cleanups of backsliding in this area - > JDK-8327171 > and JDK-8342860. In the last 2 weeks (since the most recent of those > cleanups), it seems we've had a flurry of new uses being introduced - > JDK-8344917. > > Hopefully we'll get a fix for JDK-8343802 soon. > Amazon Web Services Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597 From azafari at openjdk.org Mon Nov 25 12:19:37 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 25 Nov 2024 12:19:37 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v3] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 21 Nov 2024 20:39:24 GMT, Robert Toyonaga wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> gc/x directory removed. > > src/hotspot/share/nmt/regionsTree.hpp line 33: > >> 31: >> 32: // RegionsTree extends VMATree to add some more specific API and also defines a helper >> 33: // for processing the tree nodes in a shorter and more menaingful way. > > Typo: "meaningful" Fixed, thanks. > src/hotspot/share/nmt/vmtCommon.cpp line 121: > >> 119: size_t aligned_stack_size = align_up(stack_size, os::vm_page_size()); >> 120: >> 121: ReservedMemoryRegion* region = const_cast(rgn); > > Is this still needed now that you're directly adding committed regions to the tree? I think this was only there before because it was adding committed regions to the `ReservedMemoryRegion`. Fixed. > src/hotspot/share/nmt/vmtCommon.cpp line 133: > >> 131: committed_size = stack_bottom + stack_size - committed_start; >> 132: } >> 133: VirtualMemoryTracker::Instance::add_committed_region(committed_start, committed_size, ncs); > > Is it a problem that it is never recorded that regions are uncommitted? Committed regions are added on-the-fly when reporting data, and those regions persist after reporting is done. So maybe it's possible to report too much committed size on a future report. The old implementation had this characteristic too. Uncommit for mtThreadStack are tracked when a thread exits and cleans/releases its stack. Here, the committed pages that are not reported yet to NMT are extracted. > src/hotspot/share/runtime/os.cpp line 2213: > >> 2211: res = pd_release_memory(addr, bytes); >> 2212: if (res) { >> 2213: ThreadCritical tc; > > What is the reason for moving `pd_release_memory` out of the protection of the lock? Wouldn't it be better if the memory operation and the accounting were done together atomically like with [`os::uncommit_memory`](https://github.com/openjdk/jdk/pull/20425/files#diff-c626d392182b0193ad0e754de3f4fd42c98d959edade67490b6e1f24be38efdbR2189) for example. TBH, I don't know and this is not a change in this PR. The uncommit_memory has the same approach. I just know that if we move the pd_xxxx inside the lock some tests fail or some assertions happen, but do not remember which and why. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1856515803 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1856517353 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1856515481 PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1856511664 From azafari at openjdk.org Mon Nov 25 12:24:45 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 25 Nov 2024 12:24:45 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v4] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. > - Adding a runtime flag for selecting the old or new version can be added later. > - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 47 commits: - Roberto's feedback applied. - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - gc/x directory removed. - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - added some descriptions of how VMT works. - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - fixes after merge with use_tag_inplace - fixed merged glitches. - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - ... and 37 more: https://git.openjdk.org/jdk/compare/b8b70c8b...026256ff ------------- Changes: https://git.openjdk.org/jdk/pull/20425/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=03 Stats: 3086 lines in 54 files changed: 1312 ins; 1525 del; 249 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From azafari at openjdk.org Mon Nov 25 12:27:45 2024 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 25 Nov 2024 12:27:45 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v5] In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - Both old and new versions exist in the code and can be selected via `MemTracker::set_version()` > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~ https://bugs.openjdk.org/browse/JDK-8335167. > - Adding a runtime flag for selecting the old or new version can be added later. > - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time. Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits: - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - Roberto's feedback applied. - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - gc/x directory removed. - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - added some descriptions of how VMT works. - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - fixes after merge with use_tag_inplace - fixed merged glitches. - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree - ... and 38 more: https://git.openjdk.org/jdk/compare/965aace2...451b9047 ------------- Changes: https://git.openjdk.org/jdk/pull/20425/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=04 Stats: 3092 lines in 54 files changed: 1315 ins; 1525 del; 252 mod Patch: https://git.openjdk.org/jdk/pull/20425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425 PR: https://git.openjdk.org/jdk/pull/20425 From amitkumar at openjdk.org Mon Nov 25 12:59:10 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 25 Nov 2024 12:59:10 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: References: Message-ID: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> > s390x Port for : [JDK-8331341](https://bugs.openjdk.org/browse/JDK-8331341) > > Tier1 test: > 1. `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` > 2. No flag turn on. i.e. used `UseSecondarySupersCache` by default. > 3. `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` with C1 compiler Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: suggestion from Andrew ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22341/files - new: https://git.openjdk.org/jdk/pull/22341/files/96a5b649..df8cf06f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22341&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22341&range=00-01 Stats: 37 lines in 1 file changed: 0 ins; 27 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/22341.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22341/head:pull/22341 PR: https://git.openjdk.org/jdk/pull/22341 From amitkumar at openjdk.org Mon Nov 25 12:59:11 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 25 Nov 2024 12:59:11 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 10:16:03 GMT, Andrew Haley wrote: >> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> suggestion from Andrew > > src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3178: > >> 3176: int slots = 0; >> 3177: constexpr int NumRegs = 5; >> 3178: Register* regs[NumRegs] = {&temp_reg, &temp2_reg, &temp3_reg, &temp4_reg, &result_reg}; > > You don't need this array. It contains information that is in `pushed_regs`. Use `pushed_regs.begin()` to create an iterator, which you use like this: > > > int i = 0; > for (auto it = pushed_regs.begin(); *it != noreg; ++it, i++) { > z_stg(*it++, i * BytesPerWord + frame::z_abi_160_size, Z_SP); > } done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1856571212 From gandrian at redhat.com Mon Nov 25 14:22:01 2024 From: gandrian at redhat.com (Georgios Andrianakis) Date: Mon, 25 Nov 2024 16:22:01 +0200 Subject: Lilliput impact on startup time Message-ID: Hi folks, I just tried the Lilliput (JEP 450) using the latest OpenJDK 24 EA build on a sample Quarkus application to see how beneficial Lilliput can be for us. On my machine (a Ryzen 5950X running Linux) with Lilliput disabled, the application starts up in around 600ms and consumes around 140MB of RSS memory (before the application handles any traffic). With Lilliput enabled (via -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders) I see RSS falling to around 130MB which is really nice! However I also see a startup regression of around 30ms (approximately 5%). Is this something that is expected? Thanks! P.S. Apologies if this is not the correct mailing list for Lilliput related topics -- Georgios Andrianakis Independent Contractor -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsjolen at openjdk.org Mon Nov 25 14:27:17 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 25 Nov 2024 14:27:17 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v4] In-Reply-To: References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: On Thu, 14 Nov 2024 13:53:19 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> This enhancement adds register printouts on asserts or guarantees into the hs_err_pid.log error reporting files for Windows. >> >> Additionally, it saves an accurate EXCEPTION_RECORD into the hs_err_pid.mdmp file, also for asserts or guarantees, so the assertion context is now easily accessible in Windbg using .ecxr. >> >> For more details on this enhancement, please see the JIRA issue. >> >> Testing: Tier 1,2,3, jdk_jfr >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > extended test Hi, This code looks good to me, with a small comment. src/hotspot/os/posix/os_posix.cpp line 2219: > 2217: // In the copied version, fpregs should point to the copied contents. > 2218: // Sanity check: fpregs should point into the context. > 2219: if ((address)((const ucontext_t*)ucVoid)->uc_mcontext.fpregs > (address)ucVoid) { Maybe check that the address is larger than ucVoid but smaller than `ucVoid + sizeof(ucontext_t)`? ```c++ const ucontext_t* uc = (const ucontext_t*)ucVoid; if (uc->uc_mcontext.fpregs >= (uintptr_t)uc && uc->uc_mcontext.fpregs < (uintptr_t)(uc + 1)) { } ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21994#pullrequestreview-2458582801 PR Review Comment: https://git.openjdk.org/jdk/pull/21994#discussion_r1856703906 From stefan.karlsson at oracle.com Mon Nov 25 14:43:56 2024 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 25 Nov 2024 15:43:56 +0100 Subject: Lilliput impact on startup time In-Reply-To: References: Message-ID: <309a93fc-d577-4f65-b2a2-a19c04d92773@oracle.com> Hi Georgios, The regression seems to come from the lack of CDS. I see similar regressions when I run with -Xshare:off. I guess that these EA builds don't include the CDS archive for compact object headers: $ time jdk-24-ea-b25/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -Xlog:cds*=trace -version [0.012s][info][cds] trying to map /home/stefank/java/jdk-24-ea-b25/lib/server/classes_coh.jsa [0.012s][info][cds] Specified shared archive not found (/home/stefank/java/jdk-24-ea-b25/lib/server/classes_coh.jsa) [0.012s][info][cds] Initialize static archive failed. [0.012s][info][cds] Unable to map shared spaces Try to first dump the CDS archive with: $ jdk-24-ea-b25/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -Xshare:dump -version After I have run that I get the CDS archive: $ time jdk-24-ea-b25/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -Xlog:cds*=trace -version [0.011s][info][cds] trying to map /home/stefank/java/jdk-24-ea-b25/lib/server/classes_coh.jsa [0.011s][info][cds] Opened archive /home/stefank/java/jdk-24-ea-b25/lib/server/classes_coh.jsa. [0.011s][info][cds] Archive was created with UseCompressedOops = 1, UseCompressedClassPointers = 1, UseCompactObjectHeaders = 1 ... Could you try and see if that helps the startup times for you? Cheers, StefanK On 2024-11-25 15:22, Georgios Andrianakis wrote: > Hi folks, > > I just tried the Lilliput (JEP 450) using the latest OpenJDK 24 EA > build on a sample Quarkus application > to > see how beneficial?Lilliput can be for us. > > On my machine (a Ryzen 5950X running Linux) with Lilliput disabled, > the application starts up in around 600ms and consumes around 140MB of > RSS memory (before the application handles any traffic). > With Lilliput enabled (via -XX:+UnlockExperimentalVMOptions > -XX:+UseCompactObjectHeaders) I see RSS falling to around 130MB which > is really nice! > However I also see a startup regression of around 30ms (approximately > 5%). Is this something that is expected? > > Thanks! > > P.S. Apologies if this is not the correct mailing list for Lilliput > related topics > > -- > > Georgios Andrianakis > > Independent Contractor > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgronlun at openjdk.org Mon Nov 25 14:44:15 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 25 Nov 2024 14:44:15 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v4] In-Reply-To: References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: On Mon, 25 Nov 2024 14:23:23 GMT, Johan Sj?len wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> extended test > > src/hotspot/os/posix/os_posix.cpp line 2219: > >> 2217: // In the copied version, fpregs should point to the copied contents. >> 2218: // Sanity check: fpregs should point into the context. >> 2219: if ((address)((const ucontext_t*)ucVoid)->uc_mcontext.fpregs > (address)ucVoid) { > > Maybe check that the address is larger than ucVoid but smaller than `ucVoid + sizeof(ucontext_t)`? > > ```c++ > const ucontext_t* uc = (const ucontext_t*)ucVoid; > if (uc->uc_mcontext.fpregs >= (uintptr_t)uc && > uc->uc_mcontext.fpregs < (uintptr_t)(uc + 1)) { > } This is existing code that someone else wrote. It's also Linux-specific. I have only moved the existing logic. I prefer not to touch this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21994#discussion_r1856736596 From gandrian at redhat.com Mon Nov 25 14:50:12 2024 From: gandrian at redhat.com (Georgios Andrianakis) Date: Mon, 25 Nov 2024 16:50:12 +0200 Subject: Lilliput impact on startup time In-Reply-To: <309a93fc-d577-4f65-b2a2-a19c04d92773@oracle.com> References: <309a93fc-d577-4f65-b2a2-a19c04d92773@oracle.com> Message-ID: Hello Stefan, Thanks a lot for the tip! Indeed, forcing the creation of the archive eliminates the regression in startup time. So now my question becomes, will this process be necessary even when JDK 24 ships, or will the archive be part of the release so users don't have to create it manually? On Mon, Nov 25, 2024 at 4:44?PM Stefan Karlsson wrote: > Hi Georgios, > > The regression seems to come from the lack of CDS. I see similar > regressions when I run with -Xshare:off. > > I guess that these EA builds don't include the CDS archive for compact > object headers: > $ time jdk-24-ea-b25/bin/java -XX:+UnlockExperimentalVMOptions > -XX:+UseCompactObjectHeaders -Xlog:cds*=trace -version > [0.012s][info][cds] trying to map > /home/stefank/java/jdk-24-ea-b25/lib/server/classes_coh.jsa > [0.012s][info][cds] Specified shared archive not found > (/home/stefank/java/jdk-24-ea-b25/lib/server/classes_coh.jsa) > [0.012s][info][cds] Initialize static archive failed. > [0.012s][info][cds] Unable to map shared spaces > > Try to first dump the CDS archive with: > $ jdk-24-ea-b25/bin/java -XX:+UnlockExperimentalVMOptions > -XX:+UseCompactObjectHeaders -Xshare:dump -version > > After I have run that I get the CDS archive: > $ time jdk-24-ea-b25/bin/java -XX:+UnlockExperimentalVMOptions > -XX:+UseCompactObjectHeaders -Xlog:cds*=trace -version > [0.011s][info][cds] trying to map > /home/stefank/java/jdk-24-ea-b25/lib/server/classes_coh.jsa > [0.011s][info][cds] Opened archive > /home/stefank/java/jdk-24-ea-b25/lib/server/classes_coh.jsa. > [0.011s][info][cds] Archive was created with UseCompressedOops = 1, > UseCompressedClassPointers = 1, UseCompactObjectHeaders = 1 > ... > > Could you try and see if that helps the startup times for you? > > Cheers, > StefanK > > On 2024-11-25 15:22, Georgios Andrianakis wrote: > > Hi folks, > > I just tried the Lilliput (JEP 450) using the latest OpenJDK 24 EA build > on a sample Quarkus application > to > see how beneficial Lilliput can be for us. > > On my machine (a Ryzen 5950X running Linux) with Lilliput disabled, the > application starts up in around 600ms and consumes around 140MB of RSS > memory (before the application handles any traffic). > With Lilliput enabled (via -XX:+UnlockExperimentalVMOptions > -XX:+UseCompactObjectHeaders) I see RSS falling to around 130MB which is > really nice! > However I also see a startup regression of around 30ms (approximately 5%). > Is this something that is expected? > > Thanks! > > P.S. Apologies if this is not the correct mailing list for Lilliput > related topics > > -- > > Georgios Andrianakis > > Independent Contractor > > > > -- Georgios Andrianakis Independent Contractor -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdoerr at openjdk.org Mon Nov 25 15:01:20 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 25 Nov 2024 15:01:20 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v4] In-Reply-To: References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: On Mon, 25 Nov 2024 14:41:34 GMT, Markus Gr?nlund wrote: >> src/hotspot/os/posix/os_posix.cpp line 2219: >> >>> 2217: // In the copied version, fpregs should point to the copied contents. >>> 2218: // Sanity check: fpregs should point into the context. >>> 2219: if ((address)((const ucontext_t*)ucVoid)->uc_mcontext.fpregs > (address)ucVoid) { >> >> Maybe check that the address is larger than ucVoid but smaller than `ucVoid + sizeof(ucontext_t)`? >> >> ```c++ >> const ucontext_t* uc = (const ucontext_t*)ucVoid; >> if (uc->uc_mcontext.fpregs >= (uintptr_t)uc && >> uc->uc_mcontext.fpregs < (uintptr_t)(uc + 1)) { >> } > > This is existing code that someone else wrote. It's also Linux-specific. I have only moved the existing logic. > > I prefer not to touch this. The check is done below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21994#discussion_r1856764701 From aph at openjdk.org Mon Nov 25 15:33:47 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 25 Nov 2024 15:33:47 GMT Subject: RFR: 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only Message-ID: This bug only affects x86-64 machines without a `popcnt` instruction, which basically means pre-SSE4.2 machines. This means that x86-64 processors made around 2010 are affected. My thanks to everyone who was was involved in bisecting this, particularly Martin Bucholz who seems to be the only one testing on such old hardware. ------------- Commit messages: - 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only Changes: https://git.openjdk.org/jdk/pull/22365/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22365&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344355 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22365.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22365/head:pull/22365 PR: https://git.openjdk.org/jdk/pull/22365 From aph at openjdk.org Mon Nov 25 15:47:21 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 25 Nov 2024 15:47:21 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> References: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> Message-ID: On Mon, 25 Nov 2024 12:59:10 GMT, Amit Kumar wrote: >> s390x Port for : [JDK-8331341](https://bugs.openjdk.org/browse/JDK-8331341) >> >> Tier1 test: >> 1. `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` >> 2. No flag turn on. i.e. used `UseSecondarySupersCache` by default. >> 3. `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` with C1 compiler > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > suggestion from Andrew src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3432: > 3430: r_array_index = temp3, > 3431: slot = temp4, // NOTE: "slot" can't be Z_R0 otherwise z_sllg and z_rllg instructions below will mess up!!!! > 3432: r_bitmap = Z_R1_scratch; Why is `r_bitmap` a fixed register? Do you push `Z_R1` somewhere? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1856840405 From amitkumar at openjdk.org Mon Nov 25 15:56:17 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 25 Nov 2024 15:56:17 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: References: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> Message-ID: On Mon, 25 Nov 2024 15:42:01 GMT, Andrew Haley wrote: >> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> suggestion from Andrew > > src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3432: > >> 3430: r_array_index = temp3, >> 3431: slot = temp4, // NOTE: "slot" can't be Z_R0 otherwise z_sllg and z_rllg instructions below will mess up!!!! >> 3432: r_bitmap = Z_R1_scratch; > > Why is `r_bitmap` a fixed register? > Do you push `Z_R1` somewhere? No Z_R1 is scratch register and is free. It is not being used by `lookup_secondary_supers_table_slow_path` or `repne_scan`. So can't we use it here ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1856859628 From gziemski at openjdk.org Mon Nov 25 16:11:20 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Mon, 25 Nov 2024 16:11:20 GMT Subject: RFR: 8328944: NMT reports "unknown" memory [v4] In-Reply-To: References: Message-ID: On Thu, 21 Nov 2024 21:09:33 GMT, Gerard Ziemski wrote: >> We use `mtNone` value in several functions default parameters, which may show up in NMT reports. >> >> We address this, by avoiding using `mtNone`. >> >> This fix only addresses the cases covered by the issue. I am not trying to replace every single `mtNone` here, but eventually the goal would be to do just that. >> >> Testing: passes MARCH5 tier1-5 > > Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: > > Stefan's feedback ping ------------- PR Comment: https://git.openjdk.org/jdk/pull/21843#issuecomment-2498436409 From rkennke at amazon.de Mon Nov 25 16:15:11 2024 From: rkennke at amazon.de (Kennke, Roman) Date: Mon, 25 Nov 2024 16:15:11 +0000 Subject: Lilliput impact on startup time In-Reply-To: References: <309a93fc-d577-4f65-b2a2-a19c04d92773@oracle.com> Message-ID: <1D85DF89-81DF-4FE6-B22A-23369C2CA565@amazon.de> Hi Georgios, This is a peculiarity with the Oracle builds. Oracle has decided to not generate CDS archives with compact headers in their builds: https://bugs.openjdk.org/browse/JDK-8341553 Other vendors are free to generate compact-headers-CDS-archives, and, afaik, it is on-by-default in OpenJDK sources. FWIW, the COH-CDS archives are generated in Aleksey?s build, you may want to give them a try: https://builds.shipilev.net/openjdk-jdk/ Roman > Thanks a lot for the tip! > Indeed, forcing the creation of the archive eliminates the regression in startup time. > > So now my question becomes, will this process be necessary even when JDK 24 ships, or will the archive be part of the release so users don't have to create it manually? > > On Mon, Nov 25, 2024 at 4:44?PM Stefan Karlsson wrote: > Hi Georgios, > > The regression seems to come from the lack of CDS. I see similar regressions when I run with -Xshare:off. > > I guess that these EA builds don't include the CDS archive for compact object headers: > $ time jdk-24-ea-b25/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -Xlog:cds*=trace -version > [0.012s][info][cds] trying to map /home/stefank/java/jdk-24-ea-b25/lib/server/classes_coh.jsa > [0.012s][info][cds] Specified shared archive not found (/home/stefank/java/jdk-24-ea-b25/lib/server/classes_coh.jsa) > [0.012s][info][cds] Initialize static archive failed. > [0.012s][info][cds] Unable to map shared spaces > > Try to first dump the CDS archive with: > $ jdk-24-ea-b25/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -Xshare:dump -version > > After I have run that I get the CDS archive: > $ time jdk-24-ea-b25/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -Xlog:cds*=trace -version > [0.011s][info][cds] trying to map /home/stefank/java/jdk-24-ea-b25/lib/server/classes_coh.jsa > [0.011s][info][cds] Opened archive /home/stefank/java/jdk-24-ea-b25/lib/server/classes_coh.jsa. > [0.011s][info][cds] Archive was created with UseCompressedOops = 1, UseCompressedClassPointers = 1, UseCompactObjectHeaders = 1 > ... > > Could you try and see if that helps the startup times for you? > > Cheers, > StefanK > > On 2024-11-25 15:22, Georgios Andrianakis wrote: >> Hi folks, >> >> I just tried the Lilliput (JEP 450) using the latest OpenJDK 24 EA build on a sample Quarkus application to see how beneficial Lilliput can be for us. >> >> On my machine (a Ryzen 5950X running Linux) with Lilliput disabled, the application starts up in around 600ms and consumes around 140MB of RSS memory (before the application handles any traffic). >> With Lilliput enabled (via -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders) I see RSS falling to around 130MB which is really nice! >> However I also see a startup regression of around 30ms (approximately 5%). Is this something that is expected? >> >> Thanks! >> >> P.S. Apologies if this is not the correct mailing list for Lilliput related topics >> >> -- >> Georgios Andrianakis >> Independent Contractor >> > > > > -- > Georgios Andrianakis > Independent Contractor Amazon Web Services Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597 From duke at openjdk.org Mon Nov 25 16:22:48 2024 From: duke at openjdk.org (Larry Cable) Date: Mon, 25 Nov 2024 16:22:48 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_summary diagnostic command Message-ID: c.f: [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420) Summary ------- Add `jcmd Thread.vthread_summary` to print summary information that is useful when trying to diagnose issues with virtual threads. Problem ------- The JDK is lacking tooling to diagnose issues with virtual threads. Solution -------- Add a new command that the `jcmd` command line tool can use to print information about virtual threads. The output includes the virtual thread scheduler, the schedulers used to support timeouts, and the I/O pollers used to support virtual threads doing socket I/O, and a summary of the thread groupings. Here is sample output. The output is intended for experts and is not intended for automated parsing. Virtual thread scheduler: java.util.concurrent.ForkJoinPool at 4a624db0[Running, parallelism = 16, size = 2, active = 0, running = 0, steals = 2, tasks = 0, submissions = 0] Timeout schedulers: [0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] [1] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845[Running, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 0] [2] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] [3] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] Read I/O pollers: [0] sun.nio.ch.KQueuePoller at 524bf25 [registered = 1] Write I/O pollers: [0] sun.nio.ch.KQueuePoller at 25c41da2 [registered = 0] Thread groupings: [platform threads = 11, virtual threads = 0] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4 [platform threads = 0, virtual threads = 0] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef [platform threads = 0, virtual threads = 0] ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer at 4fa374ea [platform threads = 0, virtual threads = 0] java.util.concurrent.ThreadPoolExecutor at 506e1b77 [platform threads = 1, virtual threads = 0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12 [platform threads = 0, virtual threads = 0] java.util.concurrent.ThreadPerTaskExecutor at 24155ffc [platform threads = 0, virtual threads = 2] ForkJoinPool-1/jdk.internal.vm.SharedThreadContainer at 48a03463 [platform threads = 2, virtual threads = 0] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845 [platform threads = 1, virtual threads = 0] The "Virtual thread scheduler" section show the target parallelism, the number of threads in the scheduler's pool, and other useful counters. The "Timeout schedulers" section provides information on the usage of the ScheduledThreadPoolExecutor used to support virtual thread doing timed operations. The "I/O pollers" section will vary by OS. The sample output here is macOS which, by default, has a one read and one write poller. This is useful to see how many blocking network I/O operations on virtual threads are in progress. The "Thread groupings" appears a support people to get a sense of how the virtual threads are grouped. Virtual threads created directly with the Thread API are in the "root" grouping. Some servers may have one or more ThreadPerTaskExecutor instances. For now, this section doesn't print the tree of thread groupings that arises when using the Structured Concurrency API. Specification ------------- The output from `jcmd Thread.vthread_summary -help` is: Thread.vthread_summary` Print the virtual thread scheduler, timeout schedulers, I/O pollers, and thread groupings. Impact: Low ------------- Commit messages: - JDK-8337199: removed thread groupings iimpl from dcmd as per Alan B, and disabled asssociated tests - JDK-8337199: merge master - Sync with loom repo - Sync up from loom repo - Update from loom repo - Initial commit Changes: https://git.openjdk.org/jdk/pull/22121/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22121&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337199 Stats: 466 lines in 11 files changed: 456 ins; 6 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22121.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22121/head:pull/22121 PR: https://git.openjdk.org/jdk/pull/22121 From gandrian at redhat.com Mon Nov 25 16:26:12 2024 From: gandrian at redhat.com (Georgios Andrianakis) Date: Mon, 25 Nov 2024 18:26:12 +0200 Subject: Lilliput impact on startup time In-Reply-To: <1D85DF89-81DF-4FE6-B22A-23369C2CA565@amazon.de> References: <309a93fc-d577-4f65-b2a2-a19c04d92773@oracle.com> <1D85DF89-81DF-4FE6-B22A-23369C2CA565@amazon.de> Message-ID: Thanks a lot for the information Roman! I will try Alexey's builds and report back if there are any issues. On Mon, Nov 25, 2024 at 6:16?PM Kennke, Roman wrote: > Hi Georgios, > > This is a peculiarity with the Oracle builds. Oracle has decided to not > generate CDS archives with compact headers in their builds: > https://bugs.openjdk.org/browse/JDK-8341553 > > Other vendors are free to generate compact-headers-CDS-archives, and, > afaik, it is on-by-default in OpenJDK sources. > > FWIW, the COH-CDS archives are generated in Aleksey?s build, you may want > to give them a try: > https://builds.shipilev.net/openjdk-jdk/ > > Roman > > > > Thanks a lot for the tip! > > Indeed, forcing the creation of the archive eliminates the regression in > startup time. > > > > So now my question becomes, will this process be necessary even when JDK > 24 ships, or will the archive be part of the release so users don't have to > create it manually? > > > > On Mon, Nov 25, 2024 at 4:44?PM Stefan Karlsson < > stefan.karlsson at oracle.com> wrote: > > Hi Georgios, > > > > The regression seems to come from the lack of CDS. I see similar > regressions when I run with -Xshare:off. > > > > I guess that these EA builds don't include the CDS archive for compact > object headers: > > $ time jdk-24-ea-b25/bin/java -XX:+UnlockExperimentalVMOptions > -XX:+UseCompactObjectHeaders -Xlog:cds*=trace -version > > [0.012s][info][cds] trying to map > /home/stefank/java/jdk-24-ea-b25/lib/server/classes_coh.jsa > > [0.012s][info][cds] Specified shared archive not found > (/home/stefank/java/jdk-24-ea-b25/lib/server/classes_coh.jsa) > > [0.012s][info][cds] Initialize static archive failed. > > [0.012s][info][cds] Unable to map shared spaces > > > > Try to first dump the CDS archive with: > > $ jdk-24-ea-b25/bin/java -XX:+UnlockExperimentalVMOptions > -XX:+UseCompactObjectHeaders -Xshare:dump -version > > > > After I have run that I get the CDS archive: > > $ time jdk-24-ea-b25/bin/java -XX:+UnlockExperimentalVMOptions > -XX:+UseCompactObjectHeaders -Xlog:cds*=trace -version > > [0.011s][info][cds] trying to map > /home/stefank/java/jdk-24-ea-b25/lib/server/classes_coh.jsa > > [0.011s][info][cds] Opened archive > /home/stefank/java/jdk-24-ea-b25/lib/server/classes_coh.jsa. > > [0.011s][info][cds] Archive was created with UseCompressedOops = 1, > UseCompressedClassPointers = 1, UseCompactObjectHeaders = 1 > > ... > > > > Could you try and see if that helps the startup times for you? > > > > Cheers, > > StefanK > > > > On 2024-11-25 15:22, Georgios Andrianakis wrote: > >> Hi folks, > >> > >> I just tried the Lilliput (JEP 450) using the latest OpenJDK 24 EA > build on a sample Quarkus application to see how beneficial Lilliput can be > for us. > >> > >> On my machine (a Ryzen 5950X running Linux) with Lilliput disabled, the > application starts up in around 600ms and consumes around 140MB of RSS > memory (before the application handles any traffic). > >> With Lilliput enabled (via -XX:+UnlockExperimentalVMOptions > -XX:+UseCompactObjectHeaders) I see RSS falling to around 130MB which is > really nice! > >> However I also see a startup regression of around 30ms (approximately > 5%). Is this something that is expected? > >> > >> Thanks! > >> > >> P.S. Apologies if this is not the correct mailing list for Lilliput > related topics > >> > >> -- > >> Georgios Andrianakis > >> Independent Contractor > >> > > > > > > > > -- > > Georgios Andrianakis > > Independent Contractor > > > > > > Amazon Web Services Development Center Germany GmbH > Krausenstr. 38 > 10117 Berlin > Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss > Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B > Sitz: Berlin > Ust-ID: DE 365 538 597 > -- Georgios Andrianakis Independent Contractor -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Mon Nov 25 16:52:20 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 25 Nov 2024 16:52:20 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_summary diagnostic command In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 21:34:08 GMT, Larry Cable wrote: > c.f: [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420) > > Summary > ------- > > Add `jcmd Thread.vthread_summary` to print summary information that is useful when trying to diagnose issues with virtual threads. > > > Problem > ------- > > The JDK is lacking tooling to diagnose issues with virtual threads. > > > Solution > -------- > > Add a new command that the `jcmd` command line tool can use to print information about virtual threads. The output includes the virtual thread scheduler, the schedulers used to support timeouts, and the I/O pollers used to support virtual threads doing socket I/O, and a summary of the thread groupings. > > Here is sample output. The output is intended for experts and is not intended for automated parsing. > > > Virtual thread scheduler: > java.util.concurrent.ForkJoinPool at 4a624db0[Running, parallelism = 16, size = 2, active = 0, running = 0, steals = 2, tasks = 0, submissions = 0] > > Timeout schedulers: > [0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > [1] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845[Running, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 0] > [2] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > [3] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > > Read I/O pollers: > [0] sun.nio.ch.KQueuePoller at 524bf25 [registered = 1] > > Write I/O pollers: > [0] sun.nio.ch.KQueuePoller at 25c41da2 [registered = 0] > > Thread groupings: > [platform threads = 11, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4 [platform threads = 0, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef [platform threads = 0, virtual threads = 0] > ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer at 4fa374ea [platform threads = 0, virtual threads = 0] > java.util.concurrent.ThreadPoolExecutor at 506e1b77 [platform threads = 1, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12 [platform threads = 0, virtual threads = 0] > java.util.concurrent.ThreadPerTaskExecutor at 24155ffc [platform threads = 0, virtual threads = 2] > ForkJoinPool-1/jdk.internal.vm.SharedThreadContainer at 48a03463 [platform threads = 2, virtual threads = 0] > java.util.concurrent.Scheduled... In the CSR I think we've agreed to drop the thread groupings from this command. Can you update the Solution section so the sample output aligns with that? The PR shows merge conflicts, can you sync up the branch to closer to main line? The man page update moves from jcmd.1 to jcmd.md. Drop "thread groupings" from the description, and also VThreadSummaryDCmd::description (diagnosticCommand.hpp). I see the commit to comment out printing the thread groupings but I think better to remove the unused code. You can grab the latest VThreadSummary.java and VThreadSummaryTest.java from the loom repo. Also can you grab Poller.java too as it has the correct merge with JEP 491. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22121#issuecomment-2498536459 From aph at openjdk.org Mon Nov 25 16:55:15 2024 From: aph at openjdk.org (Andrew Haley) Date: Mon, 25 Nov 2024 16:55:15 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: References: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> Message-ID: <4zk7UqMG1gtaOVYRSEzy9keJPIeWWAITDixEYkQ9cIw=.2ce092e2-8807-44fa-9060-fa17935158d2@github.com> On Mon, 25 Nov 2024 15:53:51 GMT, Amit Kumar wrote: > No Z_R1 is scratch register and is free. It is not being used by `lookup_secondary_supers_table_slow_path` or `repne_scan`. So can't we use it here ? Ah, so it's not used by any of the compilers? OK, then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1856951071 From duke at openjdk.org Mon Nov 25 16:55:26 2024 From: duke at openjdk.org (Robert Toyonaga) Date: Mon, 25 Nov 2024 16:55:26 GMT Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v3] In-Reply-To: References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Mon, 25 Nov 2024 12:12:25 GMT, Afshin Zafari wrote: >> src/hotspot/share/runtime/os.cpp line 2213: >> >>> 2211: res = pd_release_memory(addr, bytes); >>> 2212: if (res) { >>> 2213: ThreadCritical tc; >> >> What is the reason for moving `pd_release_memory` out of the protection of the lock? Wouldn't it be better if the memory operation and the accounting were done together atomically like with [`os::uncommit_memory`](https://github.com/openjdk/jdk/pull/20425/files#diff-c626d392182b0193ad0e754de3f4fd42c98d959edade67490b6e1f24be38efdbR2189) for example. > > TBH, I don't know and this is not a change in this PR. The uncommit_memory has the same approach. I just know that if we move the pd_xxxx inside the lock some tests fail or some assertions happen, but do not remember which and why. OK, I guess it doesn't make much of a difference at the moment since it's inconsistent across many memory operations anyway. Commit, uncommit, reserve, and release don't agree on whether to make the memory operation and NMT accounting atomic together. I opened an issue for this here: https://bugs.openjdk.org/browse/JDK-8341491 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1856951247 From gandrian at redhat.com Mon Nov 25 16:56:00 2024 From: gandrian at redhat.com (Georgios Andrianakis) Date: Mon, 25 Nov 2024 18:56:00 +0200 Subject: Lilliput impact on startup time In-Reply-To: References: <309a93fc-d577-4f65-b2a2-a19c04d92773@oracle.com> <1D85DF89-81DF-4FE6-B22A-23369C2CA565@amazon.de> Message-ID: Just tried Alexey's build and everything works like a charm! Thanks for the help folks! On Mon, Nov 25, 2024 at 6:26?PM Georgios Andrianakis wrote: > Thanks a lot for the information Roman! > > I will try Alexey's builds and report back if there are any issues. > > On Mon, Nov 25, 2024 at 6:16?PM Kennke, Roman wrote: > >> Hi Georgios, >> >> This is a peculiarity with the Oracle builds. Oracle has decided to not >> generate CDS archives with compact headers in their builds: >> https://bugs.openjdk.org/browse/JDK-8341553 >> >> Other vendors are free to generate compact-headers-CDS-archives, and, >> afaik, it is on-by-default in OpenJDK sources. >> >> FWIW, the COH-CDS archives are generated in Aleksey?s build, you may want >> to give them a try: >> https://builds.shipilev.net/openjdk-jdk/ >> >> Roman >> >> >> > Thanks a lot for the tip! >> > Indeed, forcing the creation of the archive eliminates the regression >> in startup time. >> > >> > So now my question becomes, will this process be necessary even when >> JDK 24 ships, or will the archive be part of the release so users don't >> have to create it manually? >> > >> > On Mon, Nov 25, 2024 at 4:44?PM Stefan Karlsson < >> stefan.karlsson at oracle.com> wrote: >> > Hi Georgios, >> > >> > The regression seems to come from the lack of CDS. I see similar >> regressions when I run with -Xshare:off. >> > >> > I guess that these EA builds don't include the CDS archive for compact >> object headers: >> > $ time jdk-24-ea-b25/bin/java -XX:+UnlockExperimentalVMOptions >> -XX:+UseCompactObjectHeaders -Xlog:cds*=trace -version >> > [0.012s][info][cds] trying to map >> /home/stefank/java/jdk-24-ea-b25/lib/server/classes_coh.jsa >> > [0.012s][info][cds] Specified shared archive not found >> (/home/stefank/java/jdk-24-ea-b25/lib/server/classes_coh.jsa) >> > [0.012s][info][cds] Initialize static archive failed. >> > [0.012s][info][cds] Unable to map shared spaces >> > >> > Try to first dump the CDS archive with: >> > $ jdk-24-ea-b25/bin/java -XX:+UnlockExperimentalVMOptions >> -XX:+UseCompactObjectHeaders -Xshare:dump -version >> > >> > After I have run that I get the CDS archive: >> > $ time jdk-24-ea-b25/bin/java -XX:+UnlockExperimentalVMOptions >> -XX:+UseCompactObjectHeaders -Xlog:cds*=trace -version >> > [0.011s][info][cds] trying to map >> /home/stefank/java/jdk-24-ea-b25/lib/server/classes_coh.jsa >> > [0.011s][info][cds] Opened archive >> /home/stefank/java/jdk-24-ea-b25/lib/server/classes_coh.jsa. >> > [0.011s][info][cds] Archive was created with UseCompressedOops = 1, >> UseCompressedClassPointers = 1, UseCompactObjectHeaders = 1 >> > ... >> > >> > Could you try and see if that helps the startup times for you? >> > >> > Cheers, >> > StefanK >> > >> > On 2024-11-25 15:22, Georgios Andrianakis wrote: >> >> Hi folks, >> >> >> >> I just tried the Lilliput (JEP 450) using the latest OpenJDK 24 EA >> build on a sample Quarkus application to see how beneficial Lilliput can be >> for us. >> >> >> >> On my machine (a Ryzen 5950X running Linux) with Lilliput disabled, >> the application starts up in around 600ms and consumes around 140MB of RSS >> memory (before the application handles any traffic). >> >> With Lilliput enabled (via -XX:+UnlockExperimentalVMOptions >> -XX:+UseCompactObjectHeaders) I see RSS falling to around 130MB which is >> really nice! >> >> However I also see a startup regression of around 30ms (approximately >> 5%). Is this something that is expected? >> >> >> >> Thanks! >> >> >> >> P.S. Apologies if this is not the correct mailing list for Lilliput >> related topics >> >> >> >> -- >> >> Georgios Andrianakis >> >> Independent Contractor >> >> >> > >> > >> > >> > -- >> > Georgios Andrianakis >> > Independent Contractor >> >> >> >> >> >> Amazon Web Services Development Center Germany GmbH >> Krausenstr. 38 >> 10117 Berlin >> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss >> Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B >> Sitz: Berlin >> Ust-ID: DE 365 538 597 >> > > > -- > > Georgios Andrianakis > > Independent Contractor > > > -- Georgios Andrianakis Independent Contractor -------------- next part -------------- An HTML attachment was scrubbed... URL: From lujaniuk at openjdk.org Mon Nov 25 16:57:19 2024 From: lujaniuk at openjdk.org (Ludvig Janiuk) Date: Mon, 25 Nov 2024 16:57:19 GMT Subject: RFR: 8342893: Highlight special values in hserr file printing [v5] In-Reply-To: References: Message-ID: <3zWZjQ8ohlxfbNVLetyl-6xznE6eoUNW8vhYsqRW2WE=.d0319682-ba06-4e75-b352-ef13ca894249@github.com> On Thu, 14 Nov 2024 13:07:40 GMT, Matthias Baesken wrote: >> There are some special values indicating memory corruption or problematic states. Those should be highlighted / pointed out in some way when printing parts of the hserr / hsinfo file (like register values or locations), > > Matthias Baesken has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge master > - Merge remote-tracking branch 'origin/master' into JDK-8342893 > - Introduce badResourceValueWord variable > - compile error on Linux x86 and arm 32bit > - do checks in debug > - JDK-8342893 Maybe the new `os::print_reg` could be covered by some unit tests? For comparison, I managed to add the following to `test/hotspot/gtest/utilities/test_vmerror.cpp`: TEST_VM(vmErrorTest, reg) { char* actual = NEW_C_HEAP_ARRAY(char, 200, mtInternal); stringStream ss(actual, 200); os::print_dhm(&ss, "ludvig ", 1); const char* reference = "ludvig 0 days 0:00 hours\n"; EXPECT_STREQ(actual, reference); } Sample output (where I made it fail on purpose): [ RUN ] vmErrorTest.reg_vm ***/test/hotspot/gtest/utilities/test_vmerror.cpp:132: Failure Expected equality of these values: actual Which is: "not ludvig 0 days 0:00 hours\n" reference Which is: "ludvig 0 days 0:00 hours\n" [ FAILED ] vmErrorTest.reg_vm (0 ms) [----------] 13 tests from vmErrorTest (2170 ms total) Otherwise I think it's a really nice enhancement to make these values stand out better! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21811#issuecomment-2498544480 PR Comment: https://git.openjdk.org/jdk/pull/21811#issuecomment-2498546575 From jsjolen at openjdk.org Mon Nov 25 17:45:17 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 25 Nov 2024 17:45:17 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v4] In-Reply-To: References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: On Mon, 25 Nov 2024 14:58:21 GMT, Martin Doerr wrote: >> This is existing code that someone else wrote. It's also Linux-specific. I have only moved the existing logic. >> >> I prefer not to touch this. > > The check is done below. Fine by me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21994#discussion_r1857052635 From mgronlun at openjdk.org Mon Nov 25 17:56:16 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 25 Nov 2024 17:56:16 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v4] In-Reply-To: References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: On Mon, 25 Nov 2024 14:24:28 GMT, Johan Sj?len wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> extended test > > Hi, > > This code looks good to me, with a small comment. Thanks for your review, @jdksjolen . Much appreciated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21994#issuecomment-2498678041 From duke at openjdk.org Mon Nov 25 17:56:16 2024 From: duke at openjdk.org (Larry Cable) Date: Mon, 25 Nov 2024 17:56:16 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_summary diagnostic command In-Reply-To: References: Message-ID: <0yLHRaZWc0Uk2tRWAP7vnbIq-Kl_zi03ICWBvjC5f_w=.b97538c7-11b4-44c6-b3f9-26b23bddb220@github.com> On Thu, 14 Nov 2024 21:34:08 GMT, Larry Cable wrote: > c.f: [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420) > > Summary > ------- > > Add `jcmd Thread.vthread_summary` to print summary information that is useful when trying to diagnose issues with virtual threads. > > > Problem > ------- > > The JDK is lacking tooling to diagnose issues with virtual threads. > > > Solution > -------- > > Add a new command that the `jcmd` command line tool can use to print information about virtual threads. The output includes the virtual thread scheduler, the schedulers used to support timeouts, and the I/O pollers used to support virtual threads doing socket I/O, and a summary of the thread groupings. > > Here is sample output. The output is intended for experts and is not intended for automated parsing. > > > Virtual thread scheduler: > java.util.concurrent.ForkJoinPool at 4a624db0[Running, parallelism = 16, size = 2, active = 0, running = 0, steals = 2, tasks = 0, submissions = 0] > > Timeout schedulers: > [0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > [1] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845[Running, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 0] > [2] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > [3] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > > Read I/O pollers: > [0] sun.nio.ch.KQueuePoller at 524bf25 [registered = 1] > > Write I/O pollers: > [0] sun.nio.ch.KQueuePoller at 25c41da2 [registered = 0] > > Thread groupings: > [platform threads = 11, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4 [platform threads = 0, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef [platform threads = 0, virtual threads = 0] > ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer at 4fa374ea [platform threads = 0, virtual threads = 0] > java.util.concurrent.ThreadPoolExecutor at 506e1b77 [platform threads = 1, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12 [platform threads = 0, virtual threads = 0] > java.util.concurrent.ThreadPerTaskExecutor at 24155ffc [platform threads = 0, virtual threads = 2] > ForkJoinPool-1/jdk.internal.vm.SharedThreadContainer at 48a03463 [platform threads = 2, virtual threads = 0] > java.util.concurrent.Scheduled... ok On 11/25/24 8:50 AM, Alan Bateman wrote: > > In the CSR I think we've agreed to drop the thread groupings from this > command. Can you update the Solution section so the sample output > aligns with that? > > The PR shows merge conflicts, can you sync up the branch to closer to > main line? The man page update moves from jcmd.1 to jcmd.md. Drop > "thread groupings" from the description, and also > VThreadSummaryDCmd::description (diagnosticCommand.hpp). > > I see the commit to comment out printing the thread groupings but I > think better to remove the unused code. You can grab the latest > VThreadSummary.java and VThreadSummaryTest.java from the loom repo. > Also can you grab Poller.java too as it has the correct merge with JEP > 491. > > ? > Reply to this email directly, view it on GitHub > , > or unsubscribe > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > --------------43A07On2mpTNaH2Wy6LHFItz Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit ok

On 11/25/24 8:50 AM, Alan Bateman wrote:

In the CSR I think we've agreed to drop the thread groupings from this command. Can you update the Solution section so the sample output aligns with that?

The PR shows merge conflicts, can you sync up the branch to closer to main line? The man page update moves from jcmd.1 to jcmd.md. Drop "thread groupings" from the description, and also VThreadSummaryDCmd::description (diagnosticCommand.hpp).

I see the commit to comment out printing the thread groupings but I think better to remove the unused code. You can grab the latest VThreadSummary.java and VThreadSummaryTest.java from the loom repo. Also can you grab Poller.java too as it has the correct merge with JEP 491.

?
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: <openjdk/jdk/pull/22121/c2498536459@github.com>


--------------43A07On2mpTNaH2Wy6LHFItz-- ------------- PR Comment: https://git.openjdk.org/jdk/pull/22121#issuecomment-2498677452 From wkemper at openjdk.org Mon Nov 25 18:01:40 2024 From: wkemper at openjdk.org (William Kemper) Date: Mon, 25 Nov 2024 18:01:40 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Thu, 21 Nov 2024 18:30:31 GMT, Aleksey Shipilev wrote: >> Yes, in single gen mode we set `MARKING` and `YOUNG_MARKING` together. See https://github.com/openjdk/shenandoah/blob/master/src/hotspot/share/gc/shenandoah/shenandoahGlobalGeneration.cpp#L81 > > We should really either predicate it on generational mode (we already poll it a few lines below) and check for `MARKING` specifically, or assert it. I'll make some adjustments here. Note that `OLD_MARKING` also implies (and sets) `MARKING`, and - unlike `YOUNG_MARKING` - is not exclusive with `EVACUTION` and `UPDATEREFS`. Perhaps an explanatory comment is the best option here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1857098111 From shade at openjdk.org Mon Nov 25 18:25:39 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 25 Nov 2024 18:25:39 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Mon, 25 Nov 2024 17:59:05 GMT, William Kemper wrote: >> We should really either predicate it on generational mode (we already poll it a few lines below) and check for `MARKING` specifically, or assert it. > > I'll make some adjustments here. Note that `OLD_MARKING` also implies (and sets) `MARKING`, and - unlike `YOUNG_MARKING` - is not exclusive with `EVACUTION` and `UPDATEREFS`. Perhaps an explanatory comment is the best option here? Thing is, the description for `MARKING` says "marking is in progress" (for any mode), while `YOUNG_MARKING` says that it is only true for yougn marking. So for a casual reader, checking for `YOUNG_MARKING` in non-generational code looks weird. I don't know the best way out of this, really. I think this is the only place when we check `YOUNG_MARKING` for non-gen mode? If so, we should probably fix it right here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1857151960 From martin at openjdk.org Mon Nov 25 19:07:15 2024 From: martin at openjdk.org (Martin Buchholz) Date: Mon, 25 Nov 2024 19:07:15 GMT Subject: RFR: 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only In-Reply-To: References: Message-ID: <-Yinr93ud5Vm-q5cjEPSdvueBl_MfG3zpqhOCmQQ6_Y=.2abe96f8-96ff-48b3-8142-47582d1407bb@github.com> On Mon, 25 Nov 2024 15:27:22 GMT, Andrew Haley wrote: > This bug only affects x86-64 machines without a `popcnt` instruction, which basically means pre-SSE4.2 machines. This means that x86-64 processors made around 2010 are affected. > > My thanks to everyone who was was involved in bisecting this, particularly Martin Bucholz who seems to be the only one testing on such old hardware. Patch tested on MacBook Air 3,1 ------------- Marked as reviewed by martin (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22365#pullrequestreview-2459411078 From jsjolen at openjdk.org Mon Nov 25 19:08:19 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 25 Nov 2024 19:08:19 GMT Subject: RFR: 8328944: NMT reports "unknown" memory [v4] In-Reply-To: References: Message-ID: On Thu, 21 Nov 2024 21:09:33 GMT, Gerard Ziemski wrote: >> We use `mtNone` value in several functions default parameters, which may show up in NMT reports. >> >> We address this, by avoiding using `mtNone`. >> >> This fix only addresses the cases covered by the issue. I am not trying to replace every single `mtNone` here, but eventually the goal would be to do just that. >> >> Testing: passes MARCH5 tier1-5 > > Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: > > Stefan's feedback This LGTM and the chosen categories seem to make sense. ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21843#pullrequestreview-2459413170 From ccheung at openjdk.org Mon Nov 25 19:30:12 2024 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 25 Nov 2024 19:30:12 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v5] In-Reply-To: References: Message-ID: > Currently, when retrieving a ClassFileStream during runtime, we call into the zip library to retrieve the stream based only on a class name. This doesn't work well if the class is in a multi-release jar under a versioned directory such as `META-INF/versions/9/Foo.class`. To address this issue, this change calls the java api `ClassLoader.getResourceAsStream()` to retrieve the stream. > > Passed tiers 1 - 4 testing. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: @dholmes-ora comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22262/files - new: https://git.openjdk.org/jdk/pull/22262/files/d0e6eccc..a1b13168 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22262&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22262&range=03-04 Stats: 10 lines in 2 files changed: 0 ins; 7 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22262.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22262/head:pull/22262 PR: https://git.openjdk.org/jdk/pull/22262 From ccheung at openjdk.org Mon Nov 25 19:30:16 2024 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 25 Nov 2024 19:30:16 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v4] In-Reply-To: References: <00t4bv6pSjmB-nOYziAApdamEvxsXovEzRwdP9yLA7w=.4b1d9289-00a7-4f82-a8f9-6d8d3174f5cd@github.com> Message-ID: On Mon, 25 Nov 2024 04:11:20 GMT, David Holmes wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> update comments > > src/hotspot/share/cds/filemap.cpp line 2718: > >> 2716: // The result should be a [B >> 2717: assert(obj->is_typeArray(), "just checking"); >> 2718: assert(TypeArrayKlass::cast(obj->klass())->element_type() == T_BYTE, "just checking"); > > This seems unnecessary. What kind of errors are you trying to detect with this? The method signature indicates it returns a byte-array. I adapted the asserts from diagnosticCommand.cpp. I'm keeping the first assert. Is it ok? > src/hotspot/share/cds/filemap.cpp line 2728: > >> 2726: return new ClassFileStream(buffer, >> 2727: len, >> 2728: cpe->name()); > > Suggestion: > > return new ClassFileStream(buffer, len, cpe->name()); Fixed. > src/java.base/share/classes/java/lang/ClassLoader.java line 1698: > >> 1696: } catch (IOException e) { >> 1697: return null; >> 1698: } > > Any `IOException` should just be left pending so that it gets reported eventually. Otherwise you are returning null here but asserting in the VM that null is never returned. I've changed the java method to throw IOException and removed the try-catch statements. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22262#discussion_r1857233789 PR Review Comment: https://git.openjdk.org/jdk/pull/22262#discussion_r1857233832 PR Review Comment: https://git.openjdk.org/jdk/pull/22262#discussion_r1857233887 From wkemper at openjdk.org Mon Nov 25 19:40:25 2024 From: wkemper at openjdk.org (William Kemper) Date: Mon, 25 Nov 2024 19:40:25 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v10] In-Reply-To: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: > This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. William Kemper has updated the pull request incrementally with one additional commit since the last revision: Remove incomplete test case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21273/files - new: https://git.openjdk.org/jdk/pull/21273/files/7eea1d5c..381af0cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=08-09 Stats: 50 lines in 1 file changed: 0 ins; 50 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21273/head:pull/21273 PR: https://git.openjdk.org/jdk/pull/21273 From wkemper at openjdk.org Mon Nov 25 19:40:26 2024 From: wkemper at openjdk.org (William Kemper) Date: Mon, 25 Nov 2024 19:40:26 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Mon, 25 Nov 2024 18:22:09 GMT, Aleksey Shipilev wrote: >> I'll make some adjustments here. Note that `OLD_MARKING` also implies (and sets) `MARKING`, and - unlike `YOUNG_MARKING` - is not exclusive with `EVACUTION` and `UPDATEREFS`. Perhaps an explanatory comment is the best option here? > > Thing is, the description for `MARKING` says "marking is in progress" (for any mode), while `YOUNG_MARKING` says that it is only true for yougn marking. So for a casual reader, checking for `YOUNG_MARKING` in non-generational code looks weird. I don't know the best way out of this, really. I think this is the only place when we check `YOUNG_MARKING` for non-gen mode? If so, we should probably fix it right here? Something like this maybe: https://bugs.openjdk.org/browse/JDK-8344985? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1857241797 From jsjolen at openjdk.org Mon Nov 25 19:50:18 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 25 Nov 2024 19:50:18 GMT Subject: RFR: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf [v3] In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 00:33:31 GMT, David Holmes wrote: >> This is mostly an audit of the callers of `Exceptions::fthrow` to ensure unbounded strings can't appear. >> >> There is a code change in DiagnosticCmd parsing to extend the string length limit already used in part of that code. >> >> Just to clarify the issue. The size 1024 is an internal buffer limit that `fthrow` uses - it is an implementation detail and not something the caller should think about. It is also not relevant to the underlying problem, which is the size of the buffer needed for the fully expanded format string, which `os::vsnprintf` will try to calculate and report. The intent is to check callers can't hit that underlying `vsnprintf` INT_MAX limit. When your format string only deals with a few symbols and symbols are always < 64K then we know we are nowhere near that INT_MAX limit. If your format string can take a potentially arbitrary (usually from outside) string then it needs to put its own size guard in place using `%*s`. >> >> Testing: >> - tier 1-3 (sanity) >> >> Thanks > > David Holmes 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 8339134-fthrow > - Restore previous behaviour for zero length strings > - 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf OK, LGTM ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21867#pullrequestreview-2459486538 From dholmes at openjdk.org Mon Nov 25 19:58:24 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 25 Nov 2024 19:58:24 GMT Subject: RFR: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf [v3] In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 19:47:38 GMT, Johan Sj?len wrote: >> David Holmes 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 8339134-fthrow >> - Restore previous behaviour for zero length strings >> - 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf > > OK, LGTM Thanks for the review @jdksjolen ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21867#issuecomment-2498907288 From dholmes at openjdk.org Mon Nov 25 19:58:24 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 25 Nov 2024 19:58:24 GMT Subject: Integrated: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf In-Reply-To: References: Message-ID: <75uPxPy-t2hfO8dqxIya_lHR9gHf-fOPAz6jx6pDfZA=.2f29ef0b-5f85-4694-8319-15792faf0d2f@github.com> On Mon, 4 Nov 2024 07:00:38 GMT, David Holmes wrote: > This is mostly an audit of the callers of `Exceptions::fthrow` to ensure unbounded strings can't appear. > > There is a code change in DiagnosticCmd parsing to extend the string length limit already used in part of that code. > > Just to clarify the issue. The size 1024 is an internal buffer limit that `fthrow` uses - it is an implementation detail and not something the caller should think about. It is also not relevant to the underlying problem, which is the size of the buffer needed for the fully expanded format string, which `os::vsnprintf` will try to calculate and report. The intent is to check callers can't hit that underlying `vsnprintf` INT_MAX limit. When your format string only deals with a few symbols and symbols are always < 64K then we know we are nowhere near that INT_MAX limit. If your format string can take a potentially arbitrary (usually from outside) string then it needs to put its own size guard in place using `%*s`. > > Testing: > - tier 1-3 (sanity) > > Thanks This pull request has now been integrated. Changeset: 8de158ae Author: David Holmes URL: https://git.openjdk.org/jdk/commit/8de158aefe64d493e107ef310f510bab57beb251 Stats: 50 lines in 9 files changed: 44 ins; 1 del; 5 mod 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf Reviewed-by: coleenp, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/21867 From jbhateja at openjdk.org Mon Nov 25 20:04:09 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 25 Nov 2024 20:04:09 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations [v3] In-Reply-To: References: Message-ID: > Hi All, > > This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) > > Following is the summary of changes included with this patch:- > > 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. > 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. > 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. > - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. > 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. > 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. > 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. > 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF > 6. Auto-vectorization of newly supported scalar operations. > 7. X86 and AARCH64 backend implementation for all supported intrinsics. > 9. Functional and Performance validation tests. > > 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: Review comments resolution ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21490/files - new: https://git.openjdk.org/jdk/pull/21490/files/5f58eea6..746c970e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21490&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21490&range=01-02 Stats: 129 lines in 14 files changed: 37 ins; 4 del; 88 mod Patch: https://git.openjdk.org/jdk/pull/21490.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21490/head:pull/21490 PR: https://git.openjdk.org/jdk/pull/21490 From jbhateja at openjdk.org Mon Nov 25 20:04:12 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 25 Nov 2024 20:04:12 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations [v2] In-Reply-To: <2t1Bka2nUU4K1Uqe3iy3Q5aFzriK2pTpZYqK9Zjyg0s=.a77d89c2-4edc-4d6c-94a3-5a350c921267@github.com> References: <2t1Bka2nUU4K1Uqe3iy3Q5aFzriK2pTpZYqK9Zjyg0s=.a77d89c2-4edc-4d6c-94a3-5a350c921267@github.com> Message-ID: On Mon, 25 Nov 2024 08:56:31 GMT, Emanuel Peter wrote: > I heard no argument about why you did not split this up. Please do that in the future. It is hard to review well when there is this much code. If it is really necessary, then sure. Here it does not seem necessary to deliver all at once. > > > The patch includes IR framework-based scalar constant folding test points. > > You mention this IR test: > > https://github.com/openjdk/jdk/pull/21490/files#diff-3f8786f9f62662eda4b4a5c76c01fa04534c94d870d496501bfc20434ad45579R169-R174 > > Here I only see the use of very trivial values. I think we need more complicated cases. > > What about these: > > * Add/Sub/Mul/Div/Min/Max ... with NaN and infinity. > * Same where it would overflow the FP16 range. > * Negative zero tests. > * Division by powers of 2. > > It would for example be nice if you could iterate over all inputs. FP16 with 2 inputs is only 32bits, that can be iterated in just a few seconds. Then you can run the computation with constants in the interpreter, and compare to the results in compiled code. [ScalarFloat16OperationsTest.java](https://github.com/openjdk/jdk/pull/21490/files#diff-6afb7e66ce0fcdac61df60af0231010b20cf16489ec7e4d5b0b41852db8796a0) Adds has a specialized data provider that generates test vectors with special values, our functional validation is covering the entire Float16 value range. > src/hotspot/share/opto/divnode.cpp line 789: > >> 787: >> 788: if(t1 == TypeH::ZERO && !g_isnan(t2->getf()) && t2->getf() != 0.0) >> 789: return TypeH::ZERO; > > brackets for if > > Ok, why not also do it for negative zero then? Same as above, IEEE 754 spec treats both +ve and -ve zeros equally during comparison operations. jshell> 0.0f != 0.0f $1 ==> false jshell> 0.0f != -0.0f $2 ==> false jshell> -0.0f != -0.0f $3 ==> false jshell> -0.0f != 0.0f $4 ==> false > src/hotspot/share/opto/divnode.cpp line 797: > >> 795: //------------------------------isA_Copy--------------------------------------- >> 796: // Dividing by self is 1. >> 797: // If the divisor is 1, we are an identity on the dividend. > > Suggestion: > > // If the divisor is 1, we are an identity on the dividend. > > `Dividing by self is 1.` That does not seem to apply here. Maybe you meant `dividing by 1 is self`? The comment mentions the divisor being 1. Looks fine. > src/hotspot/share/opto/divnode.cpp line 836: > >> 834: >> 835: // return multiplication by the reciprocal >> 836: return (new MulHFNode(in(1), phase->makecon(TypeH::make(reciprocal)))); > > Do we have good tests for this optimization? I have added a test point https://github.com/openjdk/jdk/pull/21490/files#diff-3f8786f9f62662eda4b4a5c76c01fa04534c94d870d496501bfc20434ad45579R203 I also added detailed comments to explain this better. > src/hotspot/share/opto/mulnode.cpp line 561: > >> 559: const Type *MulHFNode::mul_ring(const Type *t0, const Type *t1) const { >> 560: if( t0 == Type::HALF_FLOAT || t1 == Type::HALF_FLOAT ) return Type::HALF_FLOAT; >> 561: return TypeH::make( t0->getf() * t1->getf() ); > > I hope that `TypeH::make` handles the overflow cases well... does it? > And do we have tests for this? Please refer to following lines of code. https://github.com/openjdk/jdk/pull/21490/files#diff-3559dcf23b719805be5fd06fd5c1851dbd8f53e47afe6d99cba13a3de0ebc6b2R1446 There are two versions of TypeH::make, one with short and the other accepting floating point parameter, in the latter version we explicitly invoke a runtime help to convert float to float16 value, this shall take care of overflow scenario where we return an infinite Float16 value. There is no underflow in the case of a floating point number, for graceful degradation we enter into a sub-normal range and eventually return a zero value. On the other end of the spectrum i.e -ve values range we return a NEGATIVE_INFINITE, existing runtime helper is fully equipped to handle these cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2498908764 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1857267174 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1857266958 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1857266304 PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1857266117 From jbhateja at openjdk.org Mon Nov 25 20:04:13 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 25 Nov 2024 20:04:13 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations [v2] In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 07:18:41 GMT, Emanuel Peter wrote: >> src/hotspot/share/opto/connode.cpp line 49: >> >>> 47: switch( t->basic_type() ) { >>> 48: case T_INT: return new ConINode( t->is_int() ); >>> 49: case T_SHORT: return new ConHNode( t->is_half_float_constant() ); >> >> That will be quite confusing.... don't you think? > > I mean do we need this? We already have `ConHNode::make` below...? JVM treats, byte and short as constrained integer type, which is why we create ConI and not ConB or ConS. In addition, transform routines of PhaseGVN and PhaseIterGVN use ConNode::make interface to create a constant IR node, it will not be appropriate to add a specialization over there. I have modified the check to remove unnecessary ambiguity while still maintaining the constant creation interface. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1857268078 From dcubed at openjdk.org Mon Nov 25 21:36:36 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 25 Nov 2024 21:36:36 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing [v4] In-Reply-To: References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: On Wed, 20 Nov 2024 18:53:37 GMT, Fredrik Bredberg wrote: >> @dcubed-ojdk is too busy, so I was asked to take over [https://github.com/openjdk/jdk/pull/18664](https://github.com/openjdk/jdk/pull/18664) and finish it. >> >> That old PR contains all the details and also got some review comments, which I have tried to address in this new PR. >> >> Tests run without failures on supported platforms. > > Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision: > > Update two after review Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22238#pullrequestreview-2459671726 From dcubed at openjdk.org Mon Nov 25 21:36:38 2024 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 25 Nov 2024 21:36:38 GMT Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing [v4] In-Reply-To: References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com> Message-ID: On Fri, 22 Nov 2024 12:13:23 GMT, David Holmes wrote: >> There's precedent for this naming in our internal tests (runthese and kitchensink). > > Sure but if we add/remove a test case we have to rename the test file. It is not obvious what numbers combine to produce 36M. It should be easy enough to add a comment to the wrapper to explain why the suffix is 36M. Yes, there is quite a bit of precedent for including the expected duration in the name of the wrapper. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22238#discussion_r1857368172 From dlong at openjdk.org Mon Nov 25 22:50:43 2024 From: dlong at openjdk.org (Dean Long) Date: Mon, 25 Nov 2024 22:50:43 GMT Subject: RFR: 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 15:27:22 GMT, Andrew Haley wrote: > This bug only affects x86-64 machines without a `popcnt` instruction, which basically means pre-SSE4.2 machines. This means that x86-64 processors made around 2010 are affected. > > My thanks to everyone who was was involved in bisecting this, particularly Martin Bucholz who seems to be the only one testing on such old hardware. Marked as reviewed by dlong (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22365#pullrequestreview-2459787294 From vlivanov at openjdk.org Mon Nov 25 23:32:43 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 25 Nov 2024 23:32:43 GMT Subject: RFR: 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only In-Reply-To: References: Message-ID: <3aaeGz7V4yLsAIeSA4ZuTr5isbsusslvk7Qftf7jiI4=.54e563e5-1319-49e0-905e-ed5159157c5e@github.com> On Mon, 25 Nov 2024 15:27:22 GMT, Andrew Haley wrote: > This bug only affects x86-64 machines without a `popcnt` instruction, which basically means pre-SSE4.2 machines. This means that x86-64 processors made around 2010 are affected. > > My thanks to everyone who was was involved in bisecting this, particularly Martin Bucholz who seems to be the only one testing on such old hardware. It's unfrotunate the bug wasn't caught during review. src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4915: > 4913: bind(done); > 4914: } > 4915: #ifdef ASSERT I understand that it greatly increases the reproducibility of the bug, but does such an adhoc code snippet adds much from maintenance perspective? Reusing registers is common in assembly code, so if all places where a register value is destroyed are annotated in a similar way, it would add a lot of noise on source code level. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22365#pullrequestreview-2459822149 PR Review Comment: https://git.openjdk.org/jdk/pull/22365#discussion_r1857464139 From vlivanov at openjdk.org Mon Nov 25 23:32:44 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 25 Nov 2024 23:32:44 GMT Subject: RFR: 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only In-Reply-To: <3aaeGz7V4yLsAIeSA4ZuTr5isbsusslvk7Qftf7jiI4=.54e563e5-1319-49e0-905e-ed5159157c5e@github.com> References: <3aaeGz7V4yLsAIeSA4ZuTr5isbsusslvk7Qftf7jiI4=.54e563e5-1319-49e0-905e-ed5159157c5e@github.com> Message-ID: On Mon, 25 Nov 2024 23:20:37 GMT, Vladimir Ivanov wrote: >> This bug only affects x86-64 machines without a `popcnt` instruction, which basically means pre-SSE4.2 machines. This means that x86-64 processors made around 2010 are affected. >> >> My thanks to everyone who was was involved in bisecting this, particularly Martin Bucholz who seems to be the only one testing on such old hardware. > > src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4915: > >> 4913: bind(done); >> 4914: } >> 4915: #ifdef ASSERT > > I understand that it greatly increases the reproducibility of the bug, but does such an adhoc code snippet adds much from maintenance perspective? Reusing registers is common in assembly code, so if all places where a register value is destroyed are annotated in a similar way, it would add a lot of noise on source code level. I'm looking at `MacroAssembler::lookup_secondary_supers_table_var()` and the only thing which can be improved there is an extra comment around line 5116 stressing that `population_count` destroys `slot`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22365#discussion_r1857469749 From dlong at openjdk.org Mon Nov 25 23:34:41 2024 From: dlong at openjdk.org (Dean Long) Date: Mon, 25 Nov 2024 23:34:41 GMT Subject: RFR: 8318127: align_up has potential overflow [v8] In-Reply-To: <-stdx3eY-an8wxy7v7Pix-2lB4mml0rHiaN1xvozs1U=.06cd889e-a421-4b55-a320-57233b2c4ea4@github.com> References: <-stdx3eY-an8wxy7v7Pix-2lB4mml0rHiaN1xvozs1U=.06cd889e-a421-4b55-a320-57233b2c4ea4@github.com> Message-ID: On Thu, 10 Oct 2024 15:12:57 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The `align_up` function contained code which could potentially overflow and produce an incorrect result. This PR adds an assert to check for such. >> >> Additionally, two test case that previously caused an overflow have been updated to use the highest possible values that do not trigger an overflow. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > newline at eof Marked as reviewed by dlong (Reviewer). src/hotspot/share/utilities/align.hpp line 75: > 73: template::value)> > 74: constexpr T align_up(T size, A alignment) { > 75: T mask = checked_cast(alignment_mask(alignment)); Should we assert that mask >= 0 or trust that the result of alignment_mask() is never negative? ------------- PR Review: https://git.openjdk.org/jdk/pull/20808#pullrequestreview-2459833599 PR Review Comment: https://git.openjdk.org/jdk/pull/20808#discussion_r1857471595 From kim.barrett at oracle.com Tue Nov 26 00:25:38 2024 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 25 Nov 2024 19:25:38 -0500 Subject: HotSpot doesn't use NULL In-Reply-To: <8BD53E0B-A928-4F59-AD14-1E8B88F8AE4C@amazon.de> References: <0298f200-cdcc-40d0-9926-a5c0436c6092@oracle.com> <8BD53E0B-A928-4F59-AD14-1E8B88F8AE4C@amazon.de> Message-ID: On 11/25/24 7:16 AM, Kennke, Roman wrote: > Is it possible - and would it make sense - to mechanically forbit NULL? E.g. by re-defining it in a central place, just like we do for other stuff like constuctors for certain things? I don't think so. Redefining it in a way that makes it unusable seems problematic because it might affect non-HotSpot code. An example where I'm pretty sure this would be a problem is gtest. Redefining it in a way that still works, as is currently done for Windows (see JDK-8324686) doesn't prevent adding new uses. Something like the suggestion in JDK-8343802 is the only viable approach I've been able to come up with.? I've seen discussion that maybe there should be a gcc -Wnull-as-null-pointer-constant (alongside the existing -Wzero-as-null-pointer-constant), but that doesn't currently exist, and would only help for gcc-based platforms. clang-tidy has modernize-use-nullptr: "The check converts the usage of null pointer constants (e.g. NULL, 0) to use the new C++11 and C23 nullptr keyword."? Perhaps something could be built on that? Doing so is likely more work than the grep-based approach suggested in JDK-8343802. From dholmes at openjdk.org Tue Nov 26 00:31:50 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Nov 2024 00:31:50 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v4] In-Reply-To: References: <00t4bv6pSjmB-nOYziAApdamEvxsXovEzRwdP9yLA7w=.4b1d9289-00a7-4f82-a8f9-6d8d3174f5cd@github.com> Message-ID: <3PpCq6QVMs7_nN3WSfJurjkE9rAuN_6XvyspU5nQ6ow=.ce0774e7-6ebb-42a6-83e6-1a6cf2c5a5fc@github.com> On Mon, 25 Nov 2024 19:26:40 GMT, Calvin Cheung wrote: >> src/hotspot/share/cds/filemap.cpp line 2718: >> >>> 2716: // The result should be a [B >>> 2717: assert(obj->is_typeArray(), "just checking"); >>> 2718: assert(TypeArrayKlass::cast(obj->klass())->element_type() == T_BYTE, "just checking"); >> >> This seems unnecessary. What kind of errors are you trying to detect with this? The method signature indicates it returns a byte-array. > > I adapted the asserts from diagnosticCommand.cpp. I'm keeping the first assert. Is it ok? Both asserts are unnecessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22262#discussion_r1857508019 From dholmes at openjdk.org Tue Nov 26 00:35:39 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Nov 2024 00:35:39 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v5] In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 19:30:12 GMT, Calvin Cheung wrote: >> Currently, when retrieving a ClassFileStream during runtime, we call into the zip library to retrieve the stream based only on a class name. This doesn't work well if the class is in a multi-release jar under a versioned directory such as `META-INF/versions/9/Foo.class`. To address this issue, this change calls the java api `ClassLoader.getResourceAsStream()` to retrieve the stream. >> >> Passed tiers 1 - 4 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @dholmes-ora comments Nothing further from me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22262#pullrequestreview-2459889166 From wkemper at openjdk.org Tue Nov 26 00:37:32 2024 From: wkemper at openjdk.org (William Kemper) Date: Tue, 26 Nov 2024 00:37:32 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v11] In-Reply-To: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: > This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. William Kemper has updated the pull request incrementally with two additional commits since the last revision: - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux - 8344985: GenShen: Refactor arraycopy barrier for generational mode Reviewed-by: shade ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21273/files - new: https://git.openjdk.org/jdk/pull/21273/files/381af0cd..08b59bc3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=09-10 Stats: 14 lines in 1 file changed: 6 ins; 7 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21273/head:pull/21273 PR: https://git.openjdk.org/jdk/pull/21273 From kbarrett at openjdk.org Tue Nov 26 01:10:43 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 26 Nov 2024 01:10:43 GMT Subject: RFR: 8318127: align_up has potential overflow [v8] In-Reply-To: References: <-stdx3eY-an8wxy7v7Pix-2lB4mml0rHiaN1xvozs1U=.06cd889e-a421-4b55-a320-57233b2c4ea4@github.com> Message-ID: On Mon, 25 Nov 2024 23:31:38 GMT, Dean Long wrote: >> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: >> >> newline at eof > > src/hotspot/share/utilities/align.hpp line 75: > >> 73: template::value)> >> 74: constexpr T align_up(T size, A alignment) { >> 75: T mask = checked_cast(alignment_mask(alignment)); > > Should we assert that mask >= 0 or trust that the result of alignment_mask() is never negative? alignment_mask requires the alignment to be a power of 2, so can't return a negative value. But now I'm wondering why the size and alignment are allowed to be of different types in all these functions. If alignment doesn't fit in T then it seems like lots of things can go wrong. Maybe alignment_mask should take the size type as an additional (non-deduced) template parameter and return a value of that type after checking it fits? Or something like that, as that isn't quite right for is_aligned. All uses of alignment_mask do some implicit or explicit conversion involving the size type. Sounds like there's some followup work to do. I'll file a JBS issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20808#discussion_r1857533533 From dholmes at openjdk.org Tue Nov 26 01:49:42 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Nov 2024 01:49:42 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_summary diagnostic command In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 21:34:08 GMT, Larry Cable wrote: > c.f: [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420) > > Summary > ------- > > Add `jcmd Thread.vthread_summary` to print summary information that is useful when trying to diagnose issues with virtual threads. > > > Problem > ------- > > The JDK is lacking tooling to diagnose issues with virtual threads. > > > Solution > -------- > > Add a new command that the `jcmd` command line tool can use to print information about virtual threads. The output includes the virtual thread scheduler, the schedulers used to support timeouts, and the I/O pollers used to support virtual threads doing socket I/O, and a summary of the thread groupings. > > Here is sample output. The output is intended for experts and is not intended for automated parsing. > > > Virtual thread scheduler: > java.util.concurrent.ForkJoinPool at 4a624db0[Running, parallelism = 16, size = 2, active = 0, running = 0, steals = 2, tasks = 0, submissions = 0] > > Timeout schedulers: > [0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > [1] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845[Running, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 0] > [2] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > [3] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > > Read I/O pollers: > [0] sun.nio.ch.KQueuePoller at 524bf25 [registered = 1] > > Write I/O pollers: > [0] sun.nio.ch.KQueuePoller at 25c41da2 [registered = 0] > > Thread groupings: > [platform threads = 11, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4 [platform threads = 0, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef [platform threads = 0, virtual threads = 0] > ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer at 4fa374ea [platform threads = 0, virtual threads = 0] > java.util.concurrent.ThreadPoolExecutor at 506e1b77 [platform threads = 1, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12 [platform threads = 0, virtual threads = 0] > java.util.concurrent.ThreadPerTaskExecutor at 24155ffc [platform threads = 0, virtual threads = 2] > ForkJoinPool-1/jdk.internal.vm.SharedThreadContainer at 48a03463 [platform threads = 2, virtual threads = 0] > java.util.concurrent.Scheduled... Generally looks like a good addition. We need to finalize names and content as per CSR request. A few coding/style issues that I've flagged. Thanks. src/hotspot/share/services/diagnosticCommand.cpp line 1124: > 1122: Symbol* sym = vmSymbols::jdk_internal_vm_VThreadSummary(); > 1123: Klass* k = SystemDictionary::resolve_or_fail(sym, true, CHECK); > 1124: if (HAS_PENDING_EXCEPTION) { You can never reach line 1124 if there is a pending exception because the `CHECK` macro will do a return from the method. I see the same problem pre-exists in the other DCmd code. If you want to handle exceptions directly then you want to use `THREAD` not `CHECK`. src/hotspot/share/services/diagnosticCommand.cpp line 1150: > 1148: oop res = cast_to_oop(result.get_jobject()); > 1149: assert(res->is_typeArray(), "just checking"); > 1150: assert(TypeArrayKlass::cast(res->klass())->element_type() == T_BYTE, "just checking"); I just called this out in another PR. These assertions are completely unnecessary unless you are trying to check the basic JavaCall operation - which you should not be. You are calling a method that returns a `byte[]` and that is what you will get back. src/hotspot/share/services/diagnosticCommand.hpp line 434: > 432: static const char* name() { return "Thread.print"; } > 433: static const char* description() { > 434: return "Print all platform threads with stacktraces."; Probably best not hide this correction in this PR but file a separate issue for it. src/java.base/share/classes/jdk/internal/vm/VThreadSummary.java line 75: > 73: private static void printSchedulers(StringBuilder sb) { > 74: sb.append("Virtual thread scheduler:") > 75: .append(System.lineSeparator()); Can't you just do: sb.append("Virtual thread scheduler:\n") ? src/java.base/share/classes/jdk/internal/vm/VThreadSummary.java line 77: > 75: .append(System.lineSeparator()); > 76: sb.append(JLA.virtualThreadDefaultScheduler()) > 77: .append(System.lineSeparator()); Stylistically it is common/customary to align the dot operator in chained method calls. src/java.base/share/classes/jdk/internal/vm/VThreadSummary.java line 106: > 104: .append(masterPoller) > 105: .append(System.lineSeparator()); > 106: sb.append(System.lineSeparator()); Is this style trying to draw attention to the blank lines between sections? It looks odd to me to not chain the final append as well. src/java.base/share/classes/sun/nio/ch/Poller.java line 280: > 278: public String toString() { > 279: return Objects.toIdentityString(this) + " [registered = " + map.size() + "]"; > 280: } Why did you move this and "inline" the content of `registered()`? src/jdk.jcmd/share/man/jcmd.1 line 1: > 1: .\" Copyright (c) 2012, 2024, Oracle and/or its affiliates. All rights reserved. The `.1` nroff files are no longer in the repo, you need to edit the markdown source instead. test/hotspot/jtreg/serviceability/dcmd/thread/VThreadSummaryTest.java line 74: > 72: .shouldContain(Objects.toIdentityString(defaultScheduler())) > 73: .shouldContain("Timeout schedulers:") > 74: .shouldContain("[0] " + ScheduledThreadPoolExecutor.class.getName()); Again please align dots on chained calls. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22121#pullrequestreview-2459949901 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857550460 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857551670 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857552627 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857554925 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857554142 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857561627 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857562945 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857563813 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857564382 From dholmes at openjdk.org Tue Nov 26 02:10:39 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Nov 2024 02:10:39 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_summary diagnostic command In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 01:38:55 GMT, David Holmes wrote: >> c.f: [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420) >> >> Summary >> ------- >> >> Add `jcmd Thread.vthread_summary` to print summary information that is useful when trying to diagnose issues with virtual threads. >> >> >> Problem >> ------- >> >> The JDK is lacking tooling to diagnose issues with virtual threads. >> >> >> Solution >> -------- >> >> Add a new command that the `jcmd` command line tool can use to print information about virtual threads. The output includes the virtual thread scheduler, the schedulers used to support timeouts, and the I/O pollers used to support virtual threads doing socket I/O, and a summary of the thread groupings. >> >> Here is sample output. The output is intended for experts and is not intended for automated parsing. >> >> >> Virtual thread scheduler: >> java.util.concurrent.ForkJoinPool at 4a624db0[Running, parallelism = 16, size = 2, active = 0, running = 0, steals = 2, tasks = 0, submissions = 0] >> >> Timeout schedulers: >> [0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> [1] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845[Running, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 0] >> [2] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> [3] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> >> Read I/O pollers: >> [0] sun.nio.ch.KQueuePoller at 524bf25 [registered = 1] >> >> Write I/O pollers: >> [0] sun.nio.ch.KQueuePoller at 25c41da2 [registered = 0] >> >> Thread groupings: >> [platform threads = 11, virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4 [platform threads = 0, virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef [platform threads = 0, virtual threads = 0] >> ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer at 4fa374ea [platform threads = 0, virtual threads = 0] >> java.util.concurrent.ThreadPoolExecutor at 506e1b77 [platform threads = 1, virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12 [platform threads = 0, virtual threads = 0] >> java.util.concurrent.ThreadPerTaskExecutor at 24155ffc [platform threads = 0, virtual threads = 2] >> ForkJoinPool-1/jdk.internal.vm.SharedThreadC... > > src/java.base/share/classes/jdk/internal/vm/VThreadSummary.java line 75: > >> 73: private static void printSchedulers(StringBuilder sb) { >> 74: sb.append("Virtual thread scheduler:") >> 75: .append(System.lineSeparator()); > > Can't you just do: > > sb.append("Virtual thread scheduler:\n") > > ? Sorry I was thinking about `%n` but you can't use that here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857616753 From ccheung at openjdk.org Tue Nov 26 03:38:25 2024 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 26 Nov 2024 03:38:25 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v6] In-Reply-To: References: Message-ID: > Currently, when retrieving a ClassFileStream during runtime, we call into the zip library to retrieve the stream based only on a class name. This doesn't work well if the class is in a multi-release jar under a versioned directory such as `META-INF/versions/9/Foo.class`. To address this issue, this change calls the java api `ClassLoader.getResourceAsStream()` to retrieve the stream. > > Passed tiers 1 - 4 testing. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: remove assert in filemap.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22262/files - new: https://git.openjdk.org/jdk/pull/22262/files/a1b13168..1f622809 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22262&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22262&range=04-05 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22262.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22262/head:pull/22262 PR: https://git.openjdk.org/jdk/pull/22262 From ccheung at openjdk.org Tue Nov 26 03:38:25 2024 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 26 Nov 2024 03:38:25 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v4] In-Reply-To: <3PpCq6QVMs7_nN3WSfJurjkE9rAuN_6XvyspU5nQ6ow=.ce0774e7-6ebb-42a6-83e6-1a6cf2c5a5fc@github.com> References: <00t4bv6pSjmB-nOYziAApdamEvxsXovEzRwdP9yLA7w=.4b1d9289-00a7-4f82-a8f9-6d8d3174f5cd@github.com> <3PpCq6QVMs7_nN3WSfJurjkE9rAuN_6XvyspU5nQ6ow=.ce0774e7-6ebb-42a6-83e6-1a6cf2c5a5fc@github.com> Message-ID: On Tue, 26 Nov 2024 00:29:15 GMT, David Holmes wrote: >> I adapted the asserts from diagnosticCommand.cpp. I'm keeping the first assert. Is it ok? > > Both asserts are unnecessary. I've removed the assert. Will run some tests before integrating the fix. Please re-review when you have a chance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22262#discussion_r1857721036 From dholmes at openjdk.org Tue Nov 26 04:08:38 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Nov 2024 04:08:38 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v6] In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 03:38:25 GMT, Calvin Cheung wrote: >> Currently, when retrieving a ClassFileStream during runtime, we call into the zip library to retrieve the stream based only on a class name. This doesn't work well if the class is in a multi-release jar under a versioned directory such as `META-INF/versions/9/Foo.class`. To address this issue, this change calls the java api `ClassLoader.getResourceAsStream()` to retrieve the stream. >> >> Passed tiers 1 - 4 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > remove assert in filemap.cpp Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22262#pullrequestreview-2460248677 From iklam at openjdk.org Tue Nov 26 05:32:44 2024 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 26 Nov 2024 05:32:44 GMT Subject: RFR: 8344904: Interned strings in old classes are not stored in CDS archive [v2] In-Reply-To: References: Message-ID: <7ausG_UkrSqNJBoU4iMf1WgvrymR0gtOQmm_uUOw3tg=.558f2d07-cd4b-4031-87ed-0889cdf04d9f@github.com> > Before this fix, CDS will only archive interned strings that are reachable from `ConstantPool::resolved_references()`, which is created only after a class is linked. However, old classes are not linked, so we didn't archive their interned strings. > > It's possible for the Java mirror of an (unlinked) old class to point to interned strings. E.g., > > > public super class OldClassWithStaticString > version 49:0 > { > public static final Field s:"Ljava/lang/String;" = String "xxxx123yyyy456"; > > > The 's' field is initialized during class file parsing, so we must intern the `"xxxx123yyyy456"` string. > > The fix is to collect interned strings from the static fields of unlinked classes. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @dholmes-ora comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22340/files - new: https://git.openjdk.org/jdk/pull/22340/files/1b07b398..c1a6bc76 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22340&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22340&range=00-01 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22340.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22340/head:pull/22340 PR: https://git.openjdk.org/jdk/pull/22340 From iklam at openjdk.org Tue Nov 26 05:37:38 2024 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 26 Nov 2024 05:37:38 GMT Subject: RFR: 8344904: Interned strings in old classes are not stored in CDS archive [v2] In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 01:16:24 GMT, David Holmes wrote: > Plus if this is only about the CDS archive can we say that in the title instead of AOT cache? IIUC this is an existing CDS issue and unrelated to any recent AOT/Leyden integrations - right? After JEP 483, we will gradually switch over to the term of "AOT" to describe all ahead-of-time features (including class metadata processing, bytecode compilation, Java object generation, etc). The term "CDS" will be deemphasized as it's a historical acronym that doesn't accurate describe its purpose anymore, but we will probably still use it when convenient (as the word CDS still appears a lot in the source code). For this issue, though, since it might be backported, I changed the title back to "CDS" so it will not look out of place in older releases. > src/hotspot/share/oops/constantPool.cpp line 411: > >> 409: if (!ik->is_linked()) { >> 410: // resolved_references() doesn't exist yet, so we have no resolved CONSTANT_String entries. However, >> 411: // Some static final fields may have default values that were initialized when the class was parsed. > > Suggestion: > > // some static final fields may have default values that were initialized when the class was parsed. Fixed > src/hotspot/share/oops/constantPool.cpp line 412: > >> 410: // resolved_references() doesn't exist yet, so we have no resolved CONSTANT_String entries. However, >> 411: // Some static final fields may have default values that were initialized when the class was parsed. >> 412: // We need to enter those into the CDS archived strings table. > > Suggestion: > > // We need to enter those into the CDS archive strings table. Fixed > test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/OldClassWithStaticString.jasm line 35: > >> 33: >> 34: public super class OldClassWithStaticString >> 35: version 49:0 > > Is this a jasm file only because we need the version 49? If so please state that somewhere. Fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22340#issuecomment-2499701207 PR Review Comment: https://git.openjdk.org/jdk/pull/22340#discussion_r1857803999 PR Review Comment: https://git.openjdk.org/jdk/pull/22340#discussion_r1857804056 PR Review Comment: https://git.openjdk.org/jdk/pull/22340#discussion_r1857804181 From kbarrett at openjdk.org Tue Nov 26 05:47:40 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 26 Nov 2024 05:47:40 GMT Subject: RFR: 8318127: align_up has potential overflow [v8] In-Reply-To: References: <-stdx3eY-an8wxy7v7Pix-2lB4mml0rHiaN1xvozs1U=.06cd889e-a421-4b55-a320-57233b2c4ea4@github.com> Message-ID: On Tue, 26 Nov 2024 01:07:48 GMT, Kim Barrett wrote: >> src/hotspot/share/utilities/align.hpp line 75: >> >>> 73: template::value)> >>> 74: constexpr T align_up(T size, A alignment) { >>> 75: T mask = checked_cast(alignment_mask(alignment)); >> >> Should we assert that mask >= 0 or trust that the result of alignment_mask() is never negative? > > alignment_mask requires the alignment to be a power of 2, so can't return a > negative value. > > But now I'm wondering why the size and alignment are allowed to be of > different types in all these functions. If alignment doesn't fit in T then it > seems like lots of things can go wrong. Maybe alignment_mask should take the > size type as an additional (non-deduced) template parameter and return a value > of that type after checking it fits? Or something like that, as that isn't > quite right for is_aligned. All uses of alignment_mask do some implicit or > explicit conversion involving the size type. > > Sounds like there's some followup work to do. I'll file a JBS issue. https://bugs.openjdk.org/browse/JDK-8345005 Validate alignment in align_down and related functions ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20808#discussion_r1857818311 From duke at openjdk.org Tue Nov 26 06:31:43 2024 From: duke at openjdk.org (Saint Wesonga) Date: Tue, 26 Nov 2024 06:31:43 GMT Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9] In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 09:17:53 GMT, Julian Waters wrote: >> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely > > Julian Waters 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 16 additional commits since the last revision: > > - Merge branch 'openjdk:master' into hotspot > - Reintroduce ifdef removed in the nuking of the Windows 32 bit x86 port in sharedRuntimeRem.cpp > - fmod_win64 in sharedRuntime.cpp > - Should only declare fmod_win64 on Windows/ARM64 sharedRuntime.hpp > - fmod_win64 in src/hotspot/share/runtime/sharedRuntime.hpp > > Co-authored-by: Andrew Haley > - No spaces in test_os_windows.cpp > - No spaces in test/hotspot/gtest/runtime/test_os.cpp > > Co-authored-by: Andrew Haley > - Revise comment in sharedRuntime.hpp > - Revise comment in sharedRuntime.cpp > - size_t brace initialization instead of unsigned literals in test_os_windows.cpp > - ... and 6 more: https://git.openjdk.org/jdk/compare/03c16e15...6cf1c83a Marked as reviewed by swesonga at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/21627#pullrequestreview-2460491392 From alanb at openjdk.org Tue Nov 26 06:39:45 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 26 Nov 2024 06:39:45 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_summary diagnostic command In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 01:37:33 GMT, David Holmes wrote: >> c.f: [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420) >> >> Summary >> ------- >> >> Add `jcmd Thread.vthread_summary` to print summary information that is useful when trying to diagnose issues with virtual threads. >> >> >> Problem >> ------- >> >> The JDK is lacking tooling to diagnose issues with virtual threads. >> >> >> Solution >> -------- >> >> Add a new command that the `jcmd` command line tool can use to print information about virtual threads. The output includes the virtual thread scheduler, the schedulers used to support timeouts, and the I/O pollers used to support virtual threads doing socket I/O, and a summary of the thread groupings. >> >> Here is sample output. The output is intended for experts and is not intended for automated parsing. >> >> >> Virtual thread scheduler: >> java.util.concurrent.ForkJoinPool at 4a624db0[Running, parallelism = 16, size = 2, active = 0, running = 0, steals = 2, tasks = 0, submissions = 0] >> >> Timeout schedulers: >> [0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> [1] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845[Running, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 0] >> [2] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> [3] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> >> Read I/O pollers: >> [0] sun.nio.ch.KQueuePoller at 524bf25 [registered = 1] >> >> Write I/O pollers: >> [0] sun.nio.ch.KQueuePoller at 25c41da2 [registered = 0] >> >> Thread groupings: >> [platform threads = 11, virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4 [platform threads = 0, virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef [platform threads = 0, virtual threads = 0] >> ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer at 4fa374ea [platform threads = 0, virtual threads = 0] >> java.util.concurrent.ThreadPoolExecutor at 506e1b77 [platform threads = 1, virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12 [platform threads = 0, virtual threads = 0] >> java.util.concurrent.ThreadPerTaskExecutor at 24155ffc [platform threads = 0, virtual threads = 2] >> ForkJoinPool-1/jdk.internal.vm.SharedThreadC... > > src/java.base/share/classes/jdk/internal/vm/VThreadSummary.java line 77: > >> 75: .append(System.lineSeparator()); >> 76: sb.append(JLA.virtualThreadDefaultScheduler()) >> 77: .append(System.lineSeparator()); > > Stylistically it is common/customary to align the dot operator in chained method calls. It's just a style thing, it was done this way because the first string is the heading, the strings that follow go under the heading. > src/jdk.jcmd/share/man/jcmd.1 line 1: > >> 1: .\" Copyright (c) 2012, 2024, Oracle and/or its affiliates. All rights reserved. > > The `.1` nroff files are no longer in the repo, you need to edit the markdown source instead. That was already pointed out, I think the PR was merged from an older version. > test/hotspot/jtreg/serviceability/dcmd/thread/VThreadSummaryTest.java line 74: > >> 72: .shouldContain(Objects.toIdentityString(defaultScheduler())) >> 73: .shouldContain("Timeout schedulers:") >> 74: .shouldContain("[0] " + ScheduledThreadPoolExecutor.class.getName()); > > Again please align dots on chained calls. and the IDE will of course re-align it at next edit :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857881180 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857881767 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857882356 From dholmes at openjdk.org Tue Nov 26 06:42:09 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Nov 2024 06:42:09 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 Message-ID: After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} are all singletons and so the actual strings can just be inlined directly into the code that uses them. Testing: - GHA - Tiers 1-4 sanity - Thanks ------------- Commit messages: - 8343703: Symbol name cleanups after JEP 479 Changes: https://git.openjdk.org/jdk/pull/22380/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22380&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343703 Stats: 95 lines in 5 files changed: 7 ins; 49 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/22380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22380/head:pull/22380 PR: https://git.openjdk.org/jdk/pull/22380 From alanb at openjdk.org Tue Nov 26 06:47:40 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 26 Nov 2024 06:47:40 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_summary diagnostic command In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 01:41:34 GMT, David Holmes wrote: >> c.f: [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420) >> >> Summary >> ------- >> >> Add `jcmd Thread.vthread_summary` to print summary information that is useful when trying to diagnose issues with virtual threads. >> >> >> Problem >> ------- >> >> The JDK is lacking tooling to diagnose issues with virtual threads. >> >> >> Solution >> -------- >> >> Add a new command that the `jcmd` command line tool can use to print information about virtual threads. The output includes the virtual thread scheduler, the schedulers used to support timeouts, and the I/O pollers used to support virtual threads doing socket I/O, and a summary of the thread groupings. >> >> Here is sample output. The output is intended for experts and is not intended for automated parsing. >> >> >> Virtual thread scheduler: >> java.util.concurrent.ForkJoinPool at 4a624db0[Running, parallelism = 16, size = 2, active = 0, running = 0, steals = 2, tasks = 0, submissions = 0] >> >> Timeout schedulers: >> [0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> [1] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845[Running, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 0] >> [2] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> [3] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> >> Read I/O pollers: >> [0] sun.nio.ch.KQueuePoller at 524bf25 [registered = 1] >> >> Write I/O pollers: >> [0] sun.nio.ch.KQueuePoller at 25c41da2 [registered = 0] >> >> Thread groupings: >> [platform threads = 11, virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4 [platform threads = 0, virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef [platform threads = 0, virtual threads = 0] >> ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer at 4fa374ea [platform threads = 0, virtual threads = 0] >> java.util.concurrent.ThreadPoolExecutor at 506e1b77 [platform threads = 1, virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12 [platform threads = 0, virtual threads = 0] >> java.util.concurrent.ThreadPerTaskExecutor at 24155ffc [platform threads = 0, virtual threads = 2] >> ForkJoinPool-1/jdk.internal.vm.SharedThreadC... > > src/java.base/share/classes/jdk/internal/vm/VThreadSummary.java line 106: > >> 104: .append(masterPoller) >> 105: .append(System.lineSeparator()); >> 106: sb.append(System.lineSeparator()); > > Is this style trying to draw attention to the blank lines between sections? It looks odd to me to not chain the final append as well. It is a blank line, shouldn't be chained to the previous statement. > src/java.base/share/classes/sun/nio/ch/Poller.java line 280: > >> 278: public String toString() { >> 279: return Objects.toIdentityString(this) + " [registered = " + map.size() + "]"; >> 280: } > > Why did you move this and "inline" the content of `registered()`? I think that is PR merge issue, it's correct in the loom repo. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857890217 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857890689 From amitkumar at openjdk.org Tue Nov 26 06:58:15 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 26 Nov 2024 06:58:15 GMT Subject: RFR: 8340731: Cleanup remaining IA64 references in hotspot code Message-ID: This PR cleans up `IA64` entries form hotspot codebase. As mentioned in the JBS, I left `zero` component as-it-is: ./cpu/zero/bytecodeInterpreter_zero.hpp:31:#if defined(PPC) || defined(IA64) ./os_cpu/linux_zero/os_linux_zero.cpp:350:#ifdef IA64 ./os_cpu/linux_zero/os_linux_zero.cpp:351: // IA64 has two stacks sharing the same area of memory, a normal ./os_cpu/linux_zero/os_linux_zero.cpp:360:#endif // IA64 Fastdebug VM Build on Mac-M1 & Linux/s390x is fine. Tests are in progress. ------------- Commit messages: - cleanup Changes: https://git.openjdk.org/jdk/pull/22382/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22382&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340731 Stats: 81 lines in 17 files changed: 4 ins; 56 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/22382.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22382/head:pull/22382 PR: https://git.openjdk.org/jdk/pull/22382 From stuefe at openjdk.org Tue Nov 26 07:02:39 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 26 Nov 2024 07:02:39 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v4] In-Reply-To: References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: On Thu, 14 Nov 2024 13:53:19 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> This enhancement adds register printouts on asserts or guarantees into the hs_err_pid.log error reporting files for Windows. >> >> Additionally, it saves an accurate EXCEPTION_RECORD into the hs_err_pid.mdmp file, also for asserts or guarantees, so the assertion context is now easily accessible in Windbg using .ecxr. >> >> For more details on this enhancement, please see the JIRA issue. >> >> Testing: Tier 1,2,3, jdk_jfr >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > extended test LGTM. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21994#pullrequestreview-2460550643 From asemenov at openjdk.org Tue Nov 26 07:20:37 2024 From: asemenov at openjdk.org (Artem Semenov) Date: Tue, 26 Nov 2024 07:20:37 GMT Subject: RFR: 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only In-Reply-To: References: Message-ID: <8wn2L9_COkaoITYRPr7Y9TkIp9DTnZwqchX-GpDaCJc=.6b522877-40ac-4de5-857b-db7c81cbba16@github.com> On Mon, 25 Nov 2024 15:27:22 GMT, Andrew Haley wrote: > This bug only affects x86-64 machines without a `popcnt` instruction, which basically means pre-SSE4.2 machines. This means that x86-64 processors made around 2010 are affected. > > My thanks to everyone who was was involved in bisecting this, particularly Martin Bucholz who seems to be the only one testing on such old hardware. Great! It works for me. ------------- Marked as reviewed by asemenov (Committer). PR Review: https://git.openjdk.org/jdk/pull/22365#pullrequestreview-2460594843 From dholmes at openjdk.org Tue Nov 26 07:23:38 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Nov 2024 07:23:38 GMT Subject: RFR: 8340731: Cleanup remaining IA64 references in hotspot code In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 06:52:51 GMT, Amit Kumar wrote: > This PR cleans up `IA64` entries form hotspot codebase. > > As mentioned in the JBS, I left `zero` component as-it-is: > > ./cpu/zero/bytecodeInterpreter_zero.hpp:31:#if defined(PPC) || defined(IA64) > ./os_cpu/linux_zero/os_linux_zero.cpp:350:#ifdef IA64 > ./os_cpu/linux_zero/os_linux_zero.cpp:351: // IA64 has two stacks sharing the same area of memory, a normal > ./os_cpu/linux_zero/os_linux_zero.cpp:360:#endif // IA64 > > > Fastdebug VM Build on Mac-M1 & Linux/s390x is fine. Tests are in progress. @offamitkumar thanks for taking up this cleanup! Generally looks okay, a couple of nits and queries. Thanks src/hotspot/share/runtime/frame.hpp line 167: > 165: > 166: // Every frame needs to return a unique id which distinguishes it from all other frames. > 167: // For sparc and ia32 use sp. ia64 can have memory frames that are empty so multiple frames For now the IA32 part should remain. src/hotspot/share/runtime/frame.hpp line 168: > 166: // Every frame needs to return a unique id which distinguishes it from all other frames. > 167: // No real frame should have an id() of null so it is a distinguishing value for an unmatchable frame. > 168: // We also have relationals which allow comparing a frame to another frame's id() allow Suggestion: // We also have relationals which allow comparing a frame to another frame's id() allowing src/hotspot/share/runtime/javaCalls.cpp line 121: > 119: // Do this after the transition because this allows us to put an assert > 120: // the Java->vm transition which checks to see that stack is not walkable > 121: // which will catch violations of the resetting of last_Java_frame Not clear the comment is still valid given we no longer have sparc or ia64 support. src/hotspot/share/runtime/os.hpp line 858: > 856: // does not require a lookup in the unwind table, which is part of the binary > 857: // file but may be unsafe to read after a fatal error. So on x86, we can > 858: // only walk stack if %ebp is used as frame pointer; Suggestion: // only walk stack if %ebp is used as frame pointer. src/hotspot/share/utilities/elfFuncDescTable.hpp line 39: > 37: > 38: On PowerPC-64 a pointer to a function is not just a plain code address, > 39: but instead a pointer to a so-called function descriptor (which is simply a structure containing 3 pointers). Suggestion: On PowerPC-64 a pointer to a function is not just a plain code address, but instead a pointer to a so-called function descriptor (which is simply a structure containing 3 pointers). ------------- PR Review: https://git.openjdk.org/jdk/pull/22382#pullrequestreview-2460585995 PR Review Comment: https://git.openjdk.org/jdk/pull/22382#discussion_r1857931749 PR Review Comment: https://git.openjdk.org/jdk/pull/22382#discussion_r1857932776 PR Review Comment: https://git.openjdk.org/jdk/pull/22382#discussion_r1857934114 PR Review Comment: https://git.openjdk.org/jdk/pull/22382#discussion_r1857934547 PR Review Comment: https://git.openjdk.org/jdk/pull/22382#discussion_r1857935992 From volker.simonis at gmail.com Tue Nov 26 07:24:41 2024 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 26 Nov 2024 08:24:41 +0100 Subject: HotSpot doesn't use NULL In-Reply-To: References: <0298f200-cdcc-40d0-9926-a5c0436c6092@oracle.com> <8BD53E0B-A928-4F59-AD14-1E8B88F8AE4C@amazon.de> Message-ID: When I forwarded this to our team, William suggested to add a new jcheck test to warn about this. I'm not familiar with the new git-jcheck, but at a first glance, this looks like an interesting opportunity to me. What do you think? Kim Barrett schrieb am Di., 26. Nov. 2024, 01:26: > On 11/25/24 7:16 AM, Kennke, Roman wrote: > > Is it possible - and would it make sense - to mechanically forbit NULL? > E.g. by re-defining it in a central place, just like we do for other stuff > like constuctors for certain things? > I don't think so. > > Redefining it in a way that makes it unusable seems problematic because it > might affect non-HotSpot code. An example where I'm pretty sure this > would be > a problem is gtest. > > Redefining it in a way that still works, as is currently done for > Windows (see > JDK-8324686) doesn't prevent adding new uses. > > Something like the suggestion in JDK-8343802 is the only viable approach > I've > been able to come up with. I've seen discussion that maybe there should > be a > gcc -Wnull-as-null-pointer-constant (alongside the existing > -Wzero-as-null-pointer-constant), but that doesn't currently exist, and > would > only help for gcc-based platforms. > > clang-tidy has modernize-use-nullptr: "The check converts the usage of null > pointer constants (e.g. NULL, 0) to use the new C++11 and C23 nullptr > keyword." Perhaps something could be built on that? Doing so is likely > more > work than the grep-based approach suggested in JDK-8343802. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amitkumar at openjdk.org Tue Nov 26 07:29:14 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 26 Nov 2024 07:29:14 GMT Subject: RFR: 8340731: Cleanup remaining IA64 references in hotspot code [v2] In-Reply-To: References: Message-ID: > This PR cleans up `IA64` entries form hotspot codebase. > > As mentioned in the JBS, I left `zero` component as-it-is: > > ./cpu/zero/bytecodeInterpreter_zero.hpp:31:#if defined(PPC) || defined(IA64) > ./os_cpu/linux_zero/os_linux_zero.cpp:350:#ifdef IA64 > ./os_cpu/linux_zero/os_linux_zero.cpp:351: // IA64 has two stacks sharing the same area of memory, a normal > ./os_cpu/linux_zero/os_linux_zero.cpp:360:#endif // IA64 > > > Fastdebug VM Build on Mac-M1 & Linux/s390x is fine. Tests are in progress. Amit Kumar has updated the pull request incrementally with three additional commits since the last revision: - Update src/hotspot/share/runtime/frame.hpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Update src/hotspot/share/runtime/os.hpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Update src/hotspot/share/utilities/elfFuncDescTable.hpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22382/files - new: https://git.openjdk.org/jdk/pull/22382/files/6e806524..182fa294 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22382&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22382&range=00-01 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22382.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22382/head:pull/22382 PR: https://git.openjdk.org/jdk/pull/22382 From dholmes at openjdk.org Tue Nov 26 07:31:42 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Nov 2024 07:31:42 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 06:36:44 GMT, David Holmes wrote: > After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: > > #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} > #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} > #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} > #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} > #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} > #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} > > are all singletons and so the actual strings can just be inlined directly into the code that uses them. > > Testing: > - GHA > - Tiers 1-4 sanity > - > Thanks Something is broken ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/22380#issuecomment-2499867992 From dholmes at openjdk.org Tue Nov 26 07:31:42 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Nov 2024 07:31:42 GMT Subject: Withdrawn: 8343703: Symbol name cleanups after JEP 479 In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 06:36:44 GMT, David Holmes wrote: > After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: > > #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} > #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} > #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} > #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} > #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} > #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} > > are all singletons and so the actual strings can just be inlined directly into the code that uses them. > > Testing: > - GHA > - Tiers 1-4 sanity > - > Thanks This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22380 From epeter at openjdk.org Tue Nov 26 07:36:46 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 26 Nov 2024 07:36:46 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations [v2] In-Reply-To: References: <2t1Bka2nUU4K1Uqe3iy3Q5aFzriK2pTpZYqK9Zjyg0s=.a77d89c2-4edc-4d6c-94a3-5a350c921267@github.com> Message-ID: On Mon, 25 Nov 2024 19:55:27 GMT, Jatin Bhateja wrote: >> I heard no argument about why you did not split this up. Please do that in the future. It is hard to review well when there is this much code. If it is really necessary, then sure. Here it does not seem necessary to deliver all at once. >> >>> The patch includes IR framework-based scalar constant folding test points. >> You mention this IR test: >> https://github.com/openjdk/jdk/pull/21490/files#diff-3f8786f9f62662eda4b4a5c76c01fa04534c94d870d496501bfc20434ad45579R169-R174 >> >> Here I only see the use of very trivial values. I think we need more complicated cases. >> >> What about these: >> - Add/Sub/Mul/Div/Min/Max ... with NaN and infinity. >> - Same where it would overflow the FP16 range. >> - Negative zero tests. >> - Division by powers of 2. >> >> It would for example be nice if you could iterate over all inputs. FP16 with 2 inputs is only 32bits, that can be iterated in just a few seconds. Then you can run the computation with constants in the interpreter, and compare to the results in compiled code. > >> I heard no argument about why you did not split this up. Please do that in the future. It is hard to review well when there is this much code. If it is really necessary, then sure. Here it does not seem necessary to deliver all at once. >> >> > The patch includes IR framework-based scalar constant folding test points. >> > You mention this IR test: >> > https://github.com/openjdk/jdk/pull/21490/files#diff-3f8786f9f62662eda4b4a5c76c01fa04534c94d870d496501bfc20434ad45579R169-R174 >> >> Here I only see the use of very trivial values. I think we need more complicated cases. >> >> What about these: >> >> * Add/Sub/Mul/Div/Min/Max ... with NaN and infinity. >> * Same where it would overflow the FP16 range. >> * Negative zero tests. >> * Division by powers of 2. >> >> It would for example be nice if you could iterate over all inputs. FP16 with 2 inputs is only 32bits, that can be iterated in just a few seconds. Then you can run the computation with constants in the interpreter, and compare to the results in compiled code. > > [ScalarFloat16OperationsTest.java](https://github.com/openjdk/jdk/pull/21490/files#diff-6afb7e66ce0fcdac61df60af0231010b20cf16489ec7e4d5b0b41852db8796a0) > Adds has a specialized data provider that generates test vectors with special values, our functional validation is covering the entire Float16 value range. @jatin-bhateja > [ScalarFloat16OperationsTest.java](https://github.com/openjdk/jdk/pull/21490/files#diff-6afb7e66ce0fcdac61df60af0231010b20cf16489ec7e4d5b0b41852db8796a0) Adds has a specialized data provider that generates test vectors with special values, our functional validation is covering the entire Float16 value range. Maybe I'm not making myself clear here. The test vectors will never constant fold - the values you read from an array load will always be the full range of their type, and not a constant. And you added constant folding IGVN optimizations. So we should test both: - Compile-time variables: for this you can use array element loads. You have to generate the values randomly beforehand, spanning the whole Float16 value range. This I think is covered somewhat adequately. - Compile-time constants: for this you cannot use array element loads - they will not be constants. You have to use literals, or you can set `static final int val = RANDOM.nextInt();`, which will constant fold during compilation, or you can use `MethodHandles.constant(int.class, 1);` to get compile-time constants, that you can change and trigger recompilation with the new "constant". It starts with something as simple as your constant folding of addition: // Supplied function returns the sum of the inputs. // This also type-checks the inputs for sanity. Guaranteed never to // be passed a TOP or BOTTOM type, these are filtered out by pre-check. const Type* AddHFNode::add_ring(const Type* t0, const Type* t1) const { if (!t0->isa_half_float_constant() || !t1->isa_half_float_constant()) { return bottom_type(); } return TypeH::make(t0->getf() + t1->getf()); } Which uses this code: const TypeH *TypeH::make(float f) { assert( StubRoutines::f2hf_adr() != nullptr, ""); short hf = StubRoutines::f2hf(f); return (TypeH*)(new TypeH(hf))->hashcons(); } You are doing the addition in `float`, and then casting back to `half_float`. Probably correct. But does it do the rounding correctly? Does it deal with `infty` and `NaN` correctly? Probably, but I would like to see tests for that. This is the simple stuff. Then there are more complex cases. const Type* MinHFNode::add_ring(const Type* t0, const Type* t1) const { const TypeH* r0 = t0->isa_half_float_constant(); const TypeH* r1 = t1->isa_half_float_constant(); if (r0 == nullptr || r1 == nullptr) { return bottom_type(); } if (r0->is_nan()) { return r0; } if (r1->is_nan()) { return r1; } float f0 = r0->getf(); float f1 = r1->getf(); if (f0 != 0.0f || f1 != 0.0f) { return f0 < f1 ? r0 : r1; } // As per IEEE 754 specification, floating point comparison consider +ve and -ve // zeros as equals. Thus, performing signed integral comparison for max value // detection. return (jint_cast(f0) < jint_cast(f1)) ? r0 : r1; } Is this adequately tested over the whole range of inputs? Of course the inputs have to be **constant**, otherwise if you only do array loads, the values are obviously variable, i.e. they would fail at the `isa_half_float_constant` check. You do have some constant folding tests like this: @Test @IR(counts = {IRNode.MIN_HF, " 0 ", IRNode.REINTERPRET_S2HF, " 0 ", IRNode.REINTERPRET_HF2S, " 0 "}, applyIfCPUFeature = {"avx512_fp16", "true"}) public void testMinConstantFolding() { assertResult(min(valueOf(1.0f), valueOf(2.0f)).floatValue(), 1.0f, "testMinConstantFolding"); assertResult(min(valueOf(0.0f), valueOf(-0.0f)).floatValue(), -0.0f, "testMinConstantFolding"); } But this is **only 2 examples for min**. It does not cover all cases by a long shot. It covers 2 "nice" cases. I do not think that is sufficient. Often the bugs are hiding in special cases. Testing is really important to me. I've made the experience myself where I did not test optimizations well and later it can turn into a bug. Comments like these do not give me much confidence: > functional validation is covering the entire Float16 value range. Then I review the tests, and see: not all cases are covered. Now what am I supposed to do as a reviewer? It does not make me trust what you say in the future. Maybe this is all a misunderstanding - if so I hope my lengthy explanation clarifies what I mean. What do you think @Bhavana-Kilambi @PaulSandoz ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2499876085 From amitkumar at openjdk.org Tue Nov 26 07:37:43 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 26 Nov 2024 07:37:43 GMT Subject: RFR: 8340731: Cleanup remaining IA64 references in hotspot code [v3] In-Reply-To: References: Message-ID: > This PR cleans up `IA64` entries form hotspot codebase. > > As mentioned in the JBS, I left `zero` component as-it-is: > > ./cpu/zero/bytecodeInterpreter_zero.hpp:31:#if defined(PPC) || defined(IA64) > ./os_cpu/linux_zero/os_linux_zero.cpp:350:#ifdef IA64 > ./os_cpu/linux_zero/os_linux_zero.cpp:351: // IA64 has two stacks sharing the same area of memory, a normal > ./os_cpu/linux_zero/os_linux_zero.cpp:360:#endif // IA64 > > > Fastdebug VM Build on Mac-M1 & Linux/s390x is fine. Tests are in progress. Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: suggestion from David ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22382/files - new: https://git.openjdk.org/jdk/pull/22382/files/182fa294..39d2fd98 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22382&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22382&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22382.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22382/head:pull/22382 PR: https://git.openjdk.org/jdk/pull/22382 From amitkumar at openjdk.org Tue Nov 26 07:37:44 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 26 Nov 2024 07:37:44 GMT Subject: RFR: 8340731: Cleanup remaining IA64 references in hotspot code [v3] In-Reply-To: References: Message-ID: <9Wjp3_-L1obl7LcNfqXnhXCR3wF15c0Pwi2gD8VPX24=.3895822c-b9cb-4548-85d4-c0eb82a3b7ed@github.com> On Tue, 26 Nov 2024 07:13:57 GMT, David Holmes wrote: >> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> suggestion from David > > src/hotspot/share/runtime/frame.hpp line 167: > >> 165: >> 166: // Every frame needs to return a unique id which distinguishes it from all other frames. >> 167: // For sparc and ia32 use sp. ia64 can have memory frames that are empty so multiple frames > > For now the IA32 part should remain. I have restored IA32 comment in the latest commit. > src/hotspot/share/runtime/javaCalls.cpp line 121: > >> 119: // Do this after the transition because this allows us to put an assert >> 120: // the Java->vm transition which checks to see that stack is not walkable >> 121: // which will catch violations of the resetting of last_Java_frame > > Not clear the comment is still valid given we no longer have sparc or ia64 support. should I remove this whole comment then ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22382#discussion_r1857955534 PR Review Comment: https://git.openjdk.org/jdk/pull/22382#discussion_r1857951132 From epeter at openjdk.org Tue Nov 26 07:44:45 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 26 Nov 2024 07:44:45 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations [v3] In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 20:04:09 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 6. Auto-vectorization of newly supported scalar operations. >> 7. X86 and AARCH64 backend implementation for all supported intrinsics. >> 9. Functional and Performance validation tests. >> >> 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: > > Review comments resolution Another example where I asked if we have good tests: ![image](https://github.com/user-attachments/assets/8fafd51e-9fed-453f-aedb-7dc6d6d17cc1) And the test you point to is this: ![image](https://github.com/user-attachments/assets/0bfda1d7-7bc0-4e5b-8ea7-171a02a805ff) It only covers a single constant `divisor = 8`. But what about divisors that are out of the allowed range, or not powers of 2? How do we know that you chose the bounds correctly, and are not off-by-1? And what about negative divisors? ![image](https://github.com/user-attachments/assets/8f2260e5-0075-4d34-9d30-2cec817c72f2) ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2499889305 From jbhateja at openjdk.org Tue Nov 26 08:28:44 2024 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 26 Nov 2024 08:28:44 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations [v3] In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 20:04:09 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 6. Auto-vectorization of newly supported scalar operations. >> 7. X86 and AARCH64 backend implementation for all supported intrinsics. >> 9. Functional and Performance validation tests. >> >> 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: > > Review comments resolution > Another example where I asked if we have good tests: ![image](https://private-user-images.githubusercontent.com/32593061/389841818-8fafd51e-9fed-453f-aedb-7dc6d6d17cc1.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzI2MDg3MDMsIm5iZiI6MTczMjYwODQwMywicGF0aCI6Ii8zMjU5MzA2MS8zODk4NDE4MTgtOGZhZmQ1MWUtOWZlZC00NTNmLWFlZGItN2RjNmQ2ZDE3Y2MxLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDExMjYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQxMTI2VDA4MDY0M1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTMwZTBhOTVjOGRmNzViY2ZjYWU0M2E3ZmE1ZWEzYmYzY2E1YmQxN2JiZDkwOGJiYjZhNTcxZTFmZDc3MGU2ZjEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.-qd93PHlVMGcEbMblqKRIgdGc6tj-M7sq4oglGpgtSA) > > And the test you point to is this: ![image](https://private-user-images.githubusercontent.com/32593061/389841921-0bfda1d7-7bc0-4e5b-8ea7-171a02a805ff.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzI2MDg3MDMsIm5iZiI6MTczMjYwODQwMywicGF0aCI6Ii8zMjU5MzA2MS8zODk4NDE5MjEtMGJmZGExZDctN2JjMC00ZTViLThlYTctMTcxYTAyYTgwNWZmLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDExMjYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQxMTI2VDA4MDY0M1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWJiMWIzYWUzYjY0NDE0NWUzMzYwMTAxMDk3MzM2YmU1MzdhNjlhZjk0ODdjN2U4OTZjMmI5YWVlMTZmMDkwZjEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.bpkhyUSEqf80pl8reM1Wa7OCvPX6Z3muzqlWOVMCnjs) > > It only covers a single constant `divisor = 8`. But what about divisors that are out of the allowed range, or not powers of 2? How do we know that you chose the bounds correctly, and are not off-by-1? And what about negative divisors? ![image](https://private-user-images.githubusercontent.com/32593061/389842530-8f2260e5-0075-4d34-9d30-2cec817c72f2.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzI2MDg3MDMsIm5iZiI6MTczMjYwODQwMywicGF0aCI6Ii8zMjU5MzA2MS8zODk4NDI1MzAtOGYyMjYwZTUtMDA3NS00ZDM0LTlkMzAtMmNlYzgxN2M3MmYyLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDExMjYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQxMTI2VDA4MDY0M1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTQ1YjNiNmY0NzQ2ZjEzMjk5ZTM1N2ZkZjk4MGRlYjYzNGRiYjg1NTQxZGViMTNhMTI1MDEyN2YxMjViYWNiNjImWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.7ThWV8y58sDmCuTzt g62HlvKu93Is1R6OiomwmSM8u8) Please refer to my detailed comments on divide by power of two transformation, test point specifically test division to multiplication transformation if divisor is POT. https://github.com/openjdk/jdk/pull/21490/files#diff-ff6734d21eacbbdeae65d3b11f5261cbb6158752a9ccf5fb13eb0d2e5eb3f414R829 https://github.com/openjdk/jdk/pull/21490/files#diff-ff6734d21eacbbdeae65d3b11f5261cbb6158752a9ccf5fb13eb0d2e5eb3f414R839 Hi @eme64 I can feel the reviewer's pain, I think adding one gtest makes sense here to test various newly added Type primitives like geth, is_nan etc and idioms being folded in newly added value transformation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2499970345 From epeter at openjdk.org Tue Nov 26 08:31:47 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 26 Nov 2024 08:31:47 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations [v3] In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 08:25:46 GMT, Jatin Bhateja wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments resolution > >> Another example where I asked if we have good tests: ![image](https://private-user-images.githubusercontent.com/32593061/389841818-8fafd51e-9fed-453f-aedb-7dc6d6d17cc1.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzI2MDg3MDMsIm5iZiI6MTczMjYwODQwMywicGF0aCI6Ii8zMjU5MzA2MS8zODk4NDE4MTgtOGZhZmQ1MWUtOWZlZC00NTNmLWFlZGItN2RjNmQ2ZDE3Y2MxLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDExMjYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQxMTI2VDA4MDY0M1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTMwZTBhOTVjOGRmNzViY2ZjYWU0M2E3ZmE1ZWEzYmYzY2E1YmQxN2JiZDkwOGJiYjZhNTcxZTFmZDc3MGU2ZjEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.-qd93PHlVMGcEbMblqKRIgdGc6tj-M7sq4oglGpgtSA) >> >> And the test you point to is this: ![image](https://private-user-images.githubusercontent.com/32593061/389841921-0bfda1d7-7bc0-4e5b-8ea7-171a02a805ff.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzI2MDg3MDMsIm5iZiI6MTczMjYwODQwMywicGF0aCI6Ii8zMjU5MzA2MS8zODk4NDE5MjEtMGJmZGExZDctN2JjMC00ZTViLThlYTctMTcxYTAyYTgwNWZmLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDExMjYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQxMTI2VDA4MDY0M1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWJiMWIzYWUzYjY0NDE0NWUzMzYwMTAxMDk3MzM2YmU1MzdhNjlhZjk0ODdjN2U4OTZjMmI5YWVlMTZmMDkwZjEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.bpkhyUSEqf80pl8reM1Wa7OCvPX6Z3muzqlWOVMCnjs) >> >> It only covers a single constant `divisor = 8`. But what about divisors that are out of the allowed range, or not powers of 2? How do we know that you chose the bounds correctly, and are not off-by-1? And what about negative divisors? ![image](https://private-user-images.githubusercontent.com/32593061/389842530-8f2260e5-0075-4d34-9d30-2cec817c72f2.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzI2MDg3MDMsIm5iZiI6MTczMjYwODQwMywicGF0aCI6Ii8zMjU5MzA2MS8zODk4NDI1MzAtOGYyMjYwZTUtMDA3NS00ZDM0LTlkMzAtMmNlYzgxN2M3MmYyLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDExMjYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQxMTI2VDA4MDY0M1omWC1BbXotRXh... @jatin-bhateja > I can feel the reviewer's pain Then please do something about it! Your comments are helpful. But they do not answer my request for better test coverage. Yes, `gtest` would be helpful. But also Java end-to-end tests are required. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2499977879 From rehn at openjdk.org Tue Nov 26 08:54:48 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 26 Nov 2024 08:54:48 GMT Subject: Integrated: 8344382: RISC-V: CASandCAEwithNegExpected fails with Zacas In-Reply-To: References: Message-ID: On Thu, 21 Nov 2024 13:56:32 GMT, Robbin Ehn wrote: > Hi, please consider. > > There are two issues with narrow amocas: > - weak_cmpxchg_narrow_value don't load from aligned address. > - cmpxchg_narrow_value compared new to loaded value, not to expected value. > > This addresses these two issues and makes some minor cleanups by: > - Weak and strong are now identical for easier debugging (and in futre code sharing). > - t1 was set by cmpxchg_narrow_value_helper but not passed. > - To free up a register, not_mask is now a scratch register. Hence if amocas fails we need to re-create not mask. > - Subjective change: a register containing temporary value is best named scratch, as the register it self is not temporary. > > Same as other PR, here be dragons. > But with a working baseline we can start improving this code. > > Passes test/hotspot/jtreg/compiler/unsafe/ with +/-UseZacas. > And I'm running tier1 +/-UseZacas (I'll run tests over the weekend). > > Thanks, Robbin This pull request has now been integrated. Changeset: 57d35f98 Author: Robbin Ehn URL: https://git.openjdk.org/jdk/commit/57d35f98f6966485c034cf096ddefcf0c7569627 Stats: 81 lines in 2 files changed: 29 ins; 13 del; 39 mod 8344382: RISC-V: CASandCAEwithNegExpected fails with Zacas Reviewed-by: fyang, mli ------------- PR: https://git.openjdk.org/jdk/pull/22293 From rehn at openjdk.org Tue Nov 26 09:09:39 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 26 Nov 2024 09:09:39 GMT Subject: RFR: 8344306: RISC-V: Add zicond Message-ID: Hi, please consider. In cpu models we save ~1 cycle per removed branch. This patch removes ~0.1% of branches in generic C2 generated code. We should probably investigate if we can improve/add peephole optimization to remove more branches. As the C1 cmov code is a bit tricky I left that as a followup. I added gtests for the cmovs. (we should add coverage for more of masm in this gtest suit) Pro tip, invoke the gtestLauncher directly (you only need to build exploded): `gtestLauncher -jdk build/linux-riscv64-server-fastdebug/jdk/ --gtest_break_on_failure --gtest_filter="*RiscV*" -XX:+UnlockDiagnosticVMOptions -XX:+UseZicond -XX:ParallelGCThreads=1 -XX:ConcGCThreads=1 -XX:CICompilerCount=2` Tested on Spacemit X60, gtests and tier1. Thanks, Robbin ------------- Commit messages: - Fixed ws - Draft Changes: https://git.openjdk.org/jdk/pull/22386/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22386&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344306 Stats: 344 lines in 9 files changed: 340 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22386.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22386/head:pull/22386 PR: https://git.openjdk.org/jdk/pull/22386 From shade at openjdk.org Tue Nov 26 09:44:02 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 26 Nov 2024 09:44:02 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v11] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 26 Nov 2024 00:37:32 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - 8344985: GenShen: Refactor arraycopy barrier for generational mode > > Reviewed-by: shade I checked all review threads, and I think my review feedback was appropriately addressed. I see no (new) test failures in my local testing as well. Thank you all, this is a huge piece of engineering work, and it looks good for experimental feature. We would probably make a few touchups and simplifications after the integration. I hope this would stabilize in the future releases to become a new default mode for Shenandoah! ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2460929110 From adinn at openjdk.org Tue Nov 26 09:44:55 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 26 Nov 2024 09:44:55 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations [v5] In-Reply-To: References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: On Fri, 22 Nov 2024 04:07:25 GMT, Vladimir Ivanov wrote: >> Andrew Dinn 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 55 additional commits since the last revision: >> >> - Merge branch 'master' into iterate_stubs >> - fix element sizes in s390 copy routines >> - fix stub is and align flags for s390 >> - fix comments and remove unused stubid on riscv >> - locate super lookup stubs in same blob for all arches >> - do verification under ifdef ASSERT >> - fix yet more problems with s390 stubs >> - better error notification >> - fix more problems with s390 stubs >> - Verify stubs are generated in correct blob >> - ... and 45 more: https://git.openjdk.org/jdk/compare/38c74dcc...e21268c4 > > I submitted it for testing and it seems the build is mostly broken on x86 when `UseAVX=3` is set. I even tried to manually build the patch on an AVX512-capable host and it reliably fails early during startup: > > Error occurred during initialization of boot layer > java.lang.module.FindException: Error reading module: /scratch/vlivanov/jdk/build/linux-x64-fastdebug/jdk/modules/java.base > Caused by: java.lang.module.InvalidModuleDescriptorException: Bad constant pool entry: 90 @iwanowww Thanks for testing Vladimir. This is crashing during module loading so it may be an error in the configuration of generation for the AVX variants of the arraycopy routines. s390 crashed at the same place for that reason because its jmod files had been built incorrectly. I'll see if I can find a problem by eyeballing the x86 source changes related to AVX and let you know if there is something obvious. If not then I will probably need to obtain an AVX capable machine and debug the 'jdk' binary. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2500131919 From adinn at openjdk.org Tue Nov 26 09:48:51 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 26 Nov 2024 09:48:51 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations [v5] In-Reply-To: References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: On Thu, 21 Nov 2024 17:50:57 GMT, Andrew Dinn wrote: >> Implementation of JDK-8343767 > > Andrew Dinn 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 55 additional commits since the last revision: > > - Merge branch 'master' into iterate_stubs > - fix element sizes in s390 copy routines > - fix stub is and align flags for s390 > - fix comments and remove unused stubid on riscv > - locate super lookup stubs in same blob for all arches > - do verification under ifdef ASSERT > - fix yet more problems with s390 stubs > - better error notification > - fix more problems with s390 stubs > - Verify stubs are generated in correct blob > - ... and 45 more: https://git.openjdk.org/jdk/compare/4ea1625c...e21268c4 src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 512: > 510: break; > 511: case jlong_disjoint_arraycopy_id: > 512: shift = 0; Ok, this is one error -- shift should be 3 src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 850: > 848: break; > 849: case jlong_arraycopy_id: > 850: shift = 0; and this is another -- again should be 3 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1858150921 PR Review Comment: https://git.openjdk.org/jdk/pull/21957#discussion_r1858151684 From tanksherman27 at gmail.com Tue Nov 26 09:55:24 2024 From: tanksherman27 at gmail.com (Julian Waters) Date: Tue, 26 Nov 2024 17:55:24 +0800 Subject: Poisoning in HotSpot Message-ID: Hi all, It turned out in the review of https://github.com/openjdk/jdk/pull/22069 that the poisoning mechanism used in HotSpot can break when combined with LTO. Also, poisoning does not work on Windows, at least not with the default Microsoft compiler (Though, the Windows/gcc Port also disables FORBID_C_FUNCTION as well). I've tried coming up with an alternative mechanism to poison methods that works on any platform, but I'm unsure what to do with it now. It can be viewed here: https://godbolt.org/z/PKMjjWTxz Any improvements that could be made to it? Should I continue this so we can have a poisoning mechanism that works even while LTO is active? best regards, Julian -------------- next part -------------- An HTML attachment was scrubbed... URL: From adinn at openjdk.org Tue Nov 26 09:58:08 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 26 Nov 2024 09:58:08 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations [v6] In-Reply-To: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: <8iGnF6YCOXLvgRrIQp86kGsAUNFRiwj_oSqWR5N7jZo=.cf279212-baf3-4110-aa3b-d3c40c711245@github.com> > Implementation of JDK-8343767 Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: fix issue with x86 avx3 array copy ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21957/files - new: https://git.openjdk.org/jdk/pull/21957/files/e21268c4..e1f41d34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21957/head:pull/21957 PR: https://git.openjdk.org/jdk/pull/21957 From adinn at openjdk.org Tue Nov 26 09:58:14 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Tue, 26 Nov 2024 09:58:14 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations [v5] In-Reply-To: References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: On Fri, 22 Nov 2024 04:07:25 GMT, Vladimir Ivanov wrote: >> Andrew Dinn 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 55 additional commits since the last revision: >> >> - Merge branch 'master' into iterate_stubs >> - fix element sizes in s390 copy routines >> - fix stub is and align flags for s390 >> - fix comments and remove unused stubid on riscv >> - locate super lookup stubs in same blob for all arches >> - do verification under ifdef ASSERT >> - fix yet more problems with s390 stubs >> - better error notification >> - fix more problems with s390 stubs >> - Verify stubs are generated in correct blob >> - ... and 45 more: https://git.openjdk.org/jdk/compare/28719dc5...e21268c4 > > I submitted it for testing and it seems the build is mostly broken on x86 when `UseAVX=3` is set. I even tried to manually build the patch on an AVX512-capable host and it reliably fails early during startup: > > Error occurred during initialization of boot layer > java.lang.module.FindException: Error reading module: /scratch/vlivanov/jdk/build/linux-x64-fastdebug/jdk/modules/java.base > Caused by: java.lang.module.InvalidModuleDescriptorException: Bad constant pool entry: 90 @iwanowww I found and patched a very obvious scaling error with the avx3 array copy routines. I could not see anything else obvious. Could you rerun tests and see if this at least gets us through the build process on x86? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2500154351 From fyang at openjdk.org Tue Nov 26 10:28:08 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 26 Nov 2024 10:28:08 GMT Subject: RFR: 8345047: RISC-V: Remove explicit use of AvoidUnalignedAccesses in interpreter Message-ID: Hi, please consider this small interpreter cleanup change. The use of AvoidUnalignedAccesses option for these cases doen't much sense to me. MacroAssembler routines like `revb_h_h_u` and `revb_h_h` will emit 5 instructions when Zbb extension is not available. This is more than the case when AvoidUnalignedAccesses option is true. After this change, we always emit 4 instructions compared to 3 instructions in the case when we have Zbb extension. But I don't think it will make a difference. Testing on linux-riscv64 platform: - [x] tier1 (release) ------------- Commit messages: - 8345047: RISC-V: Remove explicit use of AvoidUnalignedAccesses in interpreter Changes: https://git.openjdk.org/jdk/pull/22387/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22387&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345047 Stats: 36 lines in 2 files changed: 0 ins; 23 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/22387.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22387/head:pull/22387 PR: https://git.openjdk.org/jdk/pull/22387 From mli at openjdk.org Tue Nov 26 10:29:39 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 26 Nov 2024 10:29:39 GMT Subject: RFR: 8344306: RISC-V: Add zicond In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 09:00:34 GMT, Robbin Ehn wrote: > Hi, please consider. > > In cpu models we save ~1 cycle per removed branch. > This patch removes ~0.1% of branches in generic C2 generated code. > We should probably investigate if we can improve/add peephole optimization to remove more branches. > > As the C1 cmov code is a bit tricky I left that as a followup. > > I added gtests for the cmovs. > (we should add coverage for more of masm in this gtest suit) > Pro tip, invoke the gtestLauncher directly (you only need to build exploded): > `gtestLauncher -jdk build/linux-riscv64-server-fastdebug/jdk/ --gtest_break_on_failure --gtest_filter="*RiscV*" -XX:+UnlockDiagnosticVMOptions -XX:+UseZicond -XX:ParallelGCThreads=1 -XX:ConcGCThreads=1 -XX:CICompilerCount=2` > > Tested on Spacemit X60, gtests and tier1. > > Thanks, Robbin Thanks for adding the support for this extension! The code change looks good. Just have some questions below. src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2047: > 2045: assert(false, "unsupported compare condition"); > 2046: ShouldNotReachHere(); > 2047: } Seems we can use the similar way in `C2_MacroAssembler::cmp_branch` +`conditional_branches` to simplify the code. src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1143: > 1141: bne(cmp1, cmp2, no_set); > 1142: mv(dst, src); > 1143: bind(no_set); Do we have performance data comparison between `-UseZicond ` and `+ UseZicond `? ------------- PR Review: https://git.openjdk.org/jdk/pull/22386#pullrequestreview-2461030531 PR Review Comment: https://git.openjdk.org/jdk/pull/22386#discussion_r1858210922 PR Review Comment: https://git.openjdk.org/jdk/pull/22386#discussion_r1858207974 From mli at openjdk.org Tue Nov 26 10:29:40 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 26 Nov 2024 10:29:40 GMT Subject: RFR: 8344306: RISC-V: Add zicond In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 10:21:38 GMT, Hamlin Li wrote: >> Hi, please consider. >> >> In cpu models we save ~1 cycle per removed branch. >> This patch removes ~0.1% of branches in generic C2 generated code. >> We should probably investigate if we can improve/add peephole optimization to remove more branches. >> >> As the C1 cmov code is a bit tricky I left that as a followup. >> >> I added gtests for the cmovs. >> (we should add coverage for more of masm in this gtest suit) >> Pro tip, invoke the gtestLauncher directly (you only need to build exploded): >> `gtestLauncher -jdk build/linux-riscv64-server-fastdebug/jdk/ --gtest_break_on_failure --gtest_filter="*RiscV*" -XX:+UnlockDiagnosticVMOptions -XX:+UseZicond -XX:ParallelGCThreads=1 -XX:ConcGCThreads=1 -XX:CICompilerCount=2` >> >> Tested on Spacemit X60, gtests and tier1. >> >> Thanks, Robbin > > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1143: > >> 1141: bne(cmp1, cmp2, no_set); >> 1142: mv(dst, src); >> 1143: bind(no_set); > > Do we have performance data comparison between `-UseZicond ` and `+ UseZicond `? Seems the critical path when `+UseZicond` is longer than `-UseZicond`, I'm not sure how much impact the branch code will bring when `-UseZicond`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22386#discussion_r1858216997 From aph at openjdk.org Tue Nov 26 10:38:38 2024 From: aph at openjdk.org (Andrew Haley) Date: Tue, 26 Nov 2024 10:38:38 GMT Subject: RFR: 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only In-Reply-To: References: <3aaeGz7V4yLsAIeSA4ZuTr5isbsusslvk7Qftf7jiI4=.54e563e5-1319-49e0-905e-ed5159157c5e@github.com> Message-ID: On Mon, 25 Nov 2024 23:28:49 GMT, Vladimir Ivanov wrote: >> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4915: >> >>> 4913: bind(done); >>> 4914: } >>> 4915: #ifdef ASSERT >> >> I understand that it greatly increases the reproducibility of the bug, but does such an adhoc code snippet adds much from maintenance perspective? Reusing registers is common in assembly code, so if all places where a register value is destroyed are annotated in a similar way, it would add a lot of noise on source code level. > > I'm looking at `MacroAssembler::lookup_secondary_supers_table_var()` and the only thing which can be improved there is an extra comment around line 5116 stressing that `population_count` destroys `slot`. > I understand that it greatly increases the reproducibility of the bug, but does such an adhoc code snippet adds much from maintenance perspective? Reusing registers is common in assembly code, so if all places where a register value is destroyed are annotated in a similar way, it would add a lot of noise on source code level. The point isn't so much that it's destroyed, but that it's destroyed on a rarely-used code path, in this case on a code path that is only ever executed on an obsolete machine. We've had the same problem on AArch64, where there are the old and new versions of compare-and-swap, and fixed the testing in the same way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22365#discussion_r1858229650 From rehn at openjdk.org Tue Nov 26 10:43:38 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 26 Nov 2024 10:43:38 GMT Subject: RFR: 8344306: RISC-V: Add zicond In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 10:23:26 GMT, Hamlin Li wrote: >> Hi, please consider. >> >> In cpu models we save ~1 cycle per removed branch. >> This patch removes ~0.1% of branches in generic C2 generated code. >> We should probably investigate if we can improve/add peephole optimization to remove more branches. >> >> As the C1 cmov code is a bit tricky I left that as a followup. >> >> I added gtests for the cmovs. >> (we should add coverage for more of masm in this gtest suit) >> Pro tip, invoke the gtestLauncher directly (you only need to build exploded): >> `gtestLauncher -jdk build/linux-riscv64-server-fastdebug/jdk/ --gtest_break_on_failure --gtest_filter="*RiscV*" -XX:+UnlockDiagnosticVMOptions -XX:+UseZicond -XX:ParallelGCThreads=1 -XX:ConcGCThreads=1 -XX:CICompilerCount=2` >> >> Tested on Spacemit X60, gtests and tier1. >> >> Thanks, Robbin > > src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2047: > >> 2045: assert(false, "unsupported compare condition"); >> 2046: ShouldNotReachHere(); >> 2047: } > > Seems we can use the similar way in `C2_MacroAssembler::cmp_branch` +`conditional_branches` to simplify the code. The "BoolTest" is a C2 construct, C1 uses LIR_Condition, there is no generic test enum. So you would need one table to translate from C2 -> masm and one from C1 -> masm, and then one table to pick the correct version. You can turn any switch statement into a table with function pointers, but: `cmp_branch(cmpFlag ^ (1 << neg_cond_bits), op1, op2, L);` Trying to figure out which compare is selected is shoter, yes, but much more complex IMHO. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22386#discussion_r1858238759 From rehn at openjdk.org Tue Nov 26 10:48:37 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 26 Nov 2024 10:48:37 GMT Subject: RFR: 8344306: RISC-V: Add zicond In-Reply-To: References: Message-ID: <0wHgn-IQt2oxsHzFViNCVzrzKQxy2whwKyfpKqEhDdU=.14c47db5-ddb2-47ad-8d52-be3e2c0a6474@github.com> On Tue, 26 Nov 2024 10:27:15 GMT, Hamlin Li wrote: >> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1143: >> >>> 1141: bne(cmp1, cmp2, no_set); >>> 1142: mv(dst, src); >>> 1143: bind(no_set); >> >> Do we have performance data comparison between `-UseZicond ` and `+ UseZicond `? > > Seems the critical path when `+UseZicond` is longer than `-UseZicond`, I'm not sure how much impact the branch code will bring when `-UseZicond`. Not, as we are only removing one in a thousand branches, the different would be so little that I don't think I can measure it in a reasoanble amount of iterations. I think you need something very synthetic, e.g. write a hot loop where we can remove a branch in it to measure it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22386#discussion_r1858247068 From mgronlun at openjdk.org Tue Nov 26 10:52:44 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 26 Nov 2024 10:52:44 GMT Subject: Integrated: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows In-Reply-To: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: <2vTBphHbeIkGYxWEcNewgCykPx7XPH1MlQLr0pa6T7c=.c7e2da15-00ab-4599-bcba-d838b1d04ff1@github.com> On Fri, 8 Nov 2024 21:36:38 GMT, Markus Gr?nlund wrote: > Greetings, > > This enhancement adds register printouts on asserts or guarantees into the hs_err_pid.log error reporting files for Windows. > > Additionally, it saves an accurate EXCEPTION_RECORD into the hs_err_pid.mdmp file, also for asserts or guarantees, so the assertion context is now easily accessible in Windbg using .ecxr. > > For more details on this enhancement, please see the JIRA issue. > > Testing: Tier 1,2,3, jdk_jfr > > Thanks > Markus This pull request has now been integrated. Changeset: 0054bbed Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/0054bbed7fce5b8566655d6910b09b10c952e609 Stats: 249 lines in 11 files changed: 155 ins; 33 del; 61 mod 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows Reviewed-by: stuefe, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/21994 From mgronlun at openjdk.org Tue Nov 26 10:52:43 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 26 Nov 2024 10:52:43 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v4] In-Reply-To: References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: <_Mmr_Rvj1V4UK3DXi8snzdhLNawXxs15XnV4Q7XkYys=.28af4991-1c72-4e46-8683-b0cbb324e42b@github.com> On Tue, 26 Nov 2024 07:00:24 GMT, Thomas Stuefe wrote: > LGTM. Thanks for your review, @tstuefe . Much appreciated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21994#issuecomment-2500285420 From aph at openjdk.org Tue Nov 26 11:00:18 2024 From: aph at openjdk.org (Andrew Haley) Date: Tue, 26 Nov 2024 11:00:18 GMT Subject: RFR: 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only [v2] In-Reply-To: References: Message-ID: <255_hfpSxSvEECjsUa48_iufPhHxi-8o3lyWa3_GhcU=.481704f1-8a08-4892-a7fa-544e245910d8@github.com> > This bug only affects x86-64 machines without a `popcnt` instruction, which basically means pre-SSE4.2 machines. This means that x86-64 processors made around 2010 are affected. > > My thanks to everyone who was was involved in bisecting this, particularly Martin Bucholz who seems to be the only one testing on such old hardware. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22365/files - new: https://git.openjdk.org/jdk/pull/22365/files/dd2d4b5a..9a2b581e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22365&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22365&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22365.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22365/head:pull/22365 PR: https://git.openjdk.org/jdk/pull/22365 From mli at openjdk.org Tue Nov 26 11:01:39 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 26 Nov 2024 11:01:39 GMT Subject: RFR: 8345047: RISC-V: Remove explicit use of AvoidUnalignedAccesses in interpreter In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 10:19:40 GMT, Fei Yang wrote: > Hi, please consider this small interpreter cleanup change. > > The use of `AvoidUnalignedAccesses` option for these cases doen't much sense to me. > MacroAssembler routines like `revb_h_h_u` and `revb_h_h` will emit 5 instructions when Zbb extension is not available. This is more than the case when `AvoidUnalignedAccesses` option is true. After this change, we always emit 4 instructions compared to 3 instructions in the case when we have Zbb extension. But I don't think it will make a difference. > > Testing on linux-riscv64 platform: > - [x] tier1 (release) Thanks for improving the code. Just some minor comments. src/hotspot/cpu/riscv/interp_masm_riscv.cpp line 182: > 180: void InterpreterMacroAssembler::get_unsigned_2_byte_index_at_bcp(Register reg, int bcp_offset) { > 181: assert(bcp_offset >= 0, "bcp is still pointing to start of bytecode"); > 182: lbu(t1, Address(xbcp, bcp_offset)); maybe we could expand the revb_h_h here? something like below: if ((AvoidUnalignedAccesses && (bcp_offset % 2)) || !UseZbb) { ... } else { // expand revb_h_h_u when +UseZbb } src/hotspot/cpu/riscv/interp_masm_riscv.cpp line 198: > 196: assert(bcp_offset > 0, "bcp is still pointing to start of bytecode"); > 197: if (index_size == sizeof(u2)) { > 198: load_short_misaligned(index, Address(xbcp, bcp_offset), tmp, false); This change looks good. ------------- PR Review: https://git.openjdk.org/jdk/pull/22387#pullrequestreview-2461117612 PR Review Comment: https://git.openjdk.org/jdk/pull/22387#discussion_r1858263265 PR Review Comment: https://git.openjdk.org/jdk/pull/22387#discussion_r1858264253 From mli at openjdk.org Tue Nov 26 11:01:40 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 26 Nov 2024 11:01:40 GMT Subject: RFR: 8345047: RISC-V: Remove explicit use of AvoidUnalignedAccesses in interpreter In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 10:57:06 GMT, Hamlin Li wrote: >> Hi, please consider this small interpreter cleanup change. >> >> The use of `AvoidUnalignedAccesses` option for these cases doen't much sense to me. >> MacroAssembler routines like `revb_h_h_u` and `revb_h_h` will emit 5 instructions when Zbb extension is not available. This is more than the case when `AvoidUnalignedAccesses` option is true. After this change, we always emit 4 instructions compared to 3 instructions in the case when we have Zbb extension. But I don't think it will make a difference. >> >> Testing on linux-riscv64 platform: >> - [x] tier1 (release) > > src/hotspot/cpu/riscv/interp_masm_riscv.cpp line 182: > >> 180: void InterpreterMacroAssembler::get_unsigned_2_byte_index_at_bcp(Register reg, int bcp_offset) { >> 181: assert(bcp_offset >= 0, "bcp is still pointing to start of bytecode"); >> 182: lbu(t1, Address(xbcp, bcp_offset)); > > maybe we could expand the revb_h_h here? something like below: > > if ((AvoidUnalignedAccesses && (bcp_offset % 2)) || !UseZbb) { > ... > } else { > // expand revb_h_h_u when +UseZbb > } similar comments for below changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22387#discussion_r1858263880 From aph at openjdk.org Tue Nov 26 11:06:39 2024 From: aph at openjdk.org (Andrew Haley) Date: Tue, 26 Nov 2024 11:06:39 GMT Subject: RFR: 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only [v2] In-Reply-To: <255_hfpSxSvEECjsUa48_iufPhHxi-8o3lyWa3_GhcU=.481704f1-8a08-4892-a7fa-544e245910d8@github.com> References: <255_hfpSxSvEECjsUa48_iufPhHxi-8o3lyWa3_GhcU=.481704f1-8a08-4892-a7fa-544e245910d8@github.com> Message-ID: On Tue, 26 Nov 2024 11:00:18 GMT, Andrew Haley wrote: >> This bug only affects x86-64 machines without a `popcnt` instruction, which basically means pre-SSE4.2 machines. This means that x86-64 processors made around 2010 are affected. >> >> My thanks to everyone who was was involved in bisecting this, particularly Martin Bucholz who seems to be the only one testing on such old hardware. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only > It's unfortunate the bug wasn't caught during review. Well, yes, but nothing is perfect and this bug was pretty obscure. I even annotated the call to `population_count()` to show that `slot` was passed as a temp, but missed the significance of that. Testing can never show the absence of bugs, but I'd advocate for clobbering registers only used on rare code paths to be a standard practice. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22365#issuecomment-2500315408 From mli at openjdk.org Tue Nov 26 11:08:41 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 26 Nov 2024 11:08:41 GMT Subject: RFR: 8344306: RISC-V: Add zicond In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 10:41:14 GMT, Robbin Ehn wrote: >> src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2047: >> >>> 2045: assert(false, "unsupported compare condition"); >>> 2046: ShouldNotReachHere(); >>> 2047: } >> >> Seems we can use the similar way in `C2_MacroAssembler::cmp_branch` +`conditional_branches` to simplify the code. > > The "BoolTest" is a C2 construct, C1 uses LIR_Condition, there is no generic test enum. > So you would need one table to translate from C2 -> masm and one from C1 -> masm, and then one table to pick the correct version. > > You can turn any switch statement into a table with function pointers, but: > `cmp_branch(cmpFlag ^ (1 << neg_cond_bits), op1, op2, L);` > Trying to figure out which compare is selected is shoter, yes, but much more complex IMHO. I see, thanks for clarification. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22386#discussion_r1858275911 From fyang at openjdk.org Tue Nov 26 11:11:41 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 26 Nov 2024 11:11:41 GMT Subject: RFR: 8345047: RISC-V: Remove explicit use of AvoidUnalignedAccesses in interpreter In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 10:57:30 GMT, Hamlin Li wrote: >> src/hotspot/cpu/riscv/interp_masm_riscv.cpp line 182: >> >>> 180: void InterpreterMacroAssembler::get_unsigned_2_byte_index_at_bcp(Register reg, int bcp_offset) { >>> 181: assert(bcp_offset >= 0, "bcp is still pointing to start of bytecode"); >>> 182: lbu(t1, Address(xbcp, bcp_offset)); >> >> maybe we could expand the revb_h_h here? something like below: >> >> if ((AvoidUnalignedAccesses && (bcp_offset % 2)) || !UseZbb) { >> ... >> } else { >> // expand revb_h_h_u when +UseZbb >> } > > similar comments for below changes. Ah, that looks more complex than before from a maintainance perspective. We only get one instruction saved which is not on the performance critical path. I guess it doesn't worth it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22387#discussion_r1858277897 From mli at openjdk.org Tue Nov 26 11:14:37 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 26 Nov 2024 11:14:37 GMT Subject: RFR: 8345047: RISC-V: Remove explicit use of AvoidUnalignedAccesses in interpreter In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 11:07:44 GMT, Fei Yang wrote: >> similar comments for below changes. > > Ah, that looks more complex than before from a maintainance perspective. We only get one instruction saved which is not on the performance critical path. I guess it doesn't worth it? Yes, I have the similar concerns. :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22387#discussion_r1858284211 From rkennke at openjdk.org Tue Nov 26 11:16:07 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 26 Nov 2024 11:16:07 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v11] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 26 Nov 2024 00:37:32 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - 8344985: GenShen: Refactor arraycopy barrier for generational mode > > Reviewed-by: shade I also looked again at any new changes since I reviewed last time. Still looks good. Ship it! This is great work! Roman ------------- Marked as reviewed by rkennke (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2461152113 From mli at openjdk.org Tue Nov 26 11:17:40 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 26 Nov 2024 11:17:40 GMT Subject: RFR: 8345047: RISC-V: Remove explicit use of AvoidUnalignedAccesses in interpreter In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 10:19:40 GMT, Fei Yang wrote: > Hi, please consider this small interpreter cleanup change. > > The use of `AvoidUnalignedAccesses` option for these cases doen't much sense to me. > MacroAssembler routines like `revb_h_h_u` and `revb_h_h` will emit 5 instructions when Zbb extension is not available. This is more than the case when `AvoidUnalignedAccesses` option is true. After this change, we always emit 4 instructions compared to 3 instructions in the case when we have Zbb extension. But I don't think it will make a difference. > > Testing on linux-riscv64 platform: > - [x] tier1 (release) Looks good. Thanks! Since the changes are in the interpreter, I can accept minor regressions introduced in exchange for code readability. ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22387#pullrequestreview-2461157508 From fyang at openjdk.org Tue Nov 26 11:22:37 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 26 Nov 2024 11:22:37 GMT Subject: RFR: 8345047: RISC-V: Remove explicit use of AvoidUnalignedAccesses in interpreter In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 11:11:53 GMT, Hamlin Li wrote: >> Ah, that looks more complex than before from a maintainance perspective. We only get one instruction saved which is not on the performance critical path. I guess it doesn't worth it? > > Yes, I have the similar concerns. :) Yeah! Also I don't think it's a good idea to spread uses of extension options like `UseZbb` everywhere. It will be more reasonable to me if we encapsulate it in some assember routines which are more generic to the callers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22387#discussion_r1858293070 From jbechberger at openjdk.org Tue Nov 26 11:39:56 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Tue, 26 Nov 2024 11:39:56 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v30] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Fix disenroll issue ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/af59d3fb..092d447b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=28-29 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From aph at openjdk.org Tue Nov 26 11:59:40 2024 From: aph at openjdk.org (Andrew Haley) Date: Tue, 26 Nov 2024 11:59:40 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> References: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> Message-ID: On Mon, 25 Nov 2024 12:59:10 GMT, Amit Kumar wrote: >> s390x Port for : [JDK-8331341](https://bugs.openjdk.org/browse/JDK-8331341) >> >> Tier1 test: >> 1. `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` >> 2. No flag turn on. i.e. used `UseSecondarySupersCache` by default. >> 3. `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` with C1 compiler > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > suggestion from Andrew src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3495: > 3493: z_lngr(slot, slot); // slot = -slot > 3494: z_aghi(slot, 64); // slot = slot + 64 > 3495: So, I'm trying to make sense of this. First, you do slot = 63 - slot slot = 64 - slot Why not instead reduce ` slot = 64 - (63 - slot)` which is ` slot = slot - 63 + 64` which is ` slot = slot + 1` jshell> void p() { ...> for (int s = 0; s < 64; s++) { ...> int n1 = s; ...> n1 = 63 - n1; ...> n1 = 64 - n1; ...> int n2 = s + 1; ...> if (n1 != n2) { ...> throw new RuntimeException(); ...> } ...> } ...> } | created method p() jshell> p() ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1858345422 From aph at openjdk.org Tue Nov 26 12:04:38 2024 From: aph at openjdk.org (Andrew Haley) Date: Tue, 26 Nov 2024 12:04:38 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: References: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> Message-ID: On Tue, 26 Nov 2024 11:57:08 GMT, Andrew Haley wrote: >> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> suggestion from Andrew > > src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3495: > >> 3493: z_lngr(slot, slot); // slot = -slot >> 3494: z_aghi(slot, 64); // slot = slot + 64 >> 3495: > > So, I'm trying to make sense of this. > > First, you do > > > slot = 63 - slot > slot = 64 - slot > > > Why not instead reduce > ` slot = 64 - (63 - slot)` > which is > ` slot = slot - 63 + 64` > which is > ` slot = slot + 1` > > > jshell> void p() { > ...> for (int s = 0; s < 64; s++) { > ...> int n1 = s; > ...> n1 = 63 - n1; > ...> n1 = 64 - n1; > ...> int n2 = s + 1; > ...> if (n1 != n2) { > ...> throw new RuntimeException(); > ...> } > ...> } > ...> } > | created method p() > > jshell> p() I am assuming that on s390 rotate right by 64 is equivalent to rotate right by 0, but I didn't check that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1858360190 From rehn at openjdk.org Tue Nov 26 13:21:38 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Tue, 26 Nov 2024 13:21:38 GMT Subject: RFR: 8344306: RISC-V: Add zicond In-Reply-To: <0wHgn-IQt2oxsHzFViNCVzrzKQxy2whwKyfpKqEhDdU=.14c47db5-ddb2-47ad-8d52-be3e2c0a6474@github.com> References: <0wHgn-IQt2oxsHzFViNCVzrzKQxy2whwKyfpKqEhDdU=.14c47db5-ddb2-47ad-8d52-be3e2c0a6474@github.com> Message-ID: On Tue, 26 Nov 2024 10:46:24 GMT, Robbin Ehn wrote: >> Seems the critical path when `+UseZicond` is longer than `-UseZicond`, I'm not sure how much impact the branch code will bring when `-UseZicond`. > > Not, as we are only removing one in a thousand branches, the different would be so little that I don't think I can measure it in a reasoanble amount of iterations. I think you need something very synthetic, e.g. write a hot loop where we can remove a branch in it to measure it. > Seems the critical path when `+UseZicond` is longer than `-UseZicond`, I'm not sure how much impact the branch code will bring when `-UseZicond`. As I said, those 4 instructions saves ~1 cycle compared branch in out-order cpu models. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22386#discussion_r1858529983 From tanksherman27 at gmail.com Tue Nov 26 13:37:23 2024 From: tanksherman27 at gmail.com (Julian Waters) Date: Tue, 26 Nov 2024 21:37:23 +0800 Subject: HotSpot doesn't use NULL Message-ID: Both VC and gcc support pragmas that force disable all uses of an identifier whatsoever, deprecated for VC and poison for gcc. This would probably depend on whether you want to forbid null everywhere or whether you need some places where NULL has to be used best regards, Julian -------------- next part -------------- An HTML attachment was scrubbed... URL: From amitkumar at openjdk.org Tue Nov 26 13:58:23 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 26 Nov 2024 13:58:23 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v3] In-Reply-To: References: Message-ID: <3GgpyxVRYR_YSodFrJ3DY3-d3EdgT8Bx8NpxvrCp2Gc=.9086bd13-4be9-4aa5-b6aa-f1e2e5982ba0@github.com> > s390x Port for : [JDK-8331341](https://bugs.openjdk.org/browse/JDK-8331341) > > Tier1 test: > 1. `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` > 2. No flag turn on. i.e. used `UseSecondarySupersCache` by default. > 3. `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` with C1 compiler Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: Suggestion from Andrew ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22341/files - new: https://git.openjdk.org/jdk/pull/22341/files/df8cf06f..9adcdfdd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22341&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22341&range=01-02 Stats: 25 lines in 1 file changed: 5 ins; 9 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/22341.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22341/head:pull/22341 PR: https://git.openjdk.org/jdk/pull/22341 From amitkumar at openjdk.org Tue Nov 26 14:00:41 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 26 Nov 2024 14:00:41 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: References: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> Message-ID: On Tue, 26 Nov 2024 12:02:27 GMT, Andrew Haley wrote: >> src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3495: >> >>> 3493: z_lngr(slot, slot); // slot = -slot >>> 3494: z_aghi(slot, 64); // slot = slot + 64 >>> 3495: >> >> So, I'm trying to make sense of this. >> >> First, you do >> >> >> slot = 63 - slot >> slot = 64 - slot >> >> >> Why not instead reduce >> ` slot = 64 - (63 - slot)` >> which is >> ` slot = slot - 63 + 64` >> which is >> ` slot = slot + 1` >> >> >> jshell> void p() { >> ...> for (int s = 0; s < 64; s++) { >> ...> int n1 = s; >> ...> n1 = 63 - n1; >> ...> n1 = 64 - n1; >> ...> int n2 = s + 1; >> ...> if (n1 != n2) { >> ...> throw new RuntimeException(); >> ...> } >> ...> } >> ...> } >> | created method p() >> >> jshell> p() > > I am assuming that on s390 rotate right by 64 is equivalent to rotate right by 0, but I didn't check that. I must say, that was a great suggestion. Thanks for pointing it out. I have pushed the change, please look at the new code :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1858592132 From mli at openjdk.org Tue Nov 26 14:47:42 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 26 Nov 2024 14:47:42 GMT Subject: RFR: 8344306: RISC-V: Add zicond In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 09:00:34 GMT, Robbin Ehn wrote: > Hi, please consider. > > In cpu models we save ~1 cycle per removed branch. > This patch removes ~0.1% of branches in generic C2 generated code. > We should probably investigate if we can improve/add peephole optimization to remove more branches. > > As the C1 cmov code is a bit tricky I left that as a followup. > > I added gtests for the cmovs. > (we should add coverage for more of masm in this gtest suit) > Pro tip, invoke the gtestLauncher directly (you only need to build exploded): > `gtestLauncher -jdk build/linux-riscv64-server-fastdebug/jdk/ --gtest_break_on_failure --gtest_filter="*RiscV*" -XX:+UnlockDiagnosticVMOptions -XX:+UseZicond -XX:ParallelGCThreads=1 -XX:ConcGCThreads=1 -XX:CICompilerCount=2` > > Tested on Spacemit X60, gtests and tier1. > > Thanks, Robbin Looks good to me. Thanks! ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22386#pullrequestreview-2461757071 From mli at openjdk.org Tue Nov 26 14:47:43 2024 From: mli at openjdk.org (Hamlin Li) Date: Tue, 26 Nov 2024 14:47:43 GMT Subject: RFR: 8344306: RISC-V: Add zicond In-Reply-To: References: <0wHgn-IQt2oxsHzFViNCVzrzKQxy2whwKyfpKqEhDdU=.14c47db5-ddb2-47ad-8d52-be3e2c0a6474@github.com> Message-ID: On Tue, 26 Nov 2024 13:19:29 GMT, Robbin Ehn wrote: >> Not, as we are only removing one in a thousand branches, the different would be so little that I don't think I can measure it in a reasoanble amount of iterations. I think you need something very synthetic, e.g. write a hot loop where we can remove a branch in it to measure it. > >> Seems the critical path when `+UseZicond` is longer than `-UseZicond`, I'm not sure how much impact the branch code will bring when `-UseZicond`. > > As I said, those 4 instructions saves ~1 cycle compared branch in out-order cpu models. Thanks for the discussion! Overall speaking, I think the new patch with cmov is more promising in terms of performance (in terms of pipeline), although we can not enumerate all the use cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22386#discussion_r1858670339 From bkilambi at openjdk.org Tue Nov 26 15:10:49 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Tue, 26 Nov 2024 15:10:49 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations [v3] In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 20:04:09 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 6. Auto-vectorization of newly supported scalar operations. >> 7. X86 and AARCH64 backend implementation for all supported intrinsics. >> 9. Functional and Performance validation tests. >> >> 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: > > Review comments resolution test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java line 201: > 199: > 200: @Test > 201: @IR(counts = {IRNode.MUL_HF, " >0 ", IRNode.REINTERPRET_S2HF, " >0 ", IRNode.REINTERPRET_HF2S, " >0 "}, There's a bit of inconsistency in format for " >0 ". In some of the IR rules above, it's "> 0" and here it's " >0 ". Maybe follow a single format? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1858720659 From bkilambi at openjdk.org Tue Nov 26 15:18:54 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Tue, 26 Nov 2024 15:18:54 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations [v3] In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 20:04:09 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 6. Auto-vectorization of newly supported scalar operations. >> 7. X86 and AARCH64 backend implementation for all supported intrinsics. >> 9. Functional and Performance validation tests. >> >> 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: > > Review comments resolution test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java line 70: > 68: @Warmup(10000) > 69: @IR(counts = {IRNode.ADD_VHF, ">= 1"}, > 70: applyIfCPUFeatureOr = {"avx512_fp16", "true"}) this should be just `applyIfCPUFeature`. When I add the `sve` feature to this list, I will change it to `applyIfCPUFeatureOr`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1858733245 From bkilambi at openjdk.org Tue Nov 26 15:24:54 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Tue, 26 Nov 2024 15:24:54 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations [v3] In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 20:04:09 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 6. Auto-vectorization of newly supported scalar operations. >> 7. X86 and AARCH64 backend implementation for all supported intrinsics. >> 9. Functional and Performance validation tests. >> >> 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: > > Review comments resolution test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java line 43: > 41: > 42: @Test > 43: @IR(applyIfCPUFeatureAnd = {"avx512_fp16", "false", "avx512vl", "true"}, counts = {IRNode.VECTOR_CAST_HF2F, IRNode.VECTOR_SIZE_ANY, ">= 1", IRNode.VECTOR_CAST_F2HF, IRNode.VECTOR_SIZE_ANY, " >= 1"}) Would it probably be more readable if `applyIfCPUFeatureAnd` and `counts` are in separate lines? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1858743792 From gziemski at openjdk.org Tue Nov 26 15:24:51 2024 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 26 Nov 2024 15:24:51 GMT Subject: RFR: 8328944: NMT reports "unknown" memory [v4] In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 19:05:58 GMT, Johan Sj?len wrote: > This LGTM and the chosen categories seem to make sense. Thank you for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21843#issuecomment-2501130432 From ihse at openjdk.org Tue Nov 26 15:35:44 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 26 Nov 2024 15:35:44 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v17] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: <_xcPHc3NQFiZMfLnk6oFB_hpkRhoYxHXE7SalMBT1iU=.0af2b4f3-71d9-4db6-ab13-ad87415082fc@github.com> On Tue, 19 Nov 2024 20:21:52 GMT, Erik Joelsson wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Copy debuginfo > > make/autoconf/buildjdk-spec.gmk.template line 80: > >> 78: CXXFLAGS_JDKEXE := @OPENJDK_BUILD_CXXFLAGS_JDKEXE@ >> 79: LDFLAGS_JDKEXE := @OPENJDK_BUILD_LDFLAGS_JDKEXE@ >> 80: LDFLAGS_STATIC_JDK := @OPENJDK_BUILD_LDFLAGS_STATIC_JDK@ > > Do we really expect to ever build a static-jdk as buildjdk? Not really, no. I created this out of symmetry reasons. Do you want me to remove it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1858764083 From ihse at openjdk.org Tue Nov 26 15:39:55 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 26 Nov 2024 15:39:55 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v17] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Tue, 19 Nov 2024 20:28:18 GMT, Erik Joelsson wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Copy debuginfo > > make/common/JdkNativeCompilation.gmk line 313: > >> 311: # created libraries, and is read by ModuleWrapper. >> 312: ifneq ($$($1_EXCLUDE_FROM_STATIC_LIBS), true) >> 313: $$(MODULE)_JDK_LIBS += $$($1_NAME) > > This variable is used to track libraries that should be included in static libs. Perhaps the name should include the word "static" to make this clearer? Otherwise it doesn't make sense to exclude libraries like this from this list. I think it's more the name EXCLUDE_FROM_STATIC_LIBS that is bad. What I am really trying to express here is whether a library is supposed to be used by the Java classes in this module, or if it is provided as a special library for external parties to link with. Like you said about the windowsaccessbridge stuff above. These too should be flagged as "do not implement necessary native functionality for the java classes in the module". Maybe call it ONLY_EXPORTED? NOT_INTERNALLY_USED? Or maybe turn the boolean the other way around and call it USED_BY_MODULE, and set it fo `false` for those special cases? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1858771219 From bkilambi at openjdk.org Tue Nov 26 15:42:52 2024 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Tue, 26 Nov 2024 15:42:52 GMT Subject: RFR: 8342103: C2 compiler support for Float16 type and associated operations [v3] In-Reply-To: References: Message-ID: <7n50_F8vrK70EijMOWNg_OPZZdrB4qp0LVi429w0McU=.0673ea33-7980-4f26-8a24-377753797276@github.com> On Mon, 25 Nov 2024 20:04:09 GMT, Jatin Bhateja wrote: >> Hi All, >> >> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128) >> >> Following is the summary of changes included with this patch:- >> >> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations. >> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization. >> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class. >> - These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values. >> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines. >> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details. >> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa. >> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF >> 6. Auto-vectorization of newly supported scalar operations. >> 7. X86 and AARCH64 backend implementation for all supported intrinsics. >> 9. Functional and Performance validation tests. >> >> 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: > > Review comments resolution src/hotspot/share/opto/library_call.cpp line 8659: > 8657: return true; > 8658: } > 8659: This line can be removed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1858776695 From ihse at openjdk.org Tue Nov 26 15:42:55 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 26 Nov 2024 15:42:55 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v17] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Tue, 19 Nov 2024 20:34:31 GMT, Erik Joelsson wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Copy debuginfo > > make/modules/java.desktop/lib/ClientLibraries.gmk line 166: > >> 164: jfdctflt.o jfdctfst.o jfdctint.o jidctflt.o jidctfst.o jidctint.o \ >> 165: jidctred.o jmemmgr.o jmemnobs.o jpegdecoder.o jquant1.o jquant2.o \ >> 166: jutils.o > > If libsplashscreen is already excluded in StaticLibs.gmk, why do we need to exclude obj files here? > > Would it be possible to generate this list? I assume it's all the src files in libjavajpeg, but with the object file suffix. It's only excluded on Linux and Windows. (And that is just a silly one function with a duplicated name, that we could easily fix) It's all src files from libjavajpeg that originates from upstream, but we add in some additional files. But if you prefer I can rewrite this as a wildcard for libjavajpeg and then filter out our files. (And replace the file suffix, of course.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1858776734 From ihse at openjdk.org Tue Nov 26 15:47:24 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 26 Nov 2024 15:47:24 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v18] In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Just exclude the a11y libraries from static builds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20837/files - new: https://git.openjdk.org/jdk/pull/20837/files/41d37075..658be7d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=16-17 Stats: 6 lines in 2 files changed: 2 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20837.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837 PR: https://git.openjdk.org/jdk/pull/20837 From kim.barrett at oracle.com Tue Nov 26 16:56:39 2024 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 26 Nov 2024 11:56:39 -0500 Subject: Poisoning in HotSpot In-Reply-To: References: Message-ID: <7cb918b4-4ee7-4c2f-9ab8-036325dc43b4@oracle.com> On 11/26/24 4:55 AM, Julian Waters wrote: > Hi all, > > It turned out in the review of > https://github.com/openjdk/jdk/pull/22069?that the poisoning mechanism > used in HotSpot can break when combined with LTO. Also, poisoning does > not work on Windows, at least not with the default Microsoft compiler > (Though, the Windows/gcc Port also disables FORBID_C_FUNCTION as > well). I've tried coming up with an alternative mechanism to poison > methods that works on any platform, but I'm unsure what to do with it > now. It can be viewed here: https://godbolt.org/z/PKMjjWTxz > > Any improvements that could be made to it? Should I continue this so > we can have a poisoning mechanism that works even while LTO is active? I think the approach taken in that link won't work, and can't. Try void* ptr = ::malloc(size_t(1)) No "use of a deleted function" error from that. The problem is that a non-template exact match is a better match than any template in the overload set. So calling ::malloc with a size_t argument calls the clib function rather than the template in the anonymous namespace. There's also the "scoped attribute directive ignored" warnings. I remember reading something about scoped attributes not being as useful as one might think. Ah, here's part of the discussion: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368 From ihse at openjdk.org Tue Nov 26 16:58:02 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 26 Nov 2024 16:58:02 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v19] In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Find LIBJAVA_JPEG_OBJS automatically ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20837/files - new: https://git.openjdk.org/jdk/pull/20837/files/658be7d6..2b3ff7e6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=17-18 Stats: 9 lines in 1 file changed: 0 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20837.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837 PR: https://git.openjdk.org/jdk/pull/20837 From ihse at openjdk.org Tue Nov 26 16:58:02 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 26 Nov 2024 16:58:02 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v17] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Tue, 26 Nov 2024 15:40:13 GMT, Magnus Ihse Bursie wrote: >> make/modules/java.desktop/lib/ClientLibraries.gmk line 166: >> >>> 164: jfdctflt.o jfdctfst.o jfdctint.o jidctflt.o jidctfst.o jidctint.o \ >>> 165: jidctred.o jmemmgr.o jmemnobs.o jpegdecoder.o jquant1.o jquant2.o \ >>> 166: jutils.o >> >> If libsplashscreen is already excluded in StaticLibs.gmk, why do we need to exclude obj files here? >> >> Would it be possible to generate this list? I assume it's all the src files in libjavajpeg, but with the object file suffix. > > It's only excluded on Linux and Windows. (And that is just a silly one function with a duplicated name, that we could easily fix) > > It's all src files from libjavajpeg that originates from upstream, but we add in some additional files. But if you prefer I can rewrite this as a wildcard for libjavajpeg and then filter out our files. (And replace the file suffix, of course.) Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1858909321 From alanb at openjdk.org Tue Nov 26 17:05:48 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 26 Nov 2024 17:05:48 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 09:14:30 GMT, Kevin Walls wrote: > Remove redundant SecurityManager Permission references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandImpl.java line 112: > 110: this.cmd = cmd; > 111: this.info = info; > 112: Exception cause = null; I assume cause can be deleted too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22315#discussion_r1858929672 From ihse at openjdk.org Tue Nov 26 17:06:35 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 26 Nov 2024 17:06:35 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v20] In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Find LIBZIP_OBJS automatically ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20837/files - new: https://git.openjdk.org/jdk/pull/20837/files/2b3ff7e6..a1b02138 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=18-19 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/20837.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837 PR: https://git.openjdk.org/jdk/pull/20837 From ihse at openjdk.org Tue Nov 26 17:06:38 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 26 Nov 2024 17:06:38 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v17] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Tue, 19 Nov 2024 20:35:01 GMT, Erik Joelsson wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Copy debuginfo > > make/modules/java.desktop/lib/ClientLibraries.gmk line 180: > >> 178: deflate.o Deflater.o Inflater.o gzclose.o gzlib.o gzread.o gzwrite.o \ >> 179: infback.o inffast.o inflate.o inftrees.o trees.o uncompr.o zadler32.o \ >> 180: zcrc32.o zip_util.o zutil.o > > Same as above. Fixed as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1858928224 From kim.barrett at oracle.com Tue Nov 26 17:13:39 2024 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 26 Nov 2024 12:13:39 -0500 Subject: HotSpot doesn't use NULL In-Reply-To: References: <0298f200-cdcc-40d0-9926-a5c0436c6092@oracle.com> <8BD53E0B-A928-4F59-AD14-1E8B88F8AE4C@amazon.de> Message-ID: <39e1a11f-5d38-4ca0-bbc1-14d9c14e09e2@oracle.com> On 11/26/24 2:24 AM, Volker Simonis wrote: > When I forwarded this to our team, William suggested to add a new > jcheck test to warn about this. I'm not familiar with the new > git-jcheck, but at a first glance, this looks like an interesting > opportunity to me. > > What do you think? Adding it to jcheck came up in an internal discussion, and the response was "we can't easily tell jcheck to only apply rules to hotspot, so that would require updating jcheck with that ability as well." But it seems like a good approach if that limitation can be solved. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Tue Nov 26 17:15:35 2024 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 26 Nov 2024 12:15:35 -0500 Subject: HotSpot doesn't use NULL In-Reply-To: References: Message-ID: <8043dab6-3e49-46e9-88c9-89383a217316@oracle.com> On 11/26/24 8:37 AM, Julian Waters wrote: > Both VC and gcc support pragmas that force disable all uses of an > identifier whatsoever, deprecated for VC and poison for gcc. This > would probably depend on whether you want to forbid null everywhere or > whether you need some places where NULL has to be used This fails the "makes it unusable seems problematic because it might affect non-HotSpot code." criteria. From ccheung at openjdk.org Tue Nov 26 17:16:59 2024 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 26 Nov 2024 17:16:59 GMT Subject: RFR: 8343427: Class file load hook crashes on archived classes from multi-release JARs [v6] In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 04:06:22 GMT, David Holmes wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> remove assert in filemap.cpp > > Marked as reviewed by dholmes (Reviewer). Thanks @dholmes-ora, @iklam, @liach, @AlanBateman for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22262#issuecomment-2501494517 From ccheung at openjdk.org Tue Nov 26 17:17:01 2024 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 26 Nov 2024 17:17:01 GMT Subject: Integrated: 8343427: Class file load hook crashes on archived classes from multi-release JARs In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 00:37:25 GMT, Calvin Cheung wrote: > Currently, when retrieving a ClassFileStream during runtime, we call into the zip library to retrieve the stream based only on a class name. This doesn't work well if the class is in a multi-release jar under a versioned directory such as `META-INF/versions/9/Foo.class`. To address this issue, this change calls the java api `ClassLoader.getResourceAsStream()` to retrieve the stream. > > Passed tiers 1 - 4 testing. This pull request has now been integrated. Changeset: d752f196 Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/d752f19611f7d2a83b4d5356c37e6c8ff02543fd Stats: 239 lines in 7 files changed: 238 ins; 0 del; 1 mod 8343427: Class file load hook crashes on archived classes from multi-release JARs Reviewed-by: dholmes, iklam ------------- PR: https://git.openjdk.org/jdk/pull/22262 From ihse at openjdk.org Tue Nov 26 17:17:09 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 26 Nov 2024 17:17:09 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v21] In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: > As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. > > This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. > > All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Merge branch 'master' into static-jdk-image - Remove LDFLAGS_STATIC_JDK - Rename EXCLUDE_FROM_STATIC_LIBS to ONLY_EXPORTED, $(MODULE)_JDK_LIBS to $(MODULE)_INCLUDED_LIBS and module-libs.txt to module-included-libs.txt - Find LIBZIP_OBJS automatically - Find LIBJAVA_JPEG_OBJS automatically - Just exclude the a11y libraries from static builds - Copy debuginfo - Restore SetExecname in java_md.c - Fix incremental builds - Merge branch 'master' into static-jdk-image - ... and 15 more: https://git.openjdk.org/jdk/compare/c329f97f...8b1217a8 ------------- Changes: https://git.openjdk.org/jdk/pull/20837/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=20 Stats: 497 lines in 27 files changed: 399 ins; 23 del; 75 mod Patch: https://git.openjdk.org/jdk/pull/20837.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837 PR: https://git.openjdk.org/jdk/pull/20837 From ihse at openjdk.org Tue Nov 26 17:17:11 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 26 Nov 2024 17:17:11 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v17] In-Reply-To: <_xcPHc3NQFiZMfLnk6oFB_hpkRhoYxHXE7SalMBT1iU=.0af2b4f3-71d9-4db6-ab13-ad87415082fc@github.com> References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> <_xcPHc3NQFiZMfLnk6oFB_hpkRhoYxHXE7SalMBT1iU=.0af2b4f3-71d9-4db6-ab13-ad87415082fc@github.com> Message-ID: On Tue, 26 Nov 2024 15:32:43 GMT, Magnus Ihse Bursie wrote: >> make/autoconf/buildjdk-spec.gmk.template line 80: >> >>> 78: CXXFLAGS_JDKEXE := @OPENJDK_BUILD_CXXFLAGS_JDKEXE@ >>> 79: LDFLAGS_JDKEXE := @OPENJDK_BUILD_LDFLAGS_JDKEXE@ >>> 80: LDFLAGS_STATIC_JDK := @OPENJDK_BUILD_LDFLAGS_STATIC_JDK@ >> >> Do we really expect to ever build a static-jdk as buildjdk? > > Not really, no. I created this out of symmetry reasons. Do you want me to remove it? Removed. >> make/common/JdkNativeCompilation.gmk line 313: >> >>> 311: # created libraries, and is read by ModuleWrapper. >>> 312: ifneq ($$($1_EXCLUDE_FROM_STATIC_LIBS), true) >>> 313: $$(MODULE)_JDK_LIBS += $$($1_NAME) >> >> This variable is used to track libraries that should be included in static libs. Perhaps the name should include the word "static" to make this clearer? Otherwise it doesn't make sense to exclude libraries like this from this list. > > I think it's more the name EXCLUDE_FROM_STATIC_LIBS that is bad. What I am really trying to express here is whether a library is supposed to be used by the Java classes in this module, or if it is provided as a special library for external parties to link with. > > Like you said about the windowsaccessbridge stuff above. These too should be flagged as "do not implement necessary native functionality for the java classes in the module". > > Maybe call it ONLY_EXPORTED? NOT_INTERNALLY_USED? Or maybe turn the boolean the other way around and call it USED_BY_MODULE, and set it fo `false` for those special cases? I renamed `EXCLUDE_FROM_STATIC_LIBS` to `ONLY_EXPORTED`, `$(MODULE)_JDK_LIBS` to `$(MODULE)_INCLUDED_LIBS` and `module-libs.txt` to `module-included-libs.txt`. I hope this makes the purpose clearer and the usage more consistent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1858942492 PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1858940422 From mdoerr at openjdk.org Tue Nov 26 17:43:06 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 26 Nov 2024 17:43:06 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v11] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 26 Nov 2024 00:37:32 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - 8344985: GenShen: Refactor arraycopy barrier for generational mode > > Reviewed-by: shade Can you also add the platform code contributors to the Contributors, please? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2501563056 From qamai at openjdk.org Tue Nov 26 18:20:22 2024 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 26 Nov 2024 18:20:22 GMT Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle implementation [v3] In-Reply-To: References: Message-ID: > Hi, > > This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout. > > Regarding the related issues: > > - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout. > - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate` > - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests. > > Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables. > > Please take a look and leave reviews. Thanks a lot. > > The description of the original PR: > > This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks: > > Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically. > Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations. > Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler. > Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones. > Upon these changes, a `rearrange` can emit more efficient code: > > var species = IntVector.SPECIES_128; > var v1 = IntVector.fromArray(species, SRC1, 0); > var v2 = IntVector.fromArray(species, SRC2, 0); > v1.rearrange(v2.toShuffle()).intoArray(DST, 0); > > Before: > movabs $0x751589fa8,%r10 ; {oop([I{0x0000000751589fa8})} > vmovdqu 0x10(%r10),%xmm2 > movabs $0x7515a0d08,%r10 ; {oop([I{0x00000007515a0d08})} > vmovdqu 0x10(%r10),%xmm1 > movabs $0x75158afb8,%r10 ; {oop([I{0x000000075158afb8})} > vmovdqu 0x10(%r10),%xmm0 > vpand -0xddc12(%rip),%xmm0,%xmm0 # Stub::vector_int_to_byte_mask > ; {ex... Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - whitespace - Merge branch 'master' into shufflerefactor - [vectorapi] Refactor VectorShuffle implementation ------------- Changes: https://git.openjdk.org/jdk/pull/21042/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21042&range=02 Stats: 4912 lines in 64 files changed: 2602 ins; 1066 del; 1244 mod Patch: https://git.openjdk.org/jdk/pull/21042.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21042/head:pull/21042 PR: https://git.openjdk.org/jdk/pull/21042 From qamai at openjdk.org Tue Nov 26 18:20:23 2024 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 26 Nov 2024 18:20:23 GMT Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle implementation [v2] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 23:17:35 GMT, Sandhya Viswanathan wrote: >> I have adapted the patch in accordance with https://github.com/openjdk/jdk/pull/20634, I moved the index wrapping into C2 instead of making it a separate step as I think it seems clearer. Also, I think in the future we can eliminate this step so putting it in C2 would make the progress easier. >> >> Please take a look, thanks a lot. > > @merykitty Could you please merge with the latest and resolve conflicts? @sviswa7 @PaulSandoz @eme64 @jatin-bhateja Thanks for taking a look, I have merged the PR with a more recent master and resolved the sematic difference with newly added intrinsics, too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2501633760 From qamai at openjdk.org Tue Nov 26 18:20:24 2024 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 26 Nov 2024 18:20:24 GMT Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle implementation [v2] In-Reply-To: References: Message-ID: On Tue, 15 Oct 2024 16:25:04 GMT, Emanuel Peter wrote: >> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> [vectorapi] Refactor VectorShuffle implementation > > src/hotspot/share/opto/vectornode.hpp line 1618: > >> 1616: public: >> 1617: VectorLoadShuffleNode(Node* in, const TypeVect* vt) >> 1618: : VectorNode(in, vt) {} > > Can you add a comment above "class VectorLoadShuffleNode" to say what its semantics are? Done, I would refrain from renaming it right now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1859030030 From qamai at openjdk.org Tue Nov 26 18:20:25 2024 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 26 Nov 2024 18:20:25 GMT Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle implementation [v2] In-Reply-To: References: Message-ID: On Tue, 29 Oct 2024 20:27:20 GMT, Paul Sandoz wrote: >> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: >> >> [vectorapi] Refactor VectorShuffle implementation > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 228: > >> 226: } >> 227: >> 228: AbstractVector iota = vspecies().asIntegral().iota(); > > I suspect the non-power of two code is more efficient. (Even better if the MUL could be transformed to a shift for power of two values.) > > Separately, it makes me wonder if we should revisit the shuffle factories if it is now much more efficient to construct a shuffle from a vector. `shuffleFromOp` is a slow path op so I don't think it is. Additionally, our vector multiplication is against a scalar, too. So we can optimize it if `step` is a constant. > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java line 870: > >> 868: @Override >> 869: public final Int256Shuffle rearrange(VectorShuffle shuffle) { >> 870: return (Int256Shuffle) toBitsVector().rearrange(((Int256Shuffle) shuffle) > > I think the cast is redundant for all vector kinds. Similarly the explicit cast is redundant for the integral vectors, perhaps in the template separate out the expressions to avoid it where not needed? > > We could also refer to `VSPECIES` directly rather than calling `vspecies()`, same applies in other methods in the concrete vector classes. The cast is added so that we have the concrete type of the shuffle, the result of `toShuffle` is only `VectorShuffle` > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java line 908: > >> 906: } >> 907: >> 908: private static boolean indicesInRange(int[] indices) { > > Since this method is only called from an assert statement in the constructor we could avoid the clever checking that assertions are enabled and the explicit throwing on an AssertionError by using a second expression that produces an error message when the assertion fails : e.g., > > assert indicesInRange(indices) : outOfBoundsAssertMessage(indices); Yes you are right, since this method is only called in `assert` I think we can just remove the `assert` trick inside instead. > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java line 2473: > >> 2471: final >> 2472: VectorShuffle toShuffle(AbstractSpecies dsp, boolean wrap) { >> 2473: assert(dsp.elementSize() == vspecies().elementSize()); > > Even though we force inline I cannot quite decide if it is better to forego the assert since it unduly increases method size. Regardless it may be useful to place the partial wrapping logic in a separate method, given it is less likely to be used. You don't have to worry too much about inlining of Vector API methods since it is done during late inlining and we have a pretty huge budget there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1859037153 PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1859033054 PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1859033749 PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1859032221 From vlivanov at openjdk.org Tue Nov 26 19:26:42 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 26 Nov 2024 19:26:42 GMT Subject: RFR: 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only [v2] In-Reply-To: <255_hfpSxSvEECjsUa48_iufPhHxi-8o3lyWa3_GhcU=.481704f1-8a08-4892-a7fa-544e245910d8@github.com> References: <255_hfpSxSvEECjsUa48_iufPhHxi-8o3lyWa3_GhcU=.481704f1-8a08-4892-a7fa-544e245910d8@github.com> Message-ID: On Tue, 26 Nov 2024 11:00:18 GMT, Andrew Haley wrote: >> This bug only affects x86-64 machines without a `popcnt` instruction, which basically means pre-SSE4.2 machines. This means that x86-64 processors made around 2010 are affected. >> >> My thanks to everyone who was was involved in bisecting this, particularly Martin Bucholz who seems to be the only one testing on such old hardware. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only Marked as reviewed by vlivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22365#pullrequestreview-2462500134 From vlivanov at openjdk.org Tue Nov 26 19:26:43 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 26 Nov 2024 19:26:43 GMT Subject: RFR: 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only [v2] In-Reply-To: References: <3aaeGz7V4yLsAIeSA4ZuTr5isbsusslvk7Qftf7jiI4=.54e563e5-1319-49e0-905e-ed5159157c5e@github.com> Message-ID: On Tue, 26 Nov 2024 10:35:37 GMT, Andrew Haley wrote: >> I'm looking at `MacroAssembler::lookup_secondary_supers_table_var()` and the only thing which can be improved there is an extra comment around line 5116 stressing that `population_count` destroys `slot`. > >> I understand that it greatly increases the reproducibility of the bug, but does such an adhoc code snippet adds much from maintenance perspective? Reusing registers is common in assembly code, so if all places where a register value is destroyed are annotated in a similar way, it would add a lot of noise on source code level. > > The point isn't so much that it's destroyed, but that it's destroyed on a rarely-used code path, in this case on a code path that is only ever executed on an obsolete machine. We've had the same problem on AArch64, where there are the old and new versions of compare-and-swap, and fixed the testing in the same way. Ok, thanks for the pointer. I'm fine with keeping the patch as it is, but I would definitely prefer a cleaner way to zap registers when it comes to scaling its usage across the code base. FTR there's a special place `globalDefinitions.hpp` for constants used for debugging. And I'd be confused to find out that the constant is spelled in camel case after trying to grep for it :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22365#discussion_r1859115728 From qamai at openjdk.org Tue Nov 26 19:33:04 2024 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 26 Nov 2024 19:33:04 GMT Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle implementation [v4] In-Reply-To: References: Message-ID: > Hi, > > This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout. > > Regarding the related issues: > > - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout. > - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate` > - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests. > > Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables. > > Please take a look and leave reviews. Thanks a lot. > > The description of the original PR: > > This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks: > > Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically. > Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations. > Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler. > Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones. > Upon these changes, a `rearrange` can emit more efficient code: > > var species = IntVector.SPECIES_128; > var v1 = IntVector.fromArray(species, SRC1, 0); > var v2 = IntVector.fromArray(species, SRC2, 0); > v1.rearrange(v2.toShuffle()).intoArray(DST, 0); > > Before: > movabs $0x751589fa8,%r10 ; {oop([I{0x0000000751589fa8})} > vmovdqu 0x10(%r10),%xmm2 > movabs $0x7515a0d08,%r10 ; {oop([I{0x00000007515a0d08})} > vmovdqu 0x10(%r10),%xmm1 > movabs $0x75158afb8,%r10 ; {oop([I{0x000000075158afb8})} > vmovdqu 0x10(%r10),%xmm0 > vpand -0xddc12(%rip),%xmm0,%xmm0 # Stub::vector_int_to_byte_mask > ; {ex... Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: fix asserts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21042/files - new: https://git.openjdk.org/jdk/pull/21042/files/4cee07eb..36ee750a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21042&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21042&range=02-03 Stats: 11 lines in 7 files changed: 7 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/21042.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21042/head:pull/21042 PR: https://git.openjdk.org/jdk/pull/21042 From vlivanov at openjdk.org Tue Nov 26 19:46:38 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 26 Nov 2024 19:46:38 GMT Subject: RFR: 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only [v2] In-Reply-To: References: <255_hfpSxSvEECjsUa48_iufPhHxi-8o3lyWa3_GhcU=.481704f1-8a08-4892-a7fa-544e245910d8@github.com> Message-ID: On Tue, 26 Nov 2024 11:04:16 GMT, Andrew Haley wrote: > but I'd advocate for clobbering registers only used on rare code paths to be a standard practice. It would be nice to have an opt-in debugging feature to clobber registers (temporary or not used anymore). But that would require existing code to be annotated with such information. BTW there's a similar case which is pervasive on x86: external address materialization requires an extra register when the address is not reachable in rip-relative addressing mode. There's `ForceUnreachable`, but it's turned off by default. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22365#issuecomment-2501782185 From wkemper at openjdk.org Tue Nov 26 19:52:03 2024 From: wkemper at openjdk.org (William Kemper) Date: Tue, 26 Nov 2024 19:52:03 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v11] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 26 Nov 2024 00:37:32 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - 8344985: GenShen: Refactor arraycopy barrier for generational mode > > Reviewed-by: shade Thank you for getting us started: Thank you for the PPC64 port: Thank you for the RISCV port: ------------- PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2501791242 From dholmes at openjdk.org Tue Nov 26 21:22:45 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Nov 2024 21:22:45 GMT Subject: RFR: 8339480: Build static-jdk image with a statically linked launcher [v21] In-Reply-To: References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com> Message-ID: On Tue, 26 Nov 2024 17:17:09 GMT, Magnus Ihse Bursie wrote: >> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked. >> >> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. >> >> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime). > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge branch 'master' into static-jdk-image > - Remove LDFLAGS_STATIC_JDK > - Rename EXCLUDE_FROM_STATIC_LIBS to ONLY_EXPORTED, $(MODULE)_JDK_LIBS to $(MODULE)_INCLUDED_LIBS and module-libs.txt to module-included-libs.txt > - Find LIBZIP_OBJS automatically > - Find LIBJAVA_JPEG_OBJS automatically > - Just exclude the a11y libraries from static builds > - Copy debuginfo > - Restore SetExecname in java_md.c > - Fix incremental builds > - Merge branch 'master' into static-jdk-image > - ... and 15 more: https://git.openjdk.org/jdk/compare/c329f97f...8b1217a8 Hotspot changes look fine. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20837#pullrequestreview-2462695251 From kevinw at openjdk.org Tue Nov 26 21:31:52 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 26 Nov 2024 21:31:52 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands [v2] In-Reply-To: References: Message-ID: > Remove redundant SecurityManager Permission references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Remove 'cause' ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22315/files - new: https://git.openjdk.org/jdk/pull/22315/files/d173aec7..8486bbe4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22315&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22315&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22315/head:pull/22315 PR: https://git.openjdk.org/jdk/pull/22315 From kevinw at openjdk.org Tue Nov 26 21:31:53 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 26 Nov 2024 21:31:53 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands [v2] In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 17:03:22 GMT, Alan Bateman wrote: >> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove 'cause' > > src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandImpl.java line 112: > >> 110: this.cmd = cmd; >> 111: this.info = info; >> 112: Exception cause = null; > > I assume cause can be deleted too. Yes, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22315#discussion_r1859250311 From darcy at openjdk.org Tue Nov 26 23:25:39 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 26 Nov 2024 23:25:39 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 09:51:10 GMT, Kevin Walls wrote: > > This is a change to the spec of a JDK specific API so I think should be tracked by a CSR. > > OK yes, I was looking for opinions on whether this needed a CSR. > > To be clear, the interface jdk.management / com.sun.management.DiagnosticCommandMBean has a method getDescriptor() which returns a Descriptor, which "is a collection of fields containing additional meta-data for a JMX element". > > This unfortunately does not say any of the metadata are optional, so now that a permission is meaningless we want to remove dcmd.permissionName, dcmd.permissionAction, dcmd.arguments. Yes; please file a quick CSR. Thanks for asking. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22315#issuecomment-2502171504 From dholmes at openjdk.org Wed Nov 27 01:05:42 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Nov 2024 01:05:42 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 06:36:44 GMT, David Holmes wrote: > After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: > > #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} > #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} > #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} > #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} > #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} > #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} > > are all singletons and so the actual strings can just be inlined directly into the code that uses them. > > Testing: > - GHA > - Tiers 1-4 sanity > - > Thanks Re-opened. There was a testing glitch caused by a change not part of this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22380#issuecomment-2502378940 From dlong at openjdk.org Wed Nov 27 01:05:46 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 27 Nov 2024 01:05:46 GMT Subject: RFR: 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only [v2] In-Reply-To: References: <3aaeGz7V4yLsAIeSA4ZuTr5isbsusslvk7Qftf7jiI4=.54e563e5-1319-49e0-905e-ed5159157c5e@github.com> Message-ID: On Tue, 26 Nov 2024 19:23:39 GMT, Vladimir Ivanov wrote: >>> I understand that it greatly increases the reproducibility of the bug, but does such an adhoc code snippet adds much from maintenance perspective? Reusing registers is common in assembly code, so if all places where a register value is destroyed are annotated in a similar way, it would add a lot of noise on source code level. >> >> The point isn't so much that it's destroyed, but that it's destroyed on a rarely-used code path, in this case on a code path that is only ever executed on an obsolete machine. We've had the same problem on AArch64, where there are the old and new versions of compare-and-swap, and fixed the testing in the same way. > > Ok, thanks for the pointer. > > I'm fine with keeping the patch as it is, but I would definitely prefer a cleaner way to zap registers when it comes to scaling its usage across the code base. > > FTR there's a special place `globalDefinitions.hpp` for constants used for debugging. And I'd be confused to find out that the constant is spelled in camel case after trying to grep for it :-) It might be useful to have a testing flag that simulates old hardware on modern hardware. So for example, it would turn off UsePopCountInstruction. We have something similar on x86 with UseKNLSetting. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22365#discussion_r1859516618 From amenkov at openjdk.org Wed Nov 27 01:46:39 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 27 Nov 2024 01:46:39 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 06:36:44 GMT, David Holmes wrote: > After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: > > #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} > #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} > #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} > #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} > #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} > #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} > > are all singletons and so the actual strings can just be inlined directly into the code that uses them. > > Testing: > - GHA > - Tiers 1-4 sanity > - > Thanks Marked as reviewed by amenkov (Reviewer). src/java.base/share/native/libjava/NativeLibraries.c line 76: > 74: > 75: // sym + '_' + cname + '\0' > 76: if ((len = (cname != NULL ? (strlen(cname) + 1) : 0) + strlen(sym) + 1) > To match the updated comment: Suggestion: if ((len = strlen(sym) + (cname != NULL ? (strlen(cname) + 1) : 0) + 1) > ------------- PR Review: https://git.openjdk.org/jdk/pull/22380#pullrequestreview-2463375580 PR Review Comment: https://git.openjdk.org/jdk/pull/22380#discussion_r1859629230 From fyang at openjdk.org Wed Nov 27 02:07:38 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 27 Nov 2024 02:07:38 GMT Subject: RFR: 8344306: RISC-V: Add zicond In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 09:00:34 GMT, Robbin Ehn wrote: > Hi, please consider. > > In cpu models we save ~1 cycle per removed branch. > This patch removes ~0.1% of branches in generic C2 generated code. > We should probably investigate if we can improve/add peephole optimization to remove more branches. > > As the C1 cmov code is a bit tricky I left that as a followup. > > I added gtests for the cmovs. > (we should add coverage for more of masm in this gtest suit) > Pro tip, invoke the gtestLauncher directly (you only need to build exploded): > `gtestLauncher -jdk build/linux-riscv64-server-fastdebug/jdk/ --gtest_break_on_failure --gtest_filter="*RiscV*" -XX:+UnlockDiagnosticVMOptions -XX:+UseZicond -XX:ParallelGCThreads=1 -XX:ConcGCThreads=1 -XX:CICompilerCount=2` > > Tested on Spacemit X60, gtests and tier1. > > Thanks, Robbin Hi, thanks for this work! I once tried to find this extension but I think I missed it :-) Seems that we need two special AD match rules so that `eq`/`ne` zero cases could be further optimized. (Say, we use `t0` for `rtmp` in this code sequence) Conditional select, if zero rd = (rc == 0) ? rs1 : rs2 => czero.nez rd, rs1, rc czero.eqz rtmp, rs2, rc or rd, rd, rtmp Conditional select, if non-zero rd = (rc != 0) ? rs1 : rs2 => czero.eqz rd, rs1, rc czero.nez rtmp, rs2, rc or rd, rd, rtmp src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2006: > 2004: > 2005: void C2_MacroAssembler::enc_cmove(int cmpFlag, Register op1, Register op2, Register dst, Register src) { > 2006: bool is_unsigned = (cmpFlag & unsigned_branch_mask) == unsigned_branch_mask ? true : false; Maybe: `bool is_unsigned = (cmpFlag & unsigned_branch_mask) ? true : false;` src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2007: > 2005: void C2_MacroAssembler::enc_cmove(int cmpFlag, Register op1, Register op2, Register dst, Register src) { > 2006: Label L; > 2007: cmp_branch(cmpFlag ^ (1 << neg_cond_bits), op1, op2, L); The global `neg_cond_bits` is unused after this change. I think we should remove it. ------------- PR Review: https://git.openjdk.org/jdk/pull/22386#pullrequestreview-2463256160 PR Review Comment: https://git.openjdk.org/jdk/pull/22386#discussion_r1859556828 PR Review Comment: https://git.openjdk.org/jdk/pull/22386#discussion_r1859637031 From lmesnik at openjdk.org Wed Nov 27 02:18:45 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 27 Nov 2024 02:18:45 GMT Subject: RFR: 8344987: Test serviceability/sa/TestJhsdbJstackPrintVMLocks.java fails: NoClassDefFoundError: jdk/test/lib/Utils Message-ID: <15eNCXw4oid2xwKbfjrFJ0gLo9w-ZekovlM4-mLnSeM=.13db466d-cbdd-4c4e-b589-4f57c326f623@github.com> The real bug is https://bugs.openjdk.org/browse/CODETOOLS-7902847 Class directory of a test case should not be used to compile a library and the following workaround just excludes the testing group where it fails often. There is no plans to update test right now. The jtreg should be fixed. ------------- Commit messages: - Test is excluded from CDS group Changes: https://git.openjdk.org/jdk/pull/22405/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22405&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344987 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22405.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22405/head:pull/22405 PR: https://git.openjdk.org/jdk/pull/22405 From ysr at openjdk.org Wed Nov 27 02:30:01 2024 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Wed, 27 Nov 2024 02:30:01 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: <0FH7N5Xa3DLDGZcWdxwWQHivNSTxGj9w3p-hWFSgMIs=.654c7bd9-90bb-436d-aedd-08d9fa77efc8@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> <0FH7N5Xa3DLDGZcWdxwWQHivNSTxGj9w3p-hWFSgMIs=.654c7bd9-90bb-436d-aedd-08d9fa77efc8@github.com> Message-ID: On Wed, 20 Nov 2024 00:01:49 GMT, Y. Srinivas Ramakrishna wrote: >> src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp line 474: >> >>> 472: // elision safe. >>> 473: return; >>> 474: } >> >> Why is this safe for Shenandoah? I suspect it needs `CardTableBarrierSet::on_slowpath_allocation_exit` to work. `G1BarrierSetC2` gets it by subclassing `CardTableBarrierSetC2`. But `ShenandoahBarrierSetC2` does not. Should it? > > Good question. I'm tracking at https://bugs.openjdk.org/browse/JDK-8344593 , and will follow up there. A code review indicates that the code is fine, but the comment could be improved. A quick test of performance didn't indicate (with specjbb) any difference in performance (done only for GenShen) but a more complete suite of performance tests is being run to assess the efficacy of the optimization. I'm inclined to leave this in, since eliding card-marks doesn't hurt, even if it doesn't seem to help much either. The comment will be adjusted as part of the above ticket. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1859698145 From syan at openjdk.org Wed Nov 27 02:45:36 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 27 Nov 2024 02:45:36 GMT Subject: RFR: 8344987: Test serviceability/sa/TestJhsdbJstackPrintVMLocks.java fails: NoClassDefFoundError: jdk/test/lib/Utils In-Reply-To: <15eNCXw4oid2xwKbfjrFJ0gLo9w-ZekovlM4-mLnSeM=.13db466d-cbdd-4c4e-b589-4f57c326f623@github.com> References: <15eNCXw4oid2xwKbfjrFJ0gLo9w-ZekovlM4-mLnSeM=.13db466d-cbdd-4c4e-b589-4f57c326f623@github.com> Message-ID: On Wed, 27 Nov 2024 02:13:41 GMT, Leonid Mesnik wrote: > The real bug is > https://bugs.openjdk.org/browse/CODETOOLS-7902847 Class directory of a test case should not be used to compile a library > > and the following workaround just excludes the testing group where it fails often. > > There is no plans to update test right now. The jtreg should be fixed. How about exclude this test in `test/hotspot/jtreg/ProblemList.txt`, add a problemlist entry like `serviceability/sa/TestJhsdbJstackPrintVMLocks.java CODETOOLS-7902847 generic-all`, since this test will be convenient re-enable after [CODETOOLS-7902847](https://bugs.openjdk.org/browse/CODETOOLS-7902847) been fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22405#issuecomment-2502563628 From vlivanov at openjdk.org Wed Nov 27 02:55:46 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 27 Nov 2024 02:55:46 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations [v6] In-Reply-To: <8iGnF6YCOXLvgRrIQp86kGsAUNFRiwj_oSqWR5N7jZo=.cf279212-baf3-4110-aa3b-d3c40c711245@github.com> References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> <8iGnF6YCOXLvgRrIQp86kGsAUNFRiwj_oSqWR5N7jZo=.cf279212-baf3-4110-aa3b-d3c40c711245@github.com> Message-ID: <_Nk_rbzx2JFFBFbq_E1iMLI1TjkLiQVaxIZfJS5o9OY=.76827525-02c1-4de5-a2b2-613ed7149faf@github.com> On Tue, 26 Nov 2024 09:58:08 GMT, Andrew Dinn wrote: >> Implementation of JDK-8343767 > > Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: > > fix issue with x86 avx3 array copy Thanks, test results look much better now. Finally hit code buffer overflow on x86 you mentioned earlier (so far, single occurrence). It happened on windows-x64 w/ AVX512 (Ice Lake SP) and ZGC enabled. # Internal Error (.../codeBuffer.hpp:200), pid=12224, tid=45132 # assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000022aa93c4860 <= 0x0000022aa93d14c1 <= 0x0000022aa93d14c0 It crashed at the very end in `generate_final_stubs`. report_vm_error+0x5b (debug.cpp:193) CodeSection::set_end+0x97 (codeBuffer.hpp:200) Assembler::movdqu+0x12a (assembler_x86.cpp:3450) MacroAssembler::movdqu+0xb8 (macroAssembler_x86.cpp:2639) ZRuntimeCallSpill::restore+0x7a (zBarrierSetAssembler_x86.cpp:122) ZBarrierSetAssembler::load_at+0x2ae (zBarrierSetAssembler_x86.cpp:280) MacroAssembler::access_load_at+0x127 (macroAssembler_x86.cpp:6038) MacroAssembler::load_heap_oop+0x98 (macroAssembler_x86.cpp:6057) StubGenerator::generate_upcall_stub_load_target+0x19e (stubGenerator_x86_64.cpp:3989) StubGenerator::generate_final_stubs+0x41a (stubGenerator_x86_64.cpp:4171) I checked on `linux-x64` and the space is pretty tight there with ZGC and AVX512 enabled: $ jdk/bin/java -XX:UseAVX=3 -XX:+UseZGC -XX:+ForceUnreachable -Xlog:stubs ... [0.372s][info][stubs] StubRoutines (finalstubs) [0x00007fdd87bc99e0, 0x00007fdd87bd5e70] used: 46091, free: 4229 ... ``` Do you expect any increase in total stub sizes from your changes? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2502579263 From fjiang at openjdk.org Wed Nov 27 03:03:37 2024 From: fjiang at openjdk.org (Feilong Jiang) Date: Wed, 27 Nov 2024 03:03:37 GMT Subject: RFR: 8345047: RISC-V: Remove explicit use of AvoidUnalignedAccesses in interpreter In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 10:19:40 GMT, Fei Yang wrote: > Hi, please consider this small interpreter cleanup change. > > The use of `AvoidUnalignedAccesses` option for these cases doen't much sense to me. > MacroAssembler routines like `revb_h_h_u` and `revb_h_h` will emit 5 instructions when Zbb extension is not available. This is more than the case when `AvoidUnalignedAccesses` option is true. After this change, we always emit 4 instructions compared to 3 instructions in the case when we have Zbb extension. But I don't think it will make a difference. > > Testing on linux-riscv64 platform: > - [x] tier1 (release) Looks good. ------------- Marked as reviewed by fjiang (Committer). PR Review: https://git.openjdk.org/jdk/pull/22387#pullrequestreview-2463583473 From vlivanov at openjdk.org Wed Nov 27 03:13:37 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 27 Nov 2024 03:13:37 GMT Subject: RFR: 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only [v2] In-Reply-To: References: <3aaeGz7V4yLsAIeSA4ZuTr5isbsusslvk7Qftf7jiI4=.54e563e5-1319-49e0-905e-ed5159157c5e@github.com> Message-ID: On Wed, 27 Nov 2024 01:02:47 GMT, Dean Long wrote: >> Ok, thanks for the pointer. >> >> I'm fine with keeping the patch as it is, but I would definitely prefer a cleaner way to zap registers when it comes to scaling its usage across the code base. >> >> FTR there's a special place `globalDefinitions.hpp` for constants used for debugging. And I'd be confused to find out that the constant is spelled in camel case after trying to grep for it :-) > > It might be useful to have a testing flag that simulates old hardware on modern hardware. So for example, it would turn off UsePopCountInstruction. We have something similar on x86 with UseKNLSetting. Doesn't `-XX:UseSSE=2` achieve exactly that on x86-64? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22365#discussion_r1859763278 From tanksherman27 at gmail.com Wed Nov 27 04:54:34 2024 From: tanksherman27 at gmail.com (Julian Waters) Date: Wed, 27 Nov 2024 12:54:34 +0800 Subject: Poisoning in HotSpot In-Reply-To: <7cb918b4-4ee7-4c2f-9ab8-036325dc43b4@oracle.com> References: <7cb918b4-4ee7-4c2f-9ab8-036325dc43b4@oracle.com> Message-ID: Hi Kim, Darn, that's unfortunate. There was an earlier prototype I had that does solve this issue, but unfortunately the error message resulting from someone trying to use a poisoned method is much less clear in that one: #include #pragma warning(disable : 4624) // This warning is already disabled for HotSpot // Poisoning malloc so it cannot be used in a program #define FORBID_C_FUNCTION(signature, alternative, body) \ inline namespace { \ template = 0> \ [[gnu::always_inline]] inline signature noexcept { body } \ [[deprecated(alternative)]] signature noexcept = delete; \ } #define ALLOW_C_FUNCTION(name) name FORBID_C_FUNCTION(void *malloc(size_t size), "use os::malloc", return ::malloc(size);) The example program that includes the header above: #include int main() { void *ptr = ::malloc(size_t{1}); free(ptr); } Will get the following compile error: : In function 'int main()': :20:25: error: call of overloaded 'malloc(size_t)' is ambiguous 20 | void *ptr = ::malloc(size_t{1}); | In file included from /opt/compiler-explorer/gcc-trunk-20241126/include/c++/15.0.0/cstdlib:83, from :2: /usr/include/stdlib.h:540:14: note: candidate: 'void* malloc(size_t)' 540 | extern void *malloc (size_t __size) __THROW __attribute_malloc__ | ^~~~~~ :17:25: note: candidate: 'void* {anonymous}::malloc(size_t)' (deleted) 17 | FORBID_C_FUNCTION(void *malloc(size_t size), "use os::malloc", return ::malloc(size);) | ^~~~~~ :12:33: note: in definition of macro 'FORBID_C_FUNCTION' 12 | [[deprecated(alternative)]] signature noexcept = delete; \ | ^~~~~~~~~ Unless ::malloc is wrapped in ALLOW_C_FUNCTION As for the scoped attributes, for this particular case HotSpot has the ALWAYSINLINE macro, which bypasses the issue of having unknown attributes. They could be defined to the corresponding scoped forceinline attribute that the compiler understands, which avoids compile failures best regards, Julian On Wed, Nov 27, 2024 at 12:56?AM Kim Barrett wrote: > > On 11/26/24 4:55 AM, Julian Waters wrote: > > Hi all, > > > > It turned out in the review of > > https://github.com/openjdk/jdk/pull/22069 that the poisoning mechanism > > used in HotSpot can break when combined with LTO. Also, poisoning does > > not work on Windows, at least not with the default Microsoft compiler > > (Though, the Windows/gcc Port also disables FORBID_C_FUNCTION as > > well). I've tried coming up with an alternative mechanism to poison > > methods that works on any platform, but I'm unsure what to do with it > > now. It can be viewed here: https://godbolt.org/z/PKMjjWTxz > > > > Any improvements that could be made to it? Should I continue this so > > we can have a poisoning mechanism that works even while LTO is active? > > I think the approach taken in that link won't work, and can't. Try > > void* ptr = ::malloc(size_t(1)) > > No "use of a deleted function" error from that. The problem is that a > non-template exact match is a better match than any template in the overload > set. So calling ::malloc with a size_t argument calls the clib function > rather > than the template in the anonymous namespace. > > There's also the "scoped attribute directive ignored" warnings. I remember > reading something about scoped attributes not being as useful as one might > think. Ah, here's part of the discussion: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368 > From dholmes at openjdk.org Wed Nov 27 05:00:38 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Nov 2024 05:00:38 GMT Subject: RFR: 8340731: Cleanup remaining IA64 references in hotspot code [v3] In-Reply-To: <9Wjp3_-L1obl7LcNfqXnhXCR3wF15c0Pwi2gD8VPX24=.3895822c-b9cb-4548-85d4-c0eb82a3b7ed@github.com> References: <9Wjp3_-L1obl7LcNfqXnhXCR3wF15c0Pwi2gD8VPX24=.3895822c-b9cb-4548-85d4-c0eb82a3b7ed@github.com> Message-ID: On Tue, 26 Nov 2024 07:29:48 GMT, Amit Kumar wrote: >> src/hotspot/share/runtime/javaCalls.cpp line 121: >> >>> 119: // Do this after the transition because this allows us to put an assert >>> 120: // the Java->vm transition which checks to see that stack is not walkable >>> 121: // which will catch violations of the resetting of last_Java_frame >> >> Not clear the comment is still valid given we no longer have sparc or ia64 support. > > should I remove this whole comment then ? Yes please. I can't see anything related to "not walkable" in the thread state transition code. I checked back to Java 8. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22382#discussion_r1859923684 From amitkumar at openjdk.org Wed Nov 27 05:04:24 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 27 Nov 2024 05:04:24 GMT Subject: RFR: 8340731: Cleanup remaining IA64 references in hotspot code [v4] In-Reply-To: References: Message-ID: > This PR cleans up `IA64` entries form hotspot codebase. > > As mentioned in the JBS, I left `zero` component as-it-is: > > ./cpu/zero/bytecodeInterpreter_zero.hpp:31:#if defined(PPC) || defined(IA64) > ./os_cpu/linux_zero/os_linux_zero.cpp:350:#ifdef IA64 > ./os_cpu/linux_zero/os_linux_zero.cpp:351: // IA64 has two stacks sharing the same area of memory, a normal > ./os_cpu/linux_zero/os_linux_zero.cpp:360:#endif // IA64 > > > Fastdebug VM Build on Mac-M1 & Linux/s390x is fine. Tests are in progress. Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: removes comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22382/files - new: https://git.openjdk.org/jdk/pull/22382/files/39d2fd98..cabcf178 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22382&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22382&range=02-03 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22382.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22382/head:pull/22382 PR: https://git.openjdk.org/jdk/pull/22382 From amitkumar at openjdk.org Wed Nov 27 05:04:24 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 27 Nov 2024 05:04:24 GMT Subject: RFR: 8340731: Cleanup remaining IA64 references in hotspot code [v4] In-Reply-To: References: <9Wjp3_-L1obl7LcNfqXnhXCR3wF15c0Pwi2gD8VPX24=.3895822c-b9cb-4548-85d4-c0eb82a3b7ed@github.com> Message-ID: On Wed, 27 Nov 2024 04:58:14 GMT, David Holmes wrote: >> should I remove this whole comment then ? > > Yes please. I can't see anything related to "not walkable" in the thread state transition code. I checked back to Java 8. done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22382#discussion_r1859925529 From dholmes at openjdk.org Wed Nov 27 05:20:16 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Nov 2024 05:20:16 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 [v2] In-Reply-To: References: Message-ID: > After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: > > #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} > #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} > #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} > #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} > #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} > #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} > > are all singletons and so the actual strings can just be inlined directly into the code that uses them. > > Testing: > - GHA > - Tiers 1-4 sanity > - > Thanks David Holmes has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/native/libjava/NativeLibraries.c Co-authored-by: Alex Menkov <69548902+alexmenkov at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22380/files - new: https://git.openjdk.org/jdk/pull/22380/files/e7081932..c38bb48f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22380&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22380&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22380/head:pull/22380 PR: https://git.openjdk.org/jdk/pull/22380 From dholmes at openjdk.org Wed Nov 27 05:20:16 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Nov 2024 05:20:16 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 [v2] In-Reply-To: References: Message-ID: <1b1f_xG8E-rg3dYcYQIqZSlF8LLW6ZbSehDD2ZRC5Pg=.de226ac3-9641-4795-919b-d8d6975b496e@github.com> On Wed, 27 Nov 2024 01:43:34 GMT, Alex Menkov wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.base/share/native/libjava/NativeLibraries.c >> >> Co-authored-by: Alex Menkov <69548902+alexmenkov at users.noreply.github.com> > > Marked as reviewed by amenkov (Reviewer). Thanks for the review @alexmenkov ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22380#issuecomment-2502827946 From dholmes at openjdk.org Wed Nov 27 06:11:39 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Nov 2024 06:11:39 GMT Subject: RFR: 8344904: Interned strings in old classes are not stored in CDS archive [v2] In-Reply-To: <7ausG_UkrSqNJBoU4iMf1WgvrymR0gtOQmm_uUOw3tg=.558f2d07-cd4b-4031-87ed-0889cdf04d9f@github.com> References: <7ausG_UkrSqNJBoU4iMf1WgvrymR0gtOQmm_uUOw3tg=.558f2d07-cd4b-4031-87ed-0889cdf04d9f@github.com> Message-ID: On Tue, 26 Nov 2024 05:32:44 GMT, Ioi Lam wrote: >> Before this fix, CDS will only archive interned strings that are reachable from `ConstantPool::resolved_references()`, which is created only after a class is linked. However, old classes are not linked, so we didn't archive their interned strings. >> >> It's possible for the Java mirror of an (unlinked) old class to point to interned strings. E.g., >> >> >> public super class OldClassWithStaticString >> version 49:0 >> { >> public static final Field s:"Ljava/lang/String;" = String "xxxx123yyyy456"; >> >> >> The 's' field is initialized during class file parsing, so we must intern the `"xxxx123yyyy456"` string. >> >> The fix is to collect interned strings from the static fields of unlinked classes. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @dholmes-ora comments Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22340#pullrequestreview-2463981061 From dholmes at openjdk.org Wed Nov 27 06:27:36 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Nov 2024 06:27:36 GMT Subject: RFR: 8344987: Test serviceability/sa/TestJhsdbJstackPrintVMLocks.java fails: NoClassDefFoundError: jdk/test/lib/Utils In-Reply-To: References: <15eNCXw4oid2xwKbfjrFJ0gLo9w-ZekovlM4-mLnSeM=.13db466d-cbdd-4c4e-b589-4f57c326f623@github.com> Message-ID: On Wed, 27 Nov 2024 02:43:23 GMT, SendaoYan wrote: >> The real bug is >> https://bugs.openjdk.org/browse/CODETOOLS-7902847 Class directory of a test case should not be used to compile a library >> >> and the following workaround just excludes the testing group where it fails often. >> >> There is no plans to update test right now. The jtreg should be fixed. > > How about exclude this test in `test/hotspot/jtreg/ProblemList.txt`, add a problemlist entry like `serviceability/sa/TestJhsdbJstackPrintVMLocks.java CODETOOLS-7902847 generic-all`, since this test will be convenient re-enable after [CODETOOLS-7902847](https://bugs.openjdk.org/browse/CODETOOLS-7902847) been fixed. @sendaoYan adding to the PL will mean the test never runs. With the proposed change it will still run in tier1_serviceability where it has not been seen to fail, but will no longer run in the problematic tier4 grouping. This seems a reasonable compromise. That said we have modified a number of tests to workaround the CODETOOLS issue, so we could do that here as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22405#issuecomment-2503008670 From dholmes at openjdk.org Wed Nov 27 06:33:49 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Nov 2024 06:33:49 GMT Subject: RFR: 8340731: Cleanup remaining IA64 references in hotspot code [v4] In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 05:04:24 GMT, Amit Kumar wrote: >> This PR cleans up `IA64` entries form hotspot codebase. >> >> As mentioned in the JBS, I left `zero` component as-it-is: >> >> ./cpu/zero/bytecodeInterpreter_zero.hpp:31:#if defined(PPC) || defined(IA64) >> ./os_cpu/linux_zero/os_linux_zero.cpp:350:#ifdef IA64 >> ./os_cpu/linux_zero/os_linux_zero.cpp:351: // IA64 has two stacks sharing the same area of memory, a normal >> ./os_cpu/linux_zero/os_linux_zero.cpp:360:#endif // IA64 >> >> >> Fastdebug VM Build on Mac-M1 & Linux/s390x is fine. Tests are in progress. > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > removes comment Changes requested by dholmes (Reviewer). src/hotspot/share/runtime/javaCalls.cpp line 122: > 120: // the Java->vm transition which checks to see that stack is not walkable > 121: // on sparc/ia64 which will catch violations of the resetting of last_Java_frame > 122: // invariants (i.e. _flags always cleared on return to Java) Sorry please restore the first line. ------------- PR Review: https://git.openjdk.org/jdk/pull/22382#pullrequestreview-2464009412 PR Review Comment: https://git.openjdk.org/jdk/pull/22382#discussion_r1860011698 From syan at openjdk.org Wed Nov 27 06:36:42 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 27 Nov 2024 06:36:42 GMT Subject: RFR: 8344987: Test serviceability/sa/TestJhsdbJstackPrintVMLocks.java fails: NoClassDefFoundError: jdk/test/lib/Utils In-Reply-To: References: <15eNCXw4oid2xwKbfjrFJ0gLo9w-ZekovlM4-mLnSeM=.13db466d-cbdd-4c4e-b589-4f57c326f623@github.com> Message-ID: <7qHKFTCJJ1Cs1dD3aMrXXtbHGxk_oiJh0dyoCeBxHqo=.19cb31a2-d1e8-4dc1-8449-4d233727be3a@github.com> On Wed, 27 Nov 2024 02:43:23 GMT, SendaoYan wrote: >> The real bug is >> https://bugs.openjdk.org/browse/CODETOOLS-7902847 Class directory of a test case should not be used to compile a library >> >> and the following workaround just excludes the testing group where it fails often. >> >> There is no plans to update test right now. The jtreg should be fixed. > > How about exclude this test in `test/hotspot/jtreg/ProblemList.txt`, add a problemlist entry like `serviceability/sa/TestJhsdbJstackPrintVMLocks.java CODETOOLS-7902847 generic-all`, since this test will be convenient re-enable after [CODETOOLS-7902847](https://bugs.openjdk.org/browse/CODETOOLS-7902847) been fixed. > @sendaoYan adding to the PL will mean the test never runs. With the proposed change it will still run in tier1_serviceability where it has not been seen to fail, but will no longer run in the problematic tier4 grouping. Thanks David's explanation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22405#issuecomment-2503019213 From amitkumar at openjdk.org Wed Nov 27 06:42:19 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 27 Nov 2024 06:42:19 GMT Subject: RFR: 8340731: Cleanup remaining IA64 references in hotspot code [v5] In-Reply-To: References: Message-ID: <6JUM4Qd7FTHeoUFvkukajaSBR9hReqI1FWcKTgMoZ-I=.66202c29-1664-4221-be41-5fa17c0f7292@github.com> > This PR cleans up `IA64` entries form hotspot codebase. > > As mentioned in the JBS, I left `zero` component as-it-is: > > ./cpu/zero/bytecodeInterpreter_zero.hpp:31:#if defined(PPC) || defined(IA64) > ./os_cpu/linux_zero/os_linux_zero.cpp:350:#ifdef IA64 > ./os_cpu/linux_zero/os_linux_zero.cpp:351: // IA64 has two stacks sharing the same area of memory, a normal > ./os_cpu/linux_zero/os_linux_zero.cpp:360:#endif // IA64 > > > Fastdebug VM Build on Mac-M1 & Linux/s390x is fine. Tests are in progress. Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: adds portion of comment back ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22382/files - new: https://git.openjdk.org/jdk/pull/22382/files/cabcf178..7a95ebfe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22382&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22382&range=03-04 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22382.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22382/head:pull/22382 PR: https://git.openjdk.org/jdk/pull/22382 From amitkumar at openjdk.org Wed Nov 27 06:42:20 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 27 Nov 2024 06:42:20 GMT Subject: RFR: 8340731: Cleanup remaining IA64 references in hotspot code [v3] In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 06:30:33 GMT, David Holmes wrote: >> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> suggestion from David > > src/hotspot/share/runtime/javaCalls.cpp line 122: > >> 120: // the Java->vm transition which checks to see that stack is not walkable >> 121: // which will catch violations of the resetting of last_Java_frame >> 122: // invariants (i.e. _flags always cleared on return to Java) > > Sorry please restore the first line. updated :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22382#discussion_r1860018959 From dholmes at openjdk.org Wed Nov 27 07:05:39 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Nov 2024 07:05:39 GMT Subject: RFR: 8340731: Cleanup remaining IA64 references in hotspot code [v5] In-Reply-To: <6JUM4Qd7FTHeoUFvkukajaSBR9hReqI1FWcKTgMoZ-I=.66202c29-1664-4221-be41-5fa17c0f7292@github.com> References: <6JUM4Qd7FTHeoUFvkukajaSBR9hReqI1FWcKTgMoZ-I=.66202c29-1664-4221-be41-5fa17c0f7292@github.com> Message-ID: <2-r4L9wwGhgycdv1bLqYk-Z0MNuOOHK_57aQldqBXe0=.39231107-ee9b-4ed8-9270-57e7c72c1a75@github.com> On Wed, 27 Nov 2024 06:42:19 GMT, Amit Kumar wrote: >> This PR cleans up `IA64` entries form hotspot codebase. >> >> As mentioned in the JBS, I left `zero` component as-it-is: >> >> ./cpu/zero/bytecodeInterpreter_zero.hpp:31:#if defined(PPC) || defined(IA64) >> ./os_cpu/linux_zero/os_linux_zero.cpp:350:#ifdef IA64 >> ./os_cpu/linux_zero/os_linux_zero.cpp:351: // IA64 has two stacks sharing the same area of memory, a normal >> ./os_cpu/linux_zero/os_linux_zero.cpp:360:#endif // IA64 >> >> >> Fastdebug VM Build on Mac-M1 & Linux/s390x is fine. Tests are in progress. > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > adds portion of comment back Looks good. Please wait for second review before integrating. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22382#pullrequestreview-2464057200 From rehn at openjdk.org Wed Nov 27 07:28:43 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 27 Nov 2024 07:28:43 GMT Subject: RFR: 8344306: RISC-V: Add zicond In-Reply-To: References: Message-ID: <8bTXeuk2e-Fz8Szu24rN_uXEK6u4g_5_dWEUkfcoOOg=.eb357efe-7224-4b27-8506-b560be1dc0bc@github.com> On Wed, 27 Nov 2024 01:23:13 GMT, Fei Yang wrote: >> Hi, please consider. >> >> In cpu models we save ~1 cycle per removed branch. >> This patch removes ~0.1% of branches in generic C2 generated code. >> We should probably investigate if we can improve/add peephole optimization to remove more branches. >> >> As the C1 cmov code is a bit tricky I left that as a followup. >> >> I added gtests for the cmovs. >> (we should add coverage for more of masm in this gtest suit) >> Pro tip, invoke the gtestLauncher directly (you only need to build exploded): >> `gtestLauncher -jdk build/linux-riscv64-server-fastdebug/jdk/ --gtest_break_on_failure --gtest_filter="*RiscV*" -XX:+UnlockDiagnosticVMOptions -XX:+UseZicond -XX:ParallelGCThreads=1 -XX:ConcGCThreads=1 -XX:CICompilerCount=2` >> >> Tested on Spacemit X60, gtests and tier1. >> >> Thanks, Robbin > > src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2006: > >> 2004: >> 2005: void C2_MacroAssembler::enc_cmove(int cmpFlag, Register op1, Register op2, Register dst, Register src) { >> 2006: bool is_unsigned = (cmpFlag & unsigned_branch_mask) == unsigned_branch_mask ? true : false; > > Maybe: > `bool is_unsigned = (cmpFlag & unsigned_branch_mask) ? true : false;` The "(cmpFlag & unsigned_branch_mask)" is a integer value. As [hotspot don't do implicit bool values](https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md), I need to create the bool value by that comparison. But I don't need the ternary operator. I'll update to: `bool is_unsigned = (cmpFlag & unsigned_branch_mask) == unsigned_branch_mask;` > src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2007: > >> 2005: void C2_MacroAssembler::enc_cmove(int cmpFlag, Register op1, Register op2, Register dst, Register src) { >> 2006: Label L; >> 2007: cmp_branch(cmpFlag ^ (1 << neg_cond_bits), op1, op2, L); > > The global `neg_cond_bits` is unused after this change. I think we should remove it. Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22386#discussion_r1860065725 PR Review Comment: https://git.openjdk.org/jdk/pull/22386#discussion_r1860066652 From rehn at openjdk.org Wed Nov 27 07:31:40 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 27 Nov 2024 07:31:40 GMT Subject: RFR: 8344306: RISC-V: Add zicond In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 09:00:34 GMT, Robbin Ehn wrote: > Hi, please consider. > > In cpu models we save ~1 cycle per removed branch. > This patch removes ~0.1% of branches in generic C2 generated code. > We should probably investigate if we can improve/add peephole optimization to remove more branches. > > As the C1 cmov code is a bit tricky I left that as a followup. > > I added gtests for the cmovs. > (we should add coverage for more of masm in this gtest suit) > Pro tip, invoke the gtestLauncher directly (you only need to build exploded): > `gtestLauncher -jdk build/linux-riscv64-server-fastdebug/jdk/ --gtest_break_on_failure --gtest_filter="*RiscV*" -XX:+UnlockDiagnosticVMOptions -XX:+UseZicond -XX:ParallelGCThreads=1 -XX:ConcGCThreads=1 -XX:CICompilerCount=2` > > Tested on Spacemit X60, gtests and tier1. > > Thanks, Robbin > Hi, thanks for this work! I once tried to find this extension but I think I missed it :-) Seems that we need two special AD match rules to catch `eq`/`ne` zero cases could be further optimized. (Say, we use `t0` for `rtmp` in this code sequence) > > ``` > Conditional select, if zero > rd = (rc == 0) ? rs1 : rs2 > => > czero.nez rd, rs1, rc > czero.eqz rtmp, rs2, rc > or rd, rd, rtmp > ``` > > ``` > Conditional select, if non-zero > rd = (rc != 0) ? rs1 : rs2 > => > czero.eqz rd, rs1, rc > czero.nez rtmp, rs2, rc > or rd, rd, rtmp > ``` Thanks! Yes we should look into that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22386#issuecomment-2503110245 From rehn at openjdk.org Wed Nov 27 07:49:20 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 27 Nov 2024 07:49:20 GMT Subject: RFR: 8344306: RISC-V: Add zicond [v2] In-Reply-To: References: Message-ID: <1E2nFsGaUAPderV9ZbGy3LGj9ByaotHCjRW19wNWI54=.f163dacf-b2cc-4642-80c8-aa48a55e0f1a@github.com> > Hi, please consider. > > In cpu models we save ~1 cycle per removed branch. > This patch removes ~0.1% of branches in generic C2 generated code. > We should probably investigate if we can improve/add peephole optimization to remove more branches. > > As the C1 cmov code is a bit tricky I left that as a followup. > > I added gtests for the cmovs. > (we should add coverage for more of masm in this gtest suit) > Pro tip, invoke the gtestLauncher directly (you only need to build exploded): > `gtestLauncher -jdk build/linux-riscv64-server-fastdebug/jdk/ --gtest_break_on_failure --gtest_filter="*RiscV*" -XX:+UnlockDiagnosticVMOptions -XX:+UseZicond -XX:ParallelGCThreads=1 -XX:ConcGCThreads=1 -XX:CICompilerCount=2` > > Tested on Spacemit X60, gtests and tier1. > > Thanks, Robbin Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22386/files - new: https://git.openjdk.org/jdk/pull/22386/files/3bae7423..a65d9e2a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22386&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22386&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22386.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22386/head:pull/22386 PR: https://git.openjdk.org/jdk/pull/22386 From syan at openjdk.org Wed Nov 27 07:53:09 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 27 Nov 2024 07:53:09 GMT Subject: RFR: 8345043: [ASAN] methodMatcher.cpp report reading from a region of size 0 [-Werror=stringop-overread] Message-ID: Hi all, The file src/hotspot/share/compiler/methodMatcher.cpp report compile warning by gcc14 with -fsanitize=address `?size_t strlen(const char*)? reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]`. I think it's false positive, the `if (name[0] == '*')` and `if (strlen(name) == 1)` judgement has make sure that the length of name greater or equal to 2, but the static analyze at compile time is unable to identify that. So this PR add PRAGMA_DISABLE_GCC_WARNING("-Wstringop-overread") for the line to disable the false positive gcc warning. Risk is low. ------------- Commit messages: - 8345043: [ASAN] methodMatcher.cpp report reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread] by gcc14 Changes: https://git.openjdk.org/jdk/pull/22406/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22406&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345043 Stats: 15 lines in 3 files changed: 14 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22406.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22406/head:pull/22406 PR: https://git.openjdk.org/jdk/pull/22406 From fyang at openjdk.org Wed Nov 27 08:12:41 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 27 Nov 2024 08:12:41 GMT Subject: RFR: 8344306: RISC-V: Add zicond [v2] In-Reply-To: <1E2nFsGaUAPderV9ZbGy3LGj9ByaotHCjRW19wNWI54=.f163dacf-b2cc-4642-80c8-aa48a55e0f1a@github.com> References: <1E2nFsGaUAPderV9ZbGy3LGj9ByaotHCjRW19wNWI54=.f163dacf-b2cc-4642-80c8-aa48a55e0f1a@github.com> Message-ID: On Wed, 27 Nov 2024 07:49:20 GMT, Robbin Ehn wrote: >> Hi, please consider. >> >> In cpu models we save ~1 cycle per removed branch. >> This patch removes ~0.1% of branches in generic C2 generated code. >> We should probably investigate if we can improve/add peephole optimization to remove more branches. >> >> As the C1 cmov code is a bit tricky I left that as a followup. >> >> I added gtests for the cmovs. >> (we should add coverage for more of masm in this gtest suit) >> Pro tip, invoke the gtestLauncher directly (you only need to build exploded): >> `gtestLauncher -jdk build/linux-riscv64-server-fastdebug/jdk/ --gtest_break_on_failure --gtest_filter="*RiscV*" -XX:+UnlockDiagnosticVMOptions -XX:+UseZicond -XX:ParallelGCThreads=1 -XX:ConcGCThreads=1 -XX:CICompilerCount=2` >> >> Tested on Spacemit X60, gtests and tier1. >> >> Thanks, Robbin > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Update change looks good. I am OK if we want to leave other optimization opportunities to some follow-up PR. Up to you! ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22386#pullrequestreview-2464244983 From amitkumar at openjdk.org Wed Nov 27 09:00:48 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 27 Nov 2024 09:00:48 GMT Subject: RFR: 8343653: [s390x] Replace load/store sequence with move instruction Message-ID: Replaces load+store with mvc/mvghi instruction for in-memory operation. Tier1 test are clean except `ShowRegistersOnAssertTest.java` failure, but it failed on head stream also. I am doing git bisect to figure out what's going with that test. Testing: - tier1 test with no flag - tier1 with -XX:+UseCompactObjectHeaders ------------- Commit messages: - replace load + store with in memory move instruction Changes: https://git.openjdk.org/jdk/pull/22408/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22408&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343653 Stats: 17 lines in 5 files changed: 6 ins; 1 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/22408.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22408/head:pull/22408 PR: https://git.openjdk.org/jdk/pull/22408 From mdoerr at openjdk.org Wed Nov 27 09:44:04 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 27 Nov 2024 09:44:04 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v11] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 26 Nov 2024 00:37:32 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - 8344985: GenShen: Refactor arraycopy barrier for generational mode > > Reviewed-by: shade Thanks! I've run another round of tests on all our platforms and the only failure I have seen is [JDK-8344312](https://bugs.openjdk.org/browse/JDK-8344312). I can do more stress testing by making GenShen the default GC. But that can still be done after integration. Could you please add the failing test to the problem list to avoid failures in our CI? gc/shenandoah/oom/TestAllocOutOfMemory.java 8344312 linux-ppc64le ------------- PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2503393423 From amitkumar at openjdk.org Wed Nov 27 09:49:48 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 27 Nov 2024 09:49:48 GMT Subject: RFR: 8343756: CAN_SHOW_REGISTERS_ON_ASSERT for Windows [v4] In-Reply-To: References: <8BqZ3IgRkwo4U2NJ5pSY2pZgC7L2vgagjepaAuQtq4k=.4c4d8f4d-bbee-496c-aa24-6c3965e2c5e5@github.com> Message-ID: On Thu, 14 Nov 2024 13:53:19 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> This enhancement adds register printouts on asserts or guarantees into the hs_err_pid.log error reporting files for Windows. >> >> Additionally, it saves an accurate EXCEPTION_RECORD into the hs_err_pid.mdmp file, also for asserts or guarantees, so the assertion context is now easily accessible in Windbg using .ecxr. >> >> For more details on this enhancement, please see the JIRA issue. >> >> Testing: Tier 1,2,3, jdk_jfr >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > extended test Hi, `ShowRegistersOnAssertTest.java` is failing on linux-s390x after this change. I have opened https://bugs.openjdk.org/browse/JDK-8345102 . ------------- PR Comment: https://git.openjdk.org/jdk/pull/21994#issuecomment-2503408149 From kevinw at openjdk.org Wed Nov 27 09:57:42 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 27 Nov 2024 09:57:42 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands In-Reply-To: References: Message-ID: On Sat, 23 Nov 2024 06:37:23 GMT, Alan Bateman wrote: >> Remove redundant SecurityManager Permission references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > This is a change to the spec of a JDK specific API so I think should be tracked by a CSR. Thanks, (@AlanBateman and @jddarcy), have added the diff of the doc to the CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22315#issuecomment-2503427053 From cnorrbin at openjdk.org Wed Nov 27 09:57:44 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 27 Nov 2024 09:57:44 GMT Subject: RFR: 8318127: align_up has potential overflow [v8] In-Reply-To: <-stdx3eY-an8wxy7v7Pix-2lB4mml0rHiaN1xvozs1U=.06cd889e-a421-4b55-a320-57233b2c4ea4@github.com> References: <-stdx3eY-an8wxy7v7Pix-2lB4mml0rHiaN1xvozs1U=.06cd889e-a421-4b55-a320-57233b2c4ea4@github.com> Message-ID: On Thu, 10 Oct 2024 15:12:57 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The `align_up` function contained code which could potentially overflow and produce an incorrect result. This PR adds an assert to check for such. >> >> Additionally, two test case that previously caused an overflow have been updated to use the highest possible values that do not trigger an overflow. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > newline at eof Thank you both for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20808#issuecomment-2503424539 From duke at openjdk.org Wed Nov 27 09:57:45 2024 From: duke at openjdk.org (duke) Date: Wed, 27 Nov 2024 09:57:45 GMT Subject: RFR: 8318127: align_up has potential overflow [v8] In-Reply-To: <-stdx3eY-an8wxy7v7Pix-2lB4mml0rHiaN1xvozs1U=.06cd889e-a421-4b55-a320-57233b2c4ea4@github.com> References: <-stdx3eY-an8wxy7v7Pix-2lB4mml0rHiaN1xvozs1U=.06cd889e-a421-4b55-a320-57233b2c4ea4@github.com> Message-ID: <1OTgD_pvLP0nPN4tC8EMYFa6PZW3R0buKYvqBiO7byw=.14d727d1-2297-46b4-a577-8fa1094e5a49@github.com> On Thu, 10 Oct 2024 15:12:57 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> The `align_up` function contained code which could potentially overflow and produce an incorrect result. This PR adds an assert to check for such. >> >> Additionally, two test case that previously caused an overflow have been updated to use the highest possible values that do not trigger an overflow. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > newline at eof @caspernorrbin Your change (at version 0b418a4c6afa3a5dbb3a51a76799985e0e8c1775) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20808#issuecomment-2503426096 From luhenry at openjdk.org Wed Nov 27 10:02:39 2024 From: luhenry at openjdk.org (Ludovic Henry) Date: Wed, 27 Nov 2024 10:02:39 GMT Subject: RFR: 8344306: RISC-V: Add zicond [v2] In-Reply-To: <1E2nFsGaUAPderV9ZbGy3LGj9ByaotHCjRW19wNWI54=.f163dacf-b2cc-4642-80c8-aa48a55e0f1a@github.com> References: <1E2nFsGaUAPderV9ZbGy3LGj9ByaotHCjRW19wNWI54=.f163dacf-b2cc-4642-80c8-aa48a55e0f1a@github.com> Message-ID: On Wed, 27 Nov 2024 07:49:20 GMT, Robbin Ehn wrote: >> Hi, please consider. >> >> In cpu models we save ~1 cycle per removed branch. >> This patch removes ~0.1% of branches in generic C2 generated code. >> We should probably investigate if we can improve/add peephole optimization to remove more branches. >> >> As the C1 cmov code is a bit tricky I left that as a followup. >> >> I added gtests for the cmovs. >> (we should add coverage for more of masm in this gtest suit) >> Pro tip, invoke the gtestLauncher directly (you only need to build exploded): >> `gtestLauncher -jdk build/linux-riscv64-server-fastdebug/jdk/ --gtest_break_on_failure --gtest_filter="*RiscV*" -XX:+UnlockDiagnosticVMOptions -XX:+UseZicond -XX:ParallelGCThreads=1 -XX:ConcGCThreads=1 -XX:CICompilerCount=2` >> >> Tested on Spacemit X60, gtests and tier1. >> >> Thanks, Robbin > > Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Marked as reviewed by luhenry (Committer). I love the added the new `test/hotspot/gtest/riscv/test_assembler_riscv.cpp`. Is it going to be picked up, compiled and run automatically as well? ------------- PR Review: https://git.openjdk.org/jdk/pull/22386#pullrequestreview-2464537043 PR Comment: https://git.openjdk.org/jdk/pull/22386#issuecomment-2503439004 From aph at openjdk.org Wed Nov 27 10:13:44 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 27 Nov 2024 10:13:44 GMT Subject: RFR: 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only [v2] In-Reply-To: References: <3aaeGz7V4yLsAIeSA4ZuTr5isbsusslvk7Qftf7jiI4=.54e563e5-1319-49e0-905e-ed5159157c5e@github.com> Message-ID: <6l0Fu7HKb2v9-HKGDEb0uBqMbaVduoY2i03kMxnChgc=.c0e2a2aa-3de4-4917-aee1-1c22963f53ca@github.com> On Wed, 27 Nov 2024 03:10:58 GMT, Vladimir Ivanov wrote: > Doesn't `-XX:UseSSE=2` achieve exactly that on x86-64? Mmm, but x86 so many overlapping architecture changes over the years it's impossible to test every combination of them. What would be good, though, would be to run tests on whatever the minimum architecture is that we support. I don't think we have any equivalent of what GCC calls -march=x86-64, "a generic CPU with 64-bit extensions, but it looks like -XX:UseSSE=2 means Opteron aka k8, which "supersets MMX, SSE, SSE2, 3DNow!, and enhanced 3DNow!" and is our minimum CPU. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22365#discussion_r1860380119 From fyang at openjdk.org Wed Nov 27 10:28:44 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 27 Nov 2024 10:28:44 GMT Subject: Integrated: 8345047: RISC-V: Remove explicit use of AvoidUnalignedAccesses in interpreter In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 10:19:40 GMT, Fei Yang wrote: > Hi, please consider this small interpreter cleanup change. > > The use of `AvoidUnalignedAccesses` option for these cases doen't much sense to me. > MacroAssembler routines like `revb_h_h_u` and `revb_h_h` will emit 5 instructions when Zbb extension is not available. This is more than the case when `AvoidUnalignedAccesses` option is true. After this change, we always emit 4 instructions compared to 3 instructions in the case when we have Zbb extension. But I don't think it will make a difference. > > Testing on linux-riscv64 platform: > - [x] tier1 (release) This pull request has now been integrated. Changeset: 82137db2 Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/82137db24da7e922c18036eca80291abce5d8bf1 Stats: 36 lines in 2 files changed: 0 ins; 23 del; 13 mod 8345047: RISC-V: Remove explicit use of AvoidUnalignedAccesses in interpreter Reviewed-by: mli, fjiang ------------- PR: https://git.openjdk.org/jdk/pull/22387 From fyang at openjdk.org Wed Nov 27 10:28:43 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 27 Nov 2024 10:28:43 GMT Subject: RFR: 8345047: RISC-V: Remove explicit use of AvoidUnalignedAccesses in interpreter In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 11:15:29 GMT, Hamlin Li wrote: >> Hi, please consider this small interpreter cleanup change. >> >> The use of `AvoidUnalignedAccesses` option for these cases doen't much sense to me. >> MacroAssembler routines like `revb_h_h_u` and `revb_h_h` will emit 5 instructions when Zbb extension is not available. This is more than the case when `AvoidUnalignedAccesses` option is true. After this change, we always emit 4 instructions compared to 3 instructions in the case when we have Zbb extension. But I don't think it will make a difference. >> >> Testing on linux-riscv64 platform: >> - [x] tier1 (release) > > Looks good. Thanks! > Since the changes are in the interpreter, I can accept minor regressions introduced in exchange for code readability. @Hamlin-Li @feilongjiang : Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22387#issuecomment-2503497981 From aph at openjdk.org Wed Nov 27 10:30:42 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 27 Nov 2024 10:30:42 GMT Subject: Integrated: 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 15:27:22 GMT, Andrew Haley wrote: > This bug only affects x86-64 machines without a `popcnt` instruction, which basically means pre-SSE4.2 machines. This means that x86-64 processors made around 2010 are affected. > > My thanks to everyone who was was involved in bisecting this, particularly Martin Bucholz who seems to be the only one testing on such old hardware. This pull request has now been integrated. Changeset: eb0d1ce9 Author: Andrew Haley URL: https://git.openjdk.org/jdk/commit/eb0d1ce9487df000b4675901cc0d18f6a1c86348 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only Reviewed-by: vlivanov, martin, dlong, asemenov ------------- PR: https://git.openjdk.org/jdk/pull/22365 From jbechberger at openjdk.org Wed Nov 27 10:36:28 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 27 Nov 2024 10:36:28 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v31] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 157 commits: - Merge branch 'master' into parttimenerd_jfr_cpu_time_sampler4 - Fix disenroll issue - Merge remote-tracking branch 'origin' into parttimenerd_jfr_cpu_time_sampler4 - Fix zero build - Simplify #ifdefs to fix minimal and zero builds - Merge remote-tracking branch 'origin' into parttimenerd_jfr_cpu_time_sampler4 - Compute actual sampling period via si_overrun - Making queue processing only stoppable in debug builds - Obtain minimal period via the CONFIG_HZ parameter of the kernel - Improve Throttling test case - ... and 147 more: https://git.openjdk.org/jdk/compare/b3986bdb...2dbed881 ------------- Changes: https://git.openjdk.org/jdk/pull/20752/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=30 Stats: 2621 lines in 52 files changed: 2416 ins; 176 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From mdoerr at openjdk.org Wed Nov 27 10:47:40 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 27 Nov 2024 10:47:40 GMT Subject: RFR: 8344609: Check ResourceMark nesting when allocating a GrowableArray on an alternative ResourceArea In-Reply-To: References: Message-ID: <0BaoLMx7Ia-ghk6qk0Eg47ZMdKK_U-rUoLC0jPS2JkE=.963d7883-5aeb-46da-ba5c-a39f253cf5e6@github.com> On Wed, 20 Nov 2024 10:01:24 GMT, Richard Reingruber wrote: > With this change the GrowableArray nesting check is also performed if allocating from an `Arena` which in fact is a `ResourceArea`. > > The additional checking can help find issue as [JDK-8328085](https://bugs.openjdk.org/browse/JDK-8328085). > > More testing is pending. I think this enhancement is helpful to find arena usage bugs. src/hotspot/share/utilities/growableArray.cpp line 78: > 76: > 77: void GrowableArrayNestingCheck::on_arena_alloc(Arena* arena) const { > 78: if ((arena->get_tag() == Arena::Tag::tag_ra) && _nesting != static_cast(arena)->nesting()) { The first comparison uses braces, the second one doesn't. You may want to make that consistent. src/hotspot/share/utilities/growableArray.cpp line 79: > 77: void GrowableArrayNestingCheck::on_arena_alloc(Arena* arena) const { > 78: if ((arena->get_tag() == Arena::Tag::tag_ra) && _nesting != static_cast(arena)->nesting()) { > 79: fatal("allocation bug: GrowableArray is growing within nested ResourceMark"); Should it say "could grow"? ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22269#pullrequestreview-2464648151 PR Review Comment: https://git.openjdk.org/jdk/pull/22269#discussion_r1860428094 PR Review Comment: https://git.openjdk.org/jdk/pull/22269#discussion_r1860429634 From aph at openjdk.org Wed Nov 27 10:50:40 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 27 Nov 2024 10:50:40 GMT Subject: RFR: 8340731: Cleanup remaining IA64 references in hotspot code [v5] In-Reply-To: <6JUM4Qd7FTHeoUFvkukajaSBR9hReqI1FWcKTgMoZ-I=.66202c29-1664-4221-be41-5fa17c0f7292@github.com> References: <6JUM4Qd7FTHeoUFvkukajaSBR9hReqI1FWcKTgMoZ-I=.66202c29-1664-4221-be41-5fa17c0f7292@github.com> Message-ID: On Wed, 27 Nov 2024 06:42:19 GMT, Amit Kumar wrote: >> This PR cleans up `IA64` entries form hotspot codebase. >> >> As mentioned in the JBS, I left `zero` component as-it-is: >> >> ./cpu/zero/bytecodeInterpreter_zero.hpp:31:#if defined(PPC) || defined(IA64) >> ./os_cpu/linux_zero/os_linux_zero.cpp:350:#ifdef IA64 >> ./os_cpu/linux_zero/os_linux_zero.cpp:351: // IA64 has two stacks sharing the same area of memory, a normal >> ./os_cpu/linux_zero/os_linux_zero.cpp:360:#endif // IA64 >> >> >> Fastdebug VM Build on Mac-M1 & Linux/s390x is fine. Tests are in progress. > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > adds portion of comment back Marked as reviewed by aph (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22382#pullrequestreview-2464661670 From rrich at openjdk.org Wed Nov 27 10:53:41 2024 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 27 Nov 2024 10:53:41 GMT Subject: RFR: 8344609: Check ResourceMark nesting when allocating a GrowableArray on an alternative ResourceArea In-Reply-To: <0BaoLMx7Ia-ghk6qk0Eg47ZMdKK_U-rUoLC0jPS2JkE=.963d7883-5aeb-46da-ba5c-a39f253cf5e6@github.com> References: <0BaoLMx7Ia-ghk6qk0Eg47ZMdKK_U-rUoLC0jPS2JkE=.963d7883-5aeb-46da-ba5c-a39f253cf5e6@github.com> Message-ID: On Wed, 27 Nov 2024 10:42:52 GMT, Martin Doerr wrote: >> With this change the GrowableArray nesting check is also performed if allocating from an `Arena` which in fact is a `ResourceArea`. >> >> The additional checking can help find issue as [JDK-8328085](https://bugs.openjdk.org/browse/JDK-8328085). >> >> More testing is pending. > > src/hotspot/share/utilities/growableArray.cpp line 79: > >> 77: void GrowableArrayNestingCheck::on_arena_alloc(Arena* arena) const { >> 78: if ((arena->get_tag() == Arena::Tag::tag_ra) && _nesting != static_cast(arena)->nesting()) { >> 79: fatal("allocation bug: GrowableArray is growing within nested ResourceMark"); > > Should it say "could grow"? It *is* growing since the check is done when allocating to accommodate more array elements. And the RM nesting is different now than when the array was created. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22269#discussion_r1860442200 From lucy at openjdk.org Wed Nov 27 10:55:41 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Wed, 27 Nov 2024 10:55:41 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> References: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> Message-ID: On Mon, 25 Nov 2024 12:59:10 GMT, Amit Kumar wrote: >> s390x Port for : [JDK-8331341](https://bugs.openjdk.org/browse/JDK-8331341) >> >> Tier1 test: >> 1. `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` >> 2. No flag turn on. i.e. used `UseSecondarySupersCache` by default. >> 3. `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` with C1 compiler > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > suggestion from Andrew I had a few minor remarks. Code seems OK (I didn't test). src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3170: > 3168: RegSetIterator available_regs > 3169: // Z_R0 will be used to hold Z_R15(Z_SP) while pushing a new frame, So don't use that here. > 3170: // Z_R1 is will be used to hold r_bitmap in lookup_secondary_supers_table_var, so can't be used "is" or "will be"? src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3200: > 3198: temp_reg, temp2_reg, temp3_reg, temp4_reg, result_reg); > 3199: > 3200: z_cghi(result_reg, 0); There is a significant (and varying) distance between here and where the CC is evaluated. I would expect at least a comment that the code in between must not alter the CC. src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3423: > 3421: Register result) { > 3422: assert_different_registers(r_sub_klass, r_super_klass, temp1, temp2, temp3, temp4, result, Z_R1_scratch, Z_R0_scratch); > 3423: // Z_R0 will be only used in debug builds for slot value varification. Typo. Type vErification, please. ------------- Changes requested by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22341#pullrequestreview-2458761205 PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1858536074 PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1856808440 PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1856810391 From amitkumar at openjdk.org Wed Nov 27 10:58:38 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 27 Nov 2024 10:58:38 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: References: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> Message-ID: On Mon, 25 Nov 2024 15:24:49 GMT, Lutz Schmidt wrote: >> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> suggestion from Andrew > > src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3423: > >> 3421: Register result) { >> 3422: assert_different_registers(r_sub_klass, r_super_klass, temp1, temp2, temp3, temp4, result, Z_R1_scratch, Z_R0_scratch); >> 3423: // Z_R0 will be only used in debug builds for slot value varification. > > Typo. Type vErification, please. We are not using Z_R0 anymore. So this is outdated :). The whole comment is gone now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1860449700 From lucy at openjdk.org Wed Nov 27 11:01:39 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Wed, 27 Nov 2024 11:01:39 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: References: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> Message-ID: On Wed, 27 Nov 2024 10:55:50 GMT, Amit Kumar wrote: >> src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3423: >> >>> 3421: Register result) { >>> 3422: assert_different_registers(r_sub_klass, r_super_klass, temp1, temp2, temp3, temp4, result, Z_R1_scratch, Z_R0_scratch); >>> 3423: // Z_R0 will be only used in debug builds for slot value varification. >> >> Typo. Type vErification, please. > > We are not using Z_R0 anymore. So this is outdated :). The whole comment is gone now. My fault. I was too slow. Pls ignore. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1860454642 From aph at openjdk.org Wed Nov 27 11:06:41 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 27 Nov 2024 11:06:41 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: References: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> Message-ID: On Mon, 25 Nov 2024 15:23:46 GMT, Lutz Schmidt wrote: > There is a significant (and varying) distance between here and where the CC is evaluated. I would expect at least a comment that the code in between must not alter the CC. I'd just move the comparison nearer the conditional branch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1860461104 From amitkumar at openjdk.org Wed Nov 27 11:10:39 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 27 Nov 2024 11:10:39 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: References: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> Message-ID: On Wed, 27 Nov 2024 11:03:55 GMT, Andrew Haley wrote: >I'd just move the comparison nearer the conditional branch. result_reg could be `noreg`. So it will be popped out and we might loose the content. One such call is at `3245`: if (UseSecondarySupersTable) { check_klass_subtype_slow_path_table(sub_klass, super_klass, temp_reg, temp2_reg, /*temp3*/noreg, /*temp4*/noreg, /*result*/noreg, L_success, L_failure, set_cond_codes); But we can store the value in scratch register, maybe `Z_R0` and then move this check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1860467073 From rehn at openjdk.org Wed Nov 27 11:11:40 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 27 Nov 2024 11:11:40 GMT Subject: RFR: 8344306: RISC-V: Add zicond [v2] In-Reply-To: References: <1E2nFsGaUAPderV9ZbGy3LGj9ByaotHCjRW19wNWI54=.f163dacf-b2cc-4642-80c8-aa48a55e0f1a@github.com> Message-ID: On Wed, 27 Nov 2024 09:59:44 GMT, Ludovic Henry wrote: > I love the added the new `test/hotspot/gtest/riscv/test_assembler_riscv.cpp`. Is it going to be picked up, compiled and run automatically as well? Yes: [rehn at rehn-black open]$ make test-gtest CONF=linux-riscv64-server-fastdebug | grep Risc [----------] 1 test from RiscV [ RUN ] RiscV.cmov_vm [ OK ] RiscV.cmov_vm (2 ms) [----------] 1 test from RiscV (2 ms total) ------------- PR Comment: https://git.openjdk.org/jdk/pull/22386#issuecomment-2503592206 From amitkumar at openjdk.org Wed Nov 27 11:18:36 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 27 Nov 2024 11:18:36 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: References: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> Message-ID: On Wed, 27 Nov 2024 11:08:18 GMT, Amit Kumar wrote: >>> There is a significant (and varying) distance between here and where the CC is evaluated. I would expect at least a comment that the code in between must not alter the CC. >> >> I'd just move the comparison nearer the conditional branch. > >>I'd just move the comparison nearer the conditional branch. > > result_reg could be `noreg`. So it will be popped out and we might loose the content. One such call is at `3245`: > > if (UseSecondarySupersTable) { > check_klass_subtype_slow_path_table(sub_klass, > super_klass, > temp_reg, > temp2_reg, > /*temp3*/noreg, > /*temp4*/noreg, > /*result*/noreg, > L_success, > L_failure, > set_cond_codes); > > > But we can store the value in scratch register, maybe `Z_R0` and then move this check. Also, between this instruction and the branch instruction, we are emitting `z_lg` and `z_lghi` instruction. So maybe just put a comment ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1860478551 From amitkumar at openjdk.org Wed Nov 27 11:23:14 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 27 Nov 2024 11:23:14 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v4] In-Reply-To: References: Message-ID: > s390x Port for : [JDK-8331341](https://bugs.openjdk.org/browse/JDK-8331341) > > Tier1 test: > 1. `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` > 2. No flag turn on. i.e. used `UseSecondarySupersCache` by default. > 3. `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` with C1 compiler Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: updates comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22341/files - new: https://git.openjdk.org/jdk/pull/22341/files/9adcdfdd..be6bcd9e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22341&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22341&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22341.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22341/head:pull/22341 PR: https://git.openjdk.org/jdk/pull/22341 From amitkumar at openjdk.org Wed Nov 27 11:23:15 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 27 Nov 2024 11:23:15 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: References: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> Message-ID: On Tue, 26 Nov 2024 13:23:10 GMT, Lutz Schmidt wrote: >> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: >> >> suggestion from Andrew > > src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3170: > >> 3168: RegSetIterator available_regs >> 3169: // Z_R0 will be used to hold Z_R15(Z_SP) while pushing a new frame, So don't use that here. >> 3170: // Z_R1 is will be used to hold r_bitmap in lookup_secondary_supers_table_var, so can't be used > > "is" or "will be"? updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1860484100 From stefan.karlsson at oracle.com Wed Nov 27 11:26:33 2024 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 27 Nov 2024 12:26:33 +0100 Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas Message-ID: I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot Group. Axel is a member of Oracle's HotSpot GC team and has been contributing to various parts of the JVM for over two years now. Votes are due by 2024-12-11T12:24+01:00. Only current Members of the HotSpot Group [1] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [2]. Stefan Karlsson [1] https://openjdk.org/census [2] https://openjdk.org/groups/#member-vote From rehn at openjdk.org Wed Nov 27 11:28:42 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 27 Nov 2024 11:28:42 GMT Subject: RFR: 8344306: RISC-V: Add zicond [v2] In-Reply-To: References: <1E2nFsGaUAPderV9ZbGy3LGj9ByaotHCjRW19wNWI54=.f163dacf-b2cc-4642-80c8-aa48a55e0f1a@github.com> Message-ID: On Wed, 27 Nov 2024 08:10:28 GMT, Fei Yang wrote: > Update change looks good. I am OK if we want to leave other optimization opportunities to some follow-up PR. Up to you! Let's do that, thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22386#issuecomment-2503621347 From rehn at openjdk.org Wed Nov 27 11:28:43 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 27 Nov 2024 11:28:43 GMT Subject: RFR: 8344306: RISC-V: Add zicond [v2] In-Reply-To: References: <0wHgn-IQt2oxsHzFViNCVzrzKQxy2whwKyfpKqEhDdU=.14c47db5-ddb2-47ad-8d52-be3e2c0a6474@github.com> Message-ID: On Tue, 26 Nov 2024 14:43:52 GMT, Hamlin Li wrote: >>> Seems the critical path when `+UseZicond` is longer than `-UseZicond`, I'm not sure how much impact the branch code will bring when `-UseZicond`. >> >> As I said, those 4 instructions saves ~1 cycle compared branch in out-order cpu models. > > Thanks for the discussion! > Overall speaking, I think the new patch with cmov is more promising in terms of performance (in terms of pipeline), although we can not enumerate all the use cases. Yes, exactly, a branch is always more 'intrusive' in the pipeline than plain scalar ops. As we discussed, there are cases where czero perform in pair with branch, but in general it's a win. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22386#discussion_r1860491415 From jbechberger at openjdk.org Wed Nov 27 11:31:31 2024 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 27 Nov 2024 11:31:31 GMT Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v32] In-Reply-To: References: Message-ID: > This is the code for the [JEP draft: CPU Time based profiling for JFR]. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Fix build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20752/files - new: https://git.openjdk.org/jdk/pull/20752/files/2dbed881..020bbe98 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=30-31 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752 PR: https://git.openjdk.org/jdk/pull/20752 From christian.hagedorn at oracle.com Wed Nov 27 11:46:09 2024 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Wed, 27 Nov 2024 12:46:09 +0100 Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas In-Reply-To: References: Message-ID: Vote: yes Best regards, Christian On 27.11.24 12:26, Stefan Karlsson wrote: > I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot Group. > > Axel is a member of Oracle's HotSpot GC team and has been contributing to > various parts of the JVM for over two years now. > > Votes are due by 2024-12-11T12:24+01:00. > > Only current Members of the HotSpot Group [1] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] https://openjdk.org/census > [2] https://openjdk.org/groups/#member-vote From aph-open at littlepinkcloud.com Wed Nov 27 11:50:35 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Wed, 27 Nov 2024 11:50:35 +0000 Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas In-Reply-To: References: Message-ID: <6823f7c0-577d-4685-8cfc-6392672f23a6@littlepinkcloud.com> Vote: yes On 11/27/24 11:26, Stefan Karlsson wrote: > I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot Group. > > Axel is a member of Oracle's HotSpot GC team and has been contributing > to various parts of the JVM for over two years now. > > Votes are due by 2024-12-11T12:24+01:00. > > Only current Members of the HotSpot Group [1] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] https://openjdk.org/census > [2] https://openjdk.org/groups/#member-vote -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rehn at openjdk.org Wed Nov 27 11:51:27 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 27 Nov 2024 11:51:27 GMT Subject: RFR: 8344306: RISC-V: Add zicond [v3] In-Reply-To: References: Message-ID: > Hi, please consider. > > In cpu models we save ~1 cycle per removed branch. > This patch removes ~0.1% of branches in generic C2 generated code. > We should probably investigate if we can improve/add peephole optimization to remove more branches. > > As the C1 cmov code is a bit tricky I left that as a followup. > > I added gtests for the cmovs. > (we should add coverage for more of masm in this gtest suit) > Pro tip, invoke the gtestLauncher directly (you only need to build exploded): > `gtestLauncher -jdk build/linux-riscv64-server-fastdebug/jdk/ --gtest_break_on_failure --gtest_filter="*RiscV*" -XX:+UnlockDiagnosticVMOptions -XX:+UseZicond -XX:ParallelGCThreads=1 -XX:ConcGCThreads=1 -XX:CICompilerCount=2` > > Tested on Spacemit X60, gtests and tier1. > > Thanks, Robbin Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into zicond - Review comments - Fixed ws - Draft ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22386/files - new: https://git.openjdk.org/jdk/pull/22386/files/a65d9e2a..606acb06 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22386&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22386&range=01-02 Stats: 7042 lines in 217 files changed: 1343 ins; 4716 del; 983 mod Patch: https://git.openjdk.org/jdk/pull/22386.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22386/head:pull/22386 PR: https://git.openjdk.org/jdk/pull/22386 From aph at openjdk.org Wed Nov 27 11:52:42 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 27 Nov 2024 11:52:42 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: References: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> Message-ID: On Wed, 27 Nov 2024 11:16:05 GMT, Amit Kumar wrote: > Also, between this instruction and the branch instruction, we are emitting `z_lg` and `z_lghi` instruction. So maybe just put a comment ? Yes, do that. I notice we do the same on AArch64, but I sort-of "know" that `macroAssembler::pop` preserves flags on aarch64 and x86. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1860523524 From kbarrett at openjdk.org Wed Nov 27 12:21:42 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 27 Nov 2024 12:21:42 GMT Subject: RFR: 8345043: [ASAN] methodMatcher.cpp report reading from a region of size 0 [-Werror=stringop-overread] In-Reply-To: References: Message-ID: <4Pt3UYGESpqpmSLiwyx7DM5ngCRc8QAPT_QxllDotxI=.0f32badd-4e47-4b27-b016-48c668c11900@github.com> On Wed, 27 Nov 2024 07:48:00 GMT, SendaoYan wrote: > Hi all, > The file src/hotspot/share/compiler/methodMatcher.cpp report compile warning by gcc14 with -fsanitize=undefined -fsanitize=address `?size_t strlen(const char*)? reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]`. I think it's false positive, the `if (name[0] == '*')` and `if (strlen(name) == 1)` judgement has make sure that the length of name greater or equal to 2, but the static analyze at compile time is unable to identify that. > So this PR add PRAGMA_DISABLE_GCC_WARNING("-Wstringop-overread") for the line to disable the false positive gcc warning. Risk is low. src/hotspot/share/compiler/methodMatcher.cpp line 231: > 229: // This code can incorrectly cause a "stringop-overread" warning with gcc > 230: memmove(name, name + 1, strlen(name + 1) + 1); > 231: PRAGMA_DIAG_POP This function has 4 `strlen(name)` expressions. It could be changed to have only one, and then update the value as it proceeds. I wonder if changing it that way might dodge whatever is confusing ASAN, as well as (arguably) making the function a bit clearer. I've no idea how important (or not) reducing the number of strlen calls might be for performance. So something like this (not tested): static MethodMatcher::Mode check_mode(char name[], const char*& error_msg) { int match = MethodMatcher::Exact; size_t len = strlen(name); if (name[0] == '*') { if (len == 1) { return MethodMatcher::Any; } match |= MethodMatcher::Suffix; memmove(name, name + 1, len); // Include terminating nul in move. len -= 1; } if (len > 0 && name[len - 1] == '*') { match |= MethodMatcher::Prefix; name[--len] = '\0'; } if (len == 0) { error_msg = "** Not a valid pattern"; return MethodMatcher::Any; } if (strstr(name, "*") != nullptr) { error_msg = " Embedded * not allowed"; return MethodMatcher::Unknown; } return (MethodMatcher::Mode)match; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22406#discussion_r1860560780 From amitkumar at openjdk.org Wed Nov 27 12:25:38 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 27 Nov 2024 12:25:38 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: References: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> Message-ID: On Wed, 27 Nov 2024 11:49:45 GMT, Andrew Haley wrote: >> Also, between this instruction and the branch instruction, we are emitting `z_lg` and `z_lghi` instruction. So maybe just put a comment ? > >> Also, between this instruction and the branch instruction, we are emitting `z_lg` and `z_lghi` instruction. So maybe just put a comment ? > > Yes, do that. I notice we do the same on AArch64, but I sort-of "know" that `macroAssembler::pop` preserves flags on aarch64 and x86. already updated :) for s390x, `pop_frame()` doesn't interfere with `cc` as it only uses `lg` instruction which doesn't change `cc`. But `push_frame()` can change `cc` as it uses `aghi` instruction to perform add operation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1860566897 From johan.sjolen at oracle.com Wed Nov 27 12:26:31 2024 From: johan.sjolen at oracle.com (Johan Sjolen) Date: Wed, 27 Nov 2024 12:26:31 +0000 Subject: Integrating Native Memory Tracking (NMT) with core libraries Message-ID: Hi, I'd like to present a new proposal for integration of NMT with OpenJDK's native/core libraries. This is the third time that such a proposal appears on the mailing lists. The first two proposals were initiated by Thomas St?fe, so thank you to him for taking this on first and opening the discussion. If you wonder why we want to have NMT in the native/core libraries, then I think that Thomas did a great case for why in [1], so please read that! Thomas also has a good explanation of the costs and risks for his proposal, the same costs and risks also apply to this proposal. Thomas's ideas were as follows: 1. Adding an interposition library via LD_PRELOAD which captures all relevant allocation/free calls and accounts for these in NMT. Unfortunately, the tagging granularity is quite coarse for an interposition library, as no code is changed to provide more details. 2. Directly exporting NMT's current API to the native libraries via jvm.h [1] The idea of adding new memory categories for core libraries by changing source code in Hotspot was deemed as undesirable. Instead, it was requested that the core libraries can create new memory categories for themselves. So, the goal for a good proposal is to have sufficient category granularity, and that core libraries can be free in specifying their own categories. I believe that my proposal fulfills both of these goals, and so I'd like to open up discussion for this third approach. We will still have an interface exposed via jvm.h but with the possibility of creating new memory tags (categories) dynamically at runtime. This solves both the granularity issue, and let's us avoid changing `memTags.hpp` for the addition of new ones. I have written a small API and implemented a basic prototype of it[0]. NMT is a fairly large system, with multiple modes of operation (summary & detail) and multiple trackers (malloc, virtual, and memory file). For an initial changeset I intend to only implement malloc tracking in summary mode, with the intention of implementing the remaining NMT features in future RFEs. I believe that this gives you "80% of the value for 20% of the cost". Tags are created by calling `JVM_MakeNamedAllocator` which in turn returns a handle to a `named allocator`. A named allocator is uniquely identified by its name, a string provided during creation. The handles are then used similarly to `MemTag`s in HotSpot today, in that they are passed to allocation functions in order to provide NMT with information on accounting. I chose `NamedAllocator` because it's unique and can be read out loud. I appreciate a bit of bike shedding when it comes to naming, so please suggest better names if you've got them. The API is as follows: ```c typedef struct { int32_t allocator_info_handle; } named_allocator_t; /* named_allocator_t x = JVM_MakeNamedAllocator("MyName"); named_allocaotr_t x2 = JVM_MakeNamedAllocator("MyName"); assert(x.allocator_info_handle == x2.allocator_info_handle); // Same name returns same allocator_info_handle Making named allocators is serialized across threads, that is: A lock is taken. The remainder of the API is lock-free as it pertains to NMT. Of course, no guarantees are given to the underlying malloc-implementation. */ JNIEXPORT named_allocator_t JVM_MakeNamedAllocator(const char *name); JNIEXPORT void * JVM_NamedAllocatorAlloc(size_t size, named_allocator_t a); JNIEXPORT void * JVM_NamedAllocatorRealloc(void *p, size_t size, named_allocator_t a); JNIEXPORT void * JVM_NamedAllocatorCalloc(size_t numelems, size_t elemsize, named_allocator_t a); JNIEXPORT void JVM_NamedAllocatorFree(void* ptr); ``` Using this API is fairly easy: Create an allocator and save its handle, then change your malloc/free calls to the new ones. I did a small conversion of libzip to use this API, which was mundane work. Let's go through some of the changes I made. First, we need access to an allocator. I can see two practical ways of doing this We can have a 'memoized' accessor, creating the allocator the first time it's called and otherwise accessing the already created allocator. This is used in `zip_util.c`: ```c /* Zip allocator */ named_allocator_t zip_allocator = {.allocator_info_handle = -1 }; const char* allocator_name = "java.util.zip"; named_allocator_t allocator() { if (zip_allocator.allocator_info_handle == -1) { zip_allocator = JVM_MakeNamedAllocator(allocator_name); } return zip_allocator; } ``` A second variant is to have a `init` function that is called before all other functions, this is used in `Deflater.c` and looks like this: ```c named_allocator_t deflate_allocator; Java_java_util_zip_Deflater_init(JNIEnv *env, jclass cls, jint level, jint strategy, jboolean nowrap) { deflate_allocator = JVM_MakeNamedAllocator("java.util.zip.Deflater"); // ... ``` The rest of the work is simply replacing your calls to malloc and friends to the appropriate function, passing in the `named_allocator_t` handle to each of the functions. That's my proposal in a nutshell. For those who are familiar with NMT's internals, I intend to expand the memory tagging mechanism to store 4 bytes of tagging info per allocation, allowing us to have an essentially infinite amount of memory tags. Regarding a future with more FFM and less C libraries: This proposal fits neatly into the Arena concept of FFM. One could imagine a future where Arenas can be given names, and these names are then used for accounting with a NamedAllocator in NMT We're not there yet, but the point is: Hey, this proposal doesn't rule out such a future and that's nice. Thanks for reading, and I look forward to your responses. All the best, Johan Sj?l?n [0] The full prototype source code is available here: https://github.com/jdksjolen/jdk/tree/native-libs-nmt-take2 It does not integrate with the currently existing NMT and is not MT-safe. I wanted to see what the ergonomics of this API was, which is why I wrote it this way. Note: This prototype refers to the new API allocators as `arena`s, I've chosen a different name in this text as to not overload the name with the Hotspot concept. [1] https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/096197.html From cnorrbin at openjdk.org Wed Nov 27 12:30:46 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 27 Nov 2024 12:30:46 GMT Subject: Integrated: 8318127: align_up has potential overflow In-Reply-To: References: Message-ID: On Mon, 2 Sep 2024 09:41:29 GMT, Casper Norrbin wrote: > Hi everyone, > > The `align_up` function contained code which could potentially overflow and produce an incorrect result. This PR adds an assert to check for such. > > Additionally, two test case that previously caused an overflow have been updated to use the highest possible values that do not trigger an overflow. This pull request has now been integrated. Changeset: 49480628 Author: Casper Norrbin Committer: Kim Barrett URL: https://git.openjdk.org/jdk/commit/494806286f126b29b7fc6eb217fa2ae26f295072 Stats: 38 lines in 3 files changed: 33 ins; 0 del; 5 mod 8318127: align_up has potential overflow Reviewed-by: kbarrett, dlong ------------- PR: https://git.openjdk.org/jdk/pull/20808 From kim.barrett at oracle.com Wed Nov 27 12:31:39 2024 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 27 Nov 2024 07:31:39 -0500 Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas In-Reply-To: References: Message-ID: vote: yes On 11/27/24 6:26 AM, Stefan Karlsson wrote: > I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot > Group. > > Axel is a member of Oracle's HotSpot GC team and has been contributing > to various parts of the JVM for over two years now. > > Votes are due by 2024-12-11T12:24+01:00. > > Only current Members of the HotSpot Group [1] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] https://openjdk.org/census > [2] https://openjdk.org/groups/#member-vote From johan.sjolen at oracle.com Wed Nov 27 12:54:52 2024 From: johan.sjolen at oracle.com (Johan Sjolen) Date: Wed, 27 Nov 2024 12:54:52 +0000 Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas In-Reply-To: References: Message-ID: Vote: yes / Johan ________________________________________ From: hotspot-dev on behalf of Stefan Karlsson Sent: Wednesday, November 27, 2024 12:26 To: hotspot-dev at openjdk.org Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot Group. Axel is a member of Oracle's HotSpot GC team and has been contributing to various parts of the JVM for over two years now. Votes are due by 2024-12-11T12:24+01:00. Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [2]. Stefan Karlsson [1] https://openjdk.org/census [2] https://openjdk.org/groups/#member-vote From lois.foltan at oracle.com Wed Nov 27 13:14:39 2024 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 27 Nov 2024 13:14:39 +0000 Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas In-Reply-To: References: Message-ID: Vote: yes Lois From: hotspot-dev on behalf of Stefan Karlsson Date: Wednesday, November 27, 2024 at 6:26?AM To: hotspot-dev at openjdk.org Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot Group. Axel is a member of Oracle's HotSpot GC team and has been contributing to various parts of the JVM for over two years now. Votes are due by 2024-12-11T12:24+01:00. Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [2]. Stefan Karlsson [1] https://openjdk.org/census [2] https://openjdk.org/groups/#member-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From adinn at openjdk.org Wed Nov 27 13:31:44 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 27 Nov 2024 13:31:44 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations [v6] In-Reply-To: <_Nk_rbzx2JFFBFbq_E1iMLI1TjkLiQVaxIZfJS5o9OY=.76827525-02c1-4de5-a2b2-613ed7149faf@github.com> References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> <8iGnF6YCOXLvgRrIQp86kGsAUNFRiwj_oSqWR5N7jZo=.cf279212-baf3-4110-aa3b-d3c40c711245@github.com> <_Nk_rbzx2JFFBFbq_E1iMLI1TjkLiQVaxIZfJS5o9OY=.76827525-02c1-4de5-a2b2-613ed7149faf@github.com> Message-ID: On Wed, 27 Nov 2024 02:53:01 GMT, Vladimir Ivanov wrote: >> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: >> >> fix issue with x86 avx3 array copy > > Thanks, test results look much better now. Finally hit code buffer overflow on x86 you mentioned earlier (so far, single occurrence). > > It happened on windows-x64 w/ AVX512 (Ice Lake SP) and ZGC enabled. > > # Internal Error (.../codeBuffer.hpp:200), pid=12224, tid=45132 > # assert(allocates2(pc)) failed: not in CodeBuffer memory: 0x0000022aa93c4860 <= 0x0000022aa93d14c1 <= 0x0000022aa93d14c0 > > It crashed at the very end in `generate_final_stubs`. > > report_vm_error+0x5b (debug.cpp:193) > CodeSection::set_end+0x97 (codeBuffer.hpp:200) > Assembler::movdqu+0x12a (assembler_x86.cpp:3450) > MacroAssembler::movdqu+0xb8 (macroAssembler_x86.cpp:2639) > ZRuntimeCallSpill::restore+0x7a (zBarrierSetAssembler_x86.cpp:122) > ZBarrierSetAssembler::load_at+0x2ae (zBarrierSetAssembler_x86.cpp:280) > MacroAssembler::access_load_at+0x127 (macroAssembler_x86.cpp:6038) > MacroAssembler::load_heap_oop+0x98 (macroAssembler_x86.cpp:6057) > StubGenerator::generate_upcall_stub_load_target+0x19e (stubGenerator_x86_64.cpp:3989) > StubGenerator::generate_final_stubs+0x41a (stubGenerator_x86_64.cpp:4171) > > > I checked on `linux-x64` and the space is pretty tight there with ZGC and AVX512 enabled: > > $ jdk/bin/java -XX:UseAVX=3 -XX:+UseZGC -XX:+ForceUnreachable -Xlog:stubs > ... > [0.372s][info][stubs] StubRoutines (finalstubs) [0x00007fdd87bc99e0, 0x00007fdd87bd5e70] used: 46091, free: 4229 > ... > ``` > > Do you expect any increase in total stub sizes from your changes? @iwanowww Thanks for rerunning the tests. Glad to see we at least made it through bootstrapping the jmod image. > Do you expect any increase in total stub sizes from your changes? Hmm, no. Certainly nothing significant. I did not touch the generation routines themselves. The only thing that ought to be different is some of the stub names. I'll recheck the arch blob declarations to see if the sizings pre- and post-merge match up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2503881259 From rkennke at amazon.de Wed Nov 27 13:49:35 2024 From: rkennke at amazon.de (Kennke, Roman) Date: Wed, 27 Nov 2024 13:49:35 +0000 Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas In-Reply-To: References: Message-ID: <9A85A9CC-013B-4820-A8BF-FCF7F4438BC7@amazon.de> Vote: yes Cheers, Roman > I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot Group. > > Axel is a member of Oracle's HotSpot GC team and has been contributing > to various parts of the JVM for over two years now. > > Votes are due by 2024-12-11T12:24+01:00. > > Only current Members of the HotSpot Group [1] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] https://openjdk.org/census > [2] https://openjdk.org/groups/#member-vote Amazon Web Services Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597 From adinn at openjdk.org Wed Nov 27 13:53:05 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 27 Nov 2024 13:53:05 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations [v6] In-Reply-To: <8iGnF6YCOXLvgRrIQp86kGsAUNFRiwj_oSqWR5N7jZo=.cf279212-baf3-4110-aa3b-d3c40c711245@github.com> References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> <8iGnF6YCOXLvgRrIQp86kGsAUNFRiwj_oSqWR5N7jZo=.cf279212-baf3-4110-aa3b-d3c40c711245@github.com> Message-ID: <8YHq6uSjHb0He6AwCPfUjxH3Q-7JytdMWIOVXVQsSCg=.b12679b6-5ad7-4d3c-bef1-347f245f0974@github.com> On Tue, 26 Nov 2024 09:58:08 GMT, Andrew Dinn wrote: >> Implementation of JDK-8343767 > > Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: > > fix issue with x86 avx3 array copy Ah, ok, I get it now. In a few cases, depending on the architecture, I moved generation of some of the generic stubs from one blob to another. That was needed in order to bring them in line with other architectures. In particular, for x86 and s390 I relocated the secondary super table stubs from the compiler blob to the final blob because riscv and aarch64 placed them in the final blob. That's almost certainly what is causing x86 to run out of space and may also be causing an issue for s390. I'll adjust the arch blob declaration for x86 to increment the basic size of the final blob by 1000 and decrease the compiler blob size by a similar amount and see if that fixes the problem. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2503925138 From adinn at openjdk.org Wed Nov 27 13:53:05 2024 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 27 Nov 2024 13:53:05 GMT Subject: RFR: 8343767: Enumerate StubGen blobs, stubs and entries and generate code from declarations [v7] In-Reply-To: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com> Message-ID: > Implementation of JDK-8343767 Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision: adjust x86 blob sizes to allow for relocated stubs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21957/files - new: https://git.openjdk.org/jdk/pull/21957/files/e1f41d34..8497b11e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21957/head:pull/21957 PR: https://git.openjdk.org/jdk/pull/21957 From martin.doerr at sap.com Wed Nov 27 14:04:55 2024 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 27 Nov 2024 14:04:55 +0000 Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas In-Reply-To: References: Message-ID: Vote: yes Best regards, Martin Von: hotspot-dev im Auftrag von Stefan Karlsson Datum: Mittwoch, 27. November 2024 um 12:27 An: hotspot-dev at openjdk.org Betreff: CFV: New HotSpot Group Member: Axel Boldt-Christmas I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot Group. Axel is a member of Oracle's HotSpot GC team and has been contributing to various parts of the JVM for over two years now. Votes are due by 2024-12-11T12:24+01:00. Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [2]. Stefan Karlsson [1] https://openjdk.org/census [2] https://openjdk.org/groups/#member-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.castaneda.lozano at oracle.com Wed Nov 27 14:33:00 2024 From: roberto.castaneda.lozano at oracle.com (Roberto Castaneda Lozano) Date: Wed, 27 Nov 2024 14:33:00 +0000 Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas In-Reply-To: References: Message-ID: Vote: yes ________________________________________ From: hotspot-dev on behalf of Stefan Karlsson Sent: Wednesday, November 27, 2024 12:26 PM To: hotspot-dev at openjdk.org Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot Group. Axel is a member of Oracle's HotSpot GC team and has been contributing to various parts of the JVM for over two years now. Votes are due by 2024-12-11T12:24+01:00. Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [2]. Stefan Karlsson [1] https://openjdk.org/census [2] https://openjdk.org/groups/#member-vote From syan at openjdk.org Wed Nov 27 15:13:38 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 27 Nov 2024 15:13:38 GMT Subject: RFR: 8345043: [ASAN] methodMatcher.cpp report reading from a region of size 0 [-Werror=stringop-overread] In-Reply-To: <4Pt3UYGESpqpmSLiwyx7DM5ngCRc8QAPT_QxllDotxI=.0f32badd-4e47-4b27-b016-48c668c11900@github.com> References: <4Pt3UYGESpqpmSLiwyx7DM5ngCRc8QAPT_QxllDotxI=.0f32badd-4e47-4b27-b016-48c668c11900@github.com> Message-ID: <18r-L7NI6DsOkKuaxBiMFNJFsoLdPijnaohAriAuXLs=.8d68411e-1b07-4464-a898-b8893d2d9b30@github.com> On Wed, 27 Nov 2024 12:17:56 GMT, Kim Barrett wrote: >> Hi all, >> The file src/hotspot/share/compiler/methodMatcher.cpp report compile warning by gcc14 with -fsanitize=undefined -fsanitize=address `?size_t strlen(const char*)? reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]`. I think it's false positive, the `if (name[0] == '*')` and `if (strlen(name) == 1)` judgement has make sure that the length of name greater or equal to 2, but the static analyze at compile time is unable to identify that. >> So this PR add PRAGMA_DISABLE_GCC_WARNING("-Wstringop-overread") for the line to disable the false positive gcc warning. Risk is low. > > src/hotspot/share/compiler/methodMatcher.cpp line 231: > >> 229: // This code can incorrectly cause a "stringop-overread" warning with gcc >> 230: memmove(name, name + 1, strlen(name + 1) + 1); >> 231: PRAGMA_DIAG_POP > > This function has 4 `strlen(name)` expressions. It could be changed to have > only one, and then update the value as it proceeds. I wonder if changing it > that way might dodge whatever is confusing ASAN, as well as (arguably) making > the function a bit clearer. I've no idea how important (or not) reducing the > number of strlen calls might be for performance. > > So something like this (not tested): > > static MethodMatcher::Mode check_mode(char name[], const char*& error_msg) { > int match = MethodMatcher::Exact; > size_t len = strlen(name); > if (name[0] == '*') { > if (len == 1) { > return MethodMatcher::Any; > } > match |= MethodMatcher::Suffix; > memmove(name, name + 1, len); // Include terminating nul in move. > len -= 1; > } > > if (len > 0 && name[len - 1] == '*') { > match |= MethodMatcher::Prefix; > name[--len] = '\0'; > } > > if (len == 0) { > error_msg = "** Not a valid pattern"; > return MethodMatcher::Any; > } > > if (strstr(name, "*") != nullptr) { > error_msg = " Embedded * not allowed"; > return MethodMatcher::Unknown; > } > return (MethodMatcher::Mode)match; > } Thanks your advice. I think the performance impact maybe can be ignored, since this function used for parser `-XX:CompileCommand`. I will try this change can avoid gcc warning or not with -fsanitize=undefined -fsanitize=address. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22406#discussion_r1860831488 From syan at openjdk.org Wed Nov 27 15:20:24 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 27 Nov 2024 15:20:24 GMT Subject: RFR: 8345043: [ASAN] methodMatcher.cpp report reading from a region of size 0 [-Werror=stringop-overread] [v2] In-Reply-To: References: Message-ID: > Hi all, > The file src/hotspot/share/compiler/methodMatcher.cpp report compile warning by gcc14 with -fsanitize=undefined -fsanitize=address `?size_t strlen(const char*)? reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]`. I think it's false positive, the `if (name[0] == '*')` and `if (strlen(name) == 1)` judgement has make sure that the length of name greater or equal to 2, but the static analyze at compile time is unable to identify that. > So this PR add PRAGMA_DISABLE_GCC_WARNING("-Wstringop-overread") for the line to disable the false positive gcc warning. Risk is low. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: combine the calacution of stelen ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22406/files - new: https://git.openjdk.org/jdk/pull/22406/files/0d3768d5..a41e68ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22406&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22406&range=00-01 Stats: 19 lines in 3 files changed: 1 ins; 14 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22406.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22406/head:pull/22406 PR: https://git.openjdk.org/jdk/pull/22406 From syan at openjdk.org Wed Nov 27 15:29:38 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 27 Nov 2024 15:29:38 GMT Subject: RFR: 8345043: [ASAN] methodMatcher.cpp report reading from a region of size 0 [-Werror=stringop-overread] [v2] In-Reply-To: <18r-L7NI6DsOkKuaxBiMFNJFsoLdPijnaohAriAuXLs=.8d68411e-1b07-4464-a898-b8893d2d9b30@github.com> References: <4Pt3UYGESpqpmSLiwyx7DM5ngCRc8QAPT_QxllDotxI=.0f32badd-4e47-4b27-b016-48c668c11900@github.com> <18r-L7NI6DsOkKuaxBiMFNJFsoLdPijnaohAriAuXLs=.8d68411e-1b07-4464-a898-b8893d2d9b30@github.com> Message-ID: On Wed, 27 Nov 2024 15:08:13 GMT, SendaoYan wrote: >> src/hotspot/share/compiler/methodMatcher.cpp line 231: >> >>> 229: // This code can incorrectly cause a "stringop-overread" warning with gcc >>> 230: memmove(name, name + 1, strlen(name + 1) + 1); >>> 231: PRAGMA_DIAG_POP >> >> This function has 4 `strlen(name)` expressions. It could be changed to have >> only one, and then update the value as it proceeds. I wonder if changing it >> that way might dodge whatever is confusing ASAN, as well as (arguably) making >> the function a bit clearer. I've no idea how important (or not) reducing the >> number of strlen calls might be for performance. >> >> So something like this (not tested): >> >> static MethodMatcher::Mode check_mode(char name[], const char*& error_msg) { >> int match = MethodMatcher::Exact; >> size_t len = strlen(name); >> if (name[0] == '*') { >> if (len == 1) { >> return MethodMatcher::Any; >> } >> match |= MethodMatcher::Suffix; >> memmove(name, name + 1, len); // Include terminating nul in move. >> len -= 1; >> } >> >> if (len > 0 && name[len - 1] == '*') { >> match |= MethodMatcher::Prefix; >> name[--len] = '\0'; >> } >> >> if (len == 0) { >> error_msg = "** Not a valid pattern"; >> return MethodMatcher::Any; >> } >> >> if (strstr(name, "*") != nullptr) { >> error_msg = " Embedded * not allowed"; >> return MethodMatcher::Unknown; >> } >> return (MethodMatcher::Mode)match; >> } > > Thanks your advice. I think the performance impact maybe can be ignored, since this function used for parser `-XX:CompileCommand`. I will check this change can avoid gcc warning or not with -fsanitize=undefined -fsanitize=address. The four strlen calculation has been combine to one. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22406#discussion_r1860865622 From gerard.ziemski at oracle.com Wed Nov 27 15:32:52 2024 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 27 Nov 2024 15:32:52 +0000 Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas In-Reply-To: References: Message-ID: Vote: yes On Nov 27, 2024, at 07:14, Lois Foltan wrote: Vote: yes Lois From: hotspot-dev on behalf of Stefan Karlsson Date: Wednesday, November 27, 2024 at 6:26?AM To: hotspot-dev at openjdk.org Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot Group. Axel is a member of Oracle's HotSpot GC team and has been contributing to various parts of the JVM for over two years now. Votes are due by 2024-12-11T12:24+01:00. Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [2]. Stefan Karlsson [1] https://openjdk.org/census [2] https://openjdk.org/groups/#member-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbarrett at openjdk.org Wed Nov 27 15:37:44 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 27 Nov 2024 15:37:44 GMT Subject: RFR: 8345043: [ASAN] methodMatcher.cpp report reading from a region of size 0 [-Werror=stringop-overread] [v2] In-Reply-To: References: Message-ID: <0SiSQr9EcDUn5YKQK_d8OpnlXK8AmMJuFyZYY_tisZg=.3d3c6103-c5ea-4126-915c-5d9a78e481d3@github.com> On Wed, 27 Nov 2024 15:20:24 GMT, SendaoYan wrote: >> Hi all, >> The file src/hotspot/share/compiler/methodMatcher.cpp report compile warning by gcc14 with -fsanitize=undefined -fsanitize=address `?size_t strlen(const char*)? reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]`. I think it's false positive, the `if (name[0] == '*')` and `if (strlen(name) == 1)` judgement has make sure that the length of name greater or equal to 2, but the static analyze at compile time is unable to identify that. >> So this PR change `strlen(name + 1) + 1` to `strlen(name)` to dodge gcc warning. Risk is low. >> >> Additional testing: >> >> - [ ] jtreg tests(include tier1/2/3 etc.) by linux-x64 release build >> - [ ] jtreg tests(include tier1/2/3 etc.) by linux-aarch64 release build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > combine the calacution of stelen Looks good. Glad we don't need to uglify things with the warning suppression. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22406#pullrequestreview-2465377864 From hohensee at amazon.com Wed Nov 27 15:39:04 2024 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 27 Nov 2024 15:39:04 +0000 Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas Message-ID: Vote: yes ?On 11/27/24, 3:27 AM, "hotspot-dev on behalf of Stefan Karlsson" on behalf of stefan.karlsson at oracle.com > wrote: I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot Group. Axel is a member of Oracle's HotSpot GC team and has been contributing to various parts of the JVM for over two years now. Votes are due by 2024-12-11T12:24+01:00. Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [2]. Stefan Karlsson [1] https://openjdk.org/census [2] https://openjdk.org/groups/#member-vote From lucy at openjdk.org Wed Nov 27 15:46:38 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Wed, 27 Nov 2024 15:46:38 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: References: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> Message-ID: On Wed, 27 Nov 2024 12:22:39 GMT, Amit Kumar wrote: >>> Also, between this instruction and the branch instruction, we are emitting `z_lg` and `z_lghi` instruction. So maybe just put a comment ? >> >> Yes, do that. I notice we do the same on AArch64, but I sort-of "know" that `macroAssembler::pop` preserves flags on aarch64 and x86. > > already updated :) > > for s390x, `pop_frame()` doesn't interfere with `cc` as it only uses `lg` instruction which doesn't change `cc`. But `push_frame()` can change `cc` as it uses `aghi` instruction to perform add operation. > But we can store the value in scratch register, maybe `Z_R0` and then move this check. Using a scratch register is just as opaque. You implicitly rely on the code in between to do no harm. For me, a comment helps to create awareness - if anyone reads it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1860891564 From lucy at openjdk.org Wed Nov 27 15:50:38 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Wed, 27 Nov 2024 15:50:38 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v4] In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 11:23:14 GMT, Amit Kumar wrote: >> s390x Port for : [JDK-8331341](https://bugs.openjdk.org/browse/JDK-8331341) >> >> Tier1 test: >> 1. `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` >> 2. No flag turn on. i.e. used `UseSecondarySupersCache` by default. >> 3. `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` with C1 compiler > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > updates comments Are there any performance figures? Does the change help, or at least do no harm, on s390? ------------- PR Review: https://git.openjdk.org/jdk/pull/22341#pullrequestreview-2465410184 From amitkumar at openjdk.org Wed Nov 27 15:55:37 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 27 Nov 2024 15:55:37 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v2] In-Reply-To: References: <7KoauAiezizx0i349hF5SS1kV0wnhG5XFaFH4Svoinc=.eff44468-82ff-4ac3-a0d4-0e48a699d960@github.com> Message-ID: On Wed, 27 Nov 2024 15:43:58 GMT, Lutz Schmidt wrote: >> already updated :) >> >> for s390x, `pop_frame()` doesn't interfere with `cc` as it only uses `lg` instruction which doesn't change `cc`. But `push_frame()` can change `cc` as it uses `aghi` instruction to perform add operation. > >> But we can store the value in scratch register, maybe `Z_R0` and then move this check. > > Using a scratch register is just as opaque. You implicitly rely on the code in between to do no harm. For me, a comment helps to create awareness - if anyone reads it. Oh, that wasn't even my worse suggestion ?. Another solution which I was thinking about was, passing `temp_reg` at place of `result_reg` then we can move that check down without any issue, because value wouldn't be altered. And `temp_reg` then will be allocated a new register from `RegSet`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22341#discussion_r1860906145 From amitkumar at openjdk.org Wed Nov 27 15:58:39 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 27 Nov 2024 15:58:39 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v4] In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 15:48:29 GMT, Lutz Schmidt wrote: > Are there any performance figures? Does the change help, or at least do no harm, on s390? I do but they don't look interesting. withpatch: Benchmark Mode Cnt Score Error Units SecondarySuperCacheInterContention.test avgt 15 10.488 ? 0.126 ns/op SecondarySuperCacheInterContention.test:t1 avgt 15 10.528 ? 0.181 ns/op SecondarySuperCacheInterContention.test:t2 avgt 15 10.448 ? 0.168 ns/op Finished running test 'micro:vm.compiler.SecondarySuperCacheInterContention' without patch: Benchmark Mode Cnt Score Error Units SecondarySuperCacheInterContention.test avgt 15 10.450 ? 0.154 ns/op SecondarySuperCacheInterContention.test:t1 avgt 15 10.451 ? 0.170 ns/op SecondarySuperCacheInterContention.test:t2 avgt 15 10.450 ? 0.207 ns/op Finished running test 'micro:vm.compiler.SecondarySuperCacheInterContention' ------------- PR Comment: https://git.openjdk.org/jdk/pull/22341#issuecomment-2504233607 From lucy at openjdk.org Wed Nov 27 16:07:40 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Wed, 27 Nov 2024 16:07:40 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v4] In-Reply-To: References: Message-ID: <08nIXwiaMTCcMmtMSL26SLYIAowUwgyXPS1z9REjF3Q=.95e1de94-ce49-4a64-826f-1a2a63ef6b44@github.com> On Wed, 27 Nov 2024 11:23:14 GMT, Amit Kumar wrote: >> s390x Port for : [JDK-8331341](https://bugs.openjdk.org/browse/JDK-8331341) >> >> Tier1 test: >> 1. `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` >> 2. No flag turn on. i.e. used `UseSecondarySupersCache` by default. >> 3. `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` with C1 compiler > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > updates comments LGTM. This is in no way an attempt to overrule theRealAph. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22341#pullrequestreview-2465451178 From lucy at openjdk.org Wed Nov 27 16:07:41 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Wed, 27 Nov 2024 16:07:41 GMT Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter [v4] In-Reply-To: References: Message-ID: <6Ahq-U8CmimPtLVINuuq5ATx4_ggQ9S17bXzhxJ52a4=.46e0c612-18bf-4a34-bb35-e17ba5ddf3bb@github.com> On Wed, 27 Nov 2024 15:55:55 GMT, Amit Kumar wrote: > I do but they don't look interesting. OK. No harm detected. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22341#issuecomment-2504251388 From alanb at openjdk.org Wed Nov 27 17:44:40 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 27 Nov 2024 17:44:40 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands [v2] In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 21:31:52 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager Permission references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove 'cause' Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22315#pullrequestreview-2465652474 From lmesnik at openjdk.org Wed Nov 27 17:52:38 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 27 Nov 2024 17:52:38 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands [v2] In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 21:31:52 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager Permission references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove 'cause' Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22315#pullrequestreview-2465666546 From cnorrbin at openjdk.org Wed Nov 27 18:03:34 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 27 Nov 2024 18:03:34 GMT Subject: RFR: 8345126: [BACKOUT] JDK-8318127: align_up has potential overflow Message-ID: Caused failures in testing. Backing out to fix without blocking tests. Clean `git revert` The failing 2 tests now pass again. ------------- Commit messages: - Revert "8318127: align_up has potential overflow" Changes: https://git.openjdk.org/jdk/pull/22419/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22419&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345126 Stats: 38 lines in 3 files changed: 0 ins; 33 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/22419.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22419/head:pull/22419 PR: https://git.openjdk.org/jdk/pull/22419 From iklam at openjdk.org Wed Nov 27 18:05:37 2024 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 27 Nov 2024 18:05:37 GMT Subject: RFR: 8345126: [BACKOUT] JDK-8318127: align_up has potential overflow In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 17:56:46 GMT, Casper Norrbin wrote: > Caused failures in testing. Backing out to fix without blocking tests. Clean `git revert` > > The failing 2 tests now pass again. LGTM and trivial. ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22419#pullrequestreview-2465691742 From amenkov at openjdk.org Wed Nov 27 18:57:37 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 27 Nov 2024 18:57:37 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 [v2] In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 05:20:16 GMT, David Holmes wrote: >> After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: >> >> #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} >> #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} >> #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} >> #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} >> #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} >> #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} >> >> are all singletons and so the actual strings can just be inlined directly into the code that uses them. >> >> Testing: >> - GHA >> - Tiers 1-4 sanity >> - >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/native/libjava/NativeLibraries.c > > Co-authored-by: Alex Menkov <69548902+alexmenkov at users.noreply.github.com> Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22380#pullrequestreview-2465773079 From cnorrbin at openjdk.org Wed Nov 27 19:53:45 2024 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 27 Nov 2024 19:53:45 GMT Subject: Integrated: 8345126: [BACKOUT] JDK-8318127: align_up has potential overflow In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 17:56:46 GMT, Casper Norrbin wrote: > Caused failures in testing. Backing out to fix without blocking tests. Clean `git revert` > > The failing 2 tests now pass again. This pull request has now been integrated. Changeset: 15378a78 Author: Casper Norrbin Committer: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/15378a785356bdf574e557633d36591f5cfc1610 Stats: 38 lines in 3 files changed: 0 ins; 33 del; 5 mod 8345126: [BACKOUT] JDK-8318127: align_up has potential overflow Reviewed-by: iklam ------------- PR: https://git.openjdk.org/jdk/pull/22419 From vlivanov at openjdk.org Wed Nov 27 20:01:43 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 27 Nov 2024 20:01:43 GMT Subject: RFR: 8344355: Register corruption in MacroAssembler::lookup_secondary_supers_table_var: x86-64 only [v2] In-Reply-To: <6l0Fu7HKb2v9-HKGDEb0uBqMbaVduoY2i03kMxnChgc=.c0e2a2aa-3de4-4917-aee1-1c22963f53ca@github.com> References: <3aaeGz7V4yLsAIeSA4ZuTr5isbsusslvk7Qftf7jiI4=.54e563e5-1319-49e0-905e-ed5159157c5e@github.com> <6l0Fu7HKb2v9-HKGDEb0uBqMbaVduoY2i03kMxnChgc=.c0e2a2aa-3de4-4917-aee1-1c22963f53ca@github.com> Message-ID: On Wed, 27 Nov 2024 10:10:41 GMT, Andrew Haley wrote: >> Doesn't `-XX:UseSSE=2` achieve exactly that on x86-64? > >> Doesn't `-XX:UseSSE=2` achieve exactly that on x86-64? > > Mmm, but x86 so many overlapping architecture changes over the years it's impossible to test every combination of them. > > What would be good, though, would be to run tests on whatever the minimum architecture is that we support. I don't think we have any equivalent of what GCC calls -march=x86-64, "a generic CPU with 64-bit extensions", but it looks like -XX:UseSSE=2 means Opteron aka k8, which "supersets MMX, SSE, SSE2, 3DNow!, and enhanced 3DNow!" and is our minimum CPU. It's definitely not ideal. And the main limitation of VM flag-only solution is that it can't catch bugs when unsupported instructions are issued (ISA capability checks being too lax). So, can't fully substitute testing on a real hardware, but getting pretty close IMO. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22365#discussion_r1861188293 From dean.long at oracle.com Wed Nov 27 20:13:50 2024 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 27 Nov 2024 12:13:50 -0800 Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas In-Reply-To: References: Message-ID: <8ff05179-5f1e-421a-b1c0-063e55ff8616@oracle.com> Vote: yes On 11/27/24 3:26 AM, Stefan Karlsson wrote: > I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot > Group. > > Axel is a member of Oracle's HotSpot GC team and has been contributing > to various parts of the JVM for over two years now. > > Votes are due by 2024-12-11T12:24+01:00. > > Only current Members of the HotSpot Group [1] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] https://openjdk.org/census > [2] https://openjdk.org/groups/#member-vote From phh at openjdk.org Wed Nov 27 23:09:05 2024 From: phh at openjdk.org (Paul Hohensee) Date: Wed, 27 Nov 2024 23:09:05 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v11] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 26 Nov 2024 00:37:32 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - 8344985: GenShen: Refactor arraycopy barrier for generational mode > > Reviewed-by: shade Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2466068316 From liach at openjdk.org Wed Nov 27 23:19:23 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 27 Nov 2024 23:19:23 GMT Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after JDK-83324714 Message-ID: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests. The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself. Now there is fewer than 100 `@enablePreview` in the `test` directory. To reviewers, there are some redundant changes and notes: - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API. - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are: - `BoundAttribute::payloadLen` for javac attribute tests - Annotation reading/writing for javac annotation tests - Line number changes to: - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java - Move from legacy jdk.internal.classfile to java.lang.classfile in: - test/langtools/tools/javac/NoStringToLower.java and - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview. Testing: did a quick tier 1-2 locally, waiting for CI on tier 1-3. Please inform me if any of these tests belong to higher tiers. ------------- Commit messages: - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714 Changes: https://git.openjdk.org/jdk/pull/22420/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22420&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334733 Stats: 635 lines in 360 files changed: 2 ins; 556 del; 77 mod Patch: https://git.openjdk.org/jdk/pull/22420.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22420/head:pull/22420 PR: https://git.openjdk.org/jdk/pull/22420 From mikael.vidstedt at oracle.com Thu Nov 28 00:09:00 2024 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 28 Nov 2024 00:09:00 +0000 Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas In-Reply-To: References: Message-ID: Vote: yes Cheers, Mikael > On Nov 27, 2024, at 3:26?AM, Stefan Karlsson wrote: > > I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot Group. > > Axel is a member of Oracle's HotSpot GC team and has been contributing to various parts of the JVM for over two years now. > > Votes are due by 2024-12-11T12:24+01:00. > > Only current Members of the HotSpot Group [1] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] https://openjdk.org/census > [2] https://openjdk.org/groups/#member-vote From fyang at openjdk.org Thu Nov 28 00:22:54 2024 From: fyang at openjdk.org (Fei Yang) Date: Thu, 28 Nov 2024 00:22:54 GMT Subject: RFR: 8345110: RISC-V: Optimize and and clean up byte reverse assembler routine Message-ID: Hi, Could you please help review this change? MacroAssembler routines `revb_w` and `revb_w_w` will emit 32 and 17 instructions respectively without Zbb. Major changes: 1. There is no need for `revb_w` to reverse bytes for each 32-bit word. All the callers only care about the lower 32-bit word. This reimplement `revb_w` so that it only reverses bytes in lower 32-bit word and sign-extends the result (14 instructions). This makes `revb_w_w` duplicate. 2. Removed some assembler routines that are unused or become unnecessary (`revb_h`, `revb_h_helper`, `revb_h_h`, `revb_w_w`). 3. Adapted callers of these removed assembler routines in file `riscv_b.ad` to emit Zbb instructions directly. Will look into `revb_h_h_u` and `revb_h_w_u` after this change. Testing on linux-riscv64 platform: - [ ] tier1 (release) ------------- Commit messages: - 8345110: RISC-V: Optimize and and clean up byte reverse assembler routine Changes: https://git.openjdk.org/jdk/pull/22410/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22410&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345110 Stats: 122 lines in 4 files changed: 23 ins; 77 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/22410.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22410/head:pull/22410 PR: https://git.openjdk.org/jdk/pull/22410 From david.holmes at oracle.com Thu Nov 28 01:45:31 2024 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Nov 2024 11:45:31 +1000 Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas In-Reply-To: References: Message-ID: <0a41dcd7-1157-4dbf-a82d-72fb94d82a78@oracle.com> Vote: yes David On 27/11/2024 9:26 pm, Stefan Karlsson wrote: > I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot > Group. > > Axel is a member of Oracle's HotSpot GC team and has been contributing > to various parts of the JVM for over two years now. > > Votes are due by 2024-12-11T12:24+01:00. > > Only current Members of the HotSpot Group [1] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] https://openjdk.org/census > [2] https://openjdk.org/groups/#member-vote From kbarrett at openjdk.org Thu Nov 28 01:56:38 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 28 Nov 2024 01:56:38 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 [v2] In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 05:20:16 GMT, David Holmes wrote: >> After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: >> >> #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} >> #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} >> #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} >> #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} >> #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} >> #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} >> >> are all singletons and so the actual strings can just be inlined directly into the code that uses them. >> >> Testing: >> - GHA >> - Tiers 1-4 sanity >> - >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/native/libjava/NativeLibraries.c > > Co-authored-by: Alex Menkov <69548902+alexmenkov at users.noreply.github.com> Changes requested by kbarrett (Reviewer). src/java.base/share/native/libjava/NativeLibraries.c line 88: > 86: if (cname != NULL) { > 87: strcat(jniFunctionName, "_"); > 88: strcat(jniFunctionName, cname); Should be using 4-space indentation, rather than HotSpot's 2 space indentation. ------------- PR Review: https://git.openjdk.org/jdk/pull/22380#pullrequestreview-2466185432 PR Review Comment: https://git.openjdk.org/jdk/pull/22380#discussion_r1861413410 From amitkumar at openjdk.org Thu Nov 28 02:08:44 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 28 Nov 2024 02:08:44 GMT Subject: Integrated: 8340731: Cleanup remaining IA64 references in hotspot code In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 06:52:51 GMT, Amit Kumar wrote: > This PR cleans up `IA64` entries form hotspot codebase. > > As mentioned in the JBS, I left `zero` component as-it-is: > > ./cpu/zero/bytecodeInterpreter_zero.hpp:31:#if defined(PPC) || defined(IA64) > ./os_cpu/linux_zero/os_linux_zero.cpp:350:#ifdef IA64 > ./os_cpu/linux_zero/os_linux_zero.cpp:351: // IA64 has two stacks sharing the same area of memory, a normal > ./os_cpu/linux_zero/os_linux_zero.cpp:360:#endif // IA64 > > > Fastdebug VM Build on Mac-M1 & Linux/s390x is fine. Tests are in progress. This pull request has now been integrated. Changeset: a0df0a52 Author: Amit Kumar URL: https://git.openjdk.org/jdk/commit/a0df0a527fc3a6954fc08651947a5cfe1455e652 Stats: 85 lines in 17 files changed: 4 ins; 60 del; 21 mod 8340731: Cleanup remaining IA64 references in hotspot code Reviewed-by: dholmes, aph ------------- PR: https://git.openjdk.org/jdk/pull/22382 From amitkumar at openjdk.org Thu Nov 28 02:08:44 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 28 Nov 2024 02:08:44 GMT Subject: RFR: 8340731: Cleanup remaining IA64 references in hotspot code [v5] In-Reply-To: <6JUM4Qd7FTHeoUFvkukajaSBR9hReqI1FWcKTgMoZ-I=.66202c29-1664-4221-be41-5fa17c0f7292@github.com> References: <6JUM4Qd7FTHeoUFvkukajaSBR9hReqI1FWcKTgMoZ-I=.66202c29-1664-4221-be41-5fa17c0f7292@github.com> Message-ID: On Wed, 27 Nov 2024 06:42:19 GMT, Amit Kumar wrote: >> This PR cleans up `IA64` entries form hotspot codebase. >> >> As mentioned in the JBS, I left `zero` component as-it-is: >> >> ./cpu/zero/bytecodeInterpreter_zero.hpp:31:#if defined(PPC) || defined(IA64) >> ./os_cpu/linux_zero/os_linux_zero.cpp:350:#ifdef IA64 >> ./os_cpu/linux_zero/os_linux_zero.cpp:351: // IA64 has two stacks sharing the same area of memory, a normal >> ./os_cpu/linux_zero/os_linux_zero.cpp:360:#endif // IA64 >> >> >> Fastdebug VM Build on Mac-M1 & Linux/s390x is fine. Tests are in progress. > > Amit Kumar has updated the pull request incrementally with one additional commit since the last revision: > > adds portion of comment back all GHA test passed. Look like we are good to go. Thanks for the reviews Andrew, David. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22382#issuecomment-2505121505 From dholmes at openjdk.org Thu Nov 28 02:21:55 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 28 Nov 2024 02:21:55 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 [v3] In-Reply-To: References: Message-ID: > After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: > > #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} > #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} > #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} > #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} > #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} > #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} > > are all singletons and so the actual strings can just be inlined directly into the code that uses them. > > Testing: > - GHA > - Tiers 1-4 sanity > - > Thanks David Holmes has updated the pull request incrementally with two additional commits since the last revision: - Merge branch '8343703-jni-symbol' of github.com:dholmes-ora/jdk into 8343703-jni-symbol - Fix indent ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22380/files - new: https://git.openjdk.org/jdk/pull/22380/files/c38bb48f..64ecc3b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22380&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22380&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/22380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22380/head:pull/22380 PR: https://git.openjdk.org/jdk/pull/22380 From dholmes at openjdk.org Thu Nov 28 02:21:55 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 28 Nov 2024 02:21:55 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 [v2] In-Reply-To: References: Message-ID: On Thu, 28 Nov 2024 01:54:10 GMT, Kim Barrett wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.base/share/native/libjava/NativeLibraries.c >> >> Co-authored-by: Alex Menkov <69548902+alexmenkov at users.noreply.github.com> > > src/java.base/share/native/libjava/NativeLibraries.c line 88: > >> 86: if (cname != NULL) { >> 87: strcat(jniFunctionName, "_"); >> 88: strcat(jniFunctionName, cname); > > Should be using 4-space indentation, rather than HotSpot's 2 space indentation. Good catch! Thanks for reviewing Kim. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22380#discussion_r1861426578 From kbarrett at openjdk.org Thu Nov 28 02:27:46 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 28 Nov 2024 02:27:46 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 [v3] In-Reply-To: References: Message-ID: On Thu, 28 Nov 2024 02:21:55 GMT, David Holmes wrote: >> After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: >> >> #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} >> #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} >> #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} >> #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} >> #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} >> #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} >> >> are all singletons and so the actual strings can just be inlined directly into the code that uses them. >> >> Testing: >> - GHA >> - Tiers 1-4 sanity >> - >> Thanks > > David Holmes has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch '8343703-jni-symbol' of github.com:dholmes-ora/jdk into 8343703-jni-symbol > - Fix indent Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22380#pullrequestreview-2466212066 From dholmes at openjdk.org Thu Nov 28 02:27:46 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 28 Nov 2024 02:27:46 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 [v3] In-Reply-To: References: Message-ID: On Thu, 28 Nov 2024 02:21:55 GMT, David Holmes wrote: >> After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: >> >> #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} >> #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} >> #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} >> #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} >> #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} >> #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} >> >> are all singletons and so the actual strings can just be inlined directly into the code that uses them. >> >> Testing: >> - GHA >> - Tiers 1-4 sanity >> - >> Thanks > > David Holmes has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch '8343703-jni-symbol' of github.com:dholmes-ora/jdk into 8343703-jni-symbol > - Fix indent Thanks Kim! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22380#issuecomment-2505139073 From dholmes at openjdk.org Thu Nov 28 02:27:47 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 28 Nov 2024 02:27:47 GMT Subject: Integrated: 8343703: Symbol name cleanups after JEP 479 In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 06:36:44 GMT, David Holmes wrote: > After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: > > #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} > #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} > #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} > #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} > #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} > #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} > > are all singletons and so the actual strings can just be inlined directly into the code that uses them. > > Testing: > - GHA > - Tiers 1-4 sanity > - > Thanks This pull request has now been integrated. Changeset: 1a07d542 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/1a07d542ec810282eb78653698d098a24b35686f Stats: 95 lines in 5 files changed: 7 ins; 49 del; 39 mod 8343703: Symbol name cleanups after JEP 479 Reviewed-by: kbarrett, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/22380 From dholmes at openjdk.org Thu Nov 28 02:52:41 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 28 Nov 2024 02:52:41 GMT Subject: RFR: 8345043: [ASAN] methodMatcher.cpp report reading from a region of size 0 [-Werror=stringop-overread] [v2] In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 15:20:24 GMT, SendaoYan wrote: >> Hi all, >> The file src/hotspot/share/compiler/methodMatcher.cpp report compile warning by gcc14 with -fsanitize=undefined -fsanitize=address `?size_t strlen(const char*)? reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]`. I think it's false positive, the `if (name[0] == '*')` and `if (strlen(name) == 1)` judgement has make sure that the length of name greater or equal to 2, but the static analyze at compile time is unable to identify that. >> So this PR change `strlen(name + 1) + 1` to `strlen(name)` to dodge gcc warning. Risk is low. >> >> Additional testing: >> >> - [ ] jtreg tests(include tier1/2/3 etc.) by linux-x64 release build >> - [ ] jtreg tests(include tier1/2/3 etc.) by linux-aarch64 release build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > combine the calacution of stelen That seems much cleaner to me too! Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22406#pullrequestreview-2466232824 From tobias.hartmann at oracle.com Thu Nov 28 06:28:00 2024 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 28 Nov 2024 07:28:00 +0100 Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas In-Reply-To: References: Message-ID: Vote: yes Best regards, Tobias On 11/27/24 12:26, Stefan Karlsson wrote: > I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot Group. > > Axel is a member of Oracle's HotSpot GC team and has been contributing to various parts of the JVM for over two years now. > > Votes are due by 2024-12-11T12:24+01:00. > > Only current Members of the HotSpot Group [1] are eligible > to vote on this nomination.? Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] https://openjdk.org/census > [2] https://openjdk.org/groups/#member-vote From duke at openjdk.org Thu Nov 28 07:11:52 2024 From: duke at openjdk.org (Manjunath S Matti.) Date: Thu, 28 Nov 2024 07:11:52 GMT Subject: RFR: 8335367: [s390] Add support for load immediate on condition instructions. [v2] In-Reply-To: <2oJIrDqMf4MYKGz_s1K8D2aNjGwJJ75PY-gUOZwVEU0=.af1d8092-a680-4ea2-adf7-a9c3432509a3@github.com> References: <2oJIrDqMf4MYKGz_s1K8D2aNjGwJJ75PY-gUOZwVEU0=.af1d8092-a680-4ea2-adf7-a9c3432509a3@github.com> Message-ID: > Add support for load immediate on condition instructions. Manjunath S Matti. has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/cpu/s390/assembler_s390.hpp Update the comments as suggested by Amit Kumar Co-authored-by: Amit Kumar ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22058/files - new: https://git.openjdk.org/jdk/pull/22058/files/c1e13655..31709a7d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22058&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22058&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22058.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22058/head:pull/22058 PR: https://git.openjdk.org/jdk/pull/22058 From asotona at openjdk.org Thu Nov 28 07:16:40 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 28 Nov 2024 07:16:40 GMT Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after JDK-83324714 In-Reply-To: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com> References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com> Message-ID: <-obkcdGi1-P2yLOYnCFIDo6z_ldLIDE90jbM847BRAU=.87b21383-ded7-4296-8d85-8b256dce0980@github.com> On Wed, 27 Nov 2024 23:10:15 GMT, Chen Liang wrote: > Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests. The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself. Now there is fewer than 100 `@enablePreview` in the `test` directory. > > To reviewers, there are some redundant changes and notes: > > - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API. > - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are: > - `BoundAttribute::payloadLen` for javac attribute tests > - Annotation reading/writing for javac annotation tests > - Line number changes to: > - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java > - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java > - Move from legacy jdk.internal.classfile to java.lang.classfile in: > - test/langtools/tools/javac/NoStringToLower.java and > - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java > - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java > > - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview. > > Testing: tier 1-5. Please inform me if any of these tests belong to higher tiers. I would give a go to all trivial removals of `@enablePreview` after a brief check the tests pass. However all the more complex changes potentially affecting various parts of the JDK infrastructure require deeper review and probably involve more reviewers. My recommendation for easier review would be to split this 360-files patch into a patch with trivial removals of `@enablePreview` and one or more patches focused on particular area. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22420#issuecomment-2505408069 From liach at openjdk.org Thu Nov 28 07:47:37 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 28 Nov 2024 07:47:37 GMT Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after JDK-83324714 In-Reply-To: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com> References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com> Message-ID: On Wed, 27 Nov 2024 23:10:15 GMT, Chen Liang wrote: > Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests. The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself. Now there is fewer than 100 `@enablePreview` in the `test` directory. > > To reviewers, there are some redundant changes and notes: > > - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API. > - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are: > - `BoundAttribute::payloadLen` for javac attribute tests > - Annotation reading/writing for javac annotation tests > - Line number changes to: > - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java > - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java > - Move from legacy jdk.internal.classfile to java.lang.classfile in: > - test/langtools/tools/javac/NoStringToLower.java and > - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java > - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java > > - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview. > > Testing: tier 1-5. Please inform me if any of these tests belong to higher tiers. I think the simple removal of `@enablePreview` already require multiple areas of engineers, so to involve a bit more changes to fix them throughoutly is fine; these are all test-only, so we can wait and this can go in after RDP1 began. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22420#issuecomment-2505451198 From richard.reingruber at sap.com Thu Nov 28 08:30:58 2024 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Thu, 28 Nov 2024 08:30:58 +0000 Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas In-Reply-To: References: Message-ID: Vote: yes Richard. From: hotspot-dev on behalf of Stefan Karlsson Date: Wednesday, 27. November 2024 at 12:27 To: hotspot-dev at openjdk.org Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot Group. Axel is a member of Oracle's HotSpot GC team and has been contributing to various parts of the JVM for over two years now. Votes are due by 2024-12-11T12:24+01:00. Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [2]. Stefan Karlsson [1] https://openjdk.org/census [2] https://openjdk.org/groups/#member-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From syan at openjdk.org Thu Nov 28 09:09:47 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 28 Nov 2024 09:09:47 GMT Subject: RFR: 8345043: [ASAN] methodMatcher.cpp report reading from a region of size 0 [-Werror=stringop-overread] [v2] In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 15:20:24 GMT, SendaoYan wrote: >> Hi all, >> The file src/hotspot/share/compiler/methodMatcher.cpp report compile warning by gcc14 with -fsanitize=undefined -fsanitize=address `?size_t strlen(const char*)? reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]`. I think it's false positive, the `if (name[0] == '*')` and `if (strlen(name) == 1)` judgement has make sure that the length of name greater or equal to 2, but the static analyze at compile time is unable to identify that. >> So this PR change `strlen(name + 1) + 1` to `strlen(name)` to dodge gcc warning. Risk is low. >> >> Additional testing: >> >> - [x] jtreg tests(include tier1/2/3 etc.) by linux-x64 release build >> - [x] jtreg tests(include tier1/2/3 etc.) by linux-aarch64 release build > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > combine the calacution of stelen Thanks all for the advice and review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22406#issuecomment-2505597589 From syan at openjdk.org Thu Nov 28 09:09:48 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 28 Nov 2024 09:09:48 GMT Subject: Integrated: 8345043: [ASAN] methodMatcher.cpp report reading from a region of size 0 [-Werror=stringop-overread] In-Reply-To: References: Message-ID: <-r2Sfkt6HtYF6RvD--tm6U4S0kIe0K2kNsQCNwZMLbQ=.6341c2e8-6be2-4563-b9a4-42b2325a2b4f@github.com> On Wed, 27 Nov 2024 07:48:00 GMT, SendaoYan wrote: > Hi all, > The file src/hotspot/share/compiler/methodMatcher.cpp report compile warning by gcc14 with -fsanitize=undefined -fsanitize=address `?size_t strlen(const char*)? reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]`. I think it's false positive, the `if (name[0] == '*')` and `if (strlen(name) == 1)` judgement has make sure that the length of name greater or equal to 2, but the static analyze at compile time is unable to identify that. > So this PR change `strlen(name + 1) + 1` to `strlen(name)` to dodge gcc warning. Risk is low. > > Additional testing: > > - [x] jtreg tests(include tier1/2/3 etc.) by linux-x64 release build > - [x] jtreg tests(include tier1/2/3 etc.) by linux-aarch64 release build This pull request has now been integrated. Changeset: e096660a Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/e096660a18905bf1394d722790c5c3883e55dedc Stats: 6 lines in 1 file changed: 2 ins; 1 del; 3 mod 8345043: [ASAN] methodMatcher.cpp report reading from a region of size 0 [-Werror=stringop-overread] Reviewed-by: kbarrett, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/22406 From mli at openjdk.org Thu Nov 28 09:50:37 2024 From: mli at openjdk.org (Hamlin Li) Date: Thu, 28 Nov 2024 09:50:37 GMT Subject: RFR: 8345110: RISC-V: Optimize and and clean up byte reverse assembler routines In-Reply-To: References: Message-ID: <1ijnwTDZNecZMX64HDgeFk32nZK8UPXyNrrYBtV6qbY=.b98e1228-7818-4876-a868-28ce6f52d15a@github.com> On Wed, 27 Nov 2024 12:28:40 GMT, Fei Yang wrote: > Hi, Could you please help review this change? > > MacroAssembler routines `revb_w` and `revb_w_w` will emit 32 and 17 instructions respectively without Zbb. > > Major changes: > 1. There is no need for `revb_w` to reverse bytes for each 32-bit word in the 64-bit register. > All the callers only care about the lower 32-bit word. This reimplement `revb_w` so that it only > reverses bytes in lower 32-bit word and sign-extends the result (14 instructions). This makes `revb_w_w` duplicate. > 2. Removed some assembler routines that are unused or become unnecessary (`revb_h`, `revb_h_helper`, `revb_h_h`, `revb_w_w`). > 3. Adapted callers of these removed assembler routines in file `riscv_b.ad` to emit Zbb instructions directly. > > Will look into `revb_h_h_u` and `revb_h_w_u` after this change. Seems to me they could be factored out as well. > > Testing on linux-riscv64 platform: > - [x] tier1 (release) > - [x] hotspot:tier1 (fastdebug) > - [x] non-trivial benchmark workloads like Dacapo, SpecJBB, Renaissance (release) Thanks for cleanup! Not sure if I understand correctly, just have some questions, in upstream code at [1] [2], seems they both not expect a signed-extending? [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/templateTable_riscv.cpp#L1935 // set counter __ lwu(x11, Address(x9, BytesPerInt)); __ revb_w(x11, x11); __ j(loop_entry); // table search __ bind(loop); __ shadd(t0, x11, x9, t0, 3); [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/templateTable_riscv.cpp#L2009 // Initialize i & j __ mv(i, zr); // i = 0 __ lwu(j, Address(array, -BytesPerInt)); // j = length(array) // Convert j into native byteordering __ revb_w(j, j); ------------- PR Review: https://git.openjdk.org/jdk/pull/22410#pullrequestreview-2467411571 From kevinw at openjdk.org Thu Nov 28 09:57:42 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 28 Nov 2024 09:57:42 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands [v2] In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 21:31:52 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager Permission references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove 'cause' Thanks for all the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22315#issuecomment-2505697101 From kevinw at openjdk.org Thu Nov 28 09:57:42 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 28 Nov 2024 09:57:42 GMT Subject: Integrated: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 09:14:30 GMT, Kevin Walls wrote: > Remove redundant SecurityManager Permission references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). This pull request has now been integrated. Changeset: d33ad07c Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/d33ad07c32f23aee799750c9964ab26d0cbe56f4 Stats: 396 lines in 17 files changed: 0 ins; 380 del; 16 mod 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands Reviewed-by: lmesnik, alanb, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/22315 From alanb at openjdk.org Thu Nov 28 10:25:18 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 28 Nov 2024 10:25:18 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands Message-ID: Adds `jcmd Thread.vthread_scheduler` to print the virtual thread scheduler and `jcmd Thread.vthread_pollers` to print the I/O pollers that support virtual threads doing blocking network I/O operations. This is a subset of the diagnostics that we've had in the loom repo for a long time. @larry-cable proposed a PR recently ([pull/22121](https://github.com/openjdk/jdk/pull/22121)) to bring a version of same into main line but it was based on an older proposal. This new PR supplants that effort. The jtreg failure handler is updated to execute Thread.vthread_scheduler, useful capture when a test fails or times out. ------------- Commit messages: - Improve vthread_pollers output - Merge branch 'master' into JDK-8337199 - Initial commit Changes: https://git.openjdk.org/jdk/pull/22414/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22414&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337199 Stats: 405 lines in 11 files changed: 400 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22414.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22414/head:pull/22414 PR: https://git.openjdk.org/jdk/pull/22414 From liach at openjdk.org Thu Nov 28 10:25:18 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 28 Nov 2024 10:25:18 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands In-Reply-To: References: Message-ID: <7KzZ2pke6ZA4kpWBvLEXsAd1p2KflLWHZ0Jgq5uCC-M=.7abe6b24-fdad-4846-abdc-f75da15f06be@github.com> On Wed, 27 Nov 2024 15:59:17 GMT, Alan Bateman wrote: > Adds `jcmd Thread.vthread_scheduler` to print the virtual thread scheduler and `jcmd Thread.vthread_pollers` to print the I/O pollers that support virtual threads doing blocking network I/O operations. > > This is a subset of the diagnostics that we've had in the loom repo for a long time. @larry-cable proposed a PR recently ([pull/22121](https://github.com/openjdk/jdk/pull/22121)) to bring a version of same into main line but it was based on an older proposal. This new PR supplants that effort. > > The jtreg failure handler is updated to execute Thread.vthread_scheduler, useful capture when a test fails or times out. test/hotspot/jtreg/serviceability/dcmd/thread/VThreadCommandsTest.java line 2: > 1: /* > 2: * Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. test/hotspot/jtreg/serviceability/dcmd/thread/VThreadCommandsTest.java line 62: > 60: @Test > 61: void testVThreadScheduler() { > 62: // ensure default scheduler are timeout schedulers are initialized Suggestion: // ensure default scheduler and timeout schedulers are initialized test/hotspot/jtreg/serviceability/dcmd/thread/VThreadCommandsTest.java line 96: > 94: .shouldContain("Read I/O pollers:") > 95: .shouldContain("Write I/O pollers:") > 96: .shouldContain("[0] sun.nio.ch"); Suggestion: .shouldContain("[0] sun.nio.ch."); As unlikely as this is, I recommend always use a trailing separator for package names - there are corner cases like `java.lang.ref` vs `java.lang.reflect` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22414#discussion_r1861358889 PR Review Comment: https://git.openjdk.org/jdk/pull/22414#discussion_r1861358950 PR Review Comment: https://git.openjdk.org/jdk/pull/22414#discussion_r1861359883 From alanb at openjdk.org Thu Nov 28 10:25:18 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 28 Nov 2024 10:25:18 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands In-Reply-To: <7KzZ2pke6ZA4kpWBvLEXsAd1p2KflLWHZ0Jgq5uCC-M=.7abe6b24-fdad-4846-abdc-f75da15f06be@github.com> References: <7KzZ2pke6ZA4kpWBvLEXsAd1p2KflLWHZ0Jgq5uCC-M=.7abe6b24-fdad-4846-abdc-f75da15f06be@github.com> Message-ID: On Thu, 28 Nov 2024 00:04:53 GMT, Chen Liang wrote: >> Adds `jcmd Thread.vthread_scheduler` to print the virtual thread scheduler and `jcmd Thread.vthread_pollers` to print the I/O pollers that support virtual threads doing blocking network I/O operations. >> >> This is a subset of the diagnostics that we've had in the loom repo for a long time. @larry-cable proposed a PR recently ([pull/22121](https://github.com/openjdk/jdk/pull/22121)) to bring a version of same into main line but it was based on an older proposal. This new PR supplants that effort. >> >> The jtreg failure handler is updated to execute Thread.vthread_scheduler, useful capture when a test fails or times out. > > test/hotspot/jtreg/serviceability/dcmd/thread/VThreadCommandsTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved. > > Suggestion: > > * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. The feature + test were initially created in Oct 2023. It might look like a new test for main line but I think we are supposed to keep the original creation date. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22414#discussion_r1861620057 From mdoerr at openjdk.org Thu Nov 28 11:26:46 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 28 Nov 2024 11:26:46 GMT Subject: RFR: 8345146: [PPC64] Make intrinsic conversions between bit representations of half precision values and floats Message-ID: PPC64 implementation of [JDK-8289552](https://bugs.openjdk.org/browse/JDK-8289552). I've implemented some more instructions which may be useful in the future. ------------- Commit messages: - 8345146: [PPC64] Make intrinsic conversions between bit representations of half precision values and floats Changes: https://git.openjdk.org/jdk/pull/22433/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22433&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345146 Stats: 180 lines in 15 files changed: 177 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22433.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22433/head:pull/22433 PR: https://git.openjdk.org/jdk/pull/22433 From rehn at openjdk.org Thu Nov 28 12:00:55 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 28 Nov 2024 12:00:55 GMT Subject: RFR: 8345110: RISC-V: Optimize and and clean up byte reverse assembler routines In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 12:28:40 GMT, Fei Yang wrote: > Hi, Could you please help review this change? > > MacroAssembler routines `revb_w` and `revb_w_w` will emit 32 and 17 instructions respectively without Zbb. > > Major changes: > 1. There is no need for `revb_w` to reverse bytes for each 32-bit word in the 64-bit register. > All the callers only care about the lower 32-bit word. This reimplement `revb_w` so that it only > reverses bytes in lower 32-bit word and sign-extends the result (14 instructions). This makes `revb_w_w` duplicate. > 2. Removed some assembler routines that are unused or become unnecessary (`revb_h`, `revb_h_helper`, `revb_h_h`, `revb_w_w`). > 3. Adapted callers of these removed assembler routines in file `riscv_b.ad` to emit Zbb instructions directly. > > Will look into `revb_h_h_u` and `revb_h_w_u` after this change. Seems to me they could be factored out as well. > > Testing on linux-riscv64 platform: > - [x] tier1 (release) > - [x] hotspot:tier1 (fastdebug) > - [x] non-trivial benchmark workloads like Dacapo, SpecJBB, Renaissance (release) Thanks! I liked that you used rev8 directly in AD because it makes it very clear that we do not clobber t1. (as it otherwise it is one of the default registers) As all uses of revb_w use dst == src, please consider a helper version which only needs one registers passed. I.e. "__ revb_w(temp);" ------------- Marked as reviewed by rehn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22410#pullrequestreview-2467916836 From rehn at openjdk.org Thu Nov 28 12:08:48 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 28 Nov 2024 12:08:48 GMT Subject: Integrated: 8344306: RISC-V: Add zicond In-Reply-To: References: Message-ID: <07pJ2wn8O09yrMm4Lxh0sGaF1RFryWoMAhjsFONAxV8=.0ea4455e-13b0-4daa-97a6-046feaf90dd9@github.com> On Tue, 26 Nov 2024 09:00:34 GMT, Robbin Ehn wrote: > Hi, please consider. > > In cpu models we save ~1 cycle per removed branch. > This patch removes ~0.1% of branches in generic C2 generated code. > We should probably investigate if we can improve/add peephole optimization to remove more branches. > > As the C1 cmov code is a bit tricky I left that as a followup. > > I added gtests for the cmovs. > (we should add coverage for more of masm in this gtest suit) > Pro tip, invoke the gtestLauncher directly (you only need to build exploded): > `gtestLauncher -jdk build/linux-riscv64-server-fastdebug/jdk/ --gtest_break_on_failure --gtest_filter="*RiscV*" -XX:+UnlockDiagnosticVMOptions -XX:+UseZicond -XX:ParallelGCThreads=1 -XX:ConcGCThreads=1 -XX:CICompilerCount=2` > > Tested on Spacemit X60, gtests and tier1. > > Thanks, Robbin This pull request has now been integrated. Changeset: edfe2854 Author: Robbin Ehn URL: https://git.openjdk.org/jdk/commit/edfe28541a6ed94357f873aa69778c7eba707cbb Stats: 345 lines in 10 files changed: 340 ins; 1 del; 4 mod 8344306: RISC-V: Add zicond Reviewed-by: fyang, luhenry, mli ------------- PR: https://git.openjdk.org/jdk/pull/22386 From mdoerr at openjdk.org Thu Nov 28 12:30:23 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 28 Nov 2024 12:30:23 GMT Subject: RFR: 8345146: [PPC64] Make intrinsic conversions between bit representations of half precision values and floats [v2] In-Reply-To: References: Message-ID: > PPC64 implementation of [JDK-8289552](https://bugs.openjdk.org/browse/JDK-8289552). I've implemented some more instructions which may be useful in the future. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Indentation. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22433/files - new: https://git.openjdk.org/jdk/pull/22433/files/b3960683..02e54629 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22433&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22433&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22433.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22433/head:pull/22433 PR: https://git.openjdk.org/jdk/pull/22433 From fyang at openjdk.org Thu Nov 28 13:21:38 2024 From: fyang at openjdk.org (Fei Yang) Date: Thu, 28 Nov 2024 13:21:38 GMT Subject: RFR: 8345110: RISC-V: Optimize and and clean up byte reverse assembler routines In-Reply-To: <1ijnwTDZNecZMX64HDgeFk32nZK8UPXyNrrYBtV6qbY=.b98e1228-7818-4876-a868-28ce6f52d15a@github.com> References: <1ijnwTDZNecZMX64HDgeFk32nZK8UPXyNrrYBtV6qbY=.b98e1228-7818-4876-a868-28ce6f52d15a@github.com> Message-ID: On Thu, 28 Nov 2024 09:47:51 GMT, Hamlin Li wrote: > Thanks for cleanup! Not sure if I understand correctly, just have some questions, in upstream code at [1] [2], seems they both not expect a signed-extending? Sorry, I should have explained that in the PR description. For these two use cases, we are are loading the 32-bit `npairs` of bytecode `lookupswitch` which are specified to be greater than or equal to 0 by the JVMS [1]. So there is no difference whether we use sign-extension or zero-extension. Hope that answers the question :-) [1] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.lookupswitch ------------- PR Comment: https://git.openjdk.org/jdk/pull/22410#issuecomment-2506110261 From fyang at openjdk.org Thu Nov 28 13:50:39 2024 From: fyang at openjdk.org (Fei Yang) Date: Thu, 28 Nov 2024 13:50:39 GMT Subject: RFR: 8345110: RISC-V: Optimize and and clean up byte reverse assembler routines In-Reply-To: References: Message-ID: On Thu, 28 Nov 2024 11:58:30 GMT, Robbin Ehn wrote: > I liked that you used rev8 directly in AD because it makes it very clear that we do not clobber t1. (as it otherwise it is one of the default registers) Yeah. Great! > As all uses of revb_w use dst == src, please consider a helper version which only needs one registers passed. I.e. "__ revb_w(temp);" Thanks for the suggestion! Personally, I prefer to follow the mnemonics as specified by the riscv spec (like `rev8 rd, rs`) for all places to be consistent in style. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22410#issuecomment-2506169653 From rehn at openjdk.org Thu Nov 28 14:03:48 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 28 Nov 2024 14:03:48 GMT Subject: RFR: 8345177: RISC-V: Add gtests for cmpxchg Message-ID: Hi, please consider. This adds some of the base cases. Focusing on the cases when we pass in same register in some of the argument. (variant 0,1,2,3) Note: Google Test filter = *RiscV.cmpxchg* [==========] Running 4 tests from 1 test suite. [----------] Global test environment set-up. [----------] 4 tests from RiscV [ RUN ] RiscV.cmpxchg_int64_plain_lr_sc_vm [ OK ] RiscV.cmpxchg_int64_plain_lr_sc_vm (2 ms) [ RUN ] RiscV.cmpxchg_int64_plain_maybe_zacas_vm [ OK ] RiscV.cmpxchg_int64_plain_maybe_zacas_vm (0 ms) [ RUN ] RiscV.cmpxchg_int32_plain_lr_sc_vm [ OK ] RiscV.cmpxchg_int32_plain_lr_sc_vm (0 ms) [ RUN ] RiscV.cmpxchg_int32_plain_maybe_zacas_vm [ OK ] RiscV.cmpxchg_int32_plain_maybe_zacas_vm (0 ms) [----------] 4 tests from RiscV (20806 ms total) [----------] Global test environment tear-down [==========] 4 tests from 1 test suite ran. (20809 ms total) [ PASSED ] 4 tests. Executed with `-XX:+UnlockExperimentalVMOptions -XX:+UseZacas` Thanks, Robbin ------------- Commit messages: - fixed ws - gtest cmpxchg 4/8 Changes: https://git.openjdk.org/jdk/pull/22437/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22437&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345177 Stats: 156 lines in 1 file changed: 156 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22437.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22437/head:pull/22437 PR: https://git.openjdk.org/jdk/pull/22437 From kevinw at openjdk.org Thu Nov 28 14:24:38 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 28 Nov 2024 14:24:38 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 15:59:17 GMT, Alan Bateman wrote: > Adds `jcmd Thread.vthread_scheduler` to print the virtual thread scheduler and `jcmd Thread.vthread_pollers` to print the I/O pollers that support virtual threads doing blocking network I/O operations. > > This is a subset of the diagnostics that we've had in the loom repo for a long time. @larry-cable proposed a PR recently ([pull/22121](https://github.com/openjdk/jdk/pull/22121)) to bring a version of same into main line but it was based on an older proposal. This new PR supplants that effort. > > The jtreg failure handler is updated to execute Thread.vthread_scheduler, useful capture when a test fails or times out. test/hotspot/jtreg/serviceability/dcmd/thread/VThreadCommandsTest.java line 96: > 94: .shouldContain("Read I/O pollers:") > 95: .shouldContain("Write I/O pollers:") > 96: .shouldMatch("^\\[0\\] sun.nio.ch..+ \\[registered = [\\d]+, owner = .+\\]$"); Just a nit but are there three dots here in sun.nio.ch. that should literally match, so need the \\ and then the other two other dots with a plus sign, to match one or more characters. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22414#discussion_r1862284094 From mli at openjdk.org Thu Nov 28 14:39:39 2024 From: mli at openjdk.org (Hamlin Li) Date: Thu, 28 Nov 2024 14:39:39 GMT Subject: RFR: 8345110: RISC-V: Optimize and and clean up byte reverse assembler routines In-Reply-To: References: <1ijnwTDZNecZMX64HDgeFk32nZK8UPXyNrrYBtV6qbY=.b98e1228-7818-4876-a868-28ce6f52d15a@github.com> Message-ID: On Thu, 28 Nov 2024 13:17:42 GMT, Fei Yang wrote: > > Thanks for cleanup! Not sure if I understand correctly, just have some questions, in upstream code at [1] [2], seems they both not expect a signed-extending? > > Sorry, I should have explained that in the PR description. For these two cases, we are are loading the 32-bit `npairs` of bytecode `lookupswitch` which are specified to be greater than or equal to 0 by the JVMS [1]. So there is no difference whether we use sign-extension or zero-extension. Hope that answers the question :-) > > [1] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.lookupswitch I see, I guessed that might be the answer. It might be helpful to add some comment in these places to state clearly what we expect, because `revb_w` now has the comment `reverse bytes in lower word, sign-extend`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22410#issuecomment-2506267829 From ivan.walulya at oracle.com Thu Nov 28 14:51:54 2024 From: ivan.walulya at oracle.com (Ivan Walulya) Date: Thu, 28 Nov 2024 14:51:54 +0000 Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas In-Reply-To: References: Message-ID: <533F3361-7183-4C6D-A04D-F4A30EC03717@oracle.com> Vote: yes // Ivan > On 27 Nov 2024, at 12:26, Stefan Karlsson wrote: > > I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot Group. > > Axel is a member of Oracle's HotSpot GC team and has been contributing to various parts of the JVM for over two years now. > > Votes are due by 2024-12-11T12:24+01:00. > > Only current Members of the HotSpot Group [1] are eligible > to vote on this nomination. Votes must be cast in the open by > replying to this mailing list > > For Lazy Consensus voting instructions, see [2]. > > Stefan Karlsson > > [1] https://openjdk.org/census > [2] https://openjdk.org/groups/#member-vote From fyang at openjdk.org Thu Nov 28 15:24:58 2024 From: fyang at openjdk.org (Fei Yang) Date: Thu, 28 Nov 2024 15:24:58 GMT Subject: RFR: 8345110: RISC-V: Optimize and and clean up byte reverse assembler routines [v2] In-Reply-To: References: Message-ID: > Hi, Could you please help review this change? > > MacroAssembler routines `revb_w` and `revb_w_w` will emit 32 and 17 instructions respectively without Zbb. > > Major changes: > 1. There is no need for `revb_w` to reverse bytes for each 32-bit word in the 64-bit register. > All the callers only care about the lower 32-bit word. This reimplement `revb_w` so that it only > reverses bytes in lower 32-bit word and sign-extends the result (14 instructions). This makes `revb_w_w` duplicate. > 2. Removed some assembler routines that are unused or become unnecessary (`revb_h`, `revb_h_helper`, `revb_h_h`, `revb_w_w`). > 3. Adapted callers of these removed assembler routines in file `riscv_b.ad` to emit Zbb instructions directly. > > Will look into `revb_h_h_u` and `revb_h_w_u` after this change. Seems to me they could be factored out as well. > > Testing on linux-riscv64 platform: > - [x] tier1 (release) > - [x] hotspot:tier1 (fastdebug) > - [x] non-trivial benchmark workloads like Dacapo, SpecJBB, Renaissance (release) Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22410/files - new: https://git.openjdk.org/jdk/pull/22410/files/f737241a..7436021c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22410&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22410&range=00-01 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22410.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22410/head:pull/22410 PR: https://git.openjdk.org/jdk/pull/22410 From fyang at openjdk.org Thu Nov 28 15:24:58 2024 From: fyang at openjdk.org (Fei Yang) Date: Thu, 28 Nov 2024 15:24:58 GMT Subject: RFR: 8345110: RISC-V: Optimize and and clean up byte reverse assembler routines [v2] In-Reply-To: References: <1ijnwTDZNecZMX64HDgeFk32nZK8UPXyNrrYBtV6qbY=.b98e1228-7818-4876-a868-28ce6f52d15a@github.com> Message-ID: On Thu, 28 Nov 2024 14:36:45 GMT, Hamlin Li wrote: > > > Thanks for cleanup! Not sure if I understand correctly, just have some questions, in upstream code at [1] [2], seems they both not expect a signed-extending? > > > > > > Sorry, I should have explained that in the PR description. For these two cases, we are are loading the 32-bit `npairs` of bytecode `lookupswitch` which are specified to be greater than or equal to 0 by the JVMS [1]. So there is no difference whether we use sign-extension or zero-extension. Hope that answers the question :-) > > [1] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.lookupswitch > > I see, I guessed that might be the answer. It might be helpful to add some comment in these places to state clearly what we expect, because `revb_w` now has the comment `reverse bytes in lower word, sign-extend`. Make sense. I have just added some code comments to help clarify. Thanks for the suggestions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22410#issuecomment-2506356180 From alanb at openjdk.org Thu Nov 28 15:54:54 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 28 Nov 2024 15:54:54 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands [v2] In-Reply-To: References: Message-ID: > Adds `jcmd Thread.vthread_scheduler` to print the virtual thread scheduler and `jcmd Thread.vthread_pollers` to print the I/O pollers that support virtual threads doing blocking network I/O operations. > > This is a subset of the diagnostics that we've had in the loom repo for a long time. @larry-cable proposed a PR recently ([pull/22121](https://github.com/openjdk/jdk/pull/22121)) to bring a version of same into main line but it was based on an older proposal. This new PR supplants that effort. > > The jtreg failure handler is updated to execute Thread.vthread_scheduler, useful capture when a test fails or times out. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Improve regex for matching poller String representation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22414/files - new: https://git.openjdk.org/jdk/pull/22414/files/c888b2fd..2e9619a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22414&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22414&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22414.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22414/head:pull/22414 PR: https://git.openjdk.org/jdk/pull/22414 From alanb at openjdk.org Thu Nov 28 15:54:54 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 28 Nov 2024 15:54:54 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands [v2] In-Reply-To: References: Message-ID: On Thu, 28 Nov 2024 14:21:50 GMT, Kevin Walls wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve regex for matching poller String representation > > test/hotspot/jtreg/serviceability/dcmd/thread/VThreadCommandsTest.java line 96: > >> 94: .shouldContain("Read I/O pollers:") >> 95: .shouldContain("Write I/O pollers:") >> 96: .shouldMatch("^\\[0\\] sun.nio.ch..+ \\[registered = [\\d]+, owner = .+\\]$"); > > Just a nit but are there three dots here in sun.nio.ch. that should literally match, so need the \\ > and then the other two other dots with a plus sign, to match one or more characters. Well spotted, these should be escaped although it not doing so won't impact the match here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22414#discussion_r1862420265 From kevinw at openjdk.org Thu Nov 28 16:01:46 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 28 Nov 2024 16:01:46 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands [v2] In-Reply-To: References: Message-ID: <8OE5KUwMGefu8U3SipE5GBmABHn7BMsNzn5bpXL2CTg=.838462ff-bf15-4b7c-8072-0be01721411d@github.com> On Thu, 28 Nov 2024 15:54:54 GMT, Alan Bateman wrote: >> Adds `jcmd Thread.vthread_scheduler` to print the virtual thread scheduler and `jcmd Thread.vthread_pollers` to print the I/O pollers that support virtual threads doing blocking network I/O operations. >> >> This is a subset of the diagnostics that we've had in the loom repo for a long time. @larry-cable proposed a PR recently ([pull/22121](https://github.com/openjdk/jdk/pull/22121)) to bring a version of same into main line but it was based on an older proposal. This new PR supplants that effort. >> >> The jtreg failure handler is updated to execute Thread.vthread_scheduler, useful capture when a test fails or times out. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Improve regex for matching poller String representation Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22414#pullrequestreview-2468508549 From kevinw at openjdk.org Thu Nov 28 16:01:47 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 28 Nov 2024 16:01:47 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands [v2] In-Reply-To: References: Message-ID: <3sSlC2KatxWRgj1LpAZxyTMGyxuQu7Ze_2pp-DByEQ0=.4dce1212-516f-4635-9f33-3aad7d78bf35@github.com> On Thu, 28 Nov 2024 15:52:01 GMT, Alan Bateman wrote: >> test/hotspot/jtreg/serviceability/dcmd/thread/VThreadCommandsTest.java line 96: >> >>> 94: .shouldContain("Read I/O pollers:") >>> 95: .shouldContain("Write I/O pollers:") >>> 96: .shouldMatch("^\\[0\\] sun.nio.ch..+ \\[registered = [\\d]+, owner = .+\\]$"); >> >> Just a nit but are there three dots here in sun.nio.ch. that should literally match, so need the \\ >> and then the other two other dots with a plus sign, to match one or more characters. > > Well spotted, these should be escaped although it not doing so won't impact the match here. Yes -it was almost the definitive bikeshedding comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22414#discussion_r1862430118 From rehn at openjdk.org Thu Nov 28 16:28:52 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Thu, 28 Nov 2024 16:28:52 GMT Subject: RFR: 8345178: RISC-V: Add gtests for narrow cmpxchg Message-ID: Hi, please consider. This adds tests of aligned narrow cmpxchg. Note: Google Test filter = *RiscV* [==========] Running 5 tests from 1 test suite. [----------] Global test environment set-up. [----------] 5 tests from RiscV ... [ RUN ] RiscV.cmpxchg_int16_lr_sc_vm [ OK ] RiscV.cmpxchg_int16_lr_sc_vm (2 ms) [ RUN ] RiscV.cmpxchg_int8_lr_sc_vm [ OK ] RiscV.cmpxchg_int8_lr_sc_vm (1 ms) [ RUN ] RiscV.cmpxchg_int16_maybe_zacas_vm [ OK ] RiscV.cmpxchg_int16_maybe_zacas_vm (1 ms) [ RUN ] RiscV.cmpxchg_int8_maybe_zacas_vm [ OK ] RiscV.cmpxchg_int8_maybe_zacas_vm (1 ms) [----------] 5 tests from RiscV (20831 ms total) [----------] Global test environment tear-down [==========] 5 tests from 1 test suite ran. (20834 ms total) [ PASSED ] 5 tests. Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas Thanks, Robbin ------------- Commit messages: - gtest narrow cmpxchg Changes: https://git.openjdk.org/jdk/pull/22445/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22445&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345178 Stats: 87 lines in 1 file changed: 87 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22445.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22445/head:pull/22445 PR: https://git.openjdk.org/jdk/pull/22445 From mli at openjdk.org Thu Nov 28 16:51:38 2024 From: mli at openjdk.org (Hamlin Li) Date: Thu, 28 Nov 2024 16:51:38 GMT Subject: RFR: 8345110: RISC-V: Optimize and and clean up byte reverse assembler routines [v2] In-Reply-To: References: Message-ID: On Thu, 28 Nov 2024 15:24:58 GMT, Fei Yang wrote: >> Hi, Could you please help review this change? >> >> MacroAssembler routines `revb_w` and `revb_w_w` will emit 32 and 17 instructions respectively without Zbb. >> >> Major changes: >> 1. There is no need for `revb_w` to reverse bytes for each 32-bit word in the 64-bit register. >> All the callers only care about the lower 32-bit word. This reimplement `revb_w` so that it only >> reverses bytes in lower 32-bit word and sign-extends the result (14 instructions). This makes `revb_w_w` duplicate. >> 2. Removed some assembler routines that are unused or become unnecessary (`revb_h`, `revb_h_helper`, `revb_h_h`, `revb_w_w`). >> 3. Adapted callers of these removed assembler routines in file `riscv_b.ad` to emit Zbb instructions directly. >> >> Will look into `revb_h_h_u` and `revb_h_w_u` after this change. Seems to me they could be factored out as well. >> >> Testing on linux-riscv64 platform: >> - [x] tier1 (release) >> - [x] hotspot:tier1 (fastdebug) >> - [x] non-trivial benchmark workloads like Dacapo, SpecJBB, Renaissance (release) > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Thanks for updating. The code is much clear with the patch! ------------- Marked as reviewed by mli (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22410#pullrequestreview-2468584445 From mdoerr at openjdk.org Thu Nov 28 21:33:23 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 28 Nov 2024 21:33:23 GMT Subject: RFR: 8345146: [PPC64] Make intrinsic conversions between bit representations of half precision values and floats [v3] In-Reply-To: References: Message-ID: > PPC64 implementation of [JDK-8289552](https://bugs.openjdk.org/browse/JDK-8289552). I've implemented some more instructions which may be useful in the future. > VectorCastNodes are not yet implemented on PPC64. Power9 is recognized by the availability of the "darn" instruction. > > Performance on Power9: > Before patch: > > Benchmark (size) Mode Cnt Score Error Units > Fp16ConversionBenchmark.float16ToFloat 2048 thrpt 15 18.995 ? 0.156 ops/ms > Fp16ConversionBenchmark.floatToFloat16 2048 thrpt 15 18.730 ? 0.331 ops/ms > > > After patch: > > Benchmark (size) Mode Cnt Score Error Units > Fp16ConversionBenchmark.float16ToFloat 2048 thrpt 15 522.637 ? 11.274 ops/ms > Fp16ConversionBenchmark.floatToFloat16 2048 thrpt 15 408.112 ? 9.069 ops/ms Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Make sure interpreter entries are not called on Power8 or older. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22433/files - new: https://git.openjdk.org/jdk/pull/22433/files/02e54629..9a8a2734 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22433&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22433&range=01-02 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22433.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22433/head:pull/22433 PR: https://git.openjdk.org/jdk/pull/22433 From fyang at openjdk.org Fri Nov 29 02:49:37 2024 From: fyang at openjdk.org (Fei Yang) Date: Fri, 29 Nov 2024 02:49:37 GMT Subject: RFR: 8345177: RISC-V: Add gtests for cmpxchg In-Reply-To: References: Message-ID: <7Cxsbc4wXckzC324JVNjXzT7igwEUQl22rftwhA4f94=.4469d4b3-780e-43ee-a63d-c8ce7262a1e6@github.com> On Thu, 28 Nov 2024 12:30:12 GMT, Robbin Ehn wrote: > Hi, please consider. > > This adds tests to some of the base cases. > Focusing on the cases when we pass in same register in some of the argument. (variant 0,1,2,3) > > Note: Google Test filter = *RiscV.cmpxchg* > [==========] Running 4 tests from 1 test suite. > [----------] Global test environment set-up. > [----------] 4 tests from RiscV > [ RUN ] RiscV.cmpxchg_int64_plain_lr_sc_vm > [ OK ] RiscV.cmpxchg_int64_plain_lr_sc_vm (2 ms) > [ RUN ] RiscV.cmpxchg_int64_plain_maybe_zacas_vm > [ OK ] RiscV.cmpxchg_int64_plain_maybe_zacas_vm (0 ms) > [ RUN ] RiscV.cmpxchg_int32_plain_lr_sc_vm > [ OK ] RiscV.cmpxchg_int32_plain_lr_sc_vm (0 ms) > [ RUN ] RiscV.cmpxchg_int32_plain_maybe_zacas_vm > [ OK ] RiscV.cmpxchg_int32_plain_maybe_zacas_vm (0 ms) > [----------] 4 tests from RiscV (20806 ms total) > > [----------] Global test environment tear-down > [==========] 4 tests from 1 test suite ran. (20809 ms total) > [ PASSED ] 4 tests. > > > Executed with `-XX:+UnlockExperimentalVMOptions -XX:+UseZacas` > > Thanks, Robbin Nice tests! I only have one minor question. Thanks. test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 153: > 151: } > 152: _masm.flush(); > 153: OrderAccess::cross_modify_fence(); Do we need this `cross_modify_fence`? Seems to me the preceding `_masm.flush()` which delegates work to `riscv_flush_icache` syscall will do here. Same question for the `CmovTester` case. ------------- PR Review: https://git.openjdk.org/jdk/pull/22437#pullrequestreview-2468987523 PR Review Comment: https://git.openjdk.org/jdk/pull/22437#discussion_r1862858193 From fyang at openjdk.org Fri Nov 29 03:55:20 2024 From: fyang at openjdk.org (Fei Yang) Date: Fri, 29 Nov 2024 03:55:20 GMT Subject: RFR: 8345110: RISC-V: Optimize and and clean up byte reverse assembler routines [v3] In-Reply-To: References: Message-ID: <9RAUP4HsdPED-PpLQXgam0nFiVaOiUbUA6_xC6_d8Pw=.07661ca1-a791-4a62-83ee-0d56a7639a15@github.com> > Hi, Could you please help review this change? > > MacroAssembler routines `revb_w` and `revb_w_w` will emit 32 and 17 instructions respectively without Zbb. > > Major changes: > 1. There is no need for `revb_w` to reverse bytes for each 32-bit word in the 64-bit register. > All the callers only care about the lower 32-bit word. This reimplement `revb_w` so that it only > reverses bytes in lower 32-bit word and sign-extends the result (14 instructions). This makes `revb_w_w` duplicate. > 2. Removed some assembler routines that are unused or become unnecessary (`revb_h`, `revb_h_helper`, `revb_h_h`, `revb_w_w`). > 3. Adapted callers of these removed assembler routines in file `riscv_b.ad` to emit Zbb instructions directly. > > Will look into `revb_h_h_u` and `revb_h_w_u` after this change. Seems to me they could be factored out as well. > > Testing on linux-riscv64 platform: > - [x] tier1 (release) > - [x] hotspot:tier1 (fastdebug) > - [x] non-trivial benchmark workloads like Dacapo, SpecJBB, Renaissance (release) Fei Yang 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 remote-tracking branch 'upstream/master' into JDK-8345110 - Review comments - 8345110: RISC-V: Optimize and and clean up byte reverse assembler routine ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22410/files - new: https://git.openjdk.org/jdk/pull/22410/files/7436021c..8ee05498 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22410&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22410&range=01-02 Stats: 5082 lines in 172 files changed: 2301 ins; 1921 del; 860 mod Patch: https://git.openjdk.org/jdk/pull/22410.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22410/head:pull/22410 PR: https://git.openjdk.org/jdk/pull/22410 From amitkumar at openjdk.org Fri Nov 29 04:12:36 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Fri, 29 Nov 2024 04:12:36 GMT Subject: RFR: 8335367: [s390] Add support for load immediate on condition instructions. [v2] In-Reply-To: References: <2oJIrDqMf4MYKGz_s1K8D2aNjGwJJ75PY-gUOZwVEU0=.af1d8092-a680-4ea2-adf7-a9c3432509a3@github.com> Message-ID: On Thu, 28 Nov 2024 07:11:52 GMT, Manjunath S Matti. wrote: >> Add support for load immediate on condition instructions. > > Manjunath S Matti. has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/cpu/s390/assembler_s390.hpp > > Update the comments as suggested by Amit Kumar > > Co-authored-by: Amit Kumar Marked as reviewed by amitkumar (Committer). macOs build failures not related. @RealLucy free to give a review on this one ? ------------- PR Review: https://git.openjdk.org/jdk/pull/22058#pullrequestreview-2469051059 PR Comment: https://git.openjdk.org/jdk/pull/22058#issuecomment-2507057848 From dholmes at openjdk.org Fri Nov 29 04:51:48 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 29 Nov 2024 04:51:48 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands [v2] In-Reply-To: References: Message-ID: On Thu, 28 Nov 2024 15:54:54 GMT, Alan Bateman wrote: >> Adds `jcmd Thread.vthread_scheduler` to print the virtual thread scheduler and `jcmd Thread.vthread_pollers` to print the I/O pollers that support virtual threads doing blocking network I/O operations. >> >> This is a subset of the diagnostics that we've had in the loom repo for a long time. @larry-cable proposed a PR recently ([pull/22121](https://github.com/openjdk/jdk/pull/22121)) to bring a version of same into main line but it was based on an older proposal. This new PR supplants that effort. >> >> The jtreg failure handler is updated to execute Thread.vthread_scheduler, useful capture when a test fails or times out. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Improve regex for matching poller String representation The two new `execute` methods differ only in the Symbol naming the method to call. Can we not at least define a static helper in the file so that we don't need to duplicate everything? ------------- PR Review: https://git.openjdk.org/jdk/pull/22414#pullrequestreview-2469079738 From rehn at openjdk.org Fri Nov 29 06:40:37 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 29 Nov 2024 06:40:37 GMT Subject: RFR: 8345177: RISC-V: Add gtests for cmpxchg In-Reply-To: <7Cxsbc4wXckzC324JVNjXzT7igwEUQl22rftwhA4f94=.4469d4b3-780e-43ee-a63d-c8ce7262a1e6@github.com> References: <7Cxsbc4wXckzC324JVNjXzT7igwEUQl22rftwhA4f94=.4469d4b3-780e-43ee-a63d-c8ce7262a1e6@github.com> Message-ID: On Fri, 29 Nov 2024 02:36:23 GMT, Fei Yang wrote: >> Hi, please consider. >> >> This adds tests to some of the base cases. >> Focusing on the cases when we pass in same register in some of the argument. (variant 0,1,2,3) >> >> Note: Google Test filter = *RiscV.cmpxchg* >> [==========] Running 4 tests from 1 test suite. >> [----------] Global test environment set-up. >> [----------] 4 tests from RiscV >> [ RUN ] RiscV.cmpxchg_int64_plain_lr_sc_vm >> [ OK ] RiscV.cmpxchg_int64_plain_lr_sc_vm (2 ms) >> [ RUN ] RiscV.cmpxchg_int64_plain_maybe_zacas_vm >> [ OK ] RiscV.cmpxchg_int64_plain_maybe_zacas_vm (0 ms) >> [ RUN ] RiscV.cmpxchg_int32_plain_lr_sc_vm >> [ OK ] RiscV.cmpxchg_int32_plain_lr_sc_vm (0 ms) >> [ RUN ] RiscV.cmpxchg_int32_plain_maybe_zacas_vm >> [ OK ] RiscV.cmpxchg_int32_plain_maybe_zacas_vm (0 ms) >> [----------] 4 tests from RiscV (20806 ms total) >> >> [----------] Global test environment tear-down >> [==========] 4 tests from 1 test suite ran. (20809 ms total) >> [ PASSED ] 4 tests. >> >> >> Executed with `-XX:+UnlockExperimentalVMOptions -XX:+UseZacas` >> >> Thanks, Robbin > > test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 153: > >> 151: } >> 152: _masm.flush(); >> 153: OrderAccess::cross_modify_fence(); > > Do we need this `cross_modify_fence`? Seems to me the preceding `_masm.flush()` which delegates work to `riscv_flush_icache` syscall will do here. Same question for the `CmovTester` case. The exact implementation of flush we may want to change, e.g. Zjid, I/D consistency. And the same goes for CMF, e.g. with Zijd it may be an IMPORT.I and FENCE.I or similar. Here we don't care about that, we only want to test some instructions. The scary options here is UseCtxFencei, which allows us to avoid some icache flush. And we may want to remove more icache flushes. By having both we get a pretty good guarantee that future optimizations don't break this gtest. As producer I call flush(), as consumer I call CMF. But yes we can remove CMF, I'm fine with that also, maybe my paranoia is not warranted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22437#discussion_r1863022454 From lucy at openjdk.org Fri Nov 29 07:51:45 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Fri, 29 Nov 2024 07:51:45 GMT Subject: RFR: 8335367: [s390] Add support for load immediate on condition instructions. [v2] In-Reply-To: References: <2oJIrDqMf4MYKGz_s1K8D2aNjGwJJ75PY-gUOZwVEU0=.af1d8092-a680-4ea2-adf7-a9c3432509a3@github.com> Message-ID: On Thu, 28 Nov 2024 07:11:52 GMT, Manjunath S Matti. wrote: >> Add support for load immediate on condition instructions. > > Manjunath S Matti. has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/cpu/s390/assembler_s390.hpp > > Update the comments as suggested by Amit Kumar > > Co-authored-by: Amit Kumar Changes requested by lucy (Reviewer). src/hotspot/cpu/s390/assembler_s390.hpp line 996: > 994: #define BCTR_ZOPC (unsigned int)(6 << 8) > 995: #define BCTG_ZOPC (unsigned long)(227L << 40 | 70) > 996: #define BCTGR_ZOPC (unsigned int)(0xb946 << 16) Please align as above. Nice catch, btw. src/hotspot/cpu/s390/assembler_s390.hpp line 2074: > 2072: > 2073: // load halfword immediate on condition > 2074: inline void z_lochi(Register r1, int64_t i2, branch_condition m3); // load immediate r1[32-63] = i2_simm16 ; int32 <- int16 Please align as above. src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3291: > 3289: bind(L_failure); > 3290: > 3291: z_lghi(r_result, 1); This lghi deserves a conversion to locghi. Furthermore, without checking for feature availability, the code will require z13 or newer. Is that intended? ------------- PR Review: https://git.openjdk.org/jdk/pull/22058#pullrequestreview-2469266277 PR Review Comment: https://git.openjdk.org/jdk/pull/22058#discussion_r1863077698 PR Review Comment: https://git.openjdk.org/jdk/pull/22058#discussion_r1863079413 PR Review Comment: https://git.openjdk.org/jdk/pull/22058#discussion_r1863088997 From fyang at openjdk.org Fri Nov 29 07:52:41 2024 From: fyang at openjdk.org (Fei Yang) Date: Fri, 29 Nov 2024 07:52:41 GMT Subject: RFR: 8345110: RISC-V: Optimize and and clean up byte reverse assembler routines [v3] In-Reply-To: References: <1ijnwTDZNecZMX64HDgeFk32nZK8UPXyNrrYBtV6qbY=.b98e1228-7818-4876-a868-28ce6f52d15a@github.com> Message-ID: <4p9qGPama-iRe85XoAz6OEpNuBjv6Ngg-2Xavw0YnPE=.40980eaf-863e-432b-8f2b-209fca34b927@github.com> On Thu, 28 Nov 2024 14:36:45 GMT, Hamlin Li wrote: >>> Thanks for cleanup! Not sure if I understand correctly, just have some questions, in upstream code at [1] [2], seems they both not expect a signed-extending? >> >> Sorry, I should have explained that in the PR description. For these two cases, we are are loading the 32-bit `npairs` of bytecode `lookupswitch` which are specified to be greater than or equal to 0 by the JVMS [1]. So there is no difference whether we use sign-extension or zero-extension. Hope that answers the question :-) >> >> [1] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.lookupswitch > >> > Thanks for cleanup! Not sure if I understand correctly, just have some questions, in upstream code at [1] [2], seems they both not expect a signed-extending? >> >> Sorry, I should have explained that in the PR description. For these two cases, we are are loading the 32-bit `npairs` of bytecode `lookupswitch` which are specified to be greater than or equal to 0 by the JVMS [1]. So there is no difference whether we use sign-extension or zero-extension. Hope that answers the question :-) >> >> [1] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.lookupswitch > > I see, I guessed that might be the answer. > It might be helpful to add some comment in these places to state clearly what we expect, because `revb_w` now has the comment `reverse bytes in lower word, sign-extend`. @Hamlin-Li @robehn : Thanks for the review! Will propose another PR to cleanup revb_h_h_u and revb_h_w_u. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22410#issuecomment-2507258223 From fyang at openjdk.org Fri Nov 29 07:52:41 2024 From: fyang at openjdk.org (Fei Yang) Date: Fri, 29 Nov 2024 07:52:41 GMT Subject: Integrated: 8345110: RISC-V: Optimize and and clean up byte reverse assembler routines In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 12:28:40 GMT, Fei Yang wrote: > Hi, Could you please help review this change? > > MacroAssembler routines `revb_w` and `revb_w_w` will emit 32 and 17 instructions respectively without Zbb. > > Major changes: > 1. There is no need for `revb_w` to reverse bytes for each 32-bit word in the 64-bit register. > All the callers only care about the lower 32-bit word. This reimplement `revb_w` so that it only > reverses bytes in lower 32-bit word and sign-extends the result (14 instructions). This makes `revb_w_w` duplicate. > 2. Removed some assembler routines that are unused or become unnecessary (`revb_h`, `revb_h_helper`, `revb_h_h`, `revb_w_w`). > 3. Adapted callers of these removed assembler routines in file `riscv_b.ad` to emit Zbb instructions directly. > > Will look into `revb_h_h_u` and `revb_h_w_u` after this change. Seems to me they could be factored out as well. > > Testing on linux-riscv64 platform: > - [x] tier1 (release) > - [x] hotspot:tier1 (fastdebug) > - [x] non-trivial benchmark workloads like Dacapo, SpecJBB, Renaissance (release) This pull request has now been integrated. Changeset: 08d563ba Author: Fei Yang URL: https://git.openjdk.org/jdk/commit/08d563ba15047020fd5f5fea80547e18898bbab2 Stats: 128 lines in 4 files changed: 28 ins; 77 del; 23 mod 8345110: RISC-V: Optimize and and clean up byte reverse assembler routines Reviewed-by: mli, rehn ------------- PR: https://git.openjdk.org/jdk/pull/22410 From fyang at openjdk.org Fri Nov 29 08:21:06 2024 From: fyang at openjdk.org (Fei Yang) Date: Fri, 29 Nov 2024 08:21:06 GMT Subject: RFR: 8345236: RISC-V: Remove revb_h_h_u and revb_h_w_u macro assembler routines Message-ID: Hi, please consider this cleanup change. This is a further step after https://bugs.openjdk.org/browse/JDK-8345110. `revb_h_h_u` and `revb_h_w_u` assembler routines are mainly used to change byte-ordering for one halfword or two halfwords. The names don't look obvious and the callsites emit more instructions when Zbb is not available (6 and 14 instructions respectively). Seems more readable if we do the ordering while loading the bytes for these callsites, which also results in less instructions. Similar approach is taken for other places in riscv and other ports like arm. This also renames `revb_w` into `revbw` so that we are more consistent in naming with integer instructions that manipulate 32-bit values like `addiw`. Testing on linux-riscv64 platform. - [ ] tier1 (release) ------------- Commit messages: - 8345236: RISC-V: Remove revb_h_h_u and revb_h_w_u macro assembler routines Changes: https://git.openjdk.org/jdk/pull/22452/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22452&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345236 Stats: 80 lines in 3 files changed: 14 ins; 38 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/22452.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22452/head:pull/22452 PR: https://git.openjdk.org/jdk/pull/22452 From amitkumar at openjdk.org Fri Nov 29 08:23:41 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Fri, 29 Nov 2024 08:23:41 GMT Subject: RFR: 8335367: [s390] Add support for load immediate on condition instructions. [v2] In-Reply-To: References: <2oJIrDqMf4MYKGz_s1K8D2aNjGwJJ75PY-gUOZwVEU0=.af1d8092-a680-4ea2-adf7-a9c3432509a3@github.com> Message-ID: On Fri, 29 Nov 2024 07:48:45 GMT, Lutz Schmidt wrote: >> Manjunath S Matti. has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/hotspot/cpu/s390/assembler_s390.hpp >> >> Update the comments as suggested by Amit Kumar >> >> Co-authored-by: Amit Kumar > > src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3291: > >> 3289: bind(L_failure); >> 3290: >> 3291: z_lghi(r_result, 1); > > This lghi deserves a conversion to locghi. Furthermore, without checking for feature availability, the code will require z13 or newer. Is that intended? yeah, actually that was my intention but then I find out that codepath which jumps to `L_failure` not comes with setting cc to 2. testbit(r_array_index, 63); z_bfalse(L_failure); testbit(r_bitmap, (bit + 1) & Klass::SECONDARY_SUPERS_TABLE_MASK); z_bfalse(L_failure); So other solution which I could think of is, to assume that search will fail and load `1` at the start // Initialize r_result with 0 (indicating success). If searching fails, r_result will be loaded // with 1 (failure) at the end of this method. clear_reg(r_result, true /* whole_reg */, false /* set_cc */); // r_result = 0 But then I remembered this: https://github.com/openjdk/jdk/pull/19544/files#r1660693537 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22058#discussion_r1863123743 From amitkumar at openjdk.org Fri Nov 29 08:27:37 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Fri, 29 Nov 2024 08:27:37 GMT Subject: RFR: 8335367: [s390] Add support for load immediate on condition instructions. [v2] In-Reply-To: References: <2oJIrDqMf4MYKGz_s1K8D2aNjGwJJ75PY-gUOZwVEU0=.af1d8092-a680-4ea2-adf7-a9c3432509a3@github.com> Message-ID: <99CVrdckMVKo1p9L_HwA49xceL-Bqp_TlVPOtZMlMuI=.83811cf1-32c4-43d6-84ff-12e697b3ca14@github.com> On Fri, 29 Nov 2024 08:20:36 GMT, Amit Kumar wrote: >So other solution which I could think of is, to assume that search will fail and load 1 at the start with this we can now look for `CC = EQ`. And use `z_locghi(result, 0, Assembler::bcondEqual);` Also now logic for secondary supers table for c1 & interpreter assumes that search will fail and loads 1 at the start. So to be in sync, better we keep it this way :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22058#discussion_r1863129382 From stuefe at openjdk.org Fri Nov 29 09:53:41 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 29 Nov 2024 09:53:41 GMT Subject: RFR: 8340212: -Xshare:off -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64 [v4] In-Reply-To: References: Message-ID: <1F-lKOjcqx8WkskxnR9zrcT2I-j6jNCe-YAKhQLuVlE=.02e5bf5b-b486-45e7-8385-f0b8d134316f@github.com> On Thu, 21 Nov 2024 13:34:54 GMT, Coleen Phillimore wrote: >> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64. This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated. >> >> Tested with tier1-7. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Merge with incoming change for PR https://github.com/openjdk/jdk/pull/21932 Hi Coleen, sorry for the late response. I like your solution, but wonder whether we can simplify it. AFAIU, for the CDS=on path, you (1) test first in `MetaspaceShared::reserve_address_space_for_archives`, and switch off use_archive_base_addr on error. Then you check again after initialization in (2) `CompressedKlassPointers::initialize_for_given_encoding`, fatal'ing on error. (1) means you need a pre-initialization variant of the check where you funnel through base, shift and range. But (1) can only cause an error in two cases: - User specified a wrong SharedBaseAddress - the SharedBaseAddress we hardcoded as default is wrong. The former is a user error and should result in an initialization error, exactly like we do for a wrong `CompressedClassSpaceBaseAddress`. The latter should never happen. How about: - you remove the check in (1). - you extend the error message in (2) to check if user specified SharedBaseAddress - if he did, do an initialization error, if it was our hard-coded SharedBaseAddress that was wrong, just assert. - Then you can remove all variants of check_klass_decode_mode that take explicit arguments. Furthermore, since we now check at initialization time, how about simplifying check_klass_decode_mode to: bool MacroAssembler::check_klass_decode_mode() { return klass_decode_mode() != KlassDecodeNone; } and change `MacroAssembler::klass_decode_mode()` to not assert but to return KlassDecodeNone ? Then the relevant checking parts are not duplicated. We don't need the asserts in `MacroAssembler::klass_decode_mode()` anymore since we check at VM initialization now, and CompressedKlassPointers base and shift never change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21695#issuecomment-2507452065 From fyang at openjdk.org Fri Nov 29 09:56:55 2024 From: fyang at openjdk.org (Fei Yang) Date: Fri, 29 Nov 2024 09:56:55 GMT Subject: RFR: 8345236: RISC-V: Remove revb_h_h_u and revb_h_w_u macro assembler routines [v2] In-Reply-To: References: Message-ID: > Hi, please consider this cleanup change. > > This is a further step after https://bugs.openjdk.org/browse/JDK-8345110. > `revb_h_h_u` and `revb_h_w_u` assembler routines are mainly used to change byte-ordering for one halfword and two halfwords respectively. The names don't look obvious and the callsites emit more instructions when Zbb is not available (6 and 14 instructions respectively). > > Since we don't have instructions like aarch64 `rev32` or `rev16`, seems more reasonable for us to do the byte-ordering while loading the bytes for these callsites, which also results in less instructions. Similar approach is taken for other places in riscv [1] and other ports like arm [2]. This also renames `revb_w` into `revbw` so that we are more consistent in naming with integer instructions that manipulate 32-bit values like `addiw`. > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/templateTable_riscv.cpp#L1625 > [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/arm/templateTable_arm.cpp#L756 > > Testing on linux-riscv64 platform. > - [ ] tier1 (release) > - [x] non-trivial benchmark workloads like Dacapo, SpecJBB, Renaissance (release) Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Fix indentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22452/files - new: https://git.openjdk.org/jdk/pull/22452/files/7790933c..5930005d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22452&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22452&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22452.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22452/head:pull/22452 PR: https://git.openjdk.org/jdk/pull/22452 From alanb at openjdk.org Fri Nov 29 11:12:22 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 29 Nov 2024 11:12:22 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands [v3] In-Reply-To: References: Message-ID: > Adds `jcmd Thread.vthread_scheduler` to print the virtual thread scheduler and `jcmd Thread.vthread_pollers` to print the I/O pollers that support virtual threads doing blocking network I/O operations. > > This is a subset of the diagnostics that we've had in the loom repo for a long time. @larry-cable proposed a PR recently ([pull/22121](https://github.com/openjdk/jdk/pull/22121)) to bring a version of same into main line but it was based on an older proposal. This new PR supplants that effort. > > The jtreg failure handler is updated to execute Thread.vthread_scheduler, useful capture when a test fails or times out. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into JDK-8337199 - VThread*Dcmd::execute changes to use helper function - Improve regex for matching poller String representation - Improve vthread_pollers output - Merge branch 'master' into JDK-8337199 - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22414/files - new: https://git.openjdk.org/jdk/pull/22414/files/2e9619a1..ea7df830 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22414&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22414&range=01-02 Stats: 2120 lines in 75 files changed: 842 ins; 1052 del; 226 mod Patch: https://git.openjdk.org/jdk/pull/22414.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22414/head:pull/22414 PR: https://git.openjdk.org/jdk/pull/22414 From alanb at openjdk.org Fri Nov 29 11:12:23 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 29 Nov 2024 11:12:23 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands [v2] In-Reply-To: References: Message-ID: On Fri, 29 Nov 2024 04:48:57 GMT, David Holmes wrote: > The two new `execute` methods differ only in the Symbol naming the method to call. Can we not at least define a static helper in the file so that we don't need to duplicate everything? Okay, esp. as we'll likely add more. At some point I think Larry is doing to replace all this with other infrastructure for commands in Java. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22414#issuecomment-2507590830 From epeter at openjdk.org Fri Nov 29 11:43:46 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 29 Nov 2024 11:43:46 GMT Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and Math.min(long,long) [v4] In-Reply-To: References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com> Message-ID: On Thu, 17 Oct 2024 10:10:56 GMT, Galder Zamarre?o wrote: >> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance. >> >> Currently vectorization does not kick in for loops containing either of these calls because of the following error: >> >> >> VLoop::check_preconditions: failed: control flow in loop not allowed >> >> >> The control flow is due to the java implementation for these methods, e.g. >> >> >> public static long max(long a, long b) { >> return (a >= b) ? a : b; >> } >> >> >> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively. >> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization. >> E.g. >> >> >> SuperWord::transform_loop: >> Loop: N518/N126 counted [int,int),+4 (1025 iters) main has_sfpt strip_mined >> 518 CountedLoop === 518 246 126 [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21) >> >> >> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1): >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java >> 1 1 0 0 >> ============================== >> TEST SUCCESS >> >> long min 1155 >> long max 1173 >> >> >> After the patch, on darwin/aarch64 (M1): >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java >> 1 1 0 0 >> ============================== >> TEST SUCCESS >> >> long min 1042 >> long max 1042 >> >> >> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes. >> Therefore, it still relies on the macro expansion to transform those into CMoveL. >> >> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results: >> >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PA... > > Galder Zamarre?o 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 30 additional commits since the last revision: > > - Use same default size as in other vector reduction benchmarks > - Renamed benchmark class > - Double/Float tests only when avx enabled > - Make state class non-final > - Restore previous benchmark iterations and default param size > - Add clipping range benchmark that uses min/max > - Encapsulate benchmark state within an inner class > - Avoid creating result array in benchmark method > - Merge branch 'master' into topic.intrinsify-max-min-long > - Revert "Implement cmovL as a jump+mov branch" > > This reverts commit 1522e26bf66c47b780ebd0d0d0c4f78a4c564e44. > - ... and 20 more: https://git.openjdk.org/jdk/compare/20c7c9a0...0a8718e1 @galderz Thanks for taking this task on! Had a quick look at it. So auto-vectorization in SuperWord should now be working, right? If yes: It would be nice if you tested both for `IRNode.MIN_VL` and `IRNode.MIN_REDUCTION_V`, the same for max. You may want to look at these existing tests, to see what other tests there are for the `int` version: `test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Int.java` `test/hotspot/jtreg/compiler/c2/irTests/TestIfMinMax.java` `test/hotspot/jtreg/compiler/vectorization/TestAutoVecIntMinMax.java` `test/hotspot/jtreg/compiler/c2/TestMinMaxSubword.java` There may be some duplicates already here... not sure. And maybe you need to check what to do about probabilities as well. src/hotspot/share/opto/library_call.cpp line 1952: > 1950: Node *a = nullptr; > 1951: Node *b = nullptr; > 1952: Node *n = nullptr; If you are touching this, then you might as well fix the style. Suggestion: Node* a = nullptr; Node* b = nullptr; Node* n = nullptr; test/hotspot/jtreg/compiler/intrinsics/math/TestMinMaxInlining.java line 80: > 78: @IR(phase = { CompilePhase.BEFORE_MACRO_EXPANSION }, counts = { IRNode.MIN_L, "1" }) > 79: @IR(phase = { CompilePhase.AFTER_MACRO_EXPANSION }, counts = { IRNode.MIN_L, "0" }) > 80: private static long testLongMin(long a, long b) { Can you add a comment why it disappears after macro expansion? test/hotspot/jtreg/compiler/intrinsics/math/TestMinMaxInlining.java line 108: > 106: @Test > 107: @Arguments(values = { Argument.NUMBER_MINUS_42, Argument.NUMBER_42 }) > 108: @IR(counts = { IRNode.MIN_F, "1" }, applyIfCPUFeatureOr = {"avx", "true"}) Is this not supported by `asimd`? Same question for the other cases. ------------- PR Review: https://git.openjdk.org/jdk/pull/20098#pullrequestreview-2391518909 PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1814398129 PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1863381007 PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1863381913 From fyang at openjdk.org Fri Nov 29 12:16:42 2024 From: fyang at openjdk.org (Fei Yang) Date: Fri, 29 Nov 2024 12:16:42 GMT Subject: RFR: 8345177: RISC-V: Add gtests for cmpxchg In-Reply-To: References: <7Cxsbc4wXckzC324JVNjXzT7igwEUQl22rftwhA4f94=.4469d4b3-780e-43ee-a63d-c8ce7262a1e6@github.com> Message-ID: On Fri, 29 Nov 2024 06:38:15 GMT, Robbin Ehn wrote: >> test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 153: >> >>> 151: } >>> 152: _masm.flush(); >>> 153: OrderAccess::cross_modify_fence(); >> >> Do we need this `cross_modify_fence`? Seems to me the preceding `_masm.flush()` which delegates work to `riscv_flush_icache` syscall will do here. Same question for the `CmovTester` case. > > The exact implementation of flush we may want to change, e.g. Zjid, I/D consistency. > And the same goes for CMF, e.g. with Zijd it may be an IMPORT.I and FENCE.I or similar. > Here we don't care about that, we only want to test some instructions. > > The scary options here is UseCtxFencei, which allows us to avoid some icache flush. > And we may want to remove more icache flushes. > > By having both we get a pretty good guarantee that future optimizations don't break this gtest. > As producer I call flush(), as consumer I call CMF. > > But yes we can remove CMF, I'm fine with that also, maybe my paranoia is not warranted. I see. But I am a bit worried that this could be misleading to people. We have the CMF, but we only have one thread working as both producer and consumer here. Maybe we can keep it simple for now and update as appropriate when those cases you mentioned happen? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22437#discussion_r1863435219 From rehn at openjdk.org Fri Nov 29 13:52:39 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 29 Nov 2024 13:52:39 GMT Subject: RFR: 8345177: RISC-V: Add gtests for cmpxchg In-Reply-To: References: <7Cxsbc4wXckzC324JVNjXzT7igwEUQl22rftwhA4f94=.4469d4b3-780e-43ee-a63d-c8ce7262a1e6@github.com> Message-ID: On Fri, 29 Nov 2024 12:13:22 GMT, Fei Yang wrote: >> The exact implementation of flush we may want to change, e.g. Zjid, I/D consistency. >> And the same goes for CMF, e.g. with Zijd it may be an IMPORT.I and FENCE.I or similar. >> Here we don't care about that, we only want to test some instructions. >> >> The scary options here is UseCtxFencei, which allows us to avoid some icache flush. >> And we may want to remove more icache flushes. >> >> By having both we get a pretty good guarantee that future optimizations don't break this gtest. >> As producer I call flush(), as consumer I call CMF. >> >> But yes we can remove CMF, I'm fine with that also, maybe my paranoia is not warranted. > > I see. But I am a bit worried that this could be misleading to people. We have the CMF, but we only have one thread working as both producer and consumer here. Maybe we can keep it simple for now and update as appropriate when those cases you mentioned happen? Sure ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22437#discussion_r1863553775 From rehn at openjdk.org Fri Nov 29 14:01:24 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 29 Nov 2024 14:01:24 GMT Subject: RFR: 8345178: RISC-V: Add gtests for narrow cmpxchg [v2] In-Reply-To: References: Message-ID: > Hi, please consider. > > This adds tests of aligned narrow cmpxchg. > > > Note: Google Test filter = *RiscV* > [==========] Running 5 tests from 1 test suite. > [----------] Global test environment set-up. > [----------] 5 tests from RiscV > ... > [ RUN ] RiscV.cmpxchg_int16_lr_sc_vm > [ OK ] RiscV.cmpxchg_int16_lr_sc_vm (2 ms) > [ RUN ] RiscV.cmpxchg_int8_lr_sc_vm > [ OK ] RiscV.cmpxchg_int8_lr_sc_vm (1 ms) > [ RUN ] RiscV.cmpxchg_int16_maybe_zacas_vm > [ OK ] RiscV.cmpxchg_int16_maybe_zacas_vm (1 ms) > [ RUN ] RiscV.cmpxchg_int8_maybe_zacas_vm > [ OK ] RiscV.cmpxchg_int8_maybe_zacas_vm (1 ms) > [----------] 5 tests from RiscV (20831 ms total) > > [----------] Global test environment tear-down > [==========] 5 tests from 1 test suite ran. (20834 ms total) > [ PASSED ] 5 tests. > > > Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas > > Thanks, Robbin Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Remove CMF barrier ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22445/files - new: https://git.openjdk.org/jdk/pull/22445/files/e129a995..b07b2c10 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22445&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22445&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22445.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22445/head:pull/22445 PR: https://git.openjdk.org/jdk/pull/22445 From rehn at openjdk.org Fri Nov 29 14:01:53 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 29 Nov 2024 14:01:53 GMT Subject: RFR: 8345177: RISC-V: Add gtests for cmpxchg [v2] In-Reply-To: References: Message-ID: > Hi, please consider. > > This adds tests to some of the base cases. > Focusing on the cases when we pass in same register in some of the argument. (variant 0,1,2,3) > > Note: Google Test filter = *RiscV.cmpxchg* > [==========] Running 4 tests from 1 test suite. > [----------] Global test environment set-up. > [----------] 4 tests from RiscV > [ RUN ] RiscV.cmpxchg_int64_plain_lr_sc_vm > [ OK ] RiscV.cmpxchg_int64_plain_lr_sc_vm (2 ms) > [ RUN ] RiscV.cmpxchg_int64_plain_maybe_zacas_vm > [ OK ] RiscV.cmpxchg_int64_plain_maybe_zacas_vm (0 ms) > [ RUN ] RiscV.cmpxchg_int32_plain_lr_sc_vm > [ OK ] RiscV.cmpxchg_int32_plain_lr_sc_vm (0 ms) > [ RUN ] RiscV.cmpxchg_int32_plain_maybe_zacas_vm > [ OK ] RiscV.cmpxchg_int32_plain_maybe_zacas_vm (0 ms) > [----------] 4 tests from RiscV (20806 ms total) > > [----------] Global test environment tear-down > [==========] 4 tests from 1 test suite ran. (20809 ms total) > [ PASSED ] 4 tests. > > > Executed with `-XX:+UnlockExperimentalVMOptions -XX:+UseZacas` > > Thanks, Robbin Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision: Remove CMF barrier ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22437/files - new: https://git.openjdk.org/jdk/pull/22437/files/48dc0423..b5a18748 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22437&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22437&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22437.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22437/head:pull/22437 PR: https://git.openjdk.org/jdk/pull/22437 From rehn at openjdk.org Fri Nov 29 14:04:37 2024 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 29 Nov 2024 14:04:37 GMT Subject: RFR: 8345236: RISC-V: Remove revb_h_h_u and revb_h_w_u macro assembler routines [v2] In-Reply-To: References: Message-ID: On Fri, 29 Nov 2024 09:56:55 GMT, Fei Yang wrote: >> Hi, please consider this cleanup change. >> >> This is a further step after https://bugs.openjdk.org/browse/JDK-8345110. >> `revb_h_h_u` and `revb_h_w_u` assembler routines are mainly used to change byte-ordering for one halfword and two halfwords respectively. The names don't look obvious and the callsites emit more instructions when Zbb is not available (6 and 14 instructions respectively). >> >> Since we don't have instructions like aarch64 `rev32` or `rev16`, seems more reasonable for us to do the byte-ordering while loading the bytes for these callsites, which also results in less instructions. Similar approach is taken for other places in riscv [1] and other ports like arm [2]. This also renames `revb_w` into `revbw` so that we are more consistent in naming with integer instructions that manipulate 32-bit values like `addiw`. >> >> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/templateTable_riscv.cpp#L1625 >> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/arm/templateTable_arm.cpp#L756 >> >> Testing on linux-riscv64 platform. >> - [x] tier1 (release) >> - [x] non-trivial benchmark workloads like Dacapo, SpecJBB, Renaissance (release) > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentation I'm always in favour of delta negative patches, thanks! ------------- Marked as reviewed by rehn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22452#pullrequestreview-2469984491 From wkemper at openjdk.org Fri Nov 29 16:00:52 2024 From: wkemper at openjdk.org (William Kemper) Date: Fri, 29 Nov 2024 16:00:52 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v12] In-Reply-To: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: > This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 533 commits: - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux - Problem list Shenandoah TestAllocOutOfMemory on ppc64 - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux - 8344985: GenShen: Refactor arraycopy barrier for generational mode Reviewed-by: shade - Remove incomplete test case - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux - Merge - 8344779: GenShen: Consolidate shared heap region closures into one header Reviewed-by: kdnilsen, ysr - 8344797: GenShen: Update and rename confusing method Reviewed-by: ysr, kdnilsen - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux - ... and 523 more: https://git.openjdk.org/jdk/compare/a80ccf2c...f29d741c ------------- Changes: https://git.openjdk.org/jdk/pull/21273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=11 Stats: 22878 lines in 229 files changed: 21122 ins; 913 del; 843 mod Patch: https://git.openjdk.org/jdk/pull/21273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21273/head:pull/21273 PR: https://git.openjdk.org/jdk/pull/21273 From shade at openjdk.org Fri Nov 29 16:57:03 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 29 Nov 2024 16:57:03 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v12] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Fri, 29 Nov 2024 16:00:52 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 533 commits: > > - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux > - Problem list Shenandoah TestAllocOutOfMemory on ppc64 > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - 8344985: GenShen: Refactor arraycopy barrier for generational mode > > Reviewed-by: shade > - Remove incomplete test case > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - Merge > - 8344779: GenShen: Consolidate shared heap region closures into one header > > Reviewed-by: kdnilsen, ysr > - 8344797: GenShen: Update and rename confusing method > > Reviewed-by: ysr, kdnilsen > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - ... and 523 more: https://git.openjdk.org/jdk/compare/a80ccf2c...f29d741c Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2470311607 From rkennke at openjdk.org Fri Nov 29 17:58:01 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 29 Nov 2024 17:58:01 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v12] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Fri, 29 Nov 2024 16:00:52 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 533 commits: > > - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux > - Problem list Shenandoah TestAllocOutOfMemory on ppc64 > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - 8344985: GenShen: Refactor arraycopy barrier for generational mode > > Reviewed-by: shade > - Remove incomplete test case > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - Merge > - 8344779: GenShen: Consolidate shared heap region closures into one header > > Reviewed-by: kdnilsen, ysr > - 8344797: GenShen: Update and rename confusing method > > Reviewed-by: ysr, kdnilsen > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - ... and 523 more: https://git.openjdk.org/jdk/compare/a80ccf2c...f29d741c Marked as reviewed by rkennke (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2470373501 From kim.barrett at oracle.com Fri Nov 29 19:42:59 2024 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 29 Nov 2024 14:42:59 -0500 Subject: Poisoning in HotSpot In-Reply-To: References: <7cb918b4-4ee7-4c2f-9ab8-036325dc43b4@oracle.com> Message-ID: On 11/26/24 11:54 PM, Julian Waters wrote: > Hi Kim, > > Darn, that's unfortunate. There was an earlier prototype I had that > does solve this issue, but unfortunately the error message resulting > from someone trying to use a poisoned method is much less clear in > that one: > > [... snip ...] > > Will get the following compile error: > > : In function 'int main()': > :20:25: error: call of overloaded 'malloc(size_t)' is ambiguous > 20 | void *ptr = ::malloc(size_t{1}); > | > In file included from > /opt/compiler-explorer/gcc-trunk-20241126/include/c++/15.0.0/cstdlib:83, > from :2: > /usr/include/stdlib.h:540:14: note: candidate: 'void* malloc(size_t)' > 540 | extern void *malloc (size_t __size) __THROW __attribute_malloc__ > | ^~~~~~ > :17:25: note: candidate: 'void* {anonymous}::malloc(size_t)' (deleted) > 17 | FORBID_C_FUNCTION(void *malloc(size_t size), "use os::malloc", > return ::malloc(size);) > | ^~~~~~ > :12:33: note: in definition of macro 'FORBID_C_FUNCTION' > 12 | [[deprecated(alternative)]] signature noexcept = delete; \ > | ^~~~~~~~~ > > Unless ::malloc is wrapped in ALLOW_C_FUNCTION Yeah, the error message for that isn't all that nice. Though it's not *completely* terrible. The relevant information is all there. It's just somewhat buried in a bunch of not relevant stuff. I wonder what other compilers give. Also, using anonymous namespaces in headers is kind of fraught, as it can easily result in ODR violations. Though maybe the always_inline might be sufficient to dodge that here.? But I wonder if the namespace needs to be anonymous, since it's being declared inline.? Maybe give it a descriptive name, like `forbidden_c_functions`. > As for the scoped attributes, for this particular case HotSpot has the > ALWAYSINLINE macro, which bypasses the issue of having unknown > attributes. They could be defined to the corresponding scoped > forceinline attribute that the compiler understands, which avoids > compile failures We don't need to mess with scoped attributes here. As you mentioned, we *do* have ALWAYSINLINE. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkemper at openjdk.org Fri Nov 29 20:56:04 2024 From: wkemper at openjdk.org (William Kemper) Date: Fri, 29 Nov 2024 20:56:04 GMT Subject: Integrated: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) In-Reply-To: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Mon, 30 Sep 2024 22:02:45 GMT, William Kemper wrote: > This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. This pull request has now been integrated. Changeset: 28ae281b Author: William Kemper URL: https://git.openjdk.org/jdk/commit/28ae281b42cd00f471e275db544a5d23a42df59c Stats: 22878 lines in 229 files changed: 21122 ins; 913 del; 843 mod 8337511: Implement JEP 404: Generational Shenandoah (Experimental) Co-authored-by: Kelvin Nilsen Co-authored-by: Y. Srinivas Ramakrishna Co-authored-by: Bernd Mathiske Co-authored-by: Martin Doerr Co-authored-by: Fei Yang Reviewed-by: rkennke, shade, phh ------------- PR: https://git.openjdk.org/jdk/pull/21273 From jwaters at openjdk.org Sat Nov 30 00:47:53 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 30 Nov 2024 00:47:53 GMT Subject: RFR: 8345265: Fix gcc LTO without disabling LTO for g1ParScanThreadState.cpp Message-ID: fixed LTO for gcc when compiling for platforms where the FORBID_C_FUNCTION mechanism is active, however the fix does so by inhibiting LTO for a specific file. This can hinder optimization, which is the end goal if one is indeed doing an LTO build. Fix the issue in a different way by disabling FORBID_C_FUNCTION entirely for os.cpp, which is where the error originates. This has a wide downstream effect, as os.cpp contains a call to os::malloc which contains the forbidden malloc that causes errors that cannot be suppressed by ALLOW_C_FUNCTION in an LTO build. This is a stopgap fix until FORBID_C_FUNCTION is fixed to work properly with LTO on all platforms. While here, also fix a memory leak in jvmciEnv.cpp ------------- Commit messages: - Fix memory leak in jvmciEnv.cpp - Stopgap fix in os.cpp - Declaration fix in compilerWarnings_gcc.hpp - DISABLE_POISONING_STOPGAP in compilerWarnings_gcc.hpp - 8345265 Changes: https://git.openjdk.org/jdk/pull/22464/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22464&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345265 Stats: 10 lines in 4 files changed: 3 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22464.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22464/head:pull/22464 PR: https://git.openjdk.org/jdk/pull/22464 From kbarrett at openjdk.org Sat Nov 30 17:20:21 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 30 Nov 2024 17:20:21 GMT Subject: RFR: 8345269: Fix -Wzero-as-null-pointer-constant warnings in ppc code Message-ID: Please review this change to remove -Wzero-as-null-pointer-constant warnings in ppc code. Most places involve just changing literal 0 to nullptr. Removed a dead return after ShouldNotReachHere() that is no longer needed. Removed some unused Address constructors that had a default address argument with literal 0 as the default value. These could have been changed to use nullptr as the default value, but since they aren't used... Testing: GHA sanity test build, with and without -Wzero-as-null-pointer-constant enabled. I don't have the capability to run tests for this platform, so hoping someone from the aix-ppc maintainers can do more testing. ------------- Commit messages: - simple ppc fixes - remove unneeded Address ctors Changes: https://git.openjdk.org/jdk/pull/22466/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22466&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345269 Stats: 44 lines in 9 files changed: 0 ins; 9 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/22466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22466/head:pull/22466 PR: https://git.openjdk.org/jdk/pull/22466 From tanksherman27 at gmail.com Sat Nov 30 19:31:32 2024 From: tanksherman27 at gmail.com (Julian Waters) Date: Sun, 1 Dec 2024 03:31:32 +0800 Subject: Poisoning in HotSpot In-Reply-To: References: <7cb918b4-4ee7-4c2f-9ab8-036325dc43b4@oracle.com> Message-ID: VC returns: (21): error C2668: 'malloc': ambiguous call to overloaded function Z:/compilers/windows-kits-10/include/10.0.22621.0/ucrt\corecrt_malloc.h(101): note: could be 'void *malloc(size_t)' (18): note: or 'void *forbidden::malloc(size_t) noexcept' (21): note: while trying to match the argument list '(size_t)' Compiler returned: 2 While clang returns: :21:17: error: call to 'malloc' is ambiguous 21 | void *ptr = malloc(size_t{1}); | ^~~~~~ /usr/include/stdlib.h:540:14: note: candidate function 540 | extern void *malloc (size_t __size) __THROW __attribute_malloc__ | ^ :18:25: note: candidate function has been explicitly deleted 18 | FORBID_C_FUNCTION(void *malloc(size_t), "use os::malloc") | ^ 1 error generated. Compiler returned: 1 https://godbolt.org/z/zbfPzoz54 I managed to put in an override system to allow C Standard library methods to be used when they are really needed, but unfortunately the method body of the forwarding method that calls the actual C library code is still defined in a rather clunky way best regards, Julian On Sat, Nov 30, 2024 at 3:43?AM Kim Barrett wrote: > > On 11/26/24 11:54 PM, Julian Waters wrote: > > Hi Kim, > > Darn, that's unfortunate. There was an earlier prototype I had that > does solve this issue, but unfortunately the error message resulting > from someone trying to use a poisoned method is much less clear in > that one: > > [... snip ...] > > Will get the following compile error: > > : In function 'int main()': > :20:25: error: call of overloaded 'malloc(size_t)' is ambiguous > 20 | void *ptr = ::malloc(size_t{1}); > | > In file included from > /opt/compiler-explorer/gcc-trunk-20241126/include/c++/15.0.0/cstdlib:83, > from :2: > /usr/include/stdlib.h:540:14: note: candidate: 'void* malloc(size_t)' > 540 | extern void *malloc (size_t __size) __THROW __attribute_malloc__ > | ^~~~~~ > :17:25: note: candidate: 'void* {anonymous}::malloc(size_t)' (deleted) > 17 | FORBID_C_FUNCTION(void *malloc(size_t size), "use os::malloc", > return ::malloc(size);) > | ^~~~~~ > :12:33: note: in definition of macro 'FORBID_C_FUNCTION' > 12 | [[deprecated(alternative)]] signature noexcept = delete; \ > | ^~~~~~~~~ > > Unless ::malloc is wrapped in ALLOW_C_FUNCTION > > Yeah, the error message for that isn't all that nice. Though it's > not *completely* terrible. The relevant information is all there. It's just > somewhat buried in a bunch of not relevant stuff. I wonder what other > compilers give. > > Also, using anonymous namespaces in headers is kind of fraught, as it can > easily result in ODR violations. Though maybe the always_inline might be > sufficient to dodge that here. But I wonder if the namespace needs to be > anonymous, since it's being declared inline. Maybe give it a descriptive > name, like `forbidden_c_functions`. > > As for the scoped attributes, for this particular case HotSpot has the > ALWAYSINLINE macro, which bypasses the issue of having unknown > attributes. They could be defined to the corresponding scoped > forceinline attribute that the compiler understands, which avoids > compile failures > > We don't need to mess with scoped attributes here. As you mentioned, we *do* > have ALWAYSINLINE. From kim.barrett at oracle.com Sat Nov 30 19:56:07 2024 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 30 Nov 2024 14:56:07 -0500 Subject: Poisoning in HotSpot In-Reply-To: References: <7cb918b4-4ee7-4c2f-9ab8-036325dc43b4@oracle.com> Message-ID: <105ec0e9-ef09-4a6c-9cfc-76da9f260e73@oracle.com> On 11/30/24 2:31 PM, Julian Waters wrote: > VC returns: > > (21): error C2668: 'malloc': ambiguous call to overloaded function > Z:/compilers/windows-kits-10/include/10.0.22621.0/ucrt\corecrt_malloc.h(101): > note: could be 'void *malloc(size_t)' > (18): note: or 'void *forbidden::malloc(size_t) noexcept' > (21): note: while trying to match the argument list '(size_t)' > Compiler returned: 2 > > While clang returns: > > > :21:17: error: call to 'malloc' is ambiguous > 21 | void *ptr = malloc(size_t{1}); > | ^~~~~~ > /usr/include/stdlib.h:540:14: note: candidate function > 540 | extern void *malloc (size_t __size) __THROW __attribute_malloc__ > | ^ > :18:25: note: candidate function has been explicitly deleted > 18 | FORBID_C_FUNCTION(void *malloc(size_t), "use os::malloc") > | ^ > 1 error generated. > Compiler returned: 1 > > https://urldefense.com/v3/__https://godbolt.org/z/zbfPzoz54__;!!ACWV5N9M2RV99hQ!PeGhd4cAnGh4EmOWTWIiolLTwAfE11a3ZrFkFy0zSVTsMbsdcWDRAgZH9kvoQS7zYkGsp7g_SNSVg3VUsO71JgIx$ > > I managed to put in an override system to allow C Standard library > methods to be used when they are really needed, but unfortunately the > method body of the forwarding method that calls the actual C library > code is still defined in a rather clunky way I've been working on this too. Here's what I've come up with, which I think is significantly simpler, yet appears to work well. No clunky forwarding mechanism needed. And no metaprogramming. I think this might just be what we're looking for. The error messages are about ambiguity, but they all list the candidates, and with appropriate naming there's plenty of information provided. ----- begin example ----- void* frob(unsigned); namespace forbidden_functions_support { struct Forbidden {}; } // name must be unqualified. #define FORBID_C_FUNCTION(name)???????????????????????? \ ? namespace forbidden_functions_support {?????????????? \ ? using ::name;???????????????????????????????????????? \ ? }???????????????????????????????????????????????????? \ ? inline namespace forbidden_functions {??????????????? \ ? forbidden_functions_support::Forbidden name{};??????? \ ? } // name and references in expression must be unqualified. #define ALLOW_C_FUNCTION(name, expression) \ ? ([&]() { using forbidden_functions_support::name; return (expression); }()) FORBID_C_FUNCTION(frob) // no error, calls ::frob. // name and expr ref must be unqualified. void* good_frob(unsigned x) { ? return ALLOW_C_FUNCTION(frob, frob(x)); } // demonstrate error for unqualified call. #if 1 // change to 0 to avoid error void* bad_frob1(unsigned x) { ? return frob(x); } #endif // demonstrate error for qualified call. #if 1 // change to 0 to avoid error void* bad_frob2(unsigned x) { ? return ::frob(x); } #endif /* For good_frob, all 3 of gcc, clang, and msvc generate a direct call to frob. gcc error message: poison.cpp: In function ?void* bad_frob(unsigned int)?: poison.cpp:25:10: error: reference to ?frob? is ambiguous ?? 25 |?? return frob(x); ????? |????????? ^~~~ poison.cpp:16:19: note: candidates are: ?forbidden_functions_support::Forbidden forbidden_functions::frob? ?? 16 | FORBID_C_FUNCTION(frob) ????? |?????????????????? ^~~~ poison.cpp:10:44: note: in definition of macro ?FORBID_C_FUNCTION? ?? 10 |???? forbidden_functions_support::Forbidden name{}; \ ????? |??????????????????????????????????????????? ^~~~ poison.cpp:1:7: note:???????????????? ?void* frob(unsigned int)? ??? 1 | void* frob(unsigned); ????? |?????? ^~~~ clang error message: :31:10: error: reference to 'frob' is ambiguous ?? 31 |?? return frob(x); ????? |????????? ^ :1:7: note: candidate found by name lookup is 'frob' ??? 1 | void* frob(unsigned); ????? |?????? ^ :20:19: note: candidate found by name lookup is 'forbidden_functions::frob' ?? 20 | FORBID_C_FUNCTION(frob) ????? |?????????????????? ^ msvc error message: (31): error C2872: 'frob': ambiguous symbol (1): note: could be 'void *frob(unsigned int)' (20): note: or 'forbidden_functions_support::Forbidden forbidden_functions::frob' */ From kim.barrett at oracle.com Sat Nov 30 20:16:01 2024 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 30 Nov 2024 15:16:01 -0500 Subject: Poisoning in HotSpot In-Reply-To: <105ec0e9-ef09-4a6c-9cfc-76da9f260e73@oracle.com> References: <7cb918b4-4ee7-4c2f-9ab8-036325dc43b4@oracle.com> <105ec0e9-ef09-4a6c-9cfc-76da9f260e73@oracle.com> Message-ID: On 11/30/24 2:56 PM, Kim Barrett wrote: > namespace forbidden_functions_support { > struct Forbidden {}; > } > > // name must be unqualified. > #define FORBID_C_FUNCTION(name)???????????????????????? \ > ? namespace forbidden_functions_support {?????????????? \ > ? using ::name;???????????????????????????????????????? \ > ? }???????????????????????????????????????????????????? \ > ? inline namespace forbidden_functions {??????????????? \ > ? forbidden_functions_support::Forbidden name{};??????? \ > ? } > Even simpler.? Don't need the Forbidden struct. // name must be unqualified. #define FORBID_C_FUNCTION(name)???????????????? \ ? namespace forbidden_functions_support {?????? \ ? using ::name;???????????????????????????????? \ ? }???????????????????????????????????????????? \ ? inline namespace forbidden_functions {??????? \ ? const int name = 0;?????????????????????????? \ ? }