From qamai at openjdk.org Mon Dec 1 06:28:04 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 1 Dec 2025 06:28:04 GMT Subject: RFR: 8372779: C2: Disambiguate Node::adr_type for the IR graph Message-ID: Hi, Currently, `Node::adr_type` is ambiguous. For some, it refers to the memory the node consumes, while for the others, it refer to the memory the node produces. This PR removes that ambiguity by introducing `Node::in_adr_type` and `Node::out_adr_type` that refer to those properties, respectively. It also introduces a local verification of the memory graph during compilation. These additions uncover some issues: - Sometimes, the memory is wired incorrectly, such as in `LibraryCall::extend_setCurrentThread`, the `Phi` collect the `StoreNode`s instead of the whole memory state. I think these issues do not result in crashes or miscompilation, though. - `AryEqNode` reports `adr_type` being `TypeAryPtr::BYTES` (it inherits this from `StrIntrinsicNode`). This is incorrect, however, as it can accept `char[]` inputs, too. - For nodes such as `StrInflatedCopyNode`, as it consumes more than it produces, during scheduling, we need to compute anti-dependencies. This is not the case, so I fixed it by making it kill all the memory it consumes. - `GraphKit::set_output_for_allocation` uses a raw `ProjNode` as the base for a `MergeMem`, this is really suspicious. I didn't fix it, as it seems to not result in any symptom at the moment. In the end, the execution of the compiler is strictly more restricted than before, and there is less room for ambiguity. Please take a look and leave your reviews, thanks a lot. ------------- Commit messages: - Disambiguate Node::adr_type Changes: https://git.openjdk.org/jdk/pull/28570/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28570&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372779 Stats: 629 lines in 36 files changed: 403 ins; 72 del; 154 mod Patch: https://git.openjdk.org/jdk/pull/28570.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28570/head:pull/28570 PR: https://git.openjdk.org/jdk/pull/28570 From mdoerr at openjdk.org Mon Dec 1 10:27:36 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 1 Dec 2025 10:27:36 GMT Subject: RFR: 8371820: Further AES performance improvements for key schedule generation [v7] In-Reply-To: References: Message-ID: > This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption. > > The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64. Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: - Minor simplification. - Merge remote-tracking branch 'origin' into 8371820_AES_Crypt - Fix missing whitespace. - Address review comments. - Merge remote-tracking branch 'origin' into 8371820_AES_Crypt - Remove K from AES_Crypt - More minor cleanup. - Improve comment and minor cleanup. - 8371820: Further AES performance improvements for key schedule generation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28299/files - new: https://git.openjdk.org/jdk/pull/28299/files/ae84912d..c7107a70 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28299&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28299&range=05-06 Stats: 17426 lines in 467 files changed: 10903 ins; 3977 del; 2546 mod Patch: https://git.openjdk.org/jdk/pull/28299.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28299/head:pull/28299 PR: https://git.openjdk.org/jdk/pull/28299 From qamai at openjdk.org Mon Dec 1 10:53:48 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 1 Dec 2025 10:53:48 GMT Subject: RFR: 8372779: C2: Disambiguate Node::adr_type for the IR graph [v2] In-Reply-To: References: Message-ID: > Hi, > > Currently, `Node::adr_type` is ambiguous. For some, it refers to the memory the node consumes, while for the others, it refer to the memory the node produces. This PR removes that ambiguity by introducing `Node::in_adr_type` and `Node::out_adr_type` that refer to those properties, respectively. It also introduces a local verification of the memory graph during compilation. These additions uncover some issues: > > - Sometimes, the memory is wired incorrectly, such as in `LibraryCall::extend_setCurrentThread`, the `Phi` collect the `StoreNode`s instead of the whole memory state. I think these issues do not result in crashes or miscompilation, though. > - `AryEqNode` reports `adr_type` being `TypeAryPtr::BYTES` (it inherits this from `StrIntrinsicNode`). This is incorrect, however, as it can accept `char[]` inputs, too. > - For nodes such as `StrInflatedCopyNode`, as it consumes more than it produces, during scheduling, we need to compute anti-dependencies. This is not the case, so I fixed it by making it kill all the memory it consumes. > - `GraphKit::set_output_for_allocation` uses a raw `ProjNode` as the base for a `MergeMem`, this is really suspicious. I didn't fix it, as it seems to not result in any symptom at the moment. > > In the end, the execution of the compiler is strictly more restricted than before, and there is less room for ambiguity. > > Please take a look and leave your reviews, thanks a lot. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: store_to_memory does not emit MemBars ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28570/files - new: https://git.openjdk.org/jdk/pull/28570/files/10c0303f..b39029a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28570&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28570&range=00-01 Stats: 9 lines in 1 file changed: 4 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28570.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28570/head:pull/28570 PR: https://git.openjdk.org/jdk/pull/28570 From coleenp at openjdk.org Mon Dec 1 15:02:50 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Dec 2025 15:02:50 GMT Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5] In-Reply-To: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com> References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com> Message-ID: > ArrayKlass doesn't set AccessFlags so don't look for them there. See CR for details. > Fixed SA and jvmci. @iwanowww Can you check that I changed C2 correctly (we talked about this in August). > Tested with tier1-4. 5-7 in progress. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Added a comment for checking interface guard after array guard. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28371/files - new: https://git.openjdk.org/jdk/pull/28371/files/06d6a186..7f234078 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28371&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28371&range=03-04 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28371.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28371/head:pull/28371 PR: https://git.openjdk.org/jdk/pull/28371 From coleenp at openjdk.org Mon Dec 1 19:16:58 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Dec 2025 19:16:58 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v9] In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 22:44:17 GMT, Patricio Chilano Mateo wrote: >> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes. >> >> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes: >> >> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. >> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version. >> >> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`. >> >> - The code was previously structured in t... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > missing to initialize _is_disabler_at_start Excellent work. Thank you for answering my questions. There's one click suggested change. src/hotspot/share/opto/library_call.cpp line 3052: > 3050: // > 3051: // java_lang_Thread::set_is_in_VTMS_transition(vthread, true); > 3052: // carrier->set_is_in_VTMS_transition(true); Suggestion: // java_lang_Thread::set_is_in_vthread_transition(vthread, true); // carrier->set_is_in_vthread_transition(true); src/hotspot/share/opto/library_call.cpp line 3058: > 3056: // if (disable_requests > 0) { > 3057: // slow path: runtime call > 3058: // } The comment is helpful, thanks. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3526451726 PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578205190 PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578206636 From coleenp at openjdk.org Mon Dec 1 19:16:59 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Dec 2025 19:16:59 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v7] In-Reply-To: References: <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com> Message-ID: On Wed, 26 Nov 2025 22:46:37 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/prims/jvm.cpp line 3671: >> >>> 3669: >>> 3670: JVM_ENTRY(void, JVM_VirtualThreadStartFinalTransition(JNIEnv* env, jobject vthread)) >>> 3671: oop vt = JNIHandles::resolve_external_guard(vthread); >> >> Why do the opto runtime versions set is_in_VTMTS_transition in both the java.lang.Thread and JavaThread and these don't? > > Because we set them in the intrinsic when trying to start the transition. Method `MountUnmountDisabler::start_transition` expects them to be false so we need to clear them in the opto versions. Not sure what I was looking at when I made this comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578213839 From coleenp at openjdk.org Mon Dec 1 19:17:01 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Dec 2025 19:17:01 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v9] In-Reply-To: <9R5lVpD1GBtUw9g9Bc5X7wSEI2a-oFM2Q29HUmyqSmc=.5fb087cf-4305-4bf1-b730-8a3bda7fbe9a@github.com> References: <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com> <9R5lVpD1GBtUw9g9Bc5X7wSEI2a-oFM2Q29HUmyqSmc=.5fb087cf-4305-4bf1-b730-8a3bda7fbe9a@github.com> Message-ID: On Wed, 26 Nov 2025 22:47:25 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1772: >> >>> 1770: >>> 1771: assert(java_thread != nullptr, "sanity check"); >>> 1772: assert(!java_thread->is_in_VTMS_transition(), "sanity check"); >> >> Why don't you need these asserts anymore? > > We can?t assert this because it could be temporarily set by the target while trying to transition. Previously we had two fields in JavaThread, `_VTMS_transition_mark` and `_is_in_VTMS_transition`. `_VTMS_transition_mark` was set first (checked by the disabler), and if transitions were disabled we waited. Once the transition could start we set `_is_in_VTMS_transition`. > Going over the changes I see I removed one assert in `JvmtiEnvBase::get_vthread_jvf` that should be okay to keep, so I restored it. Also added an assert in `JavaThread::is_in_VTMS_transition()` (now `is_in_vthread_transition`) to verify that if it?s accessed from another thread then it has to be done from a safe context where the value will not change?right after checking. okay. seems like a better place for it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578224144 From coleenp at openjdk.org Mon Dec 1 19:17:03 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Dec 2025 19:17:03 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v7] In-Reply-To: References: <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com> Message-ID: <6tlPVcUVZe08HkhCK5LeJ48-wmHb5YjA-Yf4H2NtQf8=.348b2255-44c9-4d43-8045-384b17b3a7d3@github.com> On Wed, 26 Nov 2025 22:48:01 GMT, Patricio Chilano Mateo wrote: >> Why is there the same flag with the same name in both the Java class and C++ JavaThread? Might be an efficient cache, so something should say that (if true). > > The one in `JavaThread` is needed for the `disable_transition_for_all` case. Processing each vthread is not viable, so we instead process all `JavaThreads`. If no `JavaThread` is in a transition then it implies no vthread is in a transition. So why do you need one in java_lang_Thread then? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578256282 From coleenp at openjdk.org Mon Dec 1 19:17:04 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Dec 2025 19:17:04 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v4] In-Reply-To: References: <6WDKeD8iQTXDPhR0ohPvA6KVufW0uXHBmyZ5oOWfYWI=.44d63e7f-fbdb-47b6-8b36-f0d0cb35fb91@github.com> Message-ID: On Tue, 25 Nov 2025 23:49:29 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/mountUnmountDisabler.cpp line 126: >> >>> 124: || global_start_transition_disable_count() > base_disable_count >>> 125: JVMTI_ONLY(|| (JvmtiVTSuspender::is_vthread_suspended(java_lang_Thread::thread_id(vthread)) || thread->is_suspended())); >>> 126: } >> >> I like this approach with the JVMTIStartTransition and JVMTIEndTransition helper classes. It is a nice way to decouple the JVMTI part of the protocol. Introducing the `is_start_transition_disabled()` function was also long desired. Also, I like the functions `start_transition()` and `end_transition()` became pretty simple and clean! > > This is the function that needs a comment why you're testing all these things (and why base_disable_count is one for JVMTI). It's nice as a function that tests all the different values. Looks good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578310137 From coleenp at openjdk.org Mon Dec 1 19:17:06 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Dec 2025 19:17:06 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v4] In-Reply-To: References: <6kxaoFZTU2CYGKZpONDliyxGikpxbLMaxUtuqENnlq4=.4e48b44a-522f-4568-b4da-96b0184e5afc@github.com> Message-ID: On Wed, 26 Nov 2025 07:33:10 GMT, David Holmes wrote: >> This could be a simple cleanup of all these occurrences later. > > Yes this is terribly obscure (doing the assignment in the loop condition check - surprised that is even allowed) and also violates the style-guide in relation to implicit booleans. But frankly it is an awful use of a for-loop in my opinion. Filed https://bugs.openjdk.org/browse/JDK-8372840 as a cleanup task. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578305847 From vlivanov at openjdk.org Mon Dec 1 19:31:58 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 1 Dec 2025 19:31:58 GMT Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5] In-Reply-To: References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com> Message-ID: On Mon, 1 Dec 2025 15:02:50 GMT, Coleen Phillimore wrote: >> ArrayKlass doesn't set AccessFlags so don't look for them there. See CR for details. >> Fixed SA and jvmci. @iwanowww Can you check that I changed C2 correctly (we talked about this in August). >> Tested with tier1-4. 5-7 in progress. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Added a comment for checking interface guard after array guard. Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28371#pullrequestreview-3526629937 From alanb at openjdk.org Mon Dec 1 19:48:57 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Dec 2025 19:48:57 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v9] In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 23:05:26 GMT, Patricio Chilano Mateo wrote: >> How about removing these methods and just have an extra boolean parameter in `start/endTransition`? >> https://github.com/pchilano/jdk/compare/JDK-8364343...pchilano:jdk:startEndTransitionsOnly > > I renamed the methods as suggested. I remembered that we separated ThreadStart/ThreadEnd in 8306028 for future improvements related to JVMTI. Not sure if that?s still relevant but in any case probably better to leave that discussion for a separate bug. Given the comment block to define the terms "mount transition" and "unmount transition" then we could go a bit further and make it 6 methods: start/endMountTransition, start/endUnmountTransition, endFirstMountTransition and startLastUnmountTransition. We don't have to do it now, but it would make the use-sites clearer I think. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578388614 From liach at openjdk.org Mon Dec 1 20:27:07 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Dec 2025 20:27:07 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required Message-ID: Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) ------------- Commit messages: - 8160821 Changes: https://git.openjdk.org/jdk/pull/28585/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8160821 Stats: 135 lines in 7 files changed: 104 ins; 20 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/28585.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28585/head:pull/28585 PR: https://git.openjdk.org/jdk/pull/28585 From liach at openjdk.org Mon Dec 1 20:27:07 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Dec 2025 20:27:07 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 20:09:38 GMT, Chen Liang wrote: > Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) java.lang.invoke tests all pass. New benchmark results for `VarHandleExact`: Benchmark Mode Cnt Score Error Units VarHandleExact.exact_exactInvocation avgt 30 0.380 ? 0.007 ns/op VarHandleExact.generic_exactInvocation avgt 30 0.389 ? 0.008 ns/op VarHandleExact.generic_genericInvocation avgt 30 0.384 ? 0.008 ns/op Submitting internal CI runs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28585#issuecomment-3598661038 From liach at openjdk.org Mon Dec 1 20:34:31 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Dec 2025 20:34:31 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v2] In-Reply-To: References: Message-ID: > Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Logical fallacy ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28585/files - new: https://git.openjdk.org/jdk/pull/28585/files/522cbe9d..886d3918 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28585.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28585/head:pull/28585 PR: https://git.openjdk.org/jdk/pull/28585 From dlong at openjdk.org Mon Dec 1 21:50:54 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 1 Dec 2025 21:50:54 GMT Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5] In-Reply-To: References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com> Message-ID: <9COxlPt9xc7_2hrMumCuZ1wVuSvLPJCHn16RKEFoPu0=.cb81a68a-c100-44a4-8542-b2121c544f96@github.com> On Mon, 1 Dec 2025 15:02:50 GMT, Coleen Phillimore wrote: >> ArrayKlass doesn't set AccessFlags so don't look for them there. See CR for details. >> Fixed SA and jvmci. @iwanowww Can you check that I changed C2 correctly (we talked about this in August). >> Tested with tier1-4. 5-7 in progress. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Added a comment for checking interface guard after array guard. src/hotspot/share/oops/instanceKlass.hpp line 237: > 235: > 236: // State is set either at parse time or while executing, atomically to not disturb other state > 237: InstanceKlassFlags _misc_flags; It looks like the size of these 3 fields, _reference_type, _access_flags, and _misc_flags, will take 8 bytes because of alignment/padding, but if _reference_type was moved to the end of InstanceKlassFlags and the order reversed, it could be reduced to 6 bytes, leaving 2 for future expansion: InstanceKlassFlags _misc_flags; // contains _reference_type AccessFlags _access_flags; char _reserved[2]; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2578843984 From dlong at openjdk.org Mon Dec 1 22:12:52 2025 From: dlong at openjdk.org (Dean Long) Date: Mon, 1 Dec 2025 22:12:52 GMT Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5] In-Reply-To: References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com> Message-ID: On Mon, 1 Dec 2025 15:02:50 GMT, Coleen Phillimore wrote: >> ArrayKlass doesn't set AccessFlags so don't look for them there. See CR for details. >> Fixed SA and jvmci. @iwanowww Can you check that I changed C2 correctly (we talked about this in August). >> Tested with tier1-4. 5-7 in progress. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Added a comment for checking interface guard after array guard. Looks good. src/hotspot/share/opto/library_call.cpp line 4104: > 4102: phi->add_req(makecon(TypeInstPtr::make(env()->Object_klass()->java_mirror()))); > 4103: } > 4104: // Check for interface after array since this checks AccessFlags offset into InstanceKlass. In other words, we are accessing subtype-specific information, so we need to determine the subtype first. ------------- Marked as reviewed by dlong (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28371#pullrequestreview-3527269001 PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2578897794 From coleenp at openjdk.org Mon Dec 1 22:50:50 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Dec 2025 22:50:50 GMT Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5] In-Reply-To: <9COxlPt9xc7_2hrMumCuZ1wVuSvLPJCHn16RKEFoPu0=.cb81a68a-c100-44a4-8542-b2121c544f96@github.com> References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com> <9COxlPt9xc7_2hrMumCuZ1wVuSvLPJCHn16RKEFoPu0=.cb81a68a-c100-44a4-8542-b2121c544f96@github.com> Message-ID: On Mon, 1 Dec 2025 21:48:06 GMT, Dean Long wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Added a comment for checking interface guard after array guard. > > src/hotspot/share/oops/instanceKlass.hpp line 237: > >> 235: >> 236: // State is set either at parse time or while executing, atomically to not disturb other state >> 237: InstanceKlassFlags _misc_flags; > > It looks like the size of these 3 fields, _reference_type, _access_flags, and _misc_flags, will take 8 bytes because of alignment/padding, but if _reference_type was moved to the end of InstanceKlassFlags and the order reversed, it could be reduced to 6 bytes, leaving 2 for future expansion: > > InstanceKlassFlags _misc_flags; // contains _reference_type > AccessFlags _access_flags; > char _reserved[2]; ClassState is a u1 so that fills the u2 gap with reference_type. So I don't think moving reference type will help. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2578975466 From coleenp at openjdk.org Mon Dec 1 22:55:52 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Dec 2025 22:55:52 GMT Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5] In-Reply-To: References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com> Message-ID: On Mon, 1 Dec 2025 22:09:27 GMT, Dean Long wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Added a comment for checking interface guard after array guard. > > src/hotspot/share/opto/library_call.cpp line 4104: > >> 4102: phi->add_req(makecon(TypeInstPtr::make(env()->Object_klass()->java_mirror()))); >> 4103: } >> 4104: // Check for interface after array since this checks AccessFlags offset into InstanceKlass. > > In other words, we are accessing subtype-specific information, so we need to determine the subtype first. I can add this to the comment if you think it's helpful. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2578992154 From pchilanomate at openjdk.org Mon Dec 1 23:00:16 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 1 Dec 2025 23:00:16 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v10] In-Reply-To: References: Message-ID: > When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes. > > This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes: > > - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. > An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version. > > - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`. > > - The code was previously structured in terms of mount and un... Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Fix comment in inline_native_vthread_start_transition ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28361/files - new: https://git.openjdk.org/jdk/pull/28361/files/7aa02a46..44af0ca9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=08-09 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28361.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28361/head:pull/28361 PR: https://git.openjdk.org/jdk/pull/28361 From pchilanomate at openjdk.org Mon Dec 1 23:00:17 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 1 Dec 2025 23:00:17 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v9] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 19:14:37 GMT, Coleen Phillimore wrote: > Excellent work. Thank you for answering my questions. There's one click suggested change. > Thanks for the review Coleen! > src/hotspot/share/opto/library_call.cpp line 3052: > >> 3050: // >> 3051: // java_lang_Thread::set_is_in_VTMS_transition(vthread, true); >> 3052: // carrier->set_is_in_VTMS_transition(true); > > Suggestion: > > // java_lang_Thread::set_is_in_vthread_transition(vthread, true); > // carrier->set_is_in_vthread_transition(true); Fixed. Also fixed the comment above: the other caller is `startFinalTransition`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3599315673 PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2578999900 From pchilanomate at openjdk.org Mon Dec 1 23:00:18 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 1 Dec 2025 23:00:18 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v7] In-Reply-To: <6tlPVcUVZe08HkhCK5LeJ48-wmHb5YjA-Yf4H2NtQf8=.348b2255-44c9-4d43-8045-384b17b3a7d3@github.com> References: <0e65HV5RscFZN_q4JGzXA7k5jlT7gw7klerMqbfz4GU=.598cedb2-fd53-458b-9047-4d712661cbe4@github.com> <6tlPVcUVZe08HkhCK5LeJ48-wmHb5YjA-Yf4H2NtQf8=.348b2255-44c9-4d43-8045-384b17b3a7d3@github.com> Message-ID: On Mon, 1 Dec 2025 18:52:37 GMT, Coleen Phillimore wrote: >> The one in `JavaThread` is needed for the `disable_transition_for_all` case. Processing each vthread is not viable, so we instead process all `JavaThreads`. If no `JavaThread` is in a transition then it implies no vthread is in a transition. > > So why do you need one in java_lang_Thread then? It's needed for the `disable_transition_for_one` case. We only want to disable transitions for that particular vthread (yes, we could also disable transitions for all JavaThreads but that would be unnecessary). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2579002237 From liach at openjdk.org Mon Dec 1 23:41:04 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Dec 2025 23:41:04 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: Message-ID: > Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Tweak VH usage in some classes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28585/files - new: https://git.openjdk.org/jdk/pull/28585/files/886d3918..7bcdcbf3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=01-02 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28585.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28585/head:pull/28585 PR: https://git.openjdk.org/jdk/pull/28585 From liach at openjdk.org Mon Dec 1 23:53:46 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Dec 2025 23:53:46 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 23:41:04 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Tweak VH usage in some classes Since I removed the return type dropping VarHandle bypass, TestGetAndAdd became affected because it can no longer access the x86 assembly. Updated the Java calling convention to fix it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28585#issuecomment-3599477724 From coleenp at openjdk.org Tue Dec 2 00:10:26 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 2 Dec 2025 00:10:26 GMT Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v6] In-Reply-To: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com> References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com> Message-ID: <-KbUyaoVA5lXRBZmFQGTgeU9wtgLF4_qvR7vLHNkPzg=.e851e0f7-4b95-4a12-a5ce-a1d269ceafa5@github.com> > ArrayKlass doesn't set AccessFlags so don't look for them there. See CR for details. > Fixed SA and jvmci. @iwanowww Can you check that I changed C2 correctly (we talked about this in August). > Tested with tier1-4. 5-7 in progress. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Additional comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28371/files - new: https://git.openjdk.org/jdk/pull/28371/files/7f234078..8861381f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28371&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28371&range=04-05 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28371.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28371/head:pull/28371 PR: https://git.openjdk.org/jdk/pull/28371 From liach at openjdk.org Tue Dec 2 00:16:14 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 00:16:14 GMT Subject: RFR: 8372845: Fold identity hash code if object is constant Message-ID: Folding identity hash as constant if the incoming argument is constant would be useful for quick map lookups, such as for the [Classifier proposal](https://openjdk.org/jeps/8357674). Currently, identity hash is not constant because it loads the object header/mark word. We can add an explicit bypass to load an existing hash eagerly instead. ------------- Commit messages: - Move around - Constant fold identity hash Changes: https://git.openjdk.org/jdk/pull/28589/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28589&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372845 Stats: 88 lines in 4 files changed: 87 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28589.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28589/head:pull/28589 PR: https://git.openjdk.org/jdk/pull/28589 From vlivanov at openjdk.org Tue Dec 2 00:25:49 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 00:25:49 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: Message-ID: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> On Mon, 1 Dec 2025 23:41:04 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Tweak VH usage in some classes src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2033: > 2031: > 2032: @ForceInline > 2033: MethodHandle adaptedMethodHandle(VarHandle vh) { Can you elaborate, please, how this method is intended to behave? test/hotspot/jtreg/compiler/c2/irTests/TestGetAndAdd.java line 78: > 76: @IR(counts = {IRNode.X86_LOCK_XADDB, "3"}, phase = CompilePhase.FINAL_CODE) > 77: public static void addB() { > 78: var _ = (byte) B.getAndAdd(b2); > Since I removed the return type dropping VarHandle bypass, TestGetAndAdd became affected because it can no longer access the x86 assembly. It has performance implications for user code, doesn't it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579149358 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579150006 From liach at openjdk.org Tue Dec 2 01:12:48 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 01:12:48 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> Message-ID: <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> On Tue, 2 Dec 2025 00:20:21 GMT, Vladimir Ivanov wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Tweak VH usage in some classes > > src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2033: > >> 2031: >> 2032: @ForceInline >> 2033: MethodHandle adaptedMethodHandle(VarHandle vh) { > > Can you elaborate, please, how this method is intended to behave? When this is compiled, `constant` will become either `1` for constant VH and `2` for non-constant VH. So for constant VH, this becomes a stable read. For a non-constant VH, this becomes `getMethodHandle(mode).asType(...)`, equivalent to before. > test/hotspot/jtreg/compiler/c2/irTests/TestGetAndAdd.java line 78: > >> 76: @IR(counts = {IRNode.X86_LOCK_XADDB, "3"}, phase = CompilePhase.FINAL_CODE) >> 77: public static void addB() { >> 78: var _ = (byte) B.getAndAdd(b2); > >> Since I removed the return type dropping VarHandle bypass, TestGetAndAdd became affected because it can no longer access the x86 assembly. > > It has performance implications for user code, doesn't it? The performance is measured by the existing `org.openjdk.bench.java.lang.invoke.VarHandleExact` benchmark, which originally expects `generic_genericInvocation` to be much slower. Now it instead has a performance on par with the exact invocations. The constant folding ability is verified with the new `VarHandleMismatchedTypeFold` IR test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579218324 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579221253 From vlivanov at openjdk.org Tue Dec 2 01:45:49 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 01:45:49 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> Message-ID: On Tue, 2 Dec 2025 01:08:19 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2033: >> >>> 2031: >>> 2032: @ForceInline >>> 2033: MethodHandle adaptedMethodHandle(VarHandle vh) { >> >> Can you elaborate, please, how this method is intended to behave? > > When this is compiled, `constant` will become either `1` for constant VH and `2` for non-constant VH. So for constant VH, this becomes a stable read. For a non-constant VH, this becomes `getMethodHandle(mode).asType(...)`, equivalent to before. What's the purpose of `constant == MethodHandleImpl.CONSTANT_YES ` and `constant != MethodHandleImpl.CONSTANT_NO` checks then? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579287707 From liach at openjdk.org Tue Dec 2 01:51:47 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 01:51:47 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> Message-ID: <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> On Tue, 2 Dec 2025 01:42:50 GMT, Vladimir Ivanov wrote: >> When this is compiled, `constant` will become either `1` for constant VH and `2` for non-constant VH. So for constant VH, this becomes a stable read. For a non-constant VH, this becomes `getMethodHandle(mode).asType(...)`, equivalent to before. > > What's the purpose of `constant == MethodHandleImpl.CONSTANT_YES ` and `constant != MethodHandleImpl.CONSTANT_NO` checks then? Indeed, I should move the adaptedMh read into `constant == MethodHandleImpl.CONSTANT_YES` block. `constant != MethodHandleImpl.CONSTANT_NO` prevents capturing any further if the VH is known non-constant; we keep this branch in constant case in case the adapted MH is not ready when we know the VH is constant. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579302480 From vlivanov at openjdk.org Tue Dec 2 01:51:49 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 01:51:49 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> Message-ID: On Tue, 2 Dec 2025 01:09:59 GMT, Chen Liang wrote: >> test/hotspot/jtreg/compiler/c2/irTests/TestGetAndAdd.java line 78: >> >>> 76: @IR(counts = {IRNode.X86_LOCK_XADDB, "3"}, phase = CompilePhase.FINAL_CODE) >>> 77: public static void addB() { >>> 78: var _ = (byte) B.getAndAdd(b2); >> >>> Since I removed the return type dropping VarHandle bypass, TestGetAndAdd became affected because it can no longer access the x86 assembly. >> >> It has performance implications for user code, doesn't it? > > The performance is measured by the existing `org.openjdk.bench.java.lang.invoke.VarHandleExact` benchmark, which originally expects `generic_genericInvocation` to be much slower. Now it instead has a performance on par with the exact invocations. > > The constant folding ability is verified with the new `VarHandleMismatchedTypeFold` IR test. If I understand the IR test logic correctly, C2 was able to compile `(void) B.getAndAdd(b2)` call down to the desired instruction sequence. Is it still the case after the fix? What happens if you keep `TestGetAndAdd.java ` intact? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579300293 From liach at openjdk.org Tue Dec 2 01:54:46 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 01:54:46 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> Message-ID: On Tue, 2 Dec 2025 01:48:13 GMT, Vladimir Ivanov wrote: >> The performance is measured by the existing `org.openjdk.bench.java.lang.invoke.VarHandleExact` benchmark, which originally expects `generic_genericInvocation` to be much slower. Now it instead has a performance on par with the exact invocations. >> >> The constant folding ability is verified with the new `VarHandleMismatchedTypeFold` IR test. > > If I understand the IR test logic correctly, C2 was able to compile `(void) B.getAndAdd(b2)` call down to the desired instruction sequence. Is it still the case after the fix? What happens if you keep `TestGetAndAdd.java > ` intact? No. The old code worked because it implicitly depended on the backdoor path present in the now removed `GUARD_METHOD_TEMPLATE_V` in `VarHandleGuardMethodGenerator`. If this test is intact, now its IR compiles to doing something in adaptedMethodHandle and calling a MethodHandle. Not sure why it doesn't inline through that MethodHandle. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579310315 From vlivanov at openjdk.org Tue Dec 2 02:02:46 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 02:02:46 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> Message-ID: On Tue, 2 Dec 2025 01:49:04 GMT, Chen Liang wrote: >> What's the purpose of `constant == MethodHandleImpl.CONSTANT_YES ` and `constant != MethodHandleImpl.CONSTANT_NO` checks then? > > Indeed, I should move the adaptedMh read into `constant == MethodHandleImpl.CONSTANT_YES` block. > > `constant != MethodHandleImpl.CONSTANT_NO` prevents capturing any further if the VH is known non-constant; we keep this branch in constant case in case the adapted MH is not ready when we know the VH is constant. I still have a hard time reasoning about state transitions of the cache. 1) Why do you limit successful cache read (`cache != null`) to constant `vh` case (`constant == MethodHandleImpl.CONSTANT_YES`)? 2) Why do you avoid cache update in non-constant case (`constant != MethodHandleImpl.CONSTANT_NO`)? What happens if it runs compiled `adaptedMethodHandle` method? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579329673 From vlivanov at openjdk.org Tue Dec 2 02:08:44 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 02:08:44 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> Message-ID: <53uGo7JI87pm-cZmvxBiHniURB_bKryyfrWpewgZLP8=.bb97af75-8a6d-4aa8-8a90-e8c4cbc77ec8@github.com> On Tue, 2 Dec 2025 01:52:04 GMT, Chen Liang wrote: >> If I understand the IR test logic correctly, C2 was able to compile `(void) B.getAndAdd(b2)` call down to the desired instruction sequence. Is it still the case after the fix? What happens if you keep `TestGetAndAdd.java >> ` intact? > > No. The old code worked because it implicitly depended on the backdoor path present in the now removed `GUARD_METHOD_TEMPLATE_V` in `VarHandleGuardMethodGenerator`. If this test is intact, now its IR compiles to doing something in adaptedMethodHandle and calling a MethodHandle. Not sure why it doesn't inline through that MethodHandle. Ok, so you eliminated a fast-path check for void-return case and now JIT can't fully optimize it anymore. Do I get it right? Since this particular bytecode shape is exposed through public API, I don't see why user code can't step on it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579341027 From liach at openjdk.org Tue Dec 2 02:16:52 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 02:16:52 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> Message-ID: <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com> On Tue, 2 Dec 2025 02:00:08 GMT, Vladimir Ivanov wrote: >> Indeed, I should move the adaptedMh read into `constant == MethodHandleImpl.CONSTANT_YES` block. >> >> `constant != MethodHandleImpl.CONSTANT_NO` prevents capturing any further if the VH is known non-constant; we keep this branch in constant case in case the adapted MH is not ready when we know the VH is constant. > > I still have a hard time reasoning about state transitions of the cache. > > 1) Why do you limit successful cache read (`cache != null`) to constant `vh` case (`constant == MethodHandleImpl.CONSTANT_YES`)? > > 2) Why do you avoid cache update in non-constant case (`constant != MethodHandleImpl.CONSTANT_NO`)? What happens if it runs compiled `adaptedMethodHandle` method? So an `AccessDescriptor` is created for each sigpoly VH site in the source code. Usually it is `VH.operation()`, but it is legal to use a non-constant VarHandle variable and call an operation on that. If `constant == MethodHandleImpl.CONSTANT_NO`, we are sure that we have the non-constant case, so we cannot trust that cached method handle, and there is no point further caching. We can only read that previous MH conversion cache if `constant == MethodHandleImpl.CONSTANT_YES` because this means our cache is always correct. >> No. The old code worked because it implicitly depended on the backdoor path present in the now removed `GUARD_METHOD_TEMPLATE_V` in `VarHandleGuardMethodGenerator`. If this test is intact, now its IR compiles to doing something in adaptedMethodHandle and calling a MethodHandle. Not sure why it doesn't inline through that MethodHandle. > > Ok, so you eliminated a fast-path check for void-return case and now JIT can't fully optimize it anymore. Do I get it right? Since this particular bytecode shape is exposed through public API, I don't see why user code can't step on it. JIT can fully optimize it in JMH benchmarks. I don't know why the IR in this test can't optimize it - I couldn't reproduce this CI failure locally on my linux-x64-debug profile, but this modified test passes on CI. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579352226 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579353722 From sspitsyn at openjdk.org Tue Dec 2 02:17:51 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 2 Dec 2025 02:17:51 GMT Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v6] In-Reply-To: <-KbUyaoVA5lXRBZmFQGTgeU9wtgLF4_qvR7vLHNkPzg=.e851e0f7-4b95-4a12-a5ce-a1d269ceafa5@github.com> References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com> <-KbUyaoVA5lXRBZmFQGTgeU9wtgLF4_qvR7vLHNkPzg=.e851e0f7-4b95-4a12-a5ce-a1d269ceafa5@github.com> Message-ID: On Tue, 2 Dec 2025 00:10:26 GMT, Coleen Phillimore wrote: >> ArrayKlass doesn't set AccessFlags so don't look for them there. See CR for details. >> Fixed SA and jvmci. @iwanowww Can you check that I changed C2 correctly (we talked about this in August). >> Tested with tier1-4. 5-7 in progress. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Additional comment Looks good. Posted one nit comment though. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 67: > 65: public long getAccessFlags() { return accessFlags.getValue(this); } > 66: // Convenience routine > 67: public AccessFlags getAccessFlagsObj(){ return new AccessFlags(getAccessFlags()); } Nit: The `getAccessFlags`, `getAccessFlagsObj` definitions and `accessFlags` initialization at line 101 are not aligned with other definitions/initializations. Also, there are unneeded spaces in definitions of `getAccessFlags`, `getAccessFlagsObj`. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28371#pullrequestreview-3527876434 PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2579353928 From vlivanov at openjdk.org Tue Dec 2 02:32:47 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 02:32:47 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com> References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com> Message-ID: On Tue, 2 Dec 2025 02:13:15 GMT, Chen Liang wrote: >> I still have a hard time reasoning about state transitions of the cache. >> >> 1) Why do you limit successful cache read (`cache != null`) to constant `vh` case (`constant == MethodHandleImpl.CONSTANT_YES`)? >> >> 2) Why do you avoid cache update in non-constant case (`constant != MethodHandleImpl.CONSTANT_NO`)? What happens if it runs compiled `adaptedMethodHandle` method? > > So an `AccessDescriptor` is created for each sigpoly VH site in the source code. Usually it is `VH.operation()`, but it is legal to use a non-constant VarHandle variable and call an operation on that. If `constant == MethodHandleImpl.CONSTANT_NO`, we are sure that we have the non-constant case, so we cannot trust that cached method handle, and there is no point further caching. We can only read that previous MH conversion cache if `constant == MethodHandleImpl.CONSTANT_YES` because this means our cache is always correct. So, it seems like what you are trying to achieve is a 1-1 mapping from `AccessDescriptor` to `vh` through `adaptedMh`. So, once `cache != null` you can trust that it corresponds to the `vh` instance passed as a constant. But cache pollution can easily break the invariant, so you try to eliminate the pollution by avoiding cache updates when vh is not constant. Do I get it right? >> Ok, so you eliminated a fast-path check for void-return case and now JIT can't fully optimize it anymore. Do I get it right? Since this particular bytecode shape is exposed through public API, I don't see why user code can't step on it. > > JIT can fully optimize it in JMH benchmarks. I don't know why the IR in this test can't optimize it - I couldn't reproduce this CI failure locally on my linux-x64-debug profile, but this modified test passes on CI. I'd say it's a bad sign. Intermittent bugs manifest exactly in such a way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579374286 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579375565 From liach at openjdk.org Tue Dec 2 02:54:46 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 02:54:46 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com> Message-ID: On Tue, 2 Dec 2025 02:29:28 GMT, Vladimir Ivanov wrote: >> So an `AccessDescriptor` is created for each sigpoly VH site in the source code. Usually it is `VH.operation()`, but it is legal to use a non-constant VarHandle variable and call an operation on that. If `constant == MethodHandleImpl.CONSTANT_NO`, we are sure that we have the non-constant case, so we cannot trust that cached method handle, and there is no point further caching. We can only read that previous MH conversion cache if `constant == MethodHandleImpl.CONSTANT_YES` because this means our cache is always correct. > > So, it seems like what you are trying to achieve is a 1-1 mapping from `AccessDescriptor` to `vh` through `adaptedMh`. So, once `cache != null` you can trust that it corresponds to the `vh` instance passed as a constant. But cache pollution can easily break the invariant, so you try to eliminate the pollution by avoiding cache updates when vh is not constant. Do I get it right? No. The avoidance of cache update simply trims down the generated code by throwing away the meaningless cache update. The access to cache is already safeguarded by `constant == MethodHandleImpl.CONSTANT_YES`. I should have moved `var cache = adaptedMh;` into the if block of `constant == CONSTANT_YES`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579405388 From dlong at openjdk.org Tue Dec 2 04:47:51 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 2 Dec 2025 04:47:51 GMT Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5] In-Reply-To: References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com> Message-ID: On Mon, 1 Dec 2025 22:53:36 GMT, Coleen Phillimore wrote: >> src/hotspot/share/opto/library_call.cpp line 4104: >> >>> 4102: phi->add_req(makecon(TypeInstPtr::make(env()->Object_klass()->java_mirror()))); >>> 4103: } >>> 4104: // Check for interface after array since this checks AccessFlags offset into InstanceKlass. >> >> In other words, we are accessing subtype-specific information, so we need to determine the subtype first. > > I can add this to the comment if you think it's helpful. Yes, please. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2579562880 From dlong at openjdk.org Tue Dec 2 04:55:50 2025 From: dlong at openjdk.org (Dean Long) Date: Tue, 2 Dec 2025 04:55:50 GMT Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5] In-Reply-To: References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com> <9COxlPt9xc7_2hrMumCuZ1wVuSvLPJCHn16RKEFoPu0=.cb81a68a-c100-44a4-8542-b2121c544f96@github.com> Message-ID: <41lDi_gRckFIB_TJ2FJb6HdB_vc2_0Jj0WKsLfTyLGY=.e8ed7a8f-df9a-48c1-abba-e25fdcb3c333@github.com> On Mon, 1 Dec 2025 22:48:05 GMT, Coleen Phillimore wrote: >> src/hotspot/share/oops/instanceKlass.hpp line 237: >> >>> 235: >>> 236: // State is set either at parse time or while executing, atomically to not disturb other state >>> 237: InstanceKlassFlags _misc_flags; >> >> It looks like the size of these 3 fields, _reference_type, _access_flags, and _misc_flags, will take 8 bytes because of alignment/padding, but if _reference_type was moved to the end of InstanceKlassFlags and the order reversed, it could be reduced to 6 bytes, leaving 2 for future expansion: >> >> InstanceKlassFlags _misc_flags; // contains _reference_type >> AccessFlags _access_flags; >> char _reserved[2]; > > ClassState is a u1 so that fills the u2 gap with reference_type. So I don't think moving reference type will help. You're right, I missed that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2579576187 From dholmes at openjdk.org Tue Dec 2 06:24:07 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Dec 2025 06:24:07 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v10] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 23:00:16 GMT, Patricio Chilano Mateo wrote: >> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes. >> >> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes: >> >> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. >> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version. >> >> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`. >> >> - The code was previously structured in t... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Fix comment in inline_native_vthread_start_transition Nothing further from me. Again a great piece of work! Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3528335950 From hgreule at openjdk.org Tue Dec 2 07:54:01 2025 From: hgreule at openjdk.org (Hannes Greule) Date: Tue, 2 Dec 2025 07:54:01 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com> Message-ID: On Tue, 2 Dec 2025 02:30:28 GMT, Vladimir Ivanov wrote: >> JIT can fully optimize it in JMH benchmarks. I don't know why the IR in this test can't optimize it - I couldn't reproduce this CI failure locally on my linux-x64-debug profile, but this modified test passes on CI. > > I'd say it's a bad sign. Intermittent bugs manifest exactly in such a way. > The performance is measured by the existing `org.openjdk.bench.java.lang.invoke.VarHandleExact` benchmark, which originally expects `generic_genericInvocation` to be much slower. Now it instead has a performance on par with the exact invocations. > > The constant folding ability is verified with the new `VarHandleMismatchedTypeFold` IR test. The benchmark doesn't consider such inexact getAndAdd calls (with a void return type), I think it should cover that too. This is a very common pattern that really must not regress. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2580041626 From sspitsyn at openjdk.org Tue Dec 2 08:21:57 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 2 Dec 2025 08:21:57 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v10] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 23:00:16 GMT, Patricio Chilano Mateo wrote: >> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes. >> >> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes: >> >> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. >> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version. >> >> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`. >> >> - The code was previously structured in t... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Fix comment in inline_native_vthread_start_transition src/hotspot/share/runtime/mountUnmountDisabler.cpp line 88: > 86: // We rebinded on start_transition but the mount/unmount operation > 87: // failed so now we need to rebind to the original state. > 88: _current->rebind_to_jvmti_thread_state_of(_is_mount ? _vthread() : _current->threadObj()); Q: Not sure I fully understand this comment. We have done a rebind at the line 67 for an unmount transition only. But this comment tells that it was done for mount transition as well. Also, before this update, we used to do a rebind of `JvmtiThreadState` to a vthread in the `JvmtiVTMSTransitionDisabler::VTMS_mount_end()` for the normal (not failed) case. Please, could you explain a little bit more? It feels like this comment needs a correction. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2580118016 From pminborg at openjdk.org Tue Dec 2 09:04:53 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 2 Dec 2025 09:04:53 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 23:41:04 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Tweak VH usage in some classes src/hotspot/share/opto/library_call.cpp line 8926: > 8924: bool LibraryCallKit::inline_isCompileConstant() { > 8925: Node* n = argument(0); > 8926: set_result(n->is_Con() ? intcon(1) : intcon(2)); Can we get constants for these magic numbers on the C side as well? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2580266341 From roland at openjdk.org Tue Dec 2 09:20:41 2025 From: roland at openjdk.org (Roland Westrelin) Date: Tue, 2 Dec 2025 09:20:41 GMT Subject: RFR: 8354282: C2: more crashes in compiled code because of dependency on removed range check CastIIs [v8] In-Reply-To: References: Message-ID: > This is a variant of 8332827. In 8332827, an array access becomes > dependent on a range check `CastII` for another array access. When, > after loop opts are over, that RC `CastII` was removed, the array > access could float and an out of bound access happened. With the fix > for 8332827, RC `CastII`s are no longer removed. > > With this one what happens is that some transformations applied after > loop opts are over widen the type of the RC `CastII`. As a result, the > type of the RC `CastII` is no longer narrower than that of its input, > the `CastII` is removed and the dependency is lost. > > There are 2 transformations that cause this to happen: > > - after loop opts are over, the type of the `CastII` nodes are widen > so nodes that have the same inputs but a slightly different type can > common. > > - When pushing a `CastII` through an `Add`, if of the type both inputs > of the `Add`s are non constant, then we end up widening the type > (the resulting `Add` has a type that's wider than that of the > initial `CastII`). > > There are already 3 types of `Cast` nodes depending on the > optimizations that are allowed. Either the `Cast` is floating > (`depends_only_test()` returns `true`) or pinned. Either the `Cast` > can be removed if it no longer narrows the type of its input or > not. We already have variants of the `CastII`: > > - if the Cast can float and be removed when it doesn't narrow the type > of its input. > > - if the Cast is pinned and be removed when it doesn't narrow the type > of its input. > > - if the Cast is pinned and can't be removed when it doesn't narrow > the type of its input. > > What we need here, I think, is the 4th combination: > > - if the Cast can float and can't be removed when it doesn't narrow > the type of its input. > > Anyway, things are becoming confusing with all these different > variants named in ways that don't always help figure out what > constraints one of them operate under. So I refactored this and that's > the biggest part of this change. The fix consists in marking `Cast` > nodes when their type is widen in a way that prevents them from being > optimized out. > > Tobias ran performance testing with a slightly different version of > this change and there was no regression. Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Merge branch 'master' into JDK-8354282 - whitespace - review - review - Update src/hotspot/share/opto/castnode.cpp Co-authored-by: Christian Hagedorn - Update src/hotspot/share/opto/castnode.cpp Co-authored-by: Christian Hagedorn - Update src/hotspot/share/opto/castnode.cpp Co-authored-by: Christian Hagedorn - Update test/hotspot/jtreg/compiler/c2/irTests/TestPushAddThruCast.java Co-authored-by: Christian Hagedorn - review - review - ... and 7 more: https://git.openjdk.org/jdk/compare/ef5e744a...93b8b0c5 ------------- Changes: https://git.openjdk.org/jdk/pull/24575/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24575&range=07 Stats: 365 lines in 13 files changed: 264 ins; 27 del; 74 mod Patch: https://git.openjdk.org/jdk/pull/24575.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24575/head:pull/24575 PR: https://git.openjdk.org/jdk/pull/24575 From pminborg at openjdk.org Tue Dec 2 09:31:03 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 2 Dec 2025 09:31:03 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 23:41:04 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Tweak VH usage in some classes src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2036: > 2034: var constant = MethodHandleImpl.isCompileConstant(vh); > 2035: var cache = adaptedMh; > 2036: if (constant == MethodHandleImpl.CONSTANT_YES && cache != null) { Rookie question: Is there multi-thread considerations here? How about visibility across threads? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2580353068 From vklang at openjdk.org Tue Dec 2 10:08:39 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 2 Dec 2025 10:08:39 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: Message-ID: <8tnePBnWu5w86zsXUOVMd7R_oHsTVl_Gjug0QP7N_vw=.5ce0106a-a7bf-40a2-b6a4-76e5d816150e@github.com> On Mon, 1 Dec 2025 23:41:04 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Tweak VH usage in some classes src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 632: > 630: @Hidden > 631: @jdk.internal.vm.annotation.IntrinsicCandidate > 632: static int isCompileConstant(Object obj) { nit: an "is"-question tends to indicate a yes/no answer, but in this case it is more of a compileConstantStatus. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2580489368 From coleenp at openjdk.org Tue Dec 2 13:24:54 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 2 Dec 2025 13:24:54 GMT Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v7] In-Reply-To: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com> References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com> Message-ID: > ArrayKlass doesn't set AccessFlags so don't look for them there. See CR for details. > Fixed SA and jvmci. @iwanowww Can you check that I changed C2 correctly (we talked about this in August). > Tested with tier1-4. 5-7 in progress. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fixed indentation. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28371/files - new: https://git.openjdk.org/jdk/pull/28371/files/8861381f..c7247c00 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28371&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28371&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28371.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28371/head:pull/28371 PR: https://git.openjdk.org/jdk/pull/28371 From coleenp at openjdk.org Tue Dec 2 13:24:55 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 2 Dec 2025 13:24:55 GMT Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v6] In-Reply-To: References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com> <-KbUyaoVA5lXRBZmFQGTgeU9wtgLF4_qvR7vLHNkPzg=.e851e0f7-4b95-4a12-a5ce-a1d269ceafa5@github.com> Message-ID: On Tue, 2 Dec 2025 02:14:39 GMT, Serguei Spitsyn wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Additional comment > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 67: > >> 65: public long getAccessFlags() { return accessFlags.getValue(this); } >> 66: // Convenience routine >> 67: public AccessFlags getAccessFlagsObj(){ return new AccessFlags(getAccessFlags()); } > > Nit: The `getAccessFlags`, `getAccessFlagsObj` definitions and `accessFlags` initialization at line 101 are not aligned with other definitions/initializations. Also, there are unneeded spaces in definitions of `getAccessFlags`, `getAccessFlagsObj`. Thanks for noticing this. Did look messy. I fixed it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2581151367 From chagedorn at openjdk.org Tue Dec 2 13:54:26 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Tue, 2 Dec 2025 13:54:26 GMT Subject: RFR: 8354282: C2: more crashes in compiled code because of dependency on removed range check CastIIs [v8] In-Reply-To: References: Message-ID: <2xxjKX6hMeKDfS9SGBEvll8yadDthCoUjCIRpaE8ObA=.b567ec00-7dad-4b57-82a4-db1149fc8942@github.com> On Tue, 2 Dec 2025 09:20:41 GMT, Roland Westrelin wrote: >> This is a variant of 8332827. In 8332827, an array access becomes >> dependent on a range check `CastII` for another array access. When, >> after loop opts are over, that RC `CastII` was removed, the array >> access could float and an out of bound access happened. With the fix >> for 8332827, RC `CastII`s are no longer removed. >> >> With this one what happens is that some transformations applied after >> loop opts are over widen the type of the RC `CastII`. As a result, the >> type of the RC `CastII` is no longer narrower than that of its input, >> the `CastII` is removed and the dependency is lost. >> >> There are 2 transformations that cause this to happen: >> >> - after loop opts are over, the type of the `CastII` nodes are widen >> so nodes that have the same inputs but a slightly different type can >> common. >> >> - When pushing a `CastII` through an `Add`, if of the type both inputs >> of the `Add`s are non constant, then we end up widening the type >> (the resulting `Add` has a type that's wider than that of the >> initial `CastII`). >> >> There are already 3 types of `Cast` nodes depending on the >> optimizations that are allowed. Either the `Cast` is floating >> (`depends_only_test()` returns `true`) or pinned. Either the `Cast` >> can be removed if it no longer narrows the type of its input or >> not. We already have variants of the `CastII`: >> >> - if the Cast can float and be removed when it doesn't narrow the type >> of its input. >> >> - if the Cast is pinned and be removed when it doesn't narrow the type >> of its input. >> >> - if the Cast is pinned and can't be removed when it doesn't narrow >> the type of its input. >> >> What we need here, I think, is the 4th combination: >> >> - if the Cast can float and can't be removed when it doesn't narrow >> the type of its input. >> >> Anyway, things are becoming confusing with all these different >> variants named in ways that don't always help figure out what >> constraints one of them operate under. So I refactored this and that's >> the biggest part of this change. The fix consists in marking `Cast` >> nodes when their type is widen in a way that prevents them from being >> optimized out. >> >> Tobias ran performance testing with a slightly different version of >> this change and there was no regression. > > Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Merge branch 'master' into JDK-8354282 > - whitespace > - review > - review > - Update src/hotspot/share/opto/castnode.cpp > > Co-authored-by: Christian Hagedorn > - Update src/hotspot/share/opto/castnode.cpp > > Co-authored-by: Christian Hagedorn > - Update src/hotspot/share/opto/castnode.cpp > > Co-authored-by: Christian Hagedorn > - Update test/hotspot/jtreg/compiler/c2/irTests/TestPushAddThruCast.java > > Co-authored-by: Christian Hagedorn > - review > - review > - ... and 7 more: https://git.openjdk.org/jdk/compare/ef5e744a...93b8b0c5 Thanks for the update, it looks good to me! If @eme64 also agrees with the latest patch, we can submit some testing and then hopefully get it in right before the fork. ------------- Marked as reviewed by chagedorn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24575#pullrequestreview-3530251375 From chagedorn at openjdk.org Tue Dec 2 13:54:29 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Tue, 2 Dec 2025 13:54:29 GMT Subject: RFR: 8354282: C2: more crashes in compiled code because of dependency on removed range check CastIIs [v4] In-Reply-To: References: <6qShqR-Ohv7vamoJ_B4Ev-poU8SB96eTBo4HFJrylcI=.dac5a26f-c9f0-445b-8f1c-a7c719fa27ae@github.com> <4QQp7C7iIVfVs1MoUMC56KCgVGpXu5ziTHfZ-f2pk6o=.4ca7e1a8-3f31-44d3-aaec-30429ed7e2b0@github.com> Message-ID: On Thu, 27 Nov 2025 12:29:10 GMT, Roland Westrelin wrote: >> src/hotspot/share/opto/castnode.hpp line 101: >> >>> 99: } >>> 100: return NonFloatingNonNarrowing; >>> 101: } >> >> Just a side note: We seem to mix the terms "(non-)pinned" with "(non-)floating" freely. Should we stick to just one? But maybe it's justified to use both depending on the situation/code context. > > The patch as it is now adds some extra uses of "pinned" and "floating". What could make sense, I suppose, would be to try to use "floating"/"non floating" instead but there are so many uses of "pinned" in the code base already, and I don't see us getting rid of them, that I wonder if it would make a difference. So, I'm not too sure what to do. Yes, that's true. I was also unsure about whether we should stick with one or just allow both interchangeably. I guess since there are so many uses, we can just move forward with what you have now and still come back to clean it up if necessary - we can always do that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2581285955 From chagedorn at openjdk.org Tue Dec 2 13:54:34 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Tue, 2 Dec 2025 13:54:34 GMT Subject: RFR: 8354282: C2: more crashes in compiled code because of dependency on removed range check CastIIs [v4] In-Reply-To: <4QQp7C7iIVfVs1MoUMC56KCgVGpXu5ziTHfZ-f2pk6o=.4ca7e1a8-3f31-44d3-aaec-30429ed7e2b0@github.com> References: <6qShqR-Ohv7vamoJ_B4Ev-poU8SB96eTBo4HFJrylcI=.dac5a26f-c9f0-445b-8f1c-a7c719fa27ae@github.com> <4QQp7C7iIVfVs1MoUMC56KCgVGpXu5ziTHfZ-f2pk6o=.4ca7e1a8-3f31-44d3-aaec-30429ed7e2b0@github.com> Message-ID: On Wed, 26 Nov 2025 13:24:05 GMT, Christian Hagedorn wrote: >> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: >> >> - review >> - review >> - Merge branch 'master' into JDK-8354282 >> - review >> - infinite loop in gvn fix >> - renaming >> - merge >> - Merge branch 'master' into JDK-8354282 >> - fix & test > > src/hotspot/share/opto/castnode.hpp line 120: > >> 118: // be removed in any case otherwise the sunk node floats back into the loop. >> 119: static const DependencyType NonFloatingNonNarrowing; >> 120: > > I needed a moment to completely understand all these combinations. I rewrote the definitions in this process a little bit. Feel free to take some of it over: > > > // All the possible combinations of floating/narrowing with example use cases: > > // Use case example: Range Check CastII > // Floating: The Cast is only dependent on the single range check. > // Narrowing: The Cast narrows the type to a positive index. If the input to the Cast is narrower, we can safely > // remove the cast because the array access will be safe. > static const DependencyType FloatingNarrowing; > > // Use case example: Widening Cast nodes' types after loop opts: We want to common Casts with slightly different types. > // Floating: These Casts only depend on the single control. > // NonNarrowing: Even when the input type is narrower, we are not removing the Cast. Otherwise, the dependency > // to the single control is lost, and an array access could float above its range check because we > // just removed the dependency to the range check by removing the Cast. This could lead to an > // out-of-bounds access. > static const DependencyType FloatingNonNarrowing; > > // Use case example: An array accesses that is no longer dependent on a single range check (e.g. range check smearing). > // NonFloating: The array access must be pinned below all the checks it depends on. If the check it directly depends > // on with a control input is hoisted, we do hoist the Cast as well. If we allowed the Cast to float, > // we risk that the array access ends up above another check it depends on (we cannot model two control > // dependencies for a node in the IR). This could lead to an out-of-bounds access. > // Narrowing: If the Cast does not narrow the input type, then it's safe to remove the cast because the array access > // will be safe. > static const DependencyType NonFloatingNarrowing; > > // Use case example: Sinking nodes out of a loop > // Non-Floating & Non-Narrowing: We don't want the Cast that forces the node to be out of loop to be removed in any > // case. Otherwise, the sunk node could float back into the l... Thanks for taking it over :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2581287358 From rrich at openjdk.org Tue Dec 2 14:45:09 2025 From: rrich at openjdk.org (Richard Reingruber) Date: Tue, 2 Dec 2025 14:45:09 GMT Subject: RFR: 8371820: Further AES performance improvements for key schedule generation [v7] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 10:27:36 GMT, Martin Doerr wrote: >> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption. >> >> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64. > > Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - Minor simplification. > - Merge remote-tracking branch 'origin' into 8371820_AES_Crypt > - Fix missing whitespace. > - Address review comments. > - Merge remote-tracking branch 'origin' into 8371820_AES_Crypt > - Remove K from AES_Crypt > - More minor cleanup. > - Improve comment and minor cleanup. > - 8371820: Further AES performance improvements for key schedule generation The changes look good to me. Thanks, Richard. ------------- Marked as reviewed by rrich (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28299#pullrequestreview-3530496843 From mdoerr at openjdk.org Tue Dec 2 14:50:09 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 2 Dec 2025 14:50:09 GMT Subject: RFR: 8371820: Further AES performance improvements for key schedule generation [v7] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 10:27:36 GMT, Martin Doerr wrote: >> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption. >> >> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64. > > Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - Minor simplification. > - Merge remote-tracking branch 'origin' into 8371820_AES_Crypt > - Fix missing whitespace. > - Address review comments. > - Merge remote-tracking branch 'origin' into 8371820_AES_Crypt > - Remove K from AES_Crypt > - More minor cleanup. > - Improve comment and minor cleanup. > - 8371820: Further AES performance improvements for key schedule generation Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28299#issuecomment-3602426006 From epeter at openjdk.org Tue Dec 2 15:32:58 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 2 Dec 2025 15:32:58 GMT Subject: RFR: 8354282: C2: more crashes in compiled code because of dependency on removed range check CastIIs [v8] In-Reply-To: <_rBmTvf064PXyVEAX4zqk43DNgVr0gQDPzPcdQ4XI1A=.660e7e89-0a49-47e0-9639-972cbfbac5f0@github.com> References: <0An6wz0QZZxtVg-lP4IyqWTekcYkSmvosrVWkI7cH70=.86c07374-2127-4892-a369-ceefa82dd0b7@github.com> <_rBmTvf064PXyVEAX4zqk43DNgVr0gQDPzPcdQ4XI1A=.660e7e89-0a49-47e0-9639-972cbfbac5f0@github.com> Message-ID: <4qc5jJ1KA09yko5rWioBGstpuuRNxOiNWXRdRdh9h_E=.17c8ace8-c672-4451-bd15-247d66d92cef@github.com> On Tue, 2 Dec 2025 15:19:26 GMT, Emanuel Peter wrote: >> Actually, I'm wondering if the term `hoistable` and `non-hoistable` would not be better terms... > > At least we could say that it is allowed to hoist the RangeCheck, and the CastII could float up to where the RC is hoisted. Suggestion: // Use case example: Range Check CastII // Floating: The Cast is only dependent on the single range check. If the range check was ever to be hoisted // is would be safe to let the the Cast float to where the range check is hoisted up to. // Narrowing: The Cast narrows the type to a positive index. If the input to the Cast is narrower, we can safely // remove the cast because the array access will be safe. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2581692285 From epeter at openjdk.org Tue Dec 2 15:32:55 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 2 Dec 2025 15:32:55 GMT Subject: RFR: 8354282: C2: more crashes in compiled code because of dependency on removed range check CastIIs [v8] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 09:20:41 GMT, Roland Westrelin wrote: >> This is a variant of 8332827. In 8332827, an array access becomes >> dependent on a range check `CastII` for another array access. When, >> after loop opts are over, that RC `CastII` was removed, the array >> access could float and an out of bound access happened. With the fix >> for 8332827, RC `CastII`s are no longer removed. >> >> With this one what happens is that some transformations applied after >> loop opts are over widen the type of the RC `CastII`. As a result, the >> type of the RC `CastII` is no longer narrower than that of its input, >> the `CastII` is removed and the dependency is lost. >> >> There are 2 transformations that cause this to happen: >> >> - after loop opts are over, the type of the `CastII` nodes are widen >> so nodes that have the same inputs but a slightly different type can >> common. >> >> - When pushing a `CastII` through an `Add`, if of the type both inputs >> of the `Add`s are non constant, then we end up widening the type >> (the resulting `Add` has a type that's wider than that of the >> initial `CastII`). >> >> There are already 3 types of `Cast` nodes depending on the >> optimizations that are allowed. Either the `Cast` is floating >> (`depends_only_test()` returns `true`) or pinned. Either the `Cast` >> can be removed if it no longer narrows the type of its input or >> not. We already have variants of the `CastII`: >> >> - if the Cast can float and be removed when it doesn't narrow the type >> of its input. >> >> - if the Cast is pinned and be removed when it doesn't narrow the type >> of its input. >> >> - if the Cast is pinned and can't be removed when it doesn't narrow >> the type of its input. >> >> What we need here, I think, is the 4th combination: >> >> - if the Cast can float and can't be removed when it doesn't narrow >> the type of its input. >> >> Anyway, things are becoming confusing with all these different >> variants named in ways that don't always help figure out what >> constraints one of them operate under. So I refactored this and that's >> the biggest part of this change. The fix consists in marking `Cast` >> nodes when their type is widen in a way that prevents them from being >> optimized out. >> >> Tobias ran performance testing with a slightly different version of >> this change and there was no regression. > > Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Merge branch 'master' into JDK-8354282 > - whitespace > - review > - review > - Update src/hotspot/share/opto/castnode.cpp > > Co-authored-by: Christian Hagedorn > - Update src/hotspot/share/opto/castnode.cpp > > Co-authored-by: Christian Hagedorn > - Update src/hotspot/share/opto/castnode.cpp > > Co-authored-by: Christian Hagedorn > - Update test/hotspot/jtreg/compiler/c2/irTests/TestPushAddThruCast.java > > Co-authored-by: Christian Hagedorn > - review > - review > - ... and 7 more: https://git.openjdk.org/jdk/compare/ef5e744a...93b8b0c5 src/hotspot/share/opto/castnode.hpp line 108: > 106: // Floating: The Cast is only dependent on the single range check. > 107: // Narrowing: The Cast narrows the type to a positive index. If the input to the Cast is narrower, we can safely > 108: // remove the cast because the array access will be safe. The "Floating" part is a bit counter intuitive here, because the ctrl of the CastII is the RangeCheck, right? So is it not therefore already pinned? Maybe we can add some detail about what the "floating" explicitly means here. Is it that we can later move the CastII up in an optimization? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2581630546 From epeter at openjdk.org Tue Dec 2 15:32:57 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 2 Dec 2025 15:32:57 GMT Subject: RFR: 8354282: C2: more crashes in compiled code because of dependency on removed range check CastIIs [v8] In-Reply-To: <0An6wz0QZZxtVg-lP4IyqWTekcYkSmvosrVWkI7cH70=.86c07374-2127-4892-a369-ceefa82dd0b7@github.com> References: <0An6wz0QZZxtVg-lP4IyqWTekcYkSmvosrVWkI7cH70=.86c07374-2127-4892-a369-ceefa82dd0b7@github.com> Message-ID: <_rBmTvf064PXyVEAX4zqk43DNgVr0gQDPzPcdQ4XI1A=.660e7e89-0a49-47e0-9639-972cbfbac5f0@github.com> On Tue, 2 Dec 2025 15:17:38 GMT, Emanuel Peter wrote: >> src/hotspot/share/opto/castnode.hpp line 108: >> >>> 106: // Floating: The Cast is only dependent on the single range check. >>> 107: // Narrowing: The Cast narrows the type to a positive index. If the input to the Cast is narrower, we can safely >>> 108: // remove the cast because the array access will be safe. >> >> The "Floating" part is a bit counter intuitive here, because the ctrl of the CastII is the RangeCheck, right? >> So is it not therefore already pinned? >> >> Maybe we can add some detail about what the "floating" explicitly means here. Is it that we can later move the CastII up in an optimization? > > Actually, I'm wondering if the term `hoistable` and `non-hoistable` would not be better terms... At least we could say that it is allowed to hoist the RangeCheck, and the CastII could float up to where the RC is hoisted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2581649395 From epeter at openjdk.org Tue Dec 2 15:32:56 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 2 Dec 2025 15:32:56 GMT Subject: RFR: 8354282: C2: more crashes in compiled code because of dependency on removed range check CastIIs [v8] In-Reply-To: References: Message-ID: <0An6wz0QZZxtVg-lP4IyqWTekcYkSmvosrVWkI7cH70=.86c07374-2127-4892-a369-ceefa82dd0b7@github.com> On Tue, 2 Dec 2025 15:14:28 GMT, Emanuel Peter wrote: >> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: >> >> - Merge branch 'master' into JDK-8354282 >> - whitespace >> - review >> - review >> - Update src/hotspot/share/opto/castnode.cpp >> >> Co-authored-by: Christian Hagedorn >> - Update src/hotspot/share/opto/castnode.cpp >> >> Co-authored-by: Christian Hagedorn >> - Update src/hotspot/share/opto/castnode.cpp >> >> Co-authored-by: Christian Hagedorn >> - Update test/hotspot/jtreg/compiler/c2/irTests/TestPushAddThruCast.java >> >> Co-authored-by: Christian Hagedorn >> - review >> - review >> - ... and 7 more: https://git.openjdk.org/jdk/compare/ef5e744a...93b8b0c5 > > src/hotspot/share/opto/castnode.hpp line 108: > >> 106: // Floating: The Cast is only dependent on the single range check. >> 107: // Narrowing: The Cast narrows the type to a positive index. If the input to the Cast is narrower, we can safely >> 108: // remove the cast because the array access will be safe. > > The "Floating" part is a bit counter intuitive here, because the ctrl of the CastII is the RangeCheck, right? > So is it not therefore already pinned? > > Maybe we can add some detail about what the "floating" explicitly means here. Is it that we can later move the CastII up in an optimization? Actually, I'm wondering if the term `hoistable` and `non-hoistable` would not be better terms... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2581642290 From duke at openjdk.org Tue Dec 2 15:40:49 2025 From: duke at openjdk.org (duke) Date: Tue, 2 Dec 2025 15:40:49 GMT Subject: Withdrawn: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction In-Reply-To: References: Message-ID: On Tue, 18 Mar 2025 20:51:46 GMT, Jatin Bhateja wrote: > Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. > It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. > > Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). > > Vector API jtreg tests pass at AVX level 2, remaining validation in progress. > > Performance numbers: > > > System : 13th Gen Intel(R) Core(TM) i3-1315U > > Baseline: > Benchmark (size) Mode Cnt Score Error Units > VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms > VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms > VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms > VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms > VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms > VectorSliceBenchmark.shortVectorSliceWithVariableIndex 1024 ... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24104 From epeter at openjdk.org Tue Dec 2 16:52:30 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 2 Dec 2025 16:52:30 GMT Subject: RFR: 8354282: C2: more crashes in compiled code because of dependency on removed range check CastIIs [v8] In-Reply-To: References: Message-ID: <9zey9SqquL1zLlFLuyKV_18OiZs2UQSokhREx9ln0l0=.edc15ede-e798-4d88-b61a-d2ed086d99da@github.com> On Tue, 2 Dec 2025 09:20:41 GMT, Roland Westrelin wrote: >> This is a variant of 8332827. In 8332827, an array access becomes >> dependent on a range check `CastII` for another array access. When, >> after loop opts are over, that RC `CastII` was removed, the array >> access could float and an out of bound access happened. With the fix >> for 8332827, RC `CastII`s are no longer removed. >> >> With this one what happens is that some transformations applied after >> loop opts are over widen the type of the RC `CastII`. As a result, the >> type of the RC `CastII` is no longer narrower than that of its input, >> the `CastII` is removed and the dependency is lost. >> >> There are 2 transformations that cause this to happen: >> >> - after loop opts are over, the type of the `CastII` nodes are widen >> so nodes that have the same inputs but a slightly different type can >> common. >> >> - When pushing a `CastII` through an `Add`, if of the type both inputs >> of the `Add`s are non constant, then we end up widening the type >> (the resulting `Add` has a type that's wider than that of the >> initial `CastII`). >> >> There are already 3 types of `Cast` nodes depending on the >> optimizations that are allowed. Either the `Cast` is floating >> (`depends_only_test()` returns `true`) or pinned. Either the `Cast` >> can be removed if it no longer narrows the type of its input or >> not. We already have variants of the `CastII`: >> >> - if the Cast can float and be removed when it doesn't narrow the type >> of its input. >> >> - if the Cast is pinned and be removed when it doesn't narrow the type >> of its input. >> >> - if the Cast is pinned and can't be removed when it doesn't narrow >> the type of its input. >> >> What we need here, I think, is the 4th combination: >> >> - if the Cast can float and can't be removed when it doesn't narrow >> the type of its input. >> >> Anyway, things are becoming confusing with all these different >> variants named in ways that don't always help figure out what >> constraints one of them operate under. So I refactored this and that's >> the biggest part of this change. The fix consists in marking `Cast` >> nodes when their type is widen in a way that prevents them from being >> optimized out. >> >> Tobias ran performance testing with a slightly different version of >> this change and there was no regression. > > Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Merge branch 'master' into JDK-8354282 > - whitespace > - review > - review > - Update src/hotspot/share/opto/castnode.cpp > > Co-authored-by: Christian Hagedorn > - Update src/hotspot/share/opto/castnode.cpp > > Co-authored-by: Christian Hagedorn > - Update src/hotspot/share/opto/castnode.cpp > > Co-authored-by: Christian Hagedorn > - Update test/hotspot/jtreg/compiler/c2/irTests/TestPushAddThruCast.java > > Co-authored-by: Christian Hagedorn > - review > - review > - ... and 7 more: https://git.openjdk.org/jdk/compare/ef5e744a...93b8b0c5 @rwestrel Nice work! We not just only fixed the bug but made the concepts much clearer. This makes me very happy ? ------------- Marked as reviewed by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24575#pullrequestreview-3531172652 From epeter at openjdk.org Tue Dec 2 16:52:32 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 2 Dec 2025 16:52:32 GMT Subject: RFR: 8354282: C2: more crashes in compiled code because of dependency on removed range check CastIIs [v8] In-Reply-To: <4qc5jJ1KA09yko5rWioBGstpuuRNxOiNWXRdRdh9h_E=.17c8ace8-c672-4451-bd15-247d66d92cef@github.com> References: <0An6wz0QZZxtVg-lP4IyqWTekcYkSmvosrVWkI7cH70=.86c07374-2127-4892-a369-ceefa82dd0b7@github.com> <_rBmTvf064PXyVEAX4zqk43DNgVr0gQDPzPcdQ4XI1A=.660e7e89-0a49-47e0-9639-972cbfbac5f0@github.com> <4qc5jJ1KA09yko5rWioBGstpuuRNxOiNWXRdRdh9h_E=.17c8ace8-c672-4451-bd15-247d66d92cef@github.com> Message-ID: On Tue, 2 Dec 2025 15:29:42 GMT, Emanuel Peter wrote: >> At least we could say that it is allowed to hoist the RangeCheck, and the CastII could float up to where the RC is hoisted. > > Suggestion: > > // Use case example: Range Check CastII > // Floating: The Cast is only dependent on the single range check. If the range check was ever to be hoisted > // is would be safe to let the the Cast float to where the range check is hoisted up to. > // Narrowing: The Cast narrows the type to a positive index. If the input to the Cast is narrower, we can safely > // remove the cast because the array access will be safe. Ok, I now read the PR from the top, and not just recent changes. If one were to start reading from the top, it would be clear without my suggestions here. But I think it could still be good to apply something about letting the Cast float to where we would hoist the RC. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2582034834 From liach at openjdk.org Tue Dec 2 17:17:44 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 17:17:44 GMT Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v5] In-Reply-To: References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com> Message-ID: On Mon, 1 Dec 2025 15:02:50 GMT, Coleen Phillimore wrote: >> ArrayKlass doesn't set AccessFlags so don't look for them there. See CR for details. >> Fixed SA and jvmci. @iwanowww Can you check that I changed C2 correctly (we talked about this in August). >> Tested with tier1-4. 5-7 in progress. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Added a comment for checking interface guard after array guard. src/hotspot/share/classfile/javaClasses.cpp line 1096: > 1094: // Set the raw access_flags, this is used by reflection instead of modifier flags. > 1095: // The Java code for array classes gets the access flags from the element type. > 1096: set_raw_access_flags(mirror(), k->is_array_klass() ? 0 : InstanceKlass::cast(k)->access_flags().as_unsigned_short()); Should we merge this is_array_klass() query with the main if-else block below? We can probably skip setting raw access flags for array classes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2578581321 From liach at openjdk.org Tue Dec 2 17:27:43 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 17:27:43 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 09:28:03 GMT, Per Minborg wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Tweak VH usage in some classes > > src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2036: > >> 2034: var constant = MethodHandleImpl.isCompileConstant(vh); >> 2035: var cache = adaptedMh; >> 2036: if (constant == MethodHandleImpl.CONSTANT_YES && cache != null) { > > Rookie question: Is there multi-thread considerations here? How about visibility across threads? MethodHandle is immutable and can be safely published. So this is ok. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2582166754 From kvn at openjdk.org Tue Dec 2 17:34:58 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 2 Dec 2025 17:34:58 GMT Subject: RFR: 8371046: Segfault in compiler/whitebox/StressNMethodRelocation.java with -XX:+UseZGC In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 17:32:22 GMT, Chad Rakoczy wrote: > [JDK-8371046](https://bugs.openjdk.org/browse/JDK-8371046) > > This pull request fixes two crashes (see below) and adds `InvalidationReason::RELOCATED` to better describe why an nmethod is marked not entrant during relocation. > > --- > > #### 1. Test Bug > > It?s possible for an `nmethod` to be unloaded without its `_state` being explicitly set to `not_entrant`. Checking only `is_in_use()` isn?t sufficient, since the `nmethod` may already be in the process of unloading and therefore may not have a lock (as with ZGC, where `nmethods` are locked individually). > > The fix adds an additional `is_unloading()` check in WhiteBox before acquiring the lock. > > This issue was reproducible fairly consistently (every few runs) by executing `compiler/whitebox/StressNMethodRelocation.java` with `-XX:+UseZGC -XX:ReservedCodeCacheSize=32m` > > > After applying this patch, the original crash stopped occurring, though a more infrequent crash was still observed. > > --- > > #### 2. Implementation Bug > > `nmethod::relocate` works by copying the instructions of an `nmethod` and then adjusting the call sites to account for new PC-relative offsets. > > Previously, this fix-up happened *after* calling `post_init()`, which registers the `nmethod` and makes it visible to the GC. This introduced a race condition where the GC might attempt to resolve a call site before it had been fixed. > > The fix ensures that all call sites are patched **before** the `nmethod` is registered. > > In testing, the crash previously occurred roughly 60 times in 5,000 runs (~1.2%). With this patch, no crashes were observed in the same number of runs. >> May be we should change the assert to guarantee in Relocation::pd_set_call_destination() to make sure we catch incorrect patching it product VM. > I'm not opposed to changing this. Is this the main concern? Yes, my main concern is that new encoding of address in cloned nmethod may not fit into existing instructions set. At least with guarantee we can catch such case if it happened. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28241#issuecomment-3603204728 From qamai at openjdk.org Tue Dec 2 17:48:43 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 2 Dec 2025 17:48:43 GMT Subject: RFR: 8354282: C2: more crashes in compiled code because of dependency on removed range check CastIIs [v8] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 09:20:41 GMT, Roland Westrelin wrote: >> This is a variant of 8332827. In 8332827, an array access becomes >> dependent on a range check `CastII` for another array access. When, >> after loop opts are over, that RC `CastII` was removed, the array >> access could float and an out of bound access happened. With the fix >> for 8332827, RC `CastII`s are no longer removed. >> >> With this one what happens is that some transformations applied after >> loop opts are over widen the type of the RC `CastII`. As a result, the >> type of the RC `CastII` is no longer narrower than that of its input, >> the `CastII` is removed and the dependency is lost. >> >> There are 2 transformations that cause this to happen: >> >> - after loop opts are over, the type of the `CastII` nodes are widen >> so nodes that have the same inputs but a slightly different type can >> common. >> >> - When pushing a `CastII` through an `Add`, if of the type both inputs >> of the `Add`s are non constant, then we end up widening the type >> (the resulting `Add` has a type that's wider than that of the >> initial `CastII`). >> >> There are already 3 types of `Cast` nodes depending on the >> optimizations that are allowed. Either the `Cast` is floating >> (`depends_only_test()` returns `true`) or pinned. Either the `Cast` >> can be removed if it no longer narrows the type of its input or >> not. We already have variants of the `CastII`: >> >> - if the Cast can float and be removed when it doesn't narrow the type >> of its input. >> >> - if the Cast is pinned and be removed when it doesn't narrow the type >> of its input. >> >> - if the Cast is pinned and can't be removed when it doesn't narrow >> the type of its input. >> >> What we need here, I think, is the 4th combination: >> >> - if the Cast can float and can't be removed when it doesn't narrow >> the type of its input. >> >> Anyway, things are becoming confusing with all these different >> variants named in ways that don't always help figure out what >> constraints one of them operate under. So I refactored this and that's >> the biggest part of this change. The fix consists in marking `Cast` >> nodes when their type is widen in a way that prevents them from being >> optimized out. >> >> Tobias ran performance testing with a slightly different version of >> this change and there was no regression. > > Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Merge branch 'master' into JDK-8354282 > - whitespace > - review > - review > - Update src/hotspot/share/opto/castnode.cpp > > Co-authored-by: Christian Hagedorn > - Update src/hotspot/share/opto/castnode.cpp > > Co-authored-by: Christian Hagedorn > - Update src/hotspot/share/opto/castnode.cpp > > Co-authored-by: Christian Hagedorn > - Update test/hotspot/jtreg/compiler/c2/irTests/TestPushAddThruCast.java > > Co-authored-by: Christian Hagedorn > - review > - review > - ... and 7 more: https://git.openjdk.org/jdk/compare/ef5e744a...93b8b0c5 src/hotspot/share/opto/castnode.hpp line 105: > 103: // All the possible combinations of floating/narrowing with example use cases: > 104: > 105: // Use case example: Range Check CastII I believe this is incorrect, a range check should be floating non-narrowing. It is only narrowing if the length of the array is a constant. It is because this cast encodes the dependency on the condition `index u< length`. This condition cannot be expressed in terms of `Type` unless `length` is a constant. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2582188782 From qamai at openjdk.org Tue Dec 2 17:48:44 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 2 Dec 2025 17:48:44 GMT Subject: RFR: 8354282: C2: more crashes in compiled code because of dependency on removed range check CastIIs [v8] In-Reply-To: References: <0An6wz0QZZxtVg-lP4IyqWTekcYkSmvosrVWkI7cH70=.86c07374-2127-4892-a369-ceefa82dd0b7@github.com> <_rBmTvf064PXyVEAX4zqk43DNgVr0gQDPzPcdQ4XI1A=.660e7e89-0a49-47e0-9639-972cbfbac5f0@github.com> <4qc5jJ1KA09yko5rWioBGstpuuRNxOiNWXRdRdh9h_E=.17c8ace8-c672-4451-bd15-247d66d92cef@github.com> Message-ID: On Tue, 2 Dec 2025 16:48:55 GMT, Emanuel Peter wrote: >> Suggestion: >> >> // Use case example: Range Check CastII >> // Floating: The Cast is only dependent on the single range check. If the range check was ever to be hoisted >> // it would be safe to let the the Cast float to where the range check is hoisted up to. >> // Narrowing: The Cast narrows the type to a positive index. If the input to the Cast is narrower, we can safely >> // remove the cast because the array access will be safe. > > Ok, I now read the PR from the top, and not just recent changes. If one were to start reading from the top, it would be clear without my suggestions here. But I think it could still be good to apply something about letting the Cast float to where we would hoist the RC. Naming is hard, but it is worth pointing out in the comment that floating here refers to `depends_only_on_test`. In other words, a cast is considered floating if it is legal to change the control input of a cast from an `IfTrue` or `IfFalse` to an `IfTrue` and `IfFalse` that dominates the current control input, and the corresponding conditions of the `If`s are the same. In contrast, we cannot do that for a pinned cast, and if the control is folded away, the control input of the pinned cast is changed to the control predecessor of the folded node. It is also worth noting that we have `Node::pinned` which means the node is pinned AT the control input while pinned here means that it is pinned UNDER the control input. Very confusing! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24575#discussion_r2582215477 From valeriep at openjdk.org Tue Dec 2 18:56:52 2025 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 2 Dec 2025 18:56:52 GMT Subject: RFR: 8371820: Further AES performance improvements for key schedule generation [v7] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 10:27:36 GMT, Martin Doerr wrote: >> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption. >> >> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64. > > Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - Minor simplification. > - Merge remote-tracking branch 'origin' into 8371820_AES_Crypt > - Fix missing whitespace. > - Address review comments. > - Merge remote-tracking branch 'origin' into 8371820_AES_Crypt > - Remove K from AES_Crypt > - More minor cleanup. > - Improve comment and minor cleanup. > - 8371820: Further AES performance improvements for key schedule generation Marked as reviewed by valeriep (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28299#pullrequestreview-3531689005 From sspitsyn at openjdk.org Tue Dec 2 19:23:36 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 2 Dec 2025 19:23:36 GMT Subject: RFR: 8372098: Move AccessFlags to InstanceKlass [v7] In-Reply-To: References: <4LqPcDIgdyt_jaF-mX4LVsgXzaHDxmDYTFptWYVdVXc=.1b12674f-51a4-4f03-bf99-50245b016051@github.com> Message-ID: On Tue, 2 Dec 2025 13:24:54 GMT, Coleen Phillimore wrote: >> ArrayKlass doesn't set AccessFlags so don't look for them there. See CR for details. >> Fixed SA and jvmci. @iwanowww Can you check that I changed C2 correctly (we talked about this in August). >> Tested with tier1-4. 5-7 in progress. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fixed indentation. Marked as reviewed by sspitsyn (Reviewer). src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java line 101: > 99: } > 100: headerSize = type.getSize(); > 101: accessFlags = new CIntField(type.getCIntegerField("_access_flags"), 0); Nit: Not a big deal but this line also does not have proper indent. You can ignore this comment though. :) ------------- PR Review: https://git.openjdk.org/jdk/pull/28371#pullrequestreview-3531778810 PR Review Comment: https://git.openjdk.org/jdk/pull/28371#discussion_r2582521355 From mdoerr at openjdk.org Tue Dec 2 19:36:58 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 2 Dec 2025 19:36:58 GMT Subject: RFR: 8371820: Further AES performance improvements for key schedule generation [v7] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 10:27:36 GMT, Martin Doerr wrote: >> This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption. >> >> The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64. > > Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision: > > - Minor simplification. > - Merge remote-tracking branch 'origin' into 8371820_AES_Crypt > - Fix missing whitespace. > - Address review comments. > - Merge remote-tracking branch 'origin' into 8371820_AES_Crypt > - Remove K from AES_Crypt > - More minor cleanup. > - Improve comment and minor cleanup. > - 8371820: Further AES performance improvements for key schedule generation Thanks for all reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28299#issuecomment-3603660124 From mdoerr at openjdk.org Tue Dec 2 19:40:17 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 2 Dec 2025 19:40:17 GMT Subject: Integrated: 8371820: Further AES performance improvements for key schedule generation In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 16:48:28 GMT, Martin Doerr wrote: > This fix simplifies the hotspot intrinsics for some platforms and optimizes the key computation for encryption. We can save the `genInvRoundKeys` computation when we only do encryption. > > The micro:org.openjdk.bench.javax.crypto.AESReinit benchmark results are improved by 17% for ppc64 and 26% for x86_64. This pull request has now been integrated. Changeset: 618732ff Author: Martin Doerr URL: https://git.openjdk.org/jdk/commit/618732ffc04ef393c9b8a3265c12ba66f31784d9 Stats: 61 lines in 7 files changed: 13 ins; 8 del; 40 mod 8371820: Further AES performance improvements for key schedule generation Reviewed-by: rrich, valeriep ------------- PR: https://git.openjdk.org/jdk/pull/28299 From pchilanomate at openjdk.org Tue Dec 2 20:12:47 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 2 Dec 2025 20:12:47 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v11] In-Reply-To: References: Message-ID: > When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes. > > This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes: > > - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. > An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version. > > - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`. > > - The code was previously structured in terms of mount and un... Patricio Chilano Mateo 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 13 additional commits since the last revision: - Merge branch 'master' into JDK-8364343 - rebind in end_transition only for mount case - Fix comment in inline_native_vthread_start_transition - missing to initialize _is_disabler_at_start - More changes from Coleen's review - Drop VTMS from names - keep preexisting rebind order for mount - Remove INCLUDE_JVMTI macro - David's comments - Rename VM methods for endFirstTransition/startFinalTransition - ... and 3 more: https://git.openjdk.org/jdk/compare/836ae793...1f1cd594 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28361/files - new: https://git.openjdk.org/jdk/pull/28361/files/44af0ca9..1f1cd594 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=09-10 Stats: 84290 lines in 1350 files changed: 54871 ins; 20868 del; 8551 mod Patch: https://git.openjdk.org/jdk/pull/28361.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28361/head:pull/28361 PR: https://git.openjdk.org/jdk/pull/28361 From pchilanomate at openjdk.org Tue Dec 2 20:12:49 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 2 Dec 2025 20:12:49 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v10] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 06:20:44 GMT, David Holmes wrote: > Nothing further from me. Again a great piece of work! > > Thanks > Thanks for the review David! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3603774217 From pchilanomate at openjdk.org Tue Dec 2 20:20:32 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 2 Dec 2025 20:20:32 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v11] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 19:46:20 GMT, Alan Bateman wrote: >> I renamed the methods as suggested. I remembered that we separated ThreadStart/ThreadEnd in 8306028 for future improvements related to JVMTI. Not sure if that?s still relevant but in any case probably better to leave that discussion for a separate bug. > > Given the comment block to define the terms "mount transition" and "unmount transition" then we could go a bit further and make it 6 methods: start/endMountTransition, start/endUnmountTransition, endFirstMountTransition and startLastUnmountTransition. We don't have to do it now, but it would make the use-sites clearer I think. Sounds good, filed https://bugs.openjdk.org/browse/JDK-8372953. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2582659743 From pchilanomate at openjdk.org Tue Dec 2 20:20:30 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 2 Dec 2025 20:20:30 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v10] In-Reply-To: References: Message-ID: <5iEOi2ZO_ZVQbanlfWXhjIyGMQvZ4rt09LIK9YP-bgg=.5d15e13d-81cc-4843-bdb2-244841949808@github.com> On Tue, 2 Dec 2025 08:15:53 GMT, Serguei Spitsyn wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comment in inline_native_vthread_start_transition > > src/hotspot/share/runtime/mountUnmountDisabler.cpp line 88: > >> 86: // We rebinded on start_transition but the mount/unmount operation >> 87: // failed so now we need to rebind to the original state. >> 88: _current->rebind_to_jvmti_thread_state_of(_is_mount ? _vthread() : _current->threadObj()); > > Q: Not sure I fully understand this comment. We have done a rebind at the line 67 for an unmount transition only. But this comment tells that it was done for mount transition as well. Also, before this update, we used to do a rebind of `JvmtiThreadState` to a vthread in the `JvmtiVTMSTransitionDisabler::VTMS_mount_end()` for the normal (not failed) case. Please, could you explain a little bit more? It feels like this comment needs a correction. Yes, well spotted. I changed it to rebind the state only for the mount case, as in current code. This already handles a successful mount or a failed unmount. I also added and assert to verify we rebinded to the correct identity. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2582654454 From vlivanov at openjdk.org Tue Dec 2 20:21:29 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 20:21:29 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com> Message-ID: <_Z6KpxCYH2n3sHuT6-kRP4cSTAN3-s5UA0rbfrJSIgA=.e9d4089c-8329-406b-9a0a-167a24311c13@github.com> On Tue, 2 Dec 2025 02:51:57 GMT, Chen Liang wrote: >> So, it seems like what you are trying to achieve is a 1-1 mapping from `AccessDescriptor` to `vh` through `adaptedMh`. So, once `cache != null` you can trust that it corresponds to the `vh` instance passed as a constant. But cache pollution can easily break the invariant, so you try to eliminate the pollution by avoiding cache updates when vh is not constant. Do I get it right? > > No. The avoidance of cache update simply trims down the generated code by throwing away the meaningless cache update. > > The access to cache is already safeguarded by `constant == MethodHandleImpl.CONSTANT_YES`. I should have moved `var cache = adaptedMh;` into the if block of `constant == CONSTANT_YES`. I still find it confusing, especially tri-state logic part. For background, `isCompileConstant` was introduced as part of LF sharing effort to get rid of Java-level profiling in optimized code. The pattern is was designed for was: if (isCompileConstant(...)) { return ...; } else { ... // do some extra work (either in interpreter, C1, or not-fully-optimized version in C2) } In this patch, you don't follow that pattern and aadd new state (`CONSTANT_PENDING`) to distinguish interpreter/C1 from C2. What's the motivation? Why do you want to avoid cache updates coming from C2-generated code? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2582647097 From vlivanov at openjdk.org Tue Dec 2 20:21:33 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 20:21:33 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 23:41:04 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Tweak VH usage in some classes src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2042: > 2040: // This is still a hot path if vh is not constant - in this case, > 2041: // asType is the bottleneck for constant folding, unfortunately > 2042: var result = vh.getMethodHandle(mode).asType(symbolicMethodTypeInvoker); `mode` and `symbolicMethodTypeInvoker` are part of `AccessDescriptor` while `vh` comes as an argument. What guarantees that a cached adapter is compatible with `vh` observed during subsequent calls? It means that `vh` shape stays exactly the same shape. Is it correct? Would be good to have it validated with asserts. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2582661917 From sspitsyn at openjdk.org Tue Dec 2 20:31:30 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 2 Dec 2025 20:31:30 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v11] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 20:12:47 GMT, Patricio Chilano Mateo wrote: >> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes. >> >> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes: >> >> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. >> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version. >> >> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`. >> >> - The code was previously structured in t... > > Patricio Chilano Mateo 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 13 additional commits since the last revision: > > - Merge branch 'master' into JDK-8364343 > - rebind in end_transition only for mount case > - Fix comment in inline_native_vthread_start_transition > - missing to initialize _is_disabler_at_start > - More changes from Coleen's review > - Drop VTMS from names > - keep preexisting rebind order for mount > - Remove INCLUDE_JVMTI macro > - David's comments > - Rename VM methods for endFirstTransition/startFinalTransition > - ... and 3 more: https://git.openjdk.org/jdk/compare/4b22489c...1f1cd594 Marked as reviewed by sspitsyn (Reviewer). Yes, this is a great work! src/hotspot/share/runtime/mountUnmountDisabler.cpp line 87: > 85: } > 86: DEBUG_ONLY(bool is_virtual = java_lang_VirtualThread::is_instance(_current->jvmti_vthread())); > 87: assert((_is_mount && is_virtual) || (!_is_mount && !is_virtual), "wrong identity"); Nit: Thank you for update! This check can be simplified with: assert(_is_mount == is_virtual), "wrong identity"); But it becomes more obscure though. Feel free to ignore this comment. ------------- PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3531985682 PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3603842122 PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2582681780 From pchilanomate at openjdk.org Tue Dec 2 20:42:29 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 2 Dec 2025 20:42:29 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v12] In-Reply-To: References: Message-ID: > When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes. > > This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes: > > - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. > An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version. > > - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`. > > - The code was previously structured in terms of mount and un... Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: simplify assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28361/files - new: https://git.openjdk.org/jdk/pull/28361/files/1f1cd594..7ffbbc6d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28361&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28361.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28361/head:pull/28361 PR: https://git.openjdk.org/jdk/pull/28361 From pchilanomate at openjdk.org Tue Dec 2 20:42:30 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 2 Dec 2025 20:42:30 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v11] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 20:28:22 GMT, Serguei Spitsyn wrote: > Yes, this is a great work! > Thanks for the review Serguei! > src/hotspot/share/runtime/mountUnmountDisabler.cpp line 87: > >> 85: } >> 86: DEBUG_ONLY(bool is_virtual = java_lang_VirtualThread::is_instance(_current->jvmti_vthread())); >> 87: assert((_is_mount && is_virtual) || (!_is_mount && !is_virtual), "wrong identity"); > > Nit: Thank you for update! This check can be simplified with: > > assert(_is_mount == is_virtual), "wrong identity"); > > But it becomes more obscure though. Feel free to ignore this comment. I applied the suggestion, it reads well to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28361#issuecomment-3603874550 PR Review Comment: https://git.openjdk.org/jdk/pull/28361#discussion_r2582710357 From sspitsyn at openjdk.org Tue Dec 2 21:22:12 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 2 Dec 2025 21:22:12 GMT Subject: RFR: 8364343: Virtual Thread transition management needs to be independent of JVM TI [v12] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 20:42:29 GMT, Patricio Chilano Mateo wrote: >> When `ThreadSnapshotFactory::get_thread_snapshot()` captures a snapshot of a virtual thread, it uses `JvmtiVTMSTransitionDisabler` class to disable mount/unmount transitions. However, this only works if a JVMTI agent has attached to the VM, otherwise virtual threads don?t honor the disable request. Since this snapshot mechanism is used by `jcmd Thread.dump_to_file` and `HotSpotDiagnosticMXBean` which don?t require a JVMTI agent to be present, getting the snapshot of a virtual thread in such cases can lead to crashes. >> >> This patch moves the transition-disabling mechanism out of JVMTI and into a new class, `MountUnmountDisabler`. The code has been updated so that transitions can be disabled independently of JVMTI, making JVMTI just one user of the API rather than the owner of the mechanism. Here is a summary of the key changes: >> >> - Currently when a virtual thread starts a mount/unmount transition we only need to check if `_VTMS_notify_jvmti_events` is set to decide if we need to go to the slow path. With these changes, JVMTI is now only one user of the API, so we instead check the actual transition disabling counters, i.e the per-vthread counter and the global counter. Since these can be set at any time (unlike `_VTMS_notify_jvmti_events` which is only set at startup or during a safepoint in case of late binding agents), we follow the classic Dekker pattern for the required synchronization. That is, the virtual thread sets the ?in transition? bits for the carrier and vthread *before* reading the ?transition disabled? counters. The thread requesting to disable transitions increments the ?transition disabled? counter *before* reading the ?in transition? bits. >> An alternative that avoids the extra fence in `startTransition` would be to place extra overhead on the thread requesting to disable transitions (e.g. using safepoint, handshake-all, or UseSystemMemoryBarrier). Performance analysis show no difference with current mainline so for now I kept this simpler version. >> >> - Ending the transition doesn?t need to check if transitions are disabled (equivalent to not need to poll when transitioning from unsafe to safe safepoint state). But we still require to go through the slow path if there is a JVMTI agent present, since we need to check for event posting and JVMTI state rebinding. As such, the end transition follows the same pattern that we have today of only needing to check `_VTMS_notify_jvmti_events`. >> >> - The code was previously structured in t... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > simplify assert Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28361#pullrequestreview-3532150956